MedTech Cybersecurity Masterclass for Connected Devices and SaMD

Hello, and welcome everyone I'm Shawn Smith from Med Tech, leading voice here with Leon Dorn and we are here to talk about cyber security for medical devices in the Us. Especially the East. Our cyber security requirements. Before we get started, a couple of housekeeping notes that I'm gonna drop into the chat. Please ask questions using the QA. Button or the chat throughout start by dropping where you're calling in from into the chat button and so that so that we can figure out who's here and then the recording and slides will will be sent to all of you tomorrow, approximately 24 h after the event. You'll get an email from Zoom. That says, Here's the here's the

link to the recording and the chat. We will try to get to all the questions today, but if we can't, we'll try to follow up with you after the fact. I'm gonna drop the contact information in. And then I just have final one sentence thing to read from our sponsor. Singular security. The sponsoring. This seminar offers a streamlined cloud security solution for med tech devices. Addressing the persistent threat of cyber attackers. I'm gonna drop their contact information in and please. yeah, please, please look into what they have to offer. Oh, and one more thing if you're not subscribed to med tech, leading voice. Please do. So just go to Med tech leading Voicecom. Thanks.

Leon over to you. Yeah.

Great thanks for the introduction and thanks for the setup and for the invite for this webinar. So today, we're going to look at the cyber security for medical devices in the Us. And I think what's interesting to note is that a lot has changed since the recent introduction of the e-star, and the main changes are, do well, let's have a little bit of a dive into where the changes are coming from. So if you look at it.

About you, before.

Yeah. Oh, yeah, good. Maybe that's it. I do have an introduction slide. But it comes a little bit further.

Okay, okay. I didn't mean to interrupt. Go ahead.

No worries. I'll get on it. So maybe for those who don't know it. Back in December 2,022, there was a Consolidated Appropriations Act, which actually went into effect in March 2,023, that laid out additional requirements with regards to cybersecurity. The FDA responded, drafted a cybersecurity guidance which was issued by the FDA in 2,023 as well. Then the final cyber security guidance got issued by the FDA for Qsr. And submissions and the East are became mandatory back in October, 2,023, last year. So that's last year, and just in February and the East our version 5 and live, which is not a mandatory full month. There's no other option anymore for submitting a 5, 10 k. Unless you have a clear rationale, and it's agreed mutually with FDA that you'll use a different format.

One thing that's interesting is that just last week new guidance draft guidance was issued by the FDA. Which relates more to the post market requirements for a cyber security is worth having a look at, and I think it's open for commenting. So a very brief update on why we're in this webinar today. So if you look at the differences between Version 4 and Version 5 of the E. Star. Clearly, version 4 already required the risk management report with a clear cyber security assessment to be delivered as part of the 5, 10 k. And a cybersecurity report. Then, if you look at version 5 again, also the risk management, report

and fret molding end to end, cyber security risk assessment as home for those who are unaware of what that means. It's a security bill of materials. also one with all the end of life dates, then one with the vulnerability, security and safety risk assessment. then also an assessment of the unresolved anomalies for cyber security. the cyber security metrics. What that means we'll touch on it further on. Cyber security controls the architecture views. the cyber security testing. the cybersecurity labeling and the Cyber security management plan. And now, when you compared it to in terms of the deliverables. For the

for the East Star is a clear why, we're here today, and you can see that there's really a very strong emphasis that has started with the FDA, and they're really clearly asking for a lot more to be delivered as part of cybersecurity. And again, this is mainly driven from regulatory changes. But also clearly, I mean, if you look at the recent years, a lot of devices are moving to so far, components connected components and the cyber security threats are increasing in the market as well as we see today. So it's not that strange that the FDA is putting up the bar. So if you look at it, the cyber security right now it's

and I find that interesting. It's the biggest numbers of deliverables at all in Eastern Version 5. So in any order of the deliverables hasn't been that extensive is supported by extensive guidance. I already call that, too, but there's a lot more guidance available with the FDA especially in the East, our form itself. There's a lot of boxes that you can click on with for further information that provides a lot of information and details of also references where you can look that up. And I would definitely recommend anyone to to do that, because it makes it very clear what what is demanded by the FDA.

And clearly, cyber security is no longer an optional deliverable for for so far as a medical device, or even so far embedded within a hardware medical device. So a little bit about me. So I found that car I/O care is a independent medical device consulting firm. We help companies specifically in quality of affairs, but also regulatory affairs, and to some extent on the information security. So information security here is more in the sense of implementation of information security management systems for Isa. 27,001, and then knowledgeable with regards to software medical device and also software medical devices driven by AI and active contributor to Iso and IC Iec standards. So over the last.

