Setting the standard for healthcare cybersecurity

Section IV.A.1

An SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product’s lifecycle, including design, development, release, support, and decommission. Additionally, using SPDF processes during device design may prevent the need to re-engineer the device when connectivity-based features are added after marketing and distribution, or when vulnerabilities resulting in uncontrolled risks are discovered. An SPDF can be integrated with existing processes for product and software development, risk management, and the quality system at large.

Section IV.B

FDA will assess the adequacy of the device’s security based on the device’s ability to provide and implement the security objectives below throughout the system architecture.

• Security Objectives
• Authenticity, which includes integrity
• Authorization
• Availability
• Confidentiality
• Secure and timely updatability and patchability.

Section IV.B

Because exploitation of known vulnerabilities or weak Cybersecurity controls should be considered reasonably foreseeable failure modes for systems, these factors should be addressed in the device design.

As Cybersecurity is part of device safety and effectiveness, Cybersecurity controls should take into consideration the intended and actual use environment.

Section IV.C

A lack of Cybersecurity information, such as information necessary to integrate the device into the use environment, as well as information needed by users to maintain the medical device system’s Cybersecurity over the device lifecycle, has the potential to affect the safety and effectiveness of a device.

• A failure to disclose all of the communication interfaces or third-party software could fail to convey potential sources of risks;
• Insufficient information pertaining to whether a device has known but not disclosed Cybersecurity vulnerabilities or risks may be relevant to determining whether a device’s safety or effectiveness could be degraded; and/or
• Labeling that does not include sufficient information to explain how to securely configure or update the device may limit the ability of end users to appropriately manage and protect the medical device system.

Section V.A

"FDA recommends that security risk management processes, as detailed in the QS regulation, be established or incorporated...regulation which may be relevant in this context include, but are not limited to design controls (21 CFR 820.30), validation of production processes (21 CFR 330 820.70), and corrective and preventive actions (21 CFR 820.100) to ensure both safety and security risks are adequately addressed.”

“FDA recommends that device manufacturers conduct both a safety risk assessment and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks.”

Section V.A.1

As part of the risk assessment, FDA recommends threat modeling be performed throughout the design process and be inclusive of all medical device system elements.

The threat model should:

• Identify medical device system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the Cybersecurity risk assessment;
• State any assumptions about the medical device 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 through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment process

Section V.A.2

Cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modelling (also known as a “probabilistic manner”).

FDA recommends that manufacturers assess identified risks according to the level of risk posed from the device and the system in which it operates.

Vulnerabilities identified in Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog should be designed out of the device, as they are already being exploited and expose the medical device system and users to the risk.

Section V.A.3

As part of a medical device system, a device may have Cybersecurity considerations
from interoperable functionality, including but not limited to interfaces with:

• Other medical devices and accessories;
• ‘Other functions’ as identified in the FDA’s guidance “Multiple Function Device Products: Policy and Considerations;”
• Interoperability with healthcare infrastructure (e.g., network, Electronic Medical Records, medical imaging systems); and
• General purpose computing platforms.

When common technology and communication protocols are used to enable interoperability (e.g., Bluetooth, Bluetooth Low Energy, network protocols), device manufacturers should assess whether added security controls beneath such communication are needed to ensure the safety and effectiveness of the device (e.g., added security controls beneath Bluetooth Low Energy to protect against risks if vulnerabilities in the Bluetooth Low Energy protocol or supporting technology are discovered).

Section V.A.4

Device manufacturers should document all software components of a device and address or otherwise mitigate risks associated with these software components.

In addition, under 21 CFR 820.50, a manufacturer must put in place processes and controls to ensure that its suppliers conform to the manufacturer’s requirements.

"...manufacturers should include plans for how third-party software components could be updated or replaced if support ends or other software issues arise in premarket submissions"

Section V.A.4.a

A robust SBOM includes both the device manufacturer-developed components and third party components, including 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.  

An SBOM or an equivalent capability should be maintained as part of the device’s configuration management, be regularly updated to reflect any changes to the software in marketed devices, and should support documentation, such as the types detailed in 21 CFR 820.30(j) (Design History File) and 820.181 (Device Master Record).

