×

Seemplicity secures a total of $32M to bring the future of work to security teams!

Seemplicity
Read More

Decoding CVSS 4.0: Clarified Base Metrics

Since 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.

How Digital Transformation Impacts Vulnerability Management Programs… and the Solution

Global digital transformation is rapidly changing the way businesses operate. This has led to a significant increase in the attack surface, which organizations must protect. However, this can be a daunting task for organizations that are still using traditional vulnerability management tools and processes.

In this article, we will discuss the impact of digital transformation on vulnerability management and explore what a modern and automated vulnerability management solution looks like. We will also provide some resources that you can use to learn more about vulnerability management in a digitalized environment.

 

Disruptive Forces Call for Change

The technological landscape for enterprises is constantly changing and progressing. New disruptive technologies are emerging and quickly becoming an essential part of every network and security stack. So far, this has included the arrival of cloud environments, SaaS applications, microservices, APIs, and IoT devices, to name a few, with more new technologies and innovations on the horizon.

These new capabilities have revolutionized the way businesses operate, allowing business scalability, flexibility, and innovation in a cost-effective manner. However, the increasing complexity and scale of technological infrastructure have also summoned more cyber-attacks. 

It’s not just about the volume, though. These attacks are also more sophisticated and technologically advanced than ever. Therefore, enterprises are now dealing with an expanded and complex attack surface that is challenging to protect.

Organizations are constantly trying to find new and adequate ways to face these risks. One of the main strategies is by deploying a wide range of testing tools across all these new technological domains. These tools are intended to help them identify, prioritize, and mitigate the most serious risks. However, the volume of security findings is overwhelming, making the output unmanageable.

This staggering pile of results and sequential tasks increases the risk of IT burnout. IT professionals are under pressure to stay ahead of cyber threats and risks. They are constantly monitoring for threats, patching vulnerabilities, and responding to incidents. The pace and high stakes of the nature of their work lead to stress, fatigue, and, ultimately, burnout.

 

The Habitual Nature of Traditional Vulnerability Management

Why is the vulnerability management process so chaotic and stressful? Many would agree that vulnerability management is lagging behind the digital transformation revolution. The majority of vulnerability management teams still rely on outdated or semi-manual tools for managing their cyber threats and vulnerabilities. Spreadsheets, for instance, which were once a popular tool of choice for data management, are still being used to track and manage vulnerabilities. Task management solutions, such as Asana, while excellent for managing projects, are not designed to handle the complexities and nuances of vulnerability management.

This reality makes sense, to a certain extent. Organizations have a natural tendency to build processes and systems, ingrain them in the company culture, and gradually evolve them. Change is slow. Sticking with what we know is comfortable, even if it’s not the most efficient or effective solution.

 

The Need for Security Innovation

However, with rapidly accelerating technological advancements and an ever-evolving threat landscape, this habitual approach is no longer sufficient. Instead, there is a pressing need to rethink our approach to vulnerability management. The tools and processes that served us in the past may not be up to the task today. Instead, enterprises need vulnerability management solutions that are agile, automated, adaptable, and easily manageable.


What should a vulnerability management solution look like?

A helpful vulnerability management solution should offer a unified view of disparate risk information, providing a thorough overview of the organization’s security posture at any given moment.

In addition, the solution should support and encourage collaboration between the team members who handle and manage the different technological components, helping overcome the organizational silos that sometimes characterize organizations

Finally, the solution should enable the organization to oversee and manage the entire process, ensuring its continuity, accuracy, and efficacy.

Other departments already enjoy similar solutions for their domains, with tools like ServiceNow, Jira, and HubSpot. These tools have streamlined processes, enable enhanced collaboration, and encourage increased productivity. Vulnerability management also deserves a similar platform as a means for answering a similar pain.

 

Where Do We Go from Here

Testing and patching used to be enough for managing vulnerabilities. This is no longer the case. Businesses can no longer just keep up – they need to stay ahead. An expanded attack surface calls for a comprehensive digital platform and processes that follow best practices to manage the results of these tests.

Investing in digital tools for vulnerability management is not a luxury. In today’s digital era, it’s a necessity. Just like other domains have benefited from digital transformation, it’s time for remediation operations to enjoy the same. This will enable them to swiftly and effectively respond to emerging vulnerabilities at scale. By adopting a more agile, automated, and adaptable approach to vulnerability management, organizations can better protect themselves from cyberattacks in a digitalized environment.

To learn more about streamlining remediation operations, click here.