Brett Todd, Systems Engineering Director, Full Spectrum06.03.24
ANSI/AAMI SW96:2023, “Standard for medical device security—Security risk management for device Manufacturers” has been recognized by FDA as a recommended standard for security risk management. FDA has stated that the standard “provides direction to sponsors on how to consider and address cybersecurity risks in device design and development.”1
Note: In this article, security and cybersecurity are meant to be interchangeable terms as defined in ANSI/AAMI SW96:2023.2
At a high level, ANSI/AAMI SW96:2023 defines the security risk management process as follows:
This process is well defined in ANSI/AAMI SW96:2023 in terms of “what” should be done However, for those new to the standard (and security risk management in general), additional guidance on “how” to execute the process may be needed. This article is meant to help fill that gap by providing guidance and tips for how to best identify and document security risks and related controls
After the format for the Security Risk Assessment is agreed upon, the current security risks and controls for similar products (both internal and competitive products) should be understood. The following aspects should be considered for similar products:
Including each named asset in the security risk assessment and organizing the assessment by asset allows an easy check to ensure that all assets have been included. This can be simply performed by ensuring that all assets in the security architecture document are included. If some assets are overlooked, critical security issues may not be analyzed and controlled.
After the assets are identified, the next step is to systematically analyze and identify different security threats with respect to each asset. For the threat analysis, using the STRIDE model (an acronym named from the various threat types) can be very useful, as its use helps ensure a comprehensive list of possible threats is identified and analyzed STRIDE categorizes threats as follows:
For each asset, consider each of the STRIDE threat types by asking the question “Could an attacker use this threat type to impact this asset if controls are not in place?”. If the answer is “Yes” update the security risk assessment to include the specific threat If the answer is “No” provide rationale in the assessment
FDA guidance states “cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling.”4 This guidance also states “security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.”5
Exploitability can be applied by simply assuming that the attack will occur regardless of factors such as motivation of the attacker or value of the asset. An exploitability scale should then be applied to rank the ease with which an attack can be used to exploit a vulnerability to impact an asset. The Common Vulnerability Scoring System (CVSS) breaks exploitability into five different factors: Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, and User Interaction.6 However, it is not practical to score each line in the security risk assessment with each of these factors. Therefore, a simplified scale as shown below is recommended.
Once a viable security threat is identified and the exploitability is estimated, the next step is determining the potential impact of that threat. The impact should be determined first based on the potential effect on the clinical use of the product. For example, assume an infusion pump can accept a new configuration file with default infusion program values over a Wi-Fi connection. If the configuration data is not encrypted, an attacker could capture the data and make modifications to the configuration file transmitted. This threat could potentially lead to over-delivery of medication to the patient if default programming values or limits are modified. This should then be identified as a high-severity threat
When threats with clinical impact are identified, the severity should be consistent with the product risk assessment. The easiest way to ensure consistency is to use a common severity scale between the product risk assessment and the security risk assessment for threats that have clinical impact.
Some threats may not impact patient safety but may significantly impact the business. Examples include the theft of patient information (HIPPA violation), theft of proprietary information, or downtime of the system (causing customer dissatisfaction). These threats need to be captured in the security risk assessment but should be clearly differentiated from those that can lead to patient harm.
Each security threat with potential safety impact should have one or more security controls identified. High risk threats for business-only impact should have controls defined as well. If controls cannot be identified, rationale should be provided. The scope and effectiveness of control should align with a security risk scale; higher risks need more assurance that the attack can be prevented or mitigated. The information previously collected for similar products can be very useful when considering the type and scope of controls needed.
The security risk scale should be based on the exploitability of the attack / vulnerability and the severity of the end effect. An example of such a scale is provided below.
Once the security risk assessment is compiled, the risk rankings can be used to further focus on the highest risk areas collectively to determine if further controls should be considered
FDA guidance identifies the following standard control categories7:
Finally, each control should be assigned a unique identifier in the assessment and traced to a requirement, design specification, or process specification. The requirements and specifications should be further traced to a test or inspection This trace matrix can then be used to demonstrate that all security controls have been implemented and tested
References
Brett Todd is a Systems Engineering Director at Full Spectrum. Brett has been developing medical products for 29 years while serving in various technical roles including software developer, lead systems designer, and project manager He is passionate about product safety, well-defined requirements, and carefully considered architecture (his tenets of good medical product design) You can contact Brett at btodd@fullspectrumsoftware.com.
Note: In this article, security and cybersecurity are meant to be interchangeable terms as defined in ANSI/AAMI SW96:2023.2
At a high level, ANSI/AAMI SW96:2023 defines the security risk management process as follows:
This process is well defined in ANSI/AAMI SW96:2023 in terms of “what” should be done However, for those new to the standard (and security risk management in general), additional guidance on “how” to execute the process may be needed. This article is meant to help fill that gap by providing guidance and tips for how to best identify and document security risks and related controls
Preparatory Work
Before starting to evaluate security risks and controls, stakeholders in the security risk management process should agree on a format for documenting this information (referred throughout this document as the Security Risk Assessment). A table format in a spreadsheet tool is recommended as this allows for filters and look-up functions to be applied to assist with the review and creation of content as needed. An example of typical column headings in the Security Risk Assessment is shown below.Table 1 – Example Columns in a Security Risk Assessment
ID # | Asset | Threat | Attack Vector | Impact & Severity | Pre-Exploitability | Pre-Risk | Controls | Post-Exploitability | Post-Risk |
After the format for the Security Risk Assessment is agreed upon, the current security risks and controls for similar products (both internal and competitive products) should be understood. The following aspects should be considered for similar products:
- The communication interfaces that are present.
- The types of security features that are implemented (and not implemented).
- Any known / published security vulnerabilities or issues.
- Publicly available product information, including instructional videos and user manuals.
- News articles (including coverage of lawsuits) and recall information published by FDA.
- Vulnerabilities in the National Vulnerability Database (NVD) available on the National Institute of Standards and Technology (NIST) website.
Guidance and Tips for Content
There are different methods that can be used to organize the security risk assessment. The easiest method to demonstrate completeness of the assessment is to organize by assets. Assets should be identified in a security architecture document as elements of the product that have value to the user, patient, and business that are relevant to security. Typically, assets will include:- The product’s clinical value in terms of proper operation and availability.
- Data stored on the product, including therapy information, Protected Health Information (PHI), and configuration data.
- Data communicated by the product.
- Software / firmware installed on the product.
Including each named asset in the security risk assessment and organizing the assessment by asset allows an easy check to ensure that all assets have been included. This can be simply performed by ensuring that all assets in the security architecture document are included. If some assets are overlooked, critical security issues may not be analyzed and controlled.
After the assets are identified, the next step is to systematically analyze and identify different security threats with respect to each asset. For the threat analysis, using the STRIDE model (an acronym named from the various threat types) can be very useful, as its use helps ensure a comprehensive list of possible threats is identified and analyzed STRIDE categorizes threats as follows:
Table 2 – STRIDE Definitions3
Threat | Threat Definition | Desired property |
Spoofing | Pretending to be something or someone other than yourself (e.g. using another user's authentication information, such as username and password). | Authenticity |
Tampering | Modifying data while stored (temporary or persistent) or while being transferred. | Integrity |
Repudiation | Removing the ability to track actions or operations. | Identifiable / Traceable |
Information Disclosure | Obtaining or exposing information without proper authorization. | Confidentiality |
Denial of Service | Blocking access or service, usually by exhausting resources or overloading a communication interface. | Availability |
Elevation of Privilege | Allowing someone to perform an action or access data without proper authorization rights. | Authorization |
For each asset, consider each of the STRIDE threat types by asking the question “Could an attacker use this threat type to impact this asset if controls are not in place?”. If the answer is “Yes” update the security risk assessment to include the specific threat If the answer is “No” provide rationale in the assessment
FDA guidance states “cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling.”4 This guidance also states “security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.”5
Exploitability can be applied by simply assuming that the attack will occur regardless of factors such as motivation of the attacker or value of the asset. An exploitability scale should then be applied to rank the ease with which an attack can be used to exploit a vulnerability to impact an asset. The Common Vulnerability Scoring System (CVSS) breaks exploitability into five different factors: Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, and User Interaction.6 However, it is not practical to score each line in the security risk assessment with each of these factors. Therefore, a simplified scale as shown below is recommended.
Table 3 – Example Exploitability Scale
Exploitability Level | Description |
Very Easy | Anyone (even those with no technical knowledge) could exploit the vulnerability with very little effort Example: Attacker accesses a webpage that does not automatically logout a user after a timeout period and views patient data. |
Easy | Anyone with basic computer skills could exploit the vulnerability with little effort Example: Attacker connects to the hospital network and copies uncontrolled data. |
Average | Anyone with more advanced computer skills and/or access to special tools or information could exploit the vulnerability Example: Attacker uses a publicly available tool to capture and decode Bluetooth communication and then sends commands to a device. |
Difficult | Requires high technical ability / expertise to find and exploit the vulnerability Example: Attacker downloads firmware from a device, reverse engineers the code and makes modifications, then distributes the firmware back to the device. |
Near Impossible | Special knowledge or highly restricted access would be required to circumvent security controls Example: Attacker decrypts data by obtaining access to an encryption key stored in a highly secured area. |
Once a viable security threat is identified and the exploitability is estimated, the next step is determining the potential impact of that threat. The impact should be determined first based on the potential effect on the clinical use of the product. For example, assume an infusion pump can accept a new configuration file with default infusion program values over a Wi-Fi connection. If the configuration data is not encrypted, an attacker could capture the data and make modifications to the configuration file transmitted. This threat could potentially lead to over-delivery of medication to the patient if default programming values or limits are modified. This should then be identified as a high-severity threat
When threats with clinical impact are identified, the severity should be consistent with the product risk assessment. The easiest way to ensure consistency is to use a common severity scale between the product risk assessment and the security risk assessment for threats that have clinical impact.
Some threats may not impact patient safety but may significantly impact the business. Examples include the theft of patient information (HIPPA violation), theft of proprietary information, or downtime of the system (causing customer dissatisfaction). These threats need to be captured in the security risk assessment but should be clearly differentiated from those that can lead to patient harm.
Each security threat with potential safety impact should have one or more security controls identified. High risk threats for business-only impact should have controls defined as well. If controls cannot be identified, rationale should be provided. The scope and effectiveness of control should align with a security risk scale; higher risks need more assurance that the attack can be prevented or mitigated. The information previously collected for similar products can be very useful when considering the type and scope of controls needed.
The security risk scale should be based on the exploitability of the attack / vulnerability and the severity of the end effect. An example of such a scale is provided below.
Table 4 – Security Risk Ranking Matrix
Exploitability |
Severity (Patient Safety / Business Impact) | ||||
S1 | S2 | S3 | S4 | S5 | |
Very Easy | Low | Moderate | High | Very High | Very High |
Easy | Low | Moderate | High | High | Very High |
Average | Low | Moderate | Moderate | High | High |
Difficult | Very Low | Low | Moderate | Moderate | High |
Near Impossible | Very Low | Low | Low | Moderate | Moderate |
Once the security risk assessment is compiled, the risk rankings can be used to further focus on the highest risk areas collectively to determine if further controls should be considered
FDA guidance identifies the following standard control categories7:
- Authentication
- Authorization
- Cryptography
- Code, Data, and Execution Integrity
- Confidentiality
- Event Detection and Logging
- Resiliency and Recovery
- Firmware and Software Updates
Finally, each control should be assigned a unique identifier in the assessment and traced to a requirement, design specification, or process specification. The requirements and specifications should be further traced to a test or inspection This trace matrix can then be used to demonstrate that all security controls have been implemented and tested
Review and Maintenance
The security risk assessment will contain a lot of information which can create difficulty in evaluating a more holistic view of the overall security risk. Some methods and related questions to evaluate the soundness of the analysis include:
Filter the risks to show those with the highest risk.
- Are there any uncontrolled high-risk vulnerabilities?
- Do the highest risk items seem logical?
- Are there any risks that would be expected to be higher risk that are absent from the filtered list?
- Is there a significant reduction in risk overall due to the security controls?
- Filter for risks with no security controls.
Once complete, the security risk assessment should never be viewed as a one-time activity required prior to product clearance and launch. Much like a product risk assessment, the security risk assessment should be maintained throughout the life of the product. The assessment may require updates due to events such as:
- A new vulnerability is reported in off-the-shelf software used in the product.
- A customer reports a security event that impacts the product use.
- A similar product has a publicized vulnerability that is applicable.
- Product changes are made that may introduce new vulnerabilities and potential vulnerabilities
Conclusion
Creating and maintaining a security risk assessment can be challenging. By following the tips and guidance provided, this challenge can be lessened. More importantly, these tips and guidance will help ensure that the product security risk is appropriately characterized and controlled to enable the development and distribution of a safe and successful product.References
2 Annex A - ANSI/AAMI SW96:2023, “Standard for medical device security—Security risk management for device Manufacturers
3 Microsoft’s STRIDE Threat Model, Article 11/12/2009
4 FDA Guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 27, 2023), Page 14.
5 FDA Guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 27, 2023), Page 14.
6 Common Vulnerability Scoring System version 4.0 Specification Document 1.1, page 7.
7 FDA Guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 27, 2023), Pages 32-40.
Brett Todd is a Systems Engineering Director at Full Spectrum. Brett has been developing medical products for 29 years while serving in various technical roles including software developer, lead systems designer, and project manager He is passionate about product safety, well-defined requirements, and carefully considered architecture (his tenets of good medical product design) You can contact Brett at btodd@fullspectrumsoftware.com.