Exploited: The Cyber Truth,  a podcast by RunSafe Security. 

[Paul] Hello, everybody. Welcome back to Exploited: The Cyber Truth. I am Paul Ducklin, and I’m joined by Joe Saunders, CEO and Founder of RunSafe Security. Hello, Joe.

[Joe] Hello, Paul. Great to be here. 

[Paul] Joe, our topic for this episode is very short and blunt, hacking health care. And the subtitle is what the latest data tells us about medical device security, which is very well timed because RunSafe’s 2025 Medical Device Security Index has just come out, and it features a survey of more than 600 health care leaders across the US, the UK, and Germany. 

[Paul] Joe, maybe we can kick off by me just asking you, what do you think is the most surprising thing, whether it’s good news or bad news, that emerged from the report?

[Joe] Well, I think there’s a lot of really interesting statistics, that may paint kind of a negative picture about cybersecurity in the medical device world in that it’s a serious problem, and it’s something that needs to be solved. But what’s promising and very, very exciting from my perspective is that 46% of health care organizations have declined to purchase certain medical devices due to cybersecurity concerns. And so what that means to me is, and as we’ll learn when we go through some of the other statistics that suggest that cybersecurity is a real problem for the industry, that procurement offices are taking it very, very seriously and that organizations are pushing back on cybersecurity requirements to ensure or trying to help encourage their suppliers to adopt certain practices. Because we all know, as we’ve talked about in the past, cybersecurity risk ultimately affects safety and patient care and certainly, health care organizations’ cost of operations. And so I think that’s probably the most encouraging thing that health care organizations are looking for cybersecurity in the procurement process when they look to evaluate medical devices.

[Paul] And this is very much in the line of what we’ve spoken about in previous podcasts, isn’t it, called Secure by Demand? It’s not demand as in sort of tub thumping and banging a fist on the table and saying it had better be secure. It’s saying, we will prefer the suppliers who meet our demand or our desire for more security. At 46%, that is a pretty good sign, isn’t it? Because if we can jump to the bad parts now, it is that the cost or the risk or the negatives of cyberattacks on health care organizations have gone very much beyond the administrative tasks and the traditional IT equipment with 22%, that’s just over a fifth of organizations surveyed said they have had cyberattacks that impacted medical devices, and 75%, three quarters of that one fifth actually had patient care affected by that attack.

[Paul] What does that look like in a hospital setting, for example, when, say, an infusion pump gets compromised? How does that differ from your, hey, my server went down or my laptop won’t connect to Zoom? 

[Joe] Yeah. I mean, the consequences are high. They’re serious.

[Joe] We’re talking about health care delivery and supporting patients and patient care in general. We heard from Phil Englert last time talk about when a printer printing labels for blood transfusions failed to operate. When the printer failed to operate, it ultimately affected patient care. And, naturally, if you’re affecting patient care, it’s a very, very serious issue. And so I think this is why the FDA looks after safety concerns of medical devices and has cybersecurity regulations in there.

[Joe] We all want safe delivery of medical services. 

[Paul] Yes. That story of Phil’s really opened my eyes because I hadn’t really thought of it in those terms. The medical equipment, the multimillion dollar blood processing machines stymied because probably $29 label printer couldn’t indicate whose blood was whose. Quite a lot at stake through devices where you think it’s only the label printer.

[Paul] It’s not the blood centrifuge. Now, Joe, another part of that statistic about cyberattacks that actually impacted medical devices, not just laptops and servers, was that of those people who had devices affected by a cyber attack, one quarter of them, twenty four percent, had to do patient transfers. In other words, as we talked about in that episode with Phil, simply moves the stress to another hospital that wasn’t expecting to have those patients. So what happens? What does a hospital do when that often life or death decision has to be made?

[Joe] Everyone who’s been to a hospital knows that there are screens everywhere. Physicians and nurses and other health care providers are monitoring all the patients and all the things they need to do next. You can imagine when that gets disrupted, if something is unavailable and you have to transfer a bunch of people. We all know how stressed the hospital systems are already. You can imagine there would be standard protocols if there is a specific patient that needs to transfer from a regional hospital to a really specialized hospital system.

[Paul] Yes. You’d have a procedure for that, wouldn’t you? For example, after a severe head injury or bad burns or whatever. 

[Joe] Exactly. 

[Paul] Stabilize the patient, arrange for them to go to the specialist place. But when you’re just moving people because, hey, our infusion pumps have just stopped working, that’s a very different story indeed, isn’t it? 

