Summary

This Cybersecurity Risk Assessment SOP defines how medical device manufacturers evaluate threats across the entire product lifecycle in alignment with FDA premarket (2023), postmarket (2016), and global standards such as ISO 14971, AAMI TIR57, and TIR97. The process uses structured templates to assess risks from threat modeling, SBOM vulnerabilities, secure code analysis, penetration testing, and postmarket findings. Each threat is scored using CVSS exploitability metrics, evaluated for patient safety impact, and re-assessed after mitigations. Residual risk and benefit-risk analyses ensure defensible decisions. Documentation flows into a Cybersecurity Risk Management Report, providing traceability, audit readiness, and compliance with regulatory expectations.

The following is an example of a postmarket vulnerability management SOP that aligns with global regulatory expectations. It can be included in premarket submissions as required evidence and implemented within a manufacturer’s quality system to withstand audits, demonstrate adherence to regulatory guidance, and ensure ongoing compliance. This example also highlights the challenges ELTON addresses by automating many of these cybersecurity requirements and processes, reducing the burden on manufacturers while maintaining regulatory readiness. This Cybersecurity Risk Assessment SOP defines how medical device manufacturers evaluate threats across the entire product lifecycle in alignment with FDA premarket (2023), postmarket (2016), and global standards such as ISO 14971, AAMI TIR57, and TIR97. The process uses structured templates to assess risks from threat modeling, SBOM vulnerabilities, secure code analysis, penetration testing, and postmarket findings. Each threat is scored using CVSS exploitability metrics, evaluated for patient safety impact, and re-assessed after mitigations. Residual risk and benefit-risk analyses ensure defensible decisions. Documentation flows into a Cybersecurity Risk Management Report, providing traceability, audit readiness, and compliance with regulatory expectations.

Purpose

This document describes the Risk Assessment process used to assess Cybersecurity-related risk in products and systems designed by [Organization].

Scope

The scope of this document are Cybersecurity-related risk assessment activities for products and systems designed by ASP.

References

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, Guidance for Industry and Food and Drug Administration Staff, September 27, 2023
• Postmarket Management of Cybersecurity in Medical Devices Guidance for Industry and Food and Drug Administration Staff, December 28, 2016.
• AAMI TIR57:2016 Principles for medical device security – Risk management, 2016.
• AAMI TIR97:2019 Principles for medical device security – Postmarket risk management for device manufacturers, 2019.
• MITRE Corporation Rubric for Applying CVSS to Medical Devices, October 2020.
• ISO 14971:2019 Application of Risk Management to Medical Devices, 2019.
• FIRST Common Vulnerability Scoring System (CVSS) v3.0 Specification Document – https://www.first.org/cvss/v3.0/specification-document

Summary

The cybersecurity risk analysis process described by this procedure uses the Cybersecurity Risk Assessment template to document and assess the risks to patient safety and information security posed by threats identified in products developed by ASP.

In the context of this SOP, the term “threat” will be used to describe the following for purposes of assessing risk in the product or system:

• Threats identified during threat modeling activities.
• Vulnerabilities identified in Software Bill of Materials (SBOM) components (aka, vulnerability assessment).
• Secure code analysis findings.
• Vulnerabilities identified by 3^rd party researchers.
• Threats identified during monitoring of threat intelligence sources such as CISA and Health-ISAC.
• Findings from cybersecurity testing or pentesting.
• Issues identified during design, development, verification, and validation activities that may have cybersecurity impact.

Each threat is assessed in terms of its Exploitability, as derived from the Exploitability subscore described in the FIRST CVSS v3.x standard(s), guided by the MITRE Rubric, and the severity of harm that could result from the threat being exploited.

Each threat’s exploitability is assessed twice: once to identify the inherent or initial risk rating of the threat and a second time to assess the threat in the context of mitigations that have been identified to reduce (or control) the exploitability of the risk.

The goal of the initial risk assessment depends on the source of the threat:

• For threats identified during threat modeling, the initial risk assessment score is intended to provide prioritization and general guidance to the product team on which threats may require additional scrutiny or focus during the design process when considering mitigations for the threat.
• For threats identified from SBOM components, pentest findings, secure code findings, etc., the purpose of the initial risk assessment is to quickly determine if the threat is controlled or uncontrolled so that swift action may be taken in cases where the threat is in a currently fielded product and requires quick action to address.

During the initial risk assessment, the Severity of Harm that could arise from exploitation of a threat is identified. Severity of Harm, in the context of cybersecurity threats, is a function of the element of the system (component and/or subcomponent) that is impacted by a threat.  Using the element of the system, along with the system’s 14971-based safety risk assessment, the Hazardous Situations, Sequences of Events, and resulting Harm(s) which could result from a threat’s exploitation can be identified. In cases where multiple severities of harm could arise, the worst-case severity of harm is used.

In cases where the threat would not result in a Hazardous Situation or Harm to a patient – for example, if the threat could only result in the exposure of confidential information, not impacting the patient’s safety – the Impact metrics from the CVSS v3.x vector are identified.

Once the initial risk assessment for the threat has been determined, mitigations intended to reduce the threat’s exploitability are considered. These may be software requirements, systems requirements, hardware requirements, labeling, process, or other controls designed as part of the system to reduce the overall risk of a particular threat being exploited by a threat actor. These controls are documented as part of the overall risk assessment process as part of the Cybersecurity Risk Assessment.

These design controls must undergo appropriate verification and validation activities to ensure their effectiveness. Verification testing that must occur as part of the design and development of requirements must be performed, as well as more rigorous cybersecurity testing intended to exercise the resiliency, robustness, and effectiveness of the design controls.  These verification activities are traced, along with the design controls, as part of the Cybersecurity Risk Assessment.

After identification of mitigations, a residual risk assessment is performed for each source of threat. This second risk assessment is intended to determine if the remaining residual risk, related to the threat that was identified and mitigations intended to reduce the exploitability of that threat, are acceptable from a benefit-risk standpoint. For any threats that are still considered unacceptable, additional risk control measures (e.g., mitigations) must be considered, and if no additional mitigations are possible, a benefit-risk assessment must be performed to determine if the risk of the given threat is acceptable.

Cybersecurity Risk Analysis Procedure

A Cybersecurity Risk Analysis is conducted per the Cybersecurity Management Plan. Experience, Insight, and judgment are systematically applied to manage risk-taking, following the generally accepted state of the art.

The Risk Analysis Procedure includes individual risk assessments for the following categories of cybersecurity-related risks:

• Cybersecurity risks identified from threat modeling activities.
• Cybersecurity risks identified from secure code analysis.
• Cybersecurity risks identified from software vulnerabilities.
• Cybersecurity risks identified from penetration testing and other cybersecurity-related testing activities.
• Cybersecurity risks identified from unresolved anomalies.

