9. Compliance and special scans¶

9.1.1.1. Patterns¶

A reference file with the patterns to check and some other entries must be created. 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

This file must contain the row filename|pattern|presence/absence. The subsequent rows contain each a test entry. Each row contains three elements which are separated by |. The first field contains the path and file name, the second field the pattern to check and the third field indicates if a pattern has to be present or absent.

The pattern to check, the second element in the row, is defined as a regular expression and will be checked in the file accordingly.

Afterwards import this file in the properties of the NVT

Select the file with Browse and select Upload file. The file upload will be started by clicking Save Config.

The mask will change if there is already a file uploaded

By clicking on the icon it is possible to download the already uploaded reference file. Select Replace existing file with: to upload a new reference file. The possibilities to change is only available if the scan configuration is not in use. This is done to ensure immutable audit-compliant scan results.

9.1.1.2. Severity¶

The file content tests report any result per default as log messages. By sectioning the reporting plugins in three different NVT’s it is now possible to create distinct overrides on the severity according your needs.

In the following picture the severities of File Content: Violations and File Content: Errors have been changed which will be shown in the reports accordingly.

9.1.1.3. Example¶

Here (policy_file_content_example.xml) is an example scan configuration with all the relevant NVT’s for the file content test to download. The corresponding test file (filecontent_test) should be downloaded and extracted to the /tmp/ directory on the target system.

Now create an new task and start it for the target system where you saved test files. Please note that this has to be an authenticated scan with the appropriate SSH Credentials.

The overrides can be created either before or after a scan. The latter is easier since you can create the appropriate reference through a simple click in the result page.

9.1.2.1. Registry Content Pattern¶

A file with the reference registry content must be created: 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|DWORD:
    LocalAccountTokenFilterPolicyREG_DWORD|1
FALSE|HKLM|SOFTWARE\Virus
TRUE|HKLM|SOFTWARE\ShouldNotBeHere

This file must contain the row Present|Hive|Key|Value|ValueType|ValueContent. The subsequent rows contain each a test entry. Each row contains a regsitry entry to be checked. Each row contains six elements which are separated by |. The first field sets if 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.

Afterwards import this file in the properties of the NVT.

Select the file with Browse and select Upload file. The file upload will be started by clicking Save Config.

The mask will change if there is already a file uploaded.

By clicking on the icon it is possible to download the already uploaded reference file. Select Replace existing file with: to upload a new reference file. The option to change is only available if the scan configuration is not in use. This is done to ensure immutable audit-compliant scan results.

9.1.2.2. Severity¶

The registry content tests report any result per default as log messages. By sectioning the reporting plugins in three different NVT’s it is now possible to create distinct overrides on the severity according your needs.

In the figure Severity overrides applied for Windows registry checks. the severities of Registry Content: Violations and Registry Content: Errors have been changed which will be shown in the reports accordingly.

Severity overrides applied for Windows registry checks.

9.1.2.3. Example¶

Here (policy_registry_ScanConfig.xml) is an example scan configuration with all relevant NVT’s for the registry test to download. The corresponding testfiles (Registry_test.txt) should be downloaded to the /tmp/ directory on the target system.

Now create a new task and start it for the target system where you saved test files.

The overrides can be created either before or after a scan. The latter is easier since you can create the appropriate reference through a simple click in the result page.

9.1.3.1. Checksum Patterns¶

A file with the reference checksums must be created. Following is an example:

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

This file must first contain the row Checksum|File|Checksumtype. The subsequent rows contain each a test entry. Each row contain three elements 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.

Afterwards import this file in the properties of the NVT.

Select the file with Browse and select Upload file. The file upload will be started by clicking Save Config.

The mask will change if there is already a file uploaded.

By clicking on the icon it is possible to download the already uploaded reference file. Select Replace existing file with: to upload a new reference file. The possibilities to change is only available if the scan configuration is not in use. This is done to ensure immutable audit-compliant scan results.