[Joe] It’s a very different story indeed. There are supplies. There are, patient care availability questions, timing and cost questions. So it’s a one, it’s a significant cost hit, but I know that that isn’t the factor in making decisions. It’s really getting people to the right spots. But what if they don’t have the right supplies there? What if they’re not staffed properly for that sudden load of people? And that, of course, ultimately affects patient care as well. So you have delays in care, and then you have a stress in the next hospital.

[Paul] Now what’s the big difference in your mind or the biggest difference between the kind of cybersecurity that we’re used to in IT, which we defined in a previous podcast very loosely, sort of think of laptops, servers, domain controllers, printers, and security of the operational technology, the OT network, the things like the infusion pumps, the imaging systems? 

[Joe] We all know that our computers connected to networks at our offices are easily updated, and there’s a process for that. Medical devices, obviously, are connected in internal systems within hospitals. At the same time, though, they’re not simply easily updated. A lot of times, that’ll have to be taken offline and patches applied or software updates applied, and that’s a much more manual process where you’re updating devices or administering patches in a more controlled environment.

[Joe] You have to consider that if you go back to the original manufacturer, they have to make sure that those things are passing safety tests. 

[Paul] Exactly. 

[Joe] It’s a much longer process to distribute patches and fixes on medical devices if, in fact, you can. So that’s really it. People need to think about security that’s built in that would prevent exploitation on devices even when a patch or fix is not available.

[Joe] And I think that’s all ultimately the best recipe for success because it’s a much more onerous process to update individual devices. If you think about a hospital system, they have hundreds or thousands of medical equipment types across a hospital. Each one has perhaps its own procedures and processes to update, and so that becomes a very onerous task and often very difficult. And, in fact, patches often don’t make it to devices. 

[Paul] Yes.

[Paul] I mean, how often have you heard people showing up for a Zoom meeting and they’re a few minutes late? They said, oh, I decided I’d just let the Windows updates go through this morning, or I let my iPhone update before the meeting. And instead of taking six and a half minutes, it took thirty five minutes. That’s why I’m late. And, you know, you all have a laugh.

[Paul] But when that might be that vital equipment like an ultrasound scanner is suddenly unavailable for several prescheduled appointments, that’s a very different proposition, isn’t it? 

[Joe] It’d be very different if the doctor said, please hand me the scalpel and the nurse or physician’s assistant said, I’m sorry. It’s going through an update. That would be devastating. 

[Paul] Yes. You can use it, but at the moment, it doesn’t have a sharp edge. It’s blunt. You just can’t have that, can you? 

[Joe] Exactly. You just can’t have that in the moment.

[Joe] And so these have to be done offline and scheduled and planned for. And, again, all these devices are different. And so those who are administering any updates to software on these devices needs to be familiar with the device in the first place and how to do that. So it becomes very complicated. 

[Paul] And as Phil Englert said when we talked to him about medical devices, he’s from a global organization that promotes cybersecurity and health care, Health ISAC, he talked about the huge number of distinct vendors and suppliers that even a very modestly sized hospital would have.

[Paul] So it isn’t just like, oh, well, 80% of the devices are Windows computers and the rest are mostly Macs. There are lots of different devices that work in completely different ways that fall under potentially completely different regulations, all produced by different very specialized vendors. 

[Joe] Exactly right. And I think this is where the role of regulators does come in, and the FDA and other places provide standards in which organizations need to adhere to for safety purposes, when they administer their cybersecurity programs and when they update software. And so I think those things are a good thing, and I often laugh.

[Joe] The first time I built my home deck going back many years, and I was cursing and swearing because the local government had to come by three times, Paul, to check on my progress on my deck that I was adhering to code. And in the end, when I finished the product, because it was my first time doing it, I realized without those checks, I probably would have skipped some steps. 

[Paul] Yes. It’s easy to do, isn’t it? 

[Joe] I very likely may have made something less secure, less safe for kids.

[Joe] In any event, my point is having guidelines that people need to adhere to is a good thing and certainly needed in the medical device world. 

[Paul] If it’s relevant for the local authorities to make sure that you haven’t either cut corners or 

[Joe] Skip steps. 

[Paul] Just to protect, say, your kids and the kids of your friends who might come round, how much more important for a hospital that provides a public service to an entire county or even state? You can see why a little caution goes an awful long way. 

[Joe] Yeah.

[Joe] And I think that’s why the 46% statistic about procurement officers at health care organizations have pushed back or declined to purchase certain medical devices. It is a serious issue, and organizations need to make sure that their devices are safe before they put them in the system and operate them. 

