The Silent Killer — How Poor Cybersecurity Can Halt Market Entry | LSI USA '25

Christian Espinosa  0:00  
All right. Well, good afternoon everyone. Hopefully you're enjoying the conference so far. So I'm here to talk about cybersecurity. I call it the silent killer, because most people don't consider cybersecurity until it's too late, from a FDA submission perspective or MDR perspective, and when they consider it too late, it ends up costing like three to five times more than if they would integrate cybersecurity at the beginning. So just a little scenario here, and I'm gonna keep this workshop format so informal. If you have a question, feel free to ask anytime they just ask you come into the mic so it's recorded. The whole idea is, imagine you spent a lot of money on your innovate, innovation, and you're trying to bring it to market, and all of a sudden it's delayed by the FDA. And this happens all the time. We see this all the time my organization and is extremely frustrating for people. It's frustrating for the innovators. It's frustrating for the investors, and it's just frustrating for everyone on the team in general. It's even frustrating for us, because unfortunately, we're the ones that are the bearers of bad news to some regard, because if a client comes to us 60 days before the submission, and we find 1000 things wrong from a cybersecurity perspective, they're not going to make the 60 day timeline. It's going to take a long time to fix those 1000 things. So why this matters? Like I said, cybersecurity is becoming one of the biggest delays trying to get a device onto the market today. As most of you know, about a year and a half ago, the guidance changed dramatically in cybersecurity requirements greatly increased. So a lot of clients that got things through a lot of manufacturers maybe a year and a half ago, the same process is not going to work today. So one of the challenges we have in the industry is really, I don't think people, people don't know what they don't know. Basically, from a cybersecurity perspective, and cybersecurity is often considered, as my CTO says, a necessary evil. Nobody wants to pay for it. But I'm going to show you today how it can be a competitive advantage as well. So we'll talk about that. These are some objectives here and how to integrate it. In the beginning, I have a couple case studies. These are real case studies. We're real clients of ours. Some of them that did it right, some of them did it wrong. And like I said, if you have questions as we go through, feel free to ask so the whole idea is the FDA or MDR. It doesn't really matter which regulatory authority, they've all greatly increased the cybersecurity requirements. They have greatly increased those requirements, and it's really catching people off guard. So this can delay your time to market dramatically. The regulatory authorities are also requiring what's called Secure product development. Some people here call it spdf, a secure Product Development Framework. That means they want to see that you have designed cybersecurity into your device at the very beginning of the life cycle, rather than bolted it on at the end. It's been proven time and time again, trying to bolt on cybersecurity versus designing it into the product is very ineffective, and everyone is looking for you to have that secure Product Development Framework now. So it's important to invest in cybersecurity early. It costs way less if you invest early, then wait to the end and have to redo everything. And as we know, a single vulnerability can cause your device to be compromised. And it's not just the regulatory compliance portion getting it to market. Also, from our experience, healthcare delivery, organizations like hospitals are being more and more restrictive on what devices can be put on their environment, so they want to see proof that your medical device is secure before they place it into their environment. Because, as you know, pretty much every hospital has had a major data breach, and just when you think there can't possibly be a bigger one in the news the next day there's a bigger one announced. So it's a big problem, and hospitals are finally trying to solve that problem. And unfortunately, the odds are against us. I've been in cybersecurity for 30 plus years, and we have to get everything right. From a defense perspective, the cyber criminals only have to get one thing right. So if there's one door into your product or one door into environment, if that door is unsecure, that's all they need, where we might have 1000 doors to secure. So it's a very challenging scenario. You. Yes, so the top five reasons, and in my organization, we see deficiencies all the time, not from when we help somebody, but often a prospect will come to us. The prospect chose a different vendor for cybersecurity that doesn't understand Medtech cybersecurity, and they come to us all these deficiencies and help and ask us to help them address these deficiencies, and the top five is a threat model. Most of the time, there's not a comprehensive threat model. I'm not gonna go in the weeds at all these topics, but a threat model, basically, is all the ways an attacker can get into your system. We call the entry points. An entry point could be a Bluetooth connection, it could be NFC, it could be a USB port, it could be an HDMI port, it could be a serial port, any interface on the device, logical or physical, is an entry point. And from a threat model perspective, we have to look at the threats and how they can take advantage of the entry point if they get through it, what then can they do? So if you have a USB port that's used to transfer images from your product to a pack system, as example, that's the normal use case scenario. But the cyber criminal or the attackers are going to figure out a way to abuse that. They'll plug something different in the USB port to try to change the algorithm on your product, for instance. So we have to look at these abuse cases. The second thing is the software bill of materials. The s bomb, the software Bill materials is simply the ingredients that make up your software. Software developers don't always reinvent the will. They borrow third party software. They borrow code from other places and put it into their software, into your software of the product. So from a transparency perspective, it's important that whoever is purchasing your product knows all the components that make up your product, and these are all the third party libraries. It's like if you go buy a brand new car, you have a right to know who made the brakes for that car, who made the steering wheel, who makes the transmission. It's the same kind of concept. And this also allows us to track vulnerabilities, because there's been a lot of major flaws and vulnerabilities and medical devices because a third party component was breached, like one of them is a bash shell that nobody knew was in their product. So to solve that problem, that's why we have a software build material so now the manufacturer and the user of the product know what third party libraries are in that product and know what the true risk is. The third part is a patient safety focused risk methodology. So with medical devices, the thing that is the biggest driver is patient safety. So if I'm able to compromise the device, what harm can I do to the patient? That is the primary lens we look at through. It's not data disclosure that's important as well. But what's more important is the impact to the patient. If I can compromise an in vitro diagnostic system and cause it to have a delay in its diagnosis and somebody has sepsis, we know that they could possibly die. If I can compromise a surgical robot that's been performing surgery on somebody's spine cause it to maybe paralyze that person, that's a big problem. So that's the lens we have to look at through with medical devices, and a lot of people try to use a traditional risk methodology which has likelihood and impact. That is not what regulatory authorities are looking for. They're looking for exploitability and impact based on impact to the patient. Exploitability is more of a objective measurement versus subjective. I mentioned also that most people don't consider cyber street early in the product development. This is another reason the FDA and EU, MDR and other organizations kick back the submissions you have to prove that you're doing secure software development. And from my experience, in our experience at Blue goat cyber, most, I would say 95% of software developers know nothing about cyber security. They'll tell you they do, but they really don't. And that's that's just they're different skill sets. Software developers are very good at building functional software. Cybersecurity professionals and ethical hackers are very good at breaking that functional software. So very different skill sets and different lenses we look at through for the same set of software. So.

