Navigating the Regulatory Landscape of Medical Device Cybersecurity | Ep. 3

Welcome back. Today we're going to be looking at some of the categories of medical devices and medical device manufacturers, as well as some of the regulatory bodies that govern these devices and go through the submission approval process. Here today with Christian Espinosa, the founder and CEO of BluCyber. Awesome. How are you doing today, Trevor? Doing pretty well. How are you doing? You know, my head is, my these two fingers have been kind of numb. I went and shooting for like an hour and a half a day. I don't know if it's from shooting a handgun so long or what, but it's making typing very challenging for me. You ever had that problem from shooting? Yeah, yeah, no, I get that problem once in a while. I mean, normally I shoot kind of the racing guns, the 22 caliber, so I don't get too much. But whenever I go out for the bigger calibers or go out on big rifles, I kind of get that same issue. Okay, I thought, man, maybe something was happening to my hands here. Yeah, I'm looking forward to our episode today. We're going to talk about some important topics with the regulatory landscape. Regulatory affairs can be kind of boring, so hopefully we can cover this in a non-boring manner. One of the things with medical device manufacturers, I feel they fall into two main categories, at least the clients that deal with us. There's two main categories: there's the startups and then there's the large companies. It seems like we rarely get somebody in the middle, maybe a few, but it's mainly the startups and large companies. And a lot of the startups are VC or capital funded, and what happens is they kind of forget about cybersecurity until the very end. And whoever their Regulatory Affairs person is says, "Hey, we got to do the cybersecurity stuff," and the product has already been developed. So then they contact us and at this point we have to retroactively fix a bunch of things, or bolt on some security, which isn't the ideal way to do this. And this happens with large companies too. What do you think the ideal way to handle the security, Trevor? Should it be like they start reading the FDA guidance and all of a sudden they realize when they're about to submit their packet to the FDA that they forgot about it, or should they do it way earlier in the process? In a perfect world, as soon as they have the idea for the device, they should be accounting for security. Now, like you said, that's rarely actually the case, but in an ideal situation, you're able to account for security early and often. Pretty much any aspect of a device can be compromised in some way or another. Bad guys are unfortunately pretty crafty, so it can be easy for devices where security is an afterthought to get compromised in hundreds of different ways, which is why it's something that should be addressed at the very beginning. Now like you said, that doesn't always happen. So part of striking the balance is figuring out how can you address security once we're already down the right side of the development process. I can't count how many times we have a potential client come to us and say, "Hey, we need security considerations done for this medical device." We say, "Great, when are you planning to submit?" And they say, "Well, about three weeks from now." We go, "Whoa, that's a tight timeline." And you know, that takes in all the documentation, penetration testing, remediation, retesting. It is not typically a three-week process. We can turn our part around, the initial round of testing, typically in three weeks, but it's going to take them quite a while to fix all the stuff we identify. Right? Oh yeah, yeah, the initial round of testing. I mean, depending on how many hands you throw on the project, you can get through that pretty quickly. But I guess it's a matter of how much you find from testing typically to see how long the remediation cycle is. We have a lot of times where you don't find too much on testing. You give someone an almost clean bill of health. They make a couple tweaks and then they have a finished product the next day. Other times you absolutely eat them alive. You find dozens of critical, just tear apart a device and then, you know, suddenly. Doesn't sound very pleasant: eat them alive and tear apart the device. That's how you're describing the work. Yeah, it's, well, the bad guys aren't necessarily being pleasant about it either. They're taking a device and they're trying to do bad things to them. We're taking the white hat approach. We're looking for the device. We're trying to protect it, but when we're finding a lot of findings, it's not a good situation. And unfortunately, security is often seen as unnecessarily an unnecessary evil. Something that people have to do, just have to worry about for compliance. And that might not, that might be because they don't necessarily see the impact. But finding a lot of findings on a pen test is going to result in a pretty big turnaround time for remediation, so it's why we want to see it earlier, ideally. Yeah, and this can cause significant impact to, you know, the two categories I mentioned: if you're VC funded or a startup and you only got so much capital and you forgot to get funding for the cybersecurity component and the rework involved with it, you know that could cause some challenges. And the same thing if you're a large company and you've told all your shareholders that you're going to release this product on September 4th, and then you come to us on August 19th and say, "We need the cybersecurity done," it's probably going to be delayed. So that could really impact your public image and a lot of other things. So in general, the best cybersecurity principle is to have the requirements and design cybersecurity into the product rather than bolt it on later. So I agree with Trevor, the sooner you can get involved with cybersecurity, like as soon as you have the idea, start thinking about it, the better. And with regulations, there's a few main regulatory bodies. There's quite a few actually. There's like, if you look at the globe, there's one for pretty much every region of the world. But the main ones we deal with are the FDA, the Food and Drug Administration. A lot of people don't even know that the FDA has guidance and regulatory authority over medical devices. Most people just think it's pharmaceuticals or our food supply. The FDA of the United States, and then we have the EU MDR, the European Union Medical Device Regulation, which handles most of Europe. Those are probably the two biggest regulatory authorities in the medical device or MedTech space. And today I think we'll focus a little bit more on the FDA since that's primarily what we deal with. So the FDA has quite a bit of regulations. They came out with new guidance in September. It's relatively new, it's almost a year old now, but new guidance in September 2023 that really changed the landscape with medical device manufacturers and cybersecurity. As a result of those changes, a lot of submissions – a submission is when a device manufacturer tries to get their device approved so they can market it and sell it on the market – a lot of those submissions got rejected with deficiencies because the manufacturer did not understand all the cybersecurity requirements that the FDA now has. So before we dive into some of those requirements, let's talk a little bit about the types of pre-market submissions. So in medical device cybersecurity, and in medical devices in general, there's two categories: there's pre-market and post-market. Pre-market means your device is not on the market yet and you need it to be approved by the regulatory body, which in this case we're talking to the FDA. So you have to submit this whole package. It's often through this online system called eSTAR. And in that package has all the cybersecurity documentation, all the penetration testing reports, and you have to prove to the FDA that your device has acceptable risk in terms of patient harm or patient safety. And then there's post-market. So post-market means once your device is approved, it has to, you have to, it's not, it's not like one and done, you prove it, you can forget about cybersecurity. You have to then monitor that device and show you have a plan to make sure once your device is sold in the market that you monitor the device and you can respond to incidents, you can remotely update it if necessary, or have a plan to update a device in case there's a new vulnerability discovered. So those are the two main aspects that the FDA requires and the EU MDR require. And then maybe Trevor, you could explain a few of the different pre-market, I think we should actually talk about the classifications first before we go into like different types of pre-market submissions. What do you think? Yeah, I think I agree. So as far as the FDA goes, there are three classifications of device: it's Class 1, 2, and 3. We see Class 1 as a low-risk device, and that is just subject to general concerns. An example of a Class 1 device would just be a bandage or maybe a scalpel. These are things where we don't have to be applying the same considerations to maybe another device class. There's no, there's no cybersecurity risk with a scalpel, right? It's an instrument. Yeah, that's correct. Oftentimes cybersecurity risk sort of will introduce a higher level of risk. I think a good example of a cyber device would be like an oxygen pump for supplemental oxygen, not for emergency use, not for any sort of life-sustaining activities. But like a supplemental therapeutic oxygen applicator, that would be considered a Class 1 device where there's not necessarily any huge risk to the device and compromise isn't going to be harmful to the patient. Class 2 is a little bit higher level of risk. An example of that could be a wheelchair, for example, if a wheelchair has a computer component and that can be compromised. So let's say you're able to, a powered wheelchair, not a manual wheelchair, right? Yeah, just any wheelchair with a computer component or just an equivalent device. If you can compromise that wheelchair, someone hacks into it and they're able to crank the speed up or, you know, cause it to randomly just break in the middle of moving. That, how how fast could they crank the speed up in a wheelchair do you think? Honestly, that's a pretty good question. I mean, I'm thinking for reference like one of those electric go-karts. Those things can go about 60 miles an hour so I bet if you really got into, really were able to modify the firmware of a wheelchair, you could make it go pretty fast, huh? Yeah, I'm sitting here looking at the lake and there's a trail here and I see people go by on wheelchairs every now and then. I imagine, I guess if you could speed that thing up and you could run someone off into the lake, you know, they might drown. Yeah, yeah, seeing. Talking about it, you know, yeah, well, now you got me thinking, how fast can you race a wheelchair? I don't know. Well, you know, regardless, there's still definitely a level of threat there. A Class 3 device is the ultimate level of harm. That's like a surgical robot where a compromise of the device is effectively can lead to patient death. That's the most stringent controls, the most stringent considerations, and there's a lot of concern around there. Anytime there can be a massive breach of patient data. So let's say medical records, widespread medical records get leaked or patient death, severe injury, like with a medical robot, someone can get, someone can get killed pretty easily or someone can become disabled from a result of mistreatment with a surgical device. So there can be a lot of real risk with a Class 3 device. Yeah, and that's like an implantable defibrillator device is a Class 3 as well, high risk, like you said, right? That device is compromised, you could kill somebody. I remember we were, we were dealing with a client recently and it's kind of interesting. We look at the, we always look at risk matrices and they had, they wanted the highest risk in there to be severe. And I was like, well, and somebody could die as a result of hacking in this device and they wanted catastrophic taken off there and severe putting in there. And I'm like, it's pretty catastrophic if somebody dies, isn't it? They're like, "No, we think that's severe." I just thought that whole conversation is so bizarre, you know? I'm like, if I die, it's kind of catastrophic, maybe not for me because I won't know, I won't be around anymore, but maybe for my family they'll be like, "Man, that was, that was so, that was severe. It wasn't that big a deal," you know? Yeah, I'm picturing, you know, someone gets like misdiagnosed or dies as a result. Someone says, "Was that a catastrophe? No, no, that wasn't a catastrophe. It was a big deal but it wasn't a catastrophe." Yeah, so Class 3, I think we're dealing with, you know, catastrophic results if the worst case scenario happens. Yeah, yeah, and I think severe would more fall under that Class 2 category. That's, you know, it can cause you harm, cause you significant harm, but that's nothing that you won't recover from. That's not permanent harm or leading to permanent disability, that could cause, you know, temporary harm, temporary discomfort, things of that nature. Yeah, I think in some situations with Class 2, some extreme situations like that powered wheelchair you mentioned, you know, if you could hack in a way where you could drive it super fast into a lake or into a busy street, you know, that might be a far right use case or something, but you know, that's, that's pretty risky as well. Maybe not, maybe not the same as shocking someone's heart to death, you know, with a, like the Dick Cheney scenario. So what are the some of the pre-market submission types? We talked about the classes, and I think these tie into the type of submission. And to me it's very confusing, there's like this thing called 510K, PMA, De Novo. It's all these like crazy terms and I, it used to be when I first got into medical devices, I, I, I would get a 510K confused with a 401K, you know, it's very similar. I'm like, you know, 401K is the investment instrument, right? A 510K is something different. So what, can you explain maybe like what a 510K is, PMA, and De Novo? Well, the first thing is the naming convention is pretty poorly thought out. I cannot understand why they would have such a wide range. They have an acronym for one and then they're like doing Latin for another and then they're doing numbers for one. It doesn't make any sense. But with a 510K, that's going to be a device that has a substantial equivalent. So essentially that's nothing new to the market. That would be a device that is already out there. We can go back to the wheelchair example. Electronic wheelchairs have been around for a while, and so if a manufacturer is going to create a new electronic wheelchair, there are equivalent devices already out in the field. So that would be anything that is falling under the 510K category. Now PMA and De Novo are a little bit different. These are going to be novel devices where there isn't an equivalent already out there. What does PMA stand for? Isn't that pre-market approval? That is pre-market approval, yeah. Which is confusing in itself, because they're all, they're all technically pre-market submission types, yeah. Which just adds to kind of the additional layer. But with a pre-market approval, that is going to be something that is a very high-risk device. That's going to be the Class 3 devices that will fall under the PMA category. And the De Novo is going to be the Class 1 and 2. So these are new technologies that the maximum impact is not going to be extremely severe. De Novo in Latin, doesn't that mean like from the beginning? So that means these are new novel devices that there's nothing on the market, no substantial equivalent device out there. Is that right? Yep, that's correct. Okay, cool. And out of the like the FDA versus the, you know, EU MDR and some of the other regulatory bodies out there, which one do you think is the most stringent? I kind of think FDA, would you agree with that? I think the FDA as far as the entire cybersecurity package altogether, especially after the latest guidance as of September of 2023, the requirements as far as documentation and security considerations are very extensive for the FDA. Surprisingly, I think for the actual testing side of things, the Korean PMDA has the strictest requirements. Their testing documentation requirements are very, very comprehensive, far more so than even. It's not the actual testing for them, it's the actual, it's the documentation they want submitted, right? Then the way they want it submitted, what they want to see in a penetration test report is, covers a lot more ground than typically we see in other regulatory bodies. The FDA has strict requirements on what needs to be done for testing. They like to see that we're following the TR57 medical device testing framework which covers very comprehensively how it needs to be done as far as test plans, test cases, test reports. But the Korean PMDA, they really get into the weeds on the details, the content, the formatting of test reports. They leave no stone unturned there, while the FDA is a little bit more forgiving in that area. But with the documentation side of things, I would 100% agree that the FDA sort of puts you under the microscope a little bit more than anyone else. So the Korean, the Korean governing body is a little more regimented, you would say, than the FDA. And that's, I think that's one of the things that a lot of medical device manufacturers find confusing. The FDA provides guidance, but they don't say it's mandatory. They say you could include this if you want, but it's, it's optional. But then they make these arbitrary decisions like, "Well, you really should have included this," even though they didn't tell you explicitly what to include and how to include it. So it's not as prescriptive, I would say, as maybe the Korean one is that, is that a true assumption there? Yep, that's definitely something with the FDA that a lot of people express frustration with. The guidance is exactly like you said, it's not very prescriptive. They're not saying you go into this document, you put these headers and you fill it out with this. There's even a table at the bottom of the latest FDA guidance document and it lists each of the sections in the table of contents and it says whether or not it's a requirement or not. Only three or four of the selections are actual requirements. We frequently see kickbacks where people include those three or four and then five more and the FDA comes back and says, "Well, you missed 10 of these," and the guidance didn't say it's a requirement and so people don't always think about it. But yeah, that's definitely an issue with the way they phrase things. They don't want to be prescriptive with the guidance, even though a "we recommend" is essentially "do this or fail." Yeah. I know you spent some time in Korea. Quite a bit of time in Korea. Would you say in general in Korean culture it's more prescriptive than in the United States, I would say so? I spent a lot of time kind of traveling all over Korea. Sort of my hub was in Seoul, which had a very regimented, structured, kind of it's a very serious place. Of course there are parts of it that are very, very far from that, very fun, very relaxed, very loose. But Seoul in general is a pretty regimented place and you can see it in just public attitude, you can see it in the way that business operates. And then you can see it in the way that the PMDA requires their documentation to be submitted. It's all, it's all tied together. Interesting. So you're saying that the September guidance, and I agree, that really changed the game, this fall September 2023 guidance. It upped the ante on cybersecurity for manufacturers. What are, I don't think a lot of people understand, we talked about these classes of devices, and we worked on a device. I know you worked on personally, Trevor, it was a Class 2 device, I believe, and there was a laser that did like acne treatment. Is that, is that correct? That was a Class 2, right? Yes, that was a Class 2 device. Can you explain, because I think a lot of people still don't understand like the importance of medical device cybersecurity, like especially like a device like you go to a med spa and you're getting a laser thing done on your face to remove your acne. Like what are some of the concerns if you hack on that device? And can you maybe talk a little bit about the device we worked on? So this is a really interesting device. It is, like you said, it's an acne treatment laser. It's meant to sort of zap away any acne that you have on your face. And that has a little cooling attachment so that you aren't getting scarred and burned, which is a pretty big problem with most current acne treatments is they burn and then they leave scars and you can't go out in the sun for like a month after getting the treatment and it's a pretty involved. Wait, so this, this thing, it burns you, but cools you at the same time, so you're actually not getting burned, is what you're saying? Yeah. And so they use a very high intensity laser to essentially burn off the acne and then they try to cool it so that you're not getting scarring or any problems and you don't have any skin inflammation. It's a really cool system. Now, this device was intended to be entirely air-gapped, so they wanted it in an enclosed network, not connected to the internet, no way to get in or out. And we walk into, you know, the manufacturing environment into the lab, they show us the device and I take a wireless adapter and I stick the wireless adapter. It's no longer air-gapped. And so I'm able to get into it remotely. I'm able to get into it from my laptop, which is, you know, in another room. It could be in the same building, just tucked away in a corner. And I'm able to control it pretty remotely with just a chain of vulnerabilities, I was able to get pretty widespread access to just about anything on the device. Maybe back up there. I hear that term, chain vulnerability chaining. What does that mean? So that's when we're taking a couple of seemingly unrelated problems and sort of mapping them together to prove a greater impact. So in this case, there were a few different issues. The first one was that I could just plug anything I wanted into the computer. It was running a Windows computer and I could do whatever I wanted. So I could plug a mouse into there, control it with a mouse. I could plug in a keyboard or I could plug in a wireless adapter and connect it to the internet. The second problem is it was running this software in sort of a sandbox kiosk, so you can't really access the computer underneath, but you could force that software to crash by putting in some bad input and then it would just bring you to the desktop of the computer. The third problem with that is it was running that software as the administrator, which is the highest level of privilege, gives you access to anything on the machine. So by chaining all of that together, I was able to effectively remotely access the machine as an administrator and escalate my privileges to the system level, which acts as the computer itself. So I was able to become any computer, control anything I wanted. I could modify, change, update, delete, including the short-term memory of the computer where it was storing configurations about the temperature for the laser, the cooling settings. And I would be able to go in and change that memory to make the laser burn at a much higher temperature and completely shut off the cooling. So I could just effectively burn someone and that's it. There's no, you know, there's no cooling to try to make it better. And that laser gets hot. Surgical lasers and acne lasers get really hot. You have to wear protective equipment around it for testing. You have to do it in a special controlled laser lab. Yeah, so breaching that is a pretty big deal. Wow. And those things are, I think, pretty common like med spas and other places, aren't they? Yeah. I mean, I'm a pretty small town up here, about 40,000 people, and I can think of eight places with them around here. Oh, really? Okay. Yeah, there's one across the street. I go there and get IV therapy sometimes. I like to try to reverse my aging. So I'm like Benjamin Button, I go, I'm going backwards, but I don't know if it's working or not. But I, I get the IV therapy sometimes, NAD supplement, which really is really painful, but supposedly makes you younger and repairs everything. I don't know if you ever seen that, have you seen that one guy Brian Johnson who's like on a mission to reverse aging, yeah, yeah, yeah. I watch all of his sleep stuff and I try to stick with that. And so now I'm going to bed at, you know, 9:00 p.m. every night, waking up at 5:00 a.m. every day and just won't break through that. And so that's my way to try to stay young. Well, awesome. And that the company with that laser, I think, I think the driving, the driver for them to test this stuff was some of the new FDA guidance, isn't that correct? That's correct. So they were making some changes to their device and they were going to be doing a new submission as a result of these changes. The FDA requires that even if you have a previously accepted device and you're making a significant change in the functionality, so that can be a good example of that is if you're adding a new connectivity, if you are taking a previously sandbox air-gapped device and adding a network component, that would warrant a material change. That was the case with this device. They were adding some new functionality and they wanted to do a new submission. So this was pulled in because of the FDA requirements and they needed to find a good solution that adheres to TR57 testing requirements, which are not industry standard for penetration testing. It's for medical device testing. So a lot of cybersecurity companies aren't as intimately familiar with the practices there and they wanted to find a good solution and go through with the testing so they could get their device approved. Yeah, that's a good point, we've actually got a lot of or had a lot of companies come to us that had hired a normal, you know, quote normal penetration testing firm to do their medical device penetration test and it resulted in deficiency because the testing requirements are very different than traditional pen testing. I think that's what you said as well, right? Yep, exactly. It builds on a lot more of sort of the initial phases. So with typical, like one of the most popular types of pen tests that you'll see is a PCI compliance test. And so that's if you're taking in a payment system, you need to be make sure that your system can't be hacked into. The requirements around that, you're going to get a penetration test report, you'll remediate the findings, and you get a letter of attestation stating that this has been remediated. For a medical device, following TR57, you need to have a full plan in place. You need to have a threat modeling exercise, which threat modeling is sort of the theoretical what could happen to the device. From that, you're going to build out a test plan to try to exploit those threats. You need to build out test cases for each identified threat. Each test case needs to tie into the test plan, tie into identified interfaces. You need to provide a report that references any test cases used and adheres to the plan that you map out ahead of time. So it's a pretty involved process and that's just the initial planning before you get into testing, before you get into remediation, before you get into validation. It goes quite a ways down and it's not something that is standard, you know. It, it doesn't apply to every industry, it doesn't apply to every system, so not many people learn about kind of the intricacies there. Yeah, plus you've, plus you've got all the physical interfaces, which I think as you said earlier, not a lot of, may have been a different episode, not a lot of pen testers know how to hack into physical interfaces. Yeah, it's not very common to hack physical devices and I think that was last episode we were talking about that. I'd just gotten back from Black Hat and there I could count on one hand how many times we had seen a talk about a physical interface or seen a tool that related to it. Typically everything is in the network, in the cloud, AI security, API security and you don't see very much about hardware hacking or communications like Bluetooth, Wi-Fi. It's not very common. People inherently assume that they're secure, even though that's far from the case. Right. And there can be some pretty disastrous effects from just putting a random hardware interface and not properly securing it. Yeah, I agree. I think one of the, this episode was kind of focused on the regulatory landscape. I think one of the key takeaways is that the company with a laser would probably not have even had it tested by us if it wasn't for the new FDA guidance. So there is, I'm someone that has mixed feelings about regulations and having to follow the rules. But in this case, these regulations are actually helping make devices that could have been out there in the market that unsecure, make them secure. Would you agree with that? Definitely. And that's entirely where the original guidance came from. Is there's been a massive increasing trend every year in cybersecurity and cybersecurity related incidents and more and more medical devices are getting targeted. The medical sector is responsible for a pretty large percentage of data breaches and cybersecurity attacks. So the FDA stepped in, they updated their guidance and they are trying to push this increased effort to make sure that the medical device landscape is a little bit of a safer place. It sounds like these regulations, which often don't result in progress, these are actually resulting in progress for medical devices, which, you know, one of my passions is helping our advances in healthcare stay as advances. And if devices are compromised, these advances may be rolled back. So it's important we secure these devices and I'm happy to see these regulations are actually helping secure the devices versus be a hindrance. Yeah, 100%. So hopefully, you took away some nuggets from this episode. In the next podcast episode, we're going to talk about how we can build some of these secure medical devices and some of the technologies that are required to make sure these devices are designed and built securely, rather than, you know, the stuff bolted on later on. We, because ideally, we want to design security into the device. So I hope to see you there.