Mastering MedTech Cybersecurity Secure Your Device & Get FDA Clearance (2)

I guess we all got kicked out.

Yeah, I'm not exactly sure why, but we're live again. Apologies to anyone who had to log out and log back in. But we are here, and we are still having this event very shortly. Jose, you want to pull up your slide again.

Yep. Give me a sec.

Sure

we'll just give people another few seconds to make sure everyone gets back on, and then I'll kick things off. Well, welcome everyone to mastering medtech cybersecurity. Secure your device and get FDA clearance. This is a master class presented by Medtech leading voice and cybermed. I pasted some housekeeping notes in the chat, but I can just run through them quickly again, and then we'll kick things off.

So the recording and slides for this masterclass will be available and sent out to everyone tomorrow. And if you have questions, please use the Q&A button, and that function in order to ask them. We'll do absolutely the best we can to get to all the questions. But, Jose. we'll follow up with anyone who has an unanswered question and requires further contact. You can use the chat function for comments. Also, a certificate of attendance is available. Medtech leading voice will handle that. But if you want a certificate of attendance. Please write your email and the name as you want it to appear on the certificate and put that in the chat at some point during the webinar.

and those will be delivered in the next 48 h or so. Today we have Jose and Mohammed. Jose is the president of Cybermed, and Mohammed is the Chief Security officer at Cybermed, and my name is Dylan James Brock. I'm the executive editor at Medtech, leading voice. So check out the contact information. And then the last link we've presented in the chat which I'll share again later, is a free download link to get your cybersecurity quick. Start guide from Cyber Med, you can download that at any time on their website. Just go to Cybermedai or use the link in the chat. And with that hiccups and all. I'm gonna I'm gonna pass things over to Jose and Mohammed. And you guys, can

we can get us kicked off.

Right. Thanks, Dylan, and welcome to everybody. Hopefully. you'll get a lot of this webinar. Our goal is to help you understand better what FDA's requirements are for cybersecurity, for medical devices, and to give you a high, level understanding of the general concepts. And then we're going to go kind of into the weeds on a couple of concepts, you know. Obviously, you can't cover everything that's necessary for understanding cybersecurity in a 1 h, Webinar, but our hope is that you'll have a better understanding, and that you'll actually get some technical expertise that arises from this. So just kicking it off. And, by the way, if if you want to keep your email private on the certificate piece, feel free to just send it directly to Dylan or just to the host on the on the chat.

kicking things off. Why are we talking about this? So 1st of all, you know, cybersecurity is important, no matter what. But in the context of medical devices the FDA has raised the bar pretty substantially in the last year and a half in December of 2022, the 2023, Fedora was passed, which added section 524 B to the Food Drug and Cosmetics Act. and they provided a definition of cyber devices that was fairly broad, and commissioned the FDA to not only evaluate medical devices from the context of safety and efficacy which is a historical context, but also security. and FDA was given both the responsibility and the authority to, you know, to demand essentially from medical device manufacturers that they provide assurances of cybersecurity for their devices.

The scope that FDA chose to use is even broader than 524 c. So if you look at the guidance document from September of 2023, and you just kind of get a little highlight here on the slide. It says this guidance document is applicable to devices with cybersecurity, considerations including but not limited to devices that have a device software function. or that contains software, including firmware or programmable logic. And they go on to say, the guidance is not limited to devices that are network enabled. So what that means is. you know, they recognize the cybersecurity, even if your device is not intended to connect to the cloud, or even if it has no means that you can think of for connecting to the cloud even just the software. You load onto your medical device. You know, there's cyber security considerations there. So the scope is quite broad.

Also, around the same time they launched the Easter system for submitting 510 K applications to FDA. So you know, there's no longer paper based applications, and when you go to submit that, and you select that your medical device has software. There's about a dozen documents that you'll now need to upload. So about a dozen attachments. So we'll go over those and what they mean. And then finally, also around the same time, they announced that they would be enforcing or refuse to accept policy specifically around cybersecurity. So what that means is that before FDA begins their substantive review of your 510 k. Application or Pma, or even

an ide type of application. They want to see that the right documentation is in place around cybersecurity, and if it's not. they won't even look at the rest of your application. So, you know, to sort of summarize the importance of doing this correctly. You want to get it right the 1st time. 1st of all, you won't even be able to submit if you don't have the right cybersecurity documentation, just the Easter system won't allow you. Secondly, if you kind of just throw stuff in there, that's not adequate. FDA can refuse to accept your application without even looking at the clinical data or the design of the device, or anything else.

And then, 3, rd if you kind of pass those 2 gates, there's always the risk that upon a deeper review FDA will find that there are vulnerabilities that are unacceptable. Or there are other cybersecurity problems, and they might come back with questions that essentially force you to change your architecture, and that can be very costly. because that would mean you'd have to go back, re-architect the system, redesign it, go through your normal verification and validation. Go through your cybersecurity testing again. You know it could be a 3 to 9 month delay. So you want to make sure you get it right the 1st time.

The last point I'll make is that it's not just about getting FDA clearance, you know. Ultimately, we're developing devices that we want to be safe and secure for patients. Second point I want to make is that you know people the way the guidance is written, it's applicable. If you're submitting a new 510 k. Right? So if you have a legacy device, it's not necessarily applicable, except that if you ever need to go back to FDA for anything, they have the right, and they will request all of your cybersecurity documentation. But that means is that FDA is expecting you, even if your device is already cleared.

