Applying CVSS to Medical Devices: A Practical Guide

Organizations have had access to the Common Vulnerability Scoring System (CVSS) since the early 2000s. It’s best known for its summary score (0.0 to 10.0) and the High and Critical categories that occasionally make the headlines next to newsworthy 0-day vulnerability discoveries. By standardizing various metrics around vulnerabilities, the CVSS enables companies to prioritize their remediation strategies. However, the general CVSS fails to respond to the distinct issues that Healthcare Delivery Organizations (HDOs) face when managing medical and Internet of Medical Things (IoMT) devices. In October 2020, the MITRE Corporation, under contract with the Food and Drug Administration (FDA), released an updated version of the Rubric for Applying CVSS to Medical Devices (the Rubric), giving HDOs a resource for leveraging the CVSS within their clinical environments. 

By understanding what the 78-page rubric contains, HDOs can begin applying the CVSS to their medical device fleets to improve security and reduce an incident’s potential impact on patient health. 

What is the CVSS?

The Common Vulnerability Scoring System (CVSS) is a framework for assessing a security vulnerability’s severity. Commissioned by the National Infrastructure Advisory Council (NIAC), the Forum of Incident Response and Security Teams (FIRST) now maintains the framework. Originally designed for IT systems, the CVSS provides a standard methodology that organizations can use to prioritize their vulnerability remediation activities built on three distinct categories of metrics:

• Base metrics: characteristics that stay the same across time and environment
• Temporal metrics: characteristics that evolve over the vulnerability’s lifetime
• Environmental metrics: characteristics contextualized with an implementation in a unique environment

How is the CVSS calculated?

The CVSS uses a vector string, which creates a shorthand for expressing the set of metrics used to generate the score. All base metrics must use a vector string that follows this format:

• Label CVSS
• Numeric representation of the current CVSS version
• The set of metrics with the forward slash “/” as a delimiter
• Metric name in abbreviated form
• Metric value in abbreviated form

The abbreviations for metrics are as follows:

• AV: Attack Vector
• AC: Attack Complexity
• UI: User Interaction
• S: Scope
• C: Confidentiality
• I: Integrity
• A: Availability

Each metric has a set of uniquely described values that can make applying CVSS manually a challenge. For example, the AC metric values are:

• Network: The vulnerable component is bound to the network stack and exploitable at the protocol level one or more network hops away.
• Adjacent: The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. 
• Local: The vulnerable component is not bound to the network stack, and the attacker’s path is via read, write, and execute capabilities.
• Physical: The attacker must physically touch or manipulate the vulnerable component.

Why is applying CVSS to medical devices different from traditional devices?

Designed for traditional IT environments, The CVSS and its associated rubric fail to reflect the clinical environment and potential impact on patient safety. By nature, it does not consider or determine:

• Medical device design
• Clinical network environment
• Vulnerability’s impact on a medical device’s performance
• Evaluate potential patient safety impact

What is the Rubric for Applying CVSS to Medical Devices?

In response to the challenges that HDOs face trying to leverage the CVSS, the MITRE Corporation worked with the FDA to develop the Rubric for Applying CVSS to Medical Devices, which includes:

• Customized HDO-specific guidance
• Device-specific examples
• Discussion of issues with and conforming to the original CVSS 
• Inclusion of issues relevant to patient safety, patient/clinician privacy, and cybersecurity risk
• Visual guides

Within the traditional metric groups, the Rubric provides additional “extended vectors” and values that more directly relate to medical device concerns. 

Base Metric Group

Within the Base Metric Group, the Rubric identifies the following extended vectors across the traditional categories:

• Attack Vector: Elements are Network, TCP/IP or UDP,  Wireless, Range, Physical, and Access Type.
• Attack Complexity: Element is the ability to exploit at will.
• Privileged Required:  Elements are Low for extended users/roles, Authorization required to exploit, and System-Level access required to exploit. 
• User Interaction:  Elements are User Interaction required to exploit vulnerability
• Scope: Elements are Scope focusing on whether the exploitable component is different from the vulnerable component.
• Confidentiality Impact: Data type elements are PHI or PII, PHI or PII – Many Customers, Diagnosis or Monitoring, Therapy, Clinical Workflow, System or System-User, Other, High risk across at least one category, and Low across at least one category.
• Integrity Impact: Data type elements are PHI or PII, PHI or PII – Many Customers, Diagnosis or Monitoring, Therapy, Clinical Workflow, System or System-User, Other, High risk across at least one category, and Low across at least one category.
• Availability Impact:  Data type elements are PHI or PII, PHI or PII – Many Customers, Diagnosis or Monitoring, Therapy, Clinical Workflow, System or System-User, Other, High risk across at least one category, and Low across at least one category.

The Rubric explains that the modified base metrics have several challenges for HDOs, including:

• No way to express mitigations within the vector string
• Wide variances across how HDOs apply mitigations
• Lack of control across some metrics, like manufacturers must implement modifications
• Making modifications may make a vulnerability’s exploitability or impact worse

To address challenges arising from modifying the base vectors, the Rubric also includes these additional extended vectors:

• Modified Attack Vector: Elements are Skipped, Services Disabled, Firewall, Segmentation, Restricted Zone, Remote Original applied when network is an original Attack Vector value, and Local Original applied when local is an original Attack Vector value.
• Modified Attack Complexity: Elements are Skipped, Clinician Badges for authentication, Biometric Authentication, Multifactor Authentication, Yes for any of the previous elements, and Other for customized mitigations.
• Modified Attack Complexity: Elements are Skipped and Administrator privileges required to exploit
• Modified User Interaction: Elements are Skipped and Permission Requested before executing a functionality.
• Modified Scope: Elements are Skipped and Scope Mode, like configurations to prevent changes
• Modified Confidentiality: Elements are Skipped and Mitigation.
• Modified Integrity: Elements are Skipped and Mitigation.
• Modified Availability: Elements are Skipped and Mitigation.

Intending to address both the unique risks created by medical devices and the HDO-specific mitigations, the extended and modified vectors attempt to provide a more precise risk evaluation methodology. However, the complexity of engaging in this analysis manually can become time-consuming.

Temporal Metric Group

Within the Temporal Metric Group, the Rubric identifies the following extended vectors across the traditional categories:

• Exploit Code Maturity: Elements are Skipped, Working Code, “in the Wild”, Functional, and Proof-of-Concept.
• Remediation Level: Elements are Skipped, Official Mitigation, Temporary Mitigation, and Level Workaround.
• Report Confidence: Elements are Skipped, Confirmed, Functional Reproduction, and Confidence Reproducible.

These extended vectors, specifically the “Exploit Code Maturity,” can help teams working to prioritize remediation activities. Simultaneously, tracking these issues with threat intelligence often requires specialized skills and a dedicated staff member, something many HDOs lack. 

Environmental Metric Group

Within the Environmental Metric Group, the Rubric identifies the following extended vectors across the traditional categories:

• Confidentiality Requirement: Elements are Skipped, Delayed Therapy, Incorrect/Wrong Therapy, PHI, Reputational Risk, Financial Risk, Operational/Workflow Risk, Yes that one or more previous categories are unknown, Serious Adverse Effect.
• Integrity Requirement: Elements are Skipped, Delayed Therapy, Incorrect/Wrong Therapy, PHI, Reputational Risk, Financial Risk, Operational/Workflow Risk, Yes that one or more previous categories are unknown, Serious Adverse Effect.
• Availability Requirement: Elements are Skipped, Delayed Therapy, Incorrect/Wrong Therapy, PHI, Reputational Risk, Financial Risk, Operational/Workflow Risk, Yes that one or more previous categories are unknown, Serious Adverse Effect.

These extended metrics attempt to give HDOs a guiderail for measuring the impact to both data and patient care by considering how medical devices impact both therapies and diagnoses. For many HDOs, the biggest challenge lies in linking medical devices operations and workflows directly to patient care as medical devices are often mobile, meaning that they may be in different areas of the campus. 

Additional Metrics for Medical Device Security

Although not correlated to the CVSS, the following metrics may be important to medical device security:

• Collateral Damage Potential: explicitly considering loss of life along with physical assets, productivity, and revenue
• Target Distribution: capturing the proportion of vulnerable systems
• Number of Affected Patients: helpful when prioritizing vulnerability remediations

With these additional metrics seeking to help HDOs identify vulnerabilities larger impact on the HDO’s patient population and operations, their lack of integration with the CVSS score itself makes them difficult to apply and quantify. 

Why HDOs Struggle with the Rubric

Despite MITRE’s best intentions, many HDOs struggle to use the Rubric effectively. 

Time and Staffing Constraints

The Rubric Answer Form provided in the original document is five and a half pages of single-spaced spreadsheet. Engaging in a manual analysis for every vulnerability would require multiple full-time staff, something most HDOs can’t afford. 

Inability to Operationalize 

While a few online open-source tools can help automate the analysis process, an HDO would still need to have a person responsible for data input. Although the organization might be able to analyze critical vulnerabilities within the context of its environments, it would remain unable to move beyond an ad hoc process.

Limited Insights

When HDOs have no way to consistently and repeatedly complete the Rubric, they make “best guesses” around which vulnerabilities to spend time analyzing. Ultimately, without a way to automate the scoring and review process, they have limited insights into any and all vulnerabilities’ impacts. 

Asimily: Automated Visibility into IoMT Vulnerabilities and Risk

Asimily evaluates each new vulnerability and provides a customized risk level for each individual device, incorporating the same elements as the MITRE Risk Rubric for Applying CVSS to Medical Devices. With Asimily, organizations gain a robust automated solution that gives them a way to operationalize vulnerability and remediation management for medical and IoMT devices. 

When HDOs use Asimily’s passive scanning technology, and our unique ability to incorporate a device’s CVEs, MDS2s and protocol parsers to report each device’s Impact, Exploit Likelihood, and Utilization they can understand how attackers can take advantage of their unique environments giving them ranked, simple, fix instructions and utilization data that help them prioritize and schedule their next steps. Instead of completing a new assessment for every vulnerability or device, they have a single source of risk and monitoring information that enables them to improve security and track key metrics, including comparing their security posture to industry peers. 

By combining Asimily’s passive scanning to build inventories with the MITRE ATT@CK Framework to identify which published vulnerabilities are actually exploitable on each device, Asimily allows organizations to prioritize their risk reduction efforts on devices with real vulnerabilities versus those with potential vulnerabilities. Asimily then identifies vendor-approved remediation steps necessary to mitigate those risks to their organization and provides a remediation sandbox called Risk Simulator to optimize their team’s efforts in resolving these risky devices.

To learn more about Asimily, download our Total Cost of Ownership Analysis on Connected Device Cybersecurity Risk whitepaper or contact us today.