What Is A Medical Cyber Device? | Ep. 42

In this episode of the Med Device Cyber Podcast, hosts Christian Espinosa and Trevor Slattery from Blue Goat Cyber tackle a common and critical question in the medical technology industry: What constitutes a 'cyber device'? They address the widespread confusion among manufacturers who often mistakenly believe their products are not cyber devices simply because they lack obvious network interfaces like Wi-Fi or Ethernet. The hosts aim to clarify this ambiguity by breaking down the definition based on the latest FDA guidance and practical cybersecurity principles. They introduce a straightforward, two-part test to determine if a medical device qualifies as a cyber device: first, does it contain software, and second, does it have any possible means of connecting to the internet or another device? If the answer to both questions is yes, then it is considered a cyber device and is subject to cybersecurity regulations. The core of the discussion revolves around the surprisingly broad definition of 'connectivity.' Espinosa and Slattery emphasize that this extends far beyond traditional networking. They provide numerous examples of interfaces that can make a device a cyber device, including USB ports (even if only used for data extraction), serial ports, Bluetooth/BLE, magnetic coils (like RFID and NFC), and even HDMI ports. The hosts explain how these seemingly innocuous connections can be exploited as entry points, creating vulnerabilities. They argue that the third common criterion—the presence of an existing vulnerability—is less relevant because any device with software and an interface has the potential for vulnerabilities to be discovered in the future. The conversation also explores the concept of a device's 'boundary,' noting that the FDA may consider third-party software, such as 3D modeling programs for creating implants, as part of the overall device system, thereby bringing it into the scope of cybersecurity requirements. They conclude by highlighting that manufacturers must be proactive in understanding all potential interfaces and either securely implement them or physically secure them to avoid the cyber device classification.

