Unlocking the Power of CVSSv4: A Comprehensive Guide for Security Professionals

The article discusses the imminent release of CVSSv4, the latest version of the Common Vulnerability Scoring System, with significant updates for security practitioners. Noteworthy changes include the introduction of new metrics like CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE, modifications to fundamental metrics such as Attack Complexity and User Interaction, a shift from Temporal to Threat Metrics, safety-centric metrics considering human safety, and the addition of supplemental metrics. Tenable plans to integrate CVSSv4 into its products to enhance vulnerability management.

As the field of cybersecurity evolves quickly, staying ahead of vulnerabilities is crucial. The most recent iteration of the Common Vulnerability Scoring System, CVSSv4, is about to be released and offers security practitioners a number of noteworthy improvements. The main changes in CVSSv4 will be discussed in this article, along with Tenable’s plans to incorporate the scoring system into its products.

Consider two vulnerabilities: a local privilege escalation flaw enabling an authenticated attacker to gain administrative access to Windows workstations, and a remote code execution weakness in the SSL-VPN interface of internet-facing firewalls. While both pose serious risks, the factors influencing their exploitation, potential access granted, and organizational impact vary based on architecture and defenses. Deciding which to prioritize is a common challenge for practitioners, especially given the daily influx of 68.75 vulnerabilities, on average, as per the 2022 National Vulnerability Database.

Tenable has previously emphasized Risk Informed Vulnerability Management, crucial for exposure management and prioritizing remediation. This process starts by evaluating the core severity of a vulnerability, a task facilitated by the Common Vulnerability Scoring System (CVSS).

Evolution of CVSS

CVSS, established in 2005 by the U.S. National Infrastructure Advisory Council, quantifies vulnerability risk globally. Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS aids in comparing the risks of different vulnerabilities. The system involves a base score, which reflects the vulnerability’s technical aspects. Practitioners can then apply modifiers to account for changes in the threat landscape and the state of vulnerable targets in a specific environment. The final score, ranging from 0.0 to 10.0, helps prioritize vulnerabilities for remediation.

Key Updates in CVSSv4

CVSS, or the Common Vulnerability Scoring System, has undergone significant updates over the years, with versions 2, 3, and 3.1 marking key milestones. The latest iteration, CVSS version 4, is currently in public preview, with the final specification slated for publication on October 1, 2023.
Here are the noteworthy changes introduced in CVSSv4:

Have you heard about the latest phone OS vulnerability? People in the security field often mention a “CVSS 10,” focusing only on the base score and not fully capturing the true impact. Unfortunately, organizations frequently neglect additional metrics that provide a more comprehensive understanding of a vulnerability’s severity. In an attempt to promote the use of these metrics, CVSSv4 introduces new terms:

• CVSS-B: CVSS base score
• CVSS-BT: CVSS base + threat score
• CVSS-BE: CVSS base + environmental score
• CVSS-BTE: CVSS base + threat + environmental score

So, if someone mentions a “CVSS 10 vulnerability,” a colleague might ask, “Is that the CVSS-B score?” While the casual use of “CVSS” may persist, we encourage the professional community to adopt these additional terms for a more nuanced discussion of vulnerabilities in written contexts.

Modify the fundamental metrics

CVSSv4, the latest version of the Common Vulnerability Scoring System, brings significant changes to base exploitability metrics. In particular, two key metrics have been revamped: Attack Complexity and User Interaction.

The new metric, Attack Requirements, is introduced under Attack Complexity. When set to Present, it indicates that specific conditions must be met for exploitation, such as configuring a file transfer application for a particular protocol. If set to None, the vulnerability is considered exploitable in any state or configuration.

User Interaction, previously binary with None or Required options, now includes two distinct metrics: Passive and Active. Passive interactions are involuntary, like routine logins, while Active interactions are intentional actions by the user, such as disabling a security feature.

A notable change is the retirement of the Scope metric. CVSSv4 eliminates the concept of measuring impact beyond the scored product, addressing confusion and difficulty in measurement. Instead, the impact on confidentiality, integrity, and availability is explicitly defined as none, low, or high for both the vulnerable system and subsequent systems. Regular users of the CVSS should expect improved precision and clarity from these updates.

Shift from Temporal to Threat Metrics

The longstanding Temporal metrics, reflecting changes in both defensive and offensive aspects surrounding a vulnerability, have now been rebranded as threat metrics. These metrics have been simplified to a single option, focusing on exploit maturity with the following choices:

• Unreported: No known exploit or Proof of Concept (PoC) code is available.
• PoC: A PoC has been observed, but it has not been used to develop a reliable exploit employed in actual attacks.
• Attacked: Exploitation has been witnessed in real attacks.
• Not Defined: The metric has not been set.

This change means that the evaluation no longer considers whether a formal fix or workaround is available or if the vulnerability is confirmed by the vendor. This shift is attributed to the rise of social media, facilitating the rapid dissemination of information on vulnerabilities, exploits, and patches—a phenomenon absent during the release of CVSSv1 and v2. The need to wait for hours or days for exploit or patch confirmation is no longer a significant factor in assessing risk.

Safety-Centric Metric

In the context of the modern “network-all-the-things” approach, there’s a recognition of the growing impact of operational technology (OT) and internet of things (IoT) assets in enterprise settings. To reflect this, new metrics have been introduced to assess vulnerabilities not only in terms of their impact on machine and data confidentiality, integrity, and availability but also on human safety.

If a vulnerability’s exploitation can jeopardize human safety, the Environmental score for Subsequent System Integrity and Subsequent System Availability can be designated as Safety (S), resulting in a higher score compared to the High setting. For instance, if a vulnerability disables a fire protection system in a factory, the subsequent system availability would be set to Safety. Likewise, if exploitation causes the system to consistently report a room temperature of 72 degrees, the subsequent system integrity metric would be set to Safety.

A supplementary metric is introduced to further enhance evaluation. If a system affected by a vulnerability is designed to implement safety measures, the Safety metric can be set to Negligible (for negligible destructive consequences) or Present (for consequences above negligible). These designations align with harm classifications in the international safety systems standard IEC-61508. This addition to the system is deemed valuable, particularly for technology vendors catering to industries where safety is a paramount concern, such as manufacturing or healthcare.

Introducing Supplemental Metrics

Supplemental metrics, a novel addition to the Common Vulnerability Scoring System (CVSS), extend beyond Safety and serve as additional parameters without altering the ultimate CVSS score. These metrics provide insights into specific conditions associated with a vulnerability. The introduced metrics are as follows:

1. Safety (S): As previously explained, does the vulnerability pose the risk of causing physical harm to individuals?
2. Automatable (AU): Is it possible to automate the exploitation of the vulnerability?
3. Recovery (R): Does the system automatically recover from exploitation, does it require user intervention, or is recovery impossible?
4. Value Density (V): What is the significance of the resources accessible to an attacker post-exploitation? Are they minimal, like a set of low-privilege credentials (Diffuse), or substantial, such as access to all credentials in a directory (Concentrated)?
5. Vulnerability Response Effort (RE): What is the expected effort required to respond to a successfully exploited system—categorized as Low, Moderate, or High? This can be conceptualized in terms of time, with response efforts measured in minutes (L), hours (M), or days (H).
6. Provider Urgency (U): In instances where providers communicate vulnerability information along with a CVSS score, they can supplement it with a color-coded assessment of the vulnerability’s urgency—classified as Clear, Green, Amber, or Red.

Integration of CVSSv4 into Tenable Products

Tenable acknowledges CVSS as an industry standard and plans to support CVSSv4 in its products. While Tenable offers Vulnerability Priority Rating (VPR) scoring as an alternative metric, it recognizes the significance of CVSS and will integrate the new version into its products. Specific details about implementation are pending, awaiting the final design specification from FIRST after the public preview period.

For further information on CVSSv4 and to participate in the public preview, refer to FIRST’s page on version 4 and its presentation to the FIRST Conference. A scoring calculator for testing vulnerabilities using the public preview’s metrics is also available.

FAQs

1. How is vulnerability risk score calculated?

The vulnerability risk score is determined by considering three key factors: Technical Severity, Threats, and Tags. Vulcan calculates the final risk of a vulnerability instance by applying the risk weights that you have specified. This process incorporates scores such as CVSS or other metrics provided by the scanning vendor, ensuring a comprehensive and business-contextualized assessment of the vulnerability’s risk.

2. How is CVSS score calculated?

The CVSS score is determined through a formula that incorporates metrics related to vulnerabilities. The score is divided into three groups: Base, Temporal, and Environmental. The scale ranges from zero to 10, where zero indicates the least severe and 10 signifies the most severe level of vulnerability.

3. Is vulnerability management same as risk management?

In simple terms, vulnerability management focuses on identifying gaps or vulnerabilities in your IT and network infrastructure. On the other hand, risk management adopts a comprehensive approach, analyzing the entire business to identify areas of highest risk where potential threats could inflict the greatest degree of damage.

Get Giveaway every day!