Over the last decade, many vulnerabilities were initially perceived as critical or high but later deemed less important due to different factors. One of the famous examples was the “Bash Shellshock” vulnerability discovered in 2014. Initially, it was considered a critical vulnerability due to its widespread impact and the potential for remote code execution. However, as the vulnerability was further analyzed, it was found that the severity could vary based on various environmental factors.
Vulnerability management often relies on CVSS (Common Vulnerability Scoring System) as a key component in assessing and prioritizing vulnerabilities. CVSS is a standardized framework used to assess and quantify the severity and impact of security vulnerabilities in computer systems and software.
The CVSS framework is maintained by the Forum of Incident Response and Security Teams (FIRST), an international nonprofit organization that focuses on incident response and coordination. FIRST recently announced the CVSS 4.0 Public Preview with a target official publication date of Oct. 1, 2023.
In the version, FIRST tried to reinforce the concept that CVSS is not just the Base score and considered additional factors. Let’s discuss what the key changes in CVSS 4.0 are.
Here is a list of highlighted changes:
- Introducing a new level of granularity with Added Base Metrics and Values
- Clearer Insight into Vulnerability Impact: Assessing Effects on Vulnerable and Subsequent Systems
- Simplifying the Threat metrics to focus only on Exploit Maturity
- Introducing a New Supplemental Metric Group for Enhanced Extrinsic Attributes
CVSS 4.0: New Base Metrics and Values
What are the Base Metrics?
The Base metric group represents the intrinsic qualities of a vulnerability and provides a fundamental assessment of its severity. The Base metrics help determine the initial severity score for a vulnerability and it’s usually provided by the vendor.
In CVSS v3.1, the base metric group consisted of four main metrics, Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), and User Interaction (UI).
The CVSS 4.0 framework introduced a metric called the Attack Requirements (AT) to increase the granularity and accuracy of the scoring system.
Attack Complexity (AC) vs. Attack Requirements (AT)
AC and AT could be confusing, so let’s differentiate between them.
AC: The Attack Complexity metric assesses the level of complexity required to exploit the vulnerability. It measures steps an attacker must undertake to bypass or overcome existing security measures, such as Address Space Layout Randomization (ASLR) or Data Execution Prevention (DEP).
AT: Attack requirements encompass the necessary deployment and execution conditions of the vulnerable system that enable the successful execution of an attack. An example of attack requirements could be a specific race condition.
How will the Attack Requirements (AT) metric enhance the scoring system? Let’s see an example!
The Dirty COW vulnerability, officially designated as CVE-2016-5195, is a serious privilege escalation vulnerability that affects the Linux kernel. “Dirty COW” stands for “Dirty Copy-On-Write” and refers to a race condition flaw in the way the kernel’s memory subsystem handles certain copy-on-write (COW) operations.
Here is how this vulnerability is scored using CVSS v3.1:
The attack complexity for CVE-2016-5195 was low. This is because exploiting the vulnerability did not require complex actions or advanced skills from an attacker. In fact, it was a relatively straightforward vulnerability that could be exploited with a simple privilege escalation technique.
The missing part here is the attack requirements, since the Dirty COW vulnerability is not easy to be successfully exploited. You actually need a race condition to happen, which introduces an additional layer of complexity for attackers. This makes the exploitation more challenging and less predictable. In some cases, the success of the attack may not solely depend on the attacker, as it could require brute force or a multitude of attempts to achieve the desired outcome. In the end, attackers may not even bother trying.
Taking the attack requirements into the CVSS consideration will enhance the scoring and get a more accurate score expressing the real risk.
CVSS 4.0: Assessing Effects on Vulnerable and Subsequent Systems
In v3.1, the impact assessment was measured using the Scope (S) metric. The Scope metric is often regarded as one of the most complicated and less comprehended metrics, and it has indeed led to inconsistencies in the scoring results among different vendors.
In the new version, the scope metric is retired and replaced with the Impact Metrics that accounts for impact on both the vulnerable system and the Subsequent system.
- Vulnerable System Confidentiality (VC), Integrity (VI), Availability (VA)
- Subsequent System(s) Confidentiality (SC), Integrity (SI), Availability (SA)
CVSS 4.0: Supplemental Metric Group
What is the Supplemental Metric Group?
CVSS v4.0 introduces a new “Supplemental Metric Group.” In this group, vendors provide additional context that could be used to prioritize the remediation effort or modify the score to your environment. These supplemental metrics are optional and do not impact the final calculated score.
The usage and interpretation of this contextual information may vary in different computing environments based on the consumer’s discretion.
Here are the metrics and its definition as described by FIRST:
| Safety | The Safety metric value measures the impact regarding the Safety of a human actor or participant that can be predictably injured as a result of the vulnerability being exploited. |
| Automatable | Answers the question “Can an attacker automate exploitation of this vulnerability across multiple targets?” |
| Recovery | Describes the resilience of a Component/System to recover services, in terms of performance and availability, after an attack has been performed.
|
| Value Density | Value Density describes the resources that the attacker will gain control over with a single exploitation event. It has two possible values, diffuse and concentrated.
|
| Vulnerability Response Effort | How difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed products and services in their infrastructure. |
| Provider Urgency | To facilitate a standardized method to incorporate additional provider-supplied assessment, an optional “pass-through” Supplemental Metric called Provider Urgency has been defined.
|
How to Benefit from the Supplemental Metric Group?
For example, many vulnerabilities today have impacts outside of the traditional C/I/A. In the healthcare sector, tangible harm can occur to humans due to a vulnerability exploit. In such a case, adding context related to safety could be a game changer.
Once CVSS 4.0 becomes available, you need to ensure incorporating the supplemental metrics assessment in your vulnerability management lifecycle.
CVSS 4.0: Threat Metrics
In CVSS v3.1, we have the Temporal Score metrics that provide information about the temporal aspects of a vulnerability, such as exploit availability, remediation level, and report confidence.
In other words, it measures the aspects that are expected to change overtime and need to be updated.
This group metric has some limitations. For example, Subjectivity, the Temporal Score involves subjective judgments, such as the reliability of exploit code, the effectiveness of remediation measures, and the confidence in vulnerability reports. These judgments can vary among different assessors or organizations, leading to inconsistencies in scoring.
In v4.0, Temporal Score has been renamed to Threat Metric Group and it now includes only one metric which is Exploit Maturity. Exploit Maturity measures the likelihood that a malicious actor will attempt an attack against the vulnerable system. There are three values that can be assigned to Exploit Maturity based on the information gathered from the vulnerability management consumers:
- Attacked (A): Attacks targeting this vulnerability have been reported.
- Proof of concept (P): Proof of concept code is publicly available.
- Unreported (U): Neither attacks nor POC availability reported.
CVSS 4.0: Environmental (Modified Base Metrics)
The environmental metric group captures the specific characteristics of a vulnerability that are relevant and unique to an individual user’s environment. It is used to calculate the overall CVSS score by taking into account the specific characteristics and attributes of the target environment in which the vulnerability exists.
Let’s look at an example.
Your vulnerability scanner detected a critical vulnerability in the web application framework used in your in-store queue management system. The vulnerability is remotely exploitable with AV:N, but your application is network isolated with no internet connection.
In this case, you can modify the attack vector (MAV) to a value of Adjacent instead of Network, considering the environmental aspects.
In the future, vulnerability management vendors are likely to incorporate environmental metrics into their systems. Vendors might offer increased flexibility and customization options, allowing organizations to define and configure their own set of environmental metrics based on their specific needs, risk tolerance, and industry regulations. This flexibility would enable organizations to align the scoring and prioritization of vulnerabilities with their unique operational context.
Automation and machine learning techniques can also be leveraged to analyze and correlate environmental data. Vendors may develop algorithms that automatically identify and factor in environmental metrics, such as asset criticality, network segmentation, or user privileges. This automation would streamline the vulnerability management process and enhance the accuracy of risk assessments.
Overall, incorporating environmental metrics into vulnerability management systems will provide organizations with a more tailored and accurate understanding of their risk exposure. By considering factors specific to their operational context, organizations can prioritize remediation efforts, allocate resources effectively, and make risk-based decisions that align with their business goals and compliance requirements.
CVSS 4.0: Takeaways
The new version strongly emphasizes integrating threat intelligence and environmental metrics into the scoring process, resulting in a more realistic and comprehensive risk assessment.
You need to think about how to consume the environmental and supplemental metrics and discuss aligning with the organizational Enterprise Risk Management (ERM) process to define the environmental severities.
While specific details on how these metrics will be implemented remain unclear, it’s important to ask your vulnerability management vendor how they will incorporate the new version in their solution and how you can maximize the benefit from this CVSS release.