CVSS (Common Vulnerability Scoring System)

1. the CVSS (Common Vulnerability Scoring System)

CVSS v3.1 Calculator (CVSS Score)

What is the CVSS (Common Vulnerability Scoring System)?

The Common Vulnerability Scoring System (CVSS) is a standard for assessing IT security vulnerabilities. The CVSS score is a numerical representation of the severity (0-10) of a security vulnerability. CVSS scores are used to compare and prioritise the remediation of IT vulnerabilities. Vulnerabilities with a high CVSS score are prioritised over vulnerabilities with a low CVSS score.

Although assessing IT vulnerabilities with a standardised methodology and uniform scoring is very beneficial for information sharing, the limitations of CVSS should also be known to ensure appropriate use.

Initial research by a US Department of Homeland Security working group led to the release of CVSS 1.0 in February 2005, and since then CVSS has been maintained by the Forum of Incident Response and Security Teams (FIRST), a US-based non-profit organisation. As of 2019, the latest version is.

CVSS Score

A CVSS score is composed of up to three individual assessments (Base, Temporal, Environmental). The central assessment is that of the base metrics. The result of the base evaluation is the CVSS base score and can then be adapted to the own IT environment by adding temporal or environmental factors. In practice, however, the term CVSS score is often simply understood to mean the CVSS base score.

CVSS Vector

A CVSS score can also be specified as a so-called CVSS Vector. This is a shortened text format from which the CVSS Score can be derived.

2. Definition of CVSS Score

In IT security, the use of CVSS scores to measure the criticality of an IT security vulnerability is the de facto standard. They are also commonly used in penetration testing to assess the vulnerabilities discovered.

CVSS scores are also the most important metric for managing security vulnerabilities in the IT infrastructure and prioritising their closure.

A CVSS score can consist of up to three individual evaluations, so-called metric groups. The result is a CVSS Basic Score, an optional CVSS Temporal Score (time-dependent) and a CVSS Environmental Score (depending on the specific IT environment).

1. Base: The Base metric shows the attributes inherent to a vulnerability that are independent of the environment or time. The result of the assessment is the CVSS Base Score.
2. Temporal: The temporal metric takes the base metric as a starting point and decreases it somewhat based on some considerations such as: If there is no well-functioning and published exploit code, the CVSS Score is slightly lowered. If there is a temporary fix/workaround, the CVSS score is slightly decreased. The result is then the CVSS Temporal Score.
3. Environmental: The environmental metric can either increase or decrease the CVSS Score based on considerations such as the particular vulnerability/criticality of the affected data or a change in vulnerability due to a specific system configuration or network constellation. The result is the CVSS Environmental Score.

Qualitative scale of the CVSS Score

Sometimes it is useful to have a descriptive representation of the numerical scores. For this purpose, the following scheme is included in the standard since CVSS v3.0.

For example, a CVSS base score of 6.0 has a severity rating of Medium.”

Example (EternalBlue)

3. Operationalisation of CVSS scores

The published CVSS scores of IT vulnerabilities are usually the CVSS base scores. The starting point is what damage can be done with an IT vulnerability.

The more important question in companies and authorities, however, is actually whether this IT vulnerability can cause damage here specifically in this environment and currently.

Therefore, the temporal and environmental factors should be included in an assessment and thus also prioritisation. When operating one’s own vulnerability management programme, such considerations are essential to ensure correct prioritisation.

Nevertheless, I would like to point out that there is basically (almost) no legitimate reason not to patch vulnerabilities promptly and also not to keep software up-to-date – but this is another discussion.

4. CVSS Base Score (CVSS Basis Score)

Since the base metric group focuses on the core properties of an IT vulnerability, it does not change over time or depending on environmental factors.

When a CVSS score is documented for a vulnerability in a public system such as NIST’s National Vulnerability Database NVD, the score given is almost always the CVSS Base Score.

To calculate the CVSS Base Score (also CVSS Basis Score), the following factors are evaluated:

• Ease of exploitation (Exploitability).
• Severity of impact
• Change in scope (a change in scope is the case, for example, when an attacker can break out of a sandbox).

Vulnerability (Exploitability) rating

The exploitability rating refers specifically to the IT vulnerability without relating it to a particular configuration or other compensating factors. This assessment has four components – attack vector (AV), attack complexity (AC), required privileges (PR) and whether user interaction (UI) is necessary.

Attack Vector (AV)

The attack vector is an indicator of the level of access an attacker needs to exploit the vulnerability. A vulnerability that requires local or even physical access to a target system is much more difficult to exploit than one that can be exploited remotely purely over the network or even the Internet.

The attack vector is evaluated according to the following scheme:

• Network (N): The vulnerability can be exploited remotely – up to remote exploitation via the Internet.
• Adjacent (A): The vulnerability can only be exploited via a neighbouring network. The attack must originate from the same physical or logical network. A VLAN may make exploitation of the vulnerability difficult or impossible.
• Local (L): The vulnerability can not be exploited via a network. The attacker must access the IT system locally or remotely (for example, via RDP or SSH). However, exploitation via Social Engineering can also fall under this, if an unsuspecting user helps to exploit the vulnerability.
• Physical (P): In this type of attack, the attacker must have physical access to the IT system.

