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 Security Manager (GSM) can assist IT security professionals to check their IT security safeguards for the standards, frameworks and guidelines mentioned above.

The GSM 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 Networks Support (support@greenbone.net).

12.1 Configuring and Managing Policies

Policies are scan configurations with the flag policy.

All default policies by Greenbone Networks 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 new.

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

    _images/policy_new.png

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

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

    _images/policy_edit.png

    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.

  1. Click edit 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
    _images/policy_edit_nvt_family.png

    Fig. 12.3 Editing a family of VTs

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

  3. Click edit 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.

    _images/policy_edit_nvt.png

    Fig. 12.4 Editing a VT

  1. Click Save to save the VT.
  2. Click Save to save the family of VTs.
  3. Optional: edit scanner preferences (see Chapter 10.9.4).
  4. Optional: edit VT preferences (see Chapter 10.9.5).
  5. 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 upload.

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

    _images/policy_import.png

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

_images/policies_listpage.png

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:

  • trashcan 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 Edit the policy. Only self-created policies which are currently not used can be edited.
  • clone Clone the policy.
  • new Create a new audit for the policy (see Chapter 12.2.1.2).
  • export Export the policy as an XML file.

Note

By clicking trashcan or export 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 details 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:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all policies.
  • new Create a new policy (see Chapter 12.1.1).
  • clone Clone the policy.
  • edit Edit the policy. Only self-created policies which are currently not used can be edited.
  • trashcan 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 Export the policy as an XML file.
  • upload 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 new.

  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 new 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 new 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 new next to the drop-down list.

Add results to Assets
Selecting this option will make the systems available to the asset management of the GSM 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 GSM comes with four pre-configured policies.
Network Source Interface
Here the source interface of the GSM for the scan can be chosen.
Order for target hosts

Select how the specified network area should be searched. Options available are:

  • Sequential
  • Random
  • Reverse

This is interesting if a network, e.g., 192.168.0.0/24, is scanned that has lots of systems at the beginning or end of the IP address range. With the selection of the Random mode the progress view is more meaningful.

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 GSM appliance itself. These values “maxhosts” and “maxchecks” may be tweaked.

_images/audit_new.png

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

    → 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 start.

Note

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

→ The scan is running. For the status of an audit see Chapter 12.2.3.

Note

Scans are only started if there are enough system resources available. The most important resource is random-access memory (RAM). If too many scans are started and running at the same time and not enough RAM is available, scans are added to a waiting queue when clicking start.

When the required RAM is available again, scans from the waiting queue are started, following the principle “first in, first out”.

The number of scans in the waiting queue is limited as well, i.e., scans beyond that are not started at all.

For more information see Chapter 17.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).

_images/audits_listpage.png

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:

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

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

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

view_other The audit is owned by another user.

Status

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

status-new The audit has not been run since it was created.

status-requested The audit was just started. The GSM is preparing the scan.

status-run 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.

status-queued The scan was added to a waiting queue (following the principle “first in, first out”) for one of the following reasons:

  • Too many scans are already running and there is no memory available to start the scan. The scan will be started when the required resources are available again.
  • The GSM is performing a feed update and is currently loading new VTs.
  • The GSM was just started and is currently loading the VTs.

For more information see Chapter 17.3.

status-delete The audit was deleted. The actual deletion process can take some time as reports need to be deleted as well.

status-stopr The audit was requested to stop recently. However, the scan engine has not yet reacted to this request yet.

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

status-resumereq The audit was just resumed. The GSM is preparing the scan.

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

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

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

Note

By clicking trashcan or export 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 details 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:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all audits.
  • new Create a new audit (see Chapter 12.2.1.1).
  • clone Clone the audit.
  • edit Edit the audit.
  • trashcan Move the audit to the trashcan.
  • export Export the audit as an XML file.
  • start Start the audit. Only currently not running audits can be started.
  • stop Stop the currently running audit. All discovered results will be written to the database.
  • resume Resume the stopped audit. All unfinished hosts are scanned completely anew. The data of hosts that were already fully scanned is kept.
  • report Show the last report for the audit or show all reports for the audit.
  • results 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 always has the report format Greenbone Compliance Report PDF (GCR PDF). Changing the report format is not possible.

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 download.
  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 GSM 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.

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

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

    → The cloned policy is displayed on the page Policies.

  3. In the row of the cloned policy click edit.

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

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

    _images/file_content.png

    Fig. 12.9 Editing the family of VTs

  5. Click edit for File Content.

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

    _images/file_content_2.png

    Fig. 12.10 Uploading the reference file

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

  8. Click Save to save the VT.

  9. Click Save to save the family of VTs.

  10. Click Save to save the policy.

12.4.1.2 Changing the Severity

The severities of the VTs depend on the GOS version used. Since GOS 4.2, the VTs of the type Violations have a default severity of 10.

In the past, these VTs had a default severity of 0 (log message) and overrides were required for different severities. The new default severity of 10 can be changed using overrides as well (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).

_images/file_content_overrides.png

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

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

  2. In the row of the policy Microsoft Windows Registry Check click clone.

    → The cloned policy is displayed on the page Policies.

  3. In the row of the cloned policy click edit.

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

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

    _images/windows_registry_check.png

    Fig. 12.12 Editing the family of VTs

  5. Click edit for Windows Registry Check.

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

    _images/windows_registry_check_2.png

    Fig. 12.13 Uploading the reference file

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

  8. Click Save to save the VT.

  9. Click Save to save the family of VTs.

  10. Click Save to save the policy.

12.4.2.2 Changing the Severity

