FDA 510(k) Cybersecurity Power Hour: Demystifying Cybersecurity Controls in 60 Minutes

Hello, everybody, and welcome to Friday in Focus, MedTech Leading Voice Exchange. I'm really happy to say that today, we have two distinguished speakers, many of whom you… many of you know them. Jose and Mohammed are here from CyberMed, and I'm gonna ask, Francisco to post the second link, to the article that we posted yesterday. Apparently the new way to, keep a post… what do you call it? The… Amplifier, the…

drive engagement.

Yeah, the way to drive engagement to the posts is to actually save them, so if you could save this post, and maybe put a comment or a like on it, that'd be great. It's an article talking about, what we're gonna talk about today, and so. You can also post questions in there, and we will, monitor it throughout the call. It's a great way to show people that you're on the call. And that you're excited to hear what they have to say. I want to talk for a second about yesterday, in case you missed it yesterday, Beyond the Protocol. Six Mistakes That Sync Human Factors Validations with Denise Forky, Leah Berquist, and Kira Favica.

Kara was formerly at Medtronic, so she, she's gonna go to med school now, that's exciting. Anyway, we had, 600 registrants, over 200 people on the call. And you can get the replay, the slides, and this MedTech usability prep kit. Nothing to fill out, it's just the link. If you go to the link for the usability prep kit, you can just download the thing. It's super useful. If you care at all about that sort of thing, this is for you. Ugh. Two more announcements. One, on the calendar, next week, we're going to have the audit before the audit. This is about internal audits, conducting internal audits. If you're interested in internal audits, tune in for this, because Danny Crew was a BSI auditor for 15 years.

He's done tons of audits, and he's got his own special way of doing it. So, that's good. And then, in 2 weeks, roughly, on Wednesday the 19th, we're gonna have enrollment stops diagnosing A study that's already gone wrong, and this is clinical trials. webinar, with Donna Wildlife Science. Hi, Maria. And, her colleague, head of clinical, Daniela Pereir, is going to be speaking from her experience, and anybody who's ever rescued a clinical trial, well, Danielle has rescued plenty of them, and so it's going to be a really interesting take on, you know.

on that. Angle. Now. I don't usually talk about joining MLVX. I don't try to recruit members. I have not promoted this thing in a year, but I'm doing a membership drive this month. It's your last chance to save 20% on new enrollments. And, I'm not asking you to join off the bat, I'm asking you to book a call with me and see if it's right for you. I think that most of us are in the same position right now, which is wondering where new clients are going to come from. This program is designed specifically for, Small and solo consultants, product and service providers, in the industry who are looking to grow their

Credibility, visibility, and connections. The thing that I'm going to stress, that I stress over and over again, is that when conversations happen, that's where the opportunity for business is. What I love about this call is that it's like attending a trade show every week. It's really the closest thing that you can get to an in-person Event, without… traveling outside your bedroom slippers. So, I appreciate you all being here. I'm not gonna talk anymore. If you're interested in any of these things, please follow the links. I'd like to, you know, talk with you next week, and even if it's to find out why you're not interested in joining, that's okay with me.

I am done, and I'm gonna hand it over to Jose and Mohammed, thank you all.

Everybody! So, Jose Bohorquez here, let me share my screen. Alright, can you guys see that there? We're good. Alright, give me a sec. Alright. Cool, so yeah, so, as… as Sean said, today we're going to be talking about cybersecurity. We're specifically going to focus on cybersecurity controls that the FDA recommends you incorporate. You know, it's kind of like FDA guidance documents. People think, oh, this is FDA trying to provide some guidance. It's essentially requirements. And so they're going to be looking for these things, and we want to demystify some of these for you. Sometimes people… think of cybersecurity as kind of a black art. You know, it can be very complicated, there's factors of it, there's parts of it that are very technical, but I think a lot of the concepts are fairly intuitive, and so that's what we're hoping to do today, is to make some of those things more accessible.

the format that we're going to use, it's a little bit different, so the first maybe 10 minutes or so, I am going to kind of give you a rundown of some of the key concepts that are important, but after that, it'll be more of a conversation. between Mohammed, who's our Chief Security Officer at CyberMed, and myself, so I'll ask him some questions, we can… we can put him in the hot seat. You're welcome to ask questions in the comments, or for the panelists, just raise your hand. and ask away. So, yeah, that's the idea. We're gonna try to cover all 8 controls in 60 minutes, and a few times we'll be asking you questions, so please try to participate in the comments.

And so, right off the bat, let's start with our first question, which is, like, which best describes you? So A would be a regulatory or quality person at a manufacturer, B would be an engineering software product at a manufacturer. C would be, like, you work in security or IT, D would be that you're a consultant, service provider, or investor, E is academic student, between roles, and then F would be something else, which would be very curious to hear what that is. So drop it in the comments, seeing a lot of… A's and D's, couple B's. Awesome, so we got a good mix of people with different areas of expertise, and that's, you know, Sean said, that's what I love about these calls, is that we all get to build our community and network.

Just a quick background on Mohammed and myself. So my background, I've got a PhD in electrical engineering and computer science, been doing software since I was a teenager, and been in cybersecurity for about 10 years. Mohammed, who's our Chief Security Officer, I always like to introduce him instead of having him introduce himself, because I like to brag on him. He's, you know, on top of being you know, a PhD in computer science and the former chief software architect for a Fortune 50 company. So he was responsible for software deployment and security for Motorola Solutions, which deployed global communication systems that were very mission critical.

