12 Performing Compliance Scans and Special Scans

In information technology (IT) compliance is the main approach for organizations to keep their information and assets protected and secure.

With cybercrime on the rise, governments see the need to protect the identities and assets of their citizens by passing rules and regulations on privacy and IT security. Information security bodies such as the Information Systems Audit and Control Association (ISACA) or the International Organization for Standardization (ISO) publish IT security standards, frameworks and guidelines.

These standards, frameworks and guidelines require organizations to implement the appropriate safeguards to protect themselves and their information assets from attacks. For implementation the organization has to create an IT security framework consisting of policies, standards, baselines, guidelines and detailed procedures.

Vulnerability assessment systems such as the Greenbone Enterprise Appliance can assist IT security professionals to check their IT security safeguards for the standards, frameworks and guidelines mentioned above.

The appliance supports performing audits based on policies.

The Chapters 12.4, 12.5 and 12.6 show some examples for policy audits.

Note

The policies used in these chapters are provided via the feed.

Some policies may not be available yet, but will be added at a later time.

In case a policy is not available, contact the Greenbone Enterprise Support.

12.1 Configuring and Managing Policies

Policies are scan configurations with the flag policy.

All default policies by Greenbone are data objects that are distributed via the feed. They are downloaded and updated with each feed update.

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

Default policies cannot be edited. Furthermore, they can only be deleted temporarily by the Feed Import Owner or by a super administrator. During the next feed update, they will be downloaded again.

Note

To permanently delete a default policy, the Feed Import Owner has to delete it. Afterwards the Feed Import Owner has to be changed to (Unset) (see Chapter 7.2.1.9.1).

In addition to the default policies, custom policies can be created (see Chapter 12.1.1) or imported (see Chapter 12.1.2).

12.1.1 Creating a Policy

A new policy can be created as follows:

1. Select Resilience > Compliance Policies in the menu bar.

2. Create a new policy by clicking .

   Note

   Alternatively, a policy can be imported (see Chapter 12.1.2).

3. Enter the name of the policy in the input box Name (see Fig. 12.1).

   

   Fig. 12.1 Creating a new policy

4. Click Save.

   → The policy is created and displayed on the page Policies.

5. In the row of the policy, click .

6. In the sections Edit Network Vulnerability Test Families select the radio button if newly introduced VT families should be included and activated automatically (see Fig. 12.2).

   

   Fig. 12.2 Editing the new policy

7. In the section Edit Network Vulnerability Test Families activate the checkboxes in the column Select all NVTs if all VTs of a family should be activated.

8. Click for a VT family to edit it (see Fig. 12.3).

   Note

   The following VT families cannot be edited:

   • CentOS Local Security Checks
   • Debian Local Security Checks
   • Fedora Local Security Checks
   • Huawei EulerOS Local Security Checks
   • Oracle Linux Local Security Checks
   • Red Hat Local Security Checks
   • SuSE Local Security Checks
   • Ubuntu Local Security Checks
   

   Fig. 12.3 Editing a family of VTs

9. In the column Selected activate the checkboxes of the VTs that should be activated.

10. Click for a VT to edit it (see Fig. 12.4).

    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).

    Note

    If editing the VT includes uploading a text file, the file should use UTF-8 text encoding.

    

    Fig. 12.4 Editing a VT

11. Click Save to save the VT.
12. Click Save to save the family of VTs.
13. Optional: edit scanner preferences (see Chapter 10.9.4).
14. Optional: edit VT preferences (see Chapter 10.9.5).
15. Click Save to save the policy.

12.1.2 Importing a Policy

A policy can be imported as follows:

1. Select Resilience > Compliance Policies in the menu bar.

2. Click .

3. Click Browse… and select the XML file of the policy (see Fig. 12.5).

   

   Fig. 12.5 Importing a policy

4. Click Import.

   Note

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

   → The imported policy is displayed on the page Policies.

5. Execute steps 5 to 15 of Chapter 12.1.1 to edit the policy.

12.1.3 Managing Policies

List Page

All existing policies can be displayed by selecting Resilience > Compliance Policies in the menu bar (see Fig. 12.6).

Fig. 12.6 Page Policies displaying all available policies

For all policies the following information is displayed:

Name

Name of the policy.

For all policies the following actions are available:

• Move the policy to the trashcan. Only policies which are currently not used can be moved to the trashcan. As long as the policy is not deleted from the trashcan, it is not downloaded anew during the next feed update.
• Edit the policy. Only self-created policies which are currently not used can be edited.
• Clone the policy.
• Create a new audit for the policy (see Chapter 12.2.1.2).
• Export the policy as an XML file.

