A Deeper Dive into CVSS v4.0 for Medical Devices

Earlier this year, I wrote an MPO column about the large number of available vulnerability scoring rubrics and the issues with all of them (Jan/Feb 2024 issue).¹ This month, I am only focusing on one of them—the venerable Common Vulnerability Scoring System (CVSS). CVSS is a widely recognized vulnerability (really, “threat”) scoring rubric used to assess and prioritize the severity of vulnerabilities. CVSS provides a standardized method for scoring vulnerabilities, enabling end-user organizations to make informed decisions about their security posture. While being ubiquitous, it is also widely hated for a variety of reasons, mostly due to its being used in ways it wasn’t designed to be utilized. Since its inception, CVSS has undergone several iterations, each aimed at refining its accuracy and usability.

CVSS was first introduced in February 2005 by the National Infrastructure Advisory Council (NIAC). Two months later, NIAC transferred CVSS to the Forum of Incident Response and Security Teams (FIRST) to become the moderator of CVSS for all future development. It should be pointed out that this scoring rubric was, from the initial release, a rubric designed for first responders during a breach. As such, when a design engineer at a medical device manufacturer or a chief information security officer at a hospital tries to use it, in neither case does it give them the guidance they are seeking. This is the primary reason for the negative opinions of the rubric. However, it wasn’t designed for those use cases.

The primary goal was to create a universal framework that could be used by organizations worldwide to evaluate the risk associated with software vulnerabilities. The initial version—CVSS v1 laid the groundwork but had several limitations, including a lack of granularity and flexibility.

In 2007, CVSS v2.0 was released, addressing many of the shortcomings of its predecessor. This version introduced a more detailed scoring system, breaking down vulnerabilities into three main groups: Base, Temporal, and Environmental. These metrics allowed for a more comprehensive assessment of vulnerabilities, considering factors such as exploitability and impact.

Base Metrics: These metrics represent the inherent characteristics of a vulnerability that are constant over time and across different user environments. They include factors like Access Vector, Access Complexity, Authentication, Confidentiality Impact, Integrity Impact, and Availability Impact.

Temporal Metrics: These metrics reflect the characteristics of a vulnerability that change over time. They include Exploitability, Remediation Level, and Report Confidence.

Environmental Metrics: These metrics adjust the Base and Temporal scores based on the specific environment in which the vulnerability exists. They include Collateral Damage Potential, Target Distribution, Security Requirements, and Modified Base metrics.

Despite its improvements, CVSS v2.0 was not without criticism. Experts pointed out it still lacked the ability to account for the evolving nature of threats and the context in which vulnerabilities existed. This led to the development of CVSS v3.0, released in 2015. CVSS v3.0 introduced several new metrics and refined existing ones, offering a more nuanced approach to vulnerability scoring.

One of the most significant changes in CVSS v3.0 was the introduction of the Exploitability and Impact subscores, which provided a clearer picture of the potential damage a vulnerability could cause. Additionally, CVSS v3.0 emphasized the importance of environmental factors, allowing organizations to tailor scores based on their specific circumstances. Unfortunately, v3.0 also saw the removal of “Collateral Damage”—an attribute that was a proxy for “Severity.” As a result, starting with v3.0, there was no way to score the impact to patient harm. Further, this continued with v3.1 as well.

Then, in November 2023, FIRST released v4.0 of CVSS.2 This was a major change to the old rubric. (Note: it should be pointed out that none of the CVSS versions are compatible with each other, and v4.0 was no exception.)

CVSS v4.0 introduces several improvements over its predecessors. One notable enhancement is the inclusion of more granular metrics, which allow for a more detailed assessment of vulnerabilities. This version also incorporates environmental and temporal metrics, providing a more comprehensive view of the potential impact of a vulnerability.

Additionally, CVSS v4.0 offers better support for automation and customization, facilitating its integration into various security tools and workflows.

Like all previous revisions of CVSS, v4.0 relies on subjective assessments. The scoring process often requires human judgment, which can introduce inconsistencies and biases. This subjectivity can undermine the reliability of the scores, particularly when different organizations or individuals assess the same vulnerability. In an attempt to reduce this, some of the refinements to “attack complexity” and “attack requirements” might help, but it certainly will not result in an overall objective scoring process.

CVSS v4.0 makes significant adjustments to the entire rubric, such as:

• Removing:
• Remediation Level
• Report Confidence
• Renaming:
• Exploit Code Maturity to Exploit Maturity
• Replacing the Temporal metric group with the Threat metric group
• Introduces combinations of groupings, such as:
• Base (CVSS-B)
• Base + Threat (CVSS-BT)
• Base + Environmental (CVSS-BE)
• Base + Threat + Environmental (CVSS-BTE)
• Inclusion of a new Supplemental metric group

The new, optional Supplemental scoring group—arguably the most significant revision in v4.0—is a welcome addition. It doesn’t, however, affect the final score. In addition, while more information is a positive, I question this odd exclusion from the scoring.
The new Supplemental group
includes:

• Safety
• Automatable
• Recovery
• Value Density
• Response Effort
• Provider Urgency

Among these items, “Safety” is a very welcome addition as it restores, to some degree, the deprecated “Collateral Damage” of v2.0. Per the specification, “The Safety supplemental metric value indicates the degree of impact to the Safety of a human actor or participant that can be predictably injured as a result of the vulnerability being exploited.” Unfortunately, the range of values has been reduced to three:

• Not Defined (X): The metric has not been evaluated.
• Present (P): Consequences of the vulnerability meet the definition of IEC 61508 consequence categories of “marginal,” “critical,” or “catastrophic.”
• Negligible (N): Consequences of the vulnerability meet the definition of IEC 61508 consequence category “negligible.”

I like the references to an established ISO/IEC standard, but there is not a lot of granularity in this value (not that it matters as this value does not affect the final score).

Conclusion

While this latest version has made definite improvements, this comes at the cost of added complexity, more metric value to be filled in, and more detailed information to be provided. As a result, the time and effort required when dealing with a large set of vulnerabilities has been increased. (Remember, this rubric is designed for first responders who may only be dealing with one, two, or three vulnerabilities during a breach.) CVSS v4.0 will be a useful tool, but you may want to consider an option that can be completed quicker and is easier to perform, especially during development where you may have hundreds of vulnerabilities to prioritize.

The more I use these fancy vulnerability scoring rubrics, the more I think that “Exploitability” over “Severity” is the way to go. In other words, “Keep It Simple, Stupid,” so for this month, I’ll just leave you with a “KISS.” 

References

1. tinyurl.com/mpo241031
2. tinyurl.com/mpo241032

---

MORE FROM THIS AUTHOR: Secure Medical Device Software Development Attestation

---

Christopher Gates is the director of Product Security at Velentium. He is also the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.