to be evaluating your system for cybersecurity. We've seen this happen. We've had, you know, a client who had an FDA clear device. and they went to submit a new indication for use. So they had new clinical data. Nothing was changing in the device, and as in the course of the review of those claims to expand the indication for use. FDA came back and essentially requested all of the standard cybersecurity documentation that's now required. So you know, if you kind of see in your future that you might need to go back to FDA, maybe, for like a catch up 510 k. Or because you want to expand indications or some other reason you might want to get rolling on ensuring cybersecurity now.

and the last point I'll make is that it's not just about safety. Of course, that's the most important thing, but it's also your company's reputation. If you've been following the news, FDA recently announced that there were some vulnerabilities found in a device company called contact. And if you just type contact into Google, I mean all the news stories are about this. So if you can imagine the reputational impact that something like this could have. If you've got a vulnerability that's discovered and publicized down the line, it can be very impactful to your business. So yes, patient safety critical. Yes, FDA, clearance absolutely important. But even beyond that, just consider that there's business risks if your system is not properly secured.

So let me start with 5 cybersecurity principles that FDA wants you to look at. The 1st one is that they want you to demonstrate a reasonable assurance of cybersecurity. and that language is a little bit vague kind of by design. FDA has to look at a lot of different types of medical devices, diagnostic therapeutics, home use devices, clinical devices, you know, different risk levels. And so they can be prescriptive on a device by device level. We think that the best way to ensure reasonable assurance is essentially to follow the process. So go through the full process incorporating security into your software development lifecycle and your product lifecycle.

And you should be in good shape. Second concept is to be comprehensive. So historically, you're primarily focused on your medical device and the impact it can have on patient safety, for example and efficacy. But now, in security, you have to consider also the environment in which your device operates. So if your device connects to a hospital network, for example. they want you to consider what impact the hospital network could have on your device. What impact could your device have on the hospital network? You know there's possibilities that an attacker would come in and hack your device and then pivot to attack the hospital network. If you've got vulnerabilities in place that allow for that. So they're asking you to not just look at your device, but the things around it in your analysis.

3rd is, they're saying you should be designing for security. So security is not something you can just tack on at the end. Security is something that you need to be thinking about as early as possible, and throughout the life cycle of the product. So, starting at, you know, very early stages in architecture, and then even post market, continuously evaluating it. So you have to make sure that you design all of the mechanisms in the system so that you can do that. 4, th you have to regularly analyze cybersecurity threats. So what that means is not just pre-market, but also post-market. You're going to be generating a software bill of materials, for example, or several Sboms, and your responsibility is to continuously evaluate those to see if new threats arise. You know there's a very good chance that your software is incorporating 3rd party libraries and 3rd party software.

And the good news is that you know there's good mechanisms in place for discovered vulnerabilities to make it to a central database. But what it means for you is that you need to be continuously looking at that. So there, there might not be a vulnerability associated with a library today. But then it's discovered. After your product is in the field, you have a responsibility to evaluate that and consider what impact it can have to your devices safety, efficacy, security. and then, lastly, aligned with that so kind of as a next step of that is designing your device to be patchable and updatable, you know, if if you do find a vulnerability, what are you going to do about it now? So you have some responsibilities around

around communicating with stakeholders. But you also have responsibilities around patching and updating your device so that you, essentially, you know, remove those vulnerabilities or control for them. By the way, I see a hand raised. We're gonna hold the questions till the end. But we're gonna we're gonna have plenty of time at the end for the questions, and if you have them you can type them into the Q&A section on zoom, all right. So integrating cybersecurity into the full software development lifecycle is the best way to design for security, as as I mentioned, is one of those principles we break that down into 3 general sections, one of them being security architecture, so ensuring that the device is properly architected, that you generate security views so that you can look at it at the highest level that you're designing for security, so that you're choosing 3rd party libraries, for example, carefully that you're choosing encryption. That is reasonable and logical that you're just taking the steps during the design phase, and that you're testing correctly for security.

And then, 3rd post-market that you've got a mechanism in place for monitoring, for new vulnerabilities and threats. patching and updating the software, communicating with stakeholders, etc. So across the full lifecycle of the product, you need to be considering security. All right. So I'll spend a good amount of time on this slide. This is a this is a critical slide. As you're uploading the attachments to the Eastar system. There's there's about a dozen attachments. They might have different names. You might see different names, because, you know, they don't call it a specific name for the document. They just say, provide documentation. That shows your security architecture views. So we call it security architecture views as the attachment, and I'm going to go through those 12. Give you a brief description of what they are.

That's what we've got on the right hand side of the slide on the left. We've got the process that we recommend. You're following over the course of the development and the lifecycle of the product. And those attachments should sort of naturally drop out of that process. And so I'm going to tell you about the documents first.st Then I'll tell you about the process, and kind of how they they relate. So, from the point of view of the documents themselves. FDA expects you to provide security architecture views. They recommend a few different ones. But you know, generally it's just any views for the architecture that describe how the data flows where vulnerabilities might be, what impact those vulnerabilities could have

next. They want to see your threat modeling documentation. So what process did you follow? What came out of that process? What vulnerabilities did you discover? And threats. Next is the safety and security assessment of those vulnerabilities. So both the vulnerabilities and the controls that you implement could have impact on the safety and security of the device. So you should show that next is the cybersecurity controls. So it it's you know, you're gonna have vulnerabilities. Pretty much. Any complex software system is gonna you're gonna discover vulnerabilities in the course of the process.

What matters is to make sure that you control it properly so that the risk that it brings on to the overall device and the outside world is at acceptable level. So they want to see in your documentation what controls have you taken to ensure that the overall risk is acceptable? Which ties into the next document, which is the cybersecurity, risk assessment? So assessing from a cybersecurity standpoint. What are the risks associated with those vulnerabilities next? Is a cybersecurity management plan so articulating to FDA. You know. What are you going to do when you discover new vulnerabilities. What does that process look like? Post-market? So just giving them a plan for how you manage cybersecurity pre and post market.

