Labeling is any written text that identifies any part of a medical device. This includes a label directly on the device, user manuals, instructions for use (IFU), labels present on the outside of packaging, or anything related to ad copy, such as claims pertaining to the device functions in an ad campaign. This post will break down the fourteen (14) new requirements the FDA has set forth for Cybersecurity labeling procedures.
1) “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).” This instruction has much more applicability towards a PC embedded in a medical device than any other system. If there is some sort of cybersecurity control, a manufacturer should designate specific sections for their documentation, which would include areas such as wireless and wired authentication and pairing, front door security with the use of a password or ID swipe, and ensuring there is no default password.
2) “A description of the device features that protect critical functionality, even when the device’s cybersecurity has been compromised.” It is important for the manufacturer to convey in a manner that the average user can understand how they intend to protect the execution of the code, present data, confidentiality of patient information, and secure updates.
3) “A description of backup and restore features and procedures to regain configurations.” Once again, a very PC centric guideline that doesn’t really extend to custom hardware-based medical devices. In most cases, a simple power cycle will satisfy this requirement.
4) “Specific guidance to users regarding supporting infrastructure requirements so that the device can operate as intended.” This will be needed for devices running a separate segment, such as using ethernet, Wi-Fi, or BLE. Examples would include how an IP address is assigned, how the device handles connections to Wi-Fi and BLE, and if any specific ports that need to be open.
5) “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.” While similar to #2, here is where a list of security features needs to be itemized.
6) “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).” Similar to the items in #4, listing out the network ports and interfaces that are sending and receiving data will be sufficient.
7) “A description of systematic procedures for authorized users to download version-identifiable software and firmware from the manufacturer.” All that is needed for this guideline is a description of how to perform an upgrade of firmware/software from the manufacturer for the user.
8) “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 request to unknown entities).” Once again, this requirement is similar to #2. The system will need to go through and list out the events it is looking for and which it will announce to a user.
9) “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).” This guideline could not be more associated with PC oriented systems, but manufacturers will still have to cover forensic logs that are being maintained in embedded products. Both of these have to be covered and there are standards for interfacing analysis software if connected to a PC. The logs can and should be provided as protected forensic evidence after an attack has occurred.
10) “A description of the methods for retention and recovery of device configuration by an authenticated privileged user.” If these methods do not exist for a device, it needs to be noted in documentation. If present, they need to be able to store the configuration of the device over the communications protocol. A vast majority of devices will not need to have this functionality so it will not be a consistent requirement.
11) “Sufficiently detailed system diagrams for end-users.” Our second-least-favorite item on this list. A manufacturer will need to show devices in the system and the interconnections between them. This can be indicated via diagrams where security mitigations are implemented.
12) “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 (including patients, providers, and healthcare delivery organizations (HDOs)) 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.” Depending on the system, the software BoM will include all 3rd party software components (libraries, operating systems), and will also need to be machine readable. At this point, it appears hardware will not be included in the CBoM.
13) “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.” This requirement covers user instructions for performing a secure update and returning a device to its secure configuration (e.g., power cycling).
14) “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.” This phrase should be copied word-for-word into the device’s IFU, as it is reasonable to assume risks to end users will increase over time. There should be a concerted effort by the manufacturer to remove devices from the market and from use once support is cut off.
This concludes our breakdown of the 14 new cybersecurity labeling practices. Our seventh and final portion of this series will cover cybersecurity documentation required for submission. If you'd rather not wait, you can download the entire white paper here.
If you would like to be notified of when these posts go live, please sign up for up-to-date email alerts to the right of this page.
To learn more about Christopher Gates and his background in medical devices and cybersecurity,click here.