9.1.3.2. Severity¶

The checksum tests report any result per default as log messages. By sectioning the reporting plugins in three different NVT’s it is now possible to create distinct overrides on the severity according your needs.

In the figure Severity overrides applied for file checksum checks. the severities of File Checksum: Violations and File Checksum: Errors have been changed which will be shown in the reports accordingly.

Severity overrides applied for file checksum checks.

9.1.3.3. Example¶

Here (policy_file_checksums_example.xml) is an example scan configuration with all relevant NVT’s for the checksum test to download. The corresponding testfiles (policy_file_checksums_testfiles) should be downloaded and extracted to the /tmp/ directory on the target system. This can be done e.g. by tar xvC /tmp/ testfiles_checksum_check.tar.gz.

Now create a new task and start it for the target system where you saved test files. Please note that this has to be an authenticated scan with the appropriate SSH Credentials.

The overrides can be created either before or after a scan. The latter is easier since you can create the appropriate reference through a simple click in the result page.

9.1.3.4. Windows¶

GSM provides a similar module for Windows systems for checksum checks. Since Windows doesn’t provide an internal program for creating checksums it has to be installed one either manually or automatically by the NVT. GSM uses ReHash (http://rehash.sourceforge.net/) for creating checksums on Windows systems.

As for Linux systems the NVT’s for checksum checks are located under the Policy family.

Four NVT’s are responsible for the checksum checks under Windows

The preferences must be set then in the „Windows file Checksums“ NVT.

Please note the two operating modes for these checks: Either a before manually on the target system installed tool will be used or the tool ReHash will automatically be installed and if requested as well deinstalled on the target system during the checking routine.

Through the preferences it can be set if the checksum program ReHash should be deleted after the check or not. The program can be left on the target system to e.g. speed up recurring tests and therefore don’t have to be transfered each time. It can further be set if the checksum program should be installed automatically on the target system. If not it has to be manually installed (under C:\Windows\system32 on 32-bit system) or C:\Windows\SysWOW64 (on 64-bit systems)) and has to be executable for the authenticated user. The file with the reference checksums must be uploaded in the preferences as it is done for the Linux checksum check. The file has the same structure as the one for Linux.

9.1.3.5. Example Windows¶

A sample configuration (sample_config-Windows_file_Policy.xml ) with all needed NVT’s for the Windows checksum check can be downloaded here. The corresponding example files (windows_checksums_testfiles.zip) can be downloaded and must be saved on the target system.

For Tasks and Overrides please proceed as described above.

9.1.4.1. CPE-based, simple 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.

9.1.4.2. Checking policy compliance¶

This example demonstrates how to check the compliance of a policy regarding specific products in a IT infrastructure and how the reporting with the corresponding severity can be done.

1. The information about whether a certain product is present on the target system is gathered by a single Network Vulnerability Test (NVT) or even independently by a number of special NVTs. This means that for a certain product you can specify an optimized scan configuration that only concentrates on this product and does not do any other scan activity. The advantage of such a special scan configuration is a considerably faster execution of the scan compared to a comprehensive scan configuration such as Full and Fast. The disadvantage of a special scan configuration is that some experience is required to select the right set of NVTs to maximize the probability of success. Initially it is easier to apply a comprehensive scan configuration. In this case it is not necessary to care about the product character, you just enter its CPE identifier. This example follows the simple approach. First, a copy of Full and Fast is created. This is necessary because Full and Fast is a pre-configured scan configuration and thus can not be modified.

2. Edit the newly created scan configuration by clicking on .

3. On the overview page for this scan configuration you will find a section Network Vulnerability Test Preferences. Here, all NVTs that allow special configuration are listed. With you can jump directly to the edit dialog for a specific NVT. This short-cut avoids having to click through the family structures to get to the desired NVT (the here used NVTs are in the family Policy).