And and these are the documents. The color coding here is that you know, these orange or reddish orange documents is what we view as the documents that are primarily aligned with architecture. It's it's a little bit. It's a blurry line. It's not, you know, a hundred percent one to one. For example, that cybersecurity management plan is also related to post-market, but, generally speaking, these are documents that we see as being generated as you're going through your architectural design. Next, when you go into your design and development phase, there are other documents that will come out of that. So the 1st one is your software bill of materials. And that's really plural.

If you have multiple software images, you're going to have multiple software bills of material. So for example, your embedded software in the physical device will have an S bomb. Your, you know, if you have a mobile application or a web application or an embedded system application that might have a different Sbom, your Apis for your web interface or cloud that might have a different S bomb. You might have multiple microprocessors on the device that have different software bills and material. So you want to set up your tools to generate your Sboms in an automated way. And you know we won't get into the weeds of that today, but

happy to provide guidance on that at some future time. Next is your assessment of unresolved anomalies or your residual threats and vulnerabilities. Essentially, you know, it's recognized that you're not going to 100% mitigate every single vulnerability. But to show that you've reduced them to an acceptable range and assess what the impact of those unresolved anomalies would be. The next one is cyber security testing. So you know, there's different types of testing that you'll want to do during the design process and after the design is completed. So you know, you might be doing things like. you know, like static application security, testing over the course of the design. But you might also want to be doing things like fuzzing or fuzz testing during the course of the design. And then again at the end, so inputting into your software values that are not expected or not, you know. Necessarily, you know, the software is not designed to making sure that they treat those inputs in a proper way, and it doesn't put the system in in some mode that becomes insecure.

And then, of course, at the end, once your system is fully designed, you'd you'd go through like penetration testing and additional fuzz testing to make sure that there's no, you know, vulnerabilities that can be attacked, even though you think you've got the proper controls in place. Importantly, there, when you think about cybersecurity testing. FDA expects and requires that the testing is happening by an independent party so separate from the design team. And you know where there's no conflict of interest there so that can be internal. To, you know, large organizations. You might have an entirely separate test team that is under different management for smaller companies who usually want to hire an outside firm to do your pen testing.

Okay, so next, so we've got the cybersecurity testing. Next is your software level of support. So in, you know, including details on where all of the key components of your software how long they're gonna be supported for what your plan is, if if support ends for one of them your cyber security metrics. That's kind of a living document that will be updated once you're post market as you as you track the metrics. But, pre-market, you want to explain to FDA what are the things that you're going to be looking at post market security risk management report. So again, like, you know, evaluating what the risk the overall risk is.

And then cyber security labeling so that that relates to your instructions for use. Primarily. So essentially, you know, security. There might be some responsibilities that lie with the end user. And Fd wants to make sure that you're properly explaining to that end user what the expectations are on their end. And you know, if there's an incident, what are their responsibilities? What can they do? Who can they contact those kinds of things? So those are the outputs of the process. Quickly, just going through the process itself. you know, in software development and product development. You're gonna start with design inputs. What are the requirements, you know, and in particular, to fulfill the indications and intended use of the device.

you would create an architecture for the system and an architecture for the software. And from that extract the security views. So these are views that are specifically designed for security and Mohammed's gonna go through some of those in the following slides. performing threat, modeling against those security views, performing risk, estimation, and evaluation and then implementing controls for those threats and vulnerabilities. And the reason we show this as a loop again is because. you know, if you discover that you've got some vulnerabilities that you need to control, for you might need to update your architecture to incorporate those controls, and then you'll want to go ahead and go through that cycle again because controls could introduce new vulnerabilities. So it's it's a cycle. You're going through it until you feel like your architecture is solid, and at that point.

whatever residual threats and vulnerabilities remain, you would document. and then it's a good time to, you know. clean up your management plan. You know your management plan is something that you could start earlier, but you know, at the point where you feel like your architecture is in a solid place. That's a good point to really flesh that out some more. Then you would move on into your design and development phase. We show this somewhat linearly. If you've done product development in the past, you know that it's not a linear process. During the design and development phase, a new requirement might come in, or you might discover that you actually have to change your architecture to ensure security. But, generally speaking, this is this is the flow

in that design and implementation phase. Again, security is key. There being careful about the components that you bring in, like those 3rd party libraries or 3rd party software open source software. It's acceptable to pull those things in. But you probably want to analyze them even before you bring them in to look at what vulnerabilities are are reported on that once you feel like your software is completed. you generate your software bill of materials and perform an analysis on that. And again, Mohammed will go into a little bit of details on that you'll you'll evaluate whether it's acceptable or not. If it's acceptable, or let's say, if it's not acceptable, you might go back and change a library. For example, you might see that there's an alternate library that achieves the same function and doesn't have vulnerabilities associated with it, or significant ones. So you might update it at that point. But once, that's all good, and you feel like it's good. You might update your residual threats and vulnerabilities with anything else that's new.

Move on to cybersecurity, testing again primarily at this phase. That's fuzz and penetration testing on each of the components and then on the system as a whole. if anything fails, you know, obviously you'd come back and update your design to to fix that. But if everything passes now, you're in a position to generate your your report. and at that point you're pretty much ready to launch your product. Now, post market. Once the product's been launched, you're going to want to do continuous analysis of your S bombs and periodic retesting of your system. FDA doesn't give explicit guidance into what that needs to be. 6 months is a number that we see thrown around. You know it's reasonable where you would go back and do additional fuzz and penetration testing. But the thing that you're doing continuously is evaluating your Sbom to see if there's new threats and vulnerabilities.

