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