Note

By clicking or below the list of policies more than one policy can be moved to the trashcan or exported at a time. The drop-down list is used to select which policies are moved to the trashcan or exported.

Details Page

Click on the name of a policy to display the details of the policy. Click to open the details page of policy.

The following registers are available:

Information

General information about the policy.

Scanner Preferences

All scanner preferences for the policy with current and default values.

NVT Families

All VT families for the policy with the number of activated VTs and the trend.

NVT Preferences

All VT preferences for the policy.

Permissions

Assigned permissions (see Chapter 9.4).

The following actions are available in the upper left corner:

• Open the corresponding chapter of the user manual.
• Show the list page of all policies.
• Create a new policy (see Chapter 12.1.1).
• Clone the policy.
• Edit the policy. Only self-created policies which are currently not used can be edited.
• Move the policy to the trashcan. Only policies which are currently not used can be moved to the trashcan. As long as the policy is not deleted from the trashcan, it is not downloaded anew during the next feed update.
• Export the policy as an XML file.
• Import a policy (see Chapter 12.1.2).

12.2 Configuring and Managing Audits

Audits are scan tasks with the flag audit.

12.2.1 Creating an Audit

12.2.1.1 Creating an Audit on the Page Audits

An audit can be created on the page Audits as follows:

1. Select Resilience > Compliance Audits in the menu bar.

2. Create an audit by clicking .

3. Define the audit (see Fig. 12.7).

4. Click Save.

   → The audit is created and displayed on the page Audits.

The following information can be entered:

Name

The name can be chosen freely. A descriptive name should be chosen if possible.

Comment

The optional comment allows for the entry of background information. It simplifies understanding the configured audit later.

Scan Targets

Select a previously configured target from the drop-down list (see Chapter 10.2.1).

Additionally, the target can be created on the fly by clicking next to the drop-down list.

Alerts

Select a previously configured alert from the drop-down list (see Chapter 10.12). Status changes of an audit can be communicated via e-mail, Syslog, HTTP or a connector.

Additionally, an alert can be created on the fly by clicking next to drop-down list.

Schedule

Select a previously configured schedule from the drop-down list (see Chapter 10.10). The audit can be run once or repeatedly at a predetermined time, e.g., every Monday morning at 6:00 am.

Additionally, a schedule can be created on the fly by clicking next to the drop-down list.

Add results to Assets

Selecting this option will make the systems available to the appliance’s asset management automatically (see Chapter 13). This selection can be changed at a later point as well.

Alterable Audit

Allow for modification of the audit even though reports were already created. The consistency between reports can no longer be guaranteed if audits are altered.

Auto Delete Reports

This option may automatically delete old reports. The maximum number of reports to store can be configured. If the maximum is exceeded, the oldest report is automatically deleted. The factory setting is Do not automatically delete reports.

Policy

The appliance comes with four pre-configured policies.

Network Source Interface

Here the source interface of the appliance for the scan can be chosen.

Order for target hosts

Select in which order the specified target hosts are processed during vulnerability tests. Available options are:

• Sequential
• Random
• Reverse

In order to improve the scan progress estimation, the setting Random is recommended (see Chapter 17.2.3).

This setting does not affect the alive test during which active hosts in a target network are identified. The alive test is always random.

Maximum concurrently executed NVTs per host/Maximum concurrently scanned hosts

Select the speed of the scan on one host. The default values are chosen sensibly. If more VTs run simultaneously on a system or more systems are scanned at the same time, the scan may have a negative impact on either the performance of the scanned systems, the network or the appliance itself. These values “maxhosts” and “maxchecks” may be tweaked.

Fig. 12.7 Creating a new audit

12.2.1.2 Creating an Audit Through a Policy

An audit can directly be created for a policy as follows:

1. Select Resilience > Compliance Policies in the menu bar.

2. In the row of the desired policy, click .

   → The policy is already selected in the drop-down list Policy.

3. Define the audit.

   Tip

   For the information to enter in the input boxes see Chapter 12.2.1.1.

4. Click Save.

   → The audit is created and displayed on the page Audits.

12.2.2 Starting an Audit

In the row of the newly created audit, click .

Note

For scheduled audits is displayed. The audit is starting at the time that was defined in the schedule (see Chapter 10.10).

→ The audit is added to the waiting queue. Afterwards, the scanner begins with the scan.

Note

In some cases, the audit may remain in the queue. For more information see Chapter 17.3.

For the status of an audit see Chapter 12.2.3.