if there are any you track them, you'd go into your management plan and see how you're going to manage that you'd go back and evaluate if those vulnerabilities have a significant impact on the security of the device. You would patch, you would capture new security metrics, etc. So that's at a high level. The process that you would follow to ensure that your system is secure and that you're generating the documents FDA expects I'm gonna pass it over to Mohammed here in a second. He's our Chief Security officer, and he's gonna go into more details on the security architecture phase. You know, we it's about what we think we can cover in in the time that we have allotted. But 1st Dylan is going to briefly put up a poll.

Just to help us understand what your needs are at the moment.

Okay. I launched the poll. Does everyone see it should be right there for you to enter your information into? It's just 5 questions. feel free to respond and knock through it, and then we'll get going here in just a minute. Thanks for your input. So far, Jose. It's really helpful. thank you. Everyone for participating in the poll.

So we'll give you a minute here to look through that. and then I'll hand it over to Mohammed.

You can move to the next slide whenever you're ready.

Yeah, that's a good idea. Hey? We're doing well on the poll. Input, if you wanna get going.

Yup, okay, I'll get started because of the time. Hi, everybody. So I am going to focus our discussion really around this phase of cyber security around this loop. Of architecture, modeling, risk, estimation and cyber security controls. And you can see there on the left hand side, on the the main outline on the left hand side. There is obviously the other work that's down below which we're not. Gonna I can touch on it a little bit. But I'm going to spend a long amount of time there. Because there is a lot of detail in this architectural phase. I I do want to point out that it. It is really very important that you spend the appropriate amount of time upfront. Going through an identity. You know this, this beginning loop, because really, that's going to set the pace for your entire project. It's it's going to be the the foundation upon which everything is built

ideally. You know, you're you're following a 62, 3 or 4 type of process for the development software. And what we want to do is integrate the cyber security activities as seamlessly as possible with the normal medical device development activities. I know Jose mentioned S. Bombs earlier, and I'll sort of tie into it here? So what? What are fundamentally the the S bomb software, those materials they are really pulling in and describing all of the constituent pieces, particularly ones that are important and ones that you don't control, that you're bringing in from 3rd parties. and that establishes the dependency chains for your entire software. Put another way. It essentially defines your threat surface because your entire software essentially defines that. So having having an upfront understanding of what type of

items you want to bring in as early as possible, allows you the opportunity, or, of course, the opportunity to, as I mentioned, to perform early analysis and determine. For instance, if I have a choice of these 3 possible suppliers. Okay, which one probably has the least dependencies, or least vulnerabilities. When I bring them in, because the the last thing you want to do is not think about that. Proceed with your project. Get into design and development, pull all kinds of 3rd party pieces in, and then suddenly discover you have an S bomb with 5,000 items in it that you now have to basically pay attention to. You'd be, you'd be much better position to have a hundred dependencies than 5,000.

So so that's where sort of the the sort of nonlinear part of this whole flow is is that you know it is possible certainly, to come back and revisit some of the choices, and and we would encourage you to do that. Don't go down a path where you're you've suddenly found yourself with a huge amount of burden to to manage, because that is going to live with you for the lifetime of the product. And we again, not touching so much on post market, but recognizing that threats and vulnerabilities will will be discovered throughout the lifetime of your product. And if you have a very large net surface they could be happening continuously, which means you're having to not only monitor. But react to those by changing your software updating, pushing out patches so it can be very disruptive if you end up with the wrong type of footprint.

So with with that in mind, as I said, it's it's probably detrimental to proceed too quickly through through this flow. You you wanna upfront, have decided sort of what? What are the appropriate types of views that you wanna show for architecture? I'll touch on that in a little bit. Explain that bit further. Similarly, when it's coming down to risk analysis, decide what techniques you want to use, what what threat, modeling approach do you want to follow? There, there are some alternatives. So you want to look at them and decide what makes most sense for your type of project. When it comes to risk estimation. Again, there are different methodologies that you can use. I'd recommend. Just pick one and and just stay with it. You know you don't want to be changing. You're changing the type of methodology using. It'll give an inconsistent set of documentation for the reviewer. Basically. So you really want to have something standardized.

So you know what? Again, as we get down further, I'll sort of explain parts of this loop. The key sort of takeaway I have from this is, you know. Try and think of security first.st That's really important. It's really very challenging to try to to go through this really, quickly, jump into design and development, and then discover vulnerabilities that you have to then go back and change architecture to support it, so it can be very disruptive. Approach. So spend the right amount of time upfront. Think it all through. Identify, you know the the threats that you're trying to mitigate and then move forward from there.

Okay. Next slide. Jose.

Yeah. And and the only thing I would add to that Mohammed is just, you know. Keep in mind that the security portion of this is in the greater context of safety and usability. Right? You always have to keep in mind that if you're incorporating new security controls, you have to consider what impact that has on on same.

Particularly. Yeah, and I'll I'll touch on that as well. So so yes, these things all in all of these things interplay with each other. So you you obviously don't want to have a design that's so security centric that it becomes unusable. And and you can see ways of getting there. You can have controls that get you to the point where it's basically completely unusable. And and it's not just an unusable from a perspective. Obviously, that's bad for a medical device, but it's also bad from a security standpoint. Because if you, if your security is so onerous and we hear anecdotal stories all the time of this, if your security is very onerous.