But on top of that, he's, like, he's one of the smartest people I've ever met, and one of the best software and security people. So, you know, I'm very fortunate to have him as one of our partners. There's three of us, I think our other partner might actually be on the call, but not as a panelist, Andres. And as a company, our focus is to help medical device companies with cybersecurity. So, got a lot of experience both in cybersecurity and in medical device product development. You know, we're at the point where pretty much every company that we've helped with cybersecurity gets through without significant questions on the cybersecurity side of things, and usually.

and we'll talk about this during this conversation, if a company has implemented security well, and it's just a matter of helping them put together the software document, or the security documentation package, and doing the cybersecurity testing that FDA requires, we can usually get that done in less than 30 days. When it takes longer, it's because they come to us and they haven't implemented some of these security controls. And so, they have significant vulnerabilities that they have to go back and resolve. So that's our hope, is to help you avoid those issues during the development process, so that when you come to us to help you with the documentation and the testing, it goes very smoothly. And of course, if you bring us on early, there's a better chance of that.

So, at a high level, this is a diagram that has a lot of information, but I like to show it because we put this together about a year ago to show how we view the incorporation of cybersecurity into the standard product development process. This isn't exhaustive, there's, of course, there's other things that have to happen in the development process. But if you think about software development, which, again, is not the only thing that matters, hardware selections make… make an impact, too. But if you just think of the… during the implementation phase, kind of a classic V model for software development, where you take user needs and

Break those down into system requirements, and break those down into software requirements, and then from that, create your software architecture. Here's, like, one… one approach that you can take to incorporate security into your process from the early days. So, as an example, once you've got your software architecture in place, it's a good idea to put your architecture security views, and then do the threat modeling based on that. Look at any risks, estimate them, evaluate them, determine if they're acceptable or not. And if they're not, determine what security controls you need to put in place to then get those risks to an acceptable level, and then those cybersecurity controls will feed back into your software requirements so that your team knows to implement those controls as they're doing the development.

And it's common that you'll go through this cycle a few times. You know, FDA and we recommend that threat modeling is not a one-time thing. It's something that you're really doing over the course of the development cycle and even beyond. But at some point, you're gonna have an architecture that you feel good about, and then you move into the design phase, and, you know, this isn't meant to be a one-time loop either. You're designing, you're implementing. which is, like, a list of all the components in your software. You want to really do that as you pull in libraries and such, to evaluate those, to see if there's any risks associated with those, if there's any known vulnerabilities with a software package that you're pulling in. Again, evaluate the risk acceptability, and then kind of go through that loop.

Until you've got a software system That is, you know, that has components inside that don't have any critical vulnerabilities or anything that's gonna raise that risk level too high. And then, you know, we got unit testing. Again, this isn't happening after. You're sort of doing a lot of this stuff At the same time, and, and in loops. But you'll do your unit testing, you might discover there's a fault, either with the functional part of the software or with security. You go back into that loop. You're incorporating static and dynamic application security testing, and again, if you find vulnerabilities based on that, you might have to go back.

And then, you know, eventually, you feel like you're in a good spot, you do your software verification. And then you might find that there's some anomalies in your software that are acceptable to go to FDA with. Well, you still have to analyze those anomalies for security. And so at some point, you feel like you're in a good place. you kick off kind of the formal third-party cybersecurity testing, which includes penetration testing, fuzz testing, vulnerability analysis, all sorts of things. People kind of think of pen testing, but that's really just one element of the independent cybersecurity testing, and you might discover vulnerabilities there.

And so the, the, kind of the… the billboard high-level point to take out of this is, if you're finding vulnerabilities earlier, they're easier and less expensive to fix. Don't wait to do some of these things till the end, because then you have to go all the way back to the beginning, and I'll speak to that in a bit more detail. Coming up, but… you know, this doesn't have to be the exact process that you follow, but you should be following a secure product development framework across the life cycle of the product. And of course, there's other responsibilities that come post-market for cybersecurity.

So, you know, I like to tell people, like, I like to put numbers to things, right? I'm an engineer, I'm a very numbers-driven person, and the same vulnerability might cost you $1,000, or it might cost you $10 million. And I don't think this is an exaggeration. So, if you consider, like, if you find a vulnerability during your architecture phase, it might just be, like, a couple hours of your systems engineer rethinking it and architecting it a little bit differently, and it's in the thousands of dollars of cost. If you don't catch it then, and you catch it later during the implementation phase, now you're talking about going back and updating the architecture, and then going back and rewriting code, which could be weeks of engineering effort, which could be in the tens of thousands of dollars.

If you don't catch it then, and you don't find it until you're in the testing phase, you might have to go back and redo the architecture, redo the development, redo the testing, and now it's causing you a delay to get to market, and it could be in the hundreds of thousands of dollars. And then, of course, like, if it's not caught until the FDA reviews your package, like, we see companies that don't even realize they need to put together a security package. They think, well, my device doesn't connect to the cloud, so I don't need to do this. And then FDA kicks it back to you. You could be in this scenario where

you know, first they refuse to accept it, so that causes some delay. Then your team, like, tries to put something together quickly and send it back. FDA finds a bunch of issues and sends it back. Your team's now trying to change the software, like, going through the review process, and eventually, you know, Carrie or Michelle or whoever your regulatory advisor that says, you know what, like, our best move here is actually to withdraw and fix the system, go back through testing, and then resubmit, and you're now delayed 6 to 9 months to market. And, you know, a mentor of mine taught me a long time ago that when you're pre-market, when you haven't launched yet.

you're just losing money every month, right? So if you understand your burn rate, like, let's say your company's burning, as a startup, you're burning $200,000 or $300,000 a month. And you do… you make a mistake that costs you 6 months, well, take that $300,000, multiply it times 6, $1.8 million, and that's really the cost, because you're not generating revenue. So… so you don't… you want to avoid the mistakes that are going to cost you a lot of time to get to market, and cybersecurity can definitely be one of them. It's not the only one, but it's… it's… it's one of them. And then, of course, like, the worst, worst case scenario is that you get through all of that.