The report of an audit can be displayed as soon as the audit has been started by clicking the bar in the column Status. For reading, managing and downloading reports see Chapter 11.

As soon as the status changes to Done the complete report is available. At any the time the intermediate results can be reviewed (see Chapter 11.2.1).

Note

It can take a while for the scan to complete. The page is refreshing automatically if new data is available.

12.2.3 Managing Audits

List Page

All existing audits can be displayed by selecting Resilience > Compliance Audits in the menu bar (see Fig. 12.8).

Fig. 12.8 Page Audits displaying all available audits

For all audits the following information is displayed:

Name

Name of the audit. The following icons may be displayed:

The audit is marked as alterable. Some properties that would otherwise be locked once reports exist can be edited.

The audit is configured to run on a remote scanner (see Chapter 16).

The audit is visible to one or more other user(s).

The audit is owned by another user.

Status

Current status of the audit. The following status bars are possible:

The audit has not been run since it was created.

The audit was just started. The appliance is preparing the scan. Audits with this status cannot be stopped, resumed, or deleted.

The audit is currently running. The percent value is based on the number of VTs executed on the selected hosts. For this reason the value does not necessarily correlate with the time spent.

The audit was added to the waiting queue. In some cases, it may remain in the queue. For more information see Chapter 17.3.

The audit was deleted. The actual deletion process can take some time as reports need to be deleted as well. Audits with this status cannot be stopped, resumed, or deleted.

The audit was requested to stop recently. However, the scan engine has not yet reacted to this request yet. Audits with this status cannot be stopped, resumed, or deleted.

The audit was stopped. The latest report is possibly not yet complete. Other reasons for this status could be the reboot of the appliance or a power outage. After restarting the scanner, the audit will be resumed automatically.

The audit was just resumed. The appliance is preparing the scan. Audits with this status cannot be stopped, resumed, or deleted.

When resuming a scan, all unfinished hosts are scanned completely anew. The data of hosts that were already fully scanned is kept.

An error has occurred and the audit was interrupted. The latest report is possibly not complete yet or is missing completely.

The audit has been completed successfully.

Report

Date and time of the latest report. By clicking it the details page of the latest report is opened.

Compliance Status

Relation of requirements identified as compliant to requirements identified as non-compliant (percentage).

For all audits the following actions are available:

• Start the audit. Only currently not running audits can be started.
• Stop the currently running audit. All discovered results will be written to the database.
• Show details of the assigned schedule (only available for scheduled audits, see Chapter 10.10).
• Resume the stopped audit. All unfinished hosts are scanned completely anew. The data of hosts that were already fully scanned is kept.
• Move the audit to the trashcan.
• Edit the audit.
• Clone the audit.
• Export the audit as an XML file.
• Download the report of the audit as a GCR file (Greenbone Compliance Report as PDF format).

Note

By clicking or below the list of audits more than one audit can be moved to the trashcan or exported at a time. The drop-down list is used to select which audits are moved to the trashcan or exported.

Details Page

Click on the name of an audit to display the details of the audit. Click to open the details page of the audit.

The following registers are available:

Information

General information about the audit.

Permissions

Assigned permissions (see Chapter 9.4).

The following actions are available in the upper left corner:

• Open the corresponding chapter of the user manual.
• Show the list page of all audits.
• Create a new audit (see Chapter 12.2.1.1).
• Clone the audit.
• Edit the audit.
• Move the audit to the trashcan.
• Export the audit as an XML file.
• Start the audit. Only currently not running audits can be started.
• Stop the currently running audit. All discovered results will be written to the database.
• Resume the stopped audit. All unfinished hosts are scanned completely anew. The data of hosts that were already fully scanned is kept.
• Show the last report for the audit or show all reports for the audit.
• Show the results for the audit.

12.3 Using and Managing Policy Reports

Reports for audits are similar to reports of all other tasks.

Once a scan has been started, the report of the results found so far can be viewed. When a scan is completed, the status changes to Done and no more results will be added.

12.3.1 Using a Policy Report

A policy report can be used in the same way as any other report. Chapter 11.2 contains information about reading, interpreting, filtering, exporting, importing and comparing reports.

For further information about results and vulnerabilities see Chapters 11.3 and 11.4.

12.3.2 Exporting a Policy Report

Note

A policy reports 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.

Additionally, the report can be downloaded from the page Audits as follows:

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

12.4 Generic Policy Scans

When performing policy scans, there are groups of four VTs in the VT family Policy that can be configured accordingly.

At least the base VT and one additional VT are required to run a policy scan.

The four VT types are:

Base

This VT performs the actual scan of the policy.

Errors