users will find a way around it which actually is completely circumvents the purpose of the security. So so good security design is really going to be seamless and ideally doesn't impact usability. But you need to make sure of that and and isn't so onerous that that individual users just simply decide to circumvent it. I'm sure you all have heard examples of people that, for instance, you, you tell them, imagine the situation where you have a security policy which forces you to change your password every day. What's going to happen with that? People are just going to write their passwords down on a piece of paper and keep it next to the device, which is, which is complete, which means your security is completely useless.

That's just simple example. Okay, next slide, Jose. Alright. So views. And I know we said upfront. You know, views are important and what our views, and you know, from an architectural perspective. From architectural point of view, a view is just a perspective. It's a perspective of a particular stakeholder, and you may be familiar with different kinds of views that you have in architecture already today because they exist. You could have logical views, process views, deployment views component views. And what we're doing is basically adding to those views the security perspective. So there's a handful of different views that you can use to show the the security aspects or the security perspective of your system.

We start off with. And I've I've chosen just 2 of them to show you. But there are. There are several others you can choose. But the global system view in my mind is really very important, because that that gives you the context of your entire system. And it's really it's really, I would probably say, this is one that is not optional, that you really have to have this because this this sets the scene. This sets the environment within which your medical device operates. And, as Jose kind of pointed out, this is a little bit of a different positioning that FDA is taking. And and rightfully so is that functionally, you're really concerned from an architectural perspective, with your device, with the medical device itself and the boundary of the actual medical device.

But from a security point of view, that's not enough. You you need to know, where does your how does your how does your medical device fit within the larger landscape in which it's deployed? And the global system view gives you that the global systems view purpose is to show you the the medical device and adjacent adjacent entities that it can interact with. And it's important to recognize that. And in this example, here, I'm just choosing a simple sort of example to walk through the the rest of the slides. It's a some something like a patient, worn, vital signs monitor, for instance, which is connected to a cloud server. We're going to have a physician app which can be used to to modify the monitor's behavior. So making it part of the medical device.

And then a patient apps. That's a physician app and a patient app. That's just going to view the data. So we're not. We're actually pushing that outside of the medical device proper boundary and and considering it a medical device data system, since it's only viewing the data. So so you see here in this one diagram we're able to show both the medical device entities that that make up the medical device. the the Mdds entities as they may exist, and then anything that is not medical device, but interacting with it. The router, for instance, that your medical device is connecting through is not a medical device. It's just completely non has no medical function, but it is. It is a. It is a piece of equipment that your medical device will use.

And so so really, that's the most important thing. Obviously, you could have more complex systems than this. This is a relatively simple one. You may need to even break your Sys global system view up into multiple multiple diagrams because there's just too much to put on one. So you'll have to gauge this based on the type of system that you have. Okay, next slide, please, Jose. another view that's also important. And this this sort of you know at a glance, almost tells you not tells you everything, but tells you a lot about your threat surface, and that's really the the point of it. generally it's called

the multi Patient Harm view. That's how it was called out in the guidance. But what it's really getting at is trying to understand the degree of connectivity in your system and the degree of exposure your system has to a malicious threat actor, and there's a good high correlation between systems that are highly connected and and have exposure like in this case. So you know, if you have devices that are accessible on the Internet, if you have apps running on devices. These are all attackable surfaces. And so in this example, all of these things that are connected, the multiple patient devices, the various applications, and the cloud server itself. Obviously, all of those are.

you know, possibly possible exploit paths for an actor, and the idea is to capture those so that you have a clear understanding of where your defenses need to be in this case everywhere, basically because everywhere everywhere is attackable. So you know, as you as you go through this, your focus is fundamentally like, where where are the points through which you can pivot to hit multiple patients? And in this case, really any. Any attack coming in through any source can ultimately pivot through to to the central server, which is your your sort of main hub. That's where an attacker will ultimately be trying to reach, and if they are able to reach that from that position they can now hit any of the actual patient types of devices.

So you know, and that's common in any, in any, in any system that has a centralized point of control. That really is the the ultimate place where you need to provide the protections. And and again, the security is oftentimes, you know, not just one thing, it's a it's a it's a it's a series of of security rings, for instance, that you can create to to help thwart attackers because you're that's really the goal is you're trying to make this so onerous on an attacker that they'll just avoid avoid trying. I mean, I always say there's no such thing as basically perfect security unless you're willing to take a device and stick it in a vacuum up in space and not allow anyone to touch it. Maybe at that point it's more perfect. But any usable device can be reached.

The question is, what's the cost? What's going to be the cost for an attacker to to penetrate your system and and start to do malicious things in it. You know. And what is the cost that you're going to have? What's going to cost you as a consequence of that. So it really does come down to financials oftentimes. But you know that's a constantly evolving game as well to consider, because. you know, costs that attackers pay is actually reducing the the cost of attacks keeps coming down. And so, you know, you're having to do more defenses, because, you know, attackers are getting better tools, better techniques. And so it's it's just a it's. It's almost like an arms race. You're you're always trying to fight off the the latest attack techniques. Which is why, again, it's important to keep your threat surface small. What I mentioned at the beginning, the smaller your threat surfaces, the less area you have to defend. So the less costly it is to defend it as a trade-off.

Okay, next slide, all right, digging down deeper. So we're just descending down the sort of. And this normally would be how we do have our views, and we just start taking parts of our views and breaking down even further and just adding to this. So here we've gone down a level even lower. So now we're threat modeling. We're past. We're past the overall architecture and in threat modeling. We're really just trying to dig deep into our system. And this is, for instance, a stride based approach. There are other other approaches, too. But, the goal here is that you are trying to look at all the different constituent parts of your system. Understand the flows of data and determine how actors can penetrate parts of the system and