I think 4 years I've been a member with the aiser community specifically on sc. 42, and ch. 21. Those are the standards committees that develop standards around artificial intelligence, and then also within Tc, 62 or Tc 62 is developing for those who are unaware specific standards with regards to medical device software and those that use AI. So there's currently, I think. a few standards on the development there, specifically aiming to address AI components in 2,023, I started a consulting firm. And Nope, that's a bit of my background. So for the agenda of today we'll start with getting a little bit more into detail on prep modeling.

Then we'll head on to cybersecurity testing the Risk Assessment bill of materials, the Risk Management report and the cyber security management plan and maybe to kick it off. We'll dive immediately into threat, modeling.

Before we dive into threat, modeling.

But it's.

Launch the first poll question just so that we can sense of launch hopefully, this will work. Can everybody see it? Can you see it. Yes, people are answering the poll question, so go ahead and keep talking while they answer the poll question for the next minute or so.

Yup. So getting back to fret modeling again, Fred modeling has been around for quite a while. It's not new. It's already described in other in other industries as well. It's never been that strongly push forward to to medical device manufacturers in the past. I know. Fda was keen on getting sub security information. How well it was actually following the frap. Bombing was maybe less relevant than it is today. Because right now, really, FDA is asking you to submit the fret model the Fred Mullen. And this is from the OS website. so structured representation of all information that affects the security of an application. And in essence it's a view of the application in this environment through the lens of security. We'll touch a little bit more clearly on what that exactly means and how that needs to be implemented.

Fab modeling is a process. It's not necessarily just a deliverable. So it means that you need to start blending it. And you need to describe somewhere what that planning looks like, how you do this, how you says Fred, moving. You can do this through procedure or a specific fret modeling plan, or you can add a section on your risk management planning to describe how you're going to do your prep modeling first. And I think this is with a lot of risk management and also with other processes. Clearly, you need to scope what you're going to buy your threat modeling to. And we'll get to that, because this is in specific. The scope can be a little bit broader than what you might expect.

The assessment methodology and the rationale. So, for example, there's different techniques that you can use for fret modeling, for example, stride is the most commonly applied one. But you also have kill, change tech trees. When you read the guidance as well as provided by the FDA. In some circumstances just using one of these methods might not be sufficient. You might want to consider using a combination of the methods. Or you might wanna deciding, using just components of those methods. You need to define your scoring and acceptance criteria similar to risk management. You need to assess the entire security lifecycle. So when you do your planning, make sure they could describe what the security lifecycle of your device would actually look like.

and also consider who is involved in a fret modeling exercise. Clearly at a as a medical device manufacturer. You will have the best and knowledge and understanding of your device, but it might be useful to actually get external security experts that understand where the precise risks of the type of device you're making for the environment where you're introducing your device into wallwork. and it can help you to get a better output of your Fab modeling for going on. So the first step in the fret modeling is to decompose the application. So, for example, you create a data flow diagram. That's one way to do that.

And this is, I think, also where, in terms of the scope. the data flow, diagram should be end to end. So you don't just consider the application by itself. No, you need to really consider the application as part of the larger network where the application will run into, because clearly the the risks can come forth from the device itself. But the risks will mainly come forth as well from the external environment in which the device is introduced, the connections it has with other systems, how data is being transferred from one system to the other. So you consider the dependencies, the entries, the exit points.

and also the assets. Right? So if you look at this image, which is a simple image segmentation device running in a cloud environment. You can see that you need to consider where what data is stored. And because that's clearly right. I mean, the data is what you're trying to protect within your service within the device you need to define your trust levels with access, for example, and on top, you can consider, in addition there to global system fuse. but maybe also multi patient harm fuse. So where an attacker, for example, could spread to further auto systems update ability and patchability fuse. How quickly can you patch your different components? There might be components in a way easier to patch on others. So in terms of all the layers you might want to consider

of which ones are easy and quickest to fetch. and the Security use case views. So how the system responds. For example, in the case of any event of an incident. once it's set up, you need to identify your threats, and I'm not going to go through a lot of different methods. Here I'm just going to use. Stride again is very commonly used. So it's It's a very system systematic approach to considering sites. I'm not going to say it's perfect. because it's not. You might want to consider additional methods. So stride is just an abbreviation or an acronym for spoofing, tempering, repudiation. information, disclosure, denial of services, and the elevation of privilege.

So if you look on the right side, there's a description and the potential security controls. So in a case, for example, let's look at one a of denial services, for example. any action that is attempted to deny access to valid users. And obviously the controls you want to embed is make sure that your device continues to be available to the to the end user. So the outcome of the access to deny for valid users will be that the device becomes unavailable. One of the things to consider as well is that you? Can you look at a wasp website for additional information with regard to threat moving, but also the top 10 of most commonly frets, and

