FDA Releases Guidance On Cybersecurity In Medical Devices

John Giantsidis, president, CyberActa, Inc., wrote in the current issue of meddeviceonline: “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.2 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),4 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 Framework5 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

    Verify authentication tags (e.g., signatures, message authentication codes [MACs]) of software/firmware content, version numbers, and other metadata.

    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.

    Ensure that the authenticity of software, firmware, and configuration are validated prior to execution, e.g., “allow-listing” based on digital signatures.

    Disable or otherwise restrict unauthorized access to all test and debug ports (e.g., JTAG, UART) prior to delivering products.

    Employ tamper evident seals on device enclosures and their sensitive communication ports to help verify physical integrity.

Data

    Verify the integrity of all incoming data, ensuring that it is not modified in transit or at rest.

    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.

    Protect the integrity of data necessary to ensure the safety and effectiveness of the device.

Execution

    Verify integrity of code while it is being executed on the device.

    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.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801