5 Most Common Misconceptions of Medical Device Security | Ep. 41

In this episode of the Med Device Cyber Podcast, hosts Christian Espinosa, founder and CEO of Blue Goat Cyber, and co-host Trevor Slattery tackle the most common and critical misconceptions surrounding medical device cybersecurity. Broadcasting from Tempe, Arizona, and San Francisco respectively, the duo distills their extensive experience dealing with clients and prospects into a discussion of the top five misunderstandings that can lead to significant vulnerabilities and regulatory hurdles. The episode is framed as an essential guide for medical device manufacturers, investors, and anyone involved in the med-tech industry, aiming to clarify the unique challenges and priorities of securing devices that directly impact patient health. The central argument of the episode revolves around the first and most prevalent misconception: that cybersecurity is primarily about protecting data. Espinosa and Slattery vehemently argue against this notion, asserting that in the context of medical devices, patient safety is the paramount concern. They draw a sharp distinction between traditional IT security, historically known as 'information security,' and the specialized field of medical device cybersecurity. While data breaches are serious, a compromised medical device—such as a hacked insulin pump or defibrillator—can cause direct physical harm or death. They use vivid examples to illustrate this point, such as an attacker remotely increasing the dosage on an infusion pump to cause an overdose. This patient-centric risk model, they explain, fundamentally changes how security should be approached, assessed, and implemented, shifting the focus from data confidentiality to the operational integrity and safety of the device's function. The hosts briefly introduce other key misconceptions they plan to cover, including the mistaken belief that a device is not a 'cyber device' if it doesn't connect to the internet, and the idea that cybersecurity can be treated as a one-time, checklist item rather than an integrated, lifecycle-long process. They also touch upon the flawed assumption that software developers are inherently equipped to handle security and that all cybersecurity expertise is interchangeable. By debunking these myths, the podcast aims to educate the industry on the necessity of a specialized, proactive, and safety-focused approach to cybersecurity, highlighting the significant business and human risks of getting it wrong.

