Securing Medical Devices - The Need for a Different Approach - Part 1



It’s hard not to notice a growing collection of medical devices whenever you visit a hospital or clinic. They surround today’s medical bed, almost like a warm scarf around a bare neck on a cold winter’s day. If they weren’t there you would wonder why. They provide all kinds of patient telemetry back to the nurses station: O2 sat levels, pulse rate, blood pressure, etc. They provide automatic and regular administration of medication via pumps and drips and oxygen dispensers. The medical bed itself tracks patient location across the hospital as the patient is wheeled to and from the OR, imaging or other specialties.

What is not recognized however, is that the number of medical devices employed in the delivery of care to patients is currently growing at almost twenty percent per annum globally. What's more, this growth rate is increasing. For the BioMed staff that has historically been responsible for managing them, it’s an almost impossible task. One that gets more difficult by the day as more and more devices are plugged in or wirelessly connected to the network.

The problem as far as risk is concerned, is not just the growth of these standalone devices and the difficulty managing so many, but the fact that these systems, many of which are critical to patient well-being, by and large have ALMOST NO BUILT-IN SECURITY CAPABILITY. Nor can they be secured by standard compute endpoint tools like anti-virus / anti-malware. They are a huge vulnerability, not only to themselves, but also to everything else attached to the network on one side of the device, and the patient on the other side.

Standalone medical devices are designed, built and FDA approved to perform a very narrow and specific function, and to do so reliably for long continuous periods of operation - unlike a Windows PC, which sometimes appears to have been designed to work for a month more than its manufacture warranty! Medical devices tend to stop working when subjected to things outside of their design parameters. Things like multicast network traffic caused by worms, viruses and other malware. Things like ICMP, NMAP and other network traffic used to illuminate, query, or profile devices perhaps by attackers. What’s more, medical devices are rarely retired and withdrawn from service, which means many hospitals are still using devices designed and built twenty years ago – at a time when Windows 95 had just been released and most of us weren’t even on the ‘World Wide Web’ as we called it then! How could they POSSIBLY be secured and prepared to defend against the types of cyber attack we see today?

Many standalone medical devices leave the manufacturing plant with all kinds of security vulnerabilities – many open TCP/UDP ports, and numerous by default enabled protocols like TFTP, FTP, Telnet, etc. - many of which are highly vulnerable to attack. Several popular medical pumps have been exposed in the past year for the ease at which they could be hacked and taken over by an attacker. If one of these pumps were employed to administer at a gradual and regular level, for example, pain medication such as morphine or perhaps insulin to a patient, what damage would be inflicted upon that patient if the pump was hacked and told to administer its entire medication all at once?

While older standalone medical devices were built to run on obscure, custom, often hardened UNIX operating systems, or even eProm, many of today’s mass-produced, quick-to-market commercial devices run on Windows 9 Embedded – nothing more than a cut-down version of the hugely vulnerable and highly insecure Windows XP operating system.

Windows Embedded is subject to many of the same vulnerabilities and freely available exploits as the regular Windows XP operating system. A targeted attack against modern medical devices is thus relatively easy given a mass of known and proven exploits. Yet we continue to attach insecure, unprotected pumps and all kinds of other devices with the potential to do damage to patients, knowing that at any time a nefarious hacker or almost innocent intruder could turn the device into an execution tool.

Just because it hasn’t happened yet, doesn’t mean to say that it won’t happen today… or perhaps tomorrow!

Part 2 of this blog will be published tomorrow.


This blog is also published here. To view comments or join the discussion on this article or the questions it raises, please follow the link above.