Last updated at Tue, 25 Apr 2023 22:21:21 GMT
This is part two in a three-part series on medical device risk management, particularly as it pertains 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.
The first security team I ever joined just happened to be in healthcare. Touring a hospital, I walked by many patient rooms in which things beeped, machines were connected to patients, and care teams moved from person to person trying to provide the best and most accurate care (despite staff being greatly outnumbered by patients). At this point, I thought, “Wow, this is really what it’s all about in infosec. The security of these systems here are more than some random hack, some amount of funds stolen, or some amount of servers that could be taken down. These are human beings we are helping every day.”
With that thought in mind, it’s no surprise that when we want to ensure these devices are not susceptible to attacks that could otherwise be prevented, we get pushback: “You want to do what? We cannot run security scans for these medical devices. These are directly connected to and involved with patient care, and we can’t risk some sort of problem.”
Well, that is a bit of a problem. On one hand, we are looking to ensure the system would not succumb to an attack, yet we are being viewed as just as much of a risk as the attackers themselves. So, what’s the path forward? How do we proceed in this situation? Well, in this case, slow and steady is the way to go.
Yes, scanning medical devices does have risk associated with it. Though it is not as common today as it has been in years past, it still happens. A system receives some packets, gets mad that it doesn’t have the full TCP handshake or gets confused by a vulnerability check, and decides to get so frustrated that it falls over and dies. Before we start running vulnerability scans and experimenting, we need to learn as much about the device as possible.
First of all, who deployed these systems? Who do clinicians reach out to when the system fails to work? These are the people who will be able to answer some basic questions about system type, IP address range, and which backend systems are supporting the device. Who is the vendor contact for the device? They will be able to point toward documentation and best practices, which will be helpful even if they don’t directly provide security information and recommendations. These groups are also great people to partner with, as they’ll be the ones to help out during the testing phase.
Here is a list of things we should look to gather as we learn about the medical device we want to assess:
- System type
- Operating system
- Overall system architecture (medical device plus any supporting servers or infrastructure
- Underlying architecture (ARM, x86)
- Testing
- Is there an area that they test new updates?
- If yes, how representative is it of production?
- Does the test system connect to any production components?
- Maintenance
- Updates
- Schedule
- Frequency
- Is the system down during updates, and what issues does that cause?
- Backup and restore procedure
- System downtime procedures
- Network connectivity
- What are the system requirements for activity?
- Are connected systems local, cloud, both?
- What address space is used, and was there a reason for it?
- How is naming defined for DNS?
- Which protocols are in play?
- What type of data is transmitted,and how and where?
- Security recommendations from the vendor
- What is their approach and what are their recommendations?
Scanning medical devices for security vulnerabilities
Let’s get down to brass tacks. How are we going to scan these things? Think of this as our clinical trial—the system and impacts of scanning will need to be carefully observed to determine what life will be like in a real-world scenario. We’ll assume here that we are doing our initial scans in a test environment.
To begin, we are going to want to set up some specific tests from a scanning perspective. We put together a list of areas to test below. Each of these components will need to be evaluated to determine whether they cause any issues with the machine in question. The key components to test include the following:
Discovery
How are these systems determined to be online? Does ICMP work? Will SYN scans work? Does the machine die during discovery portions? (If it does, it’s probably better that you find it before attackers or your pen test vendor starts scanning.)
Service evaluation
When fingerprinting services, does this cause an issue? What ports are typically open? Do they need to be open? Can ACLs be used? Does a specific port cause an issue? During one of my many adventures in helping our clients be successful with Rapid7 tools, I was working with a retail client that had stores across the nation. Its point-of-sale systems did not like to be hit on port 7100, as it would cause the portion of the system that controlled credit card payments to fall over. We excluded the port from future scans, but it opened up a much more broad conversation around how to prevent this from happening in the event an attacker starts port scanning.
Vulnerability scans
If you’ve made it this far, congratulations! In my personal experience, if a machine is going to fail, it probably would have prior to this point. However, this is not the time to get sloppy. When evaluating a test medical device to determine whether vulnerability checks will have an impact on them, I like to start tests with all checks enabled and let the system decide which ones to use against the target. I do this for two reasons:
- To cut down on the volume of testing
- To evaluate what happens in a real-world scenario should a new device come online without any notification or procedures
If the system fails, check your scan logs. Where did it stop? Is it the vuln check, or did the system just get overwhelmed and fall over? What happened to the system? Did it become unresponsive? Did it reboot? Bring the test system back to operating order and rerun the test scan another time or two to validate whether it fails in the same spot. Should it continually fail, note this and work with both the vendor and internal teams to work through the following:
- What the problem is
- What specifically causes it (such as the TCP packet sequence, vuln check, or DoS)
- How we can return it to normal state
- How we can prevent the failure
- Modify scan configuration (short-term solution)
- Implement compensating control (helps in case of rogue IP or attackers scanning)
- Whether the vendor will fix it
Once you’ve fully assessed the medical device for security vulnerabilities in a test mode, increase the speed at which you are interacting with the device to test resiliency. Will this device behave casually during abnormal situations? Once you’ve put the device through its paces, it would be good to provide a scorecard to the team that owns and operates the device that they can share with the rest of their team. This will give them an appreciation for the amount of effort that went into testing, how the medical device performed, and what they can expect in the future. In many situations, we will operate in a world of uncertainty, and people understand that, but they want to be assured we are doing what we can to be thoughtful and careful about things they find important.
All of that methodical documentation will be useful for us as well. Recall that one of our principal goals with medical devices is to avoid negative patient outcomes. The data we gather during this evaluation phase should be used to:
- Modify our default scan templates to avoid any failure conditions, in the event that someone accidentally places the device on the main network accidentally
- Build a fingerprint to identify assets misplaced on the main network
- Implement compensating controls to protect patients from rogue scanners
Should you be in the familiar situation of not having a test bed to work with, you basically have to do the same thing as if you did, but in a much more limiting space and with the increased pressure of not causing damage to a medical device that everyone is depending on daily. Moreover, you need to be sure that your testing isn’t occurring when a person is plugged into the device. Remember when you were talking with the system owner about the system and its schedule for maintenance? Well, now is when you will circle back with them and determine whether you can perform some testing with their assistance during some scheduled maintenance window. This can be tedious depending on schedules and the type of device.
It is worth mentioning that during all phases of the security assessment, it will be very important to document all results methodically. It will also be very important to have someone who knows the system well enough to identify whether any strange behavior has occurred with the system during or after a scan, and someone who could fix any technical problems with the system should they occur.
At times, you may just never be in a position to scan a medical device for whatever reason, such as technical issues, fear or concern about the devices, or simply a stubborn business partner. If that's the case, and it happens, you will need to have the risks documented (both of scanning and not scanning) and have the organization accept the risk or determine whether you can ACL off the entire system to prevent outside systems from interfering with the devices.
Taking lessons learned to governance levels
Now that you went ahead and created a whole process around evaluating medical devices for security vulnerabilities, you might as well add it to your policy so you can continue to work this into future devices and scenarios. At this point, you may or may not have a vulnerability management policy. When looking at a policy, it would be important to have a section dedicated to medical equipment. A section with specific attention to medical devices will help with all future conversations around the topic. Specific items to think about would be:
- Requirements during procurement
- General operations of scanning
- What to do in the event of issue
- Causes for exclusions or exceptions and how to protect if we can’t scan
Medical device scanning can be a large and daunting task. We have a responsibility to ensure that our networks are secure along with the devices that reside on them. This must be balanced with the organization’s patient care goals. Gone are the days of security existing only at the perimeter. With a cautious and methodical process, we can both remove fear and uncertainty and intelligently add medical devices to our vulnerability management process without increasing risk to the organization.