This VT summarizes any items in which some errors occurred when running the base VT.

Matches

This VT summarizes any items which match the checks performed by the base VT.

Violations

This VT summarizes any items which did not match the checks performed by the base VT.

Note

The base VT must always be selected for a policy check since it performs the actual tests. The other three VTs may be selected according to the needs. For example, if matching patterns are of no concern then only a VT of the type Violations should be selected additionally.

12.4.1 Checking File Content

File content checks belong to policy audits which do not explicitly test for vulnerabilities but rather test the compliance of file contents (e.g., configuration files) regarding a given policy.

The appliance provides a policy module to check if a file content is compliant with a given policy.

In general, this is an authenticated scan, i.e., the scan engine will have to log into the target system to perform the check (see Chapter 10.3).

The file content check can only be performed on systems supporting the command grep. Normally this means Linux or Linux-like systems.

Four different VTs in the VT family Policy provide the file content check:

• File Content: this VT performs the actual file content check.
• File Content: Errors: this VT shows the files in which errors occurred (e.g., the file is not found on the target system).
• File Content: Matches: this VT shows the patterns and files which passed the file content check (the predefined pattern matches in the file).
• File Content: Violations: this VT shows the patterns and files which did not pass the file content check (the predefined pattern does not match in the file).

12.4.1.1 Checking File Content Patterns

1. Create a reference file with the patterns to check. Following is an 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

Note

This file must contain the row filename|pattern|presence/absence.

The subsequent rows each contain a test entry.

Each row contains three fields which are separated by |.

The first field contains the path and file name, the second field contains the pattern to check (as a regular expression) and the third field indicates if a pattern has to be present or absent.

2. Select Resilience > Compliance Policies in the menu bar.

3. In the row of the desired policy, click .

   → The cloned policy is displayed on the page Policies.

4. In the row of the cloned policy, click .

5. In the section Edit Network Vulnerability Test Families click for the VT family Policy.

   → All VTs that allow special configuration are listed (see Fig. 12.9).

   

   Fig. 12.9 Editing the family of VTs

6. Click for File Content.

7. Activate the checkbox Upload file (see Fig. 12.10).

   Tip

   If a reference file was already uploaded, the checkbox Replace existing file is displayed instead. The possibility to change the reference file is only available if the policy is currently not used.

   

   Fig. 12.10 Uploading the reference file

8. Click Browse… and select the previously created reference file.

9. Click Save to save the VT.

10. Click Save to save the family of VTs.

11. Click Save to save the policy.

12.4.1.2 Changing the Severity

The VTs of the type Violations have a default severity of 10.

This default severity can be changed using overrides (see Chapter 11.8).

By sectioning into three different VTs, it is possible to create distinct overrides for the severity according to the needs.

In the following example the severities of File Content: Violations and File Content: Errors have been changed which will be shown in the reports accordingly (see Fig. 12.11).

Fig. 12.11 Overrides changing the severity

12.4.2 Checking Registry Content

The registry is a database in Microsoft Windows containing important information about system hardware, installed programs, settings and user accounts on the computer. Microsoft Windows continually refers to the information in the registry.

Due to the nature of the Microsoft Windows registry every program/application installed under Microsoft Windows will register itself in the Microsoft Windows registry. Even malware and other malicious code usually leave traces within the registry.

The registry can be utilized to search for specific applications or malware related information such as version levels and numbers. Also, missing or changed registry settings could point to a potential security policy violation on an endpoint.

The appliance provides a policy module to verify registry entries on target systems. This module checks for the presence or absence of registry settings as well as registry violations.

Since the registry is unique to Microsoft Windows systems, this check can only be run on these systems.

To access the registry on the target system an authenticated scan has to be run.

Four different VTs in the VT family Policy provide the registry content check:

• Windows Registry Check: this VT performs the actual registry content check on the files.
• Windows Registry Check: Errors: this VT shows the files in which errors occurred (e.g., registry content not found on the target system).
• Windows Registry Check: OK: this VT shows the registry settings which passed the registry check (right registry content).
• Windows Registry Check: Violations: this VT shows the registry content which did not pass the registry check (wrong registry content).

12.4.2.1 Checking Registry Content Patterns

1. Create a reference file with the reference registry content. Following is an 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
TRUE|HKLM|SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
 System|LocalAccountTokenFilterPolicy|REG_DWORD|1
FALSE|HKLM|SOFTWARE\Virus
TRUE|HKLM|SOFTWARE\ShouldNotBeHere
TRUE|HKLM|SOFTWARE\Macromedia\FlashPlayer\SafeVersions|8.0|REG_DWORD|*