you know, you have a significant vulnerability that FDA doesn't see, your team doesn't catch. And then your device actually gets hacked, somebody maybe gets hurt, you know, you make it to the news, your reputation's in the tank, your investors pull, and now something that you've spent years building, and maybe tens of millions of dollars. you know, you're in a terrible situation that puts you in a very bad spot. So, you know, the headline here is, try to catch things early, right? Try to take this seriously, build the culture in your company that takes cybersecurity seriously, so you don't find yourself in one of these situations.

In a quick 2x2, like. You know, you might have really good implementation from a security standpoint, but poor documentation, or vice versa. And, you know, if you've got poor security and poor documentation, that's gonna cost you time, right? Because you're gonna have to go back and redo everything. Poor security and good documentation is actually quite rare. Because if you're following a process that results in good documentation, chances are you're going to implement good security. So this is a… not that common of a scenario. Of course, where you ideally want to be is you want to have a system that the security was implemented correctly, and it's all well documented, and then you're in great shape.

But if you're in a scenario where you implemented security well, but it's not well documented, that's fairly easy to recover from. Right, so we get a lot of clients in this scenario where their team is experienced, they know how to properly implement, you know, authentication and encryption and all these things. They just either hate documentation or don't exactly understand what FDA wants. and they come to us, and we put this together quickly for them, this is very recoverable, right? But the key thing is, you really want to make sure you implement the system securely. Okay, cool. I'm gonna skip through this, because I want to get through some stuff, but I'd like to do a second poll.

Which is, where is your device right now? If you're developing a medical device because you're a manufacturer, or maybe you're a consultant helping companies. Are you at the pre-submission or design phase? Are you now preparing your 510K? Is it in review, and maybe you're responding to a deficiency? Is it already cleared? And now you're kind of living with the decisions you made, where, you know, you're… Maybe finding some vulnerabilities and don't have a good way to patch them. Do you work with people's… other people's devices, not your own? And then maybe you're just here for… the good times and not really involved with devices, or maybe you're a student, you're… you're not even working on things. All right, great, so we got a good mix. Michelle's got ABD Andy, awesome.

Awesome. Alright, great. So yeah, Appendix 1 is in FDA's Cybersecurity guidance, which was first released in 2023, but now we're up to the third version in 2026. There's an appendix that actually tells you 8 different cybersecurity controls that FDA expects to see. So that's a good way to find it. And, and I'll list them here, and then what I'm gonna do is start asking Mohammed some questions so that he can explain to everybody what they mean, you know, from a technical standpoint, and also from a layman's term standpoint. So, you've got authentication, authorization, cryptography. Code, data, and execution integrity.

confidentiality. Event detection and logging, resiliency and recovery, and then updatability and patchability. And, you know, if you implement 6 out of 8, or 5 out of 8, or 7 out of 8, That might be okay, actually, in some scenarios. You'd have to explain why one of them doesn't apply, but chances are, if they all apply and you've only implemented some of them, you're going to run into issues. So, the next question here is, how many of the eight could you document today with test evidence, would you say? So, all 8, feel pretty good, you know all about this. I see Martin says all, and I'm not surprised. I know he's a… he's a pro.

5 to 7, 2 to 4, none of them yet. I'd have to go and look, I'm not responsible for this stuff, so… none of the above kind of thing. Alrighty, good stuff. Got some E's, not surprised. Alright, cool. Alright, so now let's get to it. Mohammed, time to get in the hot seat. So, what is authentication?

Indeed, what is authentication? Let me actually just clarify two things on… before… from what you said. Firstly, another way of seeing these 8 controls is actually on the E-Star submission form, because the FDA considers them important enough that they pull them right out on that on that level. So, so it's not just buried in the appendix. And then the second thing, just to point out, as we discuss these, oftentimes these all work together, so it's challenging to just think of them individually and just ignore the others. So now, with regards to authentication, which actually, in many ways, is the easiest one, it's one that everybody kind of is familiar with, it's really a… it's really identifying, or it's really clarifying your identity.

To prove who you actually are. So, one of the things that authentication is not, and this sometimes gets confused, is it's not authorization. So, it doesn't have any implication regarding what you can do. It's simply defining who you are. And the who could be a person, it could be another machine, so it's either identity of a human or identity of another machine. And fundamentally, the reason for this is This is what establishes trust between parties. So that's… that's in a nutshell what authentication is. It's a means by which you're identifying who the other party is.

And what's an example that maybe people who are not in cybersecurity might be familiar with, that they see every day?

Yeah, I mean, you've got it in your wallet. Any government-issued ID is your identity, right? An identity is just that. It's just… it's something that some… someone… some party that is mutually trusted, issues to you to say, this is who you say you are. Another one that's common is something called a certificate, for instance. You can see it in your browser. You have certificates for websites, for instance, that identify them as being, you know, issued to a particular party. And again, you have a matter of trust established between you and the provider. Through, through that identity.

Awesome. And, like, for example, like, if you're logging into email or something like that, or into a website, what might you do as a human to authenticate?

Yeah, so… so you're… so this is a little bit, you know, so… Authentication now of things like websites is essentially a combination of, for instance, sometimes it could be a username and a password. Sometimes it could use two-factor… they call it two-factor or multi-factor authentication, where it's not enough just to provide one piece of information. There could be a, you know, a code that comes to you by email, or it could be a text message. So there are… there are different forms Of achieving authentication, but they all fall under the same umbrella, which is, it's a way of conveying, clearly conveying to the other party

who you are. And it's usually the very first step of any kind of exchange.