Complexity of attack (AC).

This Complexity of Attack represents conditions outside the attacker’s control that must be present for the vulnerability to be exploited. Most often, this is a specific required configuration of the target system.

Attack complexity is rated as either low or high:

• Low (L): Exploitation of the vulnerability does not require any special preconditions.
• High (H): There are preconditions for a successful attack that cannot be controlled by the attacker. This may include bypassing security software.

Required Privileges (PR).

Required Privileges describes the level of privileges or necessary access an attacker must have for a successful attack.

Required privileges can be divided into three levels:

• None (N): The attack can be carried out without any special privileges.
• Low (L): The access rights of a normal user are required for a successful attack.
• High (H): Administrative rights or similar privileges are required for a successful attack.

User interaction (UI)

The User Interaction describes whether another user must do something for a successful exploit of the vulnerability to occur.

The necessity of a user interaction is evaluated as follows:

• None (N): No user interaction is required.
• Required (R): A user must perform one or more steps for the IT vulnerability to be successfully exploited. For example, the user must download and open an Office document and then confirm the execution of macros.

Scoring the impact of a vulnerability (Impact).

Impact metrics are intended to evaluate the consequences of the exploitation of an IT vulnerability on the information security protection objectives (confidentiality, integrity, availability). In other words: What is the negative end result as a consequence of a successful attack?

Confidentiality (C)

Confidentiality refers to the disclosure of sensitive information to unauthorised persons.

The loss of confidentiality is rated as follows:

• None (N): Disclosure of information does not occur.
• Low (L): The attacker gains partial access to information.
• High (H): The attacker succeeds in gaining full access to all resources of the affected IT system, including highly sensitive information such as cryptographic keys.

Integrity (I)

Integrity refers to whether the protected information has been manipulated or altered in any way. If there is no way for an attacker to alter the accuracy or completeness of the information, integrity is maintained.

The loss of integrity is thereby assessed as follows:

• None (N): There is no loss of integrity of the processed information.
• Low (L): – A subset of information may be altered. However, there is no weighty impact on the IT system.
• High (H): – The attacker can change all information on the target system. This leads to a complete loss of integrity.

Availability (A)

If information is no longer available in a timely manner due to an attack, for example due to deletion/encryption (ransomware) or a DDOS attack, the availability is negatively affected.

The loss of availability is assessed as follows:

• None (N): there is no loss of availability.
• Low (L): Availability may be temporarily reduced, or performance may be negatively affected by a successful attack.
• High (H): There is a loss of availability of the affected system or information.

Scope (S)

The Scope is used to determine whether an IT vulnerability in one system or component can have an impact on another system or component that lies outside the security instance of the attacked component.

The term security instance refers to mechanisms that are responsible for access control. This can be, for example, applications, the operating system, a container, a virtual machine, a browser sandbox or similar.

So if a security vulnerability in a browser leads to an attacker being able to read out the browser history, this usually does not count as a change in scope.

If, on the other hand, a browser vulnerability leads to data being accessed at the operating system level, it does. From the browser’s perspective, the operating system is not part of the browser’s security instance.

The scope can be evaluated as follows:

• Changed (C): An exploited vulnerability can affect another component that does not belong to the security instance of the component with the vulnerability.
• Unchanged (U): The exploited vulnerability is limited in its damage only to the local security instance.

5. CVSS Temporal Score (time-dependent)

With the CVSS Temporal Score, the effects of an IT security vulnerability can be evaluated over time. The basis of the temporal score is the CVSS Basic Score.

The basic idea is the current exploitability of the vulnerability and the possibility of countermeasures, such as an existing security patch.

Exploit Code Maturity: As long as there is no method to exploit a vulnerability, it is harmless. As with most software, the code available to exploit a vulnerability may mature over time, becoming more stable and more widespread. As this happens, the score for that subcomponent increases.

State of Mitigation (Mitigation Status): When a vulnerability is first discovered, there may be no patch or other mitigation available. Over time, workarounds, temporary fixes, and eventually official patches become available, causing the vulnerability score to decrease as remediation improves.

Report Confidence: Confidence measures the degree of validation showing that a vulnerability is both real and exploitable.

6. CVSS Environmental Score (environment-dependent).

CVSS environmental metrics allow the base CVSS to be modified based on custom security requirements and environmental criteria.

Environmental security requirements: The security requirements provide information for the criticality of the information involved. Mission critical data receives a higher rating than less critical data. For example, a vulnerability in an application running in a compartmentalised virtual machine would receive a lower score than if the same application were running on a mission critical server with important customer data.

Change in baseline metrics: The values of the baseline CVSS metrics may change due to remediation actions. For example, if a server is physically disconnected from the network, a vulnerability exploitable through the network may no longer matter.