Building Resilient Medical Devices: A Look at the Essential Technologies and Infrastructure | Ep. 4

In this episode of The Med Device Cyber Podcast, the hosts delve into the critical security considerations that should be integrated during the design phase of medical devices. They argue that addressing cybersecurity early in the development lifecycle—a 'shift-left' approach—is far more effective and cost-efficient than attempting to add it on later. The discussion is framed around the security controls and areas of concern highlighted by regulatory bodies like the FDA, emphasizing that these are not merely best practices but essential requirements for market approval and patient safety. The hosts begin by differentiating between functional and non-functional requirements, categorizing cybersecurity as a crucial non-functional requirement that defines *how* a system should operate securely, rather than *what* it should do. They then systematically break down the key security control categories recommended by the FDA. The conversation covers Authentication, which is about verifying a user's identity through methods like passwords, multi-factor authentication (MFA), and biometrics. They distinguish this from Authorization, which dictates what an authenticated user is permitted to do, stressing the importance of role-based access control. The discussion moves to Cryptography, explaining the need to protect data both 'at rest' (stored on the device) and 'in transit' (communicated over a network) through robust encryption. They also touch upon Code, Data, and Execution Integrity, which involves ensuring that the device's software and data have not been tampered with, often achieved through techniques like secure boot and checksums. Finally, they cover the importance of Resilience and Recovery, designing devices to withstand attacks and recover to a known good state, and the necessity of secure Firmware and Software Updates, which, while convenient, can introduce significant vulnerabilities if the update mechanism itself is not properly secured.