Yeah, no, that's great. So, I think a lot of people are accustomed to that. I remember somebody, putting it this way once, our good friend Mike, who was like, you know, you try to show, who you are, maybe by something that you know, like a password, something that you have, right? Like, it might be your phone, or something that you are, right? Like your fingerprint, or your, you know, your iris, or something along those lines, because you're trying to find a way to prove that you are yourselves in a way that somebody else can't spoof, can't pretend to be. And, you know, in authentication, I know a conversation we were having not too long ago, Mohammed, you were talking about the fact that people sometimes think, like, it's just me that has to authenticate with Google, right? But that's not true. Like, you also want to make sure that Google authenticates with you, that shows you that they are, right?

So, yeah, we're actually very… we're actually very used to one-way authentication, which is where I'm proving who I am. You know, whether it's you as an individual, you show up, you show somebody your ID, and then they trust you because they see who you are. With systems, it gets a little more complicated, because sometimes it's not enough for you to know who the other party is. The other party needs to know who you are also, so it's what's known as mutual authentication. So you want to authenticate… so it's not enough, for instance, sometimes to know that the server is who it is, who the server is the server that it's supposed to be, but occasionally you have the need for the server to know who the clients are. So… so authentication can get… and again, that… the premise of that is you have a central party who acts as the broker of trust, so…

Each side essentially uses that broker of trust to convey authentication to the other.

Yeah, yeah.

So…

One layman's way of thinking about it is, like. You know, when I go on Google and I type in my username and password, I want to make sure that it's actually Google and not some spoofed website that is, you know, trying to steal through a phishing attack. my credentials, right? So it's just as important for me to be able to know that that's the place I'm supposed to be communicating with as it is for Google to confirm that I am who I say I am. And that's, you know, at the… at the layman's kind of, like, human… point going into, like, a website, but, you know, as Mohammed's saying, at the system level as well. Like, you want to make sure that if you're pulling an over-the-air firmware update image, that you're pulling it from the right place, not… not a site that's, trying to spoof.

Yeah, I think there's one more thing to consider, and I know there's a question… there's a hand raised, but one more thing to consider for authentication, and it's a simple… authentication in and of itself is a simple concept, but one thing to consider is the granularity of authentication. So. again, this is something that's part of the control of authentication. Do you want to authenticate a group, or do you want to authenticate an individual? And obviously, you know, I would lean more towards individual authentication rather than group-level authentication. But again, this is all… so again, simple concept.

But when you get into the details of how controls are constructed for authentication, there's a lot that goes into making the decision as to what's the right level of authentication for the scenario. And they're almost always all different, so… so you have to sort of consider authentication. In the scope of the system that it's being… that it's being used in.

Luke, I think you got a question?

Well, there was something I'd like to add, and that is that we run, of course, in the same problems. But also, like, that not only the access to the device was authenticated, but then also you store data on the machine, and it also has… the data has authentication in the file itself. So… If you move the file around, you also move the authentication around at the moment of storing the data. Of course, there's different solutions to it. You can also authenticate the place for… how do you call it? Make the place where you stay, where you place the data secure, so that you have to authenticate against the silo where it's placed in.

But, we found it difficult to… To have the authentication on the data file, because then you cannot revoke the authentication on that data file again.

Yeah, I think… I think this… we'll get it… we'll touch on this when we get into data and integrity, which is another control for the.

That was too early.

Yeah, we'll get to there, but no, but you bring up a good point, which is, you know, identity. So if you just take out the word authentication, and as I said, authentication is about proving identity. The identity as a concept goes further than just authentication, as you just said. So, for instance, when you get into logging, which is another control, you probably want to capture the identity associated with a log entry. When it comes to data produced, your medical data produced, you want to cap… capture the identity of the producer, and incorporate that with the data, because it's an important part of the integrity of the data. Where did it come from? So, so authentication, think of authentication as the control

Through which identity is proven. But it isn't the end of the road for identity. It's just simply the first step of establishing the identity.

Alright, cool. So just to keep us moving, let's go to number 2. authorization, which sometimes people confuse with authentication. So what is authorization, and what's the difference?

Yeah, and they do go together, but they are different things. So, when you think about authorization, authorization is really about role enforcement, about deciding what you can do. So… so that, you know, authentication is who you are, authorization is what you can do with the system. So, so this is important to consider because from a security perspective, you're always really driving for what's known as the principle of least privilege. It's a concept where you say, in general, for any given identity, you want to provide them only as much as what they need to do. You never want to provide anyone any entity in the system

more capabilities than it ever needs, because that just creates potential… potential misuse scenarios from a security standpoint. So authorization is about defining what you can do as an identity, essentially. And again, not…

Like a user, or an admin, or maybe a patient versus a clinician, that sort of thing?

Exactly, exactly. Those are the types of roles. So, the role a patient may have in a system may be different than the role a clinician has, which may be different than the role an administrator has. Those are simply three roles within the system. Now, now, when you look at… when you start constructing authorization systems and authorization controls, it can get a lot more complicated. You start having to think about, well, how many roles do I have? Do the roles overlap? How do I design the roles so that they're, you know, clearly laid out? Can roles be misused? There are many aspects of role management and role-based access controls, as they're called, that have to be considered

under authorization. So again, summarizing, authorization is effectively what you're allowed to do once you have identified yourself to the system.

Right. And, you know, we kind of tend to think of this as people, right? So, like, a person's a user, or a person's an admin, but are there authorization elements that go beyond people, and maybe software.

Absolutely.

Things like that.