4. You can either specify a single CPE directly or a list of CPEs in a file which must be imported afterwards (through clicking on Browse to select the file and selecting Upload file). Below is an example for checking for Internet Explorer 9 and ClamAV 0.98:

cpe:/a:microsoft:ie:9
cpe:/a:clamav:clamav:0.98

For this example we have a policy where the stated CPEs must be present to comply. This means we want to know especially if there are some installations which violate this policy (e.g. missing or not wrong products/versions).

Confirm your changes with Save Config.

5. Policy checks report the results in general as “Log” messages. If you want to change this you have to create an override. In this example violations of the policy should be reported with an elevated severity.

   For this a new override has to be created through the Scan Management. The OID in this case will be “1.3.6.1.4.1.25623.1.0.103964” (for the NVT CPE-based Policy Check Violations) and a new severity of 5.0 (Medium) will be set.

6. In case the detection efficiency should be increased by applying local security checks it is required to configure remote access via the Credentials feature. If not done yet, create a corresponding user account on the Windows systems (a low privileged user account is sufficient).

7. Define the target systems (targets) and, if applicable, choose the respective credentials.

8. Now you can create the actual task. This means to combine the newly created scan configuration with the newly created targets.

9. The scan is started by clicking on of the respective task. It can take a while for the scan to complete. To update the view with the current progress, click on .

10. As soon as the status changes to Done the complete report is available. At any time you can review the intermediate results. To only show the results of the CPE-based policy checks, you can apply a suitable filter (search text “cpe”).
11. In this example ClamAV 0.98 was found on one of the target systems and reported as a log message.

Internet Explorer 9 on the other hand haven’t been found on the target system which will be reported as a medium risk as defined in the override.

9.1.4.3. Finding 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. Execute steps 1 to 3 of the above described method for finding checking policy compliance.

   Note that when choosing a general scan like Full and Fast both cases are treated the same, presence of the product as a running service and presence of the product on a hard drive.

   This essentially means that if you want to ensure the desired product indeed runs as a service you should avoid running NVTs that check for the simple presence on the file system or in a registry. If you don’t want to go into such details right now, you still have the option to look into the report details in order to check for false positives and false negatives.

2. This time a single CPE (Internet Explorer 6) will be searched.

   In this case we have to set that the entered CPE must be “present”.

   Confirm your changes with Save Config.

3. Policy checks report the results in general as “Log” messages. If you want to change this you have to create an override. In this example violations of the policy should be reported with an elevated severity.

   For this, a new override has to be created through the Scan Management. The OID in this case will be “1.3.6.1.4.1.25623.1.0.103963” (for the NVT CPE-based Policy Check OK) and a new severity of 10.0 (High) will be set.

4. In case the pure presence of a product should be considered, you should apply local security checks by configuring remote access via the Credentials feature. Execute step 6 to 9 in the example above to enable local security checks, to create a new task with the target systems and to start it.

5. As soon as the status changes to Done the complete report is available. At any time you can review the intermediate results.

   To only show the results of the CPE-based policy checks, you can apply a suitable filter (search text “cpe”).

6. In this example Internet Explorer 6 was found on one of the target systems and reported as a severe problem as defined in the override.

9.1.4.4. Detecting absence of important products¶

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

1. Execute steps 1 to 3 of the above described method for finding problematic products.

   Note that when choosing a general scan like Full and Fast both cases are treated the same, presence of the product as a running service and presence of the product on a hard drive.

   This essentially means that if you want to ensure the desired product indeed runs as a service you should avoid running NVTs that check for the simple presence on the file system or in a registry. If you don’t want to go into such details right now, you still have the option to look into the report details in order to check for false positives and false negatives.

2. This time the configuration of CPE-based Policy Check will be set up to check if Norton Antivirus is present on the target system. In this case it will be reported if it is “missing”.