Christian: Hi, welcome back to another episode of the Med Device Cyber Podcast. It's a very interesting conversation today because there are a lot of misconceptions, but we've distilled it down to the top five that we hear all the time from prospects, clients, and conversations at events, et cetera. Christian: I'm your host Christian Espinosa, founder and CEO of Blue Goat Cyber. I'm coming to you from Tempe, Arizona, looking at the lovely Tempe Town Lake. I noticed this is the last year of the Ironman Arizona, so I'm going to miss it. It was one of my fastest races. And I'm here, here today with Trevor Slattery our co-host, coming from San Francisco. Trevor: San Francisco, the foggy city with luckily no fog today, so that's pretty nice. Christian: Awesome. So let's dive into number one. It's about the data. This is a misconception. Everyone I talk to, including investors, when they think about cybersecurity, even in med tech, they they always talk about protecting the data. Now what is wrong with that misconception? Trevor: Well, of course data is something that's very important, and I think part of where this misconception comes from is that it's usually the first thought people have when they think of cybersecurity, you're protecting information in information security. But with medical devices, we have this added layer of… Christian: Oh that's a good point, it used to be called information security. Trevor: Yeah. And you know, you still say, oh well it's I-T testing, information technology, it's all about the information. But we have this unique uh situation with medical devices where a compromise in a product for medical application can hurt someone directly. Think about if, you know, someone cranks your infusion pump or like an insulin pump up to 11, that could cause you to overdose really, really fast. And that's unique where let's say I hacked into a bank or something. Of course, you could steal information, you could steal money, you could do a lot of really nasty things, but you couldn't hurt someone or you couldn't kill someone. And with medical device cybersecurity, that is an added layer. Christian: We're not saying that the data is not important. It's just, from a priority perspective, is less important than the patient safety. I mean, imagine if you have a defibrillator and someone is shocking you to death, at the same time they're stealing your protected health information, which one would you care about more, right? Probably being shocked to death. Trevor: I'd probably want to live to be upset about my data getting stolen personally. Christian: Exactly. Exactly. So they're both important, but they're not equally important. Trevor: And I think it's especially a unique situation since traditional cybersecurity is so focused around assessing risk to data. It becomes a bit of a new situation with medical devices. And we always talk about with, you know, our clients, our prospects, here's how we're assessing risk. We're talking about what can you do to an individual. Can you cause discomfort, harm, death? Uh, and doing that, you look at any traditional cybersecurity metric like CVSS scoring or like DREAD assessments or whatever, there's no box you can tick saying, "Can you kill someone with this?" And so, it's something that's super new and requires a little bit of a unique process. And so I think that's a bit of a shift for existing security teams trying to move into like product security, for example. Christian: Why are we so behind on this shift though? Because we have like autonomous driving cars, we have aircraft that have computers in them, we have all kinds of things where you can kill people. Trevor: I think that overall, there isn't quite as thorough of an understanding of how cybersecurity can be a risk in any of those. I think that medical devices are actually a little bit more mature than some of these other somewhat regulated industries. I, you know, mentioned like aircraft, automotive, obviously really strict requirements on them. Uh, but medical devices, the FDA, medical device regulators seem to be a little bit more aware of the fact, wow, this can really lead to pretty significant harm. But you could make the same argument, you know, you're in Phoenix, I'm in San Francisco, what if someone hacks into one of the Waymos out front, you know? Someone tries to drive a Waymo through a stoplight or into a building. If someone can compromise it, which Waymos do support remote connectivity, someone can take it over in situations where like, if you try to go down to watch a baseball game here, generally someone takes over the Waymo and drives it instead of the AI. So what if someone bad uses that functionality? And I don't think that other industries are quite as aware of the risks and quite as mature with the risk. Christian: I take Waymos all the time and I feel safer in Waymos than Ubers. And ironically somebody's like complaining to me like, “I would never take a Waymo. That's so crazy. You're you're like such a reckless person.” So the next day, this is when Waymo didn't go to the airport, I took an Uber. An 85-year-old woman showed up. She told us she was 85. Uh, before my wife got all the way in the car, the door wasn't closed, she started taking off, and then she got lost. I had to direct her to the way to the airport. So I'm thinking, yeah, I've never had this happen with the Waymo. Trevor: I one time in Boston had an Uber driver get on the exit ramp on the highway, with all the signs saying, "Do not enter." Yes, going the wrong way on the highway and, you know, I'm in the car. Luckily it's 3 in the morning. I'm trying to catch a flight and so I'm, you know, like, "Hey dude, look at the signs. Are you joking?" And then he corrected and turned around, but I was picturing if that was, you know, 9 a.m. on a Tuesday, ooh, that would have been bad. And yeah, I've never had Waymo take me onto the offramp before. Christian: All right, let's go to the second misconception. My device is not a cyber device. People tell me this all the time, and they'll say, well, it's a patient monitoring system and it just has a USB port that we use for uh to get the data off of the device. What are your thoughts? Trevor: I think that this is partially due to just lack of clarity on what a cyber device is. And the FDA is doing a great job at trying to build this up a little bit more slowly but surely. I think that there's still some major gaps in there. But this, yeah, all the time we hear, oh well we don't have this certain interface so we're not a cyber device. We don't connect directly into the internet, we can't be a cyber device. And I can say to them, well, this connects into a USB port and then turns it into an ethernet adapter. Did you think about that? Did you think about what if I have a Wi-Fi adapter that I plug into your system? What if you have, you know, the ability to connect to Bluetooth? You can use Bluetooth as a network connection. You can even make the same argument for data transfer over magnetic coils. The FDA considers things such as RFID like what you'd have on a credit card uh as a network connected system. So the the definition is a lot more broad than I think a lot of manufacturers realize. Christian: Yeah, and when in doubt it's best to ask the experts. You can get on a free call with us and discuss it, we can help you navigate that also. So the third misconception is that cybersecurity can be treated like any other type of study, like a biocompatibility study or anything that's a block of time in my product roadmap. Now what's the challenge with that misconception? Trevor: There are a couple of things that are really difficult there. I'll start with the regulatory compliance part of it more than, you know, the actual functionality of it. So the FDA explicitly says, it's one of the first things they talk about in their guidance, devices should be designed with security in mind. They talk about security by design principles, total product life cycle approaches. They have all sorts of different buzz words they use to say the same thing, which is that you need to integrate security all the way from the beginning, all the way to the end. It can't be a one-and-done process. Why this is a little different from biocompatibility or sterility or human factors or any of that is that there are so many small changes that can affect security. Anytime you're doing anything to the software, there's a risk that you're introducing new security problems. And so, given that the development of a medical device might contain hundreds or thousands of iteration of source code, of software, of deployments before you get to a final design freeze and your final product, there are so many spots where this can go wrong. So if you have a process in place to check each time you're making changes, have a continuous integration or deployment process that is building security into your development practices, you're far less likely to introduce risk into the system as compared to if you just did it in a block of time. You said we're going to do this once and we're going to be done. We're going to do it right at the end and then we start our penetration tests and our testers uncover 3,000 vulnerabilities, which we could have fixed if we handled it as more of a total product life cycle approach. This is more than just a security risk problem, this becomes a business risk problem, where if some manufacturers come to us early enough in the process where they say, "Well, we're looking to submit same time next year." And we go, "Oh, that's good cuz we found 3,000 vulnerabilities. Here's the plan of attack and here's how we're going to get these fixed in the next nine months." So right when we're getting ready for that submission, we're ready to go, you're going to have a clean bill of health. That's a far less stressful situation. You don't have to go to your board and say, "Hey, we're going to be delayed on this submission by another 6 months." You don't have to allocate all these internal resources when you weren't planning to. You can work on iterating your device instead of just fixing problems. So this is, I would say, the biggest problem, one of the most severe misconceptions and possibly what can be a deal killer with some submissions. Christian: I agree. People wait to the very end often, and that's why we're doing these podcasts and why we're doing a lot of content creation to raise that awareness so people start engaging cybersecurity early on because it's really from design to disposal, that entire life cycle, we need to consider cybersecurity, not just a block of time. Trevor: Yeah. And I think that the awareness part is just really the biggest aspect of it. Cybersecurity is still relatively new as far as like the big boogeyman that everyone has to worry about for their submission. I know before everyone was dealing with scrambling with the FDA's latest guidelines for biocompatibility studies. And they shifted those around pretty fast and it became pretty difficult for a lot of manufacturers to navigate. But eventually, the industry matured, they learned how to prepare for biocompatibility, so that when it came time to do those studies, they were ready. They knew the device was going to pass, or it was going to, you know, have just some minor corrections as opposed to having to go and redesign the entire product. So the hope is and what we're trying to push out there, like you said with this awareness, is that the industry starts taking a similar approach to cybersecurity where you stop, you think about it before you just start writing code. You go, "We're going to, you know, design this a little bit more safely. We're going to set up all the infrastructure that we need to build a secure product before we build anything." Christian: All right, so on misconception number four, which people say, oh, our software developers or the contract manufacturer that is developing our software, they have cybersecurity covered. They told us they have a cybersecurity person on staff. Now what is the problem with that misconception? Trevor: Well, mostly that software developers aren't typically as experienced with cybersecurity as you might think. Um I love to pick this example from when I was in college, I went to school for cybersecurity. That was what I studied, that was all I focused on. And, you know, as a part of that, we go through software engineering classes, you have to learn how to code in a couple of languages. Um, but never down to the level where you feel comfortable like designing an application from scratch. What they do want you to learn is how to design secure products, how to design uh software development life cycle with security in mind, the secure software development life cycle, SSDLC, how to develop secure deployment infrastructure, um, and then making sure that you're building out secure code in general. Now, while that was something that I had to do as a cybersecurity major, I had a lot of friends who were software engineers in college and they did not have to take the same courses that I did. They were instead focused on computer architecture, learning how to be good developers, but they didn't know the first thing about cybersecurity. Now, I could say in a more general context, if you were to ask me how to, you know, code a medical device from scratch, I'd have no idea where to start. I'm not a software developer, I don't come from that background. Most people in cybersecurity come from a network architect background or network engineer, someone who deals with the way that machines talk to each other, since that's generally how you exploit them. And in a similar vein, often times talking about all these networking terms, you might think that they're very similar but I'll talk about it with engineers and they haven't, you know, it goes right over their head. They're not sure what they're talking about. They'll talk to us about coding practices and we're not quite as in the loop as they are. So they're very different and unique skill sets. They obviously complement each other really well, but it requires separate education, separate process, and then obviously often times separate team members. Christian: I like to say that software developers are very good at building software from a functional and design perspective and user interface perspective and making it do what it's supposed to do, whereas cybersecurity professionals or penetration testers, which our team is, are very good at breaking software, making it do things that was never intended to do and extracting data out of it and sending it malicious data and seeing how it behaves. So it's a very it's a very different lens to look at the same product that you're developing through and the same code. So it's hard for someone to have both those lenses. From my experience. And I've, you know, I've been in this industry for 30 plus years. I've I think I've met one software developer that actually knew cybersecurity very well. Trevor: Yeah. No, that's definitely a good point. And I think that another thing that can tie into that, you got me thinking about it when you mentioned buffer overflows is that cybersecurity changes in my opinion, a lot faster than software development. Cyber security risks can evolve, it seems by the hour, and software development is usually a little bit more, there's a pure, clean, repeatable process. You go down to the computer architecture, you understand how computers operate at that lowest level, and then scaling back from there as you're trying to provide these instructions going all the way down. That's software development at at core, at its core, is providing instructions all the way down to the lowest level of the computer in an easier way to understand for people. Cybersecurity, the types of threats, the types of attacks that we do are going to vary heavily depending on the technology. And while obviously the specifics of development are going to vary significantly, let's say if you're dealing with a nuclear control system from the '80s compared to a modern artificial intelligence agent, the way that those are developed is not going to be super similar but there'll still be some very similar concepts between them. They could even use the same language. Uh now with cybersecurity, it's going to be pretty much a night and day difference and even the way that you would do penetration testing against an old nuclear control system from the '80s back then, well I guess cyber security wasn't really a thing in the '80s. Nobody really knew it was a problem. But even still, the comparing how you would do it four years ago to now is night and day difference, since of how fast security evolves, there are new tools, new best practices, new techniques that the industry as a whole says this is what we need to standardize on, so it can shift around pretty fast. Christian: The last misconception, and this is interesting this just came up yesterday with a, what was a prospect and now may become a client, is that cybersecurity equals cybersecurity. Like it's all the same. And I think this is a pretty popular misconception, not just when it comes to medical device cybersecurity and traditional cybersecurity. I hear people all the time saying, "I want to get my foot in the door with cybersecurity." And I'm like, "What does that mean? You want to do auditing? You want to do pen testing? You want to do forensics? You want to sit in a SOC?" There's like, there's a a million things to do in cybersecurity. So in this context, I'm talking about traditional versus medical device cybersecurity. We touched upon it a little bit when it in terms of the data versus patient safety, and I wanted to just mention something here like one of our um prospects said they chose a lower cost vendor that was a traditional vendor. They said, "We decided to move forward with lower cost vendor," but then they came back to us later and said that the cheaper option caused them a lot of issues and they're having to do a lot of rework. And they want to go with somebody that specializes in medical device cybersecurity. So what is the challenge or the misconception from your perspective, Trevor with people are picking what we like to say or label traditional cybersecurity companies to do medical device cybersecurity. Trevor: There are a couple of big things that go into it. The first that I'll talk about is the actual testing itself. So, past any of the documentation and the regulations, the type of testing that you're doing for medical devices is generally a little bit unique. The internet of things, so technologies like Wi-Fi, Bluetooth, Ethernet, USB, testing that type of stuff isn't as common as you think. In the US at least, there aren't really that many regulations on protecting consumer electronics. A lot of these are going to be non-standard for, like if you're testing automotive, for an example, that is another regulated industry but generally you're testing through unique automotive ports like CANbus as opposed to these more traditional technologies. So they're often just not super well researched. Uh so that can be one part of it. Like speaking to my background before moving into the medical device security side of things my focus was on web applications and industrial automation and control systems. Even comparing the two of those it was very, very different. My strategy for a penetration test on one against the other. And then moving into medical devices, I had to come up with a completely new strategy altogether. So the testing process is very different. The next thing is around the documentation and regulatory requirements. There are very strict, very strict regulations on how medical device penetration tests need to be conducted and documented that aren't as present in other industries. Pick an example out of a hat, we can say HIPAA compliance, something that a lot of medical device manufacturers have to deal with separately. But if we're doing a penetration test for HIPAA compliance, you could ask ten different vendors for ten different HIPAA pen tests and get ten different styles of reports with ten different structures, level of detail, risk assessments. And all of them can be considered compliant and all of them can be considered valid as long as that tester can provide some rationale and some expertise on the matter. With medical devices, we have to take a very standardized approach that's a little bit unique compared to some other industries. So it's a little bit of a shift where we have to follow a very clean, repeatable process step by step the same way, documented in the same structure. We have to plan out everything that we're doing ahead of time, detail what test cases we're going to execute against the system, document the failures and the successes of every single test case, have traceability all the way back to our threat modeling, down to any of the controls implemented. It's a lot compared to a standard penetration test where we can say, "Here are the problems. Here's one report." So I think that would be, that's a big distinction that can often be a little bit surprising to people on the differences between traditional and medical device cybersecurity. Christian: Yeah, I agree. I think we covered everything pretty well. So I'll do a little recap here. We talked about misconception number one that is not just about the data, that the data is secondary to patient harm. Number two, people say my device is not a cyber device. We defined what that is. Number three, that cybersecurity should be done in a block of time on my roadmap. We clarified it should be done iteratively throughout the entire roadmap from design to disposal. We talked about number four that most software developers, the misconception is that they understand cybersecurity, but the reality is it's a very different skillset, building software versus breaking software. And number five that cybersecurity equals cybersecurity. And we decided that that's not true because traditional cybersecurity is focused more on data protection, and is typically not as regulated as medical device cybersecurity and the skill set's different as well. Any last minute words of wisdom, Trevor? We're about out of time for this one. Trevor: Well, I think what I'm going to talk about today as a big takeaway is understanding what your device is. Really be careful when making any conclusions on whether or not your device is a cyber device. We've seen the FDA have a lot of kickbacks on submissions that do not have any cybersecurity documentation, where manufacturers have to put everything on delay and sort of do a rush job to get things done. So make sure that you're aware of exactly what type of device you have and submit accordingly. Christian: All right, I love it. And if you have questions about any of these things, we're happy to jump on a call and provide some clarity. This is all we focus on is medical device cybersecurity. So thanks for tuning in today. I hope to see you on the next one and I hope you found some value in this episode of the Med Device Cyber Podcast.