that we use tried as well. If I'm mistaken. look one step further, right? So you go in assess and score the threads. So you look at your design flow that you've created with regard to security, and you're going to consider what are all the potential threats that are applicable to the setup. So in this case, I've marked a number of 3 orange dots on the on this on the overview, and what you can see is, for example, there's a risk number one, where Fred Hector would spoof the hospitals, networks IP to trick the dicom uploader into accepting malicious data. which will be one example to, for example, the hospital staff denying the uploading of certain dicom files, and without proper loving. Clearly, you cannot prove that they've done so.

And then, you see the fur one where the dicom data is intransit to the cloud is intercepted, it's altered. So, in other words, tempered with compromising the integrity of the patient information. This is where you see that the stride provide you the systematic approach to considering what are the attempts on this di design? Diagram, where people can actually spoof the system? What are the types of denial, the denials that can take place within the system. And then the last part is, what are the interactions and the items that can be tempered with, and then you take that approach to assess all the potential threats that you can come up with.

You, put them similarly, just like a risk assessment. You put them as your risks into a table. and for each of these, and this is where you have an interaction with either 1, 4, 9, 7, one, for example, in the case of the last one, if data is being tempered with, and you can imagine that will be patient data, there might be an additional safety risk. So in this case of segmentations, if the patient data segmentation image is going to end up in incorrect patient file that may be in patient. That is, the segmentation might not match actually to that specific patient. But the doctor might not be aware of that, and could follow up on that for that specific patient

leading to an incorrect, patient outcome. So these kind of risks. and do not necessarily be looked at in isolation for security. For most of these risks you will have to consider is this also potential safety risk? And then clearly, risks are prioritized. So the ones with highest risk level. Those are the ones the highest. Fred Level. Those are the ones you want to consider first and how to mitigate them. You want to put your most efforts onto mitigating those. the next step will be to implement the controls. And in this case I'm trying to give an example as well. So if you look, for example, for risk number one, there's potential of 3 controls

the controls are also laid out in the image on the right side, so it will give you a little bit of an overview of how that will work on what that looks like and where you can implement controls. and I think and there's again right. If you, if we go one third in the last step, you can see that each of these controls, you will need to provide in a single overview. And some of these controls are actually going to be considered your requirements of your software system. So your security requirements make sure that when you identify those controls that they're also seen as a requirement, because clearly your requirements again lead back to your verification, a validation testing.

And in the case of your verification testing right security requirement, A is tested in by reference of test one. and you might want to do an additional validation test at the end, which can be a penetration test. For example. I'll hit this view. Yep, go ahead.

So one of the one of the participants wrote, could you please contrast a bit threat modeling versus usual security risk analysis, it seems to be a lot of overlapping. Well, there is that.

Go ahead. Sorry.

Yeah, I'm done.

Okay, yeah, indeed, there is a lot of overlap. So yes. there, if you look at the traditional software software, or either. 1, 4, 9, 7, one risk analysis. It's very much the same. It is a similar setup. Clearly, the deliverables that are the inputs into your fret modeling are different. For example, your design flows, the interactions, the method you apply to assess the type of threats that can occur for your system. You need to identify those. So, for example, with a stride, methodology and risk criteria that you determine can be different. The risk acceptability criteria could be different. Your overall acceptance of your security profile could be different from what you do in an Iso 1, 4, 9, 7 one. So I think the main reason for FDA to ask for this specific separation of the 2 is that if you combine the 2 within one single

risk management approach. you run the risks that you over overlook specific security risks because they do not have an implication on the safety aspect. And I think that's why we.

I think that you just answered the other question, which was, does it mean that we need to do a separate cyber security, risk, analysis and medical device. Risk analysis. Following Iso 1, 4, 9, 7, one, and.

Exactly. Yeah. So this is precisely what the FDA is asking for is they could do a separate risk assessment approach to your cyber security risk management, and this is going to be deliverable within your Eastar, and literally, you cannot complete your E star without having this deliverable done. So this is going to be a mandatory item from the FDA.

Okay, thank you. I'll stop interrupting now.

No, no worries feel free to interrupt. I mean, we're here to answer questions and to look at these methodologies. So it's a good question clearly when. And this is also asked by the FDA. And I think there is a little bit of difference. But they're just purely technical requirements, and there's always a bit the hard part with security controls. not all security controls can always be tested properly. So in the case that you cannot test that you need to provide a rationale, but these rationals will be acceptable. If really, if it is a valid rationale. and with regards to the validation testing oops. I'm sorry I just went back

