Advanced Threat Modeling in Medical Devices | Ep. 11

In this episode of The Med Device Cyber Podcast, hosts Christian Espinosa, founder of Blue Goat Cyber, and Trevor Slattery, the company's CTO, provide a comprehensive introduction to the concept of threat modeling in the context of medical device cybersecurity. They define threat modeling as a proactive process of adopting an attacker's mindset to systematically identify and analyze potential threats, vulnerabilities, and entry points within a system. This crucial practice allows developers to build security into a device from the very beginning of its lifecycle. The hosts emphasize that threat modeling is not a one-time activity but should be conducted 'early and often,' starting from the initial requirements and design phases, rather than being treated as an afterthought or a last-minute compliance check before regulatory submission to bodies like the FDA. They argue that this 'bolt-on' approach to security is far less effective and more costly to remediate than designing for security from the ground up. The discussion delves into the practical aspects of threat modeling, starting with the identification of 'entry points'—the various ways an attacker could gain access to a system. Espinosa and Slattery clarify that these are not limited to physical ports like USB or wireless interfaces like Bluetooth and Wi-Fi, but also include non-physical avenues such as software vulnerabilities in custom code and, critically, weaknesses within the supply chain, like compromised third-party libraries. The hosts introduce established frameworks to structure the threat modeling process. They highlight the MITRE Playbook for Threat Modeling Medical Devices and its four foundational questions: What are you building? What can go wrong? What are you going to do about it? And did you do a good job? To address 'what can go wrong,' they break down the widely-used STRIDE framework, which categorizes threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. They explain how the specific risks and priorities shift depending on the medical device's function; for instance, Information Disclosure is the primary concern for an Electronic Medical Record (EMR) system, whereas Denial of Service or Tampering is most critical for a life-support machine, where patient safety is directly at risk.