Note

This file must contain the row Present|Hive|Key|Value|ValueType|ValueContent.

The subsequent rows each contain a test entry.

Each row contains six fields which are separated by |.

The first field sets whether a registry entry should be present or not, the second the hive the registry entry is located in, the third the key, the fourth the value, the fifth the value type and the sixth the value content. If a star * is used in the last column any value is valid and accepted for existence or non-existence.

2. Select Resilience > Compliance Policies in the menu bar.

3. In the row of the policy Microsoft Windows Registry Check, click .

   → The cloned policy is displayed on the page Policies.

4. In the row of the cloned policy, click .

5. In the section Edit Network Vulnerability Test Families click for the VT family Policy.

   → All VTs that allow special configuration are listed (see Fig. 12.12).

   

   Fig. 12.12 Editing the family of VTs

6. Click for Windows Registry Check.

7. Activate the checkbox Upload file (see Fig. 12.13).

   Tip

   If a reference file was already uploaded, the checkbox Replace existing file is displayed instead. The possibility to change the reference file is only available if the policy is currently not used.

   

   Fig. 12.13 Uploading the reference file

8. Click Browse… and select the previously created reference file.

9. Click Save to save the VT.

10. Click Save to save the family of VTs.

11. Click Save to save the policy.

12.4.2.2 Changing the Severity

The VTs of the type Violations have a default severity of 10.

This default severity can be changed using overrides (see Chapter 11.8).

By sectioning into three different VTs, it is possible to create distinct overrides for the severity according to the needs.

In the following example the severities of Windows Registry Check: Violations and Windows Registry Check: Errors have been changed which will be shown in the reports accordingly (see Fig. 12.14).

Fig. 12.14 Overrides changing the severity

12.4.3 Checking File Checksums

File checksum checks belong to policy audits which do not explicitly test for vulnerabilities but rather for file integrity.

The appliance provides a policy module to verify file integrity on target systems. This module checks the file content by MD5 or SHA1 checksums.

In general, this is an authenticated check, i.e., the scan engine will have to log into the target system to perform the check.

The file checksum check can only be performed on systems supporting checksums. Normally this means Linux or Linux-like systems. However, the appliance provides a module for checksum checks for Microsoft Windows systems as well (see Chapter 12.4.3.3).

Four different VTs in the VT family Policy provide the file checksum check:

• File Checksums: this VT performs the actual checksum check on the files.
• File Checksums: Errors: this VT shows the files in which errors occurred (e.g., file not found on the target system).
• File Checksums: Matches: this VT shows the files which passed the checksum check (checksum matches).
• File Checksums: Violations: this VT shows the files which did not pass the checksum check (wrong checksum).

12.4.3.1 Checking File Checksum Patterns

1. Create a reference file with the reference checksums. Following is an example:

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

Note

This file must contain the row Checksum|File|Checksumtype.

The subsequent rows each contain a test entry.

Each row contains three fields which are separated by |.

The first field contains the checksum in hex, the second field the path and file name and the third field the checksum type. Currently MD5 and SHA1 checksums are supported.

Important

Checksums and checksum types must be lowercase.

2. Select Resilience > Compliance Policies in the menu bar.

3. In the row of the desired policy, click .

   → The cloned policy is displayed on the page Policies.

4. In the row of the cloned policy, click .

5. In the section Edit Network Vulnerability Test Families click for the VT family Policy.

   → All VTs that allow special configuration are listed (see Fig. 12.15).

   

   Fig. 12.15 Editing the family of VTs

6. Click for File Checksums.

7. Activate the checkbox Upload file (see Fig. 12.16).

   Tip

   If a reference file was already uploaded, the checkbox Replace existing file is displayed instead. The possibility to change the reference file is only available if the policy is currently not used.

   

   Fig. 12.16 Uploading the reference file

8. Click Browse… and select the previously created reference file.

9. Click Save to save the VT.
10. Click Save to save the family of VTs.
11. Click Save to save the policy.

12.4.3.2 Changing the Severity

The VTs of the type Violations have a default severity of 10.

This default severity can be changed using overrides (see Chapter 11.8).

By sectioning into three different VTs, it is possible to create distinct overrides for the severity according to the needs.

In the following example the severities of File Checksum: Violations and File Checksum: Errors have been changed which will be shown in the reports accordingly (see Fig. 12.17).

Fig. 12.17 Overrides changing the severity

12.4.3.3 Checking File Checksum Patterns for Microsoft Windows

The appliance provides a similar module for Microsoft Windows systems for file checksum checks.

