Getting a medical device through security testing and onto a hospital network isn't the end of the cybersecurity problem. In many ways, that's when the harder part begins.
Medical devices can remain in service for years. New vulnerabilities emerge. Software components that were considered safe when a device shipped can become vulnerable later. Updating those components may be considerably more complicated than pushing a patch to a conventional IT system.
And then there are the legacy devices that were never designed with modern cybersecurity requirements in mind but remain too useful — or too expensive — to simply rip out.
Sean Satterlee, senior principal consultant at Device Recon Labs and a medical device penetration tester, joined CYBR.HAK.CAST hosts Michael Farnum and Phillip Wylie to discuss what securing these devices actually looks like.
His description points to a fundamental change in medical device cybersecurity: security increasingly has to follow the device throughout its operational life.
Full episode and related article:
, and CYBR.SEC.Media
Bill Brenner
Medical devices don't have a normal Patch Tuesday
One of the easiest mistakes to make with medical device cybersecurity is treating a medical device like another IT endpoint. It isn't.
In a conventional enterprise environment, administrators expect operating systems, applications and infrastructure to change constantly. Microsoft releases patches. Vendors update software. Security teams identify vulnerabilities and push fixes. Medical devices operate under different constraints.
“You don't get to patch every Tuesday,” Satterlee said.
A device may have been tested and cleared using a particular software configuration. Changing that environment can potentially affect the assumptions under which the system was originally evaluated.
That makes patching a very different exercise.
“If you have to patch every Tuesday, you've changed that environment,” Satterlee said. “That environment was only cleared for this static version, so now it has to be retested in its entirety and its full implementation.”
The result is an environment where systems have to be treated carefully.
“Every host is handled with kid gloves,” Satterlee said.
That becomes important when a vulnerability is discovered in software buried somewhere inside a medical device. Finding the vulnerability may be the easy part. Fixing it without creating another problem is where things get complicated.
The medical device pentest starts with the threat model
For newer devices, cybersecurity testing begins well before the equipment reaches a hospital.
Satterlee described a process in which a proposed device undergoes threat modeling, with the threat model and software bill of materials, or SBOM, informing the penetration tester's work.
“The threat model then informs my actual activities,” he said.
The scope can be surprisingly broad. Satterlee said connectivity doesn't necessarily mean a device has to ship with Wi-Fi or an Ethernet port. A device capable of running software or firmware and connecting through another mechanism — including USB — can introduce cyber risk.
“If I can bring my own Ethernet stack and put it on the Internet,” he said, the connectivity question changes considerably.
From a testing standpoint, Satterlee's takeaway is straightforward: “You pretty much need to test everything that's not just purely mechanical.” The penetration test identifies weaknesses that then have to be mitigated or accepted as risk as the device moves through the regulatory process.
But that only establishes what defenders know about the device at that moment. Tomorrow's vulnerabilities haven't been discovered yet.
What happens after the device ships?
That's where Satterlee sees one of the biggest changes in medical device security. He characterized the previous mindset in colorful terms. Once the device had passed the necessary evaluation, the attitude could effectively become:
“Yes, that's good. Go with God and put it on the wire.”
Now, Satterlee said, the question increasingly being asked is: What happens afterward?
“How are you going to maintain that?” he said.
Post-market cybersecurity changes the problem from proving that a device is reasonably secure at one point in time to maintaining an understanding of its risk after deployment.
An SBOM becomes particularly important here.
A device might contain a software library that isn't even actively used but remains present in its software stack. A vulnerability can be disclosed in that component months or years after the device has entered service.
Satterlee said manufacturers therefore need processes for monitoring device components against newly discovered vulnerabilities, determining whether those vulnerabilities affect deployed equipment and deciding how to respond.
“You have to have an adequately planned incident response in order [to determine] how you're going to resolve that and how you're going to update your devices,” he said.
The update mechanism itself is part of the attack surface. Satterlee argued that penetration testers should inspect that mechanism during their assessment.
“If they didn't, they should have.”
The larger point is difficult to miss. A medical device isn't secure because it passed a penetration test. It's secure only for as long as the assumptions behind that test remain true.
Then there are the devices nobody tested
The lifecycle problem becomes considerably uglier with legacy medical technology.
Hospitals contain devices that predate today's cybersecurity practices. They may not have an SBOM. Their firmware may never have undergone a modern security assessment. Some were designed before their manufacturers had reason to imagine the threats they're facing today.
Yet the devices still work. And the hospital may still need them.
Satterlee described situations in which a hospital wants to connect a legacy device but its information security team refuses to simply allow it onto the network.
That's when things get interesting.
“I want a penetration test done on this,” he said, describing the security team's response.
The assessment can go well beyond scanning the device for open ports. Firmware may have to be dumped from the equipment and reverse-engineered to understand what's actually inside. That's also where researchers can uncover serious vulnerabilities. But finding vulnerabilities doesn't necessarily mean the hospital throws the device away.
“And that device ends up, even with all of its warts and vulnerabilities, still ends up on the wire in hospitals somehow,” Satterlee said.
The response may instead be to isolate it or segment it from the rest of the environment. That's one of the realities that separates medical device security from a lot of conventional vulnerability-management thinking.
The organization can know a device is vulnerable and still make a deliberate decision to keep using it.
The question becomes how to manage the risk around something that can't simply disappear.
Segmentation sounds easier than it is
“Segment the device” is an appealing answer. Actually doing it at scale is another matter.
Satterlee, Farnum and Wylie dug into the networking challenges surrounding medical environments, including Layer 2 controls, Layer 3 segmentation, VLANs, DHCP and network access control.
Strong logical segmentation and access controls can reduce exposure. But every additional architectural control introduces operational complexity.
Satterlee described the ongoing question facing healthcare environments: whether to rely heavily on tightly controlled Layer 2 environments or move further toward Layer 3 segmentation and the additional infrastructure and management that comes with it.
“It becomes a management nightmare,” he said. And management overhead matters in hospitals.
Security architecture doesn't exist independently of the people who have to operate it, the money available to maintain it and the clinical systems that have to continue working.
The theoretically strongest architecture isn't particularly useful if an organization can't reliably operate it.
Sometimes the scary thing is just bad engineering
Penetration testing medical devices can also expose another uncomfortable reality: defenders don't always know much about how the hardware underneath them was designed.
“You never know where that engineer was when they designed it,” Satterlee said.
He recalled testing tabletop diagnostic laboratory devices during the surge in rapid COVID testing. Some manufacturers, he said, were building equipment around inexpensive commodity logic boards similar to hardware used in consumer electronics.
Satterlee described boards with misspellings on their silk screens and unexplained traces buried within PCB layers. Then came the kind of discovery guaranteed to get a security researcher's attention: unexpected network traffic heading toward China.
“I just did Wireshark and I see this really weird bit of traffic going to a Chinese server,” Satterlee recalled.
It sounds like the beginning of an espionage story. According to Satterlee, it wasn't.
He described a device containing a hard-coded IP address in the binary associated with its update mechanism. The address pointed toward a Chinese healthcare-related educational host. But the manufacturer wasn't hiding it. The IP address was documented in the device instructions so customers could whitelist it if necessary. Satterlee's conclusion was much less dramatic than a nation-state implant.
“It wasn't nefarious,” he said. “It was just poor coding and poor update mechanisms.”
That doesn't make it harmless.
As the group noted, poorly designed infrastructure can potentially be turned into something malicious later.
Bad engineering and malicious engineering can sometimes produce remarkably similar attack surfaces.
Medical device security becomes a lifecycle problem
The cybersecurity industry likes clean endings. Find the vulnerability. Patch the vulnerability. Close the ticket.
Medical devices resist that model.
A device can pass a penetration test today and contain a vulnerable component tomorrow. A hospital can discover serious flaws in legacy equipment and still decide that patient care requires keeping it operational. A seemingly suspicious network connection can turn out to be bad software engineering while still creating a security weakness that needs to be managed.
That's why the shift toward post-market security matters.
Threat models and penetration tests tell manufacturers what they know about a device before deployment. SBOMs help them understand what's inside it. Post-market monitoring helps identify when that understanding changes.
And hospitals still have to figure out what to do when the answer is a vulnerability in a device they can't simply patch, replace or unplug. Medical device cybersecurity doesn't end when a regulator clears a product or when a penetration tester finishes the report.
That's when years of managing the device's actual risk begin.
