Skip to main content

Compliance & Special Scans

What this covers

How to evaluate IT security configurations with the Greenbone Enterprise Appliance using compliance policies and audits. Covers creating, importing and managing policies; creating, starting and managing audits; using and exporting policy reports; generic policy scans (file content, registry, file checksums, CPE-based checks); the bundled standard policies (IT-Grundschutz, BSI TR-03116, BSI TR-02102); and running a TLS Map scan.

Source scope

Based on the Greenbone Enterprise Appliance manual (GOS 22.04 / OPENVAS SCAN 22.04), chapter 12, verified June 2026. Compliance policies and audits exist across the Greenbone stack generally, but the specific standard policies that are available depend on the feed in use. All page elements, field names and menu paths below are taken verbatim from that manual; nothing has been added.

In information technology, compliance is a primary approach for organizations to protect and secure their information and assets. Bodies such as ISACA and the Center for Internet Security (CIS) publish IT security standards, frameworks and guidelines that require appropriate security measures. A vulnerability assessment system like the Greenbone Enterprise Appliance can assist in evaluating those arrangements by performing audits based on policies.

How the pieces fit together:

  • A Policy is a scan configuration carrying the policy flag. It defines the compliance checks to perform.
  • An Audit is a scan task carrying the audit flag. It runs one policy against one or more targets.
  • A Policy Report shows the result of an audit, including detailed information about compliant, not compliant and incomplete requirements.
note

Because most audits verify local security configurations on the target systems, authenticated audits are generally recommended (and in case of doubt). Exceptions are audits that only check externally available services, such as SSL/TLS. (§12)

1. Configuring and Managing Policies​

Policies are scan configurations with the policy flag. All default policies by Greenbone are distributed via the feed and are downloaded and updated with each feed update. (§12.1)

If no default policies are available, a feed update may be necessary, or the Feed Import Owner may need to be set.

caution

Default policies cannot be edited. They can only be deleted temporarily by the Feed Import Owner or a super administrator — during the next feed update they will be downloaded again. To permanently delete a default policy, the Feed Import Owner has to delete it and afterwards be changed to (Unset). (§12.1)

In addition to the default policies, custom policies can be created or imported.

1.1 Creating a Policy​

(§12.1.1)

  1. Select Resilience > Compliance Policies in the menu bar.
  2. Create a new policy by clicking the new icon. (Alternatively, a policy can be imported — see below.)
  3. Enter the name of the policy in the input box Name.
  4. Click Save. The policy is created and displayed on the page Policies.
  5. In the row of the policy, click the edit icon.
  6. In the section Edit Network Vulnerability Test Families, select the radio button to include and automatically activate newly introduced VT families.
  7. In that section, activate the checkboxes in the column Select all NVTs if all VTs of a family should be activated.
  8. Click a VT family to edit it.
  9. In the column Selected, activate the checkboxes of the VTs that should be activated.
  10. Click a VT to edit it.
  11. Click Save to save the VT.
  12. Click Save to save the family of VTs.
  13. Optional: edit scanner preferences.
  14. Optional: edit VT preferences.
  15. Click Save to save the policy.
note

The following VT families cannot be edited: CentOS, Debian, Fedora, Huawei EulerOS, Oracle Linux, Red Hat, SuSE and Ubuntu Local Security Checks. (§12.1.1)

note

If system-specific VTs of the VT family Policy are used (e.g., beginning with Linux, Microsoft Windows, Microsoft Office), the radio button Yes has to be selected for Verbose Policy Controls in the VT Compliance Tests (VT family Compliance). If editing the VT includes uploading a text file, the file should use UTF-8 text encoding. (§12.1.1)

1.2 Importing a Policy​

(§12.1.2)

  1. Select Resilience > Compliance Policies in the menu bar.
  2. Click the import icon.
  3. Click Browse... and select the XML file of the policy.
  4. Click Import. The imported policy is displayed on the page Policies.
  5. Execute steps 5 to 15 of Creating a Policy to edit the policy.

If the name of the imported policy already exists, a numeric suffix is added to the name.

1.3 Managing Policies​

(§12.1.3)

List page. All existing policies are listed under Resilience > Compliance Policies. The list shows the Name of each policy. Available row actions:

  • Move the policy to the trashcan. Only policies not currently used can be moved. While in the trashcan, the policy is not downloaded anew during the next feed update.
  • Edit the policy. Only self-created policies that are not currently used can be edited.
  • Clone the policy.
  • Create a new audit for the policy (see section 2).
  • Export the policy as an XML file.

