The new version (3.0) of the CVSS vulnerabilities scoring system

Foreword

"CVSS" (Common Vulnerability Scoring System) is a system allowing to compute a score assessing the criticality of a vulnerability, and to build a string (a vector) that reflects the feature of this vulnerability, and the values used to derive the score.

.CVSS version 1.0 was created in February 2005 and CVSS version 2.0 was officially released in June 2007,
CVSS version 3.0 is available since May 28, 2015.

Since 2003, the Cert-IST has been assessing the vulnerabilities criticity with the EISPP metric. At the end of 2007, it set up a gateway between the EISPP and CVSS metrics in order to include the CVSS score in its vulnerability database.

We have already released several articles on this vulnerabilities Scoring System (in April 2005 and June 2005 on CVSS v1.0, and on February 2008 on CVSS v2.0) the purpose of this article is not to make a complete overview of this system, but to present the changes in version 3.0 compared to version 2.0.

Main features

CVSS scores and vectors are still the result of three metrics groups (Base, Temporal and Environmental). Each group produces its score and its vector:

• The "Base" group evaluates the maximum theoretical impact of the vulnerability.
• The "Temporal" group is derived from the "Base" group in such a way to reflect the characteristics of a vulnerability that changes over time (i.e. availability of a functional exploit or of a patch).
• The "Environmental" group is derived from the "Temporal" group in such a way to reflect the characteristics of a vulnerability that are specific to an environment.

Each group has metrics allowing to compute a numeric score associated with the vulnerability risk.

There is no change on these general features.

Note: Cert-IST evaluates only the base group and the temporal group. The environmental group cannot be assessed when issuing a security advisory because it is related to a specific organization (a specific information system). This article therefore focuses only on the two CVSS groups: the Base group and the Temporal group.

The base group metrics evolution

Attack Vector

The "Access Vector" (AV) metric has been renamed to "Attack vector". It still reflects the remoteness of the attacker relative to the vulnerable component, with the idea that the more remote an attacker is to the vulnerable component, the more critical the vulnerability is.

For this metric, CVSS v3.0 uses the same possible values as v2.0 (Network, Adjacent Network, Local), but adds a fourth one: Physical (P).
It allows to distinguish between local attacks which require local system access and physical attacks which require physical access.

Attack Complexity & User Interaction

The "Access Complexity" (AC) metric has been separated into two metrics:

• "Attack Complexity" (AC) measures the complexity depending on conditions (hardware, software, network) that must exist in order to exploit the vulnerability.
•  "User Interaction" (UI) indicates if the vulnerability exploitation requires that a user, other than the attacker, must perform some action.

 The possible values of this metric are None (N) or Required (R).

Authentication

The "Authentication" (A) metric has been replaced by "Privileges Required" (PR).
The idea is to consider the level of authentication (none, low, high) required to exploit the vulnerability, rather than the required number of authentication.
The possible values of this metric are None (N), Low (L), High (H).

Scope

A new standard was created in order to consider cases where the vulnerability of a software component has an impact on resources located beyond the perimeter of this component.
This metric is the « Scope » (S) and its possible values are Changed (C) and Unchanged (U).
Some typical cases of scope change are:

• A vulnerability in a virtualized guest system, which has an impact on the host system.
• A vulnerability in a software running in a sandbox , which has an impact outside this sandbox.
• A Cross-site scripting vulnerability allowing to use a vulnerable system as a bounce, to attack another system.

This metrics allows to assign a higher score to a vulnerability allowing to impact resources beyond the scope of the vulnerable component (intuitively it seems normal that a malicious action on a host system is more critical than the same action on a guest system).

Impacts

"Confidentiality Impact" (C), "Integrity Impact" (I), and "Availability Impact" (A), the metrics related to the vulnerabilities impact, have been slightly modified.
The possible values of these metrics, which were None (N), Partial (P), and Complete (C) have been replaced by None (N), Low (L), and High (H).
The idea is to assess the severity degree of an attack rather than the proportion of the affected system.
For example, a vulnerability allowing to steal credentials, could have a Confidentiality metric to "Partial" with CVSS v2, then it will be rather to "High" with CVSS v3.

The temporal group metrics evolution

This metrics group has been very slightly modified . The "Exploitability" metric has been renamed "Exploit code maturity" in such a way to better reflect what this metric is measuring.

However, the influence of these metrics has been reduced in CVSS v3.0: the coefficients associated with these metrics, for computing the temporal score are closer to 1, providing a temporal score closer to the base score.
Concretely this means giving less influence to the release of a functional exploitation program, or to the lack of patches.

Rating scale

Some users created systems to map CVSS v2.0 base scores to qualitative ratings.

CVSS v3.0 provides the following table to map a numeric score to a qualitative rating:

Score	Rating
0.0	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

 

This table can be applied to the three CVSS v3.0 score (Base, Temporal, Environmental).

The use of these qualitative severity ratings is optional, and there is no requirement to include them when publishing CVSS scores.
This severity rating is displayed with the FIRST official CVSS calculator result.

Multiple vulnerabilities scoring

CVSS is designed to rate individual vulnerabilities. A CVSS score or vector is associated with a single vulnerability. It may however be interesting to assess the risk of an attack chaining the exploitation of several vulnerabilities.

Let’s take the example of two vulnerabilities A and B.

The A vulnerability allows an authenticated user to illegally obtain administrative privileges on the system where it is identified.
The A vulnerability CVSS vector and score are as follow:
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - 7.8 (High)

The B vulnerability allows an unauthenticated remote attacker to execute arbitrary code on a vulnerable system with limited privileges (the connected user privilege).
The B vulnerability CVSS vector and score are as follow:
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L – 6.3 (Medium)

Unlike the previous versions of CVSS the 3.0 version allows to associate a note and a vector to an attack chaining the exploitation of  the B vulnerability (code execution without authentication), with exploitation of the A vulnerability (elevation privilege). This attack would allow an unauthenticated remote attacker to take the full control of the vulnerable system:
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H – 8.8 (High)

CVSS v3.0 therefore allows the evaluation of attacks based on the exploitation of several vulnerabilities (Vulnerability Chaining).
This new version does not provide a formal metric, but is included as guidance for analysts when scoring these kinds of attacks.

Conclusion on the CVSS v3.0 contributions

Two new metrics allow to take into account significant aspects that had no impact on previous CVSS versions:

• The Scope metric allows to qualify the assessment, for example between a guest system take control, and the host system take control.
• The "User Interaction" allows to qualify the assessment of a vulnerability that requires the action of a victim.

Adding the "Physical" value to the "Access Vector" metric allows to distinguish the case of attacks which require local access to that which require physical access.

Authentication is evaluated in terms of level of privileges, rather than in terms of the number of authentication.

Impacts are evaluated in terms of risk, rather than in terms of percentage of impact.

A qualitative rating scale is defined with a standard mapping from numeric scores to the severity rating terms.

Scoring multiple vulnerabilities used in the same attack is allowed.

The influence of Temporal metrics has been reduced.

Documentation

CVSS v3.0 user guide:
https://www.first.org/cvss/user-guide

CVSS v3.0 specifications:
https://www.first.org/cvss/specification-document

CVSS v3 calculator:
 https://www.first.org/cvss/calculator/3.0