Christian Espinosa  10:00  
The other part is third party penetration testing. This is a mandatory thing that needs to be done. A lot of people try to do internal penetration testing, like the same team that developed the software, test the software. Obviously, that's not a good way of doing things, so you need to have an independent third party do the testing. And as I mentioned, we see a lot of the rejections from the FDA. So I've got a few of them here, and we have a whole database to these deficiencies. And I've gone through this database, and this is where I'm pulling those top five from the common things we see. And these are, these are real deficiencies we've seen. I highlighted the ones that are the most common. The top one there is a threat modeling. This is an exact response from the FDA. Next one is software, Bill materials. Next one down there is the penetration testing. And we have a database of hundreds and hundreds of these from prospects that try to do the work on their own the cybersecurity work, or they hire what I call a traditional cybersecurity firm that knows nothing about med tech cybersecurity. And we just had a submission with the FDA today from one of our clients, and their response was, a lot of people have been laid off. It looks good enough. So it's clear, is what they said ironically. And I've also heard there's, there's a Legionnaire's Disease breakout at the FDA. So everything is backed up even more because we tweak to interact with quite a bit, a little bit about my organization, Blue Gold cyber. So we've been doing this since 2014 I sold a cybersecurity company called Alpine security in 2020 to a publicly traded company with Alpine security, we did Medtech cybersecurity, but it wasn't our primary focus as part of our business while I was working for the parent company that I sold my company to, I developed six blood clots in my left leg and almost didn't make it. So thanks to a friend of mine that told me I should go to hospital, and I don't like ever going to hospital, but she convinced me to go, and thanks to a portable Doppler ultrasound that was able to find the blood clots. So I'm still here today, and after some depression and recovery, because before that, I did Iron Man Triathlon. I've done 24 of them. I've climbed mountains. I did I was very active, and I thought, you know, blood clots don't happen to people like me, but it did happen, and I had to stop doing everything I used to do. I was told I couldn't run, I couldn't hike, I couldn't get an airplane, basically. Could do nothing but sit on the couch and, you know, watch reruns of Yellowstone and get depressed. Maybe Yellowstone wasn't the right thing to watch to avoid depression. It's kind of a depressing show. But anyway, when I got out of that, I thought, maybe this is got that depression and recovered. I thought maybe this is the universe telling me to focus on Medtech cybersecurity, because I think a lot about what would have happened if that device was recalled, or if it gave a misdiagnosis. And we've worked with ultrasound devices, and they're very vulnerable. So fortunately, that one was still on the market, so I spun off just the med tech portion from the parent company, and that's what we focus on now, Medtech, cybersecurity. So we've done over 150 submissions, and we tested just about every type of device has software in it as well. And that's my actual diagnosis up there. The six split class wasn't just one of six like, I don't know how often it happens, what is pretty disturbing to me.