More than one policy can be moved to the trashcan or exported at once using the controls below the list and the drop-down selector.

Details page. Click the name of a policy to open its details. The following registers are available: Information, Scanner Preferences (current and default values), NVT Families (number of activated VTs and the trend), NVT Preferences, and Permissions. The upper-left toolbar offers actions to open the manual chapter, show the list page, create a new policy, clone, edit, move to trashcan, export and import.

2. Configuring and Managing Audits​

Audits are scan tasks with the audit flag. (§12.2)

2.1 Creating an Audit on the Page Audits​

(§12.2.1.1)

  1. Select Resilience > Compliance Audits in the menu bar.
  2. Create an audit by clicking the new icon.
  3. Define the audit (see fields below).
  4. Click Save. The audit is created and displayed on the page Audits.

The following information can be entered:

  • Name — freely chosen; a descriptive name is recommended.
  • Comment — optional background information.
  • Scan Targets — select a previously configured target, or create one on the fly.
  • Alerts — select a previously configured alert, or create one on the fly. Status changes can be communicated via e-mail, Syslog, HTTP or a connector.
  • Schedule — select a previously configured schedule, or create one on the fly. The audit can run once or repeatedly (e.g., every Monday at 6:00 am).
  • Add results to Assets — makes the systems available to asset management automatically; can be changed later.
  • Alterable Audit — allows modifying the audit's scan target(s) and scanner even after reports were created. Consistency between reports can then no longer be guaranteed.
  • Auto Delete Reports — may automatically delete old reports once a configurable maximum is exceeded; the factory setting is Do not automatically delete reports.
  • Policy — only one policy can be configured per audit.
  • Order for target hosts — Sequential, Random or Reverse. Random is recommended to improve scan progress estimation. This does not affect the alive test, which is always random.
  • Maximum concurrently executed NVTs per host / Maximum concurrently scanned hosts — controls scan speed (maxchecks / maxhosts). Defaults are chosen sensibly; raising them may negatively affect the scanned systems, the network or the appliance.

2.2 Creating an Audit Through a Policy​

(§12.2.1.2)

  1. Select Resilience > Compliance Policies in the menu bar.
  2. In the row of the desired policy, click the create audit icon. The policy is already selected in the drop-down list Policy.
  3. Define the audit (same fields as in section 2.1).
  4. Click Save. The audit is created and displayed on the page Audits.

2.3 Starting an Audit​

(§12.2.2)

In the row of the newly created audit, click the start icon. For scheduled audits a different icon is shown and the audit starts at the time defined in the schedule.

The audit is added to the waiting queue, then the scanner begins the scan. The report can be displayed as soon as the audit has started by clicking the bar in the column Status. As soon as the status changes to Done, the complete report is available; intermediate results can be reviewed at any time.

note

It can take a while for the scan to complete. The page refreshes automatically when new data is available. In some cases an audit may remain in the queue. (§12.2.2)

2.4 Managing Audits​

(§12.2.3)

List page. All existing audits are listed under Resilience > Compliance Audits. For each audit the list shows:

  • Name — with optional icons indicating that the audit is alterable, runs on a remote scanner, is visible to other users, or is owned by another user.
  • Status — a status bar. Possible states include: no runs yet, requested/queued, running (percentage based on VTs executed), processing data, Done, stop requested, stopped, resuming, deleted (in progress), and interrupted by an error. Audits that are preparing, processing, resuming, stop-requested or being deleted cannot be stopped, resumed or deleted.
  • Report — date and time of the latest report; clicking it opens the latest report's details.
  • Compliance Status — the relation of requirements identified as compliant to those identified as non-compliant, as a percentage.

Available row actions: start, stop (all discovered results are written to the database), show schedule details (scheduled audits only), resume, move to trashcan, edit, clone, export as XML, and download the report as a GCR file (Greenbone Compliance Report in PDF format). Multiple audits can be moved to trashcan or exported at once via the controls below the list.

caution

When resuming a scan, all unfinished hosts are scanned completely anew; the data of hosts that were already fully scanned is kept. (§12.2.3)

Details page. Click the name of an audit to open its details. Registers: Information and Permissions. The upper-left toolbar offers: open manual chapter, show list page, create new audit, clone, edit, move to trashcan, export, start, stop, resume, show last/all reports, and show results.

3. Using and Managing Policy Reports​