Since Microsoft Windows does not provide an internal program for creating checksums it has to be installed one either manually or automatically by the VT. The appliance uses ReHash for creating checksums on Microsoft Windows systems.

Note

There are two operating modes for these checks:

• Using a tool that was installed on the target system manually.
• The tool ReHash will automatically be installed and deinstalled as well if requested on the target system during the checking routine.

As for Linux systems the VTs for checksum checks are located in the VT family Policy.

1. Create a reference file with the patterns to check. Following is an example:

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

2. In the row of the respective policy, click .

3. In the section Edit Network Vulnerability Test Families click for the VT family Policy.

   → All VTs that allow special configuration are listed (see Fig. 12.18).

   

   Fig. 12.18 Editing the family of VTs

4. Click for Windows file Checksums.

5. For Delete hash test Programm after the test select the radio button Yes if the checksum program ReHash should be deleted after the check (see Fig. 12.19).

   Tip

   The program can be left on the target system, e.g., to speed up recurring tests and therefore does not have to be transferred each time.

   

   Fig. 12.19 Uploading the reference file

6. For Install hash test Programm on the Target select the radio button Yes if the checksum program ReHash should be installed on the target system automatically.

   Note

   If it is not installed automatically, it has to be installed manually under C:\Windows\system32 (on 32-bit systems) or C:\Windows\SysWOW64 (on 64-bit systems) and has to be executable for the authenticated user.

7. Activate the checkbox Upload file.

   Tip

   If a reference file was already uploaded, the checkbox Replace existing file is displayed instead. The possibility to change the reference file is only available if the policy is currently not used.

8. Click Browse… and select the previously created reference file.

9. Click Save to save the VT.

10. Click Save to save the family of VTs.

11. Click Save to save the policy.

12.4.4 Performing CPE-Based Checks

For detailed information about Common Platform Enumeration (CPE) see Chapter 14.2.2.

12.4.4.1 Simple CPE-Based Checks for Security Policies

With any executed scan, CPEs for the identified products are stored. This happens independently of whether the product actually reveals a security problem or not. On this basis it is possible to describe simple security policies and the checks for compliance with these.

With the Greenbone Enterprise Appliance, it is possible to describe policies to check for the presence as well as for the absence of a product. These cases can be associated with a severity to appear in the scan report.

The examples demonstrate how to check the compliance of a policy regarding specific products in an IT infrastructure and how the reporting with the corresponding severity can be done.

The information about whether a certain product is present on the target system is gathered by a single Vulnerability Test (VT) or even independently by a number of special VTs. This means that for a certain product an optimized policy that only concentrates on this product and does not do any other scan activity can be specified.

12.4.4.2 Detecting the Presence of Problematic Products

This example demonstrates how the presence of a certain product in an IT infrastructure is classified as a severe problem and reported as such.

1. Select Resilience > Compliance Policies in the menu bar.

2. Create a new policy by clicking .

3. Define the name of the policy.

4. Click Save.

   → The policy is created and displayed on the page Policies.

5. In the row of the policy, click .

6. In the row of the VT family Policy, click .

7. In the row of the VT CPE Policy Check, click .

8. Either a single CPE or multiple CPEs can be searched for at the same time.

   Enter a single CPE in the input box Single CPE, e.g., cpe:/a:microsoft:ie:6 (see Fig. 12.20).

   or

   Activate the checkbox Upload file, click Browse… and select a file containing a list of CPEs.

   Note

   The file must be a text file in which the CPEs are separated by commas or line breaks.

9. The problematic product should not be present, i.e., the condition must be set to missing. However, if the product is discovered, this is evaluated as critical.

   Select the radio button missing.

   

   Fig. 12.20 Editing CPE Policy Check

10. Click Save to save the VT.

11. Activate the checkbox Selected for the following VTs: CPE Policy Check, CPE-based Policy Check Error, CPE-based Policy Check OK and CPE-based Policy Check Violations.

12. Click Save to save the family of VTs.

13. Activate the checkbox Selected for the VT family Product Detection (see Fig. 12.21).

    

    Fig. 12.21 Activated VT families

14. Click Save to save the policy.

    Note

    In case the mere availability of a product should be considered, it is required to configure remote access using credentials to apply local security checks (see Chapter 10.3.2). If just running network services should be searched, it normally does not help but rather increases the number of false positives.

15. Create a new target (see Chapter 10.2.1), create a new audit (see Chapter 12.2.1.1) and run the audit (see Chapter 12.2.2).

    When creating the audit, use the previously created policy.