with the validation testing pen testing. For example, you also need to think about your testing your soup and OTS components and also assess your OTS and 2 components as part of a risk assessment. One thing I'll mention here, and I think it's stressed in a number of times throughout. The guidance by the FDA is, you'll need to demonstrate that traceability just like you do for your standard software requirements. So software requirements need to be linked to your verification test need to be linked to your validation testing. and it needs to be traceable in both directions. Same with the threats, the risks.

So that's not that different. But again, it's going to be delivered as separate documents for the FDA. So some notes right? And specifically, I think, on stripe. Also this type of threat model that we just ran through. It's not extensive in the sense. So most of your controls can be addressed through fret modeling, but some may not. So some may require organizational controls, and I don't think there's an appropriate room in this type of risk assessment to do that. So when we talk, for example, about your internal staff members having access to certain parts of the software and being able to lose their login details somewhere. You need to have organizational procedures on top of having just technical controls.

Make sure that your organizational procedures, for example, revoking access. When a staff member leaves right? You don't want to have stuff being able to access a medical device when they've left your organization remotely. Training or stuff, contractual agreements, also an important one. Some of these items you cannot mitigate directly. So if we go back, you can see, for example, for the first one where I made it in orange as well. Implement network like network level authentication. That is not something that is applicable to the organization executing the threat model, because this is really a risk within the hospital environment. In that case you might want to request that

hospital implements, appropriate controls. So you might want to put that in as a contractual requirement towards hospital you're working with to make sure that your medical device is appropriately protected one of the other controls that also do not come forth necessarily from the risk management. What threat, modelling, exercise, or foreseeable security risks. So, for example, writing writing down passwords on a sticky note. Just very simple example. I don't think that's properly addressed either to the fed morning it could be, but it might not always be another one to also consider is that fret bombing doesn't always strictly address the postmark and monitoring, for example, intrusion detection systems.

When you write those down as control again, I think that's more of an organization control. So it might fit a little bit on the same note that I have here. and, for example, the ones that in support the log infestations. I think we talked about it in the beginning and singular. The sponsor of this session provides a rather good solution which helps you to do intrusion, detection, and also again support some look investigations which is really helpful. Then the last part and I've mentioned it already is not a replacement for safety. Secure safety, risk, assessment, right? They complement each other and intended to complement each other. Any risk, on one hand, for security could be a risk for safety on the other side.

and sometimes and that's also good to remember is they can complement each other, but they can also contradict each other. So in some cases you might implement security controls which limit access to a medical device, whereas in certain security alerts, you might actually or safety alerts. You might want to get quick access to the medical device. But then, if there's a lot of layers of security around it, it might actually limit access to the device. So you should always have a voice balance safety against security, and that might be a bit challenging some links and guidances. I. The FDA has worked together with me today to develop a playbook which is specifically for fret modeling. It goes into a lot more detail on the fret, modeling the types of things to consider. And I really find it a useful resource. So we really point everyone to read that document and look at that document when executing and threat modeling exercise

all was clearly the top 10, but also their threat modeling. Explanations are really useful. So if we continue the software bill of materials, that's the next part on the list of items that you should be delivering to the FDA. FDA is requesting it to be machine readable, and it should be a list of the components that I went. In the so far. so components of external air origin, for example, super OTS, items should be on there. So, for example, open source items for the ones you've purchased, etc, but also your internally developed software components should be on there. including, for, for example, your standard libraries.

So why is this useful? Well, it will support the security and safety risk management process clearly, and also your vulnerability management. If we look at what that means, what is actually an asp, what should be on there. So all components are sub components. The Sbum author the date and time of the lost revision. So in this I gave a list of 3 examples of what could be on there in the in the cases of the device we just mentioned for the fret, mulling exercise as well. So you see that there's a number of versions, I mean the number of components on there. The versioning is on there the relationship. And, for example, if the C bite and

sorry if the biden codes and we all know that Biden has a lot of sub libraries. You might want to list these separately. So you wanna include. you want to clearly describe that that first component includes a number of sub components, and these sub components should be on the same list with a clear link going back up, saying that these are included within X. So the references between those systems should be clarified. the level of support. So, for example, whether it's abandoned where it is no longer maintained, or whether it's actively maintained and the end of support date. And clearly it's just for the purpose of this example I noted that the first one is amendment and is no longer supported.

If you look, then, and I specifically call that version 3.7, so we could use it to show how you also assess the vulnerabilities. So you have all your components. Then you can ever you can assess the available Cvs. So, for example, the Cve database for me today I found really useful. It's a little bit more extensive than the one that the FDA refers to the Caesar golf one. and then you will find that for example, for this specific version of bite, and there is a known vulnerability. And you need to assess is that vulnerability applicable to my device in this case, for example, yes, and it gives you an attacker. In this specific sample the option to create infinite feedback loops would would block