Christian Espinosa  13:47  
So as I mentioned, we've helped hundreds of clients. We've done 150 submissions, probably a little over 150 now, we've done pretty much every type of product that has software as a component with it, and the one of the biggest things now is AI. AI has changed a lot of things, especially the new guidance for the FDA, and I'm not sure if anyone's aware of that, but now we have to do a bunch more extensive testing. If you have AI in your product, things around AI, data poisoning, model evasion, things of that nature. We do have 100% success rate anyone that's used our services for pre market. The cybersecurity portion has got approved, and we guarantee our work. So if somebody, if the FDA, comes back with additional information request or deficiency, if they haven't come back to the deficiency, we will address that at no additional cost. So there's really three steps. These are very broad steps to avoid market failure from a cybersecurity perspective, the first one is to start early, early and often is what you should be considering with cybersecurity. And some people say, like, how early? And I'm gonna go over a couple case studies, how early is when you're in the requirements phase. So before you're done. Doing the design, because when you look at requirements, typically, cybersecurity requirements are what's called non functional requirements. They're not required for the device to operate properly, so they're often ignored. However, if they're not designed in this is where these challenges come later on. So and it should be built in alignment with whichever organization or authority you're trying to get cleared with the FDA, from our experience and China are the two most stringent. So if you want to go to EU, MDR later, if you do what's required by the FDA, you've already done all the cybersecurity work, you can just leverage the same body of work. And the other thing is, we talked about pre market so far. So once the device is finally cleared, you have to monitor it on the post market perspective. So we have to monitor the device, and you have to show this plan in the pre market submission. The plan needs to say very clearly, like, what are you going to do once the device is cleared? How do I monitor for new vulnerabilities? How do I monitor that software Bill materials, in case there's a new vulnerability in third party library? How do I allow somebody that finds a vulnerability to disclose it to me? That's called a common vulnerability disclosure database or portal, and then how do I triage these vulnerabilities? And one of the most important parts is, if my device requires an update because we had to fix something, how do I securely deploy that update? It could be over the air, which introduces its own vulnerabilities. It could be I have to have a field technician show up with a thumb drive, which we have to make sure that process is secure, if that's the way you're doing it. So one of the companies we work with, this was a first case study where they they they didn't quite do it right. So one of our clients came to us about 70 days before their submission deadline. They had a bronchial decongestion system, and they had a cellular connection on that bronchial decongestion system that connected to a cloud. So when we started looking at their system, they made a design decision like two years earlier, were they to choose a microcontroller that did not support secure boot. Secure Boot makes sure when the device boots up, the firmware and software that runs the device has not been tampered with. The FDA requires secure boot. So now, since they did not enable secure boot and their microcontroller didn't have that functionality. The only way to get their device approved was to make it stand alone, because that reduced the risk to an acceptable level to the patient. And this is this caused a lot of challenges because they they had told all their shareholders, just a publicly traded company like, all the features were going to be, what the release timeline was going to be. And they had to come up the new narrative to roll this back, which obviously this is, this is not good for public relations or anything else. And they they had that. They changed the narrative. Say, we're going to release a more secure version, and then now we're working with them to on the design perspective design, their new iteration to so it can be more secure. So this is a something that we see quite a bit. The first one that one of the first slides I mentioned about, imagine you spent all this toward the $20 million that was actually one of our actually one of our clients. I changed the name, but that client came to us 60 days before the submission, very complicated IVD system. We found 4000 vulnerabilities, and it's been 10 months, and they have still not fixed those vulnerabilities. So at this point, they're out of money, and they're sort of their plan right now is just to submit to the FDA and hope they overlook the vulnerabilities, which I know they're not going to maybe, maybe the timing is right, since they're understaffed, I don't know that might be a strategy, but I'm not comfortable having a device out there that's that's hackable. My biggest fear is if my company tests with these devices and then we miss something and somebody hacks it later on and harms a patient. You know, that's, that's, that's the thing that keeps you up at night. So we make sure we're very thorough and diligent, as I mentioned. The key, the key theme of all this is consider cybersecurity early on. And I know most people don't know what they don't know, so part of my mission is to raise that awareness in the industry. Because as an entrepreneur myself, I don't like seeing fellow entrepreneurs their product launch is delayed. I don't. Like seeing that frustration. I want to help my entrepreneurs, fellow entrepreneurs, as much as I can. We need to choose the right hardware. A lot of people don't consider the hardware. They just consider the software. Like I mentioned with that microcontroller, that was a hardware decision that greatly affected the cybersecurity and it greatly affected that product's viability on the market because they had to reduce a bunch of remove a bunch of features and from a market, a competitive market space now, now they have a product on the market with less features than a competitor, because competitor may have considered cybersecurity earlier.

