There has been an alarming increase in cyber attacks on hospitals and healthcare technology in recent years. In response, the FDA has been repeatedly raising the bar for medical device cybersecurity. As of October 1st, 2023, the bar was just raised considerably higher. So what does this mean for your company’s quality system and product team? What’s changed, and what should the team be doing? What new documentation is needed in submissions? I’ll summarize here some key concepts in the new FDA cybersecurity guidance and discuss six key requirements.
FDA released this new cybersecurity guidance: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions on September 27, 2023. This new guidance replaces the earlier cybersecurity premarket guidance documents from 2014, 2018, and 2022. The new guidance, at 57 pages, is more detailed than previous guidances, has more requirements, and has a broader scope. The requirements of this guidance are not limited to connected devices; they also apply to “potentially connected” devices. In other words, even if a manufacturer does not intend for a new medical device to be connected to the internet, a USB port on the back of the enclosure could connect it and trigger security concerns. “The guidance is not limited to devices that are network-enabled or contain other connected capabilities.” and “…the recommendations in this guidance also apply to devices for which a premarket submission is not required (e.g., for 510(k)-exempt devices).” Further, the new requirements apply to any resubmissions for updates to legacy products (adequate cybersecurity documentation for legacy devices will be especially challenging).
Key Concepts
Goals: Ensure that medical devices are designed securely and are designed to be capable of mitigating emerging cybersecurity risks throughout the product life cycle (not just at product launch).
Secure Product Development Framework (SPDF)
Let’s start with more acronyms (woo-hoo!). The guidance requires companies to establish what the FDA calls a Secure Product Development Framework (SPDF)–a set of processes that reduce the number and severity of vulnerabilities in the medical devices they produce. For decades, we’ve defined processes in a Quality Management System (QMS) to produce safe medical devices. That paradigm has changed: now, medical device companies need to incorporate an SPDF into their QMS to ensure safe and secure medical devices:
Traditional QMS → safe medical device
QMS + SPDF → safe and secure medical device
In reality, this doesn’t mean creating a totally new set of SOPs in your quality system. It means integrating security activities and controls into appropriate points throughout your product development process. I consider this analogous to human factors/usability engineering where just doing some testing at the end of development is not enough to meet FDA expectations. Likewise, just adding some encryption to a new medical device and doing some testing at the end of development is not enough to make your device secure.
New Methods for Risk Assessment
Security risk management is not the same as safety risk management. For those of us who have spent many years practicing risk management per the ISO 14971 risk management standard, this means learning some new methods and tools such as threat modeling, security risk assessment, and vulnerability scanning. For example, security risk assessment utilizes exploitability, or the ability to exploit vulnerabilities present within a product, instead of probability, which is used in safety risk management (ISO 14971). The two approaches to risk management are complementary but not independent. The outputs of security risk assessment can be inputs to safety risk assessment (a cyber attack causes unpredictable behavior of a medical device) and vice versa (an emergency access feature could affect security controls).
Transparency and Communication
Medical device manufacturers must communicate security information with all their customers to ensure security throughout the product’s lifetime. Security communication includes:
- At the time of sale,
- Delivering clear instructions to customers about how to install or configure the medical device to maintain security in its intended operating environment.
- Documenting all product interfaces
- Providing an electronic SBOM
- Documenting any known cybersecurity vulnerabilities
- Responding to a security incident,
- Quickly notifying customers of the incident with instructions for how to counteract/protect against the vulnerability
- Providing security patches to the product software in a timely manner with instructions on how to securely install the patch
Note that discovering vulnerabilities in your medical device post-launch is a matter of “when” not “if” so be prepared for how to communicate this information as part of your incident response procedure.
Security in Operation / TPLC
Ensuring a new medical device is secure at product launch is only half the job. Medical device manufacturers must take a total product life cycle (TPLC) approach to cybersecurity. This extends to the end of the product life and involves many more departments than just those involved in product development. [“The TPLC processes include design and development, manufacturing, postmarket monitoring, delivering device software and firmware updates, and servicing, among others.”]
The TPLC approach also involves regular software monitoring and tracking of security metrics. At a minimum, the FDA recommends tracking the following measures and metrics, or those that provide equivalent information:
- Percentage of identified vulnerabilities that are updated or patched (defect density);
- Duration from vulnerability identification to when it is updated or patched; and
- Duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known.
So, with these security concepts in mind, let’s look at some key requirements in the new FDA guidance (and yes, these new requirements will translate into new documentation; we’ll cover that in the following section).
Security Risk Management
Threat Modeling
Threat modeling can be summed up in four key questions (see also the Threat Modeling Manifesto):
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
“A well-developed threat model will document how a system is intended to function, justify trade-offs made in the design process, identify remaining threats to the system, and explain what mitigations are in place against them. This encompasses both the premarket development phase of the system and the postmarket maintenance phase.” (MITRE Threat Modeling Playbook) The threat model should be regularly reassessed throughout development (for example, included in design reviews).
Cybersecurity Risk Assessment
- Distinct from safety risk assessment (but some outputs can become inputs to the safety risk assessment process)
- Uses exploitability instead of probability
- Based on the security risks and controls identified from the threat model
- Includes all software components, including OTS software (with supply chain risk management of software suppliers)
Vulnerability Assessment of OTS Software
- Vulnerability scanning
- Documentation and maintenance of a Software Bill of Materials (SBOM)
Security Assessment of Unresolved Anomalies
- Anomalies (software defects) can present a different vector to safety risks through cybersecurity
- At software release, analyze both the security impact as well as the safety impact of any remaining software defects (open bug list)
Security Controls
The FDA guidance organizes different security controls into the following 8 categories (Appendix 1 of the guidance describes each category):
- Authentication;
- Authorization;
- Cryptography;
- Code, Data, and Execution Integrity;
- Confidentiality;
- Event Detection and Logging;
- Resiliency and Recovery; and
- Updatability and Patchability.
Updateability/Patchability
Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product’s lifecycle.” Basically, this is admitting that there’s no way to guarantee that a device that is secure at the time of product launch will remain secure throughout its lifetime (we live in a world of evolving cybersecurity threats). Therefore, we want to design devices to enable software updates. Ideally, this would be via Over-The-Air updates (OTA), but for some medical equipment, a manual process executed by service personnel may be adequate. Regardless of the method, the designers must ensure that the software updates are secure (i.e. don’t introduce new vulnerabilities).
Updateability is a challenging requirement, and some medical devices will simply not be updateable. For those devices, the only means of resolving a serious security vulnerability in the future will be a recall (translation: tell the product team to try really hard to design a means to update the software).
Software Bill of Materials (SBOM)
An SBOM is analogous to the list of ingredients on a product you buy in a grocery store: it enables consumers to know what they are consuming (and to avoid ingredients they don’t want, like Red Dye #37). When a vulnerability is discovered in a particular software component, an SBOM helps facilitate security risk management by providing a mechanism to identify devices and the systems in which they operate that might be affected by the vulnerability. This can happen both during development when software is being chosen as a component and after product launch.
An SBOM should:
- Include both the device manufacturer-developed software components and third-party software components,
- Include purchased/licensed software and open-source software, and the upstream software dependencies that are required/depended upon by proprietary, purchased/ licensed, and open-source software
- Be formatted per NTIA format (or equivalent)
- Be regularly updated with software releases (i.e. generated automatically from software development tools)
- Be provided in human readable (text) and machine readable formats
Security Testing
Security testing during development is multi-faceted and is performed in addition to other software testing (i.e. testing per the IEC 62304 medical software standard). Security testing includes all of the following:
- static and dynamic analysis of code
- code reviews against secure coding standards
- vulnerability scanning of software components and systems
- software verification testing of the security requirements at a module or system level
- threat mitigation testing (demonstrating security controls are effective per the threat model)
- testing interfaces with external systems
- penetration testing (“pentest”) is conducted on the full system by a third party.
Some or all of these types of security testing should be repeated after each software upgrade to ensure that code changes or configuration changes do not undermine security.
Cybersecurity Documentation
These cybersecurity documents are required for FDA submissions (in addition to the required software documentation). Note that the level of documentation should be based on the level of cybersecurity risks, not safety risks.
| Document | Description |
|---|---|
| Security Risk Management Plan | A description of the security activities and deliverables during product development, including roles, responsibilities, and resources |
| Cybersecurity Risk Analysis | A security risk assessment of the product being developed in its context of usage, including threat modeling |
| Security Architecture | Defines the system and its interfaces, with high-level definitions of the devices and/or systems that interact and design information on how those interactions occur and are secured |
| Software Bill of Materials (SBOM) | A formal inventory of software components and dependencies, information about those components, and their hierarchical relationships |
| Security Assessment of Unresolved Anomalies | An analysis of the open bug list from a security viewpoint; can be combined with an existing Unresolved Anomalies Report (with safety risk assessments) |
| Security Risk Management Report | The report summarizes the risk evaluation methods and processes, describes the risk mitigation activities and residual security risk, and provides traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation |
| Security Management Plan | The post-market plan for maintaining device security |
Medical Device Cybersecurity Links
FDA Digital Health – Cybersecurity – main page on FDA website for cybersecurity information
Postmarket Management of Cybersecurity in Medical Devices (DEC 2016) – Final FDA guidance for maintaining security postmarket (complementary to the new premarket guidance)
Demystifying the FDA Cyber Guidance – recorded presentation by Seth Carmody, VP Regulatory Strategy at MedCrypt and previously Cybersecurity Program Manager at FDA (MAY 2022)
Inside Look at New FDA Cyber Guidance – recorded interview by govinfosecurity.com with Jessica Wilkerson, Senior Cyber Policy Advisor at FDA (9/29/2023)
MITRE Playbook for Threat Modeling – white paper on methods and examples of threat modeling for medical devices; sponsored by FDA (2021)
Why Healthcare Security Is Hard – big picture (context) article by Seth Carmody of MedCrypt (2021)
Links about SBOM management
Introduction to SBOMs – by Nova Leah
SBOM – Best Practices, FAQs, and Examples – by Innolitics (OCT 2023)
SBOM Myths and Facts – by NTIA.gov
Security Benefits of SBOM – by Nova Leah
SBOMs for Medical Devices – discussion with Dr Kevin Fu (previously Acting Director FDA CDRH Cybersecurity) on the ReversingLabs blog (2022)
IMDRF Guidance on SBOM – draft guidance on preparing and managing an SBOM by the IMDRF group (JUN 2022)
Even More Links
Redline of Final vs. Draft FDA Cyber Guidance – convenient line-by-line comparison of the APR 2022 draft with the SEP 2023 final guidance document by Innolitics
Using Microsoft Threat Modeling Tool – description of how to use this free tool
Vulnerability Metrics – explanation of CVSS and other security scoring schemes from NIST website
State of Cybersecurity Report 2023 – MedISAO (from H-ISAC)
What the C-Suite Needs to Know about Security – Forbes article by Mike Kijewski of Medcrypt (2022)
MedTech Good Cyber Practices – article by Shannon Lantzy of Medcrypt (2022)
Microsoft Secure Development Lifecycle – set of articles explaining SDL practices and tools
Secure Coding Guides – from Christian Rosenzweig (2023):
- OWASP Developers Guide – guidelines from the OWASP organization
- Berkeley Info Security Office – guidelines from UC Berkeley
- Secure Coding Standards – guidelines from Perforce
Links about Cybersecurity Standards
AAMI TIR57:2016 Principles for medical device security—Risk management: guidance on addressing security risk during product development.
IEC-81001-5-1 Health software and health IT systems safety, effectiveness and security Part 5-1: Security Activities in the product life cycle (2021)
AAMI SW96:2023 – article about this new standard in AAMI Array (Jun 2023)
The AAMI Medical Device Security Working Group recently developed a new standard on security risk management for device manufacturers:
ANSI/AAMI SW96 is the first consensus standard to provide specific requirements for managing security across a product’s entire life cycle. The new standard document, released earlier this year, is based on guidance previously published in AAMI’s TIR57:2016 and TIR97:2019.