FDA Releases Guidance On Cybersecurity In Medical Devices

The digital revolution that resulted in the Internet of Things (IoT), Internet of Medical Things (IoMT), Software as a Medical Device (SaMD), and connected devices permeating the healthcare environment, both in the hospital and at home, comes with the possibility of cyberattacks and intrusions against a compromised connected medical device and the network to which such a device is connected.

Healthcare has been proven to be a valuable target for cyber threat actors (also known as hackers) and medical devices are increasingly the targets of malicious cyberattacks, which result not only in data breaches but also increased healthcare delivery costs, and they can ultimately affect patient health outcomes.¹

The consequences of these attacks, and the corresponding safety and fiscal impacts that can result from them, have prompted many governments agencies and other actors (industry associations, technical societies, standards organizations, research institutions, policy groups, and nongovernmental organizations) to undertake measures to protect themselves and their citizens. In the EU, both the MDR and IVDR requirements mandate consideration of medical device cybersecurity, and the Medical Device Coordination Group (MDCG) in its guidance directs manufacturers on how to fulfil all the relevant essential requirements of Annex I to the MDR and IVDR with regard to cybersecurity.² In Australia, the Therapeutics Goods Administration is treating medical device cybersecurity as part of the Essential Principles and the TGA requires that the cybersecurity “Essential Principles are met by applying accepted best-practice regarding quality management systems and risk management frameworks, which is typically via application of state of the art standards."³

Since 2005, the FDA has been striving to enhance medical device cybersecurity, and the latest FDA effort is a draft guidance that expects security throughout the total product life cycle (TPLC). Another effort is bipartisan congressional support of the Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act of 2022),⁴ which, if passed, would revise the existing Federal Food, Drug, and Cosmetic Act. However, let’s revisit the PATCH Act if/when it gets passed.

The FDA’s draft guidance on medical device cybersecurity provides insight on how the agency is going to apply the existing regulatory requirements. But how does one get ready to meet FDA’s medical device cybersecurity expectations?

First, it is important to understand that the scope of FDA’s guidance is exceptionally broad and covers devices that contain software (including firmware) or programmable logic, as well as SaaMD, and would be expected for:

• Premarket Notification (510(k)) submissions
• De Novo requests
• Premarket Approval Applications (PMAs) and PMA supplements
• Product Development Protocols (PDPs)
• Investigational Device Exemption (IDE)/Humanitarian Device Exemption (HDE) submissions
• All devices within the meaning of the Federal Food, Drug, and Cosmetic Act (FD&C Act), whether or not they require a premarket submission.

Principles Of Medical Device Cybersecurity

The FDA guidance establishes six broad expectations and introduces the newly minted concept of a Secure Product Development Framework (SPDF), which encompasses all aspects of a product’s life cycle, including development, release, support, and decommission to satisfy Quality System Regulations (QSR) in 21 CFR Part 820:

1. Cybersecurity is an integral part of device safety and the QSR
2. Security by design
3. Transparency
4. Security risk management
5. Security architecture
6. Testing/objective evidence

Cybersecurity Is An Integral Part Of Device Safety And The QSR

The FDA guidance sets the nexus between a reasonable assurance of safety and effectiveness for devices with cybersecurity risks and the expectation that such cybersecurity risks are governed by the QSR. The FDA borrows from NIST and introduces a Secure Product Development Framework (SPDF) concept, akin to NIST’s Secure Software Development Framework⁵ and suggests that such integration with product and software development, risk management, and the quality system at large can satisfy cybersecurity QSR. The following principles may be considered the fundamental practices that the FDA had in mind regarding SPDF:

1. Define Security Requirements for Product Development: Ensure that security requirements for product development are known at all times so they can be taken into account throughout TPLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).
2. Implement Roles and Responsibilities: Ensure that everyone inside and outside of the organization involved in the TPLC is prepared to perform their TPLC-related roles and responsibilities throughout the TPLC.
3. Implement Supporting Toolchains: Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the TPLC, as well as provide a way to document and demonstrate the use of these practices.
4. Define and Use Criteria for Product Security Checks: Help ensure that the product resulting from the TPLC meets the organization’s expectations by defining and using criteria for checking the product’s security during development.
5. Implement and Maintain Secure Environments for Product Development: Ensure that all components of the environments for product development are strongly protected from internal and external threats to prevent compromises of the environments or the product being developed or maintained within them.
6. Protect All Forms of Code from Unauthorized Access and Tampering: Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the product.
7. Provide a Mechanism for Verifying Product Release Integrity: Help product/software acquirers ensure that the product/software they acquire is legitimate and has not been tampered with.
8. Archive and Protect Each Product Release: Preserve product/software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the product/software after release.
9. Design Product to Meet Security Requirements and Mitigate Security Risks: Identify and evaluate the security requirements for the product; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived.
10. Review the Product Design to Verify Compliance with Security Requirements and Risk Information: Help ensure that the product will meet the security requirements and satisfactorily address the identified risk information.
11. Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality: Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the product by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.
12. Create Source Code by Adhering to Secure Coding Practices: Decrease the number of security vulnerabilities in the software and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
13. Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security: Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.
14. Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation.
15. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the product is released in order to prevent exploitation.
16. Configure Product to Have Secure Settings by Default: Help improve the security of the product at the time of installation to reduce the likelihood of the product being deployed with weak security settings, putting it at greater risk of compromise.
17. Identify and Confirm Vulnerabilities on an Ongoing Basis: Help ensure that vulnerabilities are identified quickly so they can be remediated quickly in accordance with risk, reducing the window of opportunity for attackers.
18. Assess, Prioritize, and Remediate Vulnerabilities: Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.
19. Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

Security By Design

The FDA guidance sets the expectation that devices must meet the security objectives of authenticity, integrity, authorization, availability, confidentiality, and secure and timely updatability and patchability. The extent to which security requirements are needed to meet these objectives would depend on:

• the device’s intended use and indications for use,
• the presence and functionality of its electronic data interfaces,
• the intended and actual environment of use,
• the type of cybersecurity vulnerabilities present,
• the exploitability of the vulnerabilities, and
• the risk of patient harm due to vulnerability exploitation.

For example, a device would be deemed that it appropriately accounts for authenticity when it evaluates and ensures authenticity for:

1. information at rest (stored),
2. information in transit (transmitted),
3. entity authentication of communication endpoints, whether those endpoints consist of software or hardware,
4. software binaries,
5. integrity of the execution state of currently running software, and
6. any other appropriate parts of the system where a manufacturer’s threat model and/or risk analyses reveal the need for it.

The expectations for demonstrating Integrity (Code, Data or Execution) provide an illustrative example:

Code

1. Verify authentication tags (e.g., signatures, message authentication codes [MACs]) of software/firmware content, version numbers, and other metadata.
2. Install cryptographically authenticated firmware and software updates and do not allow installation where such cryptographic authentication either is absent or fails. Use cryptographically signed updates to help prevent any unauthorized reductions in the level of protection by ensuring that the new update represents an authorized version change.
3. Ensure that the authenticity of software, firmware, and configuration are validated prior to execution, e.g., “allow-listing” based on digital signatures.
4. Disable or otherwise restrict unauthorized access to all test and debug ports (e.g., JTAG, UART) prior to delivering products.
5. Employ tamper evident seals on device enclosures and their sensitive communication ports to help verify physical integrity.

Data

1. Verify the integrity of all incoming data, ensuring that it is not modified in transit or at rest.
2. Validate that all data originating from external sources is well-formed and compliant with the expected protocol or specification. Additionally, validate data ranges to ensure they fall within safe limits.
3. Protect the integrity of data necessary to ensure the safety and effectiveness of the device.

Execution

1. Verify integrity of code while it is being executed on the device.
2. Review all code that handles the parsing of external data using automated (e.g., static and dynamic analyses) and manual (i.e., code review) methods.

Transparency

The FDA guidance concludes that transparency is critical to ensure safe and effective use and integration of devices and systems and such transparency can be conveyed via both device labels and vulnerability management plans.

For devices with cybersecurity risks, FDA also believes that informing users of security information through labeling may be an important part of QSR design controls to help mitigate cybersecurity risks and help ensure the continued safety and effectiveness of the device. A word of caution, however: Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing) to ensure that the user has the capability to take appropriate actions to manage those risks. The FDA outlines the following labeling to communicate security information to users:

1. Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g., anti-malware software, use of a firewall, password requirements).
2. Sufficiently detailed diagrams for users that allow recommended cybersecurity controls to be implemented.
3. A list of network ports and other interfaces that are expected to receive and/or send data.
4. User guidance regarding supporting infrastructure requirements so that the device can operate as intended (e.g., minimum networking requirements, supported encryption interfaces).
5. A Software Bill of Materials (SBOM) in a format for users to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system), and to deploy countermeasures to maintain the device’s safety and effectiveness.
6. A description of systematic procedures for users to download version-identifiable manufacturer-authorized software and firmware, including a description of how users will know when software is available.
7. A description of how the design enables the device to respond when anomalous conditions are detected (i.e., security events) to maintain safety and effectiveness.
8. A high-level description of the device features that protect critical functionality (e.g., backup mode, disabling ports/communications, etc.).
9. A description of backup and restore features and procedures to restore authenticated configurations.
10. A description of the methods for retention and recovery of device configuration by an authenticated authorized user.
11. A description of the secure configuration of shipped devices, a discussion of the risk trade-offs that might have been made about hardening options implemented by the device manufacturer, and instructions for user-configurable changes.
12. A description of how forensic evidence is captured, including but not limited to any log files kept for a security event. Log file descriptions should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software.
13. Technical instructions to permit secure network deployment and servicing, and instructions for users on how to respond upon detection of a cybersecurity vulnerability or incident.
14. Information, if known or anticipated, concerning device cybersecurity end of support and end of life. If the device remains in service following the end of support, the manufacturer should have a preestablished and pre-communicated process for transferring the risks highlighting that the cybersecurity risks for end users can be expected to increase over time.
15. Information on securely decommissioning devices by sanitizing the product of sensitive, confidential, and proprietary data and software.

The FDA guidance further expects that manufacturers institute a formal plan for how they will identify and communicate vulnerabilities that are identified after releasing the device to users. This plan is to be in unison with risk management processes under 21 CFR 820.30(g) and corrective and preventive action processes in accordance with 21 CFR 820.100.

Security Risk Management

“Security risk management should be part of a manufacturer’s quality system.” That is FDA’s expectation and further elucidates that the process for performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019. The FDA guidance sets the expectation that the security risk assessment is to focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system, and the FDA recommends that manufacturers establish a security risk management process that encompasses, at a minimum, design controls, validation of production processes, and corrective and preventive actions to ensure both safety and security risks are adequately addressed. The following security risk management practices are highlighted by the FDA guidance:

Threat Modeling

FDA considers threat modeling “foundational” and an integral part of security risk management. Threat modeling documentation shall ultimately demonstrate how the risks assessed and controls implemented for the system address questions of safety and effectiveness. The FDA guidance sets the following expectations about threat modeling:

• identify system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the security risk assessment,
• state any assumptions about the system or environment of use (e.g., hospital networks are inherently hostile; therefore, manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets), and
• capture cybersecurity risks introduced throughout
  • supply chain,
  • manufacturing,
  • deployment,
  • interoperation with other devices,
  • maintenance/update activities, and
  • decommission activities processes.

3^rd Party Software

The FDA is clear that to demonstrate compliance with quality system design controls and to support supply chain risk management processes, all software, including that developed by the device manufacturer (“proprietary software”) and obtained from third parties, should be assessed for cybersecurity risk and that risk should be addressed. Moreover, manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s cybersecurity requirements. That means that cybersecurity would have to be extended to supplier management practices and documented in the Device Master Record as required by 21 CFR 820.181.

Software Bill of Materials

The FDA guidance places great emphasis on the process and issuance of a Software Bill of Materials (SBOM) and considers the changes in the SBOM as part of the Design History File (21 CFR 820.30) and Device Master Record (21 820.181). Any industry-accepted formats of SBOMs can be used, provided that the following information is included:

1. the asset(s) where the software component resides,
2. the software component name,
3. the software component version,
4. the software component manufacturer,
5. the software level of support provided through monitoring and maintenance from the software component manufacturer,
6. the software component’s end-of-support date, and
7. any known vulnerabilities.

