Episode 39 · September 23, 2025 · 39m listen · 783 words · ~4 min read
Top 10 Medical Device Vulnerabilities with Myles Kellerman | Ep. 38 - Full Transcript | The Med Device Cyber Podcast
Read the complete, searchable transcript of Episode 39 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
This episode of The Med Device Cyber Podcast delves into the 10 most common and dangerous cybersecurity vulnerabilities identified during penetration testing of real-world medical devices. Hosts highlight that unlike traditional cybersecurity, medical device security directly impacts patient safety, introducing "harm" as a critical factor in risk assessment alongside confidentiality, integrity, and availability. The discussion covers hard-coded credentials, unsecured communication channels, and outdated third-party components, emphasizing the importance of SBOM analysis and continuous post-market monitoring. Improper access control, debug interfaces left enabled, and missing firmware integrity checks are also explored, with practical examples of their exploitation and mitigation strategies. The episode further addresses poor session management, fuzzing techniques to uncover buffer overflows and denial-of-service vulnerabilities, tamper detection mechanisms (both physical and logical), and the critical need for rate limiting to prevent brute-force attacks. The hosts stress the proactive adoption of a secure product development framework (DevSecOps) and adherence to standards like IEC 62304 and 81001-5-1 to embed security from design, noting that regulatory bodies like the FDA demand consistent safety, not just "most of the time."
Key takeaways from this episode
Penetration testing simulates malicious hacker activities to identify and fix vulnerabilities in medical devices *before* they reach the market, ensuring safer products.
Medical device cybersecurity fundamentally differs from traditional IT security by incorporating "harm" as a primary risk factor, alongside confidentiality, integrity, and availability, due to direct patient safety implications.
Hard-coded or default credentials, often found during static code analysis or physical device testing, represent a prevalent and easily exploitable vulnerability that can grant unauthorized access.
Unsecured communication channels, including those with no encryption or reliance on outdated encryption standards, frequently expose sensitive patient data and device functionality to interception or compromise.
Outdated or vulnerable third-party components, necessitating continuous SBOM analysis and post-market monitoring, are a persistent source of risk even after a device has been cleared for market.
Improper access control, encompassing both logical and physical vulnerabilities, frequently allows unauthorized users to gain elevated privileges or access sensitive data, highlighting the need for rigorous testing of user roles and permissions.
The proactive implementation of a secure product development framework, such as DevSecOps, and adherence to relevant standards like IEC 62304 and 81001-5-1 are crucial for embedding security early in the design phase, thus reducing vulnerabilities and associated remediation efforts.
Effective tamper detection, combining robust audit trails for logical events and physical tamper-evident seals, is critical for identifying and mitigating unauthorized modifications to medical devices.
Implementing rate limiting and automation controls is essential to prevent brute-force attacks that exploit weak or common passwords, thereby bolstering authentication security.
Debug interfaces (e.g., JTAG, UART) left enabled or unsecured in production devices pose significant risks, potentially enabling complete system takeover, and must be properly authenticated or physically protected.
Missing or weak firmware integrity checks (e.g., secure boot, code signing) leave devices vulnerable to unauthorized firmware modifications, emphasizing the need for comprehensive white-box penetration testing during development.
Hi, welcome back to The Med Device Cyber Podcast. In today's episode, we're going to go a little bit behind the scenes and talk about the 10 most common and also most dangerous cybersecurity vulnerabilities we discovered during penetration testing. These are penetration tests against real-world medical devices. One time we found a legacy diagnostic device with a password of 'admin' hardcoded into firmware, and that device was in production use. Imagine the vulnerabilities with that and what somebody could do just by guessing the default password. I'm joined today by Myles Kellerman, our director of MedTech Cybersecurity, one of our lead penetration testers, and leads our penetration testing team. I've also got our CTO and co-host, Trevor Slatterie. I think Trevor's coming from the San Francisco area, and Myles is coming from the same area. Both of you are in the Bay Area today, and I'm in the Phoenix metropolitan area, where it's like 118 degrees. It's foggy and cold here right now, so that's crazy.
So, let's cover a little bit of the background about penetration testing for those in the audience who don't really understand what penetration testing is in the context of medical devices. Let's unpack that just a little bit so there's some context around what we're going to be discussing the rest of the podcast episode here. Trevor, I'll throw it over to you. What's your best definition of penetration testing in terms of what we're trying to accomplish with medical devices?
Penetration testing is, in its essence, trying to simulate what a bad hacker is doing before they can do it. If a good guy hacks into a device, they responsibly and ethically tell the manufacturer of the device how they did it so that they can go and fix these problems before it's in the market. It's going to lead to a safer product as opposed to waiting for someone with maybe more malicious intentions to find these vulnerabilities first. So, it's kind of an interesting type of testing since it's practically just simulating crime to see what would happen to a system if someone wanted to really abuse it and misuse it.
So, we're simulating the bad actors or the malicious software that's propagating a healthcare delivery organization network typically. There are a couple of different types of pen testing, which is a little bit of an umbrella of activities looking at different goals. There are all sorts of different types of scanning, sorts of different testing. Some are automated, some are manual that go into the process. But it's pretty much just trying to dig up any flaws or poor design decisions for security that are going to introduce risk to a patient or to a healthcare delivery organization, like you said, like a hospital network or a blood delivery center, something like that.
I think one of the misconceptions, at least that I see periodically with pen testing, or penetration testing, is many prospects or clients think that we are not going to find anything. Has that ever been the case? I'll defer it to you, Myles. Have you ever done a penetration test where you did not find anything that needed to be addressed from a cybersecurity perspective? Typically not. There are a lot of variables that go into protecting a medical device, everything from the supply chain aspect all the way down to the source code.
So, there's always usually something there, an area of concern or at the minimum, a security recommendation to strengthen the cybersecurity controls of that medical device. These devices are looked at through a little bit of a different lens from a risk perspective. I mean, typically in quote, you know, traditional cybersecurity, we look at data disclosure, so somebody steals my credit card information or my protected health information. So it's an inconvenience, but through the lens we're looking at the world through with penetration testing and vulnerabilities with medical devices.
It's really about patient safety. If somebody hacks into a defibrillator and shocks you to death, it's a little bit more severe than your credit card information being stolen. You can recover from your credit card information being stolen, but you can't recover if you die from being shocked to death, obviously. So, the risk is much greater. Getting shocked to death is pretty permanent.
When we're going through the risk assessment process, it's very different from that regard. We have to look at how we're blending security and safety, which is completely unique to this industry. In security, they talk about the CIA triad confidentiality, integrity, availability. That's going to be relevant in the medical space, but we add the new CIA