The CVEs, CPEs and OVAL definitions are published and made accessible by NIST as part of the National Vulnerability Database (NVD) (see also section Security Content Automation Protocol (SCAP)).
18.3. Security Content Automation Protocol (SCAP)
The National Institute of Standards and Technology (NIST) in the USA provides the National Vulnerability Database (NVD).
NVD is a data repository for the vulnerability management of the US government.
The goal is the standardized provision of the data for the automated processing and support for the function of vulnerability management and the implementation of compliance guide lines.
The NVD provide different databases.
They include
- check lists,
- vulnerabilities,
- misconfigurations,
- products and
- threat metrics.
For this the NVD utilizes the Security Content Automation Protocol (SCAP).
The Security Content Automation Protocol is a combination of different interoperable standards.
Many standards were developed or derived from public discussion.
The public participation of the community in the development is an important aspect for accepting and spreading of the SCAP standards.
The SCAP protocol is currently specified in version 1.2 and includes the following components:
- Languages
- XCCDF: The Extensible Configuration Checklist Description Format
- OVAL: Open Vulnerability and Assessment Language
- OCIL: Open Checklist Interactive Language
- Asset Identification
- ARF: Asset Reporting Format
- Collections
- CCE: Common Configuration Enumeration
- CPE: Common Platform Enumeration
- CVE: Common Vulnerabilities and Exposure
- Metrics:
- CVSS: Common Vulnerability Scoring System
- CCSS: Common Configuration Scoring System
- Integrity
- TMSAD: Trust Model for Security Automation Data
OVAL, CCE, CPE and CVE are trademarks of NIST.
The Greenbone vulnerability scanner uses the OVAL standard, CVE, CPE and CVSS.
By utilizing these standards the interoperability with other systems is guaranteed.
These standards also allow comparing of the results.
Vulnerability scanners such as the Greenbone Security Manager can be validated by NIST respectively.
The Greenbone Security Manager has been validated with respect to SCAP version 1.0.
Following, the standards utilized by the Greenbone Security Manager are being covered in more detail.
18.3.1. CVE
Due to the fact that in the past often multiple organizations discovered and reported vulnerabilities at the same time and assigned them different names, communication and comparison of the results was not easy.
Different scanners reported the same vulnerability under different names.
As a matter of fact instead of two different vulnerabilities it was actually the same vulnerability.
To address this, MITRE , sponsored by the US-CERT, founded the CVE project in 1999.
Every vulnerability is assigned a unique identifier consisting of the year and a simple number.
This number then serves as central reference.
The CVE database of MITRE is not a vulnerability database.
CVE was developed in order to connect the vulnerability database and other systems with each other.
This allows for the comparison of security tools and services.
This is why the CVE database does not contain any information regarding risk, impact or remediation of the vulnerability.
Detailed technical information is also not included.
A CVE only contains the identification number with status, a short description and references to reports and advisories.
The National Vulnerability Database (NVD) refers to MITRE’s CVE database and supplements this information with information in regards to remediation of the vulnerability, the severity, affected products and possible impact.
Greenbone refers to the CVE database of the NVD so that information is included.
At the same time does the GSM combine the information with the NVTs and the CERT-Bund and DFN-CERT advisories.
This information can be displayed comfortably in the web interface.
18.3.2. CPE
The abbreviation CPE stands for Common Platform Enumeration, modelled after CVE and started by MITRE as well, as an industry standard for a common naming convention for information technology systems.
Hereby common naming exists for operating systems and applications allowing for global referencing.
Originally the Common Platform Enumeration (CPE) was initiated by MITRE.
Today the CPE standard is maintained by the US American National Institute for Standards and Technology NIST as part f the National Vulnerability Database (NVD).
NIST already had maintained the official CPE dictionary and the CPE specifications for many years.
CPE is a structured naming schema for applications, operating systems and hardware devices.
It is based on the generic syntax of the Uniform Resource Identifier (URI).
Due to the fact that the CPE standard is closely tied to the CVE standard, their combination allows for conclusion of existing vulnerabilities when discovering a platform or product.
CPE is composed of the following components:
- Naming:
- The name specification describes the logical structure of well-formed names (WFNs), its binding to URIs and formatted character strings and the conversion of the WFNs and their bindings.
- Name Matching:
- The name matching specification describes the methods to compare WFNs with each other.
This allows for the testing if some or all refer to the same product.
- Dictionary:
- The dictionary is a repository of CPE names and meta data.
Every name defines an single class of an IT product.
The dictionary specification describes the processes for the use of the dictionary, like the search for a specific name or entries, which belong to a more general class.
- Applicability Language:
- The applicability language specification describes the creation of complex logical expressions with the help of the WFNs.
These applicability statements can be used for the tagging of check lists, guide lines or other documentation and as such describe for which products these documents are relevant for.
18.3.3. OVAL
The Open Vulnerability and Assessment Language is also a Mitre project.
It is a language to describe vulnerabilities, configuration settings (compliance), patches and applications (inventory).
The XML based definitions allow for simple processing by automated systems.
As such the OVAL definition oval:org.mitre.oval:def:22127 of the inventory class describes the Adobe Flash Player 12 while the OVAL definition oval:org.mitre.oval:def:22272 describes a vulnerability of Google Chrome under Windows.
These OVAL definitions are created made available in XML and describe the discovery of individual systems and vulnerabilities.
The above mentioned OVAL definition 22272 has the following structure:
<definition id="oval:org.mitre.oval:def:22272" version="4" class="vulnerability">
<metadata>
<title>Vulnerability in Google Chrome before 32.0.1700.76 on Windows allows
attackers to trigger a sync with an arbitrary Google account by
leveraging improper handling of the closing of an untrusted signin
confirm dialog</title>
<affected family="windows">
<platform>Microsoft Windows 2000</platform>
<platform>Microsoft Windows XP</platform>
<platform>Microsoft Windows Server 2003</platform>
<platform>Microsoft Windows Server 2008</platform>
<platform>Microsoft Windows Server 2008 R2</platform>
<platform>Microsoft Windows Vista</platform>
<platform>Microsoft Windows 7</platform>
<platform>Microsoft Windows 8</platform>
<platform>Microsoft Windows 8.1</platform>
<platform>Microsoft Windows Server 2012</platform>
<platform>Microsoft Windows Server 2012 R2</platform>
<product>Google Chrome</product>
</affected>
<reference source="CVE" ref_id="CVE-2013-6643"
ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6643"/>
<description>The OneClickSigninBubbleView::WindowClosing function in
browser/ui/views/sync/one_click_signin_bubble_view.cc in Google
Chrome before 32.0.1700.76 on Windows and before 32.0.1700.77 on Mac
OS X and Linux allows attackers to trigger a sync with an arbitrary
Google account by leveraging improper handling of the closing of an
untrusted signin confirm dialog.</description>
<oval_repository>
<dates>
<submitted date="2014-02-03T12:56:06">
<contributor organization="ALTX-SOFT">Maria Kedovskaya</contributor>
</submitted>
<status_change date="2014-02-04T12:25:48.757-05:00">DRAFT</status_change>
<status_change date="2014-02-24T04:03:01.652-05:00">INTERIM</status_change>
<status_change date="2014-03-17T04:00:17.615-04:00">ACCEPTED</status_change>
</dates>
<status>ACCEPTED</status>
</oval_repository>
</metadata>
<criteria>
<extend_definition comment="Google Chrome is installed"
definition_ref="oval:org.mitre.oval:def:11914"/>
<criteria operator="AND" comment="Affected versions of Google Chrome">
<criterion comment="Check if the version of Google Chrome is greater than
or equals to 32.0.1651.2" test_ref="oval:org.mitre.oval:tst:100272"/>
<criterion comment="Check if the version of Google Chrome is less than
or equals to 32.0.1700.75" test_ref="oval:org.mitre.oval:tst:99783"/>
</criteria>
</criteria>
</definition>
This information are being processed graphically by the web interface and presented easily readable (see figure OVAL describes the discovery of vulnerabilities.).
18.3.4. CVSS
A big problem for regular administrators is the interpretation of vulnerability with their own environment.
How critical does he have to rate a vulnerability?
To support personnel that do not work with the analysis and rating of vulnerabilities constantly the Common Vulnerability Scoring System (CVSS) was invented.
CVSS is an industry standard for the description of the severity of security risks in computer systems.
In the CVSS security risks are rated and compared using different criteria.
This allows for the creation of a priority list of counter measures.
The CVSS score is continuously improved upon.
Currently in general the CVSS score version 2 is being used.
Version 3 is being developed by the CVSS Special Interest Group (CVSS-SIG) of the Forum of Incident Response and Security Teams (FIRST).
The CVSS score in version 2 supports Base Score Metrics, Temporal Score Metrics and Environmental Score Metrics.
The Base Score Metrics in general test the exploitability of a vulnerability and their impact on the target system.
Hereby access, complexity and requirement of authentication are rated.
At the same time they rate if the confidentiality, integrity or availability is threatened.
The Temporal Score Metrics test if completed example code exists, the vendor already supplied a patch and confirmed the vulnerability.
The score will be changing drastically in the course of time.
The Environmental Score Metrics review if control damage has to be suspected, the target distribution, and if confidentiality, integrity of availability is required.
This assessment is strongly depended on the environment in which the vulnerable product is being used.
Since the Base Score Metrics are merely meaningful in general and can be determined permanently the GSM provides them as part of the SecInfo data.
Hereby the following formula is being used and can be calculated with the CVSS calculator of the GSM as well (Extras/CVSS-Calculator, see figure The CVSS calculator allows for the calculation of scores conveniently.).
Hereby the impact is calculated as follows:
The exploitability is calculated as:
The function 
is 0, if the impact is 0.
In all other cases the value is 1.176.
The other values are constants:
- Access Vector
- requires local access: 0.395
- adjacent network accessible: 0.646
- network accessible: 1.0
- Access Complexity:
- high: 0.35
- medium: 0.61
- low: 0.71
- Authentication
- requires multiple instances of authentication: 0.45
- requires single instance of authentication: 0.56
- requires no authentication: 0.704
- ConfImpact:
- none: 0.0
- partial: 0.275
- complete: 0.660
- IntegImpact
- none: 0.0
- partial: 0.275
- complete: 0.660
- AvailImpact
- none: 0.0
- partial: 0.275
- complete: 0.660