Each of the above categories is documented in a separate tab in the Cybersecurity Risk Assessment document.

Procedure

The following procedure describes the steps required to perform a Risk Assessment using the Cybersecurity Risk Assessment template.  Depending on the category of risk assessment (Threat Model, Secure Code Analysis, Software Vulnerabilities, or Unresolved Anomalies), there are minor differences between the risk assessments. Those differences will be called out in each step of the procedure where applicable.

Populate the Architecture Decomposition columns

During the Threat Modeling process, an architectural decomposition of the system was developed, identifying the components, subcomponents, assets, and their relationships. This should be already documented in the Architecture Decomp, Assets, and Asset Mapping tabs of the Cybersecurity Risk Assessment template.

Threat Model Risk Assessment

The Architecture Decomposition tabs should be populated per the Threat Model SOP, and should include all components, subcomponents, the subcomponent type, and assets affected by that subcomponent.

Vulnerabilities Risk Assessment

The Architecture Decomposition columns should be populated with the Component and Subcomponent that are impacted by the Vulnerability.

In situations where the vulnerability may impact multiple components or subcomponents, each of the components and subcomponents should be individually listed, resulting in multiple rows.

The Assets column should be populated based on the Assets associated with the Subcomponent, as defined in the Threat Model and Asset Mappings tab.

Cybersecurity Testing Risk Assessment

The Architecture Decomposition columns should be populated with the Components and Subcomponents impacted by the cybersecurity testing observation or finding.

In situations where the finding may impact multiple components or subcomponents, each component and subcomponent should be individually listed, resulting in multiple rows.

The Assets column should be populated based on the Assets associated with the Subcomponent, as defined in the Threat Model and Asset Mappings tab.

Secure Code Analysis Risk Assessment

The Architecture Decomposition columns should be populated with the Component and Subcomponent that are impacted by the secure code analysis finding.

In situations where the finding may impact multiple components or subcomponents, each component and subcomponent should be individually listed, resulting in multiple rows.

The Assets column should be populated based on the Assets associated with the Subcomponent, as defined in the Threat Model and Asset Mappings tab.

Unresolved Anomalies Risk Assessment

The Architecture Decomposition columns should be populated with the Component and Subcomponent that are impacted by the unresolved anomaly.

In situations where the unresolved anomaly may impact multiple components or subcomponents, each component and subcomponent should be individually listed, resulting in multiple rows.

The Assets column should be populated based on the Assets associated with the Subcomponent, as defined in the Threat Model and Asset Mappings tab.

Populate the Threat Analysis columns

The Threat Analysis columns of the Cybersecurity Risk Assessment’s RA tabs differ depending on the source of the Risk Assessment. Populate the Threat Analysis columns per the following.

Threat Model Risk Assessment

For the Threat Model RA tab, the STRIDE per-Element rows for Threat Analysis for each of the subcomponents should be populated, as per the Threat Modeling SOP.

Vulnerabilities Risk Assessment

For vulnerabilities identified in software components of the product, for example those identified from scanning of the SBOM and identifying CVEs from the National Vulnerabilities Database, the Threat Analysis columns must be populated with the vulnerability ID (e.g., VCE), and the description of the vulnerability.

Cybersecurity Testing Risk Assessment

For observations, findings, or other results originating from cybersecurity testing  (e.g., pentesting), the Threat Analysis columns should be populated with the ID of the observation from the testing report, and a description of the observation.

Secure Code Analysis Risk Assessment

For findings from secure code analysis, the ID of the secure code analysis finding (e.g., a JIRA ticket ID) and a description of the finding should be populated in the Threat Analysis columns.

Unresolved Anomalies Risk Assessment

For unresolved anomalies identified in the unresolved anomalies report for the product, an ID (e.g., a JIRA ticket ID) and a description of the unresolved anomaly should be documented in the UA Cyber RA tab’s Threat Analysis columns.

Identify possible patient harms

For each row in the Cybersecurity Risk Assessment, identify from the Systems Hazards Analysis the Hazardous Situation and  Severity of Harm that is applicable to the Threat. Document the ID, Hazardous Situation, and Severity of Harm columns of the Cybersecurity Risk Assessment template.

When identifying the Hazardous Situation and Severity of Harm to Patient Safety for a threat, consider the following:

• There may be multiple rows in the Systems Hazards Analysis that apply to a given threat. For example, a threat may impact calibration settings on the device. The Systems Hazards Analysis may contain multiple rows identifying differing levels of harm to a patient if calibration settings are wrong, depending on the probabilities of those situations occurring. In these cases, it is best practice to select the worst-case Severity of Harm to the patient. The rationale being, it is impossible to predict how a threat actor may tamper with a calibration setting, resulting in a harm to a patient – whereas in traditional risk analysis, a variety of probabilities are considered that the calibration may be “off” by certain ranges of values. Since it is impossible to predict how a threat actor may change the calibration, assuming the worst-case is the generally accepted rule.
• Selection of the Hazardous Situation (and therefore severity of harm) should consider the Asset(s) that can be impacted by the Threat. For example, if a Threat can tamper with software or firmware on the device, allowing a threat actor to modify the operation of the device in any manner they desire, then row(s) from Systems Hazards Analysis that consider severity of harm due to incorrect or corrupt software on the device may be the most appropriate.
• Note that while it is good practice to consider impacts to Threats that do not impact patient safety, FDA regulations do not require organizations to consider impacts to, for example, data privacy. If the organization wishes to consider these impacts (usually referred to as “business risk” impacts), the organization can use a variety of techniques to determine the impact to information security. The use of the CVSS v3.x Impact Metrics (Confidentiality, Integrity, and Authenticity) shall be used to complete the overall CVSS base score for the threat, and the decision of risk acceptability based on a separate scale from the risk acceptance level table used for patient-safety-impacting threats.

Calculate Initial Exploitability Scores

For each row of the Cybersecurity Risk Assessment, the CVSS v3 exploitability sub-score (or ESS) for the Threat, without consideration of mitigations shall be calculated.

The ESS is a value ranging from 0.1 to 3.9, calculated from the Exploitability metrics of the CVSS score – Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), and Scope (S).

When calculating the CVSS v3 ESS, it is strongly recommended that the MITRE Corporation Rubric for Applying CVSS to Medical Devices is followed to determine each of the exploitability metrics.  Additional guidance is also provided in Appendix A: Calculating CVSS Exploitability vs. Severity of Harm of this document.

