Last updated at Fri, 26 Jan 2024 21:26:10 GMT

This is part one in a three-part series on medical device security and risk management, particularly as it relates to vulnerability assessment. In part one, we discuss the processes and procedures to implement inside of a clinical environment to position the security team for success. Part two gets in the weeds and examines how to directly perform assessments on medical devices, and in part three, we put it all together with an example of how an organization would implement these ideas with a based-in-reality medical device.

In a past life, I was a security analyst at a major hospital. I found working in a medical environment to be simultaneously challenging and rewarding. Even though I wasn’t working directly with patients, the decisions my team and I made on a daily basis affected patients nonetheless, and this built-in level of satisfaction scratched a very particular community service itch for me. The challenges I encountered were innumerable, but I’d like to spend a little time talking about a very specific one: advancing my hospital’s security while avoiding negative patient outcomes.

A "negative patient outcome" is anything bad that happens to a patient as a result of medical action. There are two specific reasons why I bring it up. First, it’s important that information security professionals speak in the language of their organizations, and since patient care is a hospital's No. 1 priority, technical teams that can speak in terms of patient care are the ones that stand the best chance of getting their initiatives approved. The second reason, of course, is much simpler: Information security should never harm a patient.

At Rapid7, we’re sometimes asked how our products—like InsightVM—do with scanning medical devices. It’s a logical question that results from a well-intentioned desire at completeness. Information security teams want to scan the whole network, with no exceptions, in order to identify every possible vulnerability and make appropriate recommendations for remediation back to the business.

I’d like to encourage teams prone to this disposition to take a more nuanced approach when medical devices are in play. It will require more effort and planning, but the end result will be better information, organizational buy-in, and no infosec-driven negative patient outcomes. The remainder of this discussion is going to follow three themes:

  1. Manage the risk associated with your medical devices
  2. Be intentional and tread lightly when scanning medical devices
  3. Oh, and don’t scan computers that are plugged into people

Managing the security risks of medical devices

So, why scan medical devices in the first place? To find vulnerabilities, of course! In the service of our noble cause, we will get every vulnerability identified and every patch appli—okay, let’s just hold up a second.

In my cleverly built strawman here, we seem to be confusing vulnerability management and risk management, but it’s cool—let’s explore the vulnerability management piece for a second. How many medical device security vulnerabilities do people think are tracked by the major vulnerability vendors? We at Rapid7 (and at least one of our competitors) publish our vulnerability database publicly online. Do a bit of exploring and find a few medical device CVEs while you’re in there. Don’t worry, we’ll wait. *Lights cigarette*

It quickly becomes clear that vulnerabilities specific to medical devices are not commonly detected by vulnerability scanners. Do not despair, though! That doesn’t mean that vulnerability scanners are useless for managing medical device security risks. It just means they need to be used differently.

The great thing about vulnerability scanners in this use case is all of the information that gets gathered besides, well, vulnerabilities. We can use other data gathered naturally through scanning to tag the asset, assign it a criticality, and help us to make some next-step decisions.
During a scan, we can expect to see at least this much:

  • Open ports
  • A guess at the services running on those ports
  • A guess at the operating system of the device
  • Some generic discovered vulnerabilities

For those looking for an enumeration of vulnerabilities, this is unsatisfying. If the running services are weird, they might not be enumerated properly, and if the operating system is some proprietary RTOS thing, the guess there is going to be a rough one at best. What is this good for? Building a fingerprint. Even if it isn’t 100% accurate, that set of ports, services, operating systems, and vulnerabilities allows us to uniquely identify that type of device on the network. In InsightVM, we can build a dynamic tag on these criteria to automatically mark these assets as they’re discovered.

The dirty little secret in clinical environments is that most teams don’t know what’s out there and don’t have a good way to figure it out. I would argue that the primary usage for a vulnerability scanner is to find and track these assets on our network. Once we know what we have and where it is, we can start with the individual risk assessments on them—that is, independent research of known vulnerabilities, network segmentation, and appropriate alerting mechanisms for devices that show up where they don’t belong. And, if you’re feeling frisky, you can start doing other vulnerability research, too.

This model has a few holes that need to be filled in. For one, we need to build fingerprints before we start wholesale scanning. There is a chicken-and-egg problem there. For another, we need to figure out what to do with the medical devices sitting in production (aka being used in daily clinical care).

Be intentional with medical device security scanning

