Finding Risk: Introducing Remediation Operations
Read NowSince 2005, the Common Vulnerability Scoring System (CVSS) has been used to assess and communicate the severity of vulnerabilities in software. If you’re involved in cybersecurity, even if you’re not directly involved in managing vulnerabilities, you’ve probably come across CVSS designations like ‘critical’ or ‘high’ when referring to vulnerabilities in the industry. Initially developed by the Forum of Incident Response and Security Teams (FIRST), CVSS provides security professionals with a consistent framework for evaluating and prioritizing vulnerabilities. CVSS has since achieved widespread acceptance, even being adopted by the NIST National Vulnerability Database (NVD).
The previous version, CVSS v3.1, had been in use since 2019, but it faced its fair share of criticism due to its complexity and lack of flexibility. On November 1st of 2023, FIRST introduced CVSS 4.0, a substantial update that offers a more adaptable, and more accurate scoring system. This latest version aims to deliver a more accurate representation of severity and aids organizations in prioritizing vulnerabilities so they can allocate resources more effectively.
In this blog, we’ll examine the Base Metric Group modifications introduced in CVSS 4.0. We’ll highlight what you need to know, and how it might impact usage and implementation of CVSS scores in your security environments.
Changes to the Base Metric Group in CVSS 4.0
New Exploitability Metric
Exploitability metrics–which measure how hard a vulnerability is to exploit–have been affected in CVSS 4.0 with the addition of a 5th Exploitability Metric, “Attack Requirements (AT)”. This metric captures the prerequisite deployment and execution conditions of the vulnerable system that enable the attack.
(Full CVSS 4.0 metrics outlined at https://www.first.org/cvss/v4.0/specification-document)
Attack Requirements (AT):
| Metric Value | Description |
| None (N) | The successful attack does not depend on the deployment and execution conditions of the vulnerable system. |
| Present (P) | The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. |
If an attacker fails to address or overcome these conditions, the attack may fail entirely. The Attack Requirements (AT) metric offers organizations a more contextual understanding of vulnerability severity and does a better job at helping organizations gauge the potential risks associated with their systems and environments.
Changes to the User Interaction (UI) Metric
These new changes allow for additional granularity when considering the interaction of a user with a vulnerable component. They describe the level of interaction required by a user for an attack to be successful. The previous metrics for User Interaction were: None, Required, and Unspecified. The CVSS 4.0 metrics describing “Passive” or “Active” add a lot more granularity in analyzing user interaction than the previous version.
CVSS version 4.0 changed the User Interaction metric values to the following:
| Metric Value | Description |
| None (N) | The vulnerable system can be exploited without interaction from any human user, other than the attacker. |
| Passive (P) | Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable system and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable system. |
| Active (A) | Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable system and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability. |
The “Scope”Metric was Removed
Introduced in CVSS v3.0, “Scope” was an unpopular and confusing metric, leading to inconsistencies in scoring and providing an incomplete representation of the impact on both vulnerable and affected systems. To address this, impact metrics were divided into two distinct sets. The first set covered the confidentiality (VC), integrity (VI), and availability (VA) of the vulnerable system. The second set encompassed the confidentiality (SC), integrity (SI), and availability (SA) of subsequent systems, referring to systems that are made vulnerable as a result of the initial exploit. This refinement enables a more precise evaluation of the impact, ensuring a more accurate and comprehensive assessment of the potential consequences of vulnerability exploitation
“Subsequent Systems” Impact Metrics
To address the issues with the “Scope” metric,CVSS 4.0 introduced the “Subsequent Systems” metrics, which add a more refined assessment of the impact of vulnerability exploitation, due to the separation of vulnerable systems versus subsequent systems. As a result, there are essentially 3 new impact metrics added to the Base Metric Group.
1. “Subsequent System Confidentiality” measures the extent to which the confidentiality of data in interconnected systems may be compromised in the event of successful exploitation.
| Metric Value | Description |
| High (H) | There is a total loss of confidentiality, resulting in all resources within the Subsequent System being divulged to the attacker. |
| Low (L) | There is some loss of confidentiality. The information disclosure does not cause a direct, serious loss to the Subsequent System. |
| None (N) | There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System. |
2. “Subsequent System Integrity” assesses the integrity (trustworthiness and veracity) of data and processes in these systems after an exploitation event.
| Metric Value | Description |
| High (H) | There is a total loss of integrity, or a complete loss of protection. |
| Low (L) | Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Subsequent System. |
| None (N) | There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System. |
3. Lastly, “Subsequent System Availability” focuses on the availability of services and resources after a successful attack, factoring in potential disruption to or consumption of bandwidth, processor cycles, or disk space.
| Metric Value | Description |
| High (H) | There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Subsequent System. |
| Low (L) | Performance is reduced or there are interruptions in resource availability. The resources in the Subsequent System are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the Subsequent System. |
| None (N) | There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.By incorporating these new Subsequent Systems metric values, CVSS 4.0 provides a more detailed and nuanced analysis of how a vulnerability’s exploitation can impact not only the primary system but also the wider network, assisting organizations in making more informed decisions regarding their cybersecurity strategies and risk management. |
By incorporating these new Subsequent Systems metric values, CVSS 4.0 provides a more detailed and nuanced analysis of how a vulnerability’s exploitation can impact not only the primary system but also the wider network, assisting organizations in making more informed decisions regarding their cybersecurity strategies and risk management.
Nomenclature changes
Base scores can now be further refined by the addition of Threat (previously referred to as “Temporal”) and Environmental Metrics. We won’t get into the impact of changes to Threat and Environmental metrics in this blog, but for our examination of 4.0 changes to the Base Metric Group, it’s important to note that this is changing the way that CVSS scores will be used and conveyed going forward.
| CVSS Nomenclature | CVSS Metrics Used |
| CVSS-B | Base metrics |
| CVSS-BE | Base and Environmental metrics |
| CVSS-BT | Base and Threat metrics |
| CVSS-BTE | Base, Threat, Environmental metrics |
Each CVSS score using version 4.0’s guidelines should use these naming conventions, which will inform analysts of the methodology used to generate the resulting scores. It’s important to note that the addition of Environmental and Threat metrics will be the responsibility of individual CVSS consumers for now, as many assessment providers and public/private entities like the National Vulnerability Database only provide the CVSS-B scores. The adoption of CVSS 4.0 will be a gradual process that will take time, and entities like the NVD are not currently using it and aren’t expected to anytime soon.
Why does this matter?
Although it’s early to assess how organizations are handling version 4.0 changes to CVSS base scoring, it’s going to make a noticeable impact on how the standard is used going forward. My initial impression is that CVSS 4.0 changes will have the following effect for users:
New Attack Requirements (AT) Metric – Informs users if pre-existing conditions are required for a system’s vulnerability to be exploited. This new metric addresses an issue with CVSS v3 where vulnerabilities would get a critical score but didn’t pose a real risk to most organizations, since the required specific configuration was very rare.
User Interaction (UI) Metrics Changed – The previous metrics were subjective, which led to inconsistent scoring. Now that the metrics are clear, scoring should be more consistent. The CVSS 4.0 metrics describing “Passive” as opposed to “Active” add a lot more granularity in analyzing user interaction than the previous version.
“Scope” Removed – It was removed due to complexity, and it lacked a good way of distinguishing severity of impact to the vulnerable system as opposed to subsequent systems. As a result, a non-zero percentage of security analysts will rejoice, as they no longer need to decipher what exactly this meant for each vulnerability.
Separated Impact of Vulnerable and Subsequent Systems – This provides separate descriptions of impact for the two, which allows for a more targeted approach to mitigation efforts. Separate or additional measures can be taken to protect subsequent systems if deemed necessary.
Nomenclature Changed – This makes it simple to tell which metrics were provided in the generation of a CVSS score. This will help users compare scores correctly, an apples-to-apples comparison rather than apples-to-oranges. In the long run, it will save practitioners time and avoid duplication of effort.
How does the new CVSS Base Scoring Address Past Criticisms?
Previous Criticisms:
- Too subjective
- Lack of context
- Inconsistent scoring
Improvements
CVSS 4.0 makes good progress in addressing the criticism of being too subjective in its scoring. The elimination of the “Scope” metric and addition of impact metrics to subsequent systems are prime examples, simplifying the assessment process by providing a clearer separation of the impact on vulnerable systems versus subsequent systems. Also, the distinct metrics used to define “User Interaction” facilitates more consistent and accurate vulnerability assessments.
Regarding the criticism that there was a lack of context, version 4.0 introduces the Attack Requirements (AT) metric. This metric provides useful contextual information about required conditions for a system’s vulnerability to be exploited. This additional layer of information contributes to a more comprehensive risk assessment, aligning the CVSS scoring system more closely with the nuanced realities of different organizational contexts and configurations.
To help tackle the issue of inconsistent scoring, CVSS 4.0 now has the new naming conventions to indicate which metrics were used to generate the score. It is clear that a CVSS-BTE score is different from a CVSS-B score, fostering transparency and helping practitioners interpret vulnerability assessment results. By making the scoring process more transparent and accessible, CVSS 4.0 addresses concerns about variability in scoring and fosters a more standardized and comprehensive approach to vulnerability management.
Conclusion
The changes to the Base Score metrics in CVSS 4.0 appear to be a solid leap forward in addressing criticisms to previous vulnerability scoring. CVSS 4.0 streamlines the scoring process, fixing key issues related to subjectivity. It offers more relevant context around vulnerabilities, and the new naming conventions make the scoring process more transparent and accessible. Collectively, these advancements position CVSS 4.0 as a more refined and comprehensive framework, equipping security practitioners with better tools to make informed decisions in the dynamic landscape of cybersecurity.
SHARE THIS ARTICLE 