[Paul] Yes. I was very pleasantly surprised to see that stat. Nearly half of procurement people say, you know what?

[Paul] If we don’t think it’s secure enough, no matter how flashy and fantastic it is from a biomedical or a science and engineering point of view, we’re just going to have to say no. Now what about Software Bills of Materials, SBOMs, which we’ve talked about many times before. How’s that looking in the health care industry? 

[Joe] Well, naturally, the Software Bill Materials help you understand what software components, what software libraries, what packages are included in the device itself. It’s not just a medical device. It’s not just a pump, an infusion pump. It’s a device. It’s hardware with software on it, and there are hundreds, if not thousands, of components in any one device. In my mind, this is a wonderful statistic as well. When we hear that 78% of these organizations are considering Software Bill Materials essential.

[Paul] So that’s not they’re not just waiting to be told by those vendors who either are willing to tell them or can actually find out. They’re proactively saying, tell us what’s in it so we can make our own mind up. 

[Joe] Exactly right. And going back to the FDA and going back to regulations in the EU, SBOMs are required for medical or for hospital systems. SBOMs are required, but they’re also a really, really good starting point for organizations to not only understand what’s in their devices, but build their security programs on top of it.

[Joe] And so, that’s really a foundational set of data around what’s in the medical devices to help enhance your cybersecurity programs in general. 

[Paul] And this is not just the regulators being difficult and saying you’ll do it our way or the highway. This is, again, Secure by Demand, isn’t it? If 78%, that’s more than three quarters of people who look after medical devices in the hospital are actually saying, this is not because it’s a regulatory necessity, it’s because we actually need and want that stuff. If you took the regulations away, there’d still be a significant majority of medical device users saying, we want to know what the ingredients look like.

[Paul] That’s a very good sign, isn’t it? 

[Joe] It is a good sign. I mean, it’s one thing to say I’m in compliance. It’s another thing to say I’m using this information to boost my security posture. And if there is a takeaway in this report, it’s that hospital systems do take security seriously.

[Joe] They do demand it, and they are expecting more from their product manufacturers. 

[Paul] Joe, asking for an SBOM is great, but what do you actually do with that information as the person has to look after these devices, which as you’ve said before, are even more at risk than ever because they’re increasingly interconnected with our regular IT systems. So if someone’s laptop gets hacked because they get phished, that could directly expose the label printers or the infusion pumps. So what do you do with the SBOM to make it pay its way as it were? 

[Joe] The biggest thing to do is to connect vulnerabilities to those underlying components and then start to track performance metrics against it. It could mean time to resolution, or it could be different levels of severity to help you prioritize what to do next. So that’s for planning and preparing and updating your devices and making sure you have really good information to prioritize your programs and what you can fix and what you can upgrade and what you can enhance and protect. 

[Joe] Now the flip side is also when something does go wrong or if you hear about some kind of cyberattack elsewhere, what you can look at is what do I have this vulnerability in my system? I just heard a new vulnerability came out, and I wanna know, do I have that underlying same weakness that could be exploited in my hospital system or on those devices that I’m using? And so it’s a very insightful foundation component to help you better manage and prioritize your vulnerability management practices, but then also a response when either an incident happens to you or you hear about a widespread attack and you wanna know if you’re exposed to the potential attack yourself.

[Paul] Yes. The classic example, which you’ve mentioned before, and then independently without being prompted, Phil brought up, is good old Log4j, which was a bug in a particular Java programming library. I was involved in some of the threat responses for that for a wide variety of customers. And unfortunately, the initial response of many users was, you know what? Our web servers aren’t based on Java. We run Apache or Nginx. No Java. We are completely immune. But what they’re forgetting is that that web server is processing data and passing it off somewhere inside their organization, and so actually the risk could have been anywhere. And that’s multiplied in a healthcare environment, isn’t it?

[Paul] Not only that you may have lots of laptops and servers and conventional IT devices that are at risk, you might have, like we’ve said, the label printers, the infusion pumps, the imaging devices. The injury could happen because you have the vulnerability anywhere inside your network. 

[Joe] And if you think about the software supply chain for medical devices, there is open source software that goes on these devices. There is the software that the manufacturer writes itself. Its proprietary software that goes on these devices, and then there’s software coming from third parties that might be suppliers to those medical device makers.