3. Policy checks report the results in general as “Log” messages. If you want to change this you have to create an override. In this example violations of the policy should be reported with an elevated severity.

   For this, a new override has to be created through the Scan Management. The OID in this case will be “1.3.6.1.4.1.25623.1.0.103963” (for the NVT CPE-based Policy Check OK) and a new severity of 10.0 (High) will be set.

4. For checking simply the availability of a product installation, local security checks can improve the detection rate. If just running network services should be searched it normally doesn’t help but rather increase the number of false positives.

   Execute step 6 to 9 in the example Checking policy compliance to enable local security checks, to create a new task with the target systems and to start it.

5. As soon as the status changes to Done the complete report is available. At any time you can review the intermediate results.

   To only show the results of the CPE-based policy checks, you can apply a suitable filter (search text “cpe”).

6. In this example Norton Antivirus was not found on one of the target systems.

9.2.1.1. Checking IT-Grundschutz¶

This example executes a simple check according to the German “IT-Grundschutz-Kataloge”.

1. Import the scan configuration IT-Grundschutz Scan For verinice integration: IT-Grundschutz Scan incl. Discovery for verinice

This covers the settings to execute all of the checks. The actual checks are not explicitly selected so that rather a summary result is generated.

2. The majority of checks for the measures is based on local security checks. For these a respective access needs to be configured. If not done yet, create a corresponding user account on the Windows systems (the higher the privileges of this user account, the more measures can be checked).

3. Define the target systems (targets) and, if applicable, choose the respective credentials.

4. Now you can create the actual task. This means to combine the imported scan configuration with the newly created targets.

5. The search is started by clicking on of the respective task. It can take a while for the scan to complete. To update the view with the current progress, click on .

6. As soon as the status changes to “Done” the complete report is available. At any time you can review the intermediate results. Please note, that for the textual form of the reports you need to enable category “Low” in the filter.

   With the imported scan configuration 2 versions of the results will be created: an overview in textual form (under “general/IT-Grundschutz”) and a table for further processing (under “general/IT-Grundschutz-T”). For the latter, you need to enable category “Log” in the report filter

9.2.1.2. Import of results into a spreadsheet application¶

1. Choose download format “ITG” either in the report filter or in the task overview. Note: Using the report filter it is necessary to enable the category “Log”.

For this download format suitable tabular results for all target systems are automatically collected and joined.

2. Import the ITG file as so called CSV table into your spreadsheet application.

The example above shows an import for OpenOffice 3.2. Please take care that the following settings are adjusted for the import (if not already default):

• Charset: UTF-8
• Field separator: The “pipe” symbol (vertical line)
• Text separator: The double quote
• Last column: Type “Text”

3. Now the scan results are available in the spreadsheet application:

4. From this point you can create simple (like in the screenshot below) or, of course, your individual comprehensive analysis or report.

9.2.1.3. Import of results into IT-Grundschutz tools¶

A number of tools is available to help IT-Grundschutz processes with structured approach, data entries and management.

The German federal agency for IT security (Bundesamt für Sicherheit in der Informationstechnik, BSI) offers on its website an overview on IT-Grundschutz tools.

For an import of the results of a IT-Grundschutz scan into one of these tools please contact the vendor of the corresponding tool. For additional questions please don’t hesitate to contact the Greenbone Support.

9.2.1.4. Result classes of IT-Grundschutz checks¶

The following result classes can occur for a check:

• Not fulfilled (FAIL):

  It was detected that the target system does not fulfill the measure.

• Fulfilled (OK):

  It was detected that the target system does fulfill the measure.

• Error (ERR):

  It was not possible to execute the test routine properly. For example, some checks require credentials. If the credentials are missing, the check can not be executed for technical reasons. In case no credentials are provided many of the checks will have this status.

• Check of this measure is not available (NI):

  In general it is assumed this measure can be automatically checked for, but an implementation is not yet available. For newly released “Ergänzungslieferungen” this is initially true for a number of measures. However, the Greenbone Security Feed is updated continuously, and eventually all measures will be implemented.