and cause damage. Right? And so, you know, stride as a modeling framework gives you, a vector of 6 6 basic types of attacks that that you can have on the various entities within your data flow. And you're essentially going to go item by item and see what type of attacks could be done for in a in a particular part. For instance, in this diagram here, for measuring the vital signs, or, for you know, the transferring data to the cloud, what what types of attacks can be can be brought on by a malicious actor to try to cause damage in your system. There are other other forms, and just to mention them really quickly, you know, attack trees, for instance, is another type of framework where you're focusing on typically more typically in complex systems, of a single attack and its objectives. What is it that an attacker would be trying to do, and then breaking that down. It's also good to look at. For instance, mitre has a database, the att and Ck

database, which has a lot of the sort of commonly known tactics and techniques that that threat actors typically use. It's it's good to periodically look at that sort of understand the sort of the state of the art of attackers. But at the end, really threat modeling is a is is a pretty exhaustive process where you are going through and pulling apart your entire system, to understand all the flows of information going within, and be able to from that identify all the possible types of attacks that can happen in your system. So the goal of this having documented your flows is really to come up with your list of threats. That's really what you're getting to. So you've itemized all the threats that you can see possibly happening at the different parts of your flows next, please, Jose.

and this is an example of how of this output you get. So, having gone through the process of looking at this, and this could be, you know, hundreds of items it could be, you know, multiple dozens of items again, depending on the complexity of your system. And and the goal here is, you're really trying to itemize every threat. And I I do. I wanna point out that you know, it's it's probably not good practice to dismiss threats outright. And I I've seen that before. And it, you know, you really don't want to do that. You you want to be complete. You want to basically record all of the possible threats and then analyze them and determine that they, for instance, are not they're not attacks that you are

going to score highly when you do the analysis, because, for instance, they're very local proximity. Maybe maybe they're an attack that can only happen if the attacker literally has contact with the device. That's fine. You you put it down and and you can rationalize, and it will come out of the the scoring analysis that because the attack has to be in local proximity, they will score low, and and you can at that point say, you know, this is attack is is an acceptable risk and move forward. But you know it's not good practice to just ignore attacks because you believe it's not possible. You know I I you know, I use the simplest example of we're we're talking here. A lot of just, you know, attacks that. That you see from a device manufacturer standpoint. But remember that what you take for granted an example that would be like credentials that a user uses.

You know, those types of things could be achieved by an attacker through other techniques, like like phishing attacks, for instance. So you know you, you may have, you know, strength in your defense by saying, I have a, you know, username and a password set up for every user, and you know that that protects me well, it only does as much as you know, they're not going to be vulnerable to a phishing attack where those get given away. So you know again, it's good practice not to dismiss threats, but rather document them. Make sure that make sure that you. You're clearly showing that you understand your system, and where your vulnerabilities are, and then determine what you're going to do about them. So so here, this is, this is really threat, identification early, and the analysis of the threats. And then the evaluation of the threats in terms of scoring I mentioned before.

You know, there's probably 2 good scoring systems out there. Cvss. Which just moved to 4. 0, fairly recently. And then OS has also their own Sep completely separate kind of scoring technique. And and what I'm showing here is just we typically would go through. Look at each threat, form an analysis and evaluation on threat. do the scoring using Cvss, and and you see, the Cvss outputs a vector which basically characterizes the actual threat itself. And then provides you the score that actually comes out of this in the calculator that Cvss provides. And then the score is what actually identifies the risk level. So risk levels are typically critical, high medium and low. Here, they'll just they happen to all be in the high and critical range, but they could certainly be a lot lower than I would expect that.

So yeah, so so this is this is the basic analysis I mentioned already, so other than distance, the complexity of the attack will have a variance on its score. The effect of the attack on the system itself, and and the information within will have a variance on it. This is not a risk based. This is not a this is sorry. This is not a probabilistic analysis, and that's something that the guidance specifically calls out. You should not do so as compared to, for instance, a Dfme at the functional level where you are going to look at probabilities of failures in in this evaluation for cybersecurity. We do not use a probabilistic approach. It's not about what's the percentage chance that an attacker will attack you. You take for granted that if a vulnerability exists, an attacker will attack you.

What you're really trying to do is characterize and evaluate the threat as a threat itself, in terms of, as I said, distance from distance of attack to the to the point of attack, the complexity, and other conditions that that vector that I show you there represents the different axes of classification for a threat. That that ultimately yields you the score from that threat. Okay.

More like the exploitability. Right? That's the.

Exploitability. The, you know, kind of sort of the damage you can do within the system in terms of exposing information or manipulating information. These are all part of what you would consider as a Cvss. Has has an entire. You know we're touching very quickly on all these various points. You can go to the next time we're touching very quickly on all these points. But you know something like, for instance, Cvss, there's a lot of documentation on 1st website, and they have tutorials. And you know explanation in detail of how their analysis is performed. So you know, same thing with threat modeling there. Each of these things has its own kind of more detailed descriptions. And

so past the analysis point. Now, we're at the stage where okay, we've identified all of our threats, we hope. We've scored them. We start with the most most important ones at the top and start looking at what are the controls. And and I've just listed here in a set of examples. You've taken a threat, and and you certainly may come up with multiple controls. There's no reason that there's just one control there. You may require a multifaceted mechanism to help control the threat, and that may be very, very appropriate for highly, for highly critical threats like like the one shown here. So so you would come up with a with a set of