Hi, welcome back to the Med device Cyber podcast. Today we're going to be talking about threat modeling and how attackers look at a system and how they can break into the system through what we call entry points, which is really what we're doing when we're modeling the threats. And it's a very important and often confusing topic for people. I'm Christian Espinosa, the founder of Blue Goat Cyber. We have our co-host here Trevor as well. And Trevor is our CTO and director of Medtech Cyber Security. So, Trevor you want to dive in and kind of explain or define, uh well maybe let me ask you how you're doing and where where where you are you today in the world before before we dive right into it. Trevor: Yeah, I'm doing good today. I think we've both been on a travel kick for the past about six months and so uh I'm hoping to close it out soon, but I'm out here in San Francisco for JP Morgan week. Christian: Okay, awesome. Yeah, I'm in actually at my home base in Tempe, Arizona. I'll be heading to Vegas on Saturday uh and driving some fast cars there and doing some karting and doing some dangerous things, you know, like I like to do. Went shooting yesterday. I have a a new gun I wanted to dial in the scope on and stuff, so. Trevor: Yeah. There you go. Christian: I'm uh, you know, prepared for the threats myself. I look at all the entry points of my house and I'm ready, ready in case somebody tries to break in. So. Trevor: Yeah, I think it's funny you mention, you know, Tempe as your home base. Like my home base normally Flagstaff, but uh, with how much I end up traveling, you know how your phone will prompt you and say, "Oh, do you want to set your new home location?" For me that was the Dallas Fort Worth Airport when I got that notification. Christian: That's funny. I always get delayed in Dallas. I I don't like flying through Dallas. There's always a storm every time I go there it seems like. Trevor: They lost my bag last week, and so I came here with pretty much nothing and just had to go get all new clothes. Christian: Yeah, well, uh, my wife now would enjoy that opportunity of buying new clothes. Buy new shoes and new clothes. Every chance she gets, you know. It's like we need more closet space. All right, so let's dive into threat modeling. So what exactly is threat modeling? How would you define it? Trevor: So threat modeling is trying to understand what can really happen with a device. Um, you're stepping back and getting into the head space of an attacker, looking at a medical device, an application, a network, whatever it may be and trying to come up with hypothetical situations of what you can do to essentially try to compromise the system. Um, really this is in an effort to try to find initial remediation paths or mitigations. Not necessarily remediations since it isn't a proven problem yet. But it helps you build a secure product and build a secure network. Uh it should be done early and often. It shouldn't be done as a one time thing, but it's something that can help you identify problem points early on and let you design them out of the system. Christian: I hear that quite frequently that we should do things early and often. Is that the best practice or is that what people actually do based on, you know, our experience? Trevor: Well, those are two separate questions. Uh, is it the best practice? Yes. Security is not something you can finish with, it's something you need to start with. Is that what happens? No. So more often than not when we're interacting with a medical device and it's very easy for this to happen, you know, cyber security isn't at the forefront of most company's minds, especially not a medical company. So, it can get pushed to the back or it can slip through the cracks and cyber security isn't the initial focus. And then when comes time for submission to the FDA and getting regulatory approval, that's when these cracks can start to expand a little bit and it becomes apparent what was missed. So, very often in practice, that's what we end up seeing is manufacturers are not conscious of cyber security early enough and they try to essentially bolt it on at the end, which isn't always a good solution. Christian: Yeah, so you're saying early on in the software development, we should be considering cyber security and doing some of that threat modeling as we're coming up with the requirements uh before even start the design. It sounds like. Trevor: Correct. Yeah, we'll go into that requirements phase because I think this is the perfect time to really talk about threat modeling. Once you understand what your product needs to do, so we'll say that you have a a pacemaker. You're looking at what it's supposed to do from a functional perspective. Um, you know, you look at what it needs to do from a non-functional perspective. So anything around security, anything around the internal flows. And then that lets you figure out what can go wrong there. So, let's say that this pacemaker you should be able to change some of its configuration over Bluetooth. Uh a functional requirement is going to be it needs to have a Bluetooth connection in and out, it needs to have a Bluetooth connection that is not reliant on much power, and is short range enough that it can't be intercepted from far away. You look at the security requirements around it. You should have Bluetooth authentication enabled. You shouldn't be able to read and write to handles. So, then you can go from there and really get into these threats. Well, what happens if you can write to the handles? What happens if Bluetooth pairing isn't or Bluetooth um authentication is not enabled and you can connect to it with any device. And that starts leading you down these different paths of what can go wrong, which um is a really good way to start thinking about how to design security in just from a conceptual perspective of a product without ever having a physical device yet. Christian: That makes sense and it sounds like what you're describing would be considered entry points from an attack perspective, right? Like ways into the system. Is that correct? Trevor: Yes. So, and that brings up a great point. Entry points aren't necessarily everything that you're worried about when you're threat modeling. Uh, it's the probably the main concern. You take a look at, we'll pick this mouse for an example. This mouse is a Bluetooth mouse connecting to my computer. So, if I was threat modeling this mouse, I would want to look at the Bluetooth interface as the main entry point. That's how you get inside of the mouse. Now, having said that, there can be other things to think about. Where was this mouse made? Was it made in a secure environment where no one can tamper with the manufacturing process? Who made the mouse? Was it made by someone who is trained on security? Was it made by someone with potentially malicious insider threat goals? Uh there are a lot of different questions you can ask about just the process behind things. Where is the mouse supposed to be used? Is this mouse going to be in a hostile environment? So outside of just the entry points, there are a lot of different things that you need to consider for threat modeling. Christian: I think that's a great point because when we do our threat modeling, uh we look at the entry points, which could be a USB port, Bluetooth like you mentioned, HDMI port, any... any physical entry point. It could be a Wi-Fi connection, or an ethernet connection. It doesn't matter. It's a way into the system. And I think a lot of people sort of stop there. But the reality is, other entry points are sloppy coding. you know, so it's the developers don't write secure code, then there's a vulnerability that could be introduced. Uh there's entry points into the supply chain like you mentioned, which is why we have to do a software bill of materials because if third party libraries have vulnerabilities and somebody could exploit that as well. Uh what other entry Am I missing any entry points or have we kind of covered them? Trevor: I think those are often the main ones that we're looking at from the device itself and what goes into the device, but the environment of a product is really important as well. So I briefly touched up on it, but trying to figure out where something is going to be used is really important and especially so with medical devices. Uh, any pen tester who is interacted with a hospital network has horror stories to tell about it. Hospital networks are inherently very insecure. Um, 89% of healthcare facilities undergo at least one cyber security attack every single week. Christian: So, I like to say hospital networks are hostile networks from a cyber security perspective. Trevor: Yeah, they're hostile networks. You don't know what's going on. They're often fairly mismanaged, and so when you're introducing a new device into there, you have to be aware of that network. Now, let's say a device is intended to be used in a home network. Home networks are typically far more secure. Uh, home networks rarely have anything exposed out into the open internet. They're, isn't there aren't as many people in and out of the network. It's pretty unlikely that a hacker is going to try to break into your apartment to hack into, you know, an oxygen pump. But in a hospital, that isn't very unlikely. They can try to do something outside of that oxygen pump, move into medical records, move into further parts of the network. So there's a lot more to gain and it's a lot easier. So, thinking about all these different scenarios helps guide you on that threat modeling path. If you're looking at a device that's in a hospital, you're going to have to assume that it's under attack all the time, and what are the implications for that? So it's not necessarily a one size fits all problem when you're threat modeling. You can't just look at the device. You have to look at what it's intended to be, what it's intended to do, and where it's intended to do it. Christian: That's a good point. So, I like to give an analogy of, uh, like threat modeling of where I'm currently living. You know, I guess the entry points would be like the window or the doors. Uh but then also there's things in my condo unit that were here before I got here such as the TV. So it's it's feasible, now that were thinking about this that television could be compromised. Uh, could already be compromised and could be recording, you know, things or or doing whatever. Uh same thing with like the refrigerator or any of, you know, appliance that has some sort of, uh, firmware or software on it. Uh, so if I were to actually assess all the threats, I would have to look at all those devices as well, which are already in in in you know, my contained unit per se, which is kind of like the software that's already in a, you know, hardware device. You think that's a fair analogy? Trevor: Definitely. And with, we'll kind of take it a step further. So, when looking at something that's in your system, you know, those entry points are the main concern, but figuring out what happens next is important too. So we can use that, or a great example would be if you have a safe in your house. These entry points are going to be the windows, going to be the doors. When they get in, they're going to look for money or for, you know, your passport or whatever important valuable things you have. If they're stopped by a safe, that's another additional defense on the inside. That's a layered approach to security. So a lot of these things that can be brought in, not only can they introduce risk, you don't know if your TV's been hacked into, but some of these pre-existing areas can increase security. And so stuff on the inside should be evaluated just as much as stuff on the outside. The only difference is people aren't going to go outside in as an attacker, they're going to go, or sorry, inside out as an attacker. They're going to start on the outside, try to work their way through. Christian: Well, they could go inside out if it's a supply chain vulnerability where, you know. Trevor: Yeah, that's a fair point. Christian: an adversary has got malicious code on a device and it's exfiltrating sensitive data somewhere, right? And that's why it's important to look at the software bill of materials and also do static application security testing, which we do. Um, you're kind of talking about like, what if someone goes through an entry point? What's... what's the things they can do? Which is where these frameworks come into play, like STRIDE, DREAD, PASTA, all these threat modeling frameworks. They're a way to look at, okay, once we get through the entry point, what are the things we can do? And what's the risk associated with them? Do you mind going over, I guess, STRIDE first, since that's like the most prevalent one? Trevor: Sure. So, we'll walk back a little bit first and explain where STRIDE comes in as one of our favorite threat modeling frameworks. For medical devices, there is a fantastic guide called the MITRE Playbook for threat modeling medical devices. And that is asking four questions. We've already kind of gone over the first two questions. It is, what are you working on? What can go wrong? What are we going to do about it? And did we do a good job? So, if we're looking at what are we working on? That's understanding where these windows are, where the doors are, the entry points, what's on the inside, what can happen. Now when we're moving on to what can go wrong, that's the hypotheticals from the threat modeling, that's understanding the use environment. And a great way to organize your thoughts when doing that instead of just having a disjointed process of listing anything that you think of that could go wrong is to categorize it by different threat types or attack types. So, different threat modeling frameworks have different application, they go through different processes, they have different outcomes. STRIDE stands for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. So it's taking a potential problem with a device and then putting it into one of those categories. So if we say that this device has a database storing sensitive information and our potential threat is what if an attacker guesses the password. That would be an information disclosure problem. So we can group it into that bucket. It helps understand different categories of threats because often times you can fix them with one remediation. It helps go through this organized process, so you try to think what is everything you can do to tamper with the device. How can you elevate privilege in the device? And it just is a very easy visual way to understand what's going as well. Christian: With with medical devices, you talked about information disclosure. Uh out of that stride, those different elements of stride, what's the most important or is there one more important for medical devices would you say? Trevor: I think it depends on the device. If you have, we'll take three examples. So in my opinion, tampering, uh information disclosure, and denial of service in general are going to be the more important ones. We'll look at three different devices to explain what that is since it's not necessarily going to be applicable across all devices. So the first we're going to say we have an EMR system, an electronic medical record system. This has a lot of sensitive patient data and it's not something that you want to have stuff come out. If you have problems with tampering, sure, it's an issue, but that's not necessarily going to be the end goal of an attacker of an attacker. And if they're just messing with data without knowing what they're changing, it can be a problem, but if you have backups, it's not going to be an irreparable problem. The main concern is that information disclosure. If an attacker can get into this EMR and start ciphoning out a lot of information, a lot of protected health information, uh that can be leveraged against the patients and that's a really big problem. Now, if we're looking at another device such as a life support machine. Life support machines are not going to have information in most cases that an attacker cares about. So information disclosure, it's a little less relevant. Now, denial of service would be a big problem. If there's a critical life-saving machine and it doesn't turn on or it doesn't operate normally because of a cyber security attack, that could potentially lead to immediate loss of patient life. Uh, similarly, let's say, we deal with a lot of IVD machines, so in-vitro diagnostics. That's trying to say whether or not a patient has a disease or a condition. Christian: Let's let's back up a second. IVD is a little confusing for people. So in-vitro diagnostics is basically taking a sample of tissue or your blood and running it through a system to come up with what's wrong with what's wrong with you. And then recommending a course of treatment, right? Trevor: Exactly. And part of that is the, sort of the decision-making on what's happening and the diagnosis. If you can trick that and so tamper with the results, you can say either, oh, this patient has a disease that they do not, or this patient doesn't have a disease that they do. And either put them on a treatment they shouldn't be on or deny treatment to them that they need. So I'd say those are the three main use cases that I see, uh or use cases, the three main threat cases that I see as the most impactful against a medical device. Christian: Yeah, and when I first started working on medical devices in 2014, it was an IVD system. And the two areas that had the most impact to patient safety were denial of service and delayed service. So it's an example is someone has sepsis, which their blood is toxic, and they they can't get the result because the system went down or the the result is delayed. So it's not just purely denial, it's also delayed, then uh they could die because sepsis can kill you if your blood is toxic. Trevor: Yeah. Yeah, and especially with something like that, it's interesting, sort of counterintuitive. Um, a lot of diagnostics for something like cancer, delayed results aren't really a big deal. Cancer isn't going to kill you tomorrow. And so, but something like sepsis or tuberculosis or pneumonia, those are things you need to figure out immediately. So, even getting past the category of the device and getting into the application of the device is still another big consideration. Christian: How does uh, I I think a common misconception on threat modeling is it it it's not necessary for penetration testing. Would you say that's a common misconception or do you think it actually is necessary? Like if with a standard penetration tester in your mind, actually do threat modeling or would they just start penetration testing? And what and what do you think is preferred? Trevor: I think that that is pretty common for penetration testers to just get right into it without any threat modeling. I don't think they're... they don't want to do any documentation typically, they just want to start hacking stuff. Every pen tester I know, myself included, the worst part of their day is writing reports. It's horrible. And, that's the only thing that matters though to the client typically, right? I know. But to the penetration tester, all they care about was cool how cool their hack was. That's that's it, and so they don't want to do anything else. And threat modeling is just a lot more documentation. Christian: Um, but can you do an accurate penetration test if you did not do threat modeling? Or are you kind of like guessing? And what do you think? Trevor: You're you really are guessing and sometimes that can be actually more beneficial in one way. Uh, that's the pure black box approach, which is still very valuable because that's often a little bit closer to what a real attacker is going to take as their avenue for attack. A threat model... Christian: And let's let's back up a second because I'm not sure all of our audience understands what a black box approach is. So a black box means the attacker knows nothing about the system. It's just a box and that's all they see. They don't know anything inside the box, they don't have any documentation about it versus a gray box, they know some information, and a white box, they know all the information. Trevor: Exactly. So with testing a medical device, typically we lean closer to that white box approach. We get all their documentation, their software requirements, their architecture, and we try to understand as much as we possibly can about the device before we do anything with it. Once we have all this information about the device, we can do very accurate threat modeling for what could go wrong, and then try to realize those threats. Uh, we can even go so far as digging into their source code and trying to create custom exploits against specific functionalities that we think might have a problem. This is a very, very comprehensive approach, but on the flip side, it's also very uncommon that an attacker is going to have this level of information and go that far during an exploit. So it's very comprehensive, but it's not necessarily as realistic. So there are there are merits to both approaches. With a medical device, lives can be at stake, so we believe that the more comprehensive approach is better than the realistic approach. And if we have complete coverage, the comprehensive approach, the realistic attack vectors aren't going to work regardless. Christian: Right. Yeah, that makes sense. With, we started talking about STRIDE, and I know there's PASTA and DREAD and a few other threat models. Do you feel like STRIDE covers everything? The what can go wrong aspect of the four questions you ask? Trevor: STRIDE is very good at covering the potential outcome of an attack. So, what we usually want to look at for the how it can go wrong, I guess it's a little bit of a different question. But to walk back to answer your question, I do think that STRIDE does a very good job of covering what can go wrong. Where STRIDE fails is it's unable to say how an attack can be realized effectively. I think a great option for that is the MITRE ATT&CK framework, which breaks things into attack categories or threat categories. So you're looking at a specific technique for exploiting an attack. I don't think it's a great area to start with, especially when looking at a medical device, since you have such broad areas to cover at first and slowly refine your way down. It doesn't make sense to start with an individual attack, it makes sense to start with what is the expected outcome, what is an attacker going to want to do? We'll go back to looking at these device categories. An attacker is going to have a different end goal if they're attacking a pacemaker as opposed to if they're attacking an EMR. So working your way back from that and then until you get to the individual attack vectors, I think is a better approach. Each threat modeling framework has its own pros and cons. I don't think there is a one size fits all solution, but I think STRIDE is great for getting that outcome and then moving further back. Christian: Yeah, and I think that's a good good analogy between STRIDE and the MITRE ATT&CK framework, which is more, uh, I guess technique-specific. STRIDE is more result-specific. I I do think one of the things about the MITRE ATT&CK framework that I like is it takes into consideration chaining vulnerabilities together, uh, which STRIDE is more outcome-based and... you know, once you get into a system, there there's something else you can do. Kind of like the analogy you gave earlier, like if you break into my condo and I've got a safe, you know, you you can maybe get to that safe if I left it unlocked. Uh so there's like these different vulnerabilities that can be added together to result in the ultimate holistic vulnerability or problem that needs to be solved. And it might be multiple layers of defense like we talked about, and multiple controls to be put in place, but I think a lot of people think it's just one vulnerability that you exploit and and fail to understand like from a threat perspective, what's the next thing somebody could do? And how can you protect that? Because you want to look at that entire tree, that attack tree or that threat model tree, and and and cut things off as close to the root as you can. uh and at each of the branches. What do you think about that approach? Trevor: I definitely agree. So, like you said, it's not about a single issue. You can have a vulnerability that gets you in the first layer, and then for the second layer, you find another vulnerability, and then a third vulnerability to get in past that layer. It doesn't prove necessarily the full scope of the impact if you just exploit that first vulnerability. And I think MITRE ATT&CK does a great job at letting you really run these problems to ground and understand exactly what really can happen. Christian: And that's where what I talk about the, when I talk about the differences between a vulnerability scan and a penetration test. A vulnerability scan often, well I think like 99.9% of the time just identifies that first vulnerability. Whereas the penetration test gives you the holistic depiction of what can really happen because you take it a step further. You identify the first vulnerability, you exploit it, then you see what else you can get to. So I always think, and I always advocate that a penetration test is going to give you a much more accurate depiction of your risk and vulnerabilities than a vulnerability scan. Trevor: I agree. Do you think that there's still value and if so, what do you think the advantage of just a pure vulnerability scan is? Christian: I think if you are on a Windows domain and you have an enterprise environment and you're doing authenticated vulnerability scans, I think there's value because it tells you, you can it tells you which patches you're missing, uh configuration challenges. So it can tell you things that you need to fix and then you should still have a penetration test done to validate you fixed it. But you know, if you do that iteratively, it can help you understand which applications and which operating systems need to be patched and updated. Trevor: So it sounds like the vulnerability scan is great for going wide but not really going deep. Christian: Yeah, I would I would use I would agree with that analogy, yeah. Trevor: Awesome. Christian: Well, we're coming up on time here. Uh, any last words on threat modeling or anything we've we think we've neglected to cover that's important? Trevor: I think we would just be remiss not to emphasize the point, do it early and do it often. You can't nail security on at the end. Christian: You know, threat modeling, I do it in real time. I I, maybe because of my military background, but if I'm in a restaurant, I I look at all the entry points and all the exit points. I look at where the attacker can come from, how I'm going to get out if the restaurant catches on fire. I always just do this kind of in real time. Maybe it's just a habit I developed from my days in the military, I'm not sure. Trevor: Yeah, I think that's a military thing. I don't have that habit. Christian: You don't? Trevor: No, I don't. Christian: Yeah, I I I always think, I'm always thinking, look, where can I sit, where can I see who comes in the door, and how am I going to respond, and where can I move, and how can I get out if something happens? You know, I I always assess that. Trevor: When I was um doing, living in Belize and doing a lot of freediving, I would have that same thought about sharks. When you, you catch a fish, you have to figure out, okay, there are sharks everywhere, the second they smell the blood, they want to attack your spear for the fish. What is my way out every time? And sometimes it wasn't just up, which is what's intuitive. It's, oh, there's a shark coming. I can try to, you know, go through this little canyon, and the shark isn't going to want to follow me. Christian: Or you can let go the fish. Trevor: Or you can let go the fish. But if you shoot a big fish, you don't want to let it go. That's a lot of work to get that. And um, so, you know, that's kind of another fun real-world example of constant threat modeling is figuring out how do I not get attacked by a shark? Christian: That's a good, good, uh, analogy there. Well, this is going to wrap up, we're going to wrap up our podcast here today on threat modeling, and the next podcast we're going to be talking about post-market surveillance and how to detect anomalies, which could be malicious or could just be an anomaly, uh, in medical devices. So thanks for tuning in today, for tuning into the Med Device Cyber podcast, and we hope you found value in the podcast, and we'll see you next time.