Episode 43 · June 10, 2025 · 27m listen · 4,975 words · ~25 min read
Unpacking Post-Market Management and Incident Response for Medical Devices | Ep. 23 - Full Transcript | The Med Device Cyber Podcast
Read the complete, searchable transcript of Episode 43 of The Med Device Cyber Podcast - expert conversations on medical device cybersecurity, FDA premarket and postmarket guidance, SBOM management, threat modeling, and penetration testing.
Prefer the listening experience? Open the episode page for the synopsis, key takeaways, topics, and Apple / YouTube listen links.
Episode summary
In this episode of the Med Device Cyber Podcast, hosts Christian Espinosa and Trevor Slattery of Blue Goat Cyber provide a comprehensive overview of post-market management and incident response in the context of medical device cybersecurity. They address the critical question of what happens when a medical device is hacked or a vulnerability is discovered after it has been released to the market. The discussion begins with a foundational explanation of general incident response, which involves identifying an anomaly or breach, performing a root cause analysis to understand how it happened, implementing corrective actions, and establishing preventative measures for the future. Christian Espinosa notes that not every anomaly is a malicious hack, emphasizing the importance of a thorough investigation to determine the nature of the event before escalating.
The hosts then narrow the focus to the unique challenges of medical devices. Unlike a corporate IT network, a medical device is often a single, constrained component, which can make incident response more difficult, particularly due to limited logging capabilities on many physical devices. They explore the various ways vulnerabilities come to light in the post-market phase. These sources include ongoing monitoring of the device's Software Bill of Materials (SBOM), tracking the CISA Known Exploited Vulnerabilities (KEV) catalog, conducting regular penetration tests, and, most commonly, receiving reports through a Coordinated Vulnerability Disclosure (CVD) program. Trevor Slattery explains that many of these reports come from benevolent security researchers who find weaknesses in products, a trend that is especially prevalent with Software as a Medical Device (SaMD) due to its greater accessibility compared to physical hardware.
A significant portion of the conversation is dedicated to the process that follows a vulnerability report. The first step is triage, which involves sorting through alerts and, crucially, filtering out false positives that are frequently generated by automated scanning tools. Once a true vulnerability is confirmed, the manufacturer must apply a specific risk methodology to assess its actual impact. This is a critical point, as the hosts argue that a generic CVSS score from a scanner does not account for the device's specific use case, patient safety implications, and a company's risk tolerance. The security posture and exploitability of a device are not static; they evolve as the device is used in the real world and as new exploits are developed. Therefore, post-market management is presented as a continuous, dynamic lifecycle of monitoring, assessing, and remediating, essential for maintaining patient safety and avoiding costly product recalls.
Key takeaways from this episode
Incident response for medical devices involves identifying an incident, performing root cause analysis, correcting the issue, and preventing future occurrences.
Not all security alerts or anomalies indicate a malicious hack; proper investigation is required to differentiate between a true incident and a system anomaly.
Post-market cybersecurity is a continuous process that involves monitoring vulnerabilities from multiple sources, including SBOMs, CISA's KEV catalog, and Coordinated Vulnerability Disclosure (CVD) programs.
Benevolent security researchers are a primary source for discovering and reporting vulnerabilities, particularly for Software as a Medical Device (SaMD).
Automated scanning tools frequently generate false positives; manufacturers must triage these alerts and apply a specific risk methodology to determine the true severity of a vulnerability.
The risk and exploitability of a vulnerability can change over the device's lifecycle, requiring a dynamic and evolving approach to security.
Effective post-market management and a robust incident response plan are crucial for addressing security issues promptly and avoiding costly and reputation-damaging product recalls.
The process of tracking and remediating vulnerabilities is often managed using ticketing software like Jira, which helps document the entire lifecycle for compliance and reporting.
Full episode transcript
Page 1 of 7· Paragraphs 1 - 21
Christian: Hi, welcome back to the Med Device Cyber Podcast. I'm your host Christian Espinosa along here with our co-host Trevor Slattery. Today we're going to be talking about post-market management and incident response.
Like what happens when a medical device is hacked or somebody reports a vulnerability on a coordinated vulnerability disclosure database. What's that process look like? And we're going to unpack that today.
So before we dive into it, just uh checking in with you, Trevor. How how's it going this morning?
Trevor: It's going great. We're getting some warm weather. The even broke 70 yesterday, so spring has finally arrived.
Christian: Yeah, it was up to 100 here in the valley. So I went for a walk and uh it was pretty hot.
Trevor: Yeah, you know this year was the earliest year on record that it broke nine- or the earliest day of the year on record that it broke 90 in Phoenix. I think it was February 2nd.
Christian: Yeah, doing good. Also, we got our the Blue Goat coffee mugs. I don't know if you got one yet, but...
Trevor: Oh, I didn't know we even had those. I got to get one of those.
Christian: We have those, yes. We just got back from a conference in California, so we gave a bunch of them away and uh, quite a few other things. But yeah, we'll have to get you some for, for sure.
Trevor: Perfect. Yeah, we got a couple more conferences coming up, so have to bring some Blue Goat swag.
Christian: That's true. We got to get shipped out to Boston pretty soon. Yeah. Cool. So, with incident response, uh let let maybe you can just walk us through a little bit of the standard, uh, the TIR standard, uh, 97 I believe it is, and then what the high level process is, then we'll unpack that a little bit.
Trevor: Well, I think we should sort of walk back into general incident response and then we can dive into the medical side of things. So, incident response is essentially the next steps after a breach, a vulnerability, a hack has been uncovered.
What is the corrective action? How do you figure out what led to this hack happening and how do you prevent it from happening again?
So, in a traditional cybersecurity perspective, this is usually going to be in a network where uh sys- uh systems administrator or maybe a data engineer or an architect, someone sees that something weird is going on. There's unaccounted for traffic, there's a rogue device, there's something that doesn't line up with their expected baseline. And that's a sign that they've been hacked. And they take a look, you can review, you know, network traffic, you can...
Christian: Well, it could be, it could be an anomaly, right? We've had clients that thought they were hacked but it was actually an anomaly and they had to run it to ground. So it's not always somebody hacking into you, it's it's like you said, anomalous behavior we have to figure out what what what's the root cause of it.
Trevor: Yeah, sometimes it's just computers being weird, which happens quite a lot. So, it's not always, you know, doomsday situation, you've been hacked. Often times it's just something weird going on. But you want to know whether or not someone was hacked or if it was just weird behavior. So you track it down, you look at, you know, networks on your peri- or components on your perimeter, so your VPN access, your firewalls, things like that. See if there's a problem and you try to get down to the root cause of what's going on.
Now, in medical devices, rarely is a device going to be a connected network. It can be in a connected network, but it isn't the network itself. It's a single component, so you're usually going to have a pretty targeted search if something goes wrong.
Uh, in the medical space luckily, the more common way that these vulnerabilities come up is through benevolent security researchers as opposed to malicious hackers.
Uh, but that's not always the case. It can often just be even a user that notices weird behavior. So they are going to have a process to inform the manufacturer or in some cases inform, you know, whoever's handling their security if that's outsourced that there's a problem in this product.
Maybe it's even just through an annual penetration test or, um, more often it'll be a coordinated vulnerability disclosure in the product where they say, I identified that this is an issue. Um, it happens when I do this and this is what I think the impact could be.
Christian: How is one of these security researchers I mean, how are they going to do this? They just like find an old device on eBay or something and try to hack into it? But I mean, they're not going to be in a live hospital unless they're a penetration tester like and they happen to run across a medical device.