2018 FDA Draft Guidance - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices

Warning 🔗

This guidance is obsoleted by the Draft Guidance issued on April 8, 2022: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.

Introduction 🔗

In October of 2018 the FDA released a draft cybersecurity guidance, "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices," which is meant to replace its 2014 guidance with the same name. As of August 2021, the guidance is still a draft.

Although most medical device engineers will find the guidance easy to read, it's long and has some irrelevant content. For example, the FDA traces their authority back to the various legal statutes. This article prunes, summarizes, and reorganizes the original guidance documents to make it easier for software engineers to read. Here's a link to the [actual guidance](https://www.fda.gov/media/119933/download) if you need the details.

Thank you to everyone at the FDA for their efforts to keep patients safe and make device manufacturers' jobs as easy as possible through these guidance documents.

If you're overwhelmed by regulations, guidance documents, and standards, we can help. We provide turn-key engineering solutions with cybersecurity best practices built into our standard agile processes using our open-source regulatory documentation manager. Contact us if you'd like a team that helps bring your device to the market as quickly as possible. If you have an engineering team, we can also help you with cybersecurity.

Motivation 🔗

The need for effective cybersecurity to ensure medical device functionality and safety has become more important with the increasing use of wireless, Internet- and network-connected devices, portable media (e.g. USB or CD), and the frequent electronic exchange of medical device-related health information. In addition, cybersecurity threats to the healthcare sector have become more frequent, more severe, and more clinically impactful. Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the US and globally. Such cyberattacks and exploits can delay diagnoses and/or treatment and may lead to patient harm.

The FDA recommends industry utilize the FDA presubmission process to discuss design considerations for meeting adequacy of cybersecurity risk management throughout the device life-cycle.

Cybersecurity risk tiers 🔗

The FDA classifies devices into two cybersecurity tiers. A device is Tier 1, "Higher Cybersecurity Risk," if the following criteria are both met:

1. The device is capable of connecting to another medical or non-medical product, or to a network, or to the Internet

2. A cybersecurity incident affecting the device could directly result in patient harm to multiple patients

A device is Tier 2, "Standard Cybersecurity Risk," if it doesn't meet the criteria to be Tier 1.

Cybersecurity design controls 🔗

Premarket submissions for Tier 1 devices should demonstrate how the device design and risk assessment incorporate the design controls listed below. Tier 2 devices may provide a risk-based rationale for why specific design controls are not appropriate.

Limit access to trusted users & devices only 🔗

• Limit access to devices through the authentication of users
• Use automatic timed methods to terminate sessions within the system where appropriate for the use environment.
• Employ a layered authorization model by differentiating privileges based on the user role or device functions.
• Use appropriate authentication (e.g., multi-factor authentication to permit privileged device access to system administrators, service technicians, maintenance personnel).
• Strengthen password protection. Do not use credentials that are hardcoded, default, easily guessed, easily compromised. Limit public access to passwords used for privileged device access.
• Consider physical locks on devices and their communication ports to minimize tampering.

Authenticate and check authorization of safety-critical commands 🔗

• Use authentication to prevent unauthorized access to device functions and to prevent unauthorized (arbitrary) software execution.
• Require user authentication before permitting software or firmware updates, including those affecting the operating system, applications, and anti-malware.
• Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways.
• Authenticate all external connections. For example, if a device connects to an offsite server, then it and the server should mutually authenticate, even if the connection is initiated over one or more existing trusted channels.
• Authenticate firmware and software. Verify signatures of software/firmware content, version numbers, and other metadata. The version numbers intended to be installed should themselves be signed/have MACs. Devices should be electronically identifiable (e.g., model number, serial number) to authorized users.
• Perform authorization checks based on authentication credentials or other irrefutable evidence. For example, a medical device programmer should have elevated privileges that are granted based on cryptographic authentication or a signal of intent that cannot physically be produced by another device, e.g., a home monitor, with a software-based attack.
• Devices should be designed to “deny by default,” i.e., that which is not expressly permitted by a device is denied by default. For example, the device should generally reject all unauthorized TCP, USB, Bluetooth, serial connections.
• The principle of least privilege should be applied to allow only the level of access necessary to perform a function.

Maintain code, data, and execution integrity 🔗

• Only allow installation of cryptographically verified firmware/software updates. Ensure that a new update is more recent than the currently installed version to prevent downgrade attacks.
• Where feasible, ensure that the integrity of software is validated prior to execution, e.g., 'whitelisting' based on digital signatures.
• Verify the integrity of all incoming data (ensuring it is not modified in transit or at rest, and it is well-formed/compliant with the expected protocol/specification).
• Ensure capability of secure data transfer to and from the device, and when appropriate, use methods for encryption and authentication of the end points with which data is being transferred.
• Protect the integrity of data necessary to ensure the safety and essential performance of the device.
• Use current NIST recommended standards for cryptography (e.g., FIPS 140-2, NIST26 Suite B27), or equivalent-strength cryptographic protection for communications channels.
• Use unique per device cryptographically secure communication keys to prevent leveraging the knowledge of one key to access a multitude of devices.
• Where feasible, use industry-accepted best practices to maintain/verify integrity of code while it is being executed on the device.
• Manufacturers should ensure the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through use of credentials, encryption). Loss of confidentiality of credentials could be used by a threat to effect multi-patient harm. Lack of encryption to protect sensitive information "at rest" and “in transit” can expose this information to misuse that can lead to patient harm. Other harms, such as loss of confidential protected health information (PHI), are not considered “patient harms” for the purposes of this guidance.