The Cybersecurity Risk Assessment template includes capabilities for calculating the ESS, or an on-line calculator such as the FIRST CVSS v3 Calculator (https://www.first.org/cvss/calculator/3.0) can be used, with the Exploitability Metrics and ESS pasted into the Excel document.

The CVSS Exploitability is divided into five ranges to simplify the risk-acceptance process.

CVSS v3 Exploitability Table
Exploitability	Exploitability Metric Range
Critical (5)	>= 2.9
High (4)	>= 1.9; <= 2.8
Medium (3)	>= 1.0; <= 1.8
Low (2)	>= 0.6; <= 0.9
Negligible (1)	< 0.6

Table 1 CVSS Exploitability Ranges

The rationale supporting these ranges, and how these ranges were determined, is included in Appendices A and B of this document.

The CVSS exploitability, and impact metrics for threats that do not result in harm to the patient, shall be populated in the Initial Risk Analysis columns. For threats that pose risk to patient safety, the CVSS impact metrics (C, I, and A) may be left blank.

Risk Acceptance Level (RAL)

When considering risks during assessment of concrete threats – e.g., those threats posed by a vulnerability (CVE) in a software component, a finding from a pentest, or a 3^rd party researcher reported vulnerability – the initial risk acceptance level is intended to document the CVSS score of the vulnerability as it is reported.

When considering risks during threat modeling, determining Risk Acceptance for the Initial Risk Analysis allows for threats to the system to be prioritized by acceptability or unacceptability – allowing focus to be spent on threats that are uncontrolled within the system and need further mitigation. However, it is also important to remember that the initial RAL value is theoretical – it is based on the precept that there are few (or no) controls to prevent a threat from occurring; the goal of this step is to identify areas of higher risk so they can be addressed via mitigations.

The Initial Risk Acceptance Level is calculated in one of two ways:

Patient Safety Related Risks

For risks that impact patient safety, the risk acceptance level is derived from the Risk Acceptance Level table in the Cybersecurity Risk Assessment for the product or System, included on the “Risk Acceptance Level” table. An example of this table is provided below.

			Severity of Harm
			Catastrophic	Critical	Major	Minor	Negligible
			5	4	3	2	1
Exploitability	Critical	5	25	20	15	10	5
	High	4	20	16	12	8	4
	Medium	3	15	12	9	6	3
	Low	2	10	8	6	4	2
	Negligible	1	5	4	3	2	1

Table 2 Patient Safety Risk Acceptance Levels

The Severity of Harm is cross-referenced with the Exploitability (the values can be multiplied) resulting in a value in the range of 1 to 25.

• For threats with a RAL < 10, the risk is considered acceptable.
• For threats with a RAL >= 15, the risk is considered unacceptable, and mitigations must be identified to reduce the exploitability of those threats.
• For threats with a risk in the range of >= 10 and < 15, mitigations should be identified to reduce the exploitability of those threats; alternatively, during the residual risk assessment, a benefit-risk assessment may be performed to provide a rationale as to why the risk is acceptable.

From the Risk Acceptance Level (RAL) table, look up  the Exploitability Subscore (ESS) and Severity of Harm values located in the Lookup Tables of the Cybersecurity Risk Assessment . This value can also be calculated by multiplying the ESS lookup value (1-5) and the Severity of Harm (1-5).  Document the RAL in the Cybersecurity Risk Assessment .

Non-Patient Safety Related Risks

For threats that do not impact patient safety, the CVSS base score can be used as a measurement of risk acceptability. FIRST provides a qualitative severity rating scale that can be used for these purposes, which is augmented with acceptable, unacceptable, and benefit-risk-analysis ranges below.

Rating	CVSS Score	Risk Acceptance Level
None	0.0	Acceptable
Low	0.1 – 3.9	Acceptable
Medium	4.0 – 6.9	Benefit-Risk Assessment Required
High	7.0 – 8.9	Unacceptable
Critical	9.0 – 10.0	Unacceptable

Table 3 Non-Patient Safety Risk Acceptance Level

Mitigations

Mitigations represent controls (based on requirements) that reduce the exploitability of a threat. The goal of mitigations are to reduce the exploitability of a particular threat.

Mitigations shall include one or more of the following security risk control options in the priority order listed:

1. Inherent security by design.
2. Inherent security by manufacturing process.
3. Protective threat mitigation measures added into the medical device.
4. Protective threat mitigation measures added to the manufacturing process.
5. Security risk disclosure (i.e., providing needed security information to users) and/or security risk transfer to users.
6. Where appropriate, security training to users.

Some examples of cybersecurity risk mitigations include:

• Adding multifactor authentication to a system may be considered a mitigation that increases the Privileges Required (PR) metric from Low to High, thereby reducing the ESS.
• Using data-in-transit encryption (such as TLS) may be considered a mitigation that increases Attack Complexity (AC) from Low to High.
• Disabling an SSH server (or not installing it entirely) and implementing Firewall rules may change an Attack Vector (AV) from Network to Local or Physical.

Further, it is important to clearly document mitigations and trace those mitigations to requirements in systems, software, hardware, and labeling requirements. This allows for traceability to be demonstrated that shows:

• The controls (Requirements) in the system, that were considered to mitigate or reduce risk to patient safety.
• Verification and validation of controls (requirements) to prove their effectiveness.

Documenting Mitigations

Identify systems, software, hardware, labeling, and other controls that are considered as mitigations for cybersecurity-related threats in the system. Document each mitigating control in the Mitigations tab of the Cybersecurity Risk Assessment as a separate row.

For each mitigation, identify one or more Security Control Categories to which the control applies. The following section describes each of the Security Control Categories, which are documented the FDA’s 2023 Cybersecurity Guidance.

Authentication

There are generally two types of authentication controls—information and entities—and a properly-secured system is able to prove the existence of both.

Authentication of information exists where the device and the system in which it operates are able to prove that information originated at a known and trusted source, and that the information has not been altered in transit between the original source and the point at which authenticity is verified. It is important to note that while authenticity implies that data is accurate and has been safeguarded from unauthorized user modification (i.e., integrity), integrity alone does not provide assurance that the data is real and came from a trusted source. Therefore, for the purposes of this guidance, authentication is discussed as a larger security objective over integrity.

Authentication of entities exists where a device and the system in which it operates is able to prove the identity of an endpoint (whether hardware and/or software) from which it is sending and/or receiving information, or authorized user/operator at that endpoint.

As part of normal operations within a secure system, devices should verify the authenticity of information from external entities, as well as prove the authenticity of information that they generate.

Authorization

Authorization is the right or a permission that is granted to a system entity (e.g., a device, server, or software function) to access a system resource. More specifically, as a defensive measure, an authorization scheme enforces privileges (i.e., “rights” associated with authenticated sessions, identities and/or roles). These privileges either permit allowed behavior, or refuse disallowed behavior in order to ensure that system resources are only accessed in accepted ways, by accepted parties.

Within an adequately designed authorization scheme, the principle of least privileges should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function.

For example, in a situation in which a malicious actor has gained access to a credential associated with patient privileges, that malicious actor should not be able to access device resources or functionality reserved for the manufacturer or for the healthcare provider, such as device maintenance routines or the ability to change medication dosage amounts.

While authentication schemes based on cryptographically proven designs are generally considered more robust and are therefore preferred, meaningful authorization checks can be performed based on other compelling evidence (e.g., benefit/risk assessment in accordance with Section 6.5 of AAMI TIR57 and associated supporting justification and as evidenced through security testing). For example, a medical device programmer that is capable of Near-Field Communications (NFC) could have elevated privileges that are granted based on a signal of intent over NFC that cannot physically be produced by another unauthorized device over Radio-Frequency (RF) (e.g., a home monitor).

Cryptography

Cryptographic algorithms and protocols are recommended to be implemented to achieve the secure by design objectives outlined in the FDA Premarket Cybersecurity Guidance (2023), Section IV. While high-quality, standardized cryptographic algorithms and protocols are readily available, several commercial products that include cryptographic protections have been shown to have exploitable vulnerabilities due to improper configurations and/or implementations.

Controls in this category are specifically related to the selection and implementation of the underlying cryptographic scheme used by a device and the larger system in which it operates.

Code Integrity, Data, and Execution Integrity

Many cybersecurity incidents are caused, at their root, by the violation of some form of device integrity. This includes the violation of stored code, stored and operational data, or execution state.

Confidentiality

Manufacturers should ensure support for the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through the unauthorized use of otherwise valid credentials, lack of encryption). Loss of confidentiality of credentials could be used by a threat-actor to effect multi-patient harm. Lack of encryption to protect sensitive information and or data at rest and in transit can expose this information to misuse that can lead to patient harm. For example, confidentiality is required in the handling and storage of cryptographic keys used for authentication because disclosure could lead to unauthorized use/abuse of device functionality.

