How to secure FDA approved medical devices from hackers

Cyberattacks on medical devices are a growing threat to patient safety. Cybersecurity threats to healthcare have increased in both frequency and severity, and continue to be clinically impactful causing healthcare delays. The security of medical devices is essential to protect patient safety and the integrity of healthcare data.

1 Background

Medical devices are FDA approved solutions that pose unique security challenges when deployed in enterprise networks. There are a number of reasons why medical devices are a cybersecurity and cyber risk challenge.

1.1 Unpatched and outdated systems

Ripe for exploitable vulnerabilities, many medical devices are hosted on outdated operating systems. Medical devices are normally managed by the vendor, not by the customer. As such, the customer is not always “in the know” for when updates occur. Certainly, contractual agreements may exist, but policy safeguards do not always represent the technical landscape. Often the medical device vendor will rightfully cite “FDA approval’ for controlling the system. If an untested patch is installed by a customer, the untested system may introduce medical control issues that affect patient safety.

1.2 Security not first

Being patient focused “first”, medical devices are not normally designed as “security first”. This may be a difficult situation to negotiate with the vendor. For example, a gamma knife scheduling system compromised by malware may be marginally operational, and not affect patient safety. But a gamma knife compromised by malware or ransomware during a medical procedure may introduce lethal situations to a patient.

As security specialists, it is our job to make sure all parties understand the risks to security compromise. Ultimately, it is our job to notify the business of these risks, and the business that decides how to move forward in these situations.

1.3 Highly network connected

Another risk is that medical devices are often connected to hospital networks and potentially directly to the Internet, which means that a cyberattack on one device could spread to other devices on the directly connected network. The fact that these devices may be vulnerable (as pointed out above), and connected to the Enterprise network makes them nominal bastion hosts to jump into the network, therefore a valuable target for attack.

1.4 Sensitive patient data

Additional risk areas are that medical devices often contain sensitive patient data, which makes them directly a valuable target for hackers without even needing to jump into the rest of the network.

2 The statistics

The increasing number of cyberattacks on healthcare organizations is a major concern. In 2022, there was a 74% increase in cyberattacks on healthcare organizations worldwide. This is due to a number of factors, including the increasing use of connected medical devices, the growing sophistication of cybercriminals, and the high value of healthcare data.

The potential risks of cyberattacks on medical devices are significant. They can lead to the theft of sensitive patient data, the disruption of patient care, and even the loss of life. It is therefore essential to take steps to protect their medical devices from cyberattacks.

3 Guidance & recommendations

The following guidelines should be considered when evaluating medical devices. This guidance document is focused on patient safety and introducing medical devices to enterprise networks.  The recommendations provide guidelines to safely and securely introduce vendor managed medical devices into operational enterprise networks.  There are three entities involved.  The customer is the hospital or medical facility; the vendor is the distributor of the medical device; and the manufacturer is the manufacturer on record with the FDA.

3.1 Fully document data system interfaces

Medical devices are often integrated with electronic medical records and other intricate patient health systems. Confirm that the entirety of the medical device data system interface is fully documented with asset information, connected data repository (data source & data destination), ports, and protocols. This information is important when evaluating whether additional protection (such as isolation or network segmentation) is practical. [reference 1]

3.2 Perform threat modeling

All networked devices are susceptible to malicious compromise. In threat modeling medical devices, expect the device is compromised and consider what the threat actor can do with the device. Consider patient safety first, and consider methods and techniques to protect the enterprise from the compromised medical device. [reference 2]

Threat model development are twofold. First is how a threat actor can manipulate the machine itself, potentially affecting patient safety. Second is if the device is compromised, how can that device affect healthcare operations. Threat modeling discussions should include the vendor since the vendor is more likely to intimately understand the vulnerabilities in the device.

While developing the threat model, consider that the hospital is likely not able to thoroughly scan the device for compromise. For example, consider that the device may have explicit but undocumented wireless internet capability (many off-the-shelf computers have built in Internet capable SIM cards), or that a vendor employee may introduce an Internet connected device for maintenance and updates, or that a threat actor could introduce an Internet connected USB leave-behind. Since the hospital is likely not able to scan and control the medical device system, the hospital needs to protect itself from these types of threats.

When performing threat modeling, consider specific examples of what a threat actor could do with the compromised device. For example, a threat actor could:

• Cause patient harm: Change the device’s settings or firmware. This could cause the device to malfunction, deliver incorrect treatment, and thereby harm the patient.
• Perform data theft: Access and steal sensitive patient data. This could include medical records, insurance information, or financial data.
• Leverage as a bastion host: Use the device as a launchpad for attacks on other devices in the networks. This could spread malware or ransomware to other devices in the hospital network.

3.3 Request for software changes & cyber security updates

Medical devices often include general purpose computers and industry available off the shelf (OTS) operating systems. These devices are the responsibility of the manufacturer, and controlled by the manufacturers FDA approval. Untested changes to the device could pose a risk to patient safety.

The device manufacturer bears the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device. [reference 3, 4]

The manufacturer is responsible for validating cyber security software changes to control vulnerabilities. Any requested cyber security changes are ultimately the responsibility and authority of the manufacturer’s engagement with FDA. [reference 5] Concerns related to device security and vulnerabilities need to be addressed by external measures and compensating controls such as network segmentation.