that occurring process, and can utilize the single core of CPU by 100, meaning that it would no longer be available to do any other type of activities. If you see that kind of vulnerability, you need to assess the probability of that occurring in your device, the severity clearly, again, the risk, and it can feed back into your risk assessments for cyber security devices, and how you're going to mitigate this. If you decide to keep this in the device, or if it has a very high risk. For example, you might wanna release a patch as soon as possible to to patch it. If that patch is available from the manufacturer.

I think you want to ask questions, John.

Yeah, someone asked, what does level of support mean?

The level of support is, if you Google, actually on those or just provide a search term on Google, and you look for the level of support. It's clarified. I know the the clarification here is not entirely clear. These are not my definitions. This comes from the FDA guidance with regard to abandon no longer maintained and actively maintained. I would have to look at the exact definitions as provided by the FDA, but it means that some, if it's no longer supported, for example, so the manufacturer will publish it, they will actively publish patches to the device. That means that it's actively maintained.

At some point they may still main have it available. You can still download it, and they still promote you using it, and they're still investigating it and supporting it, but at some point that will abandon it and say, Okay, you are no longer supported by the manufacturer. So we don't publish any patches anymore. So if you continue to use that specific component with that specific version. and there are security risks in there, then it's up to you, and it's under your own responsibility, and we will not take any responsibility for any issues that have occurred with it. Maybe something which is interesting to note is the image above right is considered that there might be the all the modern

digital infrastructure. There can be so many sub components that at some point you might be and leaning on the use of a very, very tiny so component that's somewhere tucked away all the way underneath. That's no longer supported. And if that one actually is becoming a problem or a racist security threat, you can your whole system good to suffer from that? Do you want to say something about the question. Sean.

Oh, just that. We launched the second poll question so that people would have something to do. And thank you all for answering the the poll questions. They really give us a stronger understanding of of who's attending and what what you're interested in and learning more about so it's very helpful for future programming as well. I can't see the questions right now. If you can look at the QA. And see if there's any There was. There was also a chat that popped up with another question about what you were just talking about.

I think there's quite a few questions. Is it helpful to do that now? Or should we go through them at the end and see if we have to.

I think I threw him at the end. I just thought that you know. well, okay, I'm gonna end the poll. So it. It looks like 62% software is a medical device, 31 connected device. These are not mutually exclusive. So you know, just to give you an idea of who's here? Share the results. you can see. very interesting. Okay, let's keep going. Sorry to interrupt.

No worries. So, going further, so unresolved anomalies, right? So you might have during your design development process. You're required to identify the unresolved anomalies. So there might be items in your device that are not. They can know that there's a buck in the device. And clearly you wanna follow up on those postmarkets to resolve them. You may have a rationale. Why, it's acceptable, but the FDA is also asking you to assess the risks associated with the unresolved anomalies. One way to do that is, suggested by the FDA is also to look at the common weakness enumeration public database. It's published on the as well my turn

and you can just search. It gives you a very good option to scroll to certain items and see if your type of vulnerability or your type of normally is listed, and what type of security risk is associated with it? And it will it give you also an id of whether you're you should be using that in your device, yes or no, and under what conditions? In this case you see that the one in the example below is acceptable. But there's also a bunch that are unacceptable, for example, or having those available in your device. And this is specifically related to known medical device issues. So it's a good database to have a look at

security metrics. So the FDA is asking you to give data about cyber security metrics. When I first read it I find it a bit old, because they're asking you to provide sub security metrics that you are aware of of your device. So not just what you're going to measure post market, but actually want to have the metrics. Sometimes you might not know what those will be, because simply your device is not on the market yet. And then in that case, the Faa saying, you can use prior model data if you have any or otherwise it's a bit unclear. I guess you need to indicate what you will be monitoring when it goes onto the market.

clearly, you should have the cybersecurity metrics throughout the full sport of device lifecycle. So when it's on the market. it should demonstrate the effectiveness of your processes, and it should be measurable. There are 3 identified by the FDA, which you're saying that you'll need to do so. For example, the number, the percentage of the number of vulnerabilities that have been patched, updated, which every virtual defect. They then see the average time between the vulnerability identification and the patch release. So how long does it actually take you to identify a vulnerability and to develop a patch release

which I referred to as your defect resolution timing, and the last one is your patching rollout timing. So from the date, if you develop the patch, you install that with all the sites, how long does that take? You? And FDA doesn't request this, but I would really recommend that you split this into separate risk categories. So, for example, high versus low risk, vulnerability, risk vulnerabilities. And the reason to do that clearly is that sometimes you might have in your system a number of low vulner risk vulnerabilities, or they might not even be applicable because of the way your device is developed, and you will just run a patch in the future when the next minor release is coming up. Then clearly, you're not going to at that point.