The severities of the VTs depend on the GOS version used. Since GOS 4.2, the VTs of the type Violations have a default severity of 10.

In the past, these VTs had a default severity of 0 (log message) and overrides were required for different severities. The new default severity of 10 can be changed using overrides as well (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).

_images/windows_registry_check_overrides.png

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

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

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

    → The cloned policy is displayed on the page Policies.

  3. In the row of the cloned policy click edit.

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

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

    _images/file_checksum.png

    Fig. 12.15 Editing the family of VTs

  5. Click edit for File Checksums.

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

    _images/file_checksum_2.png

    Fig. 12.16 Uploading the reference file

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

  1. Click Save to save the VT.
  2. Click Save to save the family of VTs.
  3. Click Save to save the policy.

12.4.3.2 Changing the Severity

The severities of the VTs depend on the GOS version used. Since GOS 4.2, the VTs of the type Violations have a default severity of 10.

In the past, these VTs had a default severity of 0 (log message) and overrides were required for different severities. The new default severity of 10 can be changed using overrides as well (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).

_images/file_checksum_overrides.png

Fig. 12.17 Overrides changing the severity

12.4.3.3 Checking File Checksum Patterns for Microsoft Windows

The GSM 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 GSM 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 edit.

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

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

    _images/windows_file_checksum.png

    Fig. 12.18 Editing the family of VTs

  4. Click edit 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.

    _images/windows_file_checksum_2.png

    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 Security Manager 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 new.

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

  6. Unfold the section Network Vulnerability Test Preferences by clicking fold.

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

    _images/scan_config_cpe_based_edit.png

    Fig. 12.20 Overview of VTs

  7. A single CPE (Internet Explorer 6) will be searched.

    Click edit for the VT CPE Policy Check – Single CPE.

    Tip

    This short-cut avoids having to click through the family structures in the section Edit Network Vulnerability Test Families to get to the desired VT (the here used VT is in the VT family Policy).

  8. Enter cpe:/a:microsoft:ie:6 in the input box Single CPE (see Fig. 12.21).

  9. For this example the stated CPEs must be present to comply.

    Select the radio button present.

    _images/scan_config_cpe_based_present.png

    Fig. 12.21 Editing CPE Policy Check – Single CPE

  10. Click Save to save the VT.

  11. Click Save to save the policy.

    Note

    The severities of the VTs depend on the GOS version used. Since GOS 4.2, the VTs of the type Violations have a default severity of 10.

    In the past, these VTs had a default severity of 0 (log message) and overrides were required for different severities. The new default severity of 10 can be changed using overrides as well (see Chapter 11.8).

    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 increase the number of false positives.

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

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

  14. Enter cpe in the input box Filter.

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

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

    In this example: if Internet Explorer 6 was found on one of the target systems it is reported as a problem.

12.4.4.3 Detecting the Absence of Important Products

This example shows how the absence of a certain product in the IT infrastructure is defined and reported as a severe problem.

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

  2. Create a new policy by clicking new.

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

  6. Unfold the section Network Vulnerability Test Preferences by clicking fold.

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

    _images/scan_config_cpe_based_edit.png

    Fig. 12.22 Overview of VTs

  7. A single CPE (Norton Antivirus) will be searched.

    Click edit for the VT CPE Policy Check – Single CPE.

    Tip

    This short-cut avoids having to click through the family structures in the section Edit Network Vulnerability Test Families to get to the desired VT (the here used VT is in the VT family Policy).

  8. Enter cpe:/a:symantec:norton_antivirus in the input box Single CPE (see Fig. 12.23).

  9. For this example the stated CPEs must be missing to comply.

    Select the radio button missing.

    _images/scan_config_cpe_based_missing.png

    Fig. 12.23 Editing CPE Policy Check – Single CPE

  10. Click Save to save the VT.

  11. Click Save to save the policy.

    Note

    The severities of the VTs depend on the GOS version used. Since GOS 4.2, the VTs of the type Violations have a default severity of 10.

    In the past, these VTs had a default severity of 0 (log message) and overrides were required for different severities. The new default severity of 10 can be changed using overrides as well (see Chapter 11.8).

    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 increase the number of false positives.

  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 previously created policy.

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

  3. Enter cpe in the input box Filter.

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

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

    In this example: if Norton Antivirus was not found on one of the target systems it is reported as missing.

12.5 Checking Standard Policies

12.5.1 IT-Grundschutz

The German Federal Office for Information Security (BSI) publishes the IT-Grundschutz catalogs, a collection of documents that provide useful information for detecting weaknesses and combating attacks on IT environments.

Greenbone Networks 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.

    Note

    The policy is provided via the feed.

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

    In case a policy is not available, contact the Greenbone Networks Support (support@greenbone.net).

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

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

    Note

    The policy is provided via the feed.

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

    In case a policy is not available, contact the Greenbone Networks Support (support@greenbone.net).

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

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

    Note

    The policy is provided via the feed.

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

    In case a policy is not available, contact the Greenbone Networks Support (support@greenbone.net).

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

  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 Security Manager (GSM) it is possible to identify systems that offer services using SSL/TLS protocols. Additionally, the GSM 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 Networks 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 new 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.

    Consider that the TLS protocol is based on the TCP protocol. 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.

    Note

    The scan configuration is provided via the feed.

    Scan configurations may not be available yet, but will be added at a later time.

    In case a scan configuration is not available, contact the Greenbone Networks Support (support@greenbone.net).

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

  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.

    Note

    The report format is provided via the feed.

    Report formats may not be available yet, but will be added at a later time.

    In case a report format is not available, contact the Greenbone Networks Support (support@greenbone.net).

  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.