The proper implementation of authorization and authentication schemes as described in Sections A. and B. of this Appendix 1 of the FDA Premarket Cybersecurity Guidance for Medical Devices (2023) will generally assure confidentiality.

Event Logging and Detection

Event detection and logging are critical capabilities that should be present in a device and the larger system in which it operates in order to ensure that suspected and successful attempts to compromise a medical device may be identified and tracked. These event detection capabilities and logs should include storage capabilities, if possible, so that forensic discovery may later be performed.

Resiliency and Recovery

Devices should be designed to be resilient to possible cyber incident scenarios (also known as cyber-resiliency) and maintain availability. Cyber-resiliency capabilities are important for medical devices because they provide a safety margin against unknown future vulnerabilities.

Firmware and Software Updates

Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product’s lifecycle. Despite best efforts, undiscovered, exploitable vulnerabilities may exist in devices after they are marketed. This is especially true over the device’s service life, as threats evolve over time and exploit methods change, and become more sophisticated.

Manufacturers should build in the ability for devices to be updated, and also plan for the rapid testing, evaluation, and patching of devices deployed in the field.

Tracing Mitigations

In each of the Risk Assessments, mitigating controls may be mapped to a threat, vulnerability, secure code analysis finding, or unresolved anomaly, as a method to reduce the exploitability of that threat. For example, a mitigating control for a threat to data-in-transit sent across a TCP/IP-based network may be Transport Layer Security (TLS).

For each source of threat (e.g., threat in the Threat Model RA, vulnerability in the Vulnerabilities RA), trace one or more mitigating control from the Mitigations tab to that source of threat.

Depending on the complexity of the system, it may be advisable to group mitigating controls logically to simplify mapping those controls to threats, vulnerabilities, secure code findings, etc., in the individual Risk Assessment tabs.

In the case that control groups are used, the mapping in the individual RA tabs should be to the Control Group documented in the Mitigations tab, instead of the individual Requirements.

Verification Testing

Each mitigation identified for one (or more) threats must be tested to ensure it meets the requirements of the mitigation, and that it is effective. Testing of these threats occurs during traditional verification and validation testing of system requirements and design and during cybersecurity-specific testing (e.g., pentesting, robustness testing, resiliency testing). The testing activities that are performed against mitigations must be traceable to the mitigations in the Cybersecurity Risk Assessment, and the threats that those mitigations were intended to control.

Verification testing of requirements representing controls or mitigations for the product are traced to requirements in the [Requirements Traceability Matrix]

In situations where control groups are used to map to the individual risk assessment tabs, traceability to requirements will be through the Control Group to which the individual requirements are mapped.

Calculate Residual Exploitability Scores

Once mitigations have been identified, the Residual Exploitability Subscore (ESS) can be calculated using the CVSS v3 standard. The ESS should be calculated with considerations made for mitigations identified to control the cybersecurity threats identified in each row of the Cybersecurity Risk Assessment.  As before, following the MITRE rubric for guidance to calculating scores is considered best-practice, with additional guidance provided in Appendix A of this document.

For each row in the Cybersecurity Risk Assessment, calculate the Residual Exploitability Subscore and document the CVSS vector and ESS in the Residual Risk Analysis columns of the Cybersecurity Risk Assessment.

The Severity of Harm column in the Residual scores section should be duplicated from the Initial risk scoring activities. It is important to remember that cybersecurity controls do not (typically) change the severity of harm as it relates to patient safety – they can only reduce the exploitability of a potential threat.  Consider the following example:

• A threat (row in the Cybersecurity Risk Assessment) has identified that a threat actor could tamper with calibration settings on the device, via remote connection (such as SSH) as the device as a root user (administrator), because there is no password to log in to SSH as root.
• The impact to patient safety for that threat is Catastrophic (it could kill a patient) if the calibration settings are out of a given safety range.

For threats that do not represent a risk to patient safety, it may be possible to adjust the impact metrics (Confidentiality, Integrity, and Authenticity) of the threat, as part of mitigations implemented in the design. Consider the following example:

• A threat row identifies that log data may contain sensitive data (e.g., PHI), resulting in a Confidentiality Impact of High.
• Mitigations implemented in the design remove PHI from the log files or data explicitly, with verification performed that ensures that no PHI is written log files. This may reduce the Confidentiality impact from High to Low or None.

Document the Impact Metrics for threats that do not impact patient safety in the C, I, and A columns of the Risk Analysis columns of the Cybersecurity Risk Assessment , including the adjusted subscores and base scores.

Benefit-Risk Analysis

If the residual risk after mitigations have been applied for an individual threat is above the threshold defined in the Risk Acceptance Level tables and cannot be further reduced, a Benefit-Risk Analysis is conducted to determine if the benefits outweigh the risk.

The analysis should include scientific evidence of the benefit as suggested below:

• The type of benefit impact on clinical management, patient health, and patient satisfaction, the probability of loss of function, and providing relief from symptoms.
• The magnitude of the benefit.
• The probability of the patient experiencing one or more benefit(s).
• The duration of effect(s)

Document the Benefit-Risk Analysis in the Benefit Risk Analysis column of the Cybersecurity Risk Assessment.