Security Architecture

FDA outlines that manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks or cloud infrastructures and, as such, the FDA draft guidance requires that security architecture information demonstrates that the risks considered during the risk management process are adequately controlled, which, in turn, supports the demonstration of the safety and effectiveness of the medical device system.

The FDA guidance relies on the existing regulatory framework of 21 CFR 820.30(b), (c), and (d) for the expectation that design processes, design requirements, and acceptance criteria for the security architecture of the device holistically address the cybersecurity considerations for the device and the system in which the device operates. An analysis of the entire system is expected, to understand the full environment and context in which the device is expected to operate, and the security architecture is to include a consideration of system-level risks, including but not limited to risks related to the supply chain (e.g., to ensure the device remains free of malware or vulnerabilities inherited from upstream dependencies such as third-party software, among others), design, production, and deployment (i.e., into a connected/networked environment).

In addition to the design control requirements (i.e., 21 CFR 820.30(b), 21 CFR 820.30(c), 21 CFR 820.30(d), and 21 CFR 820.30(g)), FDA recommends, under 21 CFR 820.100, manufacturers develop and maintain security architecture view documentation as part of the process for the design, development, and maintenance of the system. If corrective and preventive actions are identified, these views can be used to help identify impacted functionality and solutions that address the risks.

The FDA recommends providing, at minimum, the following types of security architecture views (both diagrams and explanatory text) in premarket submissions:

• Global System View,
• Multi-Patient Harm View,
• Updateability/Patchability View, and
• Security Use Case View(s).

Each of these security architecture views are to:

• identify security-relevant system elements and their interfaces,
• define security context, domains, boundaries, and external interfaces of the system,
• align the architecture with:
  • system security objectives and requirements,
  • security design characteristics, and

• establish traceability of architecture elements to user and system security requirements.

Cybersecurity Testing/Objective Evidence

The FDA draft guidance, under the existing QSR, declares that verification and validation activities shall include sufficient testing performed on the cybersecurity of the system through which the manufacturer verifies and validates their inputs and outputs. The FDA further summarizes that cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness. The following cybersecurity testing and corresponding objective evidence would be considered the minimum that may support a premarket submission:

• Security requirements
  • Evidence that each design input security requirement was implemented successfully.
  • Evidence of their boundary analysis and rationale for their boundary assumptions.
• Threat mitigation
  • Evidence of testing that demonstrates effective risk control measures according to the threat models provided in the system, use case, and call-flow views.
  • Evidence of the adequacy of each cybersecurity risk control.
• Vulnerability testing – Evidence on the testing of:
  • Abuse case, malformed and unexpected inputs
    • Robustness
    • Fuzz testing
  • Attack surface analysis
  • Vulnerability chaining
  • Closed box testing of known vulnerability scanning
  • Software composition analysis of binary executable files
  • Static and dynamic code analysis, including testing for credentials that are “hardcoded,” default, easily guessed, and easily compromised.
• Penetration testing – Identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product.
• Regular interval cybersecurity testing – Performed at regular intervals to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.

Summary

The FDA’s medical device cybersecurity guidance would require that manufacturers’ devices with software, firmware, or programmable logic, as well as software as a medical device (SaMD), minimize the cybersecurity risks associated with the design, safety, and use of those devices. Manufacturers would have to generate and maintain evidence regarding the quality management systems and risk management frameworks used to manage medical device cybersecurity to demonstrate compliance. Overall, the FDA understands that the cybersecurity threat landscape is rapidly evolving and requires constant monitoring and appropriate corrective and preventive action from medical device manufacturers, alongside timely communication to medical device users to establish their awareness of cybersecurity threats. Interested stakeholders can submit comments on this draft guidance for FDA’s consideration until July 7, 2022, to Docket No. FDA-2021-D-1158 available at https://www.regulations.gov/docket/FDA-2021-D-1158.

About The Author:

John Giantsidis is the president of CyberActa, Inc, a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, regulatory compliance, and commercialization endeavors. He is the vice chair of the Florida Bar’s Committee on Technology and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in cybersecurity policy and compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.