Christian Espinosa  20:41  
Here's another example case study. This is the company that did it right, or did it better. So this company, and there's a few of them here, actually, there are clients partner with us early on. So before they actually started the design, when they're considering the requirements, they had some consoles with us. So these are just like several hour like zoom sessions, and they're saying, Here's what we want the software to do, what cybersecurity controls we needed, here's what our product is going to do. So we simply guided them through those requirements. So those non functional requirements I was talking about, they were to add those so when the product was starting to be developed, the software development team now had additional requirements for cybersecurity, so it's integrated into the overall product, which is the requirement from the FDA and everybody else. So it's it's really like a mindset shift in Medtech, because before, nobody cared about cybersecurity, now it's something we have to care about greatly.

Christian Espinosa  21:53  
So as I mentioned, they have to have to implement a secure software development life cycle. That means we're developing software securely, and it's also required on that post market management plan that you prove that you can do updates securely as well. So if there's a vulnerability discovered, how do you securely update the software? And that goes back to this secure method of developing software Threat Modeling should be performed as early on as possible. Like I said, there's all the entry points into the system, and there's ways around this. Like if you choose a motherboard with a USB port and a serial port, but you don't need access to serial port, you can, from a hardware perspective, create an enclosure that covers the ports that don't need to be exposed, so that reduces the risk. Otherwise, we have to test those ports, and if there's a vulnerability, it's going to cost more money to fix it. Penetration testing should be iterative. Also, I think one of the biggest challenges is most people consider cybersecurity like a two month window opportunity, or something you have to do in the two months, sort of like a biocompatibility study on my roadmap, I'm gonna put cybersecurity here for two months. But cybersecurity is very iterative. Needs to be done early and often. Like I said, maybe once a quarter. We check how the software developers are doing with their code. That way we can reduce the vulnerabilities sooner that like you get to an acceptable level, then wait for this 4000 at the end. This company, they got approved the first time, which is pretty rare today with cybersecurity, they everything was maintained. They had cloud connectivity so they didn't have to roll the features back, their investors are very happy. Investors want a return on investment. They generally don't like being asked for more money when you didn't plan on plan for it, and it was adopted faster in hospitals and healthcare delivery organizations. So if you have a device that's cleared and you can show all the documentation to a healthcare provider or a third party, letter of attestation about the sort of testing that's been done, it's much easier to sell that to the provider. The key takeaways which I've been talking about, start cybersecurity early, avoid delays, have it part of your development process. You development process. And what we've noticed from an investor perspective, we talked a lot of investors, a lot of them really wonder, like, how are you going to handle cybersecurity? And I've been sat through quite a few pitches today. I see you know intellectual property is on the roadmap, but I haven't seen cybersecurity on anybody's roadmap, and now investors. I was just having lunch with one yesterday. He said, out of his portfolio, nobody had considered cybersecurity any three people, three of his portfolio had been rejected, and he told me five other. Ones, he knows how to consider it, considered it because he hasn't seen them ever talk about it. So it's a big problem for investors. So they want to see that you actually have a plan for cybersecurity, because it's becoming expensive, what is considered an afterthought. And we also need proactive. What I've been talking about planning cybersecurity early on is proactive. It's really better to be proactive than reactive in life, and there should be a budget for cybersecurity. Those non functional requirements cost money, having a third party penetration test cost money doing all the pre market submission requirements cost money that should be budgeted appropriately. So why this matters is, I was saying, if you wait and try to bolt on cybersecurity at the end, it's very frustrating that it's going to cost you a lot, like three to five times more, is the average what we've seen, and investors lose confidence. We've even had a client come to us. They actually never were clients. They're a prospect. They came to us. Asked us how much it would cost to fix their to do a pre to do a cybersecurity assessment, and how much we thought it would cost for their development team to fix their product. We gave them some ballpark figures, and it was too much for them, so they just decided to abandon the project. So imagine you spending like, three years on a project. All of a sudden, at the very end, you forgot about cybersecurity. Someone tells you this is how much like our services cost, but our service is not the most expensive. It's the rework for the software development team that's gonna cost the most. They decide to abandon the project, which has gotta be super frustrating. So faster approvals build cybersecurity in early on, early and often, as I said, and it also helps you market access quicker. So I'm open to any questions. If anybody has any, I'm happy to talk about anything in the weeds, high level. Doesn't matter. I can talk technical or non technical, or business or whatever. Does anyone have any questions? 