Look, there’s no easy way to say this, so I’m just going to say it: Those starting from zero with medical device scanning can’t just bomb the network with a scan, then start looking at weirdly identified devices to put together fingerprints. Not only are you setting yourself up for failure, but you are, in a very real sense, risking a negative patient outcome. Remember our third theme: don’t scan things that are plugged into people.

What can go wrong? Some devices may have a poorly implemented TCP/IP stack that is unfriendly to SYN scans. Some devices may dislike the speed with which enumeration occurs on them. Some devices might just have modest specifications that could tip over when touched in the wrong way. One example I know of from the field involved a well-known hospital’s paging system falling over from an nmap scan. While the IT and security teams tried to figure out what happened and restore the service, doctors and nurses in different rooms lost their ability to communicate for 20 minutes.

Being intentional with scanning means doing some homework before launching network sweeps. I recommend organizations strive to implement three processes:

  1. Production medical device network segmentation
  2. Pre-production scanning and fingerprinting
  3. Maintenance cycle-based continuous assessment

First and foremost, confirm that medical devices are segmented from the primary network. This is critical and shouldn’t be done with the vulnerability scanner. Also, never assume the segmentation is done. Talk to the biotech teams and any other IT teams involved in medical device deployment, as this will develop a critical relationship and provide valuable intel. Moreover, trust but verify. Get out into the field, grab one of those biotech folks, find an empty patient room, and work with them to observe how these medical devices are deployed in the field.

This part is neither easy nor fast. It’s going to require looking through logs, getting on switches and firewalls, and poring through device configurations. Be sure to mind the organization’s goals, though. Patient care always comes first. A careless vulnerability scanning program that scans an environment while incorrectly assuming segmentation is in place might scan medical devices without even knowing it, generating an irresponsible risk of negative patient outcomes in the process.

Production segmentation is an ongoing task. In any environment, people make mistakes and assets get accidentally placed in the wrong segment all the time. In a PCI environment, this network boundary creep might generate an ornery QSA but won’t really change how scans get run. Because of the associated patient risks in a clinical environment, we must practice constant vigilance. A light discovery scan tuned for minimum impact and designed to simply identify assets should be used even in non-medical environments to defend against such mistakes. Identified devices are bucketed and properly scanned later, while unidentified devices (or even medical devices identified with a known fingerprint) generate alerts and potentially more extreme actions for remediation.

DevOps for medical devices

The other two processes essentially build out a DevOps-powered security process for medical devices. In pre-production, before devices are deployed for usage, information security must build a fingerprint on the device and perform a risk assessment. I’ve briefly addressed the fingerprint already. The risk assessment is itself a deeper subject (and this post is already pretty long, so kudos for getting here). Part two of the series will go into the “how” of performing a risk assessment of medical devices.

Suffice it to say pre-production is the time to try to break things. Scan, attack, throw the kitchen sink at it. It’s better to learn a device falls over from a particular type of scan during pre-production, rather than when it’s deployed to the network. Learnings here can be applied to the light discovery scan mentioned in the previous section.

It’s not one-and-done with medical devices, though. These devices already undergo regular maintenance cycles, likely maintained by a biotech-specific team. It’s important to identify which cycles are for the various deployed devices and that security gets inserted into that process. When just starting, you can keep it easy and make friends with the biotech folks so they notify you when devices are coming through. However, this should eventually be automated. Automation here could be as simple as watching for changes in the biotech testing environment and triggering scans on change, or as complex as a Jenkins server running through a bunch of automated tests that the biotech team does, with security tests in the same queue.

Again, throughout all of this, remember to never scan medical devices plugged into people. Instead, run a security scan before they go live or when they come out for maintenance—just do everything you can to minimize the chance they get hammered in your non-medical networks.

The upside (besides, you know, not killing people)

I’ve had countless conversations with information security teams that don’t believe vulnerability scanning poses a major threat to their environments. For the most part, they’re right. Everything I’ve described, and everything coming in part two, seems like overkill, with massive risk aversion and unreasonable precautions.
However, here is a list of just a few of the awesome benefits beyond just avoiding negative patient outcomes:

  • An actual medical device inventory
  • Better perspective and understanding of the patient experience
  • A demonstrable SecDevOps process (buzzword!)
  • Rapport and relationship with biotech and clinical
  • Incredible learnings developed during implementation

Finally, let me go back to the start. Information security’s job is to manage risk within the context of organizational priorities. In clinical environments, there’s no priority more important than patient care. Taking steps to ensure your vulnerability scanners do not put patients at risk will not only keep people safe, but improve the overall efficacy of your security processes.

Check back next week for part two of this series, which will examine how to directly perform assessments on medical devices.