of controls. You you could. You don't have to necessarily implement all controls. You may decide. Some controls are you know, preferable to others. You know. Example in this one here is. I've added here like a rollback mechanism, may may seem like a reasonable control, but you gotta be careful sometimes, because an example is in rollback. There's actually a rollback attack. So you could introduce. So not only do you have anything you mentioned at the beginning that controls interact with the with with other aspects of the project so you could add security controls and impact usability. Well, there's actually even situations where you could add security controls that cause you new threats. The control itself is a threat, you know. An example is, I had a control. Another example of rollback. I had a control that says I need to be able to update in the field. But maybe that update is not necessarily secure.

Well, all of a sudden, you've now added a new threat, which is, someone can use the update process to attack your device. So now you decide, okay, now, I need to make that secure. And and that adds adds additional complexity, but it has to be done. So so, my point being that it's not done in isolation. You you have to review these controls with respect to other aspects of the project, including the security itself. But but hopefully, you'll identify a set of controls and be able to select a control. The appropriate controls to mitigate all of the all the threats, or at least to the point of bringing them down to to an acceptable risk level.

All right. Next slide, Jose.

Good. I think that's it. That's it. Yeah. And I mean, you know, just in the details of this example with a malicious firmware update. You know, you can see how the controls relate to that firmware update right? So code signing and secure boot encrypted update channels. So just ensuring that the controls that you're implementing help. Reduce the the exploitability or the impact of a particular vulnerability. So that's great. Thank you, Mohammed, for.

Actually let me just mention one thing, because I know you mentioned it earlier on about you know we have. We're in a loop, and sometimes people would think like, Well, when do I stop going around this loop? Because maybe I just keep going around forever and it and it's not actually really a forever loop. It's if you think about it. If you go through the loop and you reach this point and you don't add any new controls. So basically, you've gone through. And there's no other changes. That's probably a point at which you can say you can move on. So really, that's in my mind. That's sort of the that's sort of the the tell right if you if you're able to. If you run through the whole loop and you reach this point, and there's no new controls added.

You're probably you're at the point where you can move on. If you add new controls, you just have to go through the loop again because those controls are in potentially impacting your architecture because you're adding things. And then you just go have to go through again. But but you're really reaching. You want to reach the point of stability where you've you've done enough to decide. There's no more changes needed. Okay, I'm done.

Thank you. Mom, so yeah, to wrap up here. I know we've covered a lot, but there's still much more to cover. There's a lot involved in cybersecurity. You know, as Dylan mentioned at the outset, I'm Jose Borges. I'm the president of cybermed. Got a Phd. In electrical engineering computer science from Mit, and 20 years in the development of medical devices, 8 or 9 years in cyber security. Mohammed's our Chief Security officer. He comes out of the world of communications and security. More than 35 years in cybersecurity and software development has worked on super high level security systems for the Dod, the Nsa, the CIA etc.

It just has a wealth of experience here. That's 1 of those things where you can understand the process. But as you're going through it really having the expertise and experience is critical. So we always recommend to people to bring on people to the team as either employees or contractors that can help you navigate those tricky questions. And then Andres, our chief operating officer. He's got a master's in management from Harvard, and he's he's worked in multiple industries that were security is top of mind aviation, it security medical devices. leading software development teams in the Department of Defense, for example, etc. So this is the leadership team. We've got a great team. Also that works with us to help you make sure that your device is secure and is properly tested. We've got about 10 min, and we do have a few questions. If you have questions, feel free to drop them in zoom, you should see a kind of a section that says QA. And you can type them in there.

So I've got one here. Mohammed. 1st one that was sent was, what do you mean by reasonable assurance of cyber security?

Yeah, that's a really good question. Actually, it's 1 i asked. The FDA. So reasonable is as determined by FDA so effectively. You've got enough in my mind. You have to have enough information to demonstrate to FDA to an FDA reviewer who's just going to look at the documents, not going to talk to you. They're just going to look at the documents. And they're gonna basically get they? You want to give them the impression that you understand your system. Well, you've been rigorous in applying the the process and techniques to identify threats and have appropriate controls, and that you're and that you have all the things needed.

so that you are in control of the whole thing, and I think that is reasonable. But it's not really my. Unfortunately, it's not my. There isn't a hard and fast rule. It's not my choice of reasonable. I think we're always sort of aiming for being, you know, a little bit more thorough than perhaps we even feel we should be, because that will demonstrate to FDA that we are in control of the whole thing. But at the end of the day. It's an FDA's reviewers choice as to what is reasonable.

And importantly, you just want to provide rationale for why you follow a particular process. Why, you make certain decisions. and and, you know, take into account just the risk level of your device. What is the impact that an attack would have on overall safety? For example? Okay, I've got another one here that says is doing fuzzing mandatory.

I, I would say, doing penetration testing is probably mandatory. I think that doing fuzzing would be really good. Typically it may depend. It's sort of an it depends. Answer. It may depend a bit upon the risk level of your device and the type of harm that it can cause to a patient. I would tend to say that devices that could, for instance, a therapeutic device that could cause serious harm to a patient. You know you might want to be more stringent in how you apply and do pen and fuzzing, and just to make sure that make absolutely sure that there's no circumstances under which, because the device really fuzzing is all about making the device do something you don't expect. So if you're going to do something to a device that you don't expect, and as a result the device can cause serious harm to somebody, then you probably absolutely should be doing it, just to make sure that that doesn't happen. If if you've got on the other side a, you know diagnostic device that maybe isn't even capturing vital signs

that may be less of an issue. It may. It may be that you can demonstrate that there's really no need to do fuzzing, because, you know, there's no harm gonna be caused in the case of a failure, and maybe your failures are very limited anyway. So.