Section V.A.4.b

FDA’s guidance documents “Off-The-Shelf (OTS) Software Use in Medical Devices” and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” describe information that should be provided in premarket submissions for software components for which a manufacturer cannot claim complete control of the software lifecycle. In addition to the information recommended in those guidance, manufacturers should provide machine readable SBOMs consistent with the minimum elements (also referred to as “baseline attributes”) identified in the October 2021 National Telecommunications and Information Administration (NTIA) Multistakeholder Process on Software Component Transparency document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).”

In addition to the minimum elements identified by NTIA, for each software component contained within the SBOM, manufacturers should include in the premarket submission:

• The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and
• The software component’s end-of-support date.

Section V.A.5

As a part of ensuring a complete security risk assessment under 21 CFR Part 820.30(g), the assessment for impacts to safety and effectiveness may include an assessment for the potential security impacts of anomalies. The assessment should also include consideration of any present Common Weakness Enumeration (CWE) categories.

Section V.A.6

FDA recommends that vulnerabilities be assessed for any differing impacts for all fielded versions to ensure patient risks are being accurately assessed.

At a minimum, 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.

Averages of the above measures should be provided if multiple vulnerabilities are identified and addressed. These averages may be provided over multiple time frames based on volume or in response to process or procedure changes to increase efficiencies of these measures over time.

Section V.B

A security architecture definition process includes both high-level definitions of the devices and/or systems that interact, and detailed information on the implementations for how those interactions occur and are secured. It contains information that 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.

FDA recommends that these plans and procedures include design processes, design requirements, and acceptance criteria for the security architecture of the device such that they holistically address the Cybersecurity considerations for the device and the system in which the device operates.

Section V.B

The security architecture should 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).

If corrective and preventive actions are identified, these views can be used to help identify impacted functionality and solutions that address the risks.

Section V.B.2

FDA recommends providing, at minimum, the following types of views in premarketsubmissions:

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

Appendix 2.A

These views should be sufficiently detailed such that engineers and reviewers should be able to logically and easily follow data, code, and commands from any asset (e.g., a manufacturer server) to any other associated asset (e.g., a medical device), while possibly crossing intermediate assets (e.g., application).

Appendix 2.B

Section V.B.1

Effective Cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed. FDA recommends that device manufacturers’ design processes include design inputs for Cybersecurity controls.

FDA recommends that an adequate set of security controls should include, but not necessarily be limited to, controls from the following categories:

• Authentication;
• Authorization;
• Cryptography;
• Code, Data, and Execution Integrity;
• Confidentiality;
• Event Detection and Logging;
• Resiliency and Recovery; and
• Updatability and Patchability.

FDA recommends the requirements and acceptance criteria for each of the above categories be provided in premarket submissions to demonstrate safety and effectiveness.

Section V.C

FDA recommends verification and validation include sufficient testing performed by the manufacturer on the Cybersecurity of the medical device system through which the manufacturer verifies and validates their inputs and outputs, as appropriate.

FDA recommends the following types of testing, among others, be provided in the submissions

A. Security requirements;
B. Threat mitigation;
C. Vulnerability testing;
D. Penetration testing

For all testing, manufacturers should provide their assessment of any findings including rationales for not implementing or deferring any findings to future releases.

For issues that will be addressed in future releases (i.e., remediation deferred for a future software release because current risk was assessed to be acceptable), the premarket submission should contain plans for those releases.

FDA recommends that Cybersecurity testing should occur throughout the SPDF.

Section VI.A

FDA also believes that informing users of security information through labeling may be an important part of design and development activities to help mitigate Cybersecurity risks and help ensure the continued safety and effectiveness of the device.

Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended (e.g., minimum networking requirements, supported encryption interfaces). Where appropriate, such guidance should include 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.

A revision-controlled, Manufacturer Disclosure Statement for Medical Device Security (MDS2)66 and Customer Security Documentation as outlined in the Medical Device and Health IT Joint Security Plan (JSP)67 may address a number of the above recommendations.

Section VI.B

