Measuring the Severity of Vulnerabilities: Changes in CVSS 3.1

Common Vulnerability Scoring System (SVSS) version 3.0 framework was the last one that was published by the organization responsible for creating it. It was created by the Forum of Incident Response and Security Teams (FIRST). 

This open reference framework creates metrics for the communication of the impact, characteristics and severity of vulnerabilities that affect elements of the IT security environment. In this article, we will 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 values, metrics or make vital modifications to existing formulas with respect to the older version. However, it focuses on enhancing and clarifying the existing standard. The most important changes are explained below:

CVSS Measure Severity, Not Risk

This version highlights that the CVSS is created to measure the severity of a vulnerability and may not be used as the only tool needed to evaluate risk. The CVSS v3.1 specification document clearly states that the CVSS Base Score represents only the fundamental characteristics of a vulnerability that are constant over time and are common to different user environments. 

To carry out a systematic analysis, this base score must be complemented with a contextual analysis by taking advantage of the temporal and environmental metrics. Other external factors will not be considered by the CVSS as threats and exposure. 

Changes in Attack Vector 

The description of the values (Adjacent, Network, Local and Physical) of the attack vector (AV) metric are reformulated to make them more known to CVSS general consumers and suppliers, 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 uncertainty in the case of logically adjacent or trusted networks (VPN, MPLS, etc.). To address this inaccuracy, the definition of adjacent is extended, including these limited-access networks.

Modifications in the Scoring Guide 

The specification document and the user guide have been updated to assist CVSS analysts to perform defensible and consistent scores in different situations that could be ambiguous before which include:

• The specification document has been updated to explain that, by scoring base metrics, it should be assumed that the attacker has knowledge about the weakness of the target system which includes default defense mechanisms and general settings. 
• It’s clarified that when scoring the impact metrics of a vulnerability, only the negative consequences which are the result of successful exploitation on the impacted or vulnerable component, the one that suffers the worst result must be considered. 
• In the explanation of the attack complexity metric, the ambiguous text was deleted. If a particular configuration of the vulnerable component needed for an attack to be successful, it should be scored based on the assumption that it has that configuration, as long as it’s a suitable configuration.
• The explanation of the metric score of the specifications document and the concepts of vulnerable component and impacted component are reformulated to clarify them.

The Environmental Metrics Group includes three security requirement metrics:

• Confidentiality Requirement (CR): This is based on the classification of data (internal use, confidential and public) stored or used by applications running on the target system, bearing in mind that if they are encrypted, this requirement lessens.
• Integrity Requirement (IR): This 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): This is based on the uptime and redundancy requirements of the device or the applications it hosts. If there is redundancy this requirement will be low.

Guide to Scoring Attack Vector

When scoring the attack vector metric, the network or adjacent value must be used, suitably, whenever a network connection is needed for an attack to succeed, even if the attack is not launched through 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 instance, 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 that starts when it receives malicious data.

Modifications in Formulation

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

• The formulas have been restructured to make them clearer and eradicate the ambiguity that is caused by the definition of the impact sub-score for different purposes. These are only clarifications and do not modify the score.
• The roundup function of CVSS 3.0 has been renamed roundup in CVSS 3.1 and is now more specifically defined to reduce 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 to values that should produce a higher environmental score results in a lower score. The problem only occurs if the 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.

Since its initial launch in 2004, CVSS has enjoyed wide acceptance. In September 2007, CVSS v2.0 was adopted as part of the PCI DSS (Payment Card Industry Data Security Standard). 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.

Photo by Fleur on Unsplash