A summary of the risk assessment, including any benefit-risk-analysis required for threats that do not fall into the “acceptable” range of the Risk Acceptance Level table(s) is summarized in the Cybersecurity Risk Management Report.

Completeness of Risk Control

Cybersecurity risk control activities shall be reviewed to ensure that the cybersecurity risks from all identified security vulnerabilities and threats have been considered and all cybersecurity risk control activities are completed.

Overall Residual Risk Evaluation

An overall residual risk evaluation after risk controls are established is conducted to ensure the overall residual risk is acceptable using the criteria defined in the product’s Cybersecurity Management Plan.

The results of the overall residual risk evaluation shall be recorded in the Cybersecurity Risk Assessment and the summary of the risk assessment shall be recorded in the Cybersecurity Risk Management Report.

Cybersecurity Risk Management Report

Prior to release for commercial distribution, a Cybersecurity Risk Management Report is developed for each release of the system or product. The report comprises a review of the risk management process and asserts (with justification):

• That the Cybersecurity Management Plan has been appropriately implemented (may be performed/justified via checklist with references).
• That the overall residual risk is acceptable – (reference the location where the overall risk was assessed during the “Risk Control” stage).
• That the appropriate methods are in place to obtain relevant production and post-production information related to safety (reference SOPs, work instructions, etc. for gathering production information and post-market surveillance).

The report is updated after subsequent Cybersecurity Management activities (e.g., periodic review).

All versions of the Cybersecurity Risk Management Report are maintained in Document Control and/or referenced in the Risk Management File.

Production and Post-Production

Information that becomes available after the product is released may necessitate revisions to the Cybersecurity Risk Management File throughout the product life. Additionally, postmarket information shall be used to address security vulnerabilities and threats that pose risk as part of the postmarket management of the medical device.

Examples of information would include the collection and review of the following types of data:

• Results from the Corrective and Preventive Action (CAPA) System.
• Adverse events, customer complaints/feedback, regulatory authorities’ notification
• Periodic security testing of the medical device.
• Information from Purchasing, or Production and Technical Support.
• Consideration of new or revised standards.
• Information from Independent security researchers.

Appendix A: Calculating CVSS Exploitability vs. Severity of Harm

Methodology

The following section outlines the recommended methodology for using CVSS v3.x-based exploitability, vs. severity of patient harm, when assessing inherent and residual risk of threats during threat modeling and risk analysis of a system. This methodology is designed to be applied during threat modeling and threat analysis, when considering threats that may not necessarily have concrete implementations; it is a subjective methodology that can (and should) result in healthy debate and consideration of threats to ensure that risks to the system have been thoroughly considered.

The methodology uses the following six steps:

1. Identify the threat under consideration, the components and subcomponents of the system that the threat applies to, and the assets that could be impacted by the threat.
2. Identify the severity of harm that could result from the threat.
3. Determine the inherent exploitability vector and score.
4. Identify mitigations, such as design controls, which are intended to reduce the exploitability of the threat.
5. Determine the residual exploitability of the threat, using the inherent exploitability score, considering the mitigations that are intended to reduce the exploitability of the threat.
6. Using the risk level table, determine if the residual exploitability vs. severity of harm is acceptable or unacceptable.

Threat Identification

The first step of the risk assessment methodology requires the identification of threats to the device or system. The threat modeling process, decomposition of the system into components and subcomponents, identification of assets, etc., is outside the scope of this methodology. This methodology assumes that threats, affected components, subcomponents, and assets have been identified.

The following table will be used throughout this document to demonstrate how each step may be executed. To demonstrate the use of this methodology, we will assume that the device or system is network-enabled, and that remote access to the device is available via SSH.

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.

Example Threat Identification

Severity of Harm

FDA Premarket and Postmarket guidance suggest that there a several ways to determine the Severity of Harm to a patient in context of cybersecurity. The approach recommended by this document is “worst-case”, where the highest severity of harm is chosen from an ISO 14971-based risk assessment for the device. The highest severity of harm is appropriate based on the impact that could result from a live threat actor with malicious intentions and an exploitable  vulnerability.

The following table is provided as an example and should be replaced with the severity of harm(s) identified by the manufacturer from an ISO-14971-based risk assessment for their device.

Score	Description	Potential Harm
5	Catastrophic	Results in death.
4	Critical	Results in permanent impairment or life-threatening injury.
3	Serious	Results in injury or impairment requiring professional medical intervention.
2	Minor	Results in temporary injury or impairment not requiring professional medical intervention.
1	Negligible	Inconvenience or temporary discomfort.

Table 4 Ranges of Severity of Harm

Using the safety risk assessment for the system or device, identify the worst-case severity of harm that could occur based on a threat that has been identified. For this example, we’ll assume that the device is  life-sustaining, and a threat actor with remote access to the device could turn it off, interrupting the treatment, resulting in a critical (4) impact to the patient’s safety.

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.	Interruption in Treatment	4 (Critical)

Table 5 Example Severity of Harm

Inherent Exploitability

MITRE’s Rubric for Applying CVSS to Medical Devices is recommended by the FDA as a tool for determining CVSS v3 scores for vulnerabilities identified in medical devices. MITRE’s Rubric, FIRST CVSS v3 specification, and the calculation for CVSS exploitability sub scores, are used to create a table showing all possible CVSS exploitability sub scores, and associated vectors. (Appendix A)

When the exploitability scores (not rounded) are ordered from lowest to highest, patterns emerge that suggest more granular exploitability sub score ranges are necessary . For example, lower exploitability scores tend to require direct or proximal physical access to the device; in fact, no exploitability score above 1.0 includes a physical attack vector. Analysis of these patterns results in the following exploitability table, that with minor per-organization variations, is commonly employed by medical device manufacturers.

CVSS v3 Exploitability Table
Exploitability	Exploitability Metric Range
Critical (5)	>= 2.9
High (4)	>= 1.9; <= 2.8
Medium (3)	>= 1.0; <= 1.8
Low (2)	>= 0.6; <= 0.9
Negligible (1)	< 0.6

Table 6 CVSS v3 Exploitability Ranges

The following are additional considerations in the development of more granular exploitability ranges in the risk acceptance table. Considerations are informed by a stratification of all possible exploitability scores across all possible permutations of CVSS. Through this view, trends and various other observations are present in the data that inform exploitable ranges, such as:

