As long as we’ve been collecting incident data, vulnerabilities have remained a prevalent initial access vector leading to breaches and other high-impact cybersecurity attacks. Industry reporting from the past five years shows that exploitation of public-facing applications is consistently among the top three initial access vectors leveraged by adversaries. The problem is critical enough—to both private industry and the Federal government—that the Cybersecurity and Infrastructure Security Agency (CISA) is putting significant effort into collecting and disseminating intelligence about exploited vulnerabilities by way of their Known Exploited Vulnerabilities catalog.
And as long as vulnerability management has been around, security teams have been overwhelmed by long lists of vulnerabilities and various scores, ratings, and rankings but no simple, standards-based formula for quickly determining vulnerability risk. The Common Vulnerability Scoring System, or CVSS, has served as a key component of vulnerability-related risk calculations. But until recently, its usefulness for understanding the holistic risk of a vulnerability being exploited was limited.
Industry reporting from the past five years shows that exploitation of public-facing applications is consistently among the top three initial access vectors leveraged by adversaries.
Fortunately, changes to the CVSS standard in recent years have made the system far more actionable. In this article, we take a quick look at the history of the CVSS standard and explain how security teams can use CVSS version 4 to effectively set patching priorities, despite the apparent deluge of bugs that seem to emerge nearly every week.
A brief history of CVSS
An important component of every vulnerability scoring system is the Common Vulnerability Scoring System, or CVSS. CVSS version 1 was introduced in 2005 as a means of standardizing the language that we use to describe vulnerabilities and their attributes. That same year, the Forum of Incident Response and Security Teams (FIRST) became the custodians of the standard to govern its evolution.
10 years later, CVSS version 3 was released, continuing to improve upon a decade of refinement and industry feedback. But despite advances, CVSS was still at best an input—albeit a critical one—into more comprehensive systems for determining the overall risk associated with a vulnerability. Factors including exposure, threat-based context, the availability and maturity of exploits in the wild, and more had to be correlated with CVSS scores to help teams determine which of their (often) hundreds or thousands of vulnerabilities needed to be patched today.
In 2022, with CVSS approaching the 20 year mark, CVSS version 4 was released. Again, this release included improvements upon the prior model. But a number of new attributes will profoundly impact the degree to which we can describe a vulnerability, and in particular allow us to formulate useful vulnerability risk scores without pouring CVSS data into opaque vendor models.
What’s new or changed in CVSS 4.0
Source: https://www.first.org/cvss/v4.0/specification-document
The most important aspect of CVSS version 4 is metric grouping. Several metrics were added, reorganized, or removed. The resulting nomenclature is:
- CVSS-B: CVSS Base Score
- CVSS-BT: CVSS Base + Threat Score
- CVSS-BE: CVSS Base + Environmental Score
- CVSS-BTE: CVSS Base + Threat + Environmental Score
In particular, we’re interested in CVSS-BTE, as this is the first time that CVSS can natively provide something resembling a holistic vulnerability risk score.
To achieve this, a few things were changed. I’ve simplified the language here, and aligned things that exist in version 3 and 4 in the middle, with version-specific metrics or changes in either column. I encourage you to read the specification if you’re interested in precision or details.
Attack Complexity (updated)
| CVSS 3.0 | CVSS 4.0 |
|---|---|
| CVSS 3.0: Included attributes of the exploit and the target environment. A little too broad to be precise, and thus less useful. | CVSS 4.0 : Reduced in scope to focus on the complexity of the exploit itself, leaving the new Attack Requirements metric to focus on environmental attributes. Either Low or High. |
Attack Requirements (new)
| CVSS 3.0 | CVSS 4.0 |
|---|---|
| CVSS 3.0: N/A | CVSS 4.0 : Focuses on the things that have to be true in and about the environment for the attack to succeed. A binary value that is either None or Present (but like all metrics, context can be attached) |
User Interaction (updated)
| CVSS 3.0 | CVSS 4.0 |
|---|---|
| CVSS 3.0: Either None or Required.
| CVSS 4.0 : Added granularity, with options None, Passive, or Active. In the case of Active, the user has to take some action that subverts a security control, as opposed to simply taking some action that changes the system’s state. |
Exploit Maturity (renamed, from Exploit Code Maturity)
| CVSS 3.0 | CVSS 4.0 |
|---|---|
| CVSS 3.0: Exploit Code Maturity conflated the availability of an exploit, reporting, and some environmental factors (i.e,. remote exploitation as a condition of one value). | CVSS 4.0 : Focuses on the availability of the exploit, including Not Defined (default), Attacked, Proof-of-Concept, and Unreported. Unreported isn’t obvious, but effectively means that intelligence is available to indicate that the conditions for Proof-of-Concept and Attacked are not met. |
Supplemental Metrics (new)
| CVSS 3.0 | CVSS 4.0 |
|---|---|
| CVSS 3.0: N/A | CVSS 4.0 :
|
Example: Using CVSS 4.0 to identify high-risk vulnerabilities
I find it useful to think about the concept of exposure and how CVSS version 4 attributes might be used to identify assets that—if reachable by an adversary as a means of initial access—are at imminent risk of exploitation:
- Attack Vector: Network – The vulnerable system is accessible from remote networks.
- Attack Complexity: Low – No conditions outside of the user’s control.
- Attack Requirements: None – No attack requirements are present.
- Privileges Required: None – No privileges are required for an attacker to successfully exploit the vulnerability.
- User Interaction: None – No user interaction is required for an attacker to successfully exploit the vulnerability.
Assets with a vulnerability matching the above conditions should be patched immediately, and ideally, measures should be taken to reduce the asset’s exposure, so that future vulnerabilities aren’t reachable by adversaries in the first place.
The remaining metric that would increase the level of urgency is Exploit Maturity. If Exploit Maturity for the vulnerability is either option below, then you should assume that compromise is not just imminent, but likely to have happened:
- Exploit Maturity: Proof-of-Concept – A proof of concept is available.
- Exploit Maturity: Attacked – There are known exploits in the wild.
Why make this assumption if Exploit Maturity is set to Proof-of-Concept? Because threat intelligence always depends on detection and subsequent reporting. An Exploit Maturity rating of Attacked is, by definition, a lagging indicator.
For an exploit with few or no dependencies from an attacker standpoint, always assume and respond as though the worst is true. Hunt for suspicious activity at and beyond the affected device, and you’ll be relieved should you find that the worst has not occurred.
Related reading
Related Articles
Translating our detection engine: A journey from JRuby to Go
Translating our detection engine: A journey from JRuby to Go
Best practices for securing Azure Active Directory