By Stephanie Domas
When medical device manufacturers think about cybersecurity risks, they often focus on deliberate hacking attempts: a terrorist harming people by sabotaging the code in an insulin pump or pacemaker or a criminal organization using a medical device to pivot into the hospital network for a ransom attack or data theft.
The possibilities for direct, deliberate patient harm are certainly alarming and have been well documented by security researchers and “white-hat” hackers. The prospect of hackers using medical devices as a “weak link” to access hospital networks is also a genuine threat. But the biggest cybersecurity threat for medical devices isn’t a directly targeted attack. Statistically speaking, medical devices are much more likely to be impacted by commodity malware: the same rapidly propagating, indiscriminately targeted bits of malicious code that are the bane of every computer, cell phone and tablet user.
The Reproductive Cycle of Commodity Computer Viruses
By “commodity malware,” we mean malicious computer code that is designed to affect a specific library or software used across a wide range of devices (such as an operating system or a browser), not necessarily a particular device. Whereas a targeted attack requires a hacker to research a particular device for possible vulnerabilities and specifically target them, commodity malware is opportunistic. It continually makes copies of itself and searches for opportunities to infect any and all devices it comes in contact with.
These types of viruses don’t know or care that they have infected a medical device. The device is just another vector that can now be used to infect other devices or networks it encounters. The ultimate goal is to infect as many machines as possible in order to open up security holes that can be exploited for other purposes later—often to steal data. Infection of the medical device is just collateral damage as the virus blindly seeks new targets.
Malware can propagate widely in this way, even to devices that are not directly connected to the internet. Viruses can spread to medical devices when they are connected to a laptop or thumb drive to upload patient data or when they connect to a network to get software updates. If any part of the “software ecosystem” that the medical device connects to, even periodically, is infected, malware can spread to the device itself. This is the same way that the Stuxnet virus is believed to have reached centrifuges used in Iran’s nuclear program: by indiscriminately copying itself onto devices throughout the world until it finally found its way to its target, possibly through an infected thumb drive plugged in to the secure network.
How Malware Impacts Medical Devices
Attacks directly targeted at medical devices and mHealth apps can raise concerns about data privacy: does the device store HIPAA-protected medical data or sensitive patient information such as social security numbers and birthdates? Is it connected to a billing system that might allow access to financial information? With commodity malware, data privacy is still a concern, but now you also have to worry about data integrity. Malice is not required for harm to occur; data corruption may occur simply as a side effect of other things the virus is doing in the system as it blindly follows its programming.
Malware can interact with a device’s code in unpredictable ways, even when the device itself is not the target. The malware may overwrite part of the operating system or lock up critical data the medical device requires for operation, causing unexpected shutdowns or failures under certain conditions. It may cause the device to return bad data. Or it may change the data that the device uses to moderate its behavior. How dangerous or disruptive these code changes are depends on the robustness of the device, how critical the device is for patients or healthcare providers and exactly how the device’s behavior is changed. Imagine the following scenarios:
- A virus locks up the data that an insulin pump uses to determine how much insulin to deliver.
- A ventilator’s code now runs too slow due to the virus hogging system resources, causing it to behave erratically or shut itself off unexpectedly.
- The alert parameters for an mHealth app connected to a monitor are modified,
- A system interrupt is missed, causing a medical sensor to return misleading data, which a nurse relies on to make medication decisions.
- Malicious code erases data from a patient’s Electronic Health Record (EHR) or sends data to the wrong patient record.
These scenarios all present the possibility of real patient harm even though there was no malicious intent in the code. In some cases, the data corruption may be obvious: if the device returns nonsensical data, or simply no data at all, fail-safes in the device or the common sense of the patient or healthcare practitioner are likely to prevent the data from being used in a way that could cause harm. However, if the effects of infected devices are more subtle (e.g. data used for diagnostic purposes is 10% higher or lower than the actual value, a false negative is returned or an alarm fails to sound), they may be overlooked. In these cases, bad data can lead to significant negative consequences for patients.
Protecting Medical Devices from Commodity Malware
To mitigate these risks, medical device manufacturers should have a cybersecurity plan for every medical device that runs any kind of code. Devices do not have to be a direct target for hackers in order to be at risk, nor do they need to be directly connected to the internet or hospital network. Fast-spreading commodity malware can find its way onto nearly any device with software.
Medical devices and mHealth apps that run on common operating systems such as Windows, Linux, Android or iOS are at particular risk. The large portion of malware is directed at the Windows OS because it is so widely used in PCs and other devices. Patches are released frequently as new threats are discovered but often do not make their way to medical devices. While consumer devices can be easily updated by their owners or through patches pushed automatically by manufacturers, the code in medical devices is usually more locked down. And for good reason—the regulatory approval process for medical devices requires verification of the behavior and safety of the code. Whenever updates are made, device manufacturers must be able to verify that the update does not negatively impact device performance. Consumer device manufacturers can afford to take a “try it and see” approach with their patches, fixing unexpected issues resulting from unusual hardware or software configurations as they are reported. Apple, for example, had to quickly release a patch in September when their iOS 10 update temporarily bricked a number of users’ devices. Medical device manufacturers cannot afford to take that risk. As a result, many medical devices receive code updates rarely or not at all, leaving them susceptible not only to newly emerging viruses but to malicious code that has been circulating for years.
The FDA is trying to make this process easier. Their latest postmarket guidance, released in draft in January of this year, explicitly states that in most cases medical device manufacturers do not need to go through re-filing for recertification of devices when implementing routine updates and patches for cybersecurity. However, manufacturers still need to do their own internal verification to ensure that the device still operates normally after the patch. The extent of that verification process depends on the potential for patient harm that exists should the device fail to perform as expected. The FDA’s postmarket guidance document includes guidance for assessing the severity of impact on patients.
There are a number of steps that medical device manufacturers should take to mitigate potential risks from commodity malware. These include:
- Perform vulnerability assessments on medical devices to determine their risk profile. This should be done for all new devices during the design and development process. However, if cybersecurity has not been a priority, manufacturers may also want to consider performing vulnerability assessments on devices already on the market. This often includes a process called “fuzz testing,” in which massive volumes of malformed data are thrown at the device to see how it performs. This can uncover vulnerabilities that may cause the device to crash or malfunction.
- Develop a plan for patching and updating code to protect devices from emerging cybersecurity threats. The plan must include the ability to make updates securely without introducing new vulnerabilities as well as appropriate testing to ensure that the patch does not introduce unexpected behavior changes in the device.
- Have a responsible disclosure policy in place in order to collect and respond to vulnerabilities discovered by users or security professionals once the device is on the market.
Ideally, cybersecurity is incorporated into every stage of device development, from ideation to postmarket. Secure design principals can help medical device manufacturers reduce risks and liabilities from both commodity malware and targeted attacks. The FDA has released both premarket and postmarket guidance for medical device cybersecurity. In addition, AAMI has released a technical information report (TIR) that details the principles for medical device security, called TIR-57. These documents provide best practices for medical device development, vulnerability assessment and postmarket updates.
If cybersecurity is not one of your core competencies, it makes sense to work with an outside security expert during design, development and testing. A cybersecurity expert can help you conduct vulnerability assessment, ensure that secure design principals are followed and develop a plan for secure postmarket updates.
Millions of new commodity viruses are released into the wild every year. Many of these make their way onto medical devices without causing any noticeable harm. But the potential risks—to patient safety, data privacy and data integrity—are too big to ignore. Medical device manufacturers should take steps now to reduce risks of infection by opportunistic malware.
About the Author
Stephanie Domas is Lead Security Engineer for Battelle’s DeviceSecure® Services. In this role, she is responsible for the design, architecture, verification and execution of security best practices in the development of new medical devices as well as the testing and cybersecurity risk mitigation of legacy systems. Ms. Domas is a registered Professional Engineer (PE) in the state of Ohio, and a Certified Ethical Hacker (CEH). She sits on several standards committees involved in furthering cybersecurity for medical products. Ms. Domas also serves as an adjunct faculty member at the Ohio State University College of Computer Engineering.