Absolutely. So, you know, and again, we… oftentimes, a lot of these controls we think of as humans interacting with systems, but there's a… there's probably… it's more pervasive that it's really systems interacting with other systems. So your medical device itself might be composed of multiple subsystems that need to communicate with each other. That's very common. your medical device might need to communicate with larger medical device systems around it. It could be a hospital system, it could be other medical devices that it interchanges data with. So. These concepts all apply in the machine-to-machine level as well. So, you could have different levels, different roles, one machine, one medical device interacting with another. For instance, it could be a read-only role, where all it's allowed to do is access and retrieve information. It could be a role where it's allowed to actually modify data. So again, you get down to that granularity.

In designing the roles that machines can talk to machines and perform.

And I know we got a question here, but before that, so, yeah, I mean, I think even, you know, people, for example, these days are giving their AI agents, like, access to, like, let's say their bank account to do analysis on that. well, you want to make sure you're careful, like, maybe it's okay to give it read access to certain things, but maybe you don't want to give it access to write a check, send somebody a payment, you know, without your confirmation. So, just examples of how it's important to set up your roles correctly and your authorization. We got a question from Prachil, he's saying, kind of like, what's the difference between role-based access control and authorization? Are they the same thing, or similar?

Yeah, role-based access controls are a means by which you achieve authorization. So, the role-based access control is the control. It's the control that achieves authorization. I'll go one… I'll give you one more example on the machine level. So, people might have started getting a bit more familiar with the idea of creating API keys. It's becoming sort of more common now with Agentic-based system that you go and create an API key. Oftentimes, those API keys are essentially encoding identity and authorization together. So, your one key is essentially allowing you to access that API, and it defines who you are, which is the identity portion, and it also defines what you're allowed to do, which is the authorization piece. So, as I said right at the beginning, a lot of these controls do work together, they're not just isolated from each other. And in many times, a single control can combine

multiple aspects.

Excellent. Thank you. Alright, so what's the third one on our list? Or before that, let's get your involvement real quick. So let's have a scenario where, you've got one shared service credential for the field team, so you've got a field team, they've got one password, let's say. It's a strong password, it's documented, you've documented a rotation procedure, four technicians have that credential, and you're supposed to be submitting next month. Do you ship it and document your compensating controls, or do you stop and build? per user identity. So, give us your thoughts in the comments, what you think there, and then we'll put Mohamad in the hot seat to get his take on it.

Maybe people are… here we go. Florin says, stop. Alright, getting a lot of Bs. Anybody wanna say, hey, hey man, you gotta… you gotta submit next month? You got… there you go, Michelle… Michelle's the brave one that says, come on, guys, it's just 4 people. Shit. Depends on risk level.

I was gonna say, it depends.

Hands-on risk? Okay. We got a mix. Alright, Mohammed, what's your take? We're submitting next month.

I would probably instinctively lean more towards, obviously, more towards B, but it does depend. There are scenarios, there are situations where, you know, maybe that's too much, and maybe there are ways, you know, there are comp… there are sufficient compensating controls that allow you to move forward. you know, sometimes it's a question of, you have compensating controls that provide you what you need, at least temporarily, and you can say, I'll move forward right now under these compensating controls, and over the next 3 months, I'm going to, you know, revise it and and add in what's needed. So… so it does depend, but… but I would lean… instinctively, I would usually go more towards a B, unless there's some… some really strong reason not.

You make a great point, which I think some of the regulatory experts on there made as well, which is that everything in medical devices and cybersecurity ultimately comes down to risk, right? So doing a risk analysis, and then ultimately an evaluation of, is it acceptable or not? And yeah, maybe we can come up with scenarios where it's actually acceptable because the potential risk is It's very low, both from a security and a safety standpoint, but certainly from a best practice standpoint, that wouldn't be the ideal scenario. Alright, excellent. Alright, so now, a term that maybe is… the one that people think about the most when they think about cybersecurity being cryptography. What… what is it? Like, what is cryptography?

Yeah, so… so, yeah, it's a term that people probably know the most, and people just maybe naturally associate cryptography with encryption. The two sometimes go synonym… sometimes people will think of them synonymously. Now, it's not… it's not exactly that. So, crypto… cryptography, really, as a science, is really the… the use of mathematics to to, you know, to provide data secrecy, and do verification. So it's really fundamentally The, the science of utilizing mathematics. to define algorithms that can then be used for things like encryption and decryption. And they can be symmetric, you know, with the same… the same, essentially, algorithm can work in forward and reverse to be able to encrypt and decrypt. They can be asymmetric, where… where

they have… there are differences between how you perform encryption, you perform decryption, different keys, etc. So fundamentally, cryptography is the use of math to be able to provide the level of secrecy that we want for data. A lot of people make the mistake and kind of think about cryptography as just being obscurity, and there's a phrase that is used a lot in the.

up here.

in the security domain, which is security through obscurity is not security. So you, you know, so fundamentally, it doesn't mean, you know, obscurity is not security, basically, fundamentally. And then, why does it really… why does cryptography matter, fundamentally. Ultimately, a lot of security control… a lot of security concepts are fundamentally grounded in cryptography. To the extent that cryptography, I don't know, again. Cryptography is a… is almost its own discipline by itself, and when you start getting into the details of of cryptographic mechanisms, you start hitting up against, for instance, standards for NIST and others that define what can be used, what can't be used. Now, in the consumer world or commercial world.

Perhaps that's not looked upon as strongly as it is, for instance, in government spaces. If you operate in government spaces. you really don't have a choice. I mean, NIST enforces, and all government contracts will enforce you to use NIST-approved algorithms, NIST-approved approaches for using cryptography, etc. And also…

Ultimately, I mean, you're taking something that a person or a human could understand, you know, clear text, right, something that's, like, I can read and understand, and converting it into ciphertext, or something that I can't read or understand, either as a human or as a machine, right? So it might be sensitive patient data, or it might be code, right? It might be something more technical. What can you give us?