Roll out a patch, because yeah, it doesn't make too much sense. If there's not really a risk, but that is going to influence your security metric in a negative manner. So if you split them up, you have a good way of showing that you really address the high risk items immediately where the low risk items you might not be as fast, for then I would say that at the end, and I think this is going to be your catch all in one cybersecurity risk management report. So you really, in your risk management report, are going to describe everything we've talked about your flow diagrams explaining them. Explain the users, the boundaries to use environment.

explain installation environment, what your security objectives are going to be. The security lifecycle of your device, the security coding standard, the secure coding standards that you've applied throughout development. And then also the security risk management methodologies that you've applied. Explain them. Explain the scoring metrics, explain how you got to them, why these are relevant. explain the interaction with the safety risk management. So where you've considered, or how you've systematically assessed, or your cyber security risk, if they can have an effect on your safety parts as well.

And clearly the security risk management team that was involved. You can also specify the secure verification of validation testing that you've done pre-market and attach the test results as necessary. and clarified the remaining vulnerabilities, anomalies. But also you're labeling aspects. So how does this link back to your if you are there any warnings that you might need to address straight on the device itself, for example, as warning messages, alert alerts that pop up within the use of the software, or maybe potentially on the product label and your conclusions from the risk management process.

I clearly with a reference to the Cyber Security Management plan, and I would suggest that more, since you don't want to get a convoluted report, you can attach a lot of those things as your attachment. and by doing so right. having the secure diagrams as a separate appendix, having your risk assessment as a separate appendix, having your security controls as separate appendix, and so on. that will allow you to separate these, separate these appendices out to submit to the FDA as deliverables as part of the E star submission. So you have one collated document that he can maintain over time without having

a big number of cyber security documents living within your technical documentation and design history file.

That's a tremendous amount. Let's launch the third and final question. Oh. quizzes. Sorry this thing is launch. yeah, there there was a lot there. Someone asked. how? Should should all of this be included in the postmarket surveillance? You would sort of address that in the last slide that there, that there'd be a postmarket surveillance

plan. It's a little curious about that.

Yeah, this is exactly what's on the screen. Now, right? This hobby security management plan. So this is going to explain how to follow up on the premarket, on the males and vulnerabilities that you've had when you're going to implement the the batches, for example, to those. And how relevant those are, but also your references to the procedures that you have for cyber security monitoring and potentially even a more detailed monitoring plan. but also your periodic security testing. So you're going to do pen testing? Are you going to do process verifications, retesting of security controls. But in time.

and also your patching policies and the release process. So I didn't put that here. But daily the security metrics that we just discussed they should be in your cyber Security plan management plan as well, because you want to demonstrate how often you're going to assess those security metrics, and you want to monitor the security metrics over time. If you see, trends, etc. And in the past I've included this as part of the postmarked Failance plan. But I that might not be. might not be very helpful if you're doing an Eastar submission to have it as the same document it could, although you could potentially, I guess, attach it as an attachment to yours to your postmarks maintenance plan, and then

I say, separated out and submitted a separate Easter deliverable. I clearly should have a vulnerability disclosure process in place. So when you have a vulnerability that you find in your software that's out of the market, how are you going to inform your customers so that they also know if they need to take further action or need to take mitigations to to prevent that being exploited in the field. And I think, then that's some more useful resources, I guess, to look at again the meter I would really look into that. They have more documents in just the fret, modeling also the A. Meters. 57, which is

aligned with the Iso. IC. 81,001 dash 5, one. The both are already recognized by the FDA. And the Iso IC standard is going to be harmonized, probably within short notice within the European Union as well. So these are 2 standards that can really help you to embed these deliverables into your standard. So far, lifecycle processes. And that's it. So we've come to the end of the of all the slides, and I hope this gives you a little bit more insight of what is expected within the e-star process. I hope it didn't. That was too much fear already, because, to be honest, I mean, there's not going to be a lot of us who've already gone through this E start process?

so yeah, it's it remains yet to be seen. How are we going to get through? But we'll see.

That's wonderful. Thank you. I. So we have some questions. Do you want to try to address any of them?

Yeah, I think it makes sense. We have quite a few. I think there's 21 questions. So maybe we can run through.

Out

Exactly. Exactly.

We have their there. There are a lot of questions. I'm gonna look for. While he's answering some questions. I'm gonna look for the email address that the FDA gave me for cyber security questions that you can address directly to them. And they they have an email address for sending questions to, and so I recommend doing that as well. But let's try to answer so Petra somebody asks, is there a penetration test strictly necessary for software as a medical device? Or are there any alternatives.

