9 Glossary

This section defines relevant terminology which is consistently used across the entire system.

9.1 CERT-Bund Advisory

The CERT-Bund, the Computer Emergency Response Team of the German Federal Office for Information Security (BSI), is the central point of contact for preventive and reactive measures regarding security related computer incidents.

With the intention of avoiding harm and limiting potential damage, the work of CERT-Bund includes the following:

  • Creating and publishing recommendations for preventive measures

  • Pointing out vulnerabilities in hardware and software products

  • Proposing measures to address known vulnerabilities

  • Supporting public agencies efforts to respond to IT security incidents

  • Recommending various mitigation measures

Additionally, CERT-Bund operates the German IT Situation Centre.

The services of CERT-Bund are primarily available to federal authorities and include the following:

  • 24 hour on call duty in cooperation with the IT Situation Centre

  • Analyzing incoming incident reports

  • Creating recommendations derived from incidents

  • Supporting federal authorities during IT security incidents

  • Operating a warning and information service

  • Active alerting of the federal administration in case of imminent danger

CERT-Bund offers a warning and information service (German: Warn- und Informationsdienst, abbreviated as “WID”). Currently this service offers the CERT-Bund advisories. This information service is only available to federal agencies as a closed list. The advisories describe current information about security critical incidents in computer systems and detailed measures to remediate security risks.

9.2 CPE

The Common Platform Enumeration (CPE) is modelled after CVE. It is a structured naming scheme for applications, operating systems and hardware devices.

CPE was initiated by MITRE and is maintained by NIST as a part of the National Vulnerability Database (NVD). NIST has already maintained the official CPE dictionary and the CPE specifications for many years. CPE is based on the generic syntax of the Uniform Resource Identifier (URI) and includes a formal name format, a language for describing complex platforms, a method for checking names against a system and a description format for binding text and tests to a name.

A CPE name starts with “cpe:/”, followed by up to seven components separated by colons (see Fig. 9.1):

  • Part (“h” for hardware, “o” for operating system or “a” for application)

  • Vendor

  • Product

  • Version

  • Update

  • Edition

  • Language

Example: cpe:/o:linux:kernel:2.6.0

_images/cpe_name_structure.png

Fig. 9.1 Name structure of a CPE name

CPE is composed of the following components:

  • Naming

    The name specification describes the logical structure of well-formed names (WFNs), their binding to URIs and formatted character strings as well as their conversion.

  • Name Matching

    The name matching specification describes the methods to compare WFNs with each other. This allows for the testing whether some or all WFNs refer to the same product.

  • Dictionary

    The dictionary is a repository of CPE names and metadata. Every name defines a single class of an IT product. The dictionary specification describes the processes for using the dictionary, for example searching for a specific name or for entries belonging to a more general class.

  • Applicability Language

    The applicability language specification describes the creation of complex logical expressions with the help of WFNs. These applicability statements can be used for tagging checklists, guidelines or other documents and, by that, for describing for which products the documents are relevant.

9.3 CVE

In the past, various organizations discovered and reported vulnerabilities at the same time and assigned them different names. This led to different scanners reporting the same vulnerability under different names making communication and comparison of the results complicated.

To address this, MITRE founded the Common Vulnerabilities and Exposure (CVE) project. Every vulnerability is assigned a unique identifier consisting of the release year and a simple number. This identifier serves as a 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 enabling the comparison of security tools and services.

The CVE database does not contain detailed technical information or any information regarding risk, impact or elimination of the vulnerability. A CVE only contains the identification number with the status, a short description and references to reports and advisories.

The National Vulnerability Database (NVD) refers to the CVE database and complements the content with information regarding the elimination, severity, possible impact and affected products of the vulnerability. Greenbone refers to the CVE database of the NVD.

9.4 CVSS

To support the interpretation of a vulnerability, the Common Vulnerability Scoring System (CVSS) was invented. CVSS is an industry standard for describing the severity of security risks in computer systems.

Security risks are rated and compared using different criteria. This allows for the creation of a priority list of counter measures.

CVSS is developed by the CVSS Special Interest Group (CVSS-SIG) of the Forum of Incident Response and Security Teams (FIRST). The current CVSS score version is 3.1.

The CVSS score in version 2 supports base score metrics, temporal score metrics and environmental score metrics.

Base score metrics

Base score metrics test the exploitability of a vulnerability and their impact on the target system. Access, complexity and requirement of authentication are rated. Additionally, they rate whether the confidentiality, integrity or availability is threatened.

Temporal score metrics

Temporal score metrics test whether a 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.

Environmental score metrics

Environmental score metrics describe the effect of a vulnerability within an organization. They take damage, target distribution, confidentiality, integrity and availability into account. This assessment strongly depends on the environment in which the vulnerable product is used.

9.5 DFN-CERT Advisory

While the individual VTs, CVEs, CPEs and OVAL definitions are created primarily to be processed by computer systems, DFN-CERT publishes new advisories regularly.

DFN-CERT is responsible for hundreds of universities and research institutions that are associated with the German Research and Education Network (German: Deutsches Forschungsnetz, abbreviated as DFN). Additionally, it provides key security services to government and industry.

An advisory describes especially critical security risks that require fast reacting. The DFN-CERT advisory service includes the categorization, distribution and rating of advisories issued by different software vendors and distributors.

9.6 Greenbone Enterprise Feed

The content of the Greenbone Enterprise Feed, which provides the vulnerability tests (VTs) for scanning, can be viewed in Greenbone’s SecInfo Portal.