That's true for… that's true for the concept of taking clear text and converting it into a ciphertext using… using an encryption algorithm. That's straightforward, it's easy enough to understand, but when you get into, for instance, and I'll roll back to what we talked about earlier with identity. So, when we talk about identity, there's this concept of signatures, and when we talk about signatures, we're talking about cryptographic signatures. So, there are mathematical ways of proving that a digital identity is who it's supposed to be. through cryptographic signature verification. So, cryptography plays a role in other controls, because, as I said, it provides the foundational… essentially the foundational math and foundational algorithms

To provide the necessary secrecy that we need. So… so… so it's… yes, it covers data, quote, encryption and decryption, but it also goes further than that, and it… and it gets into how do you form signatures, how do you do verification, where do you establish, what are the roots of trust, where, you know, where do you begin with trust? And then you get into more complicated things, because a lot of cryptography relies on the use of random numbers, for instance, and then you get into the sort of almost black art of entropy. And what are good entropy sources, and how are… what is really random, what is not random. So as a simple example, we can take data

encrypted data. And we routinely can perform… will perform, actually, cryptographic analysis on it to determine the degree of entropy and how well encrypted it is. So that is a way of measuring, for instance, your cryptography control. So it's, you know, so as I said, cryptography is a very foundational part of this.

Yeah, and without getting into the weeds too much, we got a couple questions. I'm going to get to Tom's in a second, but I want to answer Maria's first. You know, she's asking, like, what is a key? Like, what is the role of a key? What is it? What is its role in encryption and decryption and cryptography in general?

So it… so the answer simply is it depends on the algorithm. So the key is a part… the key is… just think of the algorithm as the lock, and the key is the thing that fits into the lock. So you need to have the right kind of key for the right kind of lock, basically. Now, an algorithm like AES, for instance, which is a… which is a pretty common symmetric algorithm. That can use a range of sizes of keys, and when we say size of keys, it's just the number of bits of the key. So it could be, you know, a 128-bit key, or a 26-bit key. And then when we talk about bits, it's just a number. So at the end of the day, the key is just a number. It's just a very large number, that is generated.

Right?

Correct. Now, it doesn't have to be, because you could have, you know, asymmetric schemes, like RSA, where you've got, you know, public and private key pairs. And they can be large numbers that happen to work together, and you can use one for encryption and one for decryption, and the public one can be given to anybody. It's not a secret. Only the private one is kept as a secret. Elliptic curve uses something… similar approach, where you have private and public key pairs. The pair… the keys have to be… the pairs are created together. One you keep secret, and one you give out. So that's very common, for instance, if anyone wanted to know the insides of a… of a certificate. So what… what certificates really are, are simply a structure

that carries a public key. That's really all they are. I mean, they define some additional information, but fundamentally, they're a standard way of passing public keys between parties. That's really what a digital certificate is. And then you would use the public key… I mean, it's actually usually more than one, it's a chain of public keys, but you… you would use the public keys, to then… so that the… We're getting into a lot of details, but in asymmetric cryptography, the idea is you can encrypt something with a public key. That can only be decrypted by someone with that private key. So no one else can decrypt it. And that's a way of passing information, so if I have someone's public key, I can encrypt something, pass it to them. Anyone that gets it can't determine what it is, because they don't have the private key. Only the recipient that has the private key can actually decrypt the message.

Great. All right, and then, Tom had a question.

Maria E. Donawa, MD: Thanks.

Steganography, and… Do you see it used in medical devices at all? I'm sorry. Yeah, Tom had a question on steganography, so essentially, like, hiding secrets, messages, and kind of ordinary things, like images, or text files, or that kind of thing. I feel like we don't really see that much, but have you seen that in use at all? Medical devices?

Not… not really. I mean, it's conceivable, but, if we… yeah, I mean, I think… I think, again, you just have to be a little bit careful with things like that, that… it isn't part of your security. In other words, again, we fall in… we can fall into the trap of obscurity being used for security, so you have to be a little careful of, like, using a hidden… So an example of that is, if I use a shared… what's known as a pre-shared key. So if I have a key that I put in one device, and I store it inside that device, and that pre-shared key is the secret, and it's being used to communicate with another device, you just have to be careful about the exposure of, like, those keys.

So, so there, there's, which is why, again, you get things like key negotiation schemes. So, so there's… Cryptography, again, without getting into a lot of the details, cryptography is a fascinating area that you can go into as… just by itself, as a science, as I said. I mean, it's… it's, you know, we… we tend on the… we tend, from a security control perspective. to leverage the science that already exists, and we're not trying to invent our own algorithms, or our own key schemes, or anything like that. We're trying to leverage industry standard practices. But that field itself is a fascinating field, if you want to get into cryptography.

All right, excellent. So we'll keep moving. I see we got a question from Carrie, and we're going to come back to it in a minute. But, Code, data, and execution integrity. What is it? Why is it important?

Yeah, so… so… and this is a fairly broad topic as well, but I'm going to try and keep it really simple. So, when you talk about code, execution integrity to kind of split it. So, it's… it's just as simple as, I put some code into a device, and this could be, you know, an actual, you know. a portable medical device, handheld medical device, or it could actually be on a server, doesn't really matter, but I've got… I've developed… I've developed an application, so I've developed some code, which is what I've got cleared on. This is my cleared device software. It's in my device, but how do I know that it hasn't changed? How do I know… how do I guarantee? And that's really what it comes down to. How do I… how do I guarantee that every time my device starts up, powers up, and starts running.