Christian: Hi, welcome back to the Med Device Cyber podcast. Today we're talking about what is a cyber device. A lot of confusion about cyber devices and a lot of our prospects and people we meet of events come up to us and ask us if their device, their medical device is a cyber device. And often they think it's not a cyber device when it really is a cyber device. So we're going to unpack the latest guidance and give some specific examples of what type of interfaces make it a cyber device. From my lens, it's very simple but it gets a little complicated when we come to the interfaces. If the easiest way to think about it is, does your device have software, number one? And number two, does it have any possible way to connect to the internet? That's number two. If it meets those two criteria, then it is a cyber device and a lot of ambiguity comes around that second criteria I listed there. So I'm your host Christian Espinosa and I'm joined here with Trevor Slattery coming from San Francisco. He just moved there, got the beads in the background, living a hippie lifestyle. And I'm here in Tempe living a contrast lifestyle. Trevor: Yeah, not not too many more different cities than Tempe and San Francisco. Here everything is super old and crumbly and it's cold all the time and foggy constantly. And there it's hot and new and spread out. Christian: And sunny. Yeah, it's. Cool. So we talked about, I went over the definition and I leave off the number three, which is is there any kind of vulnerability that could exploit your device. I think that's asking for too much because if a device has software and some interface, then there may or may not be a vulnerability today but there may be one tomorrow. So it's kind of an irrelevant point from my perspective. What do you think about that? Trevor: Yeah, and I think that it's partially also down to how hard is it to argue to the FDA that your device does inherently has no level of risk. It's a very hard argument to make and it's a very risky approach to take. And so typically we recommend saying if your device has software there's likely going to be a way to exploit it. I know that one team member that we have for part of his master's program had to prove a piece of software was vulnerability free. It was like three lines of code and something around 50 pages of proof to prove that three lines of code was free of any vulnerabilities whatsoever. Now imagine when you're moving into a medical device which can have thousands, tens of thousands, hundreds of thousands lines of code, the proof that it's going to be free of vulnerabilities would be so much more effort than complying to the cyber security guidelines. We recommend not worrying too much about that third definition. Christian: So let's focus on number two. I think that's where the confusion comes in, like when people say, well I've only got a USB port that we pull data off the device and then, you know, it's a DICOM image we pull off and we manually go put it in a PAC system or something. The fact that there's a USB port means it's a cyber device. But I, that's a misconception I hear all the time still. Trevor: Yeah and I think that the FDA is trying to do a little bit better around clarifying that and adding some definition around that. So USB port's the perfect example. You would not inherently think a USB port can introduce a network scenario into the device. And it's just a little bit of a misconception with A, what the interface can do and B, what the FDA defines as internet connectivity. It does not just have to be Ethernet, Wi-Fi, those things that you traditionally think of when you think of internet. And you could pick an example like right here, this is a USB to Ethernet adapter which we use during a lot of penetration tests to try to connect into a device and turn it into a network device. Even if you are just connecting a data stream into another device, that could consider, you could consider those two devices connected. And if that separate device is connected to the internet, then you do have indirect network connectivity into the medical device. This can also go down to the level of implementing like a Wi-Fi adapter into a USB port. I know we've had some pretty nasty attacks where we've been able to do kind of like a drive-by hot plug where we stick a Wi-Fi adapter into a device and then set up our own rogue Wi-Fi network so that we can then try to hack into the device from outside the building or outside the room instead of trying to do it physically where we might get caught. So there's a lot of risk that can get introduced through very small interfaces that aren't always immediately apparent. Christian: Yeah, and I think it's worth going over some of the typical interfaces that make your device a cyber device. Like obviously if you have Wi-Fi, that's one. Cellular, that's another. And we've seen devices with all these. Bluetooth low emission, we see that quite a bit. That makes it a cyber device. A USB port makes it a cyber device. A serial port, the FDA guidance clearly states that makes it a cyber device. Magnetic coils, that makes it a cyber device. So this would be like RFID or, uh, NFC. And I think there's other magnetic coil technology as well that I'm not quite familiar with all of them. And then even something like HDMI, which most people think is just used for display, can make your device a cyber device. Out of all the ones I listed, um, maybe pick a couple and give an example cause I know people are thinking, HDMI, like no way. That just shows my device's output on a display. Trevor: Yeah, I think HDMI is possibly one of the most surprising outcomes that we see as exposing risk into a system. So HDMI, exactly like you said, you're normally thinking about it, connecting into your TV or into a second monitor, just providing display output. But those cables and those connections can actually provide control over systems over the CEC, the consumer electronics communication, and so what you're doing then if you think of a situation where maybe when you hook up into your monitor with your laptop and you turn on your laptop, it also turns on your monitor. That's an example of the CEC protocol in place. Or, likely the most common application is in like game consoles. If you turn on a game console, it'll usually turn on your TV as well. So that's an easy example where you can see that, but this can be manipulated if it's supported in a medical device. You can try to manipulate power on, power off of the device. And if this is happening during a critical state, during a critical operation, that can be a dangerous situation. Another thing that we can talk about is the HEC or HDMI ethernet channel, which is a barely uncommon, uh, very uncommon protocol and not typically something you see too often due to the widespread availability of Wi-Fi. But you can actually pass Ethernet communications over HDMI cables. So then an HDMI connection fully opens up a device to networked operability and interoperability. So, even though some of these might be a little bit more edge cases, and you can say well the easy mitigation is just to disable those. You're right, that is an easy way to do it. Don't support these protocols, but you need someone to verify that these are not in place. If they are in place, you need to ensure that they've been done safely. So I think that's a great example with, um, talking about how a kind of a an interface you wouldn't usually expect to be a cyber enablement interface would actually apply there. Christian: Right. And from a cybersecurity testing perspective, we'd have to prove that HEC is not a feature enabled on the HDMI port. Trevor: Exactly. And it's similar to during a penetration test, if we're looking at a device and we ask the manufacturer, do you use Bluetooth on this? And they say no, we still have to check if Bluetooth is getting emitted from something in the device somewhere, where someone just wasn't familiar with the, like they have a Bluetooth network card, they just didn't know or they didn't know it wasn't disabled properly. It came on an off-the-shelf component. And we've found it multiple times in the past where we can identify a Wi-Fi emission coming out of a device or a Bluetooth emission coming out of a device. And then we can remote into the device. Obviously the, you know, solutions around it are a little more straightforward. Get rid of that network card instead of here's how to harden Bluetooth. But we're doing a lot of checks as penetration testers, not just for what is there but for what isn't there as well. Christian: Yeah, and we've also got with implantables, there's various protocols like Bluetooth low emission is one, there's MED Radio, but there's there's different things we have to check for that will make that device that most people don't know is internet connected, uh, actually the potentially internet connected. Like MED Radio is often used in a defibrillator or a pacemaker. So a physician can get diagnostics off of the device or do a firmware update. Uh, Bluetooth low emissions sometimes used. So we still have to test for all of that because that is a entry point into the system. And I think it's important to understand like we're looking at software, but if there's an entry point into the system through any of these interfaces, logical or physical, then that's what makes it the cyber device. Trevor: Yeah, exactly. And Bluetooth is another great example of something where you might not say, well this is internet connectivity through Bluetooth. And this is applicable to regular Bluetooth, BLE, Bluetooth low energy, all of these different types of Bluetooth connections. If you are interoperating with multiple devices, which is what these communications do, things like Bluetooth, things like Med Radio, there is a data stream, there is a connection going back and forth, you need to verify that connection is safe, it's going to the correct endpoint. You aren't just connecting to some rogue Bluetooth device. And even with these typically lower range signals, things such as BLE is kind of the perfect example. It's meant to be pretty low range, it's meant for things like a mouse where you can have a battery last for a very long time. That's the LE part. It doesn't use too much energy. But it's not always the case that it's a super low range protocol. So often times you can see some examples that have been done by security researchers in the past at events like Black Hat where they have Bluetooth sniper rifles, for an example, which sounds like a ridiculous concept, but they look like sniper rifles that I believe have a range of around a kilometer to send and receive Bluetooth signals with super, super targeted, precise antennas. So there can be some edge case scenarios and one example we always talk about is the fact that Dick Cheney had to, wanted his pacemaker removed due to the fact that he was afraid someone could use something like a Bluetooth sniper rifle to try to assassinate him and control his pacemaker. And it's been proven in the past with certain pacemakers that've been fielded that they have vulnerabilities that can be manipulated remotely to cause harm to patients. So it's not an unfounded concern and it's something that the FDA is trying to be proactive about. Christian: Yeah, I know it was an episode in Homeland that talked about a political assassination via shocking somebody by connecting wirelessly to their uh defibrillator. So uh this is a a a time where fiction and fact kind of joined each other because what happened in Homeland is actually reality with Dick Cheney as well. And and we notice that quite a bit with what we thought was sci-fi 10 years ago is now reality, it seems like like autonomous driving cars and we have flying taxis now, kind of like the Jetsons, which, uh I think they have flying cars in the Jetsons as well. So I think we've provided some clarity on what a cyber device is, anything with software and some kind of connectivity, which can include things like MedRadio or HDMI or Bluetooth low emission or NFC or RFID. Uh but there's some edge cases here that we've seen that our clients have come to us and prospects have come to us. One of them that comes to mind, and I you're probably more familiar with this case Trevor, is the client that basically had a 3D modeling software that printed implantables, I think for the knee. And when they did the submission to the FDA, they included that third party printing software. So the FDA is like, oh, you have a cyber device because in the scope of your product, you included the software. Trevor: Yeah, that was a definitely a very unique case that came up and you know, our client was obviously pretty blindsided by this. That's why they reached out to us is the FDA's determined we're a cyber device, we really need help with this process. So in this example the FDA determined that the software they were using to plan treatments for their patients was a pivotal component of the device, so it was included in the boundary of the device. And this is what manufacturers need to be extra aware of is where are they drawing the lines with those boundaries? You might say, well this functionality, like this piece of software is needed no matter what, full stop. This has to be in the product, has to be this exact piece of software, the device isn't going to work. Or you might say, yeah you can just use, you know, you need to take a picture of this for some way or another so that a clinician can perform some analysis. But you can use your cell phone camera, you can use just any camera lying around, doesn't matter. Then you might not include that specific component within the defined perimeter of your product. So first step is define what your product is. Where does it start, where does it stop, what can you try to mark out of scope? For those things that are pivotal to the device and super important, you can't get them marked out of scope. Are they going to apply to cybersecurity considerations? In this specific example, 100% of the source code that was used in the cyber component of the device was third party off-the-shelf libraries or tools. This is a very unique situation but when the FDA talks about their definition of a cyber device, they say a device that contains software that has been validated or, you know, is executing on a product, they don't say the device contains your software. So if you are daisy chaining a whole bunch of third party components together, it's your responsibility to prove that your use case of these components is meeting FDA scrutiny. And that's what we ended up doing uh with this specific client. The components that they were using were all FDA approved. They all had their own 510(k) clearances. However, we had to prove the specific configurations, the specific implementation that they were using did not introduce any risk into the system. Um it's obviously a very difficult, it's a complicated process to go through, but through that, through that mindset, through that process and then going through the documentation under that lens, we were able to essentially build out documentation on purely off-the-shelf components on what we have control over and how we're verifying that what we can control, we're controlling to the maximum degree of safety possible. Christian: Yeah, and I know we've talked about hardware interfaces. The assumption is that if you have software as a medical device that has an IP address or network connectivity or AI and software that outputs to something or cloud with APIs that those are all cyber devices because they they have obvious logical interfaces. Um but we wanted to focus on some of the common misconceptions with the hardware. And one other thing I wanted to talk about before we wrap up here, because this comes up a lot. We have manufacturers that have a product but they have an exposed USB port they really don't need. So the way to remove that from being classified as a cyber device is to enclose that USB port and put tamper-proof seals on the device. So now it's purely self-contained. It doesn't, there's no way to connect to the software, which is a simple fix uh if you relatively simple to avoid the whole cybersecurity path with the FDA. Trevor: Yeah and that's something that we've helped a couple of our clients with is how to make their device not a cyber device. They'll say, well we have all of these different things that we need the device to do and the unfortunate truth is you usually do have to make compromises on functionality. So sometimes there'll be a cloud update server or something to do, you know, over-the-air fielded updates and we say, well, you know, you're having a hard time trying to meet the cybersecurity compliance requirements for your device because of this update infrastructure. And so if you're able to, you know, remove this entirely, you're flashing it on at the board level. Um you're doing it, you know, as kind of a one and done process or you're changing the way that you're device works so that you don't require as much of these updates and you strip out any of that connectivity, you just try to isolate it from being a cyber device. Uh we've helped clients do that in the past and mark their devices as no longer cyber devices based off of shifting functionality. It just is a little bit of a tradeoff where you have to accept sometimes we're going to have to make some compromises here to get out of that cyber device classification. Christian: Exactly. And and that's where it's worth having a conversation with us. There there's sometimes a strategy to make your device not a cyber device or to validate it is a cyber device or to provide some mitigations around either one of those. And we're happy to have a free consultation for that. So about out of time here Trevor. So I always ask you for last minute words of wisdom. What are they today? Trevor: I'm going to say never assume you are or aren't anything with your device. The FDA has a lot of definitions on when you're going to meet different compliance requirements and just asking, asking experts, asking the FDA even, going through for an example like a Form 513G where you're reaching out to the FDA, you're trying to get information around your product classification, what code you fit under, things like that, helps guide some of these decisions that you might have to make. Reaching out to experts like our team at Blue Goat to say, hey, are we a cyber device? How can we not become a cyber device? How can we secure us being a cyber device? We can help you with all of these answers and make sure that we're guiding you along, we're guiding you on a secure path forward. So I guess to recap is never assume, always verify, always double check. Christian: I like it. And we're on a mission to help MedTech innovators get their products to market securely. So we're happy to jump on a call and help with some questions free of charge to see if we can, an hour of our time can save you many, many hours of your time and much frustration. So thanks for tuning in today on our episode about what constitutes a cyber device. We hope to see you on the next episode of the Med Device Cyber podcast. Until next time, adios.