Cybersecurity For Not-Yet And Never-To-Be Connected Medical Devices

By Stephanie Domas, Battelle

A cybersecurity plan is essential for medical devices connected to hospital networks or the internet. But if your device isn’t connected, you don’t have to worry — right?

Wrong.

Any device that uses any kind of code — in other words, practically all modern medical devices more complicated than a basic scalpel — can potentially be hacked, even if they are not directly connected to the internet. Here are three good reasons to think about cybersecurity for your not-yet-connected electronic medical device.

1. Your Device Has To Connect With Something, Sometime

Devices don’t have to be continually connected to the network to be vulnerable to malware or hackers. They just need to be connected to another vector of infection once. If your device collects data, needs data, or has any kind of software or firmware, somewhere along the line, someone is going to connect it to something: a laptop, a flash drive, a network connection, a smart phone, or another medical device.

There are several ways that medical devices can become vulnerable:

• Updating software or firmware — Nearly all devices running on code will require updates at some point. This generally requires connecting the device to a network or to another system, such as a biomed computer or a USB flash drive, to receive updates from the manufacturer. Malware may be inadvertently included in the software update, or may have previously infected the hospital network or the system used to apply the updates, where it is waiting to pivot to newly connected devices.
• Data upload — If your device collects patient data, such as biometrics or medication records, at some point, someone will need to access that data. Often, this means connecting the device to a laptop on the network, so that the data can be uploaded into the patient’s electronic health record (EHR) or another centralized data repository. Again, once the device is connected, it is vulnerable to malware existing on the laptop or on the network itself.
• Data input — Does your device have a USB port that can be used to download data from a flash drive or a laptop? Flash drives are an often-overlooked vector for transfer of malware between devices or networks. Any mechanism that allows someone to enter or upload data into the device is a potential vector of infection.

The Stuxnet computer worm, discovered in 2012, provides a compelling case in point. The target of the worm appears to have been the control systems of centrifuges used for uranium enrichment in Iranian nuclear facilities. The centrifuges never touched the internet: They sat in a restricted and secured facility on a closed network, without connection to the web.

However, the widely-spreading Stuxnet worm found its way onto laptops, flash drives, and other devices around the world by pivoting to any device it encountered, searching for its target. It is believed that, at some point, someone connected an infected flash drive or laptop to the secure facility network. Once the network was infected, the worm made its way onto the centrifuges and made its malicious modifications to the centrifuges’ firmware and software in an effort to manipulate the devices’ performance.  

Even if your device is not specifically targeted (and it probably isn’t), malware that makes it onto the device can still corrupt data and affect device behavior in unexpected ways. If a device stops running at the wrong time due to bad data or a poorly timed upgrade — for example, in the middle or a surgery or while a patient is depending on it for life support — consequences may be dire. For these reasons, a comprehensive cybersecurity plan must consider all of the ways data makes its way into and out of your device, and the potential consequences if your code or data is compromised.

2. Your Hacker May Be Closer Than You Think

The person trying to hack into your device may not be an anonymous troublemaker in a basement across the world. In fact, it could be that your potential hacker is your end user. And since they have physical access to the device, they don’t need a network connection to hack into it.

For example, think about the potential temptations presented by a drug delivery device that delivers controlled amounts of a restricted painkiller. Some patients — or their family members or caregivers — may be highly motivated to alter the device in order to access more of the restricted drug. A few of them may also have the technical background and know-how to do it.

It’s much easier to reverse engineer a device that is in your hands than to break into it remotely. Most devices will have some method of data input to allow for software updates or programming. That same entry point provides a path for a motivated hacker to get in and manipulate it for his or her own purposes.

What could a hacker do if they were able to manipulate your device? Are there ways it could be used to harm a patient — for example, manipulating an insulin pump so that it delivers too much or too little insulin? Even if you think that your device does not present much motivation for hackers or potential for patient harm, it is important to think through all of the implications of a patient or caregiver making changes to its code, either with malicious intent or inadvertently.

3. The Future Is Just Around The Corner

Your device may not be connected now, but what will it look like five or ten years from now? A decade ago, most people did not see any reason for a pacemaker or an insulin pump to be connected to Wi-Fi. Now, many medical devices like these are routinely connected to the internet to allow real-time data to be exchanged between patients and providers, to make the devices easier to reprogram or update, and to give patients access to their own data through mHealth apps on their smart phones. The future points to even more connection between devices. While you may not see any reason for your device to be connected to a hospital network or a smart phone now, that is likely to change over the next few years.

If you want to avoid redesigning your device from the ground up when that day comes, now is the time to start thinking about secure design. Device development is generally iterative; future versions of your device are likely to build on the same hardware and code as your current device. Designing with cybersecurity in mind, even if your device is not currently connected, will make it easier to roll out new, connected versions of your device later on.

Building Security Into Device Design

If your device has any kind of code, you should plan to conduct cybersecurity testing. This will help you identify areas of exposure and address vulnerabilities that could provide hackers with easy points of entry. However, the best cybersecurity plan starts with device design.

Secure design starts with a device-specific threat assessment that includes characterizing, modeling, and measuring potential threats specific to the device. If you don’t have cybersecurity expertise on staff, you may want to consider bringing in outside experts to help with the design process. They can help guide you through the threat assessment and recommend best practices in hardware design and software development to reduce current and future risks.

While no device will ever be 100 percent secure, integrating secure design principles can help companies drastically reduce their exposures. It’s the smart way to protect your company and your end users, for today and tomorrow.

About the Author

Ms. Domas is Lead Security Engineer for Battelle DeviceSecure Services.  She has expertise in firmware reverse engineering (x86, x86_64, MIPS, 8051), penetration testing, application fuzzing, and application development (C/C++). Ms. Domas is a member of the joint AAMI/UL 2800 working group contributing towards secure interoperability between medical devices. She also contributed to the IEEE guidelines for security in medical device software development and production, a step toward industry standards that will systematically secure medical devices.

Ms. Domas is a registered Professional Engineer (PE) in the state of Ohio, and a Certified Ethical Hacker (CEH). She has been published and widely quoted on medical cybersecurity topics and has spoken at events for MassMEDIC, AdvaMed, and the Neurotech Leaders Forum. She also serves as an adjunct faculty member at the Ohio State University College of Computer Engineering.