21. Glossary

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

21.1. Alert

An alert is an action which can be triggered by certain events. In most cases, this means the output of a notification, e.g. an e-mail in case of new found vulnerabilities.

21.2. Asset

Assets are discovered on the network during a vulnerability scan or entered manually by the user. Currently, assets include hosts and operating systems.

21.3. CERT-Bund Advisory

An advisory published by CERT-Bund. See https://www.cert-bund.de/about for more information.

21.4. CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, platforms and packages. Based on the generic syntax for Uniform Resource Identifiers (URI), CPE 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:

  • 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

21.5. CVE

Common Vulnerabilities and Exposures (CVE) is a dictionary of publicly known information security vulnerabilities and exposures.

21.6. CVSS

The Common Vulnerability Scoring System (CVSS) is an open framework to characterize vulnerabilities.

21.7. DFN-CERT Advisory

An advisory published by DFN-CERT. See https://www.dfn-cert.de/ for more information.

21.8. Filter

A filter describes how to select a certain subset from a group of resources.

21.9. Group

A group is a collection of users.

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

A host is also an asset type. Any scanned or discovered host can be recorded in the asset database.

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

In the asset database the identification is independent of the actual network address, which however is used as the default identification.

21.11. Note

A note is a textual comment associated with an NVT. Notes show up in reports, below the results generated by the NVT. A note can be applied to a particular result, task, severity, port and/or host, so that the note appears only in certain reports.

21.12. Network Vulnerability Test (NVT)

A Network Vulnerability Test (NVT) is a routine that checks a target system for the presence of a specific known or potential security problem.

NVTs are grouped into families of similar NVTs. The selection of families and/or single NVTs is part of a scan configuration.

21.13. OVAL Definition

An OVAL definition is a definition as specified by the OVAL (Open Vulnerability and Assessment Language), version 5.10.1. It can be used for different classes of security data like vulnerabilities, patches or compliance policies.

21.14. Override

An override is a rule to change the severity of items within one or many report(s).

Overrides are especially useful to mark report items as False Positives (e.g. an incorrect or expected finding) or emphasize items that are of higher severity in the observed scenario.

21.15. Permission

A permission grants a user, role or group the right to perform a specific action.

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

21.17. 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 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 NVTs 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.

The value of 70 % is the default minimum used for filtering the displayed results in the reports.

21.18. Remediation Ticket

Remediation tickets are used to resolve the findings of vulnerabilities. Tickets can be assigned to the current user or other users. All valuable information to understand and resolve the problem is directly cross-linked and available for the assigned user.

All tickets have a specific status (e.g., open, fixed) to track the progress.

Additionally, alerts can be assigned for certain events considering tickets, e.g., a status change of an assigned ticket.

The ticket management system is capable of considering the repetition of scans automatically in order to verify that the problem has been solved.

21.19. Report

A report is the result of a scan and contains a summary of what the selected NVTs 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.

21.20. Report Format

A format in which a report can be downloaded.

An example is TXT which has the content type “text/plain”, meaning that the report is a plain text document.

21.21. Result

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

21.22. Role

A role defines a set of permissions that can be applied to a user or a group.

21.23. 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 Tasks.

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 Tasks offers an option to stop a scan.

If a stopped or interrupted scan is resumed, all unfinished hosts are scanned completely anew. The data of hosts that were already fully scanned is kept.

21.24. Scanner

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

21.25. Scan Configuration

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

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

21.26. Schedule

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

21.27. 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 or High).

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 NVTs is possible because the severity concept is strictly applied across the entire system. Any new NVT 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 High are defined by sub-ranges of the main range 0.0 – 10.0. Users can select to use different classifications. The default is the NVD classification which is the most commonly used one.

Scan results are assigned a severity while achieved. The severity of the related NVT may change over time though. If Dynamic Severity is selected in the user settings the system always uses the most current severities of NVTs for the results.

21.28. Solution Type

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

  • st_workaround Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. There can be none, one or more workarounds available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
  • st_mitigation Mitigation: 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. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product and they may or may not be officially sanctioned by the document producer.
  • st_vendorfix Vendor fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
  • st_nonavailable No fix available: Currently there is no fix available. Information should contain details about why there is no fix.
  • st_willnotfix Will not fix: 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. Information should contain details about why there will be no fix issued.

21.29. Tag

A tag is a short data package consisting of a name and a value that is attached to a resource of any kind and contains user defined information on this resource.

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

21.31. 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. However, a task can be marked as alterable when there are no reports present. For such a task the target and scan configuration can be changed at any time which may be convenient in certain situations.

A container task is a task with the function to hold imported reports. Running a container task is not possible.