I think at the end of the day it ends up with your risk management process, right? And it would really depend on what your device is doing. I mean, I can imagine there's clearly devices that are not going to be connected to the public Internet, which are, so far as a medical device that are used in isolation. And in that case a penetration test may not be the type of testing that's most relevant. After you release the product onto the market. I think you will have to have a very clear rationale to the FDA in explaining why you're not executing appendess. but I'm sure that there's ways and specific situations where rationale may be acceptable.

Excellent Should the cybersecurity metrics be part of the postmarket surveillance reporting, we answered, that.

Yes, indeed! I'm also seeing a question on whether cyber security requirements are also mandatory for class 1, 5, 10 K. Exempt devices. It's a I think it's super good question, because one, there's a regulation right that requires you to implement cyber security controls. You do not need to clear your class one device through the FDA by means submission. but that would still ensure that you clearly have a cyber security frap modeling process in place, and you assess what security met risks are associated with the user to your device, if not only for preventing your company being liable for for the device data being breached or for causing a security incident within a hospital.

Any more questions that you've ran into that you want to discuss Sean.

Yeah, I mean, any. Any of them that are listed are good. There was one about the EU in the Us. And your recommendation for sort of not doing double the work.

Yeah, clearly, that's also a super good question, and I think I may have already slightly addressed it. The Iso, 81,001 dash 5 1. That standard is already harm oh, well recognized by the FDA. It will be harmonized soon within the European Union, and there's a lot of questions being raised as to why it's not harmonized yet, because it was plans for harmonization beginning of this year, and it's not yet done. But I expect that to be done any day soon. That standard actually already demands that you determine your product security lifecycle. You have a question. Sorry.

Sorry. No. I was trying to find that email address. And I accidentally hit a podcast.

No worries.

I'm gonna have to. I'm gonna have to follow up with the with the email address afterwards, because clearly doing too many things at once. Is not my forte

Yeah. And yeah, to finalize the question. So I lost my train of thought. Sorry. Hey? Do you remember, Sean, what the question was, then I can.

It was about the EU and the FDA.

Yeah, exactly. So. Implementing Iso 81,001 is probably a good idea because it addresses the cyber security lifecycle. It addresses the the exercise of fret, modeling it also. addresses, for example, the need for penetration, testing and documenting those, and it will. It really fits in what I see. 6 to 304. So it wants you to document the requirements of risks ensure traceability between all of those. So that's a good starting point. I would say.

Do you have? Or is there a template that they can use for cyber security, risk, assessment?

To be fair. I do not have one today. I know that there's companies that have that are making templates available. I am not sure how useful it is to call these out, but I know that. Some of the requirements management systems, for example, have those. I know that there's a consulting firm here within the EU that makes available a lot of templates online. They're called open regulatory. They were thinking about making templates available online as well. But I I haven't seen them doing that yet. So might be one to monitor.

Here's an interesting question for devices, submitted Pre, start pre-star program. Is it expected to see more scrutiny of the FDA during inspections regarding cyber security requirements.

My expectation is that that will be the case. But how that will work out in practice remains to be seen. Right? I mean the. These are now the new requirements, and they're backed up by regulations. So in that sense, the FDA Inspector should be aware of these changes and regulations, and should actually order against them. So yes, I expect that. especially when the, with the also, the harmonization of the 81,001 5, one standard.

You talked about the about likelihood, but the FDA guidance also talks about not using likelihood, but exploitability instead for vault instead for vulnerabilities. I'm not sure I understand the question, but.

Yeah, I do. And I think exploitability is indeed, I agree that that is probably a better term to use, because it's the risk of a cyber security threat actually being exploited in the field. So even though the probability of that occurring in your device could potentially be high. the risk of that ever being exploited could be relatively low. So, for example. to make it as practical as possible. If you look at this exploitability, if you have a device, and I think we touched on a specific example of the Pdf file that could cause a full use of the CPU system because it creates an infinite loop. If your device doesn't even have an opportunity to create Pdf files, then that clearly is not exploitable in your device, even though that's vulnerability may be present in within the device.

So yeah, I think film exploitability is a good term to use instead.

There's another interesting one, some suggestion about legacy devices or transitional devices. How can we manage the cyber security for those devices.

So if you look at legacy devices clearly assess the risk. That's that comes with the legacy device. And maybe one question back is maybe, Sean, it's clear in the question. But is it regarding a legacy medical device that's still on the market? Or is it about a legacy component that's embedded within the device.

I think it's a legacy device that's still on the market.

