The latest revision of the industry standard for ranking vulnerabilities has some changes that practitioners will find useful. Here, we’ll discuss them, as well as Tenable’s plans to implement the scoring system in its products.
Imagine two vulnerabilities. One, a local privilege escalation flaw that allows an authenticated attacker to gain administrative access to your Windows workstations and servers. The other, a remote code execution weakness in the SSL-VPN interface of your internet-facing firewalls. While both present a serious risk, the exploitation requirements for attackers, access provided if successful, and impact to the organization could vary depending on the architecture and defenses in place. How would you decide which one you’d prioritize?
This is a challenge practitioners face frequently. In 2022, the National Vulnerability Database published an average of 68.75 vulnerabilitiesdaily with a Common Vulnerabilities and Exposures (CVE) number. If even a few of the products that contain these vulnerabilities are in your environment, you’ll end up with quite the pile to sort after just a couple of weeks.
Tenable has published guidance on Risk Informed Vulnerability Management in the past, and this practice continues to be valuable for defenders charged with exposure management, and specifically with prioritizing vulnerability remediation. This process starts with examining the core severity of a vulnerability — and this is where the Common Vulnerability Scoring System, or CVSS, comes in.
About CVSS
Since its creation by the U.S. National Infrastructure Advisory Council (NIAC) in 2005, CVSS has been used by practitioners worldwide to quantitatively measure the risk posed by vulnerabilities in their environment. It is maintained by the Forum of Incident Response and Security Teams (FIRST). The challenge of comparing the risk of two vulnerabilities, considering their discrete qualities, and determining which deserves more immediate attention, is alleviated by a taxonomy that describes the attributes of a vulnerability along with a measurement system for each attribute.
Its usage is fairly straightforward. Traditionally the creator of a vulnerable product, or the discoverer of a vulnerability, considers its specific qualities and usage and develops a base score, which outlines the nature of the flaw, with only the technical facts of the vulnerability in scope. This base score represents the severity of a vulnerability.
Modifiers to this base score can be applied by practitioners to measure the changing threat landscape — the development of a working exploit, for example — as well as the state of vulnerable targets in a specific computing environment. These modifiers help change the score from an indicator of pure severity to a risk score that the vulnerability represents to a specific organization or network. The calculation of these factors provides a final score between 0.0 and 10.0, which can then be used to, among other things, compare and stack-rank a set of vulnerabilities to prioritize for remediation.
Changes in CVSS version 4
In the years since its initial publication, several major updates to the system have been released — versions 2, 3, and 3.1 represent the milestones in its history, with 3.1 as the currently active release. The newest update, CVSS version 4, has recently entered a public preview phase, in which FIRST will collect feedback from the security community. The target publication date for the final specification is Oct 1, 2023.
Here are the key updates to the standard in CVSSv4.
Nomenclature
“Man, did you hear about that crazy new vulnerability in your phone’s OS, it's a CVSS 10” is a comment you might hear from a security professional today, taking only the base score into account and often misrepresenting its significance. We find it is rare for organizations to take the extra steps to apply the additional metrics to a base CVSS score for a vulnerability, which don’t necessarily tell the full story about its impact. In an effort to encourage the application of these metrics, CVSSv4 introduces new terms to use in referring to scores that include these metrics:
- 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 upon hearing of the “CVSS 10 vulnerability” from a colleague, the other individual in the conversation might ask “is that the CVSS-B score?” We do not anticipate a major dropoff in the colloquial use of plain-old “CVSS,” but in professional writing about vulnerabilities, we hope to see adoption of the additional context.
Changes to base metrics
The foundational attributes of a vulnerability are described with its base exploitability metrics: Attack Vector, Attack Complexity, Privileges Required and User Interaction. Let’s take a closer look at two of these: Attack Complexity and User Interaction.
To expand on the concept of Attack Complexity, a new binary metric called Attack Requirements has been introduced. If Attack Requirements is set to Present, this means a vulnerable target must have specific conditions in place to allow exploitation. An example might be if a managed file transfer application must be configured to allow a specific protocol for an exploit to work, which is not accessible in its default configuration. If the Attack Requirements metric is set to None, this typically means the product is exploitable in any state or configuration.
The base metric of User Interaction has been changed as well. In prior versions it was a binary metric with options of None or Required, denoting whether a human needed to take some kind of action to facilitate exploitation. In CVSSv4, Required has been split into two new metrics, to note whether the interaction is Passive or Active. Passive interactions are typically involuntary and do not require conscious decisions by the user (say, performing a routine login to an application). Active interactions are intentionally performed by the targeted user (e.g. disabling a security feature of an operating system).
Finally, a change that is likely to be celebrated by frequent CVSS users — the Scope metric has been retired. In prior versions, Scope measured the impact of a vulnerability beyond the product being scored; for example, if a vulnerability in a web application also impacted the browser client used to access it. While conceptually interesting, in regular usage it was considered confusing and hard to measure. In CVSSv4, the impact to the confidentiality, integrity, and availability of both the vulnerable system and to subsequent systems is explicitly defined as none, low or high.
Temporal is retired in favor of threat metrics
The longstanding Temporal metrics, which change as both the defensive and offensive situations around a vulnerability change, have been renamed to threat metrics and reduced to a single option that describes the exploit maturity, using the following options:
- Unreported — meaning there is no known exploit or Proof of Concept (PoC) code available
- PoC — meaning a PoC has been seen, but has not been used to build a reliable exploit that has been used in actual attacks
- Attacked — meaning that exploitation has been observed in actual attacks
- Not Defined — meaning that this metric has not been set
This, of course, means that there is no longer consideration given to whether a formal fix or workaround is available, or if the vulnerability is substantiated by the vendor. This is likely a function of the growth of social media, used to rapidly spread news of vulnerabilities, exploits and patches, which didn’t exist when CVSSv1 and v2 were released. Confirmation of an exploit or a patch no longer requires waiting hours or days, and evidently is no longer a major factor in measuring risk.
A new focus on safety
Illustrative of the modern network-all-the-things approach and the prevalence of operational technology (OT) and internet of things (IoT) assets in enterprise environments, new metrics have been added to represent the impact not just to the confidentiality, integrity, and availability of machines and data but to the safety of humans.
If a vulnerability’s exploitation can impact human safety in an environment, the Environmental score for Subsequent System Integrity and Subsequent System Availability can be set to Safety (S), which will result in a higher score than if set to high. So if an exploited vulnerability were to disable a fire protection system on a factory floor, for example, you’d set subsequent system availability to Safety instead of High. Similarly, if exploitation made the same fire protection system always read the temperature of the room as 72 degrees, you’d set the subsequent system integrity metric to Safety instead of High.
One of the new supplemental metrics also contributes to this evaluation. If a system affected by a vulnerability is designed with the purpose of implementing safety measures, this can be noted by setting the Safety metric to Negligible (if the destructive consequence is negligible) or Present (for anything above negligible). Note that these are aligned with designations of harm described by the international standard for safety systems IEC-61508. We feel this is a valuable addition to the system, and hope it will encourage increased use of CVSS by vendors of technology products used by industries for whom safety is a top concern, like manufacturing or healthcare.
Additional supplemental metrics
In addition to Safety, other new metrics have been added, in a category referred to as Supplemental metrics — a first for CVSS. The distinguishing feature of these supplemental metrics is that none of them modify the final CVSS score — they are simply included so that consumers of the score and associated ratings can be aware of these particular conditions. The new metrics include:
- Safety (S): Described above, does the vulnerability introduce the possibility of physical harm to people?
- Automatable (AU): Can exploitation of the vulnerability be automated?
- Recovery (R): Is recovery from exploitation automatic, by the affected system? Does a user need to be involved? Or is it impossible to recover the system?
- Value Density (V): How valuable are the resources provided to an attacker after exploitation? Are they minimal, i.e. one set of low-privilege credentials (Diffuse), or high, i.e. access to all a directory’s credentials (Concentrated)?
- Vulnerability Response Effort (RE): what is the anticipated effort to respond to a successfully exploited system (Low/Moderate/High)? It may be helpful to think of this in chronometric terms, i.e. a response effort that takes minutes (L), hours (M), or days (H).
- Provider urgency (U): For providers that are notifying customers or users about a vulnerability and including a CVSS score, the provider can add a color-coded description of its assessment of the urgency of the vulnerability, as Clear, Green, Amber, or Red.
CVSSv4 in Tenable products
CVSS is a popular system with its champions and critics alike. While Tenable offers Vulnerability Priority Rating (VPR) scoring in its products as a superior metric for understanding the exposure presented by a vulnerability to our customers, we recognize that CVSS is an industry standard and an appropriate lens through which vulnerabilities can be evaluated.
As with previous iterations, Tenable plans to support CVSSv4 in its products. Specific details are coming soon, but customers can expect to use CVSSv4 scores in a similar fashion to existing usage of CVSSv3 and v2. We are awaiting the final design spec from FIRST following this public preview period to finalize our own implementation.
For more details on CVSSv4 and to participate in the public preview, check out FIRST’s page on v4, as well as its presentation to the FIRST Conference on the new version. A calculator you can use to test scoring of vulnerabilities using the public preview’s metrics is also available. Happy scoring.
Learn more
- Read the Tenable Community post: CVSS scores in Tenable products
- Check out the Tenable blog series: Mind the Gap
- Get up to speed on Tenable's Vulnerability Priority Rating: What is VPR and how is it different from CVSS