Reports for audits are similar to reports of all other tasks. Once a scan has started, the report of results found so far can be viewed; when the scan completes, the status changes to Done and no more results are added. (§12.3)

3.1 Using a Policy Report​

A policy report is used the same way as any other report — reading, interpreting, filtering, exporting, importing and comparing all apply. See Reports & Vulnerability Management for details. (§12.3.1)

3.2 Exporting a Policy Report​

(§12.3.2)

caution

A policy report must always be downloaded in the report format Greenbone Compliance Report PDF (GCR PDF). Downloading it in any other report format will result in an empty report. (§12.3.2)

From the page Audits:

  1. Select Resilience > Compliance Audits in the menu bar.
  2. In the row of the desired audit, click the download GCR icon.
  3. Download the PDF file.

4. Generic Policy Scans​

(§12.4)

When performing policy scans, the VT family Policy provides groups of four VTs that can be configured. At least the base VT and one additional VT are required to run a policy scan. The four VT types are:

  • Base — performs the actual scan of the policy.
  • Errors — summarizes items in which errors occurred when running the base VT.
  • Matches — summarizes items that match the checks performed by the base VT.
  • Violations — summarizes items that did not match the checks performed by the base VT.
note

The base VT must always be selected — it performs the actual tests. The other three may be selected as needed. For example, if matching patterns are of no concern, only a VT of type Violations should be added. (§12.4)

4.1 Checking File Content​

(§12.4.1)

File content checks test the compliance of file contents (e.g., configuration files) against a given policy rather than testing for vulnerabilities. This is generally an authenticated scan, and it can only be performed on systems supporting the grep command (normally Linux or Linux-like systems). The four VTs are File Content, File Content: Errors, File Content: Matches and File Content: Violations.

Checking file content patterns. First create a reference file. It must contain the header row filename|pattern|presence/absence; each subsequent row is a test entry with three |-separated fields — path and file name, the pattern to check (as a regular expression), and presence or absence. Example:

filename|pattern|presence/absence
/tmp/filecontent_test|^paramter1=true.*$|presence
/tmp/filecontent_test|^paramter2=true.*$|presence
/tmp/filecontent_test|^paramter3=true.*$|absence
/tmp/filecontent_test_notthere|^paramter3=true.*$|absence

Then:

  1. Select Resilience > Compliance Policies.
  2. In the row of the desired policy, click the clone icon. The cloned policy is displayed on the page Policies.
  3. In the row of the cloned policy, click the edit icon.
  4. In the section Edit Network Vulnerability Test Families, click the VT family Policy. All VTs that allow special configuration are listed.
  5. Click the edit icon for File Content.
  6. Activate the checkbox Upload file. (If a reference file was already uploaded, Replace existing file is shown instead. Changing the reference file is only possible while the policy is not in use.)
  7. Click Browse... and select the reference file.
  8. Click Save to save the VT, Save to save the family of VTs, and Save to save the policy.

Changing the severity. VTs of type Violations have a default severity of 10. This can be changed using overrides. Because the checks are split into three VTs (e.g., File Content: Violations, File Content: Errors), distinct overrides per type can be created and are reflected in the reports.

4.2 Checking Registry Content​

(§12.4.2)

The registry is a database in Microsoft Windows that holds information about system hardware, installed programs, settings and user accounts. The appliance can verify registry entries to check for the presence or absence of settings as well as registry violations. Because the registry is unique to Microsoft Windows, this check runs only on Windows systems and requires an authenticated scan. The four VTs are Windows Registry Check, Windows Registry Check: Errors, Windows Registry Check: OK and Windows Registry Check: Violations.

Checking registry content patterns. First create a reference file. It must contain the header row Present|Hive|Key|Value|ValueType|ValueContent; each subsequent row has six |-separated fields — whether the entry should be present, the hive, the key, the value, the value type and the value content. A star * in the last column means any value is accepted for existence or non-existence. Example:

Present|Hive|Key|Value|ValueType|ValueContent
TRUE|HKLM|SOFTWARE\Macromedia\FlashPlayer\SafeVersions|8.0|REG_DWORD|33
TRUE|HKLM|SOFTWARE\Microsoft\Internet Explorer
TRUE|HKLM|SOFTWARE\Microsoft\Internet Explorer|Version|REG_SZ|9.11.10240.16384
FALSE|HKLM|SOFTWARE\Virus
TRUE|HKLM|SOFTWARE\ShouldNotBeHere
TRUE|HKLM|SOFTWARE\Macromedia\FlashPlayer\SafeVersions|8.0|REG_DWORD|*