it's running the code that I expected it to run. Same thing on a server, on a cloud, etc. And the answer is actually, again, it ties back to what we just said. There are actually cryptographic means to guarantee that, to guarantee that it either is the… it either is what you put in there, what you expect it to be. Or it isn't. And if it isn't, then you should be doing… then there should be some exception handling to determine what to go do. And when it comes to data, it's a similar concept. Think of data as being, for instance, your configuration data. And it could also be data gets produced, medical data. So how do I validate the integrity and authenticity of data, of configuration data? I put some configuration data in there. Is it the same? Is it the same today as it was a week ago?

And if it isn't, who changed it, and when? And, and…

ties into another security control, right, around…

It does. It will tie into that, yes. So again, as I said, they're tying to each other. So yeah, so code, data, and execution integrity is all about making sure that your device is operating the way it's supposed to operate with the software that you planned it to have, basically, and the configuration that you expected it to have.

Awesome. Alright, before we move to the next one, I do have an informal poll that's not included in the slides, but there's two topics that we've heard some questions about over the last couple months, and so we're thinking of doing two webinars. One of them is kind of like a cybersecurity specifically for regulatory and quality assurance professionals, so it's kind of take… looking at it more from a regulatory standpoint. So we're thinking of putting together a webinar or a workshop around that. And then another topic that we've heard about a lot, and that we think is fascinating, is the kind of the Venn diagram of cybersecurity and AI, right? So, whether it's specific cybersecurity issues related to artificial intelligence, the use of artificial intelligence for offensive means, right, for hacking, for attacking people, and then the use of artificial intelligence for defensive means.

And so we're thinking about putting together a workshop around that. So just in the comments, if you're interested in either one of those, we just want to know if there's enough interest. Let us know, like, regulatory, AI, both, and then that way we know what kind of interest there is, and then we'll know to invite you guys if you are interested in In one or the other topic. So, yeah, you can put a number. Number 1 for regulatory, number 2 for AI, or number 3 for both. Any of those should work. Okay, awesome. Looks like there's some interest, so maybe we'll do that together. We'll do that after all. Cool.

Alright, so let's make a quick… participation piece, too. Let's think about the root of trust. Now, we haven't really talked about root of trust, so maybe we need to explain that first, and then we'll lay out a scenario… Get your thoughts on what you might do. So, Mohammed, maybe a quick explanation, what is a root of trust?

Yeah, I think I touched on it slightly, as I said the phrase earlier, but fundamentally, whenever you are, validating identity, you need to start trusting… someone is conveying that… the… the trust of that identity to you, and the question is, do you trust them? Where does it start? So, roots of trust… so, for instance, if you're talking about public, certificates, for instance, there are companies that act as the roots of trust that issue those certificates, and as long as you trust them, then you can trust their certificates. So it can start there. When you have closed systems, medical devices, for instance, that are, you know, hardware devices.

that potentially, need to trust each other, then the question becomes, okay, well then… and there's no third party, for instance. How do you establish the roots of trust between them? how does one know that it can trust the other? And… and so… and there are techniques for this. There are mechanisms through which you can establish, essentially, roots of trust. And the tricky part about this one that people don't quite understand or get confused with is Establishing roots of trust oftentimes involves far more than simply your device. It's actually the environment through which your device gets created, oftentimes, that's more important. So, where is it being built? How's it being assembled? Where, at what point.

Is trust being placed inside it, and… how do you control that? So there's process controls that you have to consider, there's mechanisms and approaches, all the way back to the point of manufacture that you have to consider. So it's… it's not a… it's actually… it's not a… it's not a trivial exercise to… to establish a new route of trust, let's put it this way.

Perfect. So just on the we won't go through this, but I see that some people have thrown in their answers, which is great. And I do see we have some questions. So, Alex, Condon from Matrix Connect. I know, yeah, so Matrix, we're familiar with those guys, so they do cloud, for medical devices, and, you know, there's a benefit, of course, to working with, pre-built cloud systems like that, and that you've got a whole different team that's focused on that security side of things. But he's mentioning that when he's dealing with clients, he often tells them, it's not enough to make sure that your cloud is secure, your embedded device also has to be secure. And he was asking, like,

do we do security testing for embedded devices, and what… maybe what does that look like? So, a little bit of an aside around cybersecurity testing for embedded devices. Any thoughts you'd share on that?

Yeah, absolutely, and it's a critical part. So, you know, an embedded device is no different than any other, you know. SAMD medical software or anything else. So you… you have to basically look at all the interfaces, and oftentimes the… the… probably the… I would say the challenge with, physical medical devices is, conforming to their interfaces. So interfaces sometimes are not… are not, You know, not standardized, so you're… we have to build adapters, for instance, to be able to communicate with them, but we will do that, and… and actually do full vulnerability testing of medical… of the actual devices themselves, the embedded systems within them.

So…

Wi-Fi, USB, like, you know… USB, Bluetooth, exactly. Yeah, good, good. All right, we're gonna go into a flash round, because we've got 8 minutes and 4 more controls to go, so I'm going to ask you to answer as fast as you can. What is confidentiality?

Yeah, this is easy. So confidentiality is the easiest one. It's protecting sensitive data, and so, you know, PHI, everybody in medical is kind of aware of that, the concept of PHI, and so things like encrypting at rest. So, really, really, confidentiality is just making sure you have the controls in place such that any sensitive data is protected. It's really as simple as that.

All right. Event detection and logging. Why is that a control?

Yeah, and this one is probably, I would say, one of the ones that is most, often skipped, and one that we see FDA pointing out more than anything else, probably, of these… of controls that are missing. So, it is in… from a security perspective, you think of the concept of security audits, right? An incident occurs. Well, you need to be able to get as much information to learn about what happened in your system that caused that security vulnerability to make sure you can protect against it ever happening again. That's where event detection and logging comes in. So this is not functional. Many teams, many medical devices, both by nature, have