Host: Hey there, welcome back. Today we're going to be talking about security considerations as part of the design phase of device and what can be done to prevent vulnerabilities from popping up further right in the development process and looking at some of the big considerations as far as the areas that should be covered by security in the eyes of the regulatory bodies such as the FDA. Guest: All right. Sounds pretty serious stuff. Host: Oh yeah. Yeah, when we're looking at these medical devices and the impact of breaching them, it can get pretty serious. Guest: All right, and where do these um controls come from? You're talking about, we're going to cover. Are these standard best practices or like where where do they come from? Host: These controls are partially going to be standard best practices um industrywide. And they're also going to come, we're going to look at the FDA's requirements since that's what we have the most experience dealing with and what we see the most and what the FDA sees as the most important areas to address cyber security. Guest: Okay. Awesome. So I think one of those requirements is authentication. Is that correct? Host: Yeah, and how we're getting to the controls around these requirements. So I want to talk a little bit about a requirement in a device period. Guest: There can be a- It's a good place to start. We should back up a little bit and talk about that, yeah. Yeah. All right, go ahead, sorry. Host: There's going to be the functional requirement in a device. So, if I have my cell phone right here, a functional requirement is put a password in place to log into the phone. Now, the non-functional requirement there might be how is that password protected? Is it just stored in plain text somewhere in the phone where if someone gets in, they can just read it. Is it hashed in some way? Is it stored up in the cloud? Is there an authentication manager? The non-functional requirements are sort of where it can get a little bit murky and where security really needs to be looked at. So for each of these items, they are typically going to be the non-functional requirements that we're looking at more. And for each of the functional requirements, we need- Guest: This is kind of like cyber security as a whole. Isn't cyber security as a whole like a non-functional requirement typically? Host: Pretty much. Uh a lot of people see cyber security as a necessary evil. It's that one thing you have to do once a year to make sure that you're able to keep selling your product, which is often a hard way to think about it since that means you're often not addressing security at the very beginning and often making it a little bit harder on yourself later down the line. Guest: So that's- What what does that mean necessary evil? I'm just think I I heard that term a lot with cyber security. I'm thinking like, like what else is a necessary evil in life? Is it just cyber security or is there something else? Host: I think... I mean, great example, like going to the dentist every year. I have I want to make sure that my teeth look pretty nice, but I don't necessarily like driving all the way down to Phoenix every time I have to go to the dentist. And so that's not always something I'm excited for to wake up and do that. I'm not excited for a $3,000 bill at the end of the day for going to the dentist either. But Guest: I guess it is a necessary evil. Yeah. Yeah. And I went to the dentist once and they messed up drilling my teeth and I haven't been back. I almost passed out, it hurt so badly. I was trying to like just deal with it because they were drilling out to put a cap on or whatever, and a crown on, I think it's called. And they forgot to put the right novocaine or whatever, those injections. I was just trying to handle it out, handle it, but I tears started coming down my eyes the pain was so bad, so I haven't been back to the dentist since. So it definitely was evil, for sure. I can Yeah. Host: Well, you definitely should go to the dentist, so that's a whole other conversation. Guest: I brush my teeth and floss 'em, you know. Why do I need to go to the dentist? Host: I brush my teeth and floss 'em every day still. I have great teeth, but last time I went, I had to get some work done, so. Guest: Okay, all right. You should go to the dentist. All right, so that's another necessary evil, it's like cyber security. Host: It's... Guest: ...so cyber security is a necessary evil you're saying and these controls are necessary, um is part of cyber security. Uh but it's also the non-functional requirements is what you're saying, is where cyber security typically falls into. Host: So... Guest: So one of the things we talked about was uh, was authentication, right? That's one of the controls that are necessary. Host: Yeah, that's correct. And that's part of the example with uh using my phone for authentication. If I want to authenticate, that's proving that I am able to access the system. So... Guest: That's proving you say you are who you say you are, right? And that's typically done through like a username, a password, a PIN. You know, there's multiple factors of authentication, right? Host: Correct. Or it can be, you know, a token, a physical device, a little hardware token, anything. Um, and an authentication can be handled in a few different layers. So there's usually the initial authentication, there can be multi-factor authentication where like if I'm signing in to my email account, I get a little text up on my phone with a code and that helps to make sure that security is addressed. And that's... Guest: So that's using at least two factors of authentication in right? So what are the the factors? So everyone knows what multi-factor authentication is. In case people don't. Host: So the first factor would be my username and password. Guest: That's factor one. That's something you know, something you know, username, password. Okay. Host: There can be something you know, something you have, and something you are. Guest: So something you have is like your phone to receive a text message or... Host: That would be my phone for like a one-time password. Guest: Okay. You have to have the phone. Host: Yep. Something you are, um, kind of an example of that would be like a captcha, making sure that you are not a device trying to scrape something, uh, saying you are an authorized user, you're not just a web scraper. So it gives you a captcha to prove that you are who you say you are. Guest: Yeah, I always thought something you are is uh biometric. Uh the captcha example may work as well, but biometric like your eyes, you know, I scan, uh a retina scan, which is not used that often, a hand geometry scan, a thumbprint, a fingerprint, that's something that is unique to you, something you are. Host: I often see thumbprint as being the pretty popular option there, but I typically don't see a thumbprint for a medical device. And so, the something you are becomes a little bit of a looser interpretation. Um, often times what we recommend is usually multi-factor authentication is going to be two of the three. And we recommend something you know and something you have for that. And so there's something you have is either going to be like a hardware token or a one-time code from your phone and then there's something you know. Uh, in a lot of sensitive environments, we'll address the something you are as far as like a biometric consideration. But like you said, they're not as common and they're much less common in a medical device. Guest: Yeah. Well, often these devices are in a semi-secure area physically. Um, you know, they're in a protected area of the hospital, but they're also in a hostile environment if they're connected to the hospital network. I consider hospital networks hostile because from my experience with pen testing and everything else in in hospitals, it's kind of like the wild west. Everything's not segmented, everything's on the same network, and you can go in the chapel in the hospital and plug into an ethernet port and next thing you know, you're scanning medical devices that are in the the OR, the operating room. So it's pretty uh pretty scary. That and authentication is extremely important in that case and we've found many of these devices, uh and I think you talked about this in the previous episode, that have the default username and password for like a web, um a web admin interface to the medical device. Host: Yeah, that's a pretty common thing to find. Um, a lot of devices will integrate a third-party component or like a database, for an example, and it's just admin admin for the credentials. Boom, there you go. And you're able to compromise sensitive information without necessarily needing to perform some complicated hack against a device, you know, kind of the movie style stuff. It's just go in, guess the password, get out. And so that's definitely a pretty big problem that we see as far as authentication goes. Another one of these concerns is going to be authorization. And authorization is essentially proving that you are able to access, proving that you are approved to access this data. Guest: Yeah, so once you're authenticated, that just means you are you you are who you say you are, but then you have to be authorized to to what you can do on the system, right? Host: Correct. And authorization is going to be handled in two ways usually. We'll see different users. And so that could be when you go to log into your email, you're looking at your emails alone. If you log into your email, you can't see my emails. Or different roles where if an administrator logs in, they might be able to see everyone's emails. But the user level should only see their own emails. And a very big part of pen testing and likely one of our biggest findings and most common findings on medical devices is broken authorization. We're able to compromise one user account and use that one user account to compromise a hundred more. And that's a very big deal for the FDA. That's part of the multi-patient harm view and the sort of widespread impact of compromising a device. Guest: What What is that? What does that mean? We could do another episode on these security architecture views, but multi-patient harm view, that means if we hack into a device, we can cause damage not just to one patient, but to multiple patients at the same time, right? Host: Yep, exactly. And that can be through a few different ways. Uh that can be compromising one device and using an exploit on the device to attack another user on that same device. Or it can be compromising a device and then moving through a network to compromise a different device. I know earlier you were saying some of your stories about pen testing hospital networks and how it's kind of the wild west. One of my personal favorites is hacking into a printer if I'm doing a pen test in a hospital network. And I can breach this printer. I can move from the printer into a workstation, I can move from the workstation into an X-ray machine or into a data store and find patient records, something of that nature. And I actually remember not too long ago, I had that exact scenario come up where there were default credentials on a printer. The printer had domain credentials and the domain credentials worked on file shares with patient records. And so by getting in that printer, I was able to just spread out through the network. So that's sort of the multi-patient harm view is moving from one device to another or one user to another. Guest: And affecting multiple patients, you know, like it says harming multiple patients with one attack, effectively. Host: Yep. Interesting. Guest: I think we covered like the eight uh cyber security controls recommended by the FDA. Uh in your opinion, Trevor, do you think like if a medical device manufacturer is follows these eight things that the device will be secure or there are other things that they should consider? Host: It's difficult with a medical device because of how loose the term medical device is. A medical device can be anything from a bandage to a surgery robot. There is such a wide range. So, of course we're only looking at cyber devices here, which are devices with a computer, some sort of software component. Um, the considerations here are a very good general first area to look at. In most cases, these are gonna cover the vast majority of security considerations. But each device is unique, each, you know, landscape is unique, the attack surface is going to be unique and as a result, the security considerations need to be unique. Which is why it's really important to start addressing security, so far left in the development cycle at the initial inception phase. Guest: So you're advocating for an S S D L C as they like to say, a secure software development life cycle where we actually develop the requirements, the design with security or cyber security in mind. It sounds like you're an advocate of that or DevSecOps some people like to say as well. Host: Exactly. It's something that should be thought of in the early phases instead of letting it slip to the end. And that's, it saves time, it saves money. Um, the cost of remediation and sort of redesigning a device when you're about ready to submit is a lot more significant than if you had just addressed security in the first place. It also takes a lot more time to go back. You might find that a security flaw is in a functionality that can't really be changed. And so you might have to change the core functionality of the device as a result. So, making sure that you're hitting security early and often, typically saves a lot of headache down the line. Guest: 100%. I'm an advocate for. What what is that saying? Um, measure twice and cut once, you know? So... Host: Yeah, measure twice, cut once. Guest: Yeah. We want to do it right the first time for the beginning before we actually start, you know, making the uh production or producing something or making our cuts or um manufacturing something. or even doing the software development. It's all it's all ties together. Awesome. I think we covered the eight uh categories here pretty well that the HTTP recommendations. And I hope if you're listening, you got some value out of this and some insights other of this episode. And we'll hope to see you on the next one. Have a great one.