.png){kind=logo}
FDA Medical Device Threat Modeling and Cybersecurity Risk Assessment
We’ve previously shared an overview of the general expectations of the FDA when it comes to cybersecurity documentation [1]. In this post, we will share practical tips on implementing important elements to support a major part of that documentation: your Threat Model and Vulnerability Assessment.
Note that your Threat Model acts as an input to your Cybersecurity Risk Assessment. In some cases, they are separate documents; in others, they are part of a single document.
As we previously explained, a complete threat model should address four basic questions [2]:
- What are we building?
- What can go wrong? (e.g., how could it be attacked?)
- What are we going to do about that?
- Did we do a good enough job?
The actual approach for addressing and documenting your threat model and cyber risk assessment looks different for every device manufacturer and their specific medical device implementation. There is no universally established technique for approaching this task—it depends on factors such as the device itself, the development team’s expertise, and your organization’s available resources. The methodology described in this post is one example we’ve found to be successful for addressing threat modeling documentation required as part of a 510(k) submission.
Threat Modeling Overview
When addressing the FDA’s requirements, your threat modeling documentation should, at a minimum, do the following [3]:
- Provide threat modeling for the entire medical device system, including all end-to-end connections into and out of the system. This includes elements such as hospital networks, cloud infrastructure, and update mechanisms, as well as exempted functionalities per the 21st Century Cures Act.
- Identify system risks and mitigations to inform the pre- and post-mitigation risks considered in the cybersecurity risk assessment.
- State assumptions about the medical device system or environment of use, such as whether the environment is inherently hostile.
- Capture risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance, updates, and decommissioning.
- Include the rationale for the selected threat modeling methodology.
Developing a Software Architecture
A logical starting point for threat modeling is to define your software and its architecture. Create software architecture diagrams that:
- Capture all software components in your product.
- Describe how these components work together.
- Detail data flow and how external users interact with the software.
This documentation can be included in your Software Design Specification (SDS). Refer to the FDA’s guidance document "Content of Premarket Submissions for Device Software Functions" [4] for details on the FDA’s expectations. By establishing these documents, you address the first question of your threat model: “What are we building?”
The FDA also expects detailed information on implemented cybersecurity controls. It’s helpful to dedicate a section of your SDS to this topic. Early in the process, you may not know all the controls you’ll implement, so iterate as your cybersecurity risk analysis evolves. Section V.B.1 and Appendix 1 of the FDA’s Cybersecurity Guidance [5] provide examples of controls. If you choose not to implement a specific control mentioned in the guidance, include a justification in your documentation.
Cybersecurity Risk Analysis
Once you have a clear understanding of your product, define the threat methodology you’ll use to answer, “What can go wrong?” Examples of methodologies include AAMI TIR57 [6], STRIDE, Attack Trees, Kill Chain, and DREAD. Document your chosen methodology in your FDA submission.
Using your methodology, identify potential threats and scenarios relevant to your device. From there, conduct your cybersecurity risk analysis. This iterative process involves stakeholders and systematically addresses identified threats. Unlike ISO 14971 [7], which is used for safety risk analysis, cybersecurity risk estimation focuses on exploitability and impact using qualitative scales. Examples include:
Exploitability Scale
Impact Scale
Risk Calculation Scale
For more detailed scoring, consider the MITRE CVSS rubric [8]. It provides a structured approach for applying the Common Vulnerability Scoring System (CVSS) to medical devices.
Vulnerability Assessment and SBOM
The Software Bill of Materials (SBOM) is a key component of threat modeling and addresses “What are we building?” Your SBOM should include:
- Manufacturer-developed and third-party components (including open-source software).
- Upstream software dependencies.
- Identification of critical components and their vulnerabilities.
- Assessment of whether vulnerabilities are exploitable within your device’s implementation.
Dependencies with critical and exploitable vulnerabilities should undergo further risk analysis. If a dependency is not considered critical, document your rationale.
Refer to AAMI TIR57 and the FDA’s Postmarket Cybersecurity Guidance [9] for detailed methodologies and examples.
Practical Example
For example, consider a wearable glucose monitor. Threat modeling might identify a scenario where an attacker intercepts Bluetooth communication between the device and a mobile app. Mitigations could include encrypting all wireless communication and implementing authentication protocols to prevent unauthorized access.
Closing Thoughts
Systematic threat modeling and cybersecurity risk assessment are critical components of a successful FDA submission. These efforts help manufacturers identify vulnerabilities, mitigate risks, and ensure the safety and security of their devices.
We encourage manufacturers to share their experiences with cybersecurity documentation and FDA submissions. Have questions or need support? Contact us at info@cosmhq.com for templates or tailored guidance. You can checkout our Shopify store for digital templates and guides you can purchase and download here - https://cosmhq.myshopify.com/
REFERENCES
- [1] Cosm’s FDA Cybersecurity Guidance blog post - www.cosmhq.com/resources-posts/summary-of-fda-cybersecurity-guidance-for-medical-devices
- [2] https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
- [3] FDA eStar template, https://www.fda.gov/medical-devices/how-study-and-market-your-device/estar-program
- [4] June 2023 Guidance for Industry and Food and Drug Administration Staff, Content of Premarket Submissions for Device Software Functions, https://www.fda.gov/media/153781/download
- [5] September 2023 Guidance for Industry and Food and Drug Administration Staff, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, https://www.fda.gov/media/119933/download
- [6] https://webstore.ansi.org/Standards/AAMI/aamitir572016
- [7] https://www.iso.org/standard/72704.html
- [8] https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
- [9] FDA Postmarket Cybersecurity Guidance - Postmarket Management of Cybersecurity in Medical Devices - https://www.fda.gov/media/95862/download
---
Main Image Source: Created with assistance from ChatGPT, powered by OpenAI
Disclaimer - https://www.cosmhq.com/disclaimer