Yeah, then, clearly, you should just maintain your security lifecycle process, no doubt, and make sure that you patch it. I mean, there's a risk right? This security risk associated with the device. If you need to have all the documentation that is mandatory by the e-star. I don't think so, because you're not going to submit it as a new 5, 10 K. But I would make sure that you have clear processes in place to exercise the risk management on that device and exercise an overview of all the vulnerabilities that are associated with the device. What is still out on the market.

Interesting. so there's going to be a short survey following this. Please. So here's a question. Please recommend any certificate or recognition on cybersecurity for medical devices, if any, I guess, would be the Iso standard.

Yeah, the indeed, the I understand everybody's. You can really get a certificate against it. So I'm not aware of a specific iso certification. If you can get on a product level as an organization, what you might want to do is consider implementing Isa 27,001 and get a certificate against Isa. 27,001, though Isa. 27,001 is, I would say I one. It's not tailored towards medical device industry. 2. It is rather lenient. You can decide yourself what controls you am implement within the device rather than it actually demanding that you are strictly what you implement. and you can also limit the scope to not even include the device aspects. So if you want to do a proper

certification, maybe Isa and 7,001 is not going to be sufficient to demonstrate that you fill the cyber security requirements. However, it will establish a good framework for assessing risks for making sure that you decide how to implement the measures that you ever sort of system in place. But it's there's not really a good certification that you can obtain today, as far as I'm aware.

What kind of medical devices require cloud security? Specifically.

Well, any device that is connected, I think one to the Internet. to the public Internet in that sense. because as soon as your device is connected to the public Internet. then it can be attacked over the Internet.

Someone else. Would you recommend? Use Cvss. For determination of the exploitability.

Yeah, clearly. Yes, that I, I think, is very helpful, because they clearly have the. If you look at the Cfs Cfss, you can clearly trace back and understand how likely it is that that item will be exploited. But that's just only part of the question, right? Because your local implementation will change the exploitability even further. I mean, if if if you implemented in a certain manner, then maybe it cannot even be exploited at all when in your system, and it might not even be applicable, even though I see if he has actually exist or Cve actually exists.

Someone asks, in practice, would you suggest having a new separate sop for cyber security risk management or incorporate cyber security risk management in the existing risk management sop.

Yeah, so what I've done in organizations. And I would, I think there's multiple answers to this. I think the basic answer to said to provide is that a lot of done in organizations? So actually, risk management procedures can be awfully specific. So they can detail already quite a lot in detail what you're going to do, how you're going to do it, following either one for 9, 7, one explaining the sometimes we've seen the risk acceptance criteria, and it is scoring criteria being explained to risk management procedures. If you ask me, the risk management procedure should be a basic outline saying.

identify at one. All risk management activities will be done according to a risk management plan. In your risk management plan. You identify the members of the team. You identify the risk management methodology. You identify the regulations that apply to the risk management process you're going to execute and the standard that apply. And then you're going to make that much more specific within a risk management plan, and I would keep the risk management procedure much more high level and much more process oriented rather than actually and detailed, because then you can just apply it through for different types of risk analysis. Also, you already see this as a example where it becomes difficult, is in products versus process risk assessment where

risk assessment procedures, usually aim to address both. But then, if you try to add specific security, risk assessments, then it becomes a bit of a hassle, so I will make them as general as possible. so it can address all types of risk assessment.

Interesting. Would this apply to devices not directly connected to the Internet, but accessible via Bluetooth. I think Bluetooth is directly connected to the Internet.

Not necessarily right. You could have one device connecting to another device just using Bluetooth, and it would not have an active connection to the Internet. So, but it would still apply right? You would have the same diagrams. Bluetooth can be exploited because it has a local access point. Just might have a much lower risk. Profile as compared to a connected device that's connected to the open Internet so clearly is as a very different structure. But the process of doing a fret modeling would still be the same, and the requirements that you need to fulfill when you're submitting your 5, 10 K. Are going to be the same. So yes, you should do the pro. You should follow these processes.

The outcome might be a very simplified version of that whole setup.

The last question that I'm gonna ask before we go to the survey is thoughts on the latest draft from the FDA select updates for the Premarket Cyber Security guidance, section 2, 5, 24 B of the Fd. And CR. What.

Yeah, exactly. This is the guidance that was released, I think last week. I unfortunately, I haven't been able to analyze it in that much tap yet so, or I, I cannot make an active statement on it. Sorry.

That's okay. That's okay. I thought that might be the case. so I'd like to thank Leon very much we will try to follow up with the questions. I will also send the link to the FDA for their cyber security question answer line. They should be able to help you if we cannot. And yeah, please. connect with Leon, connect with me, connect with singular and look forward to the next webinar. If you have suggestions for me about upcoming webinars, speakers, topics, etc, please let me know. And thank you everyone so much for your participation.

Thanks, Sean, for the organization.

Take care!