OpenVAS Terms to Know
A Host is a single system that is connected to a computer network and that may 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 hostname.
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.
This concept also solves the challenge of potential vulnerabilities. Such are always recorded and kept in the results database but are only visible on demand.
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.
|100%||exploit||The detection happened via an exploit and therefore is fully verified.|
|99%||remote_vul||Remote active checks (code execution, traversal attack, sql injection etc.) where the response clearly shows the presence of the vulnerability.|
|98%||remote_app||Remote active checks (code execution, traversal attack, sql injection etc.) where 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 Windows systems.|
|95%||remote_active||Remote active checks (code execution, traversal attack, sql injection etc.) where the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible where the detection would be wrong.|
|80%||remote_banner||Remote banner check of applications that offer patch level in version. Many proprietary products do so.|
|80%||executable_version||Authenticated executable version checks for Linux(oid) or Windows systems where applications offer patch level in version.|
|75%||This value was assigned to any pre-qod results during system migration. 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 where intermediate systems such as firewalls might pretend correct detection so that it is actually not clear whether the application itself answered. This can happen for example for non-TLS connections.|
|30%||remote_banner_unreliable||Remote banner checks of applications that don’t 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 don’t 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 the default filtering to display the results in the reports.
The Severity is a value between 0.0 (no severity) and 10.0 (highest severity) and expresses also a Severity Class (None, Low, Medium or High).
This concept is based on CVSS but is applied also where no full CVSS Base Vector is available. For example, arbitrary values in that range are applied for Overrides and used by OSP scanners even without a vector definition.
Comparison, weighting, prioritisation is possible of any scan results or NVTs because the severity concept is strictly applied across the entire system. Not a single severity is just expressed as “High” for example. Any new NVT is assigned with a full CVSS vector even if CVE does not offer one and any results of OSP scanners is assigned a adequate severity value even if the respective scanner uses a different severity scheme.
The severity classes None, 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. Users can select Dynamic Severity to let the system always use the most current severity of NVTs for the results.
This information shows possible solutions for the remediation of the vulnerability. Currently three different variants are available:
Workaround: Information is available about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability. There may be none, one, or more workarounds available. This is typically the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information is available about a configuration or deployment scenario that helps to reduce the risk of the vulnerability 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.
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.
None-Available: Currently there is no fix available. Information should contain details about why there is no fix.
WillNotFix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, end-of-life, or otherwise deprecated. Information should contain details about why there will be no fix issued.