• For scores below 0.6 – Attack scenarios in this range require (at minimum) adjacent access to the target. In fact, within the range of 0 to 0.5 (inclusive), only one vector (AV:A/AC:H/PR:H/UI:R/S:C) occurs outside of close physical proximity (AC:P or AC:L) to the target. In the case of an adjacent attack vector (e.g. over a wireless channel), a threat actor would still require elevated privileges (PR:H), user interaction (UI:R), and factors outside of the attacker’s control (AC:H) to successfully exploit a vulnerability.
• For scores in the range between 0.6 (inclusive) and 0.9 (inclusive) – Attack scenarios in this range begin to include network-based attacks (AV:N), or attacks that can occur within physical proximity (AV:P, AV:L) and require at least two other metrics to be more easily exploited – e.g., an attack complexity of low (AC:L), or a scope of changed (S:C). Attacks at the adjacent (AV:A) only have one metric “above” the lowest level.
• For scores between 1.0 (inclusive) and 1.8 (inclusive) – Attack scenarios in this range include network-based repeatable attacks, such as those that do not require extenuating circumstances (complexity) outside of the threat actors’ control (AC:L), such as an unauthenticated network exploit This range also includes the last of highly exploitable physical attack vectors, all of which have no permissions required (PR:N), are of low complexity (AC:L), and require no user interaction (UI:N), a common scenario that includes drive-by attacks on a physical device. Attacks that can occur without physical contact (AV:L, AV:A) tend to have two or three other metrics that are more easily exploited.
• For scores between 1.9 (inclusive) and 2.8 (inclusive) – Attack scenarios in this range include all attacks that are exploitable without physical access to the device, and metrics for local and adjacent (AV:L, AV:A) metrics are near or at their most exploitable values.
• For scores above 2.9 – Attack scenarios in this range include attacks that no longer require close-proximity access to the device (AV:L) such as Bluetooth or other short-range wireless communications and occur either at the network-stack level (AV:N) or on a wireless channel (AV:A). For scores with an adjacent attack vector (AV:A), the AC, PR, and UI metrics are all at their most exploitable value.

Continuing our example, we can use the CVSS v3.x standard and MITRE rubric to guide the selection of Exploitability for the CVSS vector:

• Attack Vector – Since the device is intended to be network connected, or at least has a network interface on the device that is enabled, and an SSH service is enabled on the device to allow remote connections, the attack vector (AV) should be set to network (AV:N).
• Attack Complexity – We will assume that SSH is enabled on the device at all times, and that root access to SSH is enabled, with an easy-to-guess or global password. Based on these characteristics the attack complexity (AC) should be set to Low (AC:L).
  • When considering attack complexity, an example characteristic to consider (as provided in the MITRE rubric) is the ability of a threat actor to exploit the design of the device without the need of additional attacks (man-in-the-middle or machine-in-the-middle). Further, the CVSS v3.x specification discusses the requirements of the threat actor to prepare the target environment for the attack to ensure repeatability or reliability.
• Privileges Required – We will assume that authentication to the SSH service is enabled for a variety of environment users – not just root or a dedicated low-privileged SSH user. Additionally, we will assume that the device can be rebooted or shut down by any SSH user, setting the privileges required (PR) to Low (PR:L).
  • Privileges can manifest in many ways in a system – it is not as simple as “does the user require a password” or “is the user an administrator.” For example, the MITRE rubric discusses “authorization” to a component using an “authorization model” – an analogy for a role-based access model. If a system uses such a model, and the user must have a high level of permissions (e.g., administrator) to perform an action, the privileges required may be set to high.
• User Interaction – This metric attempts to capture if another entity such as the user is required to perform an action to allow a threat actor to exploit the vulnerability. For example, if SSH was disabled on the device but could be enabled by a user with physical access to the device via a user-interface element, this may constitute setting the UI metric to required. In this example, we’ll assume that SSH is enabled by default and starts when the system boots, resulting in a user interaction metric of none (UI:N).
• Scope – The scope metric is a modifier for the overall exploitability score, which attempts to capture if the vulnerability could grant the threat actor access to a component or subcomponent other than the one directly impacted by the vulnerability. In this example, we’ll assume that the device or system is a single component and subcomponent, and only has a single network interface; meaning that if the device is compromised via the SSH service running on the device via the network interface, there are no other components or sub-components (either the device itself or adjacent systems) that would be impacted, setting the scope to unchanged (S:U).

  Let us consider an example of a threat that could result in scope change with the following examples:

  • In the above example, if the device was further broken into multiple subcomponents, such that the SSH service was threat modeled as a separate subcomponent from the operating system. A vulnerability and successful exploitation of the SSH service (as root) would enable a scope change into the operating system subcomponent (as root). Once a threat actor has access to the operating system (as root via the SSH service) they will have access to, and complete control over, the operating system and any other subcomponents directly attached to the main operating system component.
  • In another example, assume that the device has two network interfaces – the physical network interface, and a wireless network interface. Assume that the wireless network interface is enabled by default and is intended to act as a Wi-Fi access point. When considering threats to that Wi-Fi access point, if a threat actor were to connect to that Wi-Fi access point, and log into the device via SSH, that could grant the threat actor an easy ingress point to the network on which the device resides. This could represent a scope change (S:C) in terms of the CVSS Scope metric.

Given the example metric selections above, the exploitability vector would be AV:N/AC:L/PR:L/UI:N/S:U, with an exploitability subscore of 2.8. The lookup value from the exploitability table (above) would then be high (4).

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.	Interruption in Treatment	4 (Critical)	AV:N/AC:L/PR:L/UI:N/S:U	2.8	4 (High)

Example Inherent Exploitability

At this point, the inherent risk of the threat can be identified using the risk acceptance table for patient safety impact. While not strictly necessary for this risk assessment, the inherent risk score can be used to guide design-time activities and help prioritize potential threats that may need additional consideration during the design of the device.

In the example provided so far, the patient safety impact of this threat would be unacceptable, as the severity is 4 (catastrophic) and the exploitability is 4 (high). If no controls or mitigations were identified to reduce the risk of this threat, the risk would be unacceptable.

Mitigations

In the context of this risk assessment, mitigations are design controls, such as systems or software requirements, hardware requirements, configuration of a system, labeling, and other measures that are intended to reduce the exploitability of a given threat. This concept is also applicable to concrete vulnerabilities that affect a device or system.

Using our example, some mitigations to prevent a threat actor from accessing the device via SSH and rebooting or shutting it down, resulting in an interruption in therapy, may include:

• Stronger SSH authentication – such as certificate-based authentication, unique-per-device credentials that are not derived from a characteristic of the device, or multi-factor authentication solutions.
• Disabling SSH by default – if SSH is only necessary under certain circumstances, disabling the SSH service and only enabling it when those circumstances arise, through strongly-authenticated local or physical access to the device, may be an option.
• Permissions controls – disabling SSH access to root users, disabling sudo privileges for users with SSH access to the system, careful consideration of filesystem permissions, are all potential mitigations to prevent a threat actor with SSH access to the device from having the ability to realize the threat.

For purposes of this example, we will say that mitigations include multi-factor authentication on SSH login to the device, only enabling SSH for specific accounts (service), and that sudo permissions are disabled for the service account.