FDA recommends that manufacturers establish a plan for how they will identify and communicate to users vulnerabilities that are identified after releasing the device in accordance with the 21 CFR 820.100. This plan can also support security risk management processes that are described throughout the QS regulation.

Cybersecurity management plans should include the following elements:

• Personnel responsible;
• Sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g., researchers, NIST national vulnerability database (NIST NVD), third-party software manufacturers);
• Identify and address vulnerabilities identified in CISA Known Exploited Vulnerabilities Catalog;
• Periodic security testing;
• Timeline to develop and release patches;
• Update processes;
• Patching capability (i.e., rate at which update can be delivered to devices);
• Description of their coordinated vulnerability disclosure process; and
• Description of how the manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.

Appendix 1.A

There are generally two types of authentication controls—information and entities—and a properly-secured system is able to prove the existence of both.

A medical device system that appropriately accounts for authenticity can evaluate and ensure authenticity for:

• Information at rest (stored);
• Information in transit (transmitted);
• Entity authentication of communication endpoints, whether those endpoints consist of software or hardware;
• Software binaries;
• Integrity of the execution state of currently running software; and
• Any other appropriate parts of the medical device system where a manufacturer’s threat model and/or risk analyses reveal the need for it.

Appendix 1.B

Within an adequately designed authorization scheme, the principle of least privileges should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function.

While authentication schemes based on cryptographically proven designs are generally considered more robust and are therefore preferred, meaningful authorization checks can be performed based on other compelling evidence

Appendix 1.A

When choosing an authentication scheme, manufacturers should keep in mind the following
generally applicable characteristics of different types of schemes:

• Implicit authentication schemes, based solely on non-cryptographic interfaces, handshakes, and/or protocols, are inherently weak because, once they are reverse engineered, an unauthorized user can easily emulate the correct behaviour and appear to be authorized.
• Cryptographic authentication protocols are generally superior, but they need careful design choices and implementation practices to achieve their full strength. In addition, these schemes are still limited by the confidentiality of the cryptographic keys needed to interact with the scheme, and by the integrity of the devices that hold or otherwise leverage those keys

Appendix 1.C

Cryptographic algorithms and protocols are recommended to be implemented to achieve the secure by design objectives outlined in Section IV. While high-quality, standardized cryptographic algorithms and protocols are readily available, several commercial products that include cryptographic protections have been shown to have exploitable vulnerabilities due to improper configurations and/or implementations.

Design a system architecture and implement security controls to prevent a situation where the full compromise of any single device can result in the ability to reveal keys for other devices.

Appendix 1.D

Allow installation of 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 (downgrade or rollback attacks) by ensuring that the new update represents an authorized version change;

Cryptographic authentication schemes verify data integrity, but do not verify data validity. Therefore, the integrity of all incoming data should be verified to ensure that it is not modified in transit or at rest;

Carefully design and 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.

Appendix 1.E

Manufacturers should ensure support for the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through the unauthorized use of otherwise valid credentials, lack of encryption). Loss of confidentiality of credentials could be used by a threat-actor to effect multi-patient harm. Lack of encryption to protect sensitive information and or data at rest and in transit can expose this information to misuse that can lead to patient harm. For example, confidentiality is required in the handling and storage of cryptographic keys used for authentication because disclosure could lead to unauthorized use/abuse of device functionality.

Appendix 1.F

Event detection and logging are critical capabilities that should be present in a device and the larger system in which it operates in order to ensure that suspected and successful attempts to compromise a medical device may be identified and tracked.

While many of the following recommendations are tailored for workstations, the concepts presented also apply to embedded computing devices.

Implement design features that allow for security compromises and suspected compromise attempts to be detected, recognized, logged, timed, and acted upon during normal use.

Ensure the design enables forensic evidence capture.

Appendix 1.G

Devices should be designed to be resilient to possible cyber incident scenarios (also known as “cyber-resiliency”) and maintain availability.

Implement features that protect critical functionality and data, even when the device has been partially compromised.

Appendix 1.H

Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product’s lifecycle.

Design devices to anticipate the need for software and firmware patches and updates to address future Cybersecurity vulnerabilities. This will likely necessitate the need for additional storage space and processing resources.