• Check of the measure is not implemented (NA):

  A number of measures of the “IT-Grundschutzkataloge” are kept too general to create an explicit automatic check. Other measures describe checks that can only be done physically and thus also belong to this class of test that can’t be implemented at all.

• Check not suited for the target system (NS):

  Some measures refer exclusively to a special type of operating system. If the target system runs another operating system type, the measure does not apply and the result class is set to NS.

• This measure is deprecated (DEP):

  Some updates (“Ergänzungslieferungen”) removed some measures without a replacement. Old IDs of such deprecated measures are never re-used. So, the results marked as DEP can be safely ignored but the entries remain for completeness.

9.2.1.5. Supported measures¶

This overview refers to the current Ergänzungslieferung. The measure ID’s link to the corresponding detailed information available on the website of BSI.

The following test types are distinguished:

• Remote: For the check it is only necessary to have network connection to the target system.
• Credentials: For the check is is required to use a account on the target system.

9.2.2.1. Payment Card Industry Data Security Standard¶

The PCI DSS is a security standard for payment card transactions and is supported by the major payment systems MasterCard, Visa, AMEX, Discover and JCB.

All organizations that process card payments, store or transfer card data are required to perform compliance validation according to PCI DSS. Non-compliance or lack of validation means the risk of being fined or, ultimately, losing the ability to process payment cards.

The validation of compliance depends on the volume of card transactions. Here, service providers are usually classified as Level 1 Service Provider and they must, on a quarterly basis, validate their cardholder data environment by an independent scanning vendor approved by the PCI Security Standards Council (PCI SSC). In addition, an annual on-site PCI Security Audit has to be performed by an independent Qualified Security Assessor (QSA), also approved by the PCI SSC.

The “Approved Scanning Vendor” (ASV) is a service provider who performs a vulnerability scan of the cardholder data environment visible to the internet. As such the vulnerability scanners themselves can not be classified or certified as ASVs. However, they are tools for the ASV to perform the vulnerability scan using the approved process.

9.2.2.2. Greenbone Security Manager and PCI DSS¶

According to PCI DSS (Version 3.1, Requirement 11.2) two types of vulnerability scans are to be perfomred on a quarterly basis and after significant changes to the cardholder data environment. This includes the vulnerability scan conducted by the ASV explained above and an internal scan of the cardholder data environment. The latter scan may be performed by employees of the organization and requires no approval by the PCI SSC.

The Greenbone Security Manager (GSM) can perform both of these scans. The false positive management features help avoid significant work load of manual elimination of wrong alerts.

A merchant can use the GSM to check the security requirements prior to the ASV vulnerability scan in order to avoid costly re-scans.

This way, a merchant can use the GSM to check for PCI compliance on an ongoing basis even between the scans performed by the ASV.

Since security changes are stored immutable for audit compliance within the GSM, the correct security and compliance status can even be verified at all times in between the quarterly ASV scans.

Escalation methods can inform an external auditor as well as internal experts continuously about the security status. Summaries are sent to the responsible parties.

9.2.2.3. Policy Monitoring¶

In the same way the GSM checks the technical aspects of other policies periodically it can also check the system parameters according to the PCI DSS policy.

With a permanent background policy scan it is ensured that antivirus tools are not outdated or firewalls don’t get deactivated without notice. Such parameters can be monitored and escalated in the same way as software vulnerabilities.

Advantages for merchant:

• Permanent policy monitoring
• Flexible escalation
• “False Positive” management
• Internal and external vulnerability scanning
• Complete vulnerability analysis according to PCI DSS for internal scans

Advantages for the ASV:

• “False Positive” Management
• Static scan configuration for re-scans
• Complete vulnerability analysis according to PCI DSS for external scans via internet
• Flexible reporting framework for individual scan reports

Greenbone Networks GmbH as the vendor of the GSM does not act as an ASV. But among Greenbone’s business partners you will find security consultants that as an ASV at the same time and can introduce the GSM into your security process.