Post Syndicated from Devin Krugly original https://blog.rapid7.com/2023/08/14/whats-new-in-cvss-v4/

The pending update to the Common Common Vulnerability Scoring System (CVSS), version 4.0, has garnered a noticeable volume of articles, blog posts and watercooler (now known as Slack and Zoom) air time. Reaction from the community has been positive, with general sentiment pinned somewhere near “practical.”

CVSS provides a standardized method for evaluating the potential severity (and in many cases impact) of a vulnerability so organizations can make informed decisions about how to respond to specific security issues. Its fundamentals have been widely adopted by vendors, researchers, academics, and vulnerability analysts.

The standard has been improved over time with the release of v1 in Feb. 2005, v2 in June 2007, and v3 in June 2015. The current version (v3.1) debuted in June 2019. Version 4 is slated for release on October 1, 2023.

So, what’s new in CVSS v4?

CVSS v4 ushers in some meaningful improvements wrapped in a bit of nuanced complexity, especially if you’re a vendor or threat researcher responsible for providing base scores. As far back as CVSS v1, the standard has recognized that things like time, value of the target, exploit activity, and specific operating environment all influence the amount of risk associated with a unique vulnerability. A balance between completeness and ease of use has been sought in development of more recent CVSS versions.

Temporal and Environmental Metrics were intended to provide business context to help influence tradeoff decisions. However, these metrics were “optional” in v3, and adoption stagnated and never really grew beyond use of Base Metrics. Reality reflects this observation partially due to the score subjectivity stemming from assessor interpretation(s), human bias, but most importantly the fact that calculating “optional” metrics requires resources and time that organizations might invest in other areas.

The following summary is presented in sequence across each of the scoring systems v4 groups:

Base Metric Groups and Definitions

Greater precision and accuracy by introducing four (4) groups where only one group has been in practical use until now. The specification document also emphasizes that Base Metrics, provided by vendors and researchers, represent intrinsic qualities. Threat and Environmental groups, which provide business and situational context are intended to be, and can only be, provided by end user organizations.

• Clarity that CVSS-B is designed to measure the severity of a vulnerability and should not be used alone to assess risk, while CVSS-BTE much more closely approximates risk.
• CVSS-B – Base metrics plus….. [what’s commonly used today and composed of the Base Metric Group]
• CVSS-BT – Base and Threat Metrics
• CVSS-BE – Base and Environmental Metrics
• CVSS-BTE – Base, Threat, Environmental metrics
• more on the Supplemental Metric Group later

Figure 1. CVSS v.4 Metric Groups, FIRST.org (2023)

Exploitability Metric provides clarification to improve upon the often cited lack of granularity

• Attack Vector (physical/logical location) – {Network, Adjacent, Local, Physical}
• Attack Complexity (consideration for mitigating controls) – {Low, High}
• Attack Requirements (dependencies for exploit/attack to be successful) – {None, Present},
• Privileges Required (needed prior to attempted exploit) – {None, Low, High}
• User Interaction (is participation necessary) – {None, Passive, Active}

Impact Metric clarification that Impact measures consequences post attack, also intended usage guidance (with examples) and consideration for Vulnerable (primary) and Subsequent (secondary) Systems across Confidentiality (C), Integrity (I) and Availability (A) dimensions to improve application and usage, these measures replace the often criticized and misused Scope metric in v3.x.

• Vulnerable System Confidentiality (data disclosure beyond authorized users) – {High, Low, None}
• Vulnerable System Integrity (loss of trust or accuracy of the data) – {High, Low, None}
• Vulnerable System Availability (loss of accessibility to compute resources) – {High, Low, None}
• Subsequent System Confidentiality (data disclosure beyond authorized users) – {High, Low, None}
• Subsequent System Integrity (loss of trust or accuracy of the data) – {High, Low, None}
• Subsequent System Availability (loss of accessibility to compute resources) – {High, Low, None}

Threat Metric Group and Definition

Previously called Temporal Metrics in v3.x, Threat Metrics are intended to provide the ‘likelihood’ of a particular CVE being attacked, there are three (3) components which should be assessed in deriving a “Exploit Maturity” value {Not Defined, Attacked, Proof-of-Concept, Unreported}, responsibility for which lies with the affected organization.

• Current state of exploit techniques (ex. consider advances with ML alongside the Mitre ATT&CK TTPs)
• Exploit code availability (ex. is there a POC on Github)
• Active, observable exploitation (ex. what’s the threat analyst or your TIP tell you)

Environmental Metric Group

Like the Threat Metric Group, this set of assessments is intended to be derived by the affected organization and allow an analyst to further tailor any one CVSS score for the use case of the affected asset/system. We return to the security fundamental  ‘CIA Triad’ as the measures to modify or tailor the overall CVSS v4 score(s).

