Postmarket Surveillance and Anomaly Detection for Medical Devices

Host: Hi, welcome back to the Med Device Cyber podcast. I'm your host Christian Espinosa. I'm here with Trevor Slattery. And today we're going to talk about post-market management and anomalies that we might find in a medical device. Host: We talked about premarket before, but the challenge is, what happens after the device is on the market? How do we make sure it stays secure? And if a vulnerability is found, how does somebody, a manufacturer update that vulnerability? So this is a very critical topic. Host: And before we dive into it, I just want to introduce myself a little bit. I'm Christian. I'm the founder of Blue Goat Cyber. I'll let Trevor introduce himself. Trevor: Hi, I'm Trevor. I'm the CTO and director of MedTech security at Blue Goat Cyber. And uh... Host: All right. Trevor: Yeah, so how's your day going today, Christian? Host: My day is packed. You know, I've got all these days. It's like block after block after block of stuff to do. Host: I wanted to go karting today because I signed up for this endurance karting event. Um, and I want to get into like a 24-hour one. But uh I have, I just haven't had time. So my endurance is probably not that great. Trevor: 24-hour, so 24 hours of nonstop karting. Host: Yeah, you need a team, but yeah. Trevor: Oh, okay. Host: You you you you kart, you do a pit stop. You have to do pit stops to change the tires and yeah. I I I should probably start with like a, the one I'm going to do in this month is two and a half hours. Um, but I want to gradually work up to 24 hours. Trevor: Yeah, that'd be that'd be a lot. I think about, you know, if I've been up for 12 hours and I'm driving, I'm already getting tired. If I'm up for 24 hours and I'm driving, I shouldn't be driving. Host: Oh, that's that's a challenge, right? Trevor: Yeah. Host: All right. So we've been talking so far about pre-mar, in our previous episodes about pre-market, which is all the things we need to do for a medical device before it gets on the market. And now we're focused on post-market because once the device is on the market, we still have to be concerned about vulnerabilities because a new vulnerability might be discovered in Bluetooth and in a third-party library. Uh and how do we handle all that is is really the topic of today's discussion. Host: So, and when we say pre-market, like I said, it's before the device on the market, post market is it's on the market. So a couple of the main areas for post-market, and I'll just go over these and then if I missed any, you can fill me in, fill it in Trevor, is what's called a coordinated vulnerability disclosure system. So that's one of the requirements for post-market. Host: The software bill materials management is another requirement. So if a vulnerability pops up with a third-party library. Annual penetration testing at least once a year and vulnerability testing as well as static application security testing. And then one of the challenges I think with post-market is if a vulnerability is discovered, how does the manufacturer securely develop a patch for it and then deploy that patch? Host: Because not every device, the patch can be deployed over the air or OTA, some people like to say. Sometimes it has to be deployed by a field technician that physically goes out there and plugs in a USB drive. And then what the scenario that always goes through my head is what if that USB drive is infected? Now you're just making the problem worse, right? So they have to have a total product life cycle that is very secure. Host: Did I miss anything like the requirements? And we can dive deep a little bit deeper in each of them. Trevor: Yeah, I think that's a great overview of everything. And of course, every device is going to have a little bit of a a different threat landscape and as a result, different post-market requirements. But in short, the main things that need to be covered is continued security through the supply chain, uh continued security through the public, which is where that vulnerability disclosure system comes into play and then finding a way to fix things in as they come up. Trevor: So, an interesting area that I'd be curious to hear your thoughts on, and I know the FDA has been pushing away from this. They've been pushing away from devices that can't receive updates. Um, it's a bit of a double-edged sword as update functionality is a new attack vector. But if you're unable to update a device, it can be a very involved process to make changes. So I'm curious on your thoughts on how to manage devices that are unable to receive updates once they're out in the field. Host: Yeah, I've I've got a quite a bit of experience with that. We've uh dealt with devices for, I've been doing this for a little over 10 years now. And devices that can't receive an OTA or over the air update are often times more secure. Uh because like you meant alluded to, that pathway to allow a remote update can be exploited and we've had clients that have not secured that pathway or that environment. Host: So, it opens up a can of worms though because you have to send somebody to the device or you have to train the physician, the user, the device, the doctor, the nurse, whoever and how to do the update and mail them a thumb drive or something. So it's important to have a mechanism in place if your device can't be updated over the air and make sure that mechanism is secure. Host: So if I am to put something on a thumb drive like a firmware update and provide the instructions to a field technician, I have to make sure that that thumb drive is not compromised. And there's been lots of scenarios where people have bought thumb drives at trade shows, they've received them, and they've all had malicious code on them, right? So we have to have a way to ensure the security of our update process to fix the vulnerability because it is another pathway to introduce another vulnerability. Trevor: It's like that one scene from Mr. Robot where the guy on the street is giving out USB drives with his mixed tape on it and then compromises a bunch of people's computers. Host: I, are you a Mr. Robot fan? Trevor: I personally didn't like the show that much, but I feel like I'm obligated as a penetration tester to watch it. Host: I watched one episode and because all the penetration testers kept talking about it so much, I I I felt like it was it was like too mandatory to watch. I I only watched one episode. But maybe maybe I'll go cuz maybe I'll go back and watch it cuz I felt left out of the conversations when they're all talking about Mr. Robot, you know. Trevor: I don't think it's worth watching, but anytime anytime I introduce myself to someone I say, yeah, I do offensive cyber security. The first question is, have you seen Mr. Robot? Every time. Host: Well, I do sales too and the first question is not always have you seen Glengarry Glen Ross? Trevor: Yeah, I think Mad Men's a whole lot better. Host: I haven't seen that yet. Maybe I'll check it out. Host: All right, so what the over the air update, let me let's go back to that. We talked about a city of Phil technician. The over the air update, which the FDA is pushing for. That's what you said earlier. That opens up a whole another attack vector based on our experience with clients. We've had clients that are that don't have a separate network to push the updates to their devices that they deploy. Host: They've had the corporate network and somebody that's attached to the corporate network is pushing it or an update to the device. And that's a problem because there's no segmentation on the corporate network typically. So if the HR person's computer is infected because they clicked on a fishing email, that computer can affect the computer that's pushing the update to the device and now there's a mechanism to actually infect all the devices remotely. If if you've seen that before? Trevor: Yeah, yeah, that can definitely be a problem. And using device, medical devices as an entry point into compromising a full hospital network is very, very common. It's a very common vector for threat actors. Um, the Internet of Things is notoriously insecure. I know a lot of our uh a lot of our better hospital hacks at Blue Goat have been through insecure x-ray machines and printers. It's very easy to move through them. Host: So you know I I have a it's maybe a pet peeve of mine, but I've never understood why people say insecure versus unsecure when talking about devices in cybersecurity. It's not like the device doesn't feel good about itself. It's insecure. Trevor: So it should be unsecure? Host: Yes. Trevor: I'm not sure unsecure is a word. Host: Well, maybe that's the problem. We make up words in cybersecurity all the time though. So... Trevor: Yeah, yeah, well, you know, one way or another, maybe we can maybe we we can we can make it a word if nothing else. Host: All right. Trevor: Um, well, insecure, unsecure, whichever they may be, devices are one of them in a lot of cases. So we need to have a way to protect networks from medical devices interestingly enough. Um, in that perfect example, if a device is connected to a network, you can use it to move through the network. So there is an increased level of risk there. Trevor: Outside of using the devices, an entry point, the device is a lot more visible if it's on the network. So we'll assume that a threat actor has found a way to compromise the external hospital network and move their way to the inside. If this is a remote threat actor and this is not an internet connected medical device, they're not going to see it. And so they're not going to know it's potential for attack. Trevor: If it is connected to that internal hospital network, even if it's the internal network, they'll still be able to see it and potentially target and attack that device. So there's a lot that can go into protecting a device and, unfortunately, update functionality usually does require that to be connected to the network and over the air update functionality. Um, there are some workarounds for it, like using Bluetooth for the update functionality. This is common for a lot of smaller or lower energy devices. But if done properly, if done securely, if the update server is secure and rigorously tested, if the device is secure and rigorously tested, over the air updates allow for very quick deployment of fixes, uh very quick changes in the event of a problem, and more managed deployment across multiple devices. So it is, it is a bit of a double-edged sword though. Host: Yeah, as you're discussing that, something came to mind that is a challenge I've run into because we've worked with health care providers or health care delivery organizations as well as medical device manufacturers. And one of the challenges that an HDO or you know, healthcare delivery organization, a clinic or a hospital face is from their IT department perspective is they have all these devices on their environment that they cannot patch or update themselves and it's a source of frustration. Host: So imagine you're the IT department for a hospital and you have 200 medical devices on your environment that you do not know if they have a vulnerability or not. And if they do, you can't patch it. You're relying on the manufacturer to patch it by sending a field technician or doing an over-the-air update. So yeah, it's a, it's a frustrating scenario. Trevor: A really interesting statistic that I like to bring up is this is a statistic from 2023. Uh, this is an a estimation from the FBI. They believe that over 50% of medical devices had a known critical vulnerability in 2023. So, it's scary not knowing if yours is one of them and having it out on that network. And I think that's why guidance is changing so quickly and the FDA is pushing out such a drive for cybersecurity in medical devices as you don't know what you don't know. And now with a lot more intention and focus behind it, modern devices aren't going to have that problem as much. Host: Yeah, and that ties into, you know, network segmentation uh for medical devices away from typical systems on the, like the systems in the EMR or the systems the nurses use on the hospital. So let's dive into the specifics for post-market. We talked about a CVD, a coordinated vulnerability disclosure system. You want to explain a little bit about what that is and why we need one of those? Trevor: So a CVD is a method for a manufacturer, a company, a network, whatever it may be, to bring in information about a device from the public, from a security perspective. Uh the coordinated vulnerability disclosure, a public security researcher is going to disclose that vulnerability and then the program will be managed by the manufacturer or by a third party. Trevor: Um if the manufacturer is having Blue Goat handle their CVD, then we're the ones managing this vulnerability intake and we interface with the security researcher and then we interface with the manufacturer kind of as a middle man to determine what's actually a substantial report. It is a great way for someone who finds a problem to just come forward responsibly and say, hey, I found this issue, you should be aware. Trevor: Now, one big issue with doing this typically is hacking is illegal. So a coordinated vulnerability disclosure is essentially giving legal protection to a security researcher to say, hey, we aren't going to pursue action against you, maybe we'll even send you a branded t-shirt. You know, something just as a thank you for doing this. But we want to know what problems could be in our device. Trevor: So, it's a great way just to bring in information from a lot of different perspectives. It's not always going to be accurate information. Sometimes people can submit a report where they don't really know what's going on. They aren't, you know, getting accurate information out, but more often than not, it's security researchers with the best intentions trying to just help spread and make the world a bit of a safer place. Host: Yeah, so what it looks like in in in deployment, I guess, is if I'm a security researcher or I don't even have to be a security researcher, I could be a a nurse or a doctor and and just discover something. I go to a website, I put in the device, I put in what I discovered, how I discovered it, my contact information I want to, and then if it comes to us on the back, we run that to ground and determine if it's a true positive or a false positive. And if it's a true positive, like it actually is a vulnerability, we will then work with the manufacturer to fix that vulnerability and then that takes us back to the scenario how do we deploy that fix to the device. Trevor: Definitely. And having that full process going through, working with the whoever disclose the finding is it's really important. So the communication aspect of a coordinated vulnerability disclosure program is often very overlooked. Sometimes the more focus is on just the outcome. If there aren't the available means for a security researcher to convey this information or they aren't sure how to convey what they've found, then it's going to be very hard for the manufacturer to fix it. So having a good process in place for interfacing with researchers, doctors, nurses, whoever finds the problem. Trevor: And then having a good way to get all the information necessary and then convey the fixes from whoever's triaging the finding back to the manufacturer. This three-step chain is really important to keep everything moving smooth. So, that's part of a, definitely part of the post-market management, but the list kind of continues on with um another very key component being supply chain security. So why don't you get a little bit into what is important for considering supply chain security with the post market. Host: Well, supply chain security comes into monitoring that software bill materials. And this is a this is a sticky topic for a lot of manufacturers. They don't want to make the S bomb, the software bill of materials public because they think it's like a playbook to how to break into their system. But you know, if I'm buying a vehicle, I think I have the right to know who makes the brakes or who made the distributor or who makes who what spark plugs are in it, which is like the bill of materials for the vehicle. So I don't think it's necessarily like releasing all the vulnerabilities, but that's one of the requirements is to monitor the software build materials, which is all the software components that were borrowed from other places, typically open source, that go into the manufacturer's product. Host: because one of those libraries that were borrowed could have a vulnerability. Just like Bash was used in a lot of devices in the past and the Bash shell had a vulnerability but nobody knew which products had that third-party library in it. And when that's the problem we're trying to solve. So that was really with Shellshock came out, that was really a major issue. And people are like, I don't know if our device has that library in it and then their device became infected. Trevor: There was a pretty similar issue recently. I'm not sure if you remember. I believe it was this March or April. Um there was a problem with the XC library on A Buntu machines. And there was this big panic in the cybersecurity community that every A Buntu machine had been backdoored by an insecure component that somebody built a fake library into the library. So it was essentially a transitive dependency. And that left a back door in it was estimated around a billion machines because of how prevalent A Buntu is. Trevor: Um I remember at the time getting a call from right when the notification came out, I was in Korea at the time so I was asleep and I got a call from someone on our team at like 3:00 in the morning saying, hey, you need to wake up. We have to fix all of our machines. We have to figure out which ones are using this library. Turns out we didn't use any A Buntu machines at all, so didn't matter for us. But uh it was still definitely a little bit of a panic day in the security industry. Host: Yeah, we like to have panic days. People always talk about burnout and all the stress and cybersecurity and we can never sleep because the attackers are always attacking from around the world. Trevor: Yep, yeah, it's it's it's a 24/7 hands-on job for sure. Host: You got to have your go bag ready in case you have to respond to something, you know. Trevor: With cyber security in general, I always refer to it as the necessary evil of the tech field. Nobody wants to spend money on cyber security since it's expensive and it doesn't provide any value. Uh spending money on research, design, marketing, sales. That's fine. That has a return. Cyber security only costs money. There there is no return from it. The only benefit is that you are passing some compliance check or a regulatory check. So that is the typical perception. Uh as public interest in cyber security is increasing, now hospitals and consumers, they won't buy an insecure device without this information. So, it's a bit of a misconception, but that is the view that most manufacturers and companies take. Trevor: So now when you tell them, you have to allocate a chunk of your budget every single year to this process that you didn't even want to do once, people don't like that. Host: Well, that's like going to the dentist I think you said once. It's a necessary evil. Trevor: It's like going to the dentist, you have to go. Host: Yeah, and it cost money that you don't want to spend. see the dentist. Host: Awesome. I think we're coming up on time here. Uh any parting thoughts on post-market surveillance or post-market management? Trevor: I think that we covered just about everything. Um, you know, of course, post-market and cyber security in general is a mile wide and a mile deep, but it's a good way to start wrapping your head around what can happen after the fact. Host: Awesome. Well, thanks for tuning in to the Med Device Cyber podcast. Uh we'll wrap up here and the next episode, we're going to cover interoperability issues with third-party components. So stay tuned.