9.7 Host

A host is a single system that is connected to a computer network and that can be scanned. One or many hosts form the basis of a scan target.

Hosts in scan targets and in scan reports are identified by their network address, either an IP address or a host name.

9.8 Vulnerability Test (VT)

A Vulnerability Test (VT) is a routine that checks a target system for the presence of a specific known or potential security problem. VTs include information about development date, affected systems, impact of vulnerabilities and remediation.

9.9 OVAL Definition

The Open Vulnerability and Assessment Language (OVAL) is a MITRE project and maintained by the Center of Internet Security (CIS).

OVAL is a language to describe vulnerabilities, configuration settings (compliance), patches and applications (inventory).

The XML based definitions allow simple processing by automated systems and describe the discovery of individual systems and vulnerabilities.

9.10 Port List

A port list is a list of ports. Each target is associated with a port list. This determines which ports are scanned during a scan of the target.

9.11 Quality of Detection (QoD)

The Quality of Detection (QoD) is a value between 0 % and 100 % describing the reliability of the executed vulnerability detection or product detection.

While the QoD range allows to express the quality quite fine-grained, in fact most of the test routines use a standard methodology. Therefore, QoD types are associate with a QoD value. The current list of types might be extended over time.

QoD in %

QoD Type

Description

100

exploit

The detection happened via an exploit and is therefore fully verified.

99

remote_vul

Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerability.

98

remote_app

Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerable application.

97

package

Authenticated package-based checks for Linux(oid) systems.

97

registry

Authenticated registry based checks for Microsoft Windows systems.

95

remote_active

Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible in which the detection would be wrong.

80

remote_banner

Remote banner checks of applications that offer patch level in version. Many proprietary products do so.

80

executable_version

Authenticated executable version checks for Linux(oid) or Microsoft Windows systems where applications offer patch level in version.

75

During system migration this value was assigned to any results obtained before QoD was introduced. However, some VTs eventually might own this value for some reason.

70

remote_analysis

Remote checks that do some analysis but which are not always fully reliable.

50

remote_probe

Remote checks in which intermediate systems such as firewalls might pretend correct detection so that it is actually not clear whether the application itself answered. For example, this can happen for non-TLS connections.

30

remote_banner_unreliable

Remote banner checks of applications that do not offer patch level in version identification. For example, this is the case for many open source products due to backport patches.

30

executable_version_unreliable

Authenticated executable version checks for Linux(oid) systems where applications do not offer patch level in version identification.

1

general_note

General note on potential vulnerability without finding any present application.

9.12 Report

A report is the result of a scan and contains a summary of what the selected VTs detected for each of the target hosts.

A report is always associated with a task. The scan configuration that determines the extent of the report is part of the associated task and cannot be modified. Therefore, for any report it is ensured that its execution configuration is preserved and available.

9.13 Result

A single result generated by the scanner as part of a report, for example a vulnerability warning or a log message.

9.14 Scan

A scan is a task in progress. For each task only one scan can be active. The result of a scan is a report.

The status of all active scans can be seen on the page Scan Management.

When the scan is running, the progress is shown as a percentage of total number of tests to be executed. The duration of a scan is determined by the number of targets and the complexity of the scan configuration and ranges from minutes to many hours or even days.

The page Scan Management offers the option to stop a scan.

9.15 Scanner

A scanner is an OpenVAS Scanner daemon or compatible OSP daemon on which the scan will be run.

9.16 Scan Configuration

A scan configuration covers the selection of VTs as well as general and very specific (expert) parameters for the scan server and for some of the VTs.

Not covered by a scan configuration is the selection of targets.

9.17 Schedule

A schedule sets the time when a task should be started automatically, a period after which the task should run again and a maximum duration the task is allowed to take.

9.18 Severity

The severity is a value between 0.0 (no severity) and 10.0 (highest severity) and expresses also a severity class (Log, Low, Medium and Critical).

This concept is based on CVSS but is applied in case no full CVSS Base Vector is available as well. For example, arbitrary values in that range are applied for overrides and used by OSP scanners even without a vector definition.

Comparison, weighting and prioritisation of any scan results or VTs is possible because the severity concept is strictly applied across the entire system. Any new VT is assigned with a full CVSS vector even if CVE does not offer one and any result of OSP scanners is assigned an adequate severity value even if the respective scanner uses a different severity scheme.

The severity classes Log, Low, Medium and Critical are defined by sub-ranges of the main range 0.0 – 10.0.

Scan results are assigned a severity while achieved. The severity of the related VT may change over time though.

9.19 Solution Type

This information shows possible solutions for the remediation of the vulnerability.

Temporary Fix

A workaround (information about a configuration or a specific deployment scenario that can be used to avoid exposure to the vulnerability) is available to temporarily eliminate the vulnerability. There can be none, one or more workaround(s) available. This is usually the “first line of defense” against a new vulnerability before a risk reduction or official fix has been issued or even discovered.

Risk Reduction

Information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product.

Official Fix

An official vendor patch is available. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.

Searching for Fix

There is currently no solution available to remediate the vulnerability but there may be a solution in the future.

No Fix Available

There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated.

9.20 Target

A target defines a set of systems (hosts) that is scanned. The systems are identified either by their IP addresses, by their host names or with CIDR network notation.

9.21 Task

A task is initially formed by a target and a scan configuration. Executing a task initiates a scan. Each scan produces a report. As a result, a task collects a series of reports.

A task’s target and scan configuration are static. Thus, the resulting sequence of reports describes the change of security status over time.