Audience Question  27:08  
So the trend has been with more for more cybersecurity regulation and guidance from the FDA. But I'm just curious with the current political trend of deregulation. Do you see any change to that trajectory?

Christian Espinosa  27:21  
Well, the change, I didn't think you would change the the rigor and the scrutiny of the FDA regulators, but then today, my CTL told me the FDA just said it looks good enough, but we don't have time to really thoroughly review it, so it might change in that regard. And that's that just happened today. They said we don't have time because too many people laid off. So what I thought would originally, originally happened would be the time for the FDA to review a submission would be greatly increased because of lack of staff. But when I saw that today, I thought, well, maybe they're just going to approve things a little more willy nilly, I don't know. So it's kind of up in the air at this point. Yeah, right. Definitely. Liability, hospital, client liability, 100% Yeah. From legal perspective, even if the FDA approves it, if somebody hacks into it, your device and you know, patients are harmed, the legality is not going to FDA. It's coming back to you as a manufacturer, yeah, and that's a big aspect of it, too. There's been, there's been an increasing number of recalls. I subscribe to the FDA, a lot of the FDA recall list, and there's been, like, almost once a week there's a medical device recalled because of cybersecurity. These days, too cool, any other questions? Did that answer your question? Okay, no more questions. All right. Well, thank you for your time. Hopefully you learned something valuable.