Then:

  1. Select Resilience > Compliance Policies.
  2. In the row of the policy Microsoft Windows Registry Check, click the clone icon.
  3. In the row of the cloned policy, click the edit icon.
  4. In the section Edit Network Vulnerability Test Families, click the VT family Policy.
  5. Click the edit icon for Windows Registry Check.
  6. Activate the checkbox Upload file (or Replace existing file if one was already uploaded).
  7. Click Browse... and select the reference file.
  8. Click Save for the VT, Save for the family, and Save for the policy.

Changing the severity. As above, Violations VTs default to severity 10 and can be adjusted per type using overrides.

4.3 Checking File Checksums​

(§12.4.3)

File checksum checks test for file integrity by verifying file content against MD5 or SHA1 checksums. This is generally an authenticated check on systems supporting checksums (normally Linux or Linux-like); a separate module exists for Microsoft Windows (see below). The four VTs are File Checksums, File Checksums: Errors, File Checksums: Matches and File Checksums: Violations.

Checking file checksum patterns. First create a reference file. It must contain the header row Checksum|File|Checksumtype; each subsequent row has three |-separated fields — the checksum in hex, the path and file name, and the checksum type (md5 or sha1). Example:

Checksum|File|Checksumtype
6597ecf8208cf64b2b0eaa52d8169c07|/bin/login|md5
ed3ed98cb2efa9256817948cd27e5a4d9be2bdb8|/bin/bash|sha1
7c59061203b2b67f2b5c51e0d0d01c0d|/bin/pwd|md5
caution

Checksums and checksum types must be lowercase. (§12.4.3.1)

Then:

  1. Select Resilience > Compliance Policies.
  2. In the row of the desired policy, click the clone icon.
  3. In the row of the cloned policy, click the edit icon.
  4. In the section Edit Network Vulnerability Test Families, click the VT family Policy.
  5. Click the edit icon for File Checksums.
  6. Activate the checkbox Upload file (or Replace existing file).
  7. Click Browse... and select the reference file.
  8. Click Save for the VT, Save for the family, and Save for the policy.

Changing the severity. Violations VTs default to severity 10 and can be adjusted per type using overrides.

Checking file checksum patterns for Microsoft Windows. (§12.4.3.3) Windows has no built-in checksum tool, so the appliance uses ReHash, which can be installed manually or automatically by the VT. The Windows checksum VTs are also in the VT family Policy.

  1. Create a reference file with the same Checksum|File|Checksumtype format as above.
  2. In the row of the respective policy, click the edit icon.
  3. In the section Edit Network Vulnerability Test Families, click the VT family Policy.
  4. Click the edit icon for Windows file Checksums.
  5. For Delete hash test Programm after the test, select the radio button Yes if ReHash should be removed after the check. (Leaving it installed can speed up recurring tests.)
  6. For Install hash test Programm on the Target, select Yes to install ReHash automatically.
  7. Activate the checkbox Upload file (or Replace existing file).
  8. Click Browse... and select the reference file.
  9. Click Save for the VT, Save for the family, and Save for the policy.
note

If ReHash is not installed automatically, it must be installed manually under C:\Windows\system32 (32-bit) or C:\Windows\SysWOW64 (64-bit) and must be executable for the authenticated user. (§12.4.3.3)

4.4 Performing CPE-Based Checks​

(§12.4.4)

Simple CPE-based checks. With every scan, CPEs for identified products are stored, independently of whether the product reveals a security problem. On this basis, simple security policies can describe checks for the presence or absence of a product, each associated with a severity that appears in the scan report. Because detection can come from a single VT or a number of specialized VTs, an optimized policy can concentrate on one product without other scan activity.

Detecting the presence of problematic products. (§12.4.4.2) This example classifies the presence of a product as a severe problem:

  1. Select Resilience > Compliance Policies.
  2. Create a new policy, define its name and click Save.
  3. In the row of the policy, click the edit icon.
  4. In the row of the VT family Policy, click to edit it.
  5. In the row of the VT CPE Policy Check, click to edit it.
  6. Either enter a single CPE in Single CPE (e.g., cpe:/a:microsoft:ie:6), or activate Upload file, click Browse... and select a text file of CPEs separated by commas or line breaks.
  7. Because the problematic product should not be present, select the radio button missing — if the product is discovered, it is evaluated as critical.
  8. Click Save to save the VT.
  9. Activate the checkbox Selected for: CPE Policy Check, CPE-based Policy Check Error, CPE-based Policy Check OK and CPE-based Policy Check Violations.
  10. Click Save to save the family of VTs.
  11. Activate the checkbox Selected for the VT family Product Detection, then click Save to save the policy.
  12. Create a target, create an audit using this policy, and run the audit.
  13. When complete, select Scans > Reports, enter cpe in the Filter input to show only CPE-based policy results, then open a report by its date.