3.4 Implement compensating controls

Due to the “hands off” nature of medical devices, compensating controls should be utilized wherever practical. For example, network segmentation is a method to improve data and system protection. [reference 6] Network segmentation can be used to protect the medical device, and also to protect the enterprise network from compromised medical devices. Creating a network segment also forces the creation of fully documented medical device data system interface (e.g., data flow diagrams), thereby enhancing the security of the engagement.

3.5 Document maintenance responsibilities and maintenance schedules

It is customary that the manufacturer maintain the medical device and associated software. However, there may be situations where operational staff are involved with portions of maintenance. Fully document manufacturer’s requests for involvement.

3.6 Document cyber security readiness

Cyber incidences happen. It is important to ensure that staff are aware of the security risks posed by medical devices and how to protect the patient from those risks. For example, device specific awareness training will guide the medical staff on actions to take during an attack. In addition, indicators of compromise should be documented and staff properly trained for awareness.

A key to successfully resolving cyber incidences is a preplanned incident response playbook (e.g., a cyber security incident response plan, or CSIRP). Document the cyber security incident response opportunities and agreements between the hospital and the vendor, including the cyber security incident response contact teams.

The cyber security protection plan should include guidelines and procedures to

• Identify: Threat landscapes are continually evolving, and it is critical to recognize threats as applied to specific devices. During the device lifecycle, many changes will occur, including changes on the device itself, software patches, and connected network changes. Contractually agree to a regular cadence of “re-documenting” the system to confirm cyber security readiness.
• Protect: Periodically review the security controls in place, and confirm that the controls continue to effectively protect the device from newly discovered threat vectors and vulnerabilities.
• Detect: Identifying signs of compromise. It is especially important that staff be made aware of indicators of compromise, and what to do if a machine is acting as though it is compromised. For example, fully document who the staff should contact when presented with what is believed to be suspicious activity.
• Respond: Methods to isolate the compromised device to prevent additional attacks. Keep in mind that these are medical devices, and immediately isolating the medical device may negatively affect patient care. It is important to understand how to respond to a cyber attack while ultimately protecting patient care.
• Recover: Restore operations, restoration of patient data.

It is critical that the CSIRP be tested on a regular basis, and after any significant system change. This testing exercise confirms that the CSIRP remains valid in the dynamic operational enterprise environment.

3.7 Simplicity is the key to security

The “least burdensome approach” to maintaining and protecting medical devices should be considered. [reference 7, 8] Consider the FDA solution a complex “vendor managed solution” where forcing last minute vendor changes are neither practical nor secure. Instead, recognize the device as unmanaged (unmanaged from the customer’s point of view), with unmanaged risks and unmanaged validation, and work to implement a framework of controls around the device that protects both itself, and protects the rest of the enterprise from the device.

3.8 Informal agreements are not obligations

Remember that Emails and discussions are not contractual obligations. Consider the value of the emails and discussions, and document any fundamentally important agreements in contractual obligations. Consider whether the agreements are absolutely critical to the engagement, and apply the principles of “practical security”.

4 Conclusion

Medical devices are capable of directly affecting patient care. These devices are also connected to other infrastructure components with an ability to affect patient records, retrieve and store sensitive patient information, and be used as jump boxes to the rest of a hospital network.

When considering methods to protect the medical device system from attack by a threat actor, and to protect the hospital network from being attacked by a rogue device, the most effective methods are

• To coach medical staff on cyber security readiness,
• To employ methods to encapsulate and control network traffic,
• To regularly revisit the vulnerability landscape for the system, and
• To understand how an offensive operator can use that medical system to their benefit, to the hospitals detriment, and to the patients peril.

Medical devices & systems are a critical part of patient care, and securing these systems is essential to protecting patients and providing healthcare services.

Reference material

• 1 Food and Drug Administration (FDA), “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices Guidance for Industry and Food and Drug Administration Staff”, September 28, 2022, https://www.fda.gov/media/88572/download
• 2 MITRE, “Playbook for threat modeling medical devices”, November 30, 2021, https://www.mitre.org/sites/default/files/2021-11/Playbook-for-Threat-Modeling-Medical-Devices.pdf
• 3 Food and Drug Administration (FDA), “Guidance document, Off-The-Shelf Software Use in Medical Devices, Guidance for Industry and Food and Drug Administration Staff”, September 27, 2019 (originally issued September 9, 1999), https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use- medical-devices
• 4 Food and Drug Administration (FDA), “Global Approach to Software as a Medical Device”, https://www.fda.gov/medical-devices/software-medical-device-samd/global-approach-software-medical-device
• 5 Food and Drug Administration (FDA), “Guidance for Industry Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software”, https://www.fda.gov/media/72154/download
• 6 National Institutes of Health (NIH), “Information Technology and Medical Technology Personnel´s Perception Regarding Segmentation of Medical Devices: A Focus Group Study”, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7151197/
• 7 Food and Drug Administration (FDA), “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software”, January 14, 2005, https://www.fda.gov/regulatory-information/search- fda-guidance-documents/cybersecurity-networked-medical-devices-containing-shelf-ots-software
• 8 Hoffer, Gregory, “Complexity is Still the Enemy of Security”, https://www.cyberdefensemagazine.com/complexity-is-still-the-enemy-of-security/