Healthcare IoT

Does Not Compute: Making the Case for PC-like Standards for Connected Medical Devices

4 min read

When we think about medical devices, such as MRI scanners, infusion pumps or ultrasound machines, we usually think of their medical utility - i.e., how they help us map our bodies and cure diseases. We’re much less likely to think of these devices as computers, similar to your laptop or your iPhone - executing code or sending and receiving information from other computers. However, if we step back and think of medical devices as what they are, computers connected to the Internet, it’s easy to see how they can be just as vulnerable -- if not more vulnerable than other connected devices, and it would make sense to take inspiration for their security from connected devices that have a reputation of being some of the most secure on the market.

medical devices in pc screens 1920px

A Look At Standards

There have been many standards for communication between computers over the years. A great example is HTTPS. HTTPS is a communication protocol that consists of not only a standard of data format (i.e. HTTP) but also takes care of encryption (i.e. SSL/TLS encapsulation). HTTPS is the building block of internet communication. Almost every website you access today is using HTTPS as its main protocol (few are still HTTP-only). It doesn't matter which company built the website or which technologies the site is based on, nor whether it's running on premise or on a cloud provider. Ultimately, they will all communicate over HTTPS because that’s the accepted standard.

So, what's the standard communication protocol for medical devices? The answer is ... there is none.

There are several common protocols. None of them are being used by all medical devices and each has its issues. To illustrate the issues, we can examine two of the more common protocols in use today. The first is HL7. HL7 is being used by many medical devices to transfer clinical and administrative data. It allows devices of different types and different vendors to interface with each other easily, but it’s not compatible with all medical devices. Furthermore, HL7 is frequently implemented without any encryption or other security mechanisms1. This allows unauthorized access to sensitive data2.

Then there is DICOM - a communication standard for medical imaging information. The DICOM standard defines security mechanisms3 such as TLS for traffic encryption, Kerberos and SAML for authorized access. It even defines encryption of the DICOM file content being sent, using AES or Triple-DES. However, all these features are optional. Most imaging device manufacturers and integrators in hospitals haven’t taken these suggestions into consideration when implementing the DICOM standard in their CT or MRI. Worth noting that, for understandable reasons, the implementer must keep the imaging device compatible with the existing implementations of the PACS servers they are using that don't always support DICOM's security mechanisms.

On top of the more “standard” (less perfect) protocols, there are also numerous medical devices that use proprietary protocols. These protocols are created by the device manufacturer and require specific attention for their unique security challenges. At the time of the implementation of these protocols, there probably wasn't a better solution for the unique requirements of these devices. Today, because internet communications have advanced significantly, each of these proprietary protocols could be migrated into an existing network protocol to create a standard for all medical devices. HTTPS is a great candidate, as its security mechanisms are continuously improving; whereas proprietary medical protocols have not. This will not only make the integration between devices of different vendors much easier, it will accelerate the deployment of new security mechanisms into this standard protocol. Ultimately, that will allow for the enforcement of compliance to the same standards for all medical devices. This, in turn, will make medical devices communication extremely robust.

Cybersecurity is Overlooked and is Falling Behind

These days, medical devices are built based on many innovative and unique technologies. Medical device manufacturers are spending billions of dollars on R&D4 to improve the devices they build and make sure they are constantly utilizing state-of-the-art technologies. In the process of building the new cutting-edge MRI or infusion pump, however, cybersecurity seldom receives the attention it deserves.

Research5 from 2020 found that 83% of all medical imaging devices were running on unsupported operating systems. For example, 56% are running Windows 7- an OS that reached end of support in 2020. That example is just a symptom of a much greater problem that is relevant to almost every medical device out there: Medical devices are not built with ongoing security updates in mind.

As most medical devices have life-saving importance, it can be daunting to frequently deploy security updates that might result in bugs or performance issues. Another issue unique to medical technology is that deploying software updates on medical devices might also require an extra review from the Food and Drug Administration (FDA). The FDA is generally aware of the urgency regarding security updates. They allow for the deployment of updates without approval provided the updates don’t affect the safety and effectiveness of the device6.

While relaxing the restrictions has made it far easier for hospitals to offer telehealth services, it potentially “unlocks the back door” for threat actors to gain unauthorized access to the hospital’s network and PHI data.

No Need to Reinvent the Wheel

Some manufacturers go with an existing operating system. Some decide to build a proprietary operating system or firmware that's customized to the specific device. Unfortunately, in both cases the devices aren’t likely to receive any major security updates after leaving the factory.

Using existing operating systems (e.g., Linux, Windows and iOS) guarantees high maintenance by a reliable third-party. Throughout the years, their developers have encountered thousands of vulnerabilities. These vulnerabilities were only closed ad-hoc. In addition, the developers invested substantial resources in building new and sophisticated security mechanisms to prevent the next vulnerability and make it much harder to exploit. That's why using an existing operating system is almost always a better option than building a new one. It circumvents the cybersecurity pitfalls many have fallen into before.

After deciding to use an existing operating system, custom applications must be built on top of it to provide the required utilities of the medical device. When building these applications, it's important to take advantage of security mechanisms offered by the operating system.

For example, one powerful security feature that’s implemented in many Linux distributions is SELinux - a security architecture that is embedded into the Linux kernel and provides access control abilities at a very granular level. Another feature provided, although a little more abstract, is a sandbox. There are many implementations of sandboxing, but the idea behind all of them is pretty much the same. Sandboxes restrict access to system resources and user data in other applications to mitigate damage potential in case one application is compromised by malicious code.

If we consider a medical device vulnerability like MDHex, exploiting it could allow malicious users to tamper with the vital signs reported by the patient monitor. A sandbox can be used here to execute the network services in a completely isolated user space (i.e., separate from the process displaying the patient’s vital signs on the monitor). SELinux can help with enforcing user permissions. This enables it to access only mandatory system resources which cannot alter the patient’s vital signs and other user data. In cases where MDHex vulnerabilities are exploited, the malicious code won't have access to the patient’s vital signs. It also won't be able to cause any damage by putting the patient's life at risk.

And what about security updates? There’s no need to reinvent the wheel here either. There are several security patch management solutions to use as examples. Microsoft’s SCCM, for instance, is used by almost every managed network to handle patch management and deploy software and security updates. Utilizing that architecture for medical device management can have tremendous impact on connected medical device security. Of course, it requires developing a solution that will handle active management of medical devices. This solution must be able to handle updates for medical devices with real-time importance (e.g., ventilators, patient monitors, etc.). It should also allow for hotfixes to be applied at runtime without the need for a system reboot. Note - this is supported by both Windows and Linux. Another viable option is to apply updates while the device is idle, during a maintenance window. Update procedures should also include a self-test post-deployment to assure the device’s safety and effectiveness were not compromised.

Final Thoughts

All the ideas suggested in here are not particularly novel. They are already implemented in other fields - personal computers, smartphones, etc. What is required is to put these ideas into practice in the medical device industry. This needs to be a collaboration among all major manufacturers and actors in this field.

We must work together to define a proper standard for all medical device intercommunication and maintain a unified operating system embedded with security mechanisms. This will help lift the medical device industry forward to potentially become a leader in IoT cybersecurity.


For More Information:

If you want to learn more, below are several sources for your reference.