[Joe] And, really, when you build a Software Bill of Materials and you want to understand what’s in it, one of the issues is visibility into that complete supply chain, if you will. And, the technical question or term when it comes to an SBOM is, do you have transitive dependencies enumerated in your Software Bill of Materials? Meaning, do you understand the underlying components that are coming from those third party suppliers or from the open source community that may not be perfectly obvious or reported by the device maker himself or herself. And so the transitive properties when you build a Software Bill of Material, or dependencies become very, very important. The idea of having a SBOM and really having full visibility into the full dependency tree of components and not just the superficial ones that you think are in there, but the full deep ones.

[Joe] And when you go back to Log4j, part of the issue is people didn’t even know they had that component in there. The suppliers didn’t even know because it was sort of embedded within their complex software supply chain, and they were inheriting some components and libraries from either the open source or third party. And so I think a key step and a key thing for folks to look for, when they look at those SBOMs is how complete they are, how correct they are, and do they uncover these transitive dependencies? 

[Paul] Now, Joe, this good news that 78% of people are saying, you’ve got to give us an SBOM. And we’ve got 46% of respondents saying, if you don’t meet my cybersecurity requirements for embedded devices, It doesn’t matter how biomedically flashy they are, they ain’t coming in my network.

[Paul] Yet, 75% of health care organizations increased their security budget last year, but fewer than 20% of them, just 17%, feel a strong sense of confidence about being able to detect and prevent attacks, or if they have an attack to contain it. How does that imbalance come about, and can we bridge that gap? 

[Joe] I think we can absolutely bridge the gap, and I think the imbalance is a result of the economic nature of purchasing medical devices. You don’t rent them. You don’t get them updated every six months or or once a year.

[Joe] You capitalize them often over many years if you’re a hospital system. And so you’re owning this equipment, and you want them to operate for a long time as long as they are useful and still operating and providing the information you need and doing the stuff that needs to be done. And so there is a lifespan. If you think about a website or, you know, a social media application, those things get updated every day or multiple times a day. Medical devices don’t, and there are also capital expenses that are expected to be used over many, many years.

[Joe] So even if the budgets are increasing, protecting specific legacy devices that are still very productive, very useful, and very important for patient care over a period of time means that there are older versions that are not updated, not protected. You ask the question, can we fill the gap? And you can absolutely fill the gap in two ways. You can replace devices with new devices, which, of course, is expensive and could be costly from the perspective of yet another capital outlay. 

[Paul] And you can’t just buy any device these days because 46% of people are saying, no. It has to meet my cybersecurity requirements as well. 

[Joe] 100%. And so then the other option is to look for ways to add security protections on existing devices in ways that future proof it against cyberattacks down the road or zero days as we like to say, or allow you to extend that life of that and add in security thereafter. So there’s a couple options that folks can do, but you can’t just replace all your medical devices.

[Joe] You have to look at ways to spend those dollars, and it’s a good thing that the budgets are increasing because the need is high. But there are options, I think, organizations can pursue to add in security in their existing devices as well as demand that for future devices. 

[Paul] So, Joe, do you want to say something about the advanced runtime protection products that RunSafe has? Because I think a lot of people are seeing, well, just add a whole load of extra code to do protection. But for a lot of existing devices, you can’t add more and more and more extra code to do the sort of protections that you get, say, in today’s Windows operating systems that you didn’t get in XP because you don’t have an extra three gigabytes of memory to pack the new code in.

[Paul] So how do you deal with that? How do you protect the code without making changes so significant that it changes its behavior in deleterious ways? 

[Joe] I think part of the answer is shifting the mindset to instead of chasing every new vulnerability and having to fix tests and patch, it’s an exhaustive process, and it’s never ending because there’s always the next vulnerability. And so the first mind shift is, can you eliminate entire classes of vulnerabilities even if a patch is not available? And that’s what runtime defenses try to do.

[Joe] The second point is these aren’t massive servers in the cloud with unlimited resources. These are devices perhaps with limited compute, perhaps with limited power, and you can’t just add more software onto the devices. You need to find ways to add in security protections that don’t affect the performance of the device to your point that it has to be timely and reliable and safe. Those are major shifts in security mindset. And what’s interesting is when health care providers hear about the possibilities of this kind of advanced runtime protection that doesn’t change system behavior or device behavior, works in low power, works in low compute, and doesn’t add new software onto a device, and yet eliminates an entire class of vulnerabilities.

[Joe] What we have found in this survey is that 79% of buyers would pay more for devices with such advanced runtime protection. And you can see why because it does ensure patient care would be delivered, but it also ensures that there’s a more streamlined process, and it quite likely could extend the life for the devices, against which you purchase those. 