Note that these mitigations are not intended to illustrate comprehensive requirements for this type of threat and are simply to illustrate the reduction in exploitability of the threat to demonstrate how risk acceptance may be reached.

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.	Interruption in Treatment	4 (Critical)	AV:N/AC:L/PR:L/UI:N/S:U	2.8	4 (High)	Multi-factor token-based authentication required for SSH login.   SSH access is only granted to service user account.   Sudo permissions denied for service account.

Example Mitigations

Residual Exploitability

Once mitigations have been identified for the threat, the impact of those mitigations on the exploitability of the threat may be considered, resulting in the residual exploitability score calculated as part of the risk assessment.

• Attack Vector – None of the mitigations change the method by which SSH is accessed (it is still tied to the network stack), the attack vector remains network (AV:N)
• Attack Complexity – multi-factor authentication can be considered as an additional protection that is intended to prevent exploitation of easy-to-access remote-access tools such as SSH. This would change the attack complexity (AC) metric to high (AC:H)
• Privileges Required – Through adding controls to limit the ability of users accessing the system via SSH from rebooting the device, this particular threat (rebooting or shutting down the device using remote access) could have its privileges required metric changed from low to high (PR:H). Further, the addition of the preventative measure of the service user with access to the device via SSH, would reinforce the change from PR:L to PR:H.
• User Interaction – No additional controls or changes were designed to change this metric. It would remain UI:N
• Scope –The impact of this threat would still only affect the component under consideration (the device) this metric would remain Unchanged (S:U).

With these mitigations in place, the revised exploitability vector would be AV:N/AC:H/PR:H/UI:N/S:U, and a revised exploitability subscore of 0.7. The exploitability value from the exploitability table would then be low (2).

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.	Interruption in Treatment	4 (Critical)	AV:N/AC:L/PR:L/UI:N/S:U	2.8	4 (High)	Multi-factor token-based authentication required for SSH login.   SSH access is only granted to service user account.   Sudo permissions denied for service account.	AV:N/AC:H/PR:H/UI:N/S:U	0.7	2 (Low)

Example Residual Exploitability

Risk Acceptance

The last step of the risk assessment process is determining whether the risk is acceptable or unacceptable. Regardless of whether some amount of risk is transferred to the device owner or customer, the manufacturer must determine a threshold at which a risk is acceptable or unacceptable.

The method does not necessarily need to be a bright line between acceptability or unacceptability; for example, the FDA’s Postmarket Guidance alludes to a grey scale between controlled and uncontrolled risk. However, it does go on to state that that manufacturers must arrive at a binary decision of “controlled” vs. “uncontrolled” (aka acceptable vs. unacceptable) when assessing the risk of a vulnerability in their system, regardless of the method they arrived at that conclusion.

Using our working example, the residual exploitability score of low (2), and severity of harm of critical (4), we can perform a lookup on the patient safety Impact risk acceptance table, and determine that the risk is acceptable:

		Severity of Harm
		Catastrophic (5)	Critical (4)	Major (3)	Minor (2)	Negligible (1)
Exploitability	Critical (5)	Unacceptable	Unacceptable	Unacceptable	Unacceptable	Acceptable
	High (4)	Unacceptable	Unacceptable	Unacceptable	Acceptable	Acceptable
	Medium (3)	Unacceptable	Unacceptable	Acceptable	Acceptable	Acceptable
	Low (2)	Unacceptable	Acceptable	Acceptable	Acceptable	Acceptable
	Negligible (1)	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable

Example Selection of Risk Acceptance

Threat Description	Patient Safety		Inherent Exploitability			Mitigations	Residual Exploitability			Risk Acceptance
	Harm	Severity	Vector	Score	Expl		Vector	Score	Expl
A threat actor with network access to the device (e.g., on the same network subnet, or if the device is exposed to the internet) could log into the device via the SSH service and shut down or reboot the device.	Interruption in Treatment	4 (Critical)	AV:N/AC:L/PR:L/UI:N/S:U	2.8	4 (High)	Multi-factor token-based authentication required for SSH login.   SSH access is only granted to service user account.   Sudo permissions denied for service account.	AV:N/AC:H/PR:H/UI:N/S:U	0.7	2 (Low)	Acceptable

Example Risk Acceptance

There are situations where the residual exploitability and severity of harm, even after mitigations have been designed into the system, can still result in an unacceptable level of risk. This can be addressed in a few ways.

• Adjusting the line between acceptable and unacceptable risk – depending on the characteristics of the device. For example, is it life sustaining or not? What is the intended use environment? Is it intended to be used only in a controlled hospital environment such as a surgical theater? Depending on these types of characteristics, loosening, or tightening the line between risk acceptability and unacceptability may be appropriate.
• Creating a “grey” line between unacceptable and acceptable risk, where risks within that range may be acceptable, but require additional analysis by the designer to provide a rationale as to why the risk is acceptable.

Patient Safety Impact

The patient safety risk level table provides a tool to determine risk acceptability based on exploitability as calculated using the CVSSv3 standard, and severity of harm as identified in the ISO-14971-based “safety” risk assessment for the device.  The relationship between the exploitability and severity of Harm can be plotted on two axes of a graph, resulting in a matrix which can then be used to assist with the determination of if a risk is acceptable or unacceptable.

The FDA, as part of their Postmarket Cybersecurity Guidance (2016) provides the following figure, which demonstrates a gradient between “controlled” (acceptable) and “uncontrolled” (unacceptable) risk. The FDA goes on to state that the figure can be used to assess the risk of patient harm from a cybersecurity vulnerability using this range, however a binary decision (acceptable or unacceptable) must be reached by the manufacturer.

Table 7 FDA Postmarket Cybersecurity Guidance Controlled vs. Uncontrolled Risk

The following table is provided as a demonstrative example – the choice of the intersection between severity of harm and exploitability should be carefully considered by the manufacturer based on the characteristics of the device. For example, a life-sustaining device such as a ventilator or infusion device that may require lower-exploitability scores with catastrophic impact to patient safety are unacceptable.

		Severity of Harm
		Catastrophic (5)	Critical (4)	Major (3)	Minor (2)	Negligible (1)
Exploitability	Critical (5)	Unacceptable	Unacceptable	Unacceptable	Unacceptable	Acceptable
	High (4)	Unacceptable	Unacceptable	Unacceptable	Acceptable	Acceptable
	Medium (3)	Unacceptable	Unacceptable	Acceptable	Acceptable	Acceptable
	Low (2)	Unacceptable	Acceptable	Acceptable	Acceptable	Acceptable
	Negligible (1)	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable

Example Patient Safety Impact Table

Appendix B. CVSS Calculations Table

The following table was developed by generating a matrix of every possible CVSS v3 exploitability vector and calculating the CVSS v3 exploitability sub score from the provided vector. The results are ordered based on the un-rounded exploitability sub score to simplify analysis of the data.

