Recently our Head of Regulations, Shlomit Cymbalista, presented at Medical Device and Diagnostic Cybersecurity Conference, where she talked about medical device standards and regulations and their impact on the future of the industry
Below is the recording and the transcript of her talk, and the link to her deck.
Moderator: So our next speaker is Shlomit Cymbalista. She is Head of Regulations and Compliance at Sternum. So thank you.
Shlomit Cymbalista: Hi everyone. Do you hear me OK? OK, great. So as was mentioned, my name is Shlomit. I’m the Head of Regulation and Compliance at Sternum. Today we’re going to talk about how you guys, many of you medical device manufacturers, can say two steps ahead of all the new cybersecurity regulations coming out.
We will focus quite a bit on the FDA. But as you will see that these themes really are more of a global movement than only here in the US. A little bit about myself. Oh, a new remote. A little bit about myself before I joined Sternum a few months ago, I spent about 10 years in medical device regulation and quality management.
In my previous role as Head of Regulation at Zebra Medical Vision, I worked on 10 FDA clearances in the field of AI and radiology software. So a lot of the obstacles you’re all facing I faced before. I’ve been there and I understand and I hope that today’s presentation will help you a bit.
OK. So for our discussion today, we’re going to talk about four main ideas. Firstly, the era of hypothetical is over. Why you need to start worrying about cybersecurity yesterday and not tomorrow.
Cyber is no longer an add-on. Regulators, the FDA, are starting to ask tough questions today regarding how you’re designing your medical devices with security in mind, not just an afterthought.
I’m going to highlight the key changes that we’re seeing in the FDA requirements from your new guidance that was released this past April with some technical solutions. I know this is all going to sound very complicated. It’s a lot of information for medical device manufacturers to comprehend but we’re going to discuss the next steps and some ideas of how you all can start finding solutions to all of these requests.
Era of hypothetical is over. How many people here before the last couple of days thought of cybersecurity as one of the top three priorities in their company, with a show of hands?
Wow. OK. Well, I hope that after today, that number will be a lot higher and I’m sure after this conference, you will see that it definitely is. So for those of you who are news junkies like I am, I’m sure you’ve been reading a lot about over the last few years about ransomware hacks that are hitting different hospital networks. The number is growing annually and the health industry is probably the most attacked area of critical infrastructure in the US with each attack costing hospitals millions and millions of dollars for each breach.
In addition to that – oh, sorry. OK. In addition to that, a few weeks ago, the FBI released a very upsetting report regarding just how vulnerable these hospitals are because each hospital has upwards of tens of thousands of connected medical devices, legacy medical devices that are working on software as old as 10 years and they have an increased number of vulnerabilities.
Now if any single one of these vulnerabilities and single medical device gets hacked, it will provide hackers entrance to the entire hospital network. Now originally or in the past, there is a concern of data privacy and patient information security and you don’t want that data being shared through that ransomware attack.
But what we’re seeing is that the fear is even greater, that if these medical devices get hacked, it will allow the attackers to access the medical device functionality, affect the use of the device and even cause harm to patients.
Here are some of the main categories of medical devices that the FBI lists as some of the most vulnerable out there. Now in this report, the FBI cited a study in which 89 percent of healthcare professionals experienced a cybersecurity attack in the last 12 months and many of those have actually experienced upwards of 4 or 5 attacks within the last year.
Twenty percent of them showed an increase in mortality rates of patients in the hospitals and at least 50 percent saw a decrease in patient care or delay in patient care. As we know, that could also very much lead to mortality rates as well.
Now why am I talking about this? I think this demonstrates the need for this great shift in cybersecurity in the medical device sphere. In the past when you thought of device security, I think people really thought of data privacy, information security.
I’m sure everyone here is familiar with HIPAA and GDPR and the ISO 27100 series for information security. But what we’re seeing is that healthcare needs to evolve from data protection to product security because at the end of the day, our new reality is that if you’re not ensuring product security, you cannot ensure patient safety. Now let that sink in for a moment.
Cyber is no longer an add-on. I don’t know about you. But in my experience in regulation, I don’t think cybersecurity was at the forefront of what we were worrying about at the start of design and development. But what we’re seeing from companies that we work with is that regulators and the FDA are already starting to push back today and ask some really tough questions about cybersecurity within the design of your device.
I want to talk about some themes we’re seeing before I actually bring some hard examples of different FDA submissions and responses. But I think the general themes that you’re going to see really align with what the FDA has published in their guidance back in April 2022.
Firstly they are increasingly highlighting the importance that cybersecurity directly affects the device they see. They want to see that there are mitigations and controls in their runtime protection. When your device is in the field and is being used by their intended users, what kind of protection and alerting are available so you know what coding errors are being affected that also can affect device safety?
And lastly, they want evidence and performance of these controls. It’s not enough to say they’re there. They want to see reporting. They want to see results and know that these mitigations actually work.
So as I mentioned, I’m going to show some examples from different submissions, from customers that we’ve worked with, that they’ve seen and these are direct quotes from the FDA.
So the first example, the FDA is asking for evidence regarding coding errors. You know, we’re human. Your developers are human. There are very possible coding errors within your software.
The question is, what are you doing to protect and detect these errors during runtime of the device? What rules are being implemented and how are you showing evidence that they actually work? OK? And as I highlighted here, again, we’re seeing that their concern at the end of the day is the safety of the device and the safety to the patient.
The second example I’m going to show I think really hones in on the general theme of what the FDA wants to know. Information security and cybersecurity that is needed for the device and what I think is very interesting and that people need to pay attention to is that even for devices that have no connectivity, that even your device is not always connected to the internet. It might have vulnerabilities that can cause a risk to the hospital network and to patient safety.
Some examples of what they’ve asked for. Mitigations for intentional and unintentional cybersecurity risks. Cybersecurity risks that you’re considering in the design of your device, just like you’re thinking of product requirements and software requirements. Possible risk management. What are you thinking about when it comes to the cybersecurity risk of your device?
Evidence that the controls are performing as intended. List and justification of all of these cybersecurity controls. I think when it comes down to it, this really demonstrates the similarity to what many of you are augmenting for your risk management, for safety and effectiveness of your device.
It’s time to start implementing a similar process for the security of your device because at the end of the day, this is what the FDA wants to see, that the information being held in your device is confidential. There’s information integrity and information availability.
OK. So the key changes. Raise your hand if you’ve had this chance to really do a deep dive in the FDA’s recent cybersecurity guidance.
OK. Some of you. There’s a lot of information there and so what I’m going to try to do is really hone in on the main themes and the main ideas that really repeat themselves throughout the guidance. So firstly, security within design of the device. Security by design. How many of you have heard that term in the last two days? I’m sure all of you.
It’s because it’s not new. It has been there but it’s time that manufacturers really start implementing it. Secure practices and evidence. It’s great that you have those controls in your device, if you do. But you need to show that your company culture, the processes and procedures you have in place are being performed with security in mind. From day one of design, development, release and post-market of your device.
The greatest shift I think is Onus is on the manufacturer. I don’t know about you. but when I was working in regulation in the past, I think we felt pretty safe to put in the IFU that our medical device needs to run on a secure network in your hospital.
So the responsibility was really put on the hospital to ensure that they’re functioning on a secure network. It’s not the case anymore. You as a manufacturing need to demonstrate that you are doing what you can to minimize the risk of your device from a security perspective.
OK. So this is my favorite quote from the FDA guidance and you know you’re in regulation if you have a favorite FDA quote. FDA requires manufacturers to implement developmental processes that account for and address cybersecurity risks as part of design control and they want to see that your submissions include that information that describes how security objectives are addressed by and integrated in the device design. If you haven’t heard me say it enough, secure by design.
When you’re thinking about designing your device, what the UI looks like, what your performance metrics are going to be. Security has to be up there as well.
OK. So the question is, what are some of the ways that the FDA recommends manufacturers to incorporate all of these – the theme of security by design throughout the total product lifecycle? There are a lot but I really want to focus today on some of the more actionable and attainable solutions that I think are a great place for US medical device manufacturers to begin.
So let’s start down here. Everything in pink really applies to the total product lifecycle. In blue, we’re going to talk about pre-market and development and purple we’re going to talk about post-market.
So to start, SPDF, secure product development framework. It’s taking of QMS, ensuring quality procedures for design and development and implementing the same concept for security. Having secure processes throughout your QMS to ensure just like quality matters, so does security.
I think many of you who have already implemented information security procedures, this actually won’t be such a large jump. But if you haven’t, it’s time to start implementing that today.
Security throughout your total product lifecycle. I see it as the implementation of your SPDF that ensuring that in every stage from design, development, testing, that you have secure processes and security in your company culture for those points.
V and V, validation and verification. Just like you need to test that your performance and your security requirements are – I’m sorry. Your products and software requirements are meeting their goals and your performance, your sensitivity or specificity similarly for cybersecurity. You need to include security testing, identifying vulnerabilities, testing your mitigation, penetration testing just to name a few, are giving the results that you want to expect before you release your device to market and this is already part of the pre-market stage.
Vulnerability management identifying, evaluating, treating and when needed reporting on the different vulnerabilities that may be present in your software.
At the end of the day, no software is void of vulnerabilities and that’s OK. But the ability to have an organized way of tracing them, identifying their risk level. Is it a high-risk vulnerability? Is it low-risk? Is it a risk of safety? These are questions you want to start asking yourself, especially for those of you using third-party libraries.
You want to make sure that you have an idea of what vulnerabilities are present. So if tomorrow they list another log for that you know that whether that software is present in your device and you have the vigilance and reporting requirements that you would need.
SBOM I think really feeds into vulnerability management. It provides you as a manufacturer traceability and transparency into your software components and their vulnerabilities. I think there’s a lot of talk I’ve heard the last two days as SBOM as a solution.
If you ask me and I think this since I – when you look more into the regulation, I think SBOM is more of a tool. It’s good, if you need it, to have that transparency and to know what’s happening in your software. But I think – and we will talk about it soon. The FDA wants to see some more technical security controls in there.
So SBOM is great but I don’t – I don’t really see it as an end-all solution and post-market surveillance. After a device is released into the market, how do you know what new cybersecurity risks are being developed? What’s happening in the field when new vulnerabilities are being identified?
So I think it’s important to remember really the concept of secure by design is going to follow the device throughout this little product lifecycle.
OK. Before we move on to some more technical solutions, I just want to know that everything we’re talking about today, these themes that we’re seeing really translate throughout the different regulations both here in the US, through the Patch Act of the Biden administration. Recommended, really honed in on the need for an SBOM for all connected devices, not just medical.
The IMDRF principles for cybersecurity, the MD or MDCG guidance for cybersecurity that really supports those of you who are in the European market or want to enter the European market. It really mimics a lot of the guidelines we’re seeing through the FDA.
I think the joined security plan is going to be a great tool for all of you who are starting to build your good practices for cybersecurity. It’s a great tool and I highlight recommend looking into it and of course NIST I think is a standard that everyone is quite familiar with.
OK. So a lot of information, a lot of action items, a lot of new things they need to incorporate into my company, the design development processes. What do I do? Where do I begin?
So to start, let’s look at a standard medical device and why connecting medical devices are very different than other devices out there. They are generally much smaller. They have lower resources, almost no visibility into what’s happening and almost all of them have known vulnerabilities.
So what are some of the solutions that we can look at regarding the requirements that we have to make? First and foremost, like we said, secure by design. How do we gain visibility into the usage, the cyber breaches and the performance of the device once it’s in the field? What are some mitigations for the supply chain and third party vulnerabilities that we are – we know are in our medical device and what are some of the technical controls that the FDA requires from medical device manufacturers?
So firstly, some of the technologies available are some form of security solution, autonomous security solution that can really be built into the code of the device. It takes up limited resources. It’s autonomous. It doesn’t need to be – necessarily be connected to the internet. So it’s really a great solution to ensure security within the design build of your device.
Real-time observability and alerting will allow you to know what’s going on in your device, give you visibility. If there’s a cybersecurity attack, alert you right away and really know in real time what’s happening. A great vulnerability management system coverage of your third-party vulnerabilities and an automated SBOM to keep you up-to-date whenever those library versions are updated or new vulnerabilities are identified.
And lastly, some of the many recommended technical controls by the FDA is data and code integrity, cryptography, authentication and event detection and logging.
Many of you aren’t necessarily the R and D people on your team. So this might feel like a lot of information. But there are solutions out there and I want to talk a little bit about what we at Sternum are doing.
So firstly on the side of security. Why our solution really answers a lot of those questions and a lot of those needs. Our runtime protection provides autonomous security for medical devices built in to the software of the device. So even for both known and unknown vulnerabilities, there’s protection because the software is able to identify the different footprint of cyberattacks and that really is standard for many hackers. They follow a certain footprint that we can identify, seamless integration. It really doesn’t take a lot of time to integrate into the code.
Because we already developed within the development part of the software process, we’re already there when you get to V and V. So during cybersecurity testing, we can identify the new vulnerabilities that might be there, provide mitigation and all of that evidence that the FDA is asking for.
Because of our protection from zero-day attacks, it really minimizes the need for patching. I think there’s a lot of emphasis of patching as a reactive solution. But we at Sternum believe that medical device manufacturers need to be more proactive in their solutions.
So by minimizing the need for patching, you’re saving your resources in R and D for your next version of the device and you’re not wasting time and money on patching and just to know where in the total product lifecycle this solution can help is really throughout it, a little bit what I mentioned.
Next, we also provide monitoring and observability solution because it’s embedded throughout the – oh, sorry. Because it’s embedded throughout the total product lifecycle. We could provide a real-time alert when there’s a cybersecurity attack in the field. Again, we stop the exploitation of these vulnerabilities. So even if you know the attack is happening, you have the security to know that your device is protected, which I think is really – gives you peace of mind.
The monitoring observability platform manufacturers can personalize what kind of traces that they want within their device, so they could collect the data that is relevant to them. It can be used for post-market surveillance, product improvement and our event tracing gives you a step-by-step understanding of what happened. What were the events before any quality or cyber event? So that you can use that for your investigation into customer complaint and CAPA assessment and lastly, we provide a static and dynamic SBOM options so that really – at the end of the day, the regulators are going to want to see it and we can support you with that documentation as well.
Again just to know which part of the total product lifecycle that it provides a solution for. And lastly is the anomaly detection portion of the Sternum solution. The anomaly detection software learns your device. It learns what is expected behavior and thus what is unexpected behavior.
So over time, if any behavior starts to not go according to plan, it gives you an alert to understand, OK, am I – is there an emerging issue here? Is this just a bug or is this a bigger problem that’s going to affect my entire fleet of devices, be it 20 devices or 20,000 devices?
This information can really help you get ahead of the game when it comes to your medical device security. It also allows you to understand device trends and user interaction and here again is just a note of where in the total product lifecycle this can support you.
Just a few notes about the Sternum solution. It can be used for both new and legacy devices. In the beginning of the presentation, we spoke about how a lot of the concern coming out of the FBI report and ransomware attacks are based in legacy devices. So this certain solution can be used for both.
Improved ROI with minimized patching. Again using less resources, less time and less money and really no impact on performance and little requirement and resources needed.
So implications of everything we just spoke about, just to sum it up. As we mentioned in the beginning, cybersecurity is no longer an afterthought. It needs to be incorporated into your device from day one of design because security by design is going to be your new cost of entry into any regulatory market.
Today we focused on the FDA. I assure you, you’re going to hear the same thing about Europe, Australia, Japan, China, wherever it is. Security is becoming a very, very big problem.
It doesn’t stop after release. You need to make sure that you have the mitigations and continuous monitoring available to know what’s happening in your device once it’s in the market and of course a lot of new documentations, be it your SBOM, your reporting, evidence for your cybersecurity controls. You want to make sure you have that for your regulators.
If you’re feeling vulnerable after today’s talk, feel free to reach out and I’m happy to take any questions from the audience. OK.
Moderator: So I have a question.
Shlomit Cymbalista: Sure.
Moderator: So the FDA has approved several standards, UL 2900 and the IEC 62443. So for those of us developing medical devices, which standards should we go with or what should we do?
Shlomit Cymbalista: Great question. I think firstly in the cybersecurity guidance, the FDA does know which standards that they see as best practices. So I really think when you’re looking at your device and what seems appropriate, I think the 60443, it has a system and a component level and it’s originally built for industrial systems.
So for some medical devices that might be a little heavy or less applicable, so I think it really comes down to knowing your device and the requirements that are right for you. But I still think when looking at the standards, it also should be in conjunction with the FDA guidance.
There is a lot of overlap but I think there are some nuances that the FDA want to seek. So it’s really a mix of the two.
Moderator: OK. Thank you!
