Frequently Asked Questions

How do you get your CVSS ratings? Why do these sometimes differ from the manufacturer's information or the CVE database?

CVSS essentially represents the properties of vulnerabilities in an automatically evaluable format. Our system is able to generate CVSS based on the detected vulnerability properties.

When a CVSS vector is already known at the time of the advisory creation, we usually adopt it, but still check whether the information matches the source text, since in certain cases the manufacturers define the vector in favour of less criticality. We make sure that the information in CVSS is consistent with the texts.

There are cases where there are already different vectors for a vulnerability in the sources. In such cases we adopt the vector with the higher criticality according to our "worst case principle" at first, but validate it in a later step.

The CVSS data may therefore differ from the official CVE database. We do not carry out a subsequent adjustment. A correction in individual cases is possible and will be carried out if necessary.

How do you evaluate attack probability and damage?

We have had our own scheme ("VAS scheme" in the following) in place since 1999. Over the years, this has been repeatedly adapted to the circumstances. An assessment consists of the components attack probability and potential damage. Both components are rated on a scale of 1 (low) to 5 (high). The following tables show how the evaluation is structured.

Attack Probability

Attack Probability	Base Value		Modification
remote anonymous	4	Exploit/Proof-of-Concept-Code / described in detail / applicable, even when the exploit is invisible, that means a trustworthy source (e.g. vendor) attests the exploitation	+1
		user action trivial (according to intended use, 1-click (Mail etc.))	-1
		user action complex/administrative user	-2
		no information	-1
		limited range (not routable / Lan / Wlan)	-1
remote unknown	3	Exploit/Proof-of-Concept-Code / described in detail / applicable, even when the exploit is invisible, that means a trustworthy source (e.g. vendor) attests the exploitation	+1
		user action trivial (according to intended use, 1-click (Mail etc.))	-1
		user action complex/administrative user	-2
		no information	-1
		limited range (e.g. not routable / Lan / Wlan)	-1
remote authenticated authentication via network access (autentication to access to the application)	2	Exploit/Proof-of-Concept-Code / described in detail / applicable, even when the exploit is invisible, that means a trustworthy source (e.g. vendor) attests the exploitation	+1
		user action trivial (according to intended use, 1-click (Mail etc.))	-1
		user action complex/administrative user	-2
		no information	-1
		limited range (e.g. not routable / Lan / Wlan)	-1
local (Shell / account on the operating system) includes SSH, Telnet	2	Exploit/Proof-of-Concept-Code / described in detail / applicable, even when the exploit is invisible, that means a trustworthy source (e.g. vendor) attests the exploitation	+1
		no information	-1
		user interaction	-1
		privileged account needed	-1
physical access	1	Exploit/Proof-of-Concept-Code / described in detail / applicable, even when the exploit is invisible, that means a trustworthy source (e.g. vendor) attests the exploitation	+1

Damage

Target	Base Value		Modification
Admin / System	5
User / application / daemon	4	extremly limited (e.g. in virt. envirmonment)	-1
DoS	3	Client application Word, Excel, Browser, singular application	-1
		critical system (network infrastructure, AAA, IOS, operating system Windows SERVER and Unix/Linux)	+1
		Server application(e.g. Apache Server)	0
access to data / Manipulation	2	SQL Injection	+2
		system authentication	+2
		write access (CF oder XSS + Meta: user action) authentication access	+1
		Info gain / unimportant data	-1
bypass	3	security component (Firewall)	+1
		even AntiVirus	0
		Cryptography	+2

I noticed that your CVSS vectors deviate from the rating according to the VAS scheme every now and then. How did this happen?

Our VAS scheme has 5x5 different gradations (or ultimately 5 risk levels), whereas CVSS knows 100 different scores due to the decimal place. Our scheme is easy to explain and traceable on a maximum of two A4 pages. CVSS is based on complex mathematics.

Furthermore, there are different weightings of individual vulnerability characteristics. Examples:

Different weighting of individual facts. For example, when bypassing security mechanisms (damage amount = 3), we evaluate a higher damage amount if special security components are bypassed (=4) or if cryptography can be bypassed (=5). CVSS makes no distinction here and only sees the general impact on the protection goals "confidentiality" and "integrity".
Requirement for user action: VAS evaluates -1 for the probability of attack; CVSS only considers this in the metric "AC" (Access Complexity) for CVSSv2 in the decimal place. CVSSv3 has been further developed in this respect and has the separate metric "UI" (User Interaction).
Existence of an exploit: VAS evaluates +1 in attack probability; CVSS only considers this in the "Temporal Score" in the decimal place

Your advisory gives a CVSS rating with a local attacker, but the description says "remote attacker" - how does that fit?

The term "remote attacker" in our advisories refers to the location of the attacker. The metric "AV" in the CVSS v3.1 vector in turn indicates the interface (remote/local) through which the attack takes place. In this case, the attack itself is performed locally.

For example, if CVSS states that the attack vector is local (AV:L) and requires user interaction (UI:R), this usually describes an attack where the victim is tricked, for example through social engineering, into opening a specially crafted file, resulting in a local attack on the computer.

This is where CVSS v2 and v3.1 differ - while version 2 indicates the location of the attacker, version 3.1 refers to the interface used for the attack.

What is CVE? What is the relationship between CVE and your advisory numbers?

The CVE number uniquely identifies a vulnerability worldwide (CVE = Common Vulnerability Enumeration), but this can occur in several products. Conversely, several CVEs are often combined in an advisory for a particular product.

Each advisory can therefore contain any number of CVEs, but a CVE can also be mentioned in several advisories (e.g. Android often has CVE numbers, which we already reported in Linux kernel, libxml etc., because these components and their vulnerabilities are part of Android).

Are your advisories also available in a machine-readable format?

Yes, we also publish all advisories in an XML format, that is aligned with the "Common Vulnerability Reporting Framework" (CVRF). You can either download it from our web server or receive it as a daily e-mail.

Customers can use the following URLs to download CVRF:

https://www.dcert.de/customer/cvrf_v2/index.txt => Index with file names for single download

https://www.dcert.de/customer/cvrf_v2/cvrf2_YYYY-MM-DD.zip => All advisories from day YYYY-MM-DD in a ZIP file

Information on the use of cookies