[Paul] So even if you have an old school device with old school CPU, old school amounts of memory, and even if you have an old school development environment, say, you have only a C compiler, you don’t yet have a Rust compiler, you don’t yet have all the fancy features that modern compilers like Clang have when you’re compiling for Windows, you can still retrofit security in a way that changes the behavior of the software in the device to a sufficiently small degree that it still meets all the regulatory requirements. 

[Joe] Exactly right. You reminded me of something related that I’d love to bring up, and that is in a recent study from Tesla, I heard that 30% of Rust code is written in what’s called unsafe Rust without the memory safe features turned on.

[Paul] Yes. Because it has to interact with other parts of the system that need you to have direct manipulative access to memory or ports and things like that. When the device that you’re interacting with requires you to basically be poking knitting needles into holes to get it to work. 

[Joe] Exactly. If you introduce a foreign library to the Rust application that you’re running, say a foreign library written in C, it very likely won’t have those safety precautions.

[Joe] Anyway, I went down that path because even Rust, which is supposed to be memory safe, is often not memory safe. At least 30% is written in unsafe Rust. 

[Paul] So, Joe, with 46% of respondents saying, yes, cybersecurity matters so much that it might cause us to refuse to buy a product even if we think it will be brilliant for our hospital or our doctor surgery or for our wards or whatever it is, and with 80% of respondents saying, we’d be willing to fund the retrofitting of fixes so we can keep using our old devices safely. With that in mind, for any medical device manufacturers who are listening, what would be the single best thing you think that they could do? 

[Joe] Yeah.

[Joe] I would certainly do two steps immediately if I was a medical device manufacturer. The first step is I would generate a build time Software Bill of Materials that has complete visibility into a 100% of the components that go on the device, including those transitive dependencies that we talked about so that you have full visibility of all the software components that go in there that you pull in from third parties and open source components. It’s the only way to have a complete picture of your cybersecurity posture on your device. That’s the first thing I would do. The second thing I would do is I would associate the vulnerabilities with all those components and analyze the underlying risk in that software that it could be exploited even if a patch is not available.

[Joe] And with that, as a result of that analysis, I would add in the runtime protections to ensure that you eliminate entire classes of vulnerabilities, especially those the memory safety related vulnerabilities that are inherent on most of these medical devices. So I would generate the SBOM and analyze the data around vulnerabilities and future zero day risk, and then I would add in the runtime protections to eliminate memory based vulnerabilities from being exploited, especially when patches aren’t available.

[Paul] If you’re going to eat food and you look at it and you think, you know, I have no idea what ingredients went into it, you’d have every reason to be concerned that there might be something in there that either is poisonous or that is poisonous to you because you’re allergic to it. Why shouldn’t it be the same for your software? 

[Joe] 100% right.

[Paul] So for the users of healthcare devices in the healthcare industry, what do you think is the single biggest takeaway from this research, and how can they turn that to their advantage? How can they narrow that gap between the three quarters of them who want to spend more money on cybersecurity, but the 80% of them that are going, we don’t know how to make it pay off? 

[Joe] Well, I think taking steps with your product manufacturers is the right step. And asking like we say, ask for Secure by Demand or or implement Secure by Demand practices. And I think asking for a Software Bill of Materials and asking if you have advanced runtime protection built into the devices that you’re purchasing.

[Joe] And I think because people are willing to pay more for those kinds of features, I think all the hospital systems should be asking for them so that the product manufacturers really hear the voice. I think these statistics will get out there and help the industry as well. And the idea is that if the product manufacturers are adding security in, then we can all focus on other things. And what it means for health care systems is they can really emphasize and continue to emphasize their core focus, which is patient care. 

[Paul] Indeed.

[Paul] Joe, I think that really puts it in a nutshell. Their goal is patient care. Patient care must come first, but achieving a higher level of cybersecurity both for IT and OT devices in today’s hospital world is absolutely vital to that as well. Thank you so much for your very thoughtful responses. You didn’t do the usual thing that lots of companies would do.

[Paul] They’d, oh, let’s just turn it into like a big sales pitch. You analyze the numbers with intellectual rigor and in a way that people can get started without actually spending money to get going. 

[Paul] So that is a wrap for this episode of Exploited: The Cyber Truth. Thanks to all of you who tuned in and listened. If you like this podcast, please don’t forget to subscribe so you can join us every week. Please share it with everyone in your team, and don’t forget, stay ahead of the threat. See you next time.