Commodity Malware: What Medical Device Manufacturers Should Know

By Stephanie Domas
November 29, 2016


• Categories: 04-Product Design & Development, 05-Quality/Regulatory

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 with which it comes in contact.

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 that 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 monitor are modified, causing it to fail to send important alerts to the patient or doctor.
• 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.4  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 also 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 2016, 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.

Fuzz testing: massive volumes of malformed data are thrown at the device to see how it performs

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.^6,7 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.

References

1. Radcliffe, J. “Hacking Medical Devices for Fun and Insulin: Breaking the Human SCADA System.” Black Hat, 2011. Accessed October 2016. Retrieved from https://media.blackhat.com/bh-us-11/Radcliffe/BH_US_11_Radcliffe_Hacking_Medical_Devices_WP.pdf
2. Storm, D. “MEDJACK: Hackers Hijacking Medical Devices to Create Backdoors in Hospital Networks.” Computerworld, June 8, 2015. Accessed October 2016. Retrieved from http://www.computerworld.com/article/2932371/cybercrime-hacking/medjack-hackers-hijacking-medical-devices-to-create-backdoors-in-hospital-networks.html
3. Kushner, D. “The Real Story of Stuxnet: How Kaspersky Lab Tracked Down Malware That Stymied Iran’s Nuclear-Fuel Enrichment Program.” IEEE Spectrum, February 26, 2013. Accessed October 2016. http://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet
4. Pressman, A. “Apple’s iOS Update Producing Sporadic Reports of Problems.” Fortune. Accessed September 13, 2016. Retrieved from http://fortune.com/2016/09/13/apples-ios-10-update-problems
5. U.S. Department of Health and Human Services, Food and Drug Administration. Postmarket Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. January 22, 2016. Accessed October 2016. Retrieved from http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf
6. U.S. Department of Health and Human Services, Food and Drug Administration. Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff. October 2, 2014. Accessed October 2016. Retrieved from http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf
7. U.S. Department of Health and Human Services, Food and Drug Administration. Postmarket Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. January 22, 2016. Accessed October 2016. Retrieved from http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf
8. AAMI. Principles for Medical Device Security—Risk Management. June 2015. Accessed October 2016. Retrieved from http://www.aami.org/productspublications/productdetail.aspx?itemnumber=3729