I go as far as saying that you know, whereas pen testing is very focused on cybersecurity. Fuzzing is cybersecurity, but it's also just the quality of your software and your device. You know, you want to know that if a user inputs, you know data that's not expected, that device is not going to break, or you know it's not going to malfunction in a way that that is undesired. So FDA does, you know, explicitly list fuzzing, not as saying it is specifically required, but it's like they they require cyber security testing as adequate for your system. And but they do call out explicitly, pen testing and fuzz testing. So you know, it's a good hint that they probably do expect to see it. And honestly, it's just a good practice to make sure that your system is robust.

I mean no one.

We're doing more testing.

Yeah, that's true. And.

So it's.

Another one here that says, if your pen test identifies high, low, and medium issues, is it a requirement to close the low one as well.

It depends. Again, I with pen testing particularly. Here's the challenge with penetration testing. So with penetration testing, you're really concerned about leakage of information and potentially penetration to the point of takeover of a system. So you want to be a little bit careful with that, I mean, I I would be a little. It depends on what it exactly is. So when you're saying low, it's what is the low? It's? Is it low leakage, or is it low? Takeover? What exactly is the low but I I would tend to be a little bit careful with with any penetration vulnerabilities because of the following, you may do a pen test today and reveal some low vulnerabilities. But remember, attackers are constantly improving their techniques.

Systems are constantly being, are evolving. And so what may be low today may suddenly become a more serious threat down the road. So I I would tend to want to make it as clean as possible, and not have any any known issues, or at the very, at the very least. And this is another technique we can use at the very least, even even if you decide that there's something that's low and not much of a threat. And it's not something that you need to worry about today. I think it's okay to to rationalize that and have, for instance, a plan to say we're going to address this in our next release. You know we're gonna do another release in 6 months time, and we're gonna be buttoning this this up. So you you don't necessarily have to have absolutely everything done day one. If there are things that you know that are are

very fairly inconsequential. But you feel like, yes, we do want to take care of them. But we're just not going to take care of them now, just at least, at least put a rationale to that and say, like, I said, we will be addressing this in a subsequent release, and that then gives gives FDA the indication that yep, you, you know you're on top of this, you understand? You've prioritized, and you are going to deal with these things. You're just not gonna necessarily deal with them all. Now.

So we only have a couple of minutes left guys and want to give you a chance to answer one last question, but just a reminder that the recording and the slides will be available tomorrow to everyone who attended. Thank you, everyone for attending. and Jose and Mohammed, if you have a last question. You want to jump into, feel free anyone who answered the question not anonymously. We will follow up with you. If your question wasn't anonymous, and we're happy to stay on after. If you want to keep talking, go ahead.

Yeah, no, we got a ton, a ton of questions. This is great. And yeah, we'll we'll definitely try to address on these. And, by the way, there is, there's another poll that we're gonna do. On what topics are there? Or was that already included in the original poll?

It's in the survey, so you'll get a link to it when the event ends, or when you leave you'll get a link to fill out the survey. Please complete the survey. It will be very helpful for us, and thank you to 102 people who completed the poll.

Yeah, wonderful. Yeah. So so we're we're gonna try to do these on a regular basis to help demystify a lot of these topics. So if we don't get to your question now, my, you know our, our email address, phone number and web address is showing right now. Feel free to shoot us an email, we'd be more than happy to jump on a call and and explain some of these things. But here, just to tackle one last question here. Somebody asked for s bomb. Do I need to generate by using tool and mitigation? What do I need to submit for S bomb.

What you need to submit has to be Fdr specifically asking for machine readable. so that's I. And they call out Cyclone Dx, which is, I think, personally, I prefer that format. But Spdx is also another format you can use. So it needs to be machine readable. They need that 1st as far as generating it is concerned. I really would recommend that an S bomb is built into your tool. Generation is built into your tool chain. Only I mean. if you have such a simple system that you really can call, pull out your S bomb and and create it manually. Okay. But remember that you're going to be potentially doing builds, you know, not just this one time, but you may be doing subsequent builds in the future that you'd want to update your S bombs for. So you really are better off generating it out of your tool chain. And honestly, most

oh, I'd say not most, at least the the newer development environments that exist for the types of medical devices that I've seen, all the tool chains typically can be integrated with s. 1 generation in a relatively straightforward manner. Some tool chains are a little bit harder to to manage, and there are some ways around that. But but I would really recommend, and that's our preference is always to build it in. But you know they don't tell you how to do it. They just say they want the output to be machine readable. And that's the that's the only really obligation is to provide a machine readable as far how you do. It is not. They don't care. But from a from an overall project basis I would say it would be highly recommended to integrate it.

Yeah. And it's worth the investment upfront to try to. You know, as Mohammed said, just build the tools into your Id, so that it's continuously being updated. This is, it's trickier for legacy products. Maybe when the software is fairly old and design environments fairly old, there are some open source spom generation tools, for example, that can kind of plug into to you know that are not directly designed for the Id, and you can use do the analysis post facto on the source code. But where possible, it's best to incorporate it into your your design environment. Alright, folks, we're out of time here. Thank you so much for attending. We hope it was helpful. Please reach out. If you've got any questions we'd love to chat and love to help. Thank you.

Thank you, Jose. Thank you, Mohammed, and you can subscribe for more insights at medtechleadingvoice.com, and look for future events from us there, and thank you so much to cybermen today for participating. We hope you all have a wonderful day and look for the follow up with the slides and the recording tomorrow have a great day to everyone.

Thanks. Everyone.

Fine.