• Confidentiality | Integrity | Availability Requirement – {Not Defined (insufficient information to choose value), High (catastrophic adverse effect), Medium (serious adverse effect), Low (limited adverse effect)}

Modified Base Metrics within the Environmental Group are intended to codify “mitigations” which may be in place for any vulnerability OR capture instances where the risk is greater due to a lack of expected controls – for example an administrative UI exposed to the internet.

Accommodation for Safety (human safety) where exploitation may result in injuries or worse.

Supplemental Metric Group

An entirely new group of optional measures to accommodate a wide spectrum of extrinsic factors that can influence risk decisions including consideration for

• Automatable (can an attacker automate exploitation en masse) – {Not Defined, No, Yes}
• Recovery (ability for a system to resume performance and availability after an attack) – {Not Defined, Automatic, User, Irrecoverable}
• Safety (degree of impact for predictable injury using IEC 61508 Consequence Categories) – {Not Defined, Present, Negligible}
• Value Density (level of resources attacker will gain after a single exploit) – {Not Defined, Diffused, Concentrated}
• Provider Urgency (supplemental urgency rating, available to any supplier in the chain) – {Not Defined, Red, Amber, Green, Clear}
• Vulnerability Response Effort (supplemental information to suggest level-of-effort (LOE) involved in remediation/mitigation) – {Not Defined, Low, Moderate, High}

That concludes this summary of changes pertaining to the metrics used to derive and supplement a CVSS v4 score. There are also several functional accommodations that have been made including:

• Vector String updates to accommodate all the revised metric definitions and versioning, which may be a bit unwieldy in practical use for some, but machine readable has extensible value – get your decoder rings ready (ex. CVSS:4.0/AV:P/AC:H/AT:P/PR:H/UI:N/VC:L/VI:H/VA:N/SC:N/SI:H/SA:L/S:P/R:U/RE:M/U:Clear/MAV:A/MAT:P/MPR:N/MUI:A/MVC:H/MVI:L/MVA:N/MSC:H/MSI:L/MSA:N/CR:H/IR:M/AR:L/E:P) [Check out the Interactive Caclulator]
• Qualitative and quantitative improvements to create greater vuln score distribution and score results, improvements to underlying equations to generate scores
• Accommodation for unique Base Scores for multiple product versions, platforms and/or OS (operating system)
• Guidance to baseline Software Vulnerabilities at ‘reasonable worst-case’ implementation scenario and remove confusion regarding software library effects, for example
• Stronger advocacy to correlate data from both asset management and vulnerability management systems, whenever possible, to drive adoption and use of all four (4) metric groups, similarly to better incorporate and optimize the use of threat intelligence
• and, finally consideration for transitional support so a single vulnerability may accommodate use of both v4.0 scores and current v3.1 scores.

Day to day impacts

I wouldn’t anticipate the calculation and LOE to derive a CVSS-B (Base Metric) score to significantly increase, but the thought process and underlying analysis sequence will require some updates to existing processes. The bulk of the Base Metric procedural updates will fall to the usual suspects and host of vendors. The more interesting impacts will affect the security teams and vulnerability analysts. It isn’t provocative to suggest that operationalizing the optional metrics, both in v3.x and in the current proposal, could require a pretty heavy lift. Consider the effort a vuln analyst would need to invest on a typical Patch Tuesday to derive Threat Metrics and Environmental Metric groups for every relevant CVE. Doing so for every new vuln and derivation for each Patch Tuesday could easily bleed into the next patch cycle, so automation using enterprise grade vuln management solutions like Rapid7 IVM will continue to be a necessity to facilitate efficient vuln response at scale.

The preceding scenario is precisely the rationale behind the development and release of Rapid7’s new risk scoring model. It will deliver on many of the core tenets of risk-assessment systems including the flexibility to accommodate organizationally specific factors like those defined under Threat and Environmental Metric Groups business to provide teams with a prioritized list of remediation targets.

Summary

While perceptually complex, as proposed CVSS v4 is a meaningful, well researched and structured framework to advance the discipline of vulnerability management. As many have opined, there is room for improvement in the, now old enough to drive, scoring system and in the cybersecurity’s rigor and practical use of all that is considered in the v4 User Guide.

It will be interesting to understand the community’s reaction towards adoption both in scale and complexity—all at once “big bang” approach or incremental change over a longer time horizon. Also, how much of the new system is adopted in practice. Regardless, the resulting work and effort is impressive both in scale and detail. It will resonate with many in the cybersecurity and the broader information technology field(s) and certainly deliver some overdue considerations for others.

The anonymous public comment period ([email protected]) closed on July 31, 2023. First.org is targeting all feedback to be reviewed and addressed by August 31, 2023, with a target official publication date of October 1, 2023.