When I ask the question of Healthcare CIOs and CISOs “What keeps you up at night?” one of the most common answers I receive – after the usual jokes about indigestion, or the snoring spouse, is the problem of what to do about securing medical devices in our hospitals. Most healthcare executives are acutely aware of the problem (to some degree at least), but very few have an effective or scalable solution at hand to address this ever-growing risk.
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 continues to increase. 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!
This is so true I first heard about this very same topic via NPR radio. They already withhold medical information for ransom, who’s to say they won’t start holding lives for ransom??
Courtney: Medical device security is a growing area of concern across health systems, one that has only recently reached the mainstream press for public discussion, although security professionals have voiced concern for many years.
In 2014, the Federal Bureau of Investigation issued a report that predicted hackers could assail medical devices. They followed that up a year later with an alert warning companies and the public about cybersecurity risks to networked medical devices and wearable sensors.
Although the concern is not new, the risks have been steadily increasing as more and more medical devices have been attached to hospital networks, while at the same time formerly separate biomed networks (for medical devices) have been converged with the main hospital business network to form a single network thus exacerbating risks to both networks.
Securing these devices is now a big concern for healthcare leaders and that’s one of the reasons for looking into alternate ways of securing them.
FDA has insane, obscure, labyrinthine requirements already, & those requirements essentially compel medical manufacturing companies to hire numerous Compliance Experts who cause R&D to be artificially delayed by years or decades.
If the FDA instituted cyber security requirements, delays will be longer.
But, without an FDA mandate it’s not going to happen because it’s already VERY difficult and expensive to get the MEDICAL features right while jumping through existing hoops.
At this stage, protection is all outside the devices, if at all.
Good article. Looking forward to the followup.
Hi Al – Thanks for your comments. I agree with you that the FDA moves at a snails pace and while medical devices need to be safe before being attached to the patient, trying to manage a growing multitude of devices at each hospital by the same means that workstations and laptops are secured makes no sense. Nor does trying to assess and review each device one at a time.
The second part of my article outlines a different approach to securing medical devices, from that which most healthcare leaders have employed to date. Many of the top healthcare systems are now looking into, or implementing a dynamic network-centric approach to securing medical devices using the approach I detailed. Right now, and until such times that manufacturers improve the security of their devices and older ones are retired, the onus is on the delivery organization to come up with ways of securing these systems.
The bottom line is that the FDA needs to improve its game. It needs to publish better requirements for security and safety and keep these updated on a regular basis as threats and risks change. Secondly, it needs to improve its efficiency and testing of new devices so that manufacturers are incentivized to design newer, better and more secure medical devices, and that patients can benefit from them before they die of old age waiting for the FDA.
There are a lot of people that work tirelessly everyday to ensure the hospital remains a safe place for care…nothing mentioned here is new to the professionals dedicated to that cause.
Is it safe to assume part 2 of this blog will move on from the scary what-ifs to the “different approach” cited in the headline…perhaps providing some mitigation mechanisms to address the risks presented by medical devices on the network?
@Mike… am hoping for more of the ‘different approach’ discussion too… cause I already know the scary what-ifs… have been telling management for years… I want to see the ‘different approach’ and see if it is like my ‘approach’ to make a difference.
I hope you like Part 2 Mike and Jim. Maybe there’s a few things to consider.
This is a huge issue for us hospital CIOs. The device manufacturers claim that they cannot retrofit the numerous devices in the field as, besides being cost-prohibitive, they simply weren’t designed to have such capability. The FDA says it understands the issue but will take 18-24 months to release updated guidelines. In the meantime, we must institute our own countermeasures, like segmentation of the medical device network (e.g., separate VLAN with its own firewall). Hopefully part 2 of this blog provides some other options.
Vince: Not sure if you have had chance to read Part 2 of this blog series yet, but many of the healthcare leaders I speak with are in a similar situation as yourself, using Infrastructure Segmentation – firewalls in front of whole VLANs full of medical devices.
While this has proven a good stop-gap measure while we all wait on medical device manufacturers and the FDA to implement changes, this approach has proven to be inflexible since one usually cannot take a medical device from one hospital ward or building and connect it easily at another location without first adding its MAC address, and IP address, etc. to an ACL somewhere, defining permitted ports and protocols along the way. This static segmentation is also proving to be a pretty expensive overhead every time someone needs to add or remove a device to a secured VLAN.
A firewalled VLAN also doesn’t address the inter-device threats where one device may become infected or compromised, which spreads to all other devices in that segment. What many healthcare leaders are aiming for is ‘micro-segmentation’ where each device is isolated from each other device or system right the way across the network unless specifically authorized.
Hopefully, Part 2 of this article will provide you and many other healthcare CIOs with a better alternative, regardless of what manufacturers and the FDA do. Here’s a shortcut dlvr.it/NwphVY