Measuring the severity of vulnerabilities: changes in CVSS 3.1

So far, version 3.0 of the CVSS (Common Vulnerability Scoring System) framework was the last one published by the organisation responsible for its creation, the FIRST (Forum of Incident Response and Security Teams). This open reference framework establishes metrics for the communication of the characteristics, impact and severity of vulnerabilities that affect elements of the IT security environment. In the INCIBE-CERT blog we have already published a CVSS 3.0 entry explaining the metrics and equations of that version, and comparing it with the previous one, in that case, with version 2. Now we review the changes to the recently published version 3.1 compared to its predecessor.

Main changes to CVSS 3.1 compared to CVSS 3.0

Version 3.1 does not introduce new metrics or values or make significant changes to existing formulas with respect to the previous version, but instead focuses on clarifying and improving the existing standard. The most significant modifications are explained below:

CVSS measures severity, not risk

This version highlights that the CVSS is designed to measure the severity of a vulnerability and, therefore, must not be used as the only tool to assess risk. The CVSS v3.1 specification document now clearly states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability that are constant over time and are common to different user environments. To carry out a systematic risk analysis, this base score must be complemented with a contextual analysis taking advantage of the temporal and environmental metrics, and with other external factors not considered by the CVSS as exposure and threat.

Changes in Attack Vector and Modified Attack Vector

The descriptions of the values (Network, Adjacent, Local and Physical) of the Attack Vector (AV) metric are reformulated to make them more familiar to CVSS suppliers and general consumers, avoiding references to the OSI model. A guide section for the use of this metric is also included when resources are behind a firewall.

The value Adjacent (A) of the Attack Vector (AV) metric, of the Base Score group of metrics, as defined in CVSS 3.0 caused ambiguity in the case of logically adjacent or trusted networks (MPLS, VPN, etc.). To address this inaccuracy, the definition of Adjacent is extended, including these limited access networks.

Changes in the scoring guide

The specification document and the user guide have been updated to help CVSS analysts perform consistent and defensible scores in various situations that could be ambiguous before, including:

• The specification document has been updated to clarify that, by scoring Base Metrics, it should be assumed that the attacker has advanced knowledge of the weaknesses of the target system, including general settings and default defence mechanisms.
• It is clarified that when scoring the impact metrics of a vulnerability, only the negative consequences that are the result of a successful exploitation (for example, the increase in the level of access or the new privileges obtained) on the vulnerable or impacted component, the one that suffers the worst result should be considered. This change has to be scored in the Impact Metrics (Confidentiality, Integrity and Availability). If there has not been a change in the Scope, the impacts of Confidentiality, Integrity and Availability reflect the consequences for the vulnerable component, otherwise, they reflect the consequences for the component that suffers the greatest impact.
• In the explanation of the Attack Complexity metric the ambiguous text was deleted: “the presence of certain system configuration settings”. If a specific configuration of the vulnerable component is required for an attack to be successful, it should be scored assuming that it has that configuration, provided that this is an appropriate configuration (configurations that are explicitly contraindicated should not be used).
• The explanation of the metric Scope of the specifications document and the concepts of Vulnerable Component and Impacted Component are reformulated to clarify them. A section is added in the user guide with examples.

- Scope metric score diagram. Source: CVSS 3.1 user guide. -

• The new guide explains how to rate the impact of a vulnerability in libraries and the like. Given the analyst's difficulty in knowing the ways in which a library can be used, it must presuppose the worst scenario of reasonable implementation and detail these assumptions when possible.
• This new guide explicitly allows you to generate multiple CVSS Base Scores scores for a vulnerability that affects multiple versions of products, platforms and operating systems.
• The Environmental Metrics Group, includes three security requirement metrics:
  • Confidentiality Requirement (CR), which is based on the classification of data (public, internal use, confidential...) stored or used by applications running on the target system, bearing in mind that if they are encrypted, this requirement lessens.
  • Integrity Requirement (IR), which focuses on the importance of the accuracy of the data it stores or uses. This requirement is not considered if the data passes without being consumed through the target system. Encryption must not be taken into account.
  • Availability Requirement (AR), which is based on the redundancy and uptime requirements of the device or the applications it hosts. If there is redundancy this requirement will be low.

Guide to scoring Attack Vector: considerations

When scoring the Attack Vector metric, the Adjacent or Network value must be used, as appropriate, whenever a network connection is required for an attack to succeed, even if the attack is not launched through a network. For example, when a local program with privileges is tricked into sending sensitive data over a network.

Vulnerabilities in which malicious data is received through a network by a component and then passed to another separate component with a vulnerability must be scored with a Local Attack Vector. For example, a browser that downloads a malicious Office document, stores it on disk and starts an Office application that reads it.

In cases where vulnerable functionality is part of the component that receives malicious data, the Attack Vector must be classified as Network. For example, a browser with its own vulnerability or a plug-in or extension that starts when it receives malicious data.

The CVSS extension framework

A standard method is defined to extend the CVSS and include additional metrics and groups of metrics, while retaining the official metric groups Base, Temporary and Environmental. The additional metrics allow industrial sectors related to privacy, security, health, automotive, etc., to rate factors that are outside the basic CVSS standard.

Changes in formulation

The formulas used to calculate the Base, Temporary and Environmental scores have been modified in the following ways:

• The formulas have been restructured to make them clearer and eliminate the ambiguity caused by the definition of the impact sub-score for different purposes. These are only clarifications and do not alter the score.
• The Round up function of CVSS 3.0 has been renamed Roundup in CVSS 3.1 and is now more precisely defined to minimize the possibility of implementations generating different scores due to small floating-point inaccuracies. This may happen due to differences in floating point arithmetic between different programming languages and hardware platforms.
• In CVSS 3.0, certain sets of Environmental metrics have the counterintuitive property that changing the Security Requirement or Modified Impact metrics to values that should produce a higher Environmental Score results in a lower score. The problem only occurs if Modified Scope is changed and at least one of the Security Requirements metrics is High. This is solved by entering a constant in the Modified Impact formula that is used when modifying the Modified Scope.

Version Identifier update in the Vector String representation

Vector String (compressed text representation of the values used to obtain the final score) is updated so that it starts with CVSS:3.1 instead of with CVSS:3.0. The Vector String representation is as follows:

- Vector String representation. Source: CVSS 3.1 user guide. -

This Vector String is also obtained, in addition to the final score, from the CVSS 3.1 calculator of the FIRST.

Since its initial launch in 2004, CVSS has enjoyed wide acceptance. In September 2007, CVSS v2.0 was adopted as part of the Payment Card Industry Data Security Standard (PCI DSS). In 2007, the National Institute of Standards and Technology (NIST) included CVSS v2.0 as part of its Security Content Automation Protocol (SCAP). In March 2016, CVSS v3.0 was formally adopted as an international standard for rating vulnerabilities (ITU-T X.1521).

The user guide complements the document of specification of the Common Vulnerability Scoring System (CVSS) version 3.1, with additional information that includes the most significant changes with respect to version 3.0 of CVSS. It is expected that at the end of 2019 the course for this new version will be available on the FIRST platform.