Navigating the Regulatory Landscape of Medical Device Cybersecurity | Ep. 3 - Full Transcript | The Med Device Cyber Podcast

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.