Score	Attack Vector (AV)	Attack Complexity (AC)	Privileges Required (PR)	User Interaction (UI)	Scope (S)
0.2	AV:P	AC:H	PR:H	UI:R	S:U
0.2	AV:P	AC:H	PR:H	UI:N	S:U
0.3	AV:P	AC:L	PR:H	UI:R	S:U
0.3	AV:P	AC:H	PR:H	UI:R	S:C
0.3	AV:P	AC:H	PR:L	UI:R	S:U
0.3	AV:P	AC:L	PR:H	UI:N	S:U
0.4	AV:P	AC:H	PR:L	UI:R	S:C
0.4	AV:P	AC:H	PR:H	UI:N	S:C
0.4	AV:L	AC:H	PR:H	UI:R	S:U
0.4	AV:A	AC:H	PR:H	UI:R	S:U
0.4	AV:P	AC:H	PR:N	UI:R	S:C
0.4	AV:P	AC:H	PR:L	UI:N	S:U
0.4	AV:P	AC:H	PR:N	UI:R	S:U
0.4	AV:P	AC:L	PR:H	UI:R	S:C
0.5	AV:P	AC:H	PR:L	UI:N	S:C
0.5	AV:L	AC:H	PR:H	UI:N	S:U
0.5	AV:P	AC:L	PR:L	UI:R	S:U
0.6	AV:N	AC:H	PR:H	UI:R	S:U
0.6	AV:A	AC:H	PR:H	UI:N	S:U
0.6	AV:P	AC:H	PR:N	UI:N	S:U
0.6	AV:P	AC:H	PR:N	UI:N	S:C
0.6	AV:P	AC:L	PR:L	UI:R	S:C
0.6	AV:P	AC:L	PR:H	UI:N	S:C
0.6	AV:L	AC:L	PR:H	UI:R	S:U
0.7	AV:L	AC:H	PR:H	UI:R	S:C
0.7	AV:A	AC:L	PR:H	UI:R	S:U
0.7	AV:P	AC:L	PR:N	UI:R	S:C
0.7	AV:P	AC:L	PR:L	UI:N	S:U
0.7	AV:P	AC:L	PR:N	UI:R	S:U
0.7	AV:A	AC:H	PR:H	UI:R	S:C
0.8	AV:N	AC:H	PR:H	UI:N	S:U
0.8	AV:P	AC:L	PR:L	UI:N	S:C
0.8	AV:L	AC:H	PR:L	UI:R	S:U
0.8	AV:L	AC:L	PR:H	UI:N	S:U
0.9	AV:L	AC:H	PR:L	UI:R	S:C
0.9	AV:L	AC:H	PR:H	UI:N	S:C
0.9	AV:A	AC:H	PR:L	UI:R	S:U
1.0	AV:N	AC:L	PR:H	UI:R	S:U
1.0	AV:A	AC:L	PR:H	UI:N	S:U
1.0	AV:P	AC:L	PR:N	UI:N	S:U
1.0	AV:P	AC:L	PR:N	UI:N	S:C
1.0	AV:A	AC:H	PR:L	UI:R	S:C
1.0	AV:N	AC:H	PR:H	UI:R	S:C
1.0	AV:A	AC:H	PR:H	UI:N	S:C
1.1	AV:L	AC:H	PR:L	UI:N	S:U
1.1	AV:L	AC:H	PR:N	UI:R	S:U
1.1	AV:L	AC:H	PR:N	UI:R	S:C
1.1	AV:L	AC:L	PR:H	UI:R	S:C
1.2	AV:L	AC:H	PR:L	UI:N	S:C
1.2	AV:N	AC:H	PR:L	UI:R	S:U
1.2	AV:A	AC:H	PR:L	UI:N	S:U
1.2	AV:A	AC:H	PR:N	UI:R	S:C
1.2	AV:A	AC:H	PR:N	UI:R	S:U
1.3	AV:A	AC:L	PR:H	UI:R	S:C
1.3	AV:N	AC:L	PR:H	UI:N	S:U
1.3	AV:N	AC:H	PR:L	UI:R	S:C
1.3	AV:A	AC:H	PR:L	UI:N	S:C
1.4	AV:N	AC:H	PR:H	UI:N	S:C
1.4	AV:L	AC:L	PR:L	UI:R	S:U
1.5	AV:L	AC:H	PR:N	UI:N	S:C
1.5	AV:L	AC:H	PR:N	UI:N	S:U
1.5	AV:L	AC:L	PR:L	UI:R	S:C
1.5	AV:L	AC:L	PR:H	UI:N	S:C
1.6	AV:A	AC:L	PR:L	UI:R	S:U
1.7	AV:N	AC:H	PR:L	UI:N	S:U
1.7	AV:N	AC:H	PR:N	UI:R	S:C
1.7	AV:N	AC:H	PR:N	UI:R	S:U
1.7	AV:A	AC:H	PR:N	UI:N	S:C
1.7	AV:A	AC:H	PR:N	UI:N	S:U
1.7	AV:A	AC:L	PR:L	UI:R	S:C
1.7	AV:N	AC:L	PR:H	UI:R	S:C
1.7	AV:A	AC:L	PR:H	UI:N	S:C
1.8	AV:N	AC:H	PR:L	UI:N	S:C
1.9	AV:L	AC:L	PR:L	UI:N	S:U
1.9	AV:L	AC:L	PR:N	UI:R	S:U
1.9	AV:L	AC:L	PR:N	UI:R	S:C
2.1	AV:L	AC:L	PR:L	UI:N	S:C
2.1	AV:N	AC:L	PR:L	UI:R	S:U
2.1	AV:A	AC:L	PR:N	UI:R	S:C
2.1	AV:A	AC:L	PR:L	UI:N	S:U
2.1	AV:A	AC:L	PR:N	UI:R	S:U
2.3	AV:N	AC:H	PR:N	UI:N	S:U
2.3	AV:N	AC:H	PR:N	UI:N	S:C
2.3	AV:N	AC:L	PR:L	UI:R	S:C
2.3	AV:A	AC:L	PR:L	UI:N	S:C
2.3	AV:N	AC:L	PR:H	UI:N	S:C
2.6	AV:L	AC:L	PR:N	UI:N	S:U
2.6	AV:L	AC:L	PR:N	UI:N	S:C
2.9	AV:N	AC:L	PR:L	UI:N	S:U
2.9	AV:N	AC:L	PR:N	UI:R	S:U
2.9	AV:N	AC:L	PR:N	UI:R	S:C
2.9	AV:A	AC:L	PR:N	UI:N	S:C
2.9	AV:A	AC:L	PR:N	UI:N	S:U
3.2	AV:N	AC:L	PR:L	UI:N	S:C
3.9	AV:N	AC:L	PR:N	UI:N	S:C
3.9	AV:N	AC:L	PR:N	UI:N	S:U

CVSS Exploitability Calculations