Detect cybersecurity events in a timely fashion 🔗

• Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use.
• Devices should be designed to permit routine security and antivirus scanning such that the safety and essential performance of the device is not impacted.
• Ensure the design enables forensic evidence capture. The design should include mechanisms to create and store log files for security events. Documentation should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion Detection System, IDS). Examples of security events include but are not limited to configuration changes, network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).
• The device design should limit the potential impact of vulnerabilities by specifying a secure configuration. Secure configurations may include endpoint protections such as anti-malware, firewall/firewall rules, whitelisting, defining security event parameters, logging parameters, physical security detection.
• The device design should enable software configuration management and permit tracking and control of software changes to be electronically obtainable (i.e., machine readable) by authorized users.
• The product life-cycle, including its design, should facilitate a variant analysis of a vulnerability across device models and product lines.
• The device design should provide a CBOM in a machine readable, electronic format to be consumed automatically.

Respond to and contain the impact of a potential cybersecurity incident 🔗

• The device should be designed to notify users upon detection of a potential cybersecurity breach.
• The device should be designed to anticipate the need for software patches and updates to address future cybersecurity vulnerabilities.
• The device should be designed to facilitate the rapid verification, validation, and testing of patches and updates.
• The design architecture should facilitate the rapid deployment of patches and updates.

Recover capabilities or services that were impaired due to a cybersecurity incident 🔗

• Implement device features that protect critical functionality and data, even when the device’s cybersecurity has been compromised.
• The design should provide methods for retention and recovery of device configuration by an authenticated privileged user.
• The design should specify the level of autonomous functionality (resilience) any component of the system possesses when its communication capabilities with the rest of the system are disrupted including disruption of significant duration.
• Devices should be designed to be resilient to possible cybersecurity incident scenarios such as network outages, Denial of Service attacks, excessive bandwidth usage by other products, disrupted quality of service (QoS), and excessive jitter (i.e., a variation in the delay of received packets).

Cybersecurity documentation 🔗

Labeling 🔗

When drafting labeling for inclusion in a premarket submission, a manufacturer should consider all applicable labeling requirements and how informing users through labeling may be an effective way to manage cybersecurity risks. Specifically, we recommend the following be included in labeling to communicate to end-users relevant security information:

• Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g., anti-virus software, use of a firewall).
• A description of the device features that protect critical functionality, even when the device’s cybersecurity has been compromised.
• A description of backup and restore features and procedures to regain configurations.
• Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended.
• A description of how the device is or can be hardened using secure configuration. Secure configurations may include end point protections such as anti-malware, firewall/firewall rules, whitelisting, security event parameters, logging parameters, physical security detection.
• A list of network ports and other interfaces that are expected to receive and/or send data, and a description of port functionality and whether the ports are incoming or outgoing (note that unused ports should be disabled).
• A description of systematic procedures for authorized users to download version-identifiable software and firmware from the manufacturer.
• A description of how the design enables the device to announce when anomalous conditions are detected (i.e., security events). Security event types could be configuration changes, network anomalies, login attempts, anomalous traffic (e.g., send requests to unknown entities).
• A description of how forensic evidence is captured, including but not limited to any log files kept for a security event. Log files descriptions should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g., Intrusion Detection System, IDS).
• A description of the methods for retention and recovery of device configuration by an authenticated privileged user.
• Sufficiently detailed system diagrams for end-users.
• A CBOM including but not limited to a list of commercial, open source, and off-the-shelf software and hardware components to enable device 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 essential performance.
• Where appropriate, technical instructions to permit secure network (connected) deployment and servicing, and instructions for users on how to respond upon detection of a cybersecurity vulnerability or incident.
• Information, if known, concerning device cybersecurity end of support. At the end of support, a manufacturer may no longer be able to reasonably provide security patches or software updates. If the device remains in service following the end of support, the cybersecurity risks for end-users can be expected to increase over time.

Design 🔗

• For Tier 1 devices, documentation that addresses each of the cybersecurity design controls listed above.
• For Tier 2 devices, documentation that addresses each of the cybersecurity design controls listed above or include a risk-based rationale for why a cybersecurity design control was not necessary. Risk-based rationales should leverage an analysis of exploitability to describe likelihood instead of probability.
• System Diagrams sufficiently detailed to permit an understanding of how the specific device design elements are incorporated into a system-level and holistic picture. Analysis of the entire system is necessary to understand the manufacturer’s threat model and the device within the larger ecosystem. System diagrams should include:

- Network, architecture, flow, and state diagrams.

- The interfaces, components, assets, communication pathways, protocols, and network ports.

- Authentication mechanisms and controls for each communicating asset or component of the system including web sites, servers, interoperable systems, cloud stores, etc.

- Users’ roles and level of responsibility if they interact with these assets or communication channels.

- Use of cryptographic methods should include descriptions of the method used and the type and level of cryptographic key usage and their style of use throughout your system (one-time use, key length, the standard employed, symmetric or otherwise, etc.). Descriptions should also include details of cryptographic protection for firmware and software updates.

• A summary describing the design features that permit validated software updates and patches as needed throughout the life cycle of the medical device to continue to ensure its safety and effectiveness.

Risk management 🔗

Risk assessments tie design to threat models, clinical hazards, mitigations, and testing.

Cybersecurity risk management documentation should include:

• A system level threat model that includes 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), design, production, and deployment (i.e., into a connected/networked environment).
• A specific list of all cybersecurity risks that were considered in the design of your device. The FDA recommends providing descriptions of risk that leverage an analysis of exploitability to describe likelihood instead of probability. If numerical probabilities are provided, we recommend providing additional information that explains how the probability was calculated.
• A specific list and justification for all cybersecurity controls that were established for your device. This should include all risk mitigations and design considerations pertaining to intentional and unintentional cybersecurity risks associated with your device, including:

- A list of verifiable function/subsystem requirements related to access control, encryption/decryption, firewalls, intrusion detection/prevention, antivirus packages, etc.

- A list of verifiable of security requirements impacting other functionality, data, and interface requirements.

• A description of the testing that was done to ensure the adequacy of cybersecurity risk controls (e.g., security effectiveness in enforcing the specified security policy, performance for required traffic conditions, stability and reliability as appropriate). Test reports should include:

- testing of device performance

- evidence of security effectiveness of third-party OTS software in the system

- static and dynamic code analysis including testing for credentials that are “hardcoded”, default, easily-guessed, and easily compromised

- vulnerability scanning

- robustness testing

- boundary analysis

- penetration testing

- Third Party test reports

• A traceability matrix that links your actual cybersecurity controls to the cybersecurity risks that were considered in your security risk and hazard analysis.
• A CBOM cross referenced with the National Vulnerability Database (NVD) or similar known vulnerability database. Provide criteria for addressing known vulnerabilities and a rationale for not addressing remaining known vulnerabilities, consistent with the FDA’s final guidance, Postmarket Management of Cybersecurity in Medical Devices.

We can help 🔗

If you're overwhelmed by regulations, guidance documents, and standards, we can help. We provide turn-key engineering solutions with cybersecurity best practices built into our standard agile processes using our open-source regulatory documentation manager. Contact us if you'd like a team that helps bring your device to the market as quickly as possible. If you have an engineering team, we can also help you with cybersecurity.