Vulnerability Scoring: Comparing CVSS V2 & V3 for Medical Devices Pt.1

Welcome back to our series on scoring vulnerabilities in medical device designs! In this post, we’re going to summarize the first five of nine key differences in CVSS Version 3 compared to Version 2 and describe the relative advantages or disadvantages of each change.

Share this
Share this

Welcome back to our series on scoring vulnerabilities in medical device designs! In this post, we’re going to summarize the first five of nine key differences in CVSS Version 3 compared to Version 2 and describe the relative advantages or disadvantages of each change.

The change summary information contained in these sections is based on the summary provided by FIRST.

 

I. Vulnerability Impact Assessment

  • Version 2: Vulnerabilities are scored relative to the overall impact on the host platform.
  • Version 3: Vulnerabilities are now scored relative to the impact on the impacted component.

Impact on medical device design scoring: Very little. When CVSS v2 is used to score potential vulnerabilities at the time of design, the decomposition process forces the score to be assessed relative to the current component’s vulnerability. In this one respect, how we use v2 during the design phase is very similar to how FIRST intends v3 to be used at any phase.

 

II. Vulnerability Scope

  • Version 2: Does not assess or score situations in which a vulnerability in one application impacted other applications on the same system.
  • Version 3: A new metric, Scope, now accommodates vulnerabilities for which the impacted component is different from the vulnerable component.

Impact on medical device design scoring: This is not a desirable feature when scoring design vulnerabilities. The process is intended to highlight areas of the design where additional mitigations are indicated due to vulnerabilities in that component, not redirect attention away from the vulnerable component due to secondary impacts.

 

III. Local vs. Physical

  • Version 2: The Access Complexity metric is not defined precisely enough to avoid conflating attacks that require local system access with those that require physical hardware attacks.
  • Version 3: Local and Physical values are now separated in the Attack Vector metric.

Impact on medical device design scoring: This change produces an advantage where the system being scored is purely an MIS/IT-type system, since for these systems physical access can typically be controlled via physical security mitigations. However, for medical devices, physical attacks are almost always a viable attack vector. Therefore, conflating Local and Physical metrics is appropriate.

 

IV. User Inclusion in Access Complexity

  • Version 2: In some cases, Access Complexity could conflate system configuration with user interaction.
  • Version 3: The Access Complexity metric has been separated into Attack Complexity (accounting for system complexity), and User Interaction (accounting for user involvement in a successful attack).

Impact on medical device design scoring: There is no advantage in separating Access Complexity into two metrics in a medical device. Moreover, doing so tends to drive mitigations towards involving a user, which adds to user burden and has been proven to be an ineffective mitigation.

 

V. Authentication vs. Privileges Required

  • Version 2: In practice, the Authentication metric scores were biased toward two of three possible outcomes, and so did not effectively simply identify a vulnerability.
  • Version 3: A new metric, Privileges Required, replaces Authentication. The scoring system now reflects the greatest level of privilege required by an attacker, rather than the number of times and ways the attacker must authenticate.

Impact on medical device design scoring: This change reflects the MIS/IT focus of the FIRST organization; it assumes that there is a privilege structure to be exploited. For most medical devices, “Authentication” needs to be the initial qualifier, as it provides the basis for any “Authorization” that enables a privilege structure to be accessed in a subsequent process.

 

Our next post will examine the final four differences between Versions 2.x and 3.x, and conclude with an explanation for CVSS v2’s continued popularity despite – or because of – these changes.

Prev Post
Next Post