logging for functional issues. You know, something happened in a device and you captured that. But they will miss out having, event detection and logging for security, and it's different. And so… so really, fundamentally, what you're looking here, and the controls are, do you have in place sufficient event detection and logging to ensure that any incident that the device can detect, any of the other control failures, so control failure of authentication, of authorization, of everything that we've talked about, right, and the ones to come. is captured. And more than it's captured, it's captured, it's accessible, it's reviewable, it's actionable, so you can actually use it to improve and protect your system further. So this is a recognition that

you will not be invulnerable. Vulnerabilities will always either exist today or can exist in the future that you didn't even know about, and so you have to be able to recover from vulnerabilities, and this is the means by which you gain the information to allow you to recover. I'm trying to be as succinct as I can, but…

Even more succinct, resiliency and recovery.

Yeah, and this is… so this feeds onto it, right? So… so this is, again, recognizing that failures can happen, so security vulnerabilities can manifest themselves, and they can be taken advantage of with an attacker, what happens then? Does your device have the ability to essentially fail-safe? Can it, even though someone was able to penetrate it, you know, get in with invalid, you know, escalate their authorization, for instance, change their role. how does the device handle that? Is it resilient to that? And then, on the recovery side, is what happens… how can you trigger recovery? Does the device have the ability to restart itself back into a safe mode? Is it vulnerable forever once it's become vulnerable once? So…

What are the controls? What are the means by which your device can return back to a safe, secure state? That's what this is all about.

And designing it so that it… so that it is, so that it is…

I mean, that's the control. You have to put the design controls in place to ensure that the device can be restored back to a… restored back to a good known working state, and that the recovery is not oh, I have to send the device back to the manufacturer and wait 6 months until it comes back to me, because then they may have a problem with availability and usage of the device. But anyway, so that's what resiliency and recovery is about.

Alright, and now the final one, number 8, ability and patchability, what's that all about?

And again, and this is actually simple, again, people can understand the concept of remote updatability, but I think that the nuance here is that in the past, maybe it was acceptable that devices get periodically updated once a year, once every six months, whatever it had to be. FDA really enforces this principle of, well, no, if you have a vulnerability and something happens in the field, you need to be able to, and this is important, securely update your device promptly. Now, you'll commit to that as part of your management plan, but fundamentally, you need the means to achieve it. And this ties right back into, we talked earlier about, and this is where the tie-in comes in, we talked earlier about code integrity, integrity and execution. Well, this is important, an important tie-in here, because when you perform a software update securely.

you've got to be able to do it in such a way that it works with your security, with your integrity controls around execution, for instance, which means you're using signed software that has to be cryptographically validated when it arrives. The, you know, and so you have to think through How does… how…

Oh, looks like we lost Mohammed. I swear, I didn't do it. We lost you for a second there, Mohammed, but yeah, absolutely. So it's not just that you want your device to be updatable, because of course, if you discover a new vulnerability. That's not very helpful if you can't patch it, if you can't fix it. But at the same time, you don't want to implement updatability in an insecure way, where it creates even worse vulnerabilities, right? So you're balancing those things out. Awesome, thank you, sir. I'm gonna skip this in the interest of time. Maybe just as a final poll here, which of these 8 has your team found to be the hardest? Or maybe, you know, if you're not involved in the implementation, do you find the most confusing?

Just curious out of these. So, authentication or authorization, A, cryptography, key management, etc. Code, data, and execution integrity, detection, resiliency, and updatability, all of the above, or, not sure quite yet. That's okay, too. Awesome. seen a good amount of Ds. Yeah, I feel like D's.

D doesn't surprise me.

Yeah, yeah, yeah, sometimes people… Particularly on the detection and resiliency side, it's not so clear. How do you design a device to be resilient if, in fact, it does get compromised? And how do you update it? Awesome. Thank you, guys. Thank you all for participating in these polls. You know, just some final thoughts as we wrap up. You know, when you go to submit your FDA, it's usually not okay to just say not applicable, unless you've got a really good rationale for that. FDA's expecting you to consider all 8 of these categories and more, anything else that might be relevant. If there is a category that legitimately isn't applicable, just make sure you provide proper documentation and evidence for that.

And the last thing I would say is, like, remember that clearance is just the beginning. There's a whole other conversation we could have around post-market responsibilities, you know, as Mohammed mentioned during the conversation. just because your device is deemed secure today doesn't mean it's secure forever. There's new attack vectors that are found, there's new vulnerabilities that get discovered, you know, there's… There's zero-day attacks, there's people who find something that nobody had even found before, and so, you've got responsibilities as a manufacturer to have a process in place to then capture those vulnerabilities and fix them.

So as a final poll. What would help you the most in the next 90 days? So, A, a gap review of our cybersecurity documentation before we submit. B would be help answering a cybersecurity deficiency we already have. C is, security architecture and Threat Modeling for Device and Design. D is security testing and evidence generation, and E would be, now we're good. That's the gist of it. And, and you could also, you know. If it's not relevant, let us know that. Really appreciate everybody being on the call, participating in the comments, and the few of you that were brave enough to speak up as well. Sean, any closing things before we get off here?

As usual. would like to thank the speakers, for our excellent presentation today, and everyone who attended and participated, and I would close by saying I look forward to seeing you next week for, the audit behind the audit. Don't forget. And… Everybody have a great weekend. Thank you.

Reach out on LinkedIn, my email is also on the slides on the bottom there, jose at cybermed.ai, so if you've got questions or need help, please, please don't be shy. Awesome. Thanks, everybody.

Thanks, everyone.

Maria E. Donawa, MD: Really excellent. Thanks.

Thank you, Maria.

Take care.