note

To consider the mere availability of a product, configure remote access using credentials so local security checks apply; searching only running network services tends to increase false positives. Violations VTs default to severity 10 and can be changed using overrides. (§12.4.4.2)

5. Checking Standard Policies​

(§12.5)

Greenbone bundles policies for several published standards. Availability depends on the feed.

Standard policy (use this Policy in the audit)What it checks (per source)
IT-Grundschutz Kompendium (§12.5.1)Compliance with selected modules of the BSI IT-Grundschutz Compendium: SYS.1.2.2 Windows Server 2012, SYS.1.3 Server on Linux and Unix, SYS.2.2.2 Clients on Windows 8.1, SYS.2.2.3 Clients on Windows 10, SYS.2.3 Clients on Linux and Unix.
BSI TR-03116: Part 4 (§12.5.2)Cryptographic requirements (SSL/TLS) for federal government services. Tests whether hosts/services use SSL/TLS and, if so, compliance with: TLS version (lower than 1.2 not allowed), supported ciphers, and the allowed cipher suites for TLS 1.2 and TLS 1.3.
BSI TR-02102-4 (§12.5.3)Recommendations for the SSH protocol. Tests settings in /etc/ssh/sshd_config: Protocol (SSH version 2), KexAlgorithms, ReKeyLimit (renew after 1 hour or 1 GiB), Ciphers, MACs, HostKeyAlgorithms, AuthenticationMethods (publickey) and PubkeyAuthentication (publickey).

5.1 Running a Standard Policy Scan​

The procedure is the same for all three standards, differing only in the policy selected when creating the audit:

  1. Create a new target, create a new audit (using IT-Grundschutz Kompendium, BSI TR-03116: Part 4, or BSI TR-02102-4), and run the audit.
  2. When the scan is complete, select Scans > Reports and click the date of the report. The report contains detailed information about compliant, not compliant and incomplete requirements.
  3. To export the report, click the download icon.
  4. For Include, activate Notes to include attached notes and Overrides to label enabled overrides and include their text field.
  5. Select GCR PDF in the drop-down list Report Format.
  6. Click OK and download the PDF file.

6. Running a TLS Map Scan​

(§12.6)

The TLS protocol ensures the confidentiality, authenticity and integrity of communication in insecure networks. The appliance can identify systems offering SSL/TLS services, detect the protocol versions and offered encryption algorithms, and — where the service can be identified — gather further details. For an overview of TLS usage, Greenbone recommends the scan configuration TLS-Map.

note

A TLS Map scan uses a normal task with the TLS-Map scan configuration (not a compliance audit/policy), and the result is exported in the TLS Map report format. (§12.6)

  1. Select Configuration > Port Lists to review the pre-configured port lists. (Own port lists can be created.)
  2. Choose a suitable list of ports. A more extensive list takes longer but may detect services at unusual ports. TLS is mainly TCP-based, so a UDP port list slows the scan without benefit; select All TCP to cover all TCP ports.
  3. Create a new target, create a new task using the scan configuration TLS-Map, and run the task.
  4. When complete, select Scans > Reports and click the date of the report.
  5. To export, click the download icon.
  6. For Include, activate Notes and Overrides as needed.
  7. Select TLS Map in the drop-down list Report Format.
  8. Click OK and download the CSV file for use in spreadsheet applications.

The CSV file contains one line per port and system where an SSL/TLS protocol is offered, with the columns IP, Host, Port, TLS-Version, Ciphers and Application-CPE. When more than one value is offered for a column, the values are separated with semicolons. Example:

IP,Host,Port,TLS-Version,Ciphers,Application-CPE
192.168.12.34,www.local,443,TLSv1.0;SSLv3,SSL3_RSA_RC4_128_SHA;TLS1_RSA_RC4_128_SHA,cpe:/a:apache:http_server:2.2.22;cpe:/a:php:php:5.4.4
192.168.56.78,www2.local,443,TLSv1.0;SSLv3,SSL3_RSA_RC4_128_SHA;TLS1_RSA_RC4_128_SHA,cpe:/a:apache:http_server:2.2.22