Compliance and special scans ============================ Compliance in the IT security world is the primary approach for organizations to keep their information and assets protected and secure. With cybercrime on the rise, governments see the need to protect their citizens and pass rules and regulations on privacy and IT security in the hopes to protect our identities and assets. 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 such as the Control Objectives for Information and Related Technology (COBIT) or the ISO 27000 series which cover information security standards. The German Federal Office for Security in Information Technology (BSI), for example, publishes the IT Baseline Protection Catalogs, or IT-Grundschutz-Kataloge. This is a collection of documents that provide useful information for detecting weaknesses and combating attacks on IT environments. To better protect against credit card data theft the Payment Card Industry Security Standards Council publishes the payment Card Industry Data Security Standard (PCI DSS). All these privacy laws, standards, frameworks, rules and regulations are to force and assist organizations to implement the appropriate safeguards to protect themselves and their information assets from attacks. In order to implement these laws, standards, frameworks, rules and regulations within an organization the organization will have to create an IT security framework consisting of policies, standards, baselines, guidelines and detailed procedures. Security scanners such as the Greenbone Security Manager (GSM) can assist IT security professionals to check their IT security safeguards against the aforementioned regulations, standards and frameworks for compliance. In the following sections we will describe how the GSM can be utilized to perform certain compliance checks. Generic Policy Scans -------------------- When performing policy scans there are several groups each with four NVTs that can be configured accordingly. In the policy section of the NVTs database at least two of these four policy NVTs are required to run a policy scan. The four NVT types are: * :gos:pref:`Base` This NVT performs the actual scan/function of the actual policy scan. * :gos:pref:`Matches` This NVT summarizes any items which match the checks performed by the base NVT. * :gos:pref:`Violations` This NVT summarizes any items which did not match the checks performed by the base NVT. * :gos:pref:`Errors` This NVT sumarizes any items where some error occurred when running the policy scan. The base NVT must be selected for a policy check since it performs the actual tests. The other three plugins may be selected according to your needs. For example, if matching patterns are of no concern then only the violations plugin should be selected additionally. File Content ^^^^^^^^^^^^ File content checks belong to policy audits which don't explicitly test for vulnerabilities but rather test the compliance of file contents (e.g. configuration files) regarding a given policy. GSM provides a policy module to check if a file content is compliant with a given policy. 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 content check can only be performed on systems supporting the command :gos:cmd:`grep`. Normally this means Linux or Linux-like systems. .. figure:: images-3.1/filecontent_families.png :align: center The NVT's are in the „Policy“ family Four different NVT's provide the file content check: * :gos:pref:`File Content`: This NVT performs the actual file content check. * :gos:pref:`File Content: Matches`: This NVT shows the patterns and files which passed the file content check (the predefined pattern matches in the file) * :gos:pref:`File Content: Violations`: This NVT shows the patterns and files which didn't pass the file content check (the predefined pattern doesn't match in the file) * :gos:pref:`File Content: Errors`: This NVT shows the files where some error occurred (e.g. the file is not found on the target system) The NVT :gos:webui:`File Content` must be selected for a file content check since it performs the actual tests. The other three plugins may be selected according to your needs. E.g. if just not matching patterns are of concern then only the plugin :gos:pref:`File Content: Violations` should be additionally selected. 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 :gos:setting:`filename|pattern|presence/absence`. The subsequent rows contain each a test entry. Each row contains three elements which are separated by :gos:var:`|`. 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. .. figure:: images-3.1/filecheck_content.png :align: center Afterwards import this file in the properties of the NVT Select the file with :gos:webui:`Browse` and select :gos:webui:`Upload file`. The file upload will be started by clicking :gos:webui:`Save Config`. .. figure:: images-3.1/filecheck_content_edit.png :align: center The mask will change if there is already a file uploaded By clicking on the |download| icon it is possible to download the already uploaded reference file. Select :gos:webui:`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. 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 :gos:pref:`File Content: Violations` and :gos:pref:`File Content: Errors` have been changed which will be shown in the reports accordingly. .. figure:: images-3.1/filecheck_content_overrides.png :align: center 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. Registry Content ^^^^^^^^^^^^^^^^ The registry is a database in Windows that contains important information about system hardware, installed programs and settings, and profiles of each of the user accounts on your computer. Windows continually refers to the information in the registry [#REG]_. Due to the nature of the Windows registry every program/application installed under windows will register itself in the Windows registry and as such has a registry entry. Even malware and other malicious code usually leaves traces within the windows registry. The registry now can be utilized to search for specific application 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. GSM provides a policy auditing 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 Windows systems this check can only be run on Windows systems. To access the registry on the target system the check needs to authenticate on the target system. .. figure:: images-3.1/policy_file_checksums_families.png :align: center The NVT's are in the „Policy“ family. Four different NVT's provide the registry content check: * :gos:pref:`Windows Registry Check`: This NVT performs the actual registry content check on the files. * :gos:pref:`Windows Registry Check: OK`: This NVT shows the registry setting which passed the registry check (registry content OK). * :gos:pref:`Windows Registry Check: Violations`: This NVT shows the registry content which didn't pass the registry check (wrong registry content). * :gos:pref:`Windows Registry Check: Errors`: This NVT shows the registry entries where some error occurred (e.g. registry content not found on the target system). The plugin :gos:webui:`Windows Registry Check` must be selected for a registry check since it performs the actual tests. The other three plugins may be selected according to the needs. E.g. just entries with wrong regsitry content are of concern then only the plugin :gos:webui:`Windows Registry Check: Violations` should be additionally selected. 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 :gos:setting:`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 :gos:var:`|`. 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. .. figure:: images-3.1/policy_registry_content_family.png :align: center Afterwards import this file in the properties of the NVT. Select the file with :gos:webui:`Browse` and select :gos:webui:`Upload file`. The file upload will be started by clicking :gos:webui:`Save Config`. .. figure:: images-3.1/policy_registry_content_edit.png :align: center The mask will change if there is already a file uploaded. By clicking on the |download| icon it is possible to download the already uploaded reference file. Select :gos:webui:`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. 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 :ref:`fig:severity_registry` the severities of :gos:pref:`Registry Content: Violations` and :gos:pref:`Registry Content: Errors` have been changed which will be shown in the reports accordingly. .. _fig:severity_registry: .. figure:: images-3.1/Severity_Darstellung_Registry_Content_scan_en.png :align: center Severity overrides applied for Windows registry checks. 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 :gos:pref:`/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. .. _compliance_file_checksums: File Checksums ^^^^^^^^^^^^^^ File checksum checks belong to policy audits which don't explicitly test for vulnerabilities but rather test the integrity of files. GSM provides a policy auditing 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. GSM provides however as well a module for checksum checks for Windows systems (see :ref:`windows_checksums`). .. figure:: images-3.1/policy_file_checksums_families.png :align: center The NVT's are in the „Policy“ family. Four different NVT's provide the file checksum check: * :gos:pref:`File Checksums`: This NVT performs the actual checksum check on the files. * :gos:pref:`File Checksums: Matches`: This NVT shows the files which passed the checksum check (checksum matches). * :gos:pref:`File Checksums: Violations`: This NVT shows the files which didn't pass the checksum check (wrong checksum). * :gos:pref:`File Checksums: Errors`: This NVT shows the files where some error occurred (e.g. file not found on the target system). The plugin :gos:webui:`File Checksums` must be selected for a file checksum check since it performs the actual tests. The other three plugins may be selected according to the needs. E.g. just files with wrong checksums are of concern then only the plugin :gos:webui:`File Checksums: Violations` should be additionally selected. 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 :gos:setting:`Checksum|File|Checksumtype`. The subsequent rows contain each a test entry. Each row contain three elements which are separated by :gos:var:`|`. 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. .. note:: Checksums and checksum type must be lowercase. .. figure:: images-3.1/policy_file_checksums_family.png :align: center Afterwards import this file in the properties of the NVT. Select the file with :gos:webui:`Browse` and select :gos:webui:`Upload file`. The file upload will be started by clicking :gos:webui:`Save Config`. .. figure:: images-3.1/policy_file_checksums_edit.png :align: center The mask will change if there is already a file uploaded. By clicking on the |download| icon it is possible to download the already uploaded reference file. Select :gos:webui:`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. 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 :ref:`fig:severity_file_checksums` the severities of :gos:webui:`File Checksum: Violations` and :gos:webui:`File Checksum: Errors` have been changed which will be shown in the reports accordingly. .. _fig:severity_file_checksums: .. figure:: images-3.1/policy_file_checksums_overrides.png :align: center Severity overrides applied for file checksum checks. 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 :gos:pref:`/tmp/` directory on the target system. This can be done e.g. by :gos:cmd:`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. .. _windows_checksums: 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 :gos:webui:`Policy` family. .. figure:: images-3.1/policy_file_checksums_nvt_win.png :align: center Four NVT's are responsible for the checksum checks under Windows .. figure:: images-3.1/policy_file_checksums_pref_win.png :align: center 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 :gos:pref:`C:\\Windows\\system32` on 32-bit system) or :gos:pref:`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. 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. CPE-based ^^^^^^^^^ CPE stands for `Common Product Enumeration `_. It is a structured naming scheme for information technology systems, platforms, and packages. In other words: CPE provides a unique identifier for virtually any software product that is known for a vulnerability. The CPE dictionary is maintained by `U.S. National Institute for Standards and Technology (NIST) `_ and was developed by the `MITRE Corporation (MITRE) `_ and NIST. Close to the end of 2014 MITRE announced that all intellectual property associated with CPE has been transferred to NIST. MITRE still maintains CVE (Common Vulnerability Enumeration) and other relevant security standards. .. figure:: images/cpe_name_structure.png :align: center 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. .. _checking_compliance: 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 :gos:webui:`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 :gos:webui:`Full and Fast` is created. This is necessary because :gos:webui:`Full and Fast` is a pre-configured scan configuration and thus can not be modified. .. figure:: images-3.1/cpe_policy_new_scanconfig.png :align: center 2. Edit the newly created scan configuration by clicking on |edit|. .. figure:: images-3.1/cpe_policy_edit_scanconfig.png :align: center 3. On the overview page for this scan configuration you will find a section :gos:webui:`Network Vulnerability Test Preferences`. Here, all NVTs that allow special configuration are listed. With |edit| 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 :gos:webui:`Policy`). .. figure:: images-3.1/cpe_policy_edit_cpepolicy.png :align: center 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 :gos:webui:`Browse` to select the file and selecting :gos:webui:`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 :gos:webui:`Save Config`. .. figure:: images-3.1/cpe_policy_setcpepolicy1.png :align: center 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 :gos:webui:`Scan Management`. The OID in this case will be "1.3.6.1.4.1.25623.1.0.103964" (for the NVT :gos:webui:`CPE-based Policy Check Violations`) and a new severity of 5.0 (Medium) will be set. .. figure:: images-3.1/cpe_policy_override.png :align: center 6. In case the detection efficiency should be increased by applying local security checks it is required to configure remote access via the :gos:webui:`Credentials` feature. If not done yet, create a corresponding user account on the Windows systems (a low privileged user account is sufficient). .. figure:: images-3.1/cpe_policy_newcredential.png :align: center :width: 12cm 7. Define the target systems (targets) and, if applicable, choose the respective credentials. .. figure:: images-3.1/cpe_policy_newtarget.png :align: center :width: 12cm 8. Now you can create the actual task. This means to combine the newly created scan configuration with the newly created targets. .. figure:: images-3.1/cpe_policy_newtask.png :align: center :width: 12cm 9. The scan is started by clicking on |start| of the respective task. It can take a while for the scan to complete. To update the view with the current progress, click on |refresh|. .. figure:: images-3.1/cpe_policy_reportlist.png :align: center 10. As soon as the status changes to :gos:webui:`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. .. figure:: images-3.1/cpe_policy_report_log.png :align: center 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. .. figure:: images-3.1/cpe_policy_report_medium.png :align: center 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 :gos:webui:`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 :gos:webui:`Save Config`. .. figure:: images-3.1/cpe_policy_setcpepolicy2.png :align: center 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 :gos:webui:`Scan Management`. The OID in this case will be "1.3.6.1.4.1.25623.1.0.103963" (for the NVT :gos:webui:`CPE-based Policy Check OK`) and a new severity of 10.0 (High) will be set. .. figure:: images-3.1/cpe_policy_override_high.png :align: center 4. In case the pure presence of a product should be considered, you should apply local security checks by configuring remote access via the :gos:webui:`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 :gos:webui:`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"). .. figure:: images-3.1/cpe_policy_resultfilter.png :align: center 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. .. figure:: images-3.1/cpe_policy_report_high.png :align: center 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 :gos:webui:`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 :gos:webui:`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". .. figure:: images-3.1/cpe_policy_setcpepolicy3.png :align: center 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 :gos:webui:`Scan Management`. The OID in this case will be "1.3.6.1.4.1.25623.1.0.103963" (for the NVT :gos:webui:`CPE-based Policy Check OK`) and a new severity of 10.0 (High) will be set. .. figure:: images-3.1/cpe_policy_override_high_missing.png :align: center 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 :ref:`checking_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 :gos:webui:`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"). .. figure:: images-3.1/cpe_policy_resultfilter.png :align: center 6. In this example Norton Antivirus was not found on one of the target systems. .. figure:: images-3.1/cpe_policy_missing_report.png :align: center Standard Policies ----------------- IT-Grundschutz ^^^^^^^^^^^^^^ With the Greenbone Security Manager it is possible to automatically check the German "IT-Grundschutz-Kataloge" as published and maintained by the `Bundesamt für Sicherheit in der Informationstechnik `_ (German Federal Office for IT Security, BSI). Supported is always the current "Ergänzungslieferung" with tests for over 80 measures. That is the maximum number of measures which is possible to support with automatic tests. Some measures are quite comprehensive so that and actually consist of several single tests. A couple of measures address a specific operating system ans hence will only be applied to those. The number and type of tested systems remains irrelevant for the Greenbone Security Manager. This makes the Greenbone Security Manager the fastest co-worker for executing a IT-Grundschutz audit. And it opens the opportunity to install a check for breaches as a permanent background process. 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 `_ .. figure:: images-3.1/itgrundschutz_importscanconfig.png :align: center 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. .. figure:: images-3.1/itgrundschutz_scanconfig.png :align: center 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). .. figure:: images-3.1/new_credential.png :align: center 3. Define the target systems (targets) and, if applicable, choose the respective credentials. .. figure:: images-3.1/itgrundschutz_newtarget.png :align: center 4. Now you can create the actual task. This means to combine the imported scan configuration with the newly created targets. .. figure:: images-3.1/itgrundschutz_newtask.png :align: center 5. The search is started by clicking on |start| of the respective task. It can take a while for the scan to complete. To update the view with the current progress, click on |refresh|. .. figure:: images-3.1/itgrundschutz_reportlist.png :align: center 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 .. figure:: images-3.1/itgrundschutz_report.png :align: center .. figure:: images-3.1/itgrundschutz_report-t.png :align: center 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". .. figure:: images-3.1/itgrundschutz_download.png :align: center 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. .. figure:: images-3.1/itgrundschutz_officeimport.png :align: center 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: .. figure:: images-3.1/itgrundschutz_officeimport.png :align: center 4. From this point you can create simple (like in the screenshot below) or, of course, your individual comprehensive analysis or report. .. figure:: images-3.1/itgrundschutz_openoffice_pie.png :align: center 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. 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. 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. .. tabularcolumns:: |l|p{5cm}|l|p{5cm}| =================================================================================================================== ======================================================================================== =========== =============================================================================================================================================================================================================== BSI reference Title Test type Note =================================================================================================================== ======================================================================================== =========== =============================================================================================================================================================================================================== `M4.2 `_ Screen lock Credentials Windows: Can only test for local accounts. Linux: Only default screen savers in Gnome and KDE. `M4.3 `_ Use of anti virus protection software Credentials `M4.4 `_ Compliant handling of drives for removable media and external data storage devices Credentials `M4.5 `_ Logging of telecommunication equipment Credentials `M4.7 `_ Changing of default passwords Remote Test only via SSH and Telnet. `M4.9 `_ Use of the seccurity mechanisms of XWindows Credentials `M4.14 `_ Mandatory password protection in Unix Credentials `M4.15 `_ Secure login Credentials `M4.16 `_ Access restrictions of user IDs and / or terminals Credentials `M4.17 `_ Locking and deleting unneeded accounts and terminals Credentials `M4.18 `_ Administrative and technical securing of access to monitoring and single-user mode Credentials `M4.19 `_ Restrictive allocation of attributes for UNIX system files and directories Credentials `M4.20 `_ Restrictive allocation of attributes for UNIX user files and directories Credentials `M4.21 `_ Preventing of unauthorized escalation of administrator rights Credentials `M4.22 `_ Preventing of loss of confidentiality of sensitive data in the UNIX system Credentials `M4.23 `_ Safe access of executable files Credentials `M4.33 `_ Use of a virus scanning program for storage media exchange and data transfer Credentials `M4.36 `_ Disabling of certain fax receiving phone numbers Credentials Cisco devices can only be tested via telnet because they do not support blowfish-cbc encryption. `M4.37 `_ Disabling of cetrain fax sending phone numbers Credentials Cisco devices can only be tested via telnet because they do not support blowfish-cbc encryption. `M4.40 `_ Preventing the unauthorized use of the computer microphone Credentials Only implemented for Linux. Under Windows it is not possible to determine the status of the microphone via registry/WMI. `M4.48 `_ Password protection if Windows systems Credentials `M4.49 `_ Securing of the the boot process of Windows systems Credentials `M4.52 `_ Equipment protection under Windows NT-based systems Credentials `M4.57 `_ Deactivation of automatic CD-ROM recognition Credentials `M4.80 `_ Sichere Zugriffsmechanismen bei Fernadministration Remote `M4.94 `_ Protection of web server files Remote `M4.96 `_ Disabling of DNS Credentials `M4.97 `_ One service per server Remote `M4.98 `_ Limit communication though a packet filter to a minimum Credentials Microsoft Windows Firewall is being tested. For Vista and newer any firewall that is installed comforming to the system. `M4.106 `_ Activation of system wide logging Credentials `M4.135 `_ Restrictive assigning of access rights to system files Credentials `M4.147 `_ Secure use of EFS under Windows Credentials `M4.200 `_ Use of USB storage media Credentials `M4.227 `_ Use of a local NTP server for time synchronization Credentials `M4.238 `_ Use of a local packet filter Credentials Microsoft Windows Firewall is being tested. For Vista and newer any firewall that is installed comforming to the system. `M4.244 `_ Secure system configuration of Windows client operating systems Credentials `M4.277 `_ Securing of the SMB, LDAP and RCP communication of Windows servers Credentials `M4.284 `_ Handling of services of Windows Server 2003 Credentials `M4.285 `_ Uninstallation of unneeded client services of Windows Server 2003 Credentials `M4.287 `_ Secure administration of VoIP middleware Remote `M4.300 `_ Information protection of printers, copies and multi-function equipment Remote `M4.305 `_ Use of storage quotas Credentials `M4.310 `_ Implementaion of LDAP access to file services Remote `M4.313 `_ Providing of secure domain controllers Credentials `M4.325 `_ Deletion of swap files Credentials `M4.326 `_ Providing the NTFS properties on a Samba file server Credentials `M4.328 `_ Secure base configuration of a Samba server Credentials `M4.331 `_ Secure configuration of the operating system for a samba server Credentials `M4.332 `_ Secure configuration of access controls of a samber server Credentials `M4.333 `_ Secure configuration of Winbind under Samba Credentials `M4.334 `_ SMB message signing and Samba Credentials `M4.338 `_ Use of Windows Vista and new file and registry virtulization Credentials Only a general test if file and registry virtulization is enabled. `M4.339 `_ Avoidance of unauthorized use of portable media under Windows Vista and later Credentials `M4.340 `_ Use of the Windows user account control UAC starting with Windows Vista Credentials `M4.341 `_ Integrity protection starting with Windows Vista Credentials Where possible technically implemented (active UAC and protected mode in different zones). `M4.342 `_ Activation of last access certificate stamp starting with Windows Vista Credentials `M4.344 `_ Monitoring of Windows Vista-, Windows 7 und Windows Server 2008-Systemen Credentials `M4.368 `_ Regular audits of the terminal server environemnt Credentials `M5.8 `_ Regular security check of the network Remote Only a message is being displayed that tests should be performed with up-to date plugins. `M5.17 `_ Use of the security mechanisms of NFS Credentials `M5.18 `_ Use of the security mechanisms of NIS Credentials `M5.19 `_ Use of the security mechanisms of sendmail Remote `M5.19 `_ Use of the security mechanisms of sendmail Credentials `M5.20 `_ Use of the security mechanisms of rlogin, rsh and rcp Credentials `M5.21 `_ Secure use of telnet, ftp, tftp and rexec Credentials `M5.34 `_ Use of one time passwords Credentials `M5.59 `_ Protection from DNS-spoofing with authentication mechanisms Credentials `M5.63 `_ Use of GnuPG or PGP Credentials `M5.64 `_ Secure shell Remote `M5.66 `_ Use of TLS/SSL Remote `M5.72 `_ Deactivation of not required net services Credentials Only displays the services in question. `M5.90 `_ Use of IPSec under Windows Credentials `M5.91 `_ Use of fersonal firewalls for clients Credentials Microsoft Windows Firewall is being tested. For Vista and newer any firewall that is installed comforming to the system. On Linux systems, displaying if the the iptables rules, if possible. `M5.109 `_ Use of a e-mail scanners on the mailserver Remote `M5.123 `_ Securing of the network commuication under Windows Credentials `M5.131 `_ Securing of the IP protocols under Windows Server 2003 Credentials `M5.145 `_ Secure use of CUPS Credentials `M5.147 `_ Securing of the communication with directory services Remote =================================================================================================================== ======================================================================================== =========== =============================================================================================================================================================================================================== PCI DSS ^^^^^^^ Introduction into vulnerability analysis and policy monitoring for the Payment Card Industry Data Security Standard (PCI DSS) with the Greenbone Security Manager. 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. 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. 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. Special Policies ---------------- Mailserver Online Test ^^^^^^^^^^^^^^^^^^^^^^ In September 2014 the Bavarian State Office for Data Protection performed an online test "`Mailserver regarding STARTTLS, Perfect Forward Secrecy and Hartbleed `_". The organizations that were found to be affected by this test were asked to remove the security risks. Using Greenbone Security Manager or OpenVAS respectively an organziation can test themselves if their own mail servers comply with the security criteria. For this follow these steps: #. Import the following scan config: `onlinepruefung-mailserver-scanconfig.xml `_. #. Configure a new port with the port range :gos:setting:`T:25`. #. Configure a target containing the mailservers to be tested and select the port list created in the previous step. Depending on the the network settings it could make sense to use "Consider Alive" as Alive Test. #. Create a task with the target created above and the imported scan config. #. Start the scan. It can take 30-40 Minutes because generally the scanner has to wait for some data from the mailservers a bit longer. #. Finally you will get a scan report with different log entries for each mailserver. The missing StartTLS will initially only be displayed as a log message as it is a policy question how it should be assessed. For Example an override for this NVT can be created defining it as a high risk. The override can then be expanded to all hosts and possibly all tasks. #. Should monitoring be established, a schedule for this task can be created (i.e. every week on Sundays) as well as an alert (i.e. an email). Combined with the respective overrides an automated warning system is being created in the background. .. rubric:: Footnotes .. [#REG] http://windows.microsoft.com/en-ca/windows-vista/what-is-the-registry Conficker Search ---------------- `Conficker `_ is a computer worm that occured in fall 2008. It threatens Windows operating systems and caused numerous network failures with significant financial damage. The worm takes advantage of a security hole in the operating system and is self-updating. `Microsoft Bulletin MS08-067 `_ describes the most important security hole that is exploited by Conficker to attack the corresponding systems. Search methods for vulnerability and infection ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Using the Greenbone Security Manager two methods are recommended for the search: * Non-invasive search for the security holes described by Microsoft in Bulletin MS08-067, including the Conficker worm. * Invasive search for the security holes described by Microsoft in Bulletin MS08-067, including the Conficker worm. The first method is able to detect the presence of the vulnerability. The second method goes as far as exploiting the vulnerability to be certain that it is indeed present. Admittedly, this may cause outages of the corresponding systems and thus should be executed with appropriate prudence. Execute search for vulnerability and Conficker ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Import the `scan configuration Conficker Search `_ or, for the invasive search, the `scan configuration Invasive Conficker Search `_. .. figure:: images-3.1/conficker_importconfig.png :align: center :width: 70% * If the target systems do not allow anonymous access, create credentials to provide the scan engine with access to the target systems. If not done yet, create a corresponding user account on the Windows systems (a low privileged user account is sufficient). .. figure:: images-3.1/conficker_newcredential.png :align: center :width: 70% * Define the target systems (targets) and, if applicable, choose the respective credentials. .. figure:: images-3.1/conficker_newtarget.png :align: center :width: 70% * Now you can create the actual task. This means to combine the imported scan configuration with the newly created targets. .. figure:: images-3.1/conficker_newtask.png :align: center :width: 70% * The search is started by clicking on |start| of the respective task. It can take a while for the scan to complete. To update the view with the current progress, click on |refresh|. .. figure:: images-3.1/conficker_reportlist.png :align: center :width: 70% * As soon as the status changes to "Done" the complete report is available. At any time you can review the intermediate results. Here is an example for a system where the vendor security update for MS08-67 has not been installed. .. figure:: images-3.1/conficker_report.png :align: center :width: 70% OVAL System Characteristics --------------------------- The `Open Vulnerability and Assessment Language (OVAL) `_ is an approach for a standardized description of the (security) state of an IT system. OVAL files describe a vulnerability and define tests to identify the state in which a system is vulnerable. They usually refer to specific version of software products for which a known vulnerability exists. This means that in order to check for vulnerabilities described in an OVAL definition, information about the current state of the system is needed. This information is collected in a standardized format as well — the OVAL System Characteristics (SC). There are a number of solutions which perform checks based on OVAL definitions and SC files. OVAL definitions are `provided by various vendors `_. MITRE provides the `OVAL Repository `_ with more than 13,000 entries. OVAL Adoption Program ^^^^^^^^^^^^^^^^^^^^^ Greenbone is an official OVAL Adopter and Greenbone Security Manager is registered as a "Systems Characteristics Producer". See also: `OVAL Adoption Program `_. .. figure:: images-3.1/oval_adopter_150x150.png :align: right :width: 20% Supported are OVAL versions 5.3 to 5.10. Should any wrong, missing or incomplete OVAL element be found, users are encouraged to provide feedback to the Greenbone support team. The OVAL-SC implementation of the Greenbone solution allows to activate updates within a single day and therefore provides timely improvements for the users. Collecting Scan Results as OVAL SCs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ During a scan the Greenbone Security Manager collects large amounts of data about the target system. This information is managed in an optimized data pool. Parts of this information are usable as a component of an OVAL System Characteristics. The creation of OVAL SC files is not enabled by default but has to be explicitly enabled. The following scan configuration can be used to achieve this: `collect-oval-sc-v2.xml `_. Import the scan configuration in the GSM: .. figure:: images-3.1/oval-sc-import-scanconfig_500.png :align: center :width: 70% The new scan configuration is now shown in the list: .. figure:: images-3.1/oval-sc-scanconf-imported_500.png :align: center :width: 70% The most comprehensive results of a target system can be collected using authenticated scans. For this you need to create an account on the target system. Ensure that the account has the necessary privileges. For unixoid systems an account with low privileges is usually sufficient, for Windows system administrative privileges are required. .. figure:: images-3.1/oval_new_credential.png :align: center :width: 70% The following example shows the creation of a Linux target. For a Windows target the credential must be set in the SMB field instead of SSH. .. figure:: images-3.1/newtarget_linux_credential_500.png :align: center :width: 70% Now create the task, which you can start immediately. .. figure:: images-3.1/oval_sc_new_task_500.png :align: center :width: 70% The scan itself is quite fast because the scan configuration is optimized to collect only the specific data needed for generating the System Characteristics file. The results are returned a log information. If you adjust your filter you can see the OVAL System Characteristics in XML formatted for easy readability: .. figure:: images-3.1/oval-sc-results-overview_500.png :align: center :width: 70% .. figure:: images-3.1/oval-sc-results-details_500.png :align: center :width: 70% Please note: If you have collected data from a large number of target systems this view may become hard to read. Exporting OVAL SCs ^^^^^^^^^^^^^^^^^^ OVAL SC files are defined in a way that one file can contain only information about one system. Using the Greenbone Security Manager you can collect a large number of System Characteristics from many different systems in one single step. Because of this we provide two Report Format Plugins: * OVAL System Characteristics: Produces a single SC file in the XML format. * OVAL System Characteristics Archive: Can be used for an arbitrary number of System Characteristics, which will be collected in a ZIP file. The names of the individual SC files will contain the IP address of the target system. Both plugins are available for download on the `Report Formats page `_. Import the report format plugins, verify the signature and activate them. For detailed information about this process, please refer to: :ref:`report_plugins`. You can now download the results in the format you require for further processing. Select the format "OVAL-SC" or "OVAL-SC archive" in the "Full report" line: .. figure:: images-3.1/oval-sc-export_500.png :align: center :width: 70% The ZIP archives look as follows: .. figure:: images-3.1/oval-sc-archive.png :align: center :width: 70% Example: Using OVAL SCs with ovaldi ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The MITRE organization not only provides the OVAL standard but also provides a reference implementation for local OVAL checks. The `OVAL Interpreter ovaldi `_ is available under an Open Source license. By using the Greenbone Security Manager to provide OVAL System Characteristics it is easy to use ovaldi on Linux to check a Windows system — or the other way round. For example, if the target system you tested above was a Debian Linux system, you can now download the official `Debian OVAL definitions 2010 `_ and execute the test ("false" means that a condition was not met, i.e. a vulnerability does not exist on the target). Ovaldi automatically creates a HTML and XML version of the plain text output as shown below: `oval-sc-debian-squeeze-sample-ovaldi-results.html `_ (102 KByte) and `oval-sc-debian-squeeze-sample-ovaldi-results.xml `_ (4.2 MByte). To run the tests additionally download the files `oval-definitions-2010.xml `_ and `oval-sc-debian-squeeze-sample.xml `_. .. code-block:: bash $ cd /tmp $ ovaldi -m -o /tmp/oval-definitions-2010.xml \ -i /tmp/oval-sc-debian-squeeze-sample.xml \ -a /usr/share/ovaldi/xml/ ---------------------------------------------------- OVAL Definition Interpreter Version: 5.10.1 Build: 2 Build date: Sep 11 2012 07:49:59 Copyright (c) 2002-2012 - The MITRE Corporation ---------------------------------------------------- Start Time: Tue Sep 11 12:12:52 2012 ** parsing /tmp/oval-definitions-2010.xml file. - validating xml schema. ** checking schema version - Schema version - 5.3 ** skipping Schematron validation ** parsing /tmp/oval-sc-debian-lenny-sample.xml for analysis. - validating xml schema. ** running the OVAL Definition analysis. Analyzing definition: FINISHED ** applying directives to OVAL results. ** OVAL definition results. OVAL Id Result ------------------------------------------------------- oval:org.debian:def:1965 false oval:org.debian:def:1966 false oval:org.debian:def:1967 false oval:org.debian:def:1968 false oval:org.debian:def:1969 false oval:org.debian:def:1970 false oval:org.debian:def:1971 false oval:org.debian:def:1972 false oval:org.debian:def:1973 false oval:org.debian:def:1974 false ... oval:org.debian:def:2124 false oval:org.debian:def:2125 false oval:org.debian:def:2126 false oval:org.debian:def:2127 false oval:org.debian:def:2128 false oval:org.debian:def:2129 false oval:org.debian:def:2130 false oval:org.debian:def:2131 false oval:org.debian:def:2132 false oval:org.debian:def:2133 false ------------------------------------------------------- ** finished evaluating OVAL definitions. ** saving OVAL results to results.xml. ** running OVAL Results xsl: /usr/share/ovaldi/xml//results_to_html.xsl. ---------------------------------------------------- If the target system was a Microsoft Windows system, you can use the `definitions provided by MITRE `_ and execute the test ("false" means that a condition was not met, i.e. a vulnerability does not exist on the target). Ovaldi automatically creates a HTML and XML version of the plain text output as shown below: `oval-sc-windows-xp-sample-ovaldi-results.html `_ (23 KByte) and `oval-sc-windows-xp-sample-ovaldi-results.xml `_ (159 KByte). To run the tests additionally download the files `windows.xml `_ and `oval-sc-windows-xp-sample.xml `_. .. code-block:: bash $ cd /tmp $ ovaldi -m -o /tmp/windows.xml \ -i /tmp/oval-sc-windows-xp-sample.xml \ -a /usr/share/ovaldi/xml/ ---------------------------------------------------- OVAL Definition Interpreter Version: 5.10.1 Build: 2 Build date: Sep 11 2012 07:49:59 Copyright (c) 2002-2012 - The MITRE Corporation ---------------------------------------------------- Start Time: Tue Sep 11 15:57:55 2012 ** parsing /tmp/windows.xml file. - validating xml schema. ** checking schema version - Schema version - 5.10 ** skipping Schematron validation ** parsing /tmp/oval-sc-windows-xp-sample.xml for analysis. - validating xml schema. ** running the OVAL Definition analysis. Analyzing definition: FINISHED ** applying directives to OVAL results. ** OVAL definition results. OVAL Id Result ------------------------------------------------------- oval:org.mitre.oval:def:754 true oval:org.mitre.oval:def:15339 false oval:org.mitre.oval:def:15465 false oval:org.mitre.oval:def:15452 false oval:org.mitre.oval:def:15377 false oval:org.mitre.oval:def:15346 false oval:org.mitre.oval:def:15173 false oval:org.mitre.oval:def:15057 false oval:org.mitre.oval:def:15546 false oval:org.mitre.oval:def:14566 false oval:org.mitre.oval:def:720 false oval:org.mitre.oval:def:627 false oval:org.mitre.oval:def:286 false oval:org.mitre.oval:def:748 false oval:org.mitre.oval:def:684 false oval:org.mitre.oval:def:396 false oval:org.mitre.oval:def:1205 false oval:org.mitre.oval:def:679 false oval:org.mitre.oval:def:165 false oval:org.mitre.oval:def:565 false oval:org.mitre.oval:def:289 false oval:org.mitre.oval:def:730 false oval:org.mitre.oval:def:1162 false oval:org.mitre.oval:def:2041 false oval:org.mitre.oval:def:1946 false oval:org.mitre.oval:def:1815 false oval:org.mitre.oval:def:1282 false oval:org.mitre.oval:def:1804 false oval:org.mitre.oval:def:1469 false oval:org.mitre.oval:def:718 false oval:org.mitre.oval:def:347 false oval:org.mitre.oval:def:283 false oval:org.mitre.oval:def:282 false ------------------------------------------------------- ** finished evaluating OVAL definitions. ** saving OVAL results to results.xml. ** running OVAL Results xsl: /usr/share/ovaldi/xml/results_to_html.xsl. ----------------------------------------------------