16. When the scan is completed select Scans > Reports in the menu bar.

    Tip

    To show only the results of the CPE-based policy checks, a suitable filter can be applied.

17. Enter cpe in the input box Filter.

    → The reports for CPE-based policy checks are displayed.

18. Click on the date of a report.

    → The report for CPE-based policy checks is displayed.

    The report can be used as described in Chapter 11.2.1.

    Note

    The VTs of the type Violations have a default severity of 10.

    This default severity can be changed using overrides (see Chapter 11.8).

    If the problematic product is found on one of the target systems, it is reported as a problem.

12.5 Checking Standard Policies

12.5.1 IT-Grundschutz

The German Federal Office for Information Security (BSI) publishes the IT-Grundschutz Compendium, which replaced the IT-Grundschutz Catalogs in 2017 and provides useful information for detecting weaknesses and combating attacks on IT environments.

Greenbone provides a policy for testing the compliance with the following modules of the 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

An IT-Grundschutz scan can be carried out as follows:

1. Create a new target (see Chapter 10.2.1), create a new audit (see Chapter 12.2.1.1) and run the audit (see Chapter 12.2.2).

   When creating the audit, use the policy IT-Grundschutz.

2. When the scan is completed select Scans > Reports in the menu bar.

3. Click on the date of the report.

   → The report for the IT-Grundschutz scan is displayed.

   The report can be used as described in Chapter 11.2.1. The report contains detailed information about compliant, not compliant and incomplete requirements.

4. To export the report click .

5. For Include activate the checkbox Notes to include attached notes and the checkbox Overrides to label enabled overrides and include their text field (see Chapter 11.2.2).

6. Select GCR PDF in the drop-down list Report Format.

7. Click OK and download the PDF file.

12.5.2 BSI TR-03116: Kryptographische Vorgaben für Projekte der Bundesregierung

The German Federal Office for Information Security (BSI) published a technical guideline TR-03116: Kryptographische Vorgaben für Projekte der Bundesregierung. Part 4 of this guideline describes the security requirements for services of the federal government using the cryptographic protocols SSL/TLS, S/MIME and OpenPGP.

The requirements are based on forecasts for the security of the algorithms and key lengths for the next years.

Greenbone provides a policy for testing the compliance of services with the technical guideline “TR-03116”.

The policy tests if the scanned hosts and services use SSL/TLS. If this is the case, the compliance with the guideline is tested.

The policy states three main requirements:

TLS version

TLS versions lower than 1.2 are not allowed.

Supported ciphers

If TLS 1.2 is enabled, one of the following ciphers has to be supported:

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

If TLS 1.3 is enabled, cipher TLS_AES_128_GCM_SHA256 has to be supported.

Allowed cipher suites

If TLS 1.2 is enabled, only the following cipher suites are allowed:

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA

If TLS 1.3 is enabled, only the following cipher suites are allowed:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_AES_128_CCM_SHA256

A BSI TR-03116 scan can be carried out as follows:

1. Create a new target (see Chapter 10.2.1), create a new audit (see Chapter 12.2.1.1) and run the audit (see Chapter 12.2.2).

   When creating the audit, use the policy BSI TR-03116: Part 4.

2. When the scan is completed select Scans > Reports in the menu bar.

3. Click on the date of the report.

   → The report for the BSI TR-03116 scan is displayed.

   The report can be used as described in Chapter 11.2.1. The report contains detailed information about compliant, not compliant and incomplete requirements.

4. To export the report click .

5. For Include activate the checkbox Notes to include attached notes and the checkbox Overrides to label enabled overrides and include their text field (see Chapter 11.2.2).

6. Select GCR PDF in the drop-down list Report Format.

7. Click OK and download the PDF file.

12.5.3 BSI TR-02102: Kryptographische Verfahren: Empfehlungen und Schlüssellängen

The German Federal Office for Information Security (BSI) published a technical guideline TR-02102: Kryptographische Verfahren: Empfehlungen und Schlüssellängen. Part 4 of this guideline describes the recommendations for the use of the Secure Shell (SSH) cryptographic protocol.

Greenbone provides a policy for testing the compliance of services with the technical guideline “TR-02102”.

The following SSH settings in the file /etc/ssh/sshd_config are tested in the policy:

• Protocol (OID: 1.3.6.1.4.1.25623.1.0.150066): SSH version 2 has to be used.
• KexAlgorithms (OID: 1.3.6.1.4.1.25623.1.0.150077): the following algorithms are allowed for key exchange during SSH connection establishment: diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha256, diffie-hellman-group15-sha512, diffie-hellman-group16-sha512, rsa2048-sha256, ecdh-sha2-*
• ReKeyLimit (OID: 1.3.6.1.4.1.25623.1.0.150560): the key material of a connection must be renewed after 1 hour or 1 GiB of transferred data.
• Ciphers (OID: 1.3.6.1.4.1.25623.1.0.150225): the following encryption methods are allowed: AEAD_AES_128_GCM, AEAD_AES_256_GCM, aes256-cbc, aes192-cbc, aes128-cbc, aes128-ctr, aes192-ctr, aes256-ctr
• MACs (OID: 1.3.6.1.4.1.25623.1.0.109795): the following MACs are allowed: hmac-sha1, hmac-sha2-256, hmac-sha2-512
• HostKeyAlgorithms (OID: 1.3.6.1.4.1.25623.1.0.150559): the following methods for server authentication are allowed: pgp-sign-rsa, pgp-sign-dss, ecdsa-sha2-, x509v3-rsa2048-sha256, x509v3-ecdsa-sha2-
• AuthenticationMethods (OID: 1.3.6.1.4.1.25623.1.0.150561): the public key authentication (publickey) has to be used.
• PubkeyAuthentication (OID: 1.3.6.1.4.1.25623.1.0.150222): the public key authentication (publickey) has to be allowed.

A BSI TR-02102 scan can be carried out as follows:

1. Create a new target (see Chapter 10.2.1), create a new audit (see Chapter 12.2.1.1) and run the audit (see Chapter 12.2.2).

   When creating the audit, use the policy BSI TR-02102-4.

2. When the scan is completed select Scans > Reports in the menu bar.

3. Click on the date of the report.

   → The report for the BSI TR-02102 scan is displayed.

   The report can be used as described in Chapter 11.2.1. The report contains detailed information about compliant, not compliant and incomplete requirements.

4. To export the report click .

5. For Include activate the checkbox Notes to include attached notes and the checkbox Overrides to label enabled overrides and include their text field (see Chapter 11.2.2).

6. Select GCR PDF in the drop-down list Report Format.

7. Click OK and download the PDF file.

12.6 Running a TLS Map Scan

The TLS (Transport Layer Security) protocol ensures the confidentiality, authenticity and integrity of communication in insecure networks. It establishes confidential communication between sender and receiver, e.g., web server and web browser.

With the Greenbone Enterprise Appliance, it is possible to identify systems that offer services using SSL/TLS protocols. Additionally, the appliance detects the protocol versions and offers encryption algorithms. Further details about the service can be achieved in case it can be properly identified.

12.6.1 Checking for TLS and Exporting the Scan Results

For an overview on TLS usage in the network or on single systems, Greenbone recommends using the scan configuration TLS-Map. This scan configuration identifies the used protocol versions and the offered encryption algorithms. Additionally, it tries to identify in-depth details of the service.

1. Select Configuration > Port Lists in the menu bar to have a look at the pre-configured port lists.

   Note

   By clicking own port lists can be created (see Chapter 10.7.1).

2. Choose a suitable list of ports that should be scanned.

   Note

   Pay attention that all ports of interest are covered by the list.

   The more extensive the list the longer the scan will take but this may also detect services at unusual ports.

   The TLS protocol is mainly based on TCP. A port list with UDP ports will slow down the scan without benefits. If any TCP ports should be covered All TCP should be selected.

3. Create a new target (see Chapter 10.2.1), create a new task (see Chapter 10.2.2) and run the task (see Chapter 10.2.3).

   When creating the task, use the scan configuration TLS-Map.

4. When the scan is completed select Scans > Reports in the menu bar.

5. Click on the date of the report.

   → The report for the TLS-Map scan is displayed.

   The report can be used as described in Chapter 11.2.1.

6. To export the report click .

7. For Include activate the checkbox Notes to include attached notes and the checkbox Overrides to label enabled overrides and include their text field (see Chapter 11.2.2).

8. Select TLS Map in the drop-down list Report Format.

9. Click OK and download the CSV file.

   → The report can be used in spreadsheet applications.

The file contains one line per port and systems where an SSL/TLS protocol is offered:

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

Separated by commas, each line contains the following information:

• IP

  The IP address of the system where the service was detected.

• Host

  The DNS name of the system in case it is available.

• Port

  The port where the service was detected.

• TLS-Version

  The protocol version offered by the service. In case more than one is offered, the versions are separated with semicolons.

• Ciphers

  The encryption algorithms offered by the service. In case more than one is offered, the algorithms are separated with semicolons.

• Application-CPE

  The detected application in CPE format. In case more than one is identified, the applications are separated with semicolons.