Medical Device Cybersecurity Is Tricky [The Industrial Security Podcast]

I would estimate that somewhere between thirty and fifty percent of medical devices that are submitted to FDA today qualify as a cyber device per the Food Dragon Cosmetic Act. Welcome listeners to the Industrial Security Podcast. My name is Nate Nelson. I'm here with Andrew Ginter, the vice president of Industrial Security at Waterfall Security Solutions.

He's going to introduce the subject and guest of our show today. Andrew, how are you. I'm very well, Thank you, Nate. Our guest today is Naomi Schwartz.

She is the VP of Services at Medcrypt, and we're going to be talking about cybersecurity for medical devices, talking about regulations for cybersecurity and medical devices, everything from MRIs to pacemakers to the blood sugar testers that diabetic folks use every day. Then, without further ado, here's your conversation with Naomi. Hello Naomi, and welcome to the podcast. Before we get started, can I ask you please to say a few words of introduction about yourself and about the good work that you're doing in midcrypt.

Sure. So, I'm Naomi Schwartz. I'm the vice president of Services at ncrypt. We are a medical device cybersecurity specialty firm.

I joined Medcrypt two and a half years ago after a six and a half year stint at the FDA in the Center for Devices and Radiological Health here in the US. I was a former pre market reviewer and a consumer safety officer. Most people at FDA wear both hats, so you do pre market and post market management, and I had particular focus in software, cybersecurity, interoperability, and wireless coexistence for connected diabetes devices. I was a member of a team that received a large number of awards, including Commissioner's Special Citations and the Samuel Hyman Service to America Metals for Management Excellence because we took a very innovative approach to regulatory science.

In our review group. I'm also a former defense contractor. I spent fifteen years developing complex radar systems and jammers for live field tests with operational DOOD assets. What that means is, I don't just bring a theoretical and an academic perspective to evaluating whether somebody has done a good job of testing their software, their hardware, software integration, their cybersecurity.

I've actually built things, and those things are actually still in the operational phase of their life cycle. In some cases. So you know, from my own background an actual electrical and computer engineer, I was kind of a rare bird at FDA, which is largely comprised of more of the biological and chemical sciences in terms of staffing. But what I brought to FDA when I was there was a deep understanding of how to connect things in a way that makes them as secure as they can be given the constraints that we have in our supply chain today.

As far as the company goes, Medcrypt was really exciting prospect for me when I considered leaving FDA, because I wanted to get out there and teach as many companies in the medical device space how to do cybersecurity well as possible, which meant not going to one large company or one small company, but working for a lot of companies. And Medcrypt is really focused. On improving the overall ecosystem and teaching everybody how to do it well, rather than just working with you know, individual company or too and focusing on improving their perspective.

We've never had anyone on talking about either medical devices or you know, the FDA regulations, which I know are are very important in the field of human consumables and medical stuff. Can I ask you, you know you're gonna you're gonna talk a bit about about medical devices. Can I ask you to to, you know, give us a high level intro? I mean, what are these devices?

How do they work? You know? What? What are we talking about here?

I've never had anyone explain this this space to me in one silver words. I mean, we were talking about the you know, pacemakers that are implanted inside the human body. Are we talking about MRIs that are as big as rooms? What?

What are we talking about? And how do they work? Sure? So there's a huge range of what kinds of things are considered medical devices that are regulated by the U s f d A and quite frankly, by regulators worldwide.

In most countries, they're separated and distinguished between in vitro diagnostic devices and all other medical devices. The FDA does not maintain that distinction, but there's some interesting and complicated reasons for it, and it relates back to how standards are written internationally to support the regulation of medical devices. But fundamentally, a medical device could be something as simplistic as a band aid or in other English terminology, plasters, as they may be referred to.

But you know a bandage that you put on, a scrape on your knee that technically could be a medical device. It could be a scalpol for surgery. This is a chunk of metal. It is supposed to have a certain weight, it's supposed to have a certain grade.

It's you know, the specific types of metals used are meant to reduce the reactivity between the patient and the metal component that's used on their body. Or it could be something as complex as a pacemaker as you mentioned, or an automated insulin dosing system, which is actually multiple medical devices put together into a system that functions in a particular way. So really, I mean in a deaf nition sense, a medical device is defined by the US law in the Food, Drug, and Cosmetic Act as a device or instrument or apparatus or implement or machine, contrivance, implant, in future reagion, or other similar or related article, which is intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease in man or other animals.

And then you know there's some extensive language beyond that. It could affect the structure or function of the body of a human or other animals. And it doesn't achieve its primary intended purpose through chemical action, which would be a drug or within or on the body of man or other animals, So it's not dependent upon metabolization to achieve its primary intended purposes. Again, those would be drugs or biologics potentially, So a device here is a pretty wide category of things that used to diagnose, cure, mitigate, treat, or prevent diseases.

And that's very broad. There are there are some limitations to that, but I don't want to complicate things by getting into you know, specific line items that are that are called out separately in the regulation. No, I'm I'm I'm happy just to learn what the rule is not yet, not what the exceptions are, you know for someone Yeah, who's who's you know, at some distance from this. Let you know, let's let's stick with the basics.

And you know, as important as as you know, scalpels are our focus here is industrial cybersecurity. And you know, I'm stretching industrial to include medical, but you know it's it's cyber physical, this is this is important stuff. And then you know, the keyword is cybersecurity. So when you're you're talking about cybersecurity concerns in medical devices, what are those concerns?

What are what are the priorities? Uh, you know when I mean in a power plant, often the rist priorities don't kill anyone. The second one is keep the lights on, you know. The third one is do it all efficiently so we can afford the power.

You know, what are what are we worried about cybersecurity wise in the medical device field, and what are the priorities over there? Sure? So you know from an FDA perspective, and you know, FDA is largely well harmonized with other regulators, So when I say FDA perspective, this largely applies to the rest of the world as well. The FDA is super focused on ensuring that medical device manufacturers are addressing what's called the CIA triad of confidentiality, integrity, and availability for their medical devices.

Now, some medical devices, like a scalpel, don't have any software, they don't have any connectivity, they don't have any cybersecurity risks associated with them. But many other medical devices utilize software in one way or another. They're either software in the medical device that allows the user to operate the hardware and to facilitate user interactions with the hardware or its software. As a medical device, where the software performs the entire device function, and what FDA is looking for is that these medical device manufacturers have evaluated the potential for that software to be the cause of some kind of harm, whether it's harmed to the operator or harm to the patient, and whether they've done appropriate risk management.

Historically, they achieved this through risk management aspects of the Quality system regulation, but that wasn't getting the industry to accelerate their cybersecurity posture fast enough, and FDA collaborated with the United States Congress to put together a regulation that would be passed by law rather than through rulemaking from the agency, and so they got what's called the Patch Act written into the Food Drug Cosmetic Act as an amendment in the Omnibus Act of twenty twenty three, that's the budget funding vehicle in Congress in the US, and that Act says, if you have software, and if it could be vulnerable, which usually goes along with having software, and if your device could be connected to the internet.

These three things are added, you must provide cybersecurity documentation to FDA. If you have only two of the three things, you probably still have to but it's not literally required by law. But if those three things are true, FDA wants you to focus on confidentiality, integrity, and availability. Now, how are medical devices different than traditional IT security and maybe different than OT security in say power, They're not entirely different, right, There's a lot of similarities.

But in IT security, confidentiality is usually king. It's your first focus because you protect client data, confidential data that could cost you reputationally and commercially if it's lost or shared. When it shouldn't be. In OT security, like embedded medical devices, as an example, you want to focus on integrity and availability first because you want to assure that the medical devices operate when you need them to, which is availability, and that they do what they're supposed to when they are operating, which is really what integrity is all about.

Many medical devices don't contain any or not much personal health information or personally identifiable information PHI or PII, which are usually the focus of confidentiality. I don't want anybody to know that my seventy year old aunt is receiving whatever treatment. I don't want that information out there for example. So you're really thinking about protecting information that has some value POTENTI to some malicious actor.

That's not as important in a medical device as making sure that your MRI, which is connecting to a picture archiving and communications or pack system is available when the doctors need to get the scan so that they can figure out, you know, do you have a brain bleed, for instance, and can I get that data into the hands of the doctor who's going to make treatment decisions. Maybe they need to go in and clear a clot out that's causing a backup in the brain and could lead to stroke.

So you need to have availability of those systems, and you need to have integrity. You want to know that somebody can't go in and alter the data. But it might be a good example just to compare a couple different in vitro diagnostics to set up some context. So you might get a cholesterol test as part of your annual physical from your general practitioner.

Most people do. If your results are dramatically different from your past test results, your doctor might request a retest in a few months. An extremely high or extremely low cholesterol result is typically not going to lead to some kind of immediate dramatic intervention, and a doctor's not going to say, oh, you had this nice linear progression where you were getting slowly increasing you know, total cholesterol levels, and suddenly your level is twice or three times as high, which probably will raise an eyebrow, but but not lead to, you know, prescription of a new drug.

They're they're they're not they're not going to. Say, oh, wow, really big number, let's do something about it. They're going to say, that's inconsistent with past results, right doctors. Doctors do that kind of thinking, and that's that's what they're intended to do with it.

So integrity loss with a cholesterol test is not a huge problem. It's not it's not ideal, right, you want to get the right results, but it's not the end of the world. On the other hand, if you're admitted to the emergency room and the medical team suspects damage to your heart muscle, like during a heart attack, they'll request a troponin test. This is another in vitro diagnostic.

It's a different classification than cholesterol because of the risk profile, but that troponin test is intended to confirm the levels of troponin t or eye proteins, and they want repeated tests over time to see if there's a level detected and if it is increasing, decreasing, or staying the same. This is an indication of heart muscle damage and it can help them rule out or diagnose a heart attack or other cardiac conditions. They make decision making immediately when they see troponin levels that are very high and they decrease rapidly over time.

So if you don't have availability, you may miss some of the signals and that may lead to a delay in treatment which could cause longer term heart damage that is not recoverable. Potentially, somebody could have a pretty serious health incident that leads to a need for a transplant, or worse, they may die. So availability of testing in that space is critical, and the integrity of the results has an immediate impact on decision making from your healthcare professional. You know in past episodes, depending on the industry and the application of what we're talking about, Andrew, it feels like there are consistently considerations that are prioritized above others in certain orders, like for example, safety systems.

Whenever they're relevant tends to take first billing, and then you start talking about you know, reliability, availability of systems, and then however lower you get on the tone and pull, you get to like business efficiency considerations. It feels like with regard to medical devices, this ordering is pretty dream in that. Regard to a degree. Yes, I mean what I heard Naomi say is that there's enormous variation in the field about you know, what different devices do, how urgent things are in different circumstances.

But yeah, in you know, critical infrastructure, which is sort of my bread and butter, we talk about safety first, don't kill anyone, don't cause an environmental disaster. Reliability second, keep the lights on, keep drinking water in the taps, and efficiency. Third, it does no good to have drinking water in the taps if nobody can afford to consume it. And confidentiality.

Occasionally it sounds to me like and you know, Naomi is using sort of the first generation confidentiality, integrity, availability language that I think speaks to the same priorities. And you know what I heard her say, and she didn't quite use these words, but what I heard her say was safety first. You know, the device has to be safe, you can't can't kill your patient, and it has to produce a reliable result. But you know, in my understanding, confidentiality, you know, she said, it's often the third priority.

You know, first priorities don't kill anyone. But the confidentiality, in my understanding of her description of it, is sort of a higher priority for the medical world than it is in let's say a power plant, where you know, I'm sorry, there's not a lot of secrets. The you know, the the temperature or the boiler. The steam boiler is the same temperature everybody uses worldwide.

It's it's a well understood phenomenon. So so yeah, it's it is a little bit different. The other thing that I'm reminded of is our discussion I don't know a few years ago with the head of ot security at Airbus, and I asked him this question about priorities, and he was representing a manufacturer. Now in NAIMI is getting into the manufacturing space a little bit later on, but in the manufacturing space, he said, the number one priority is not the safety of the people in the plant.

You go, really, he said, no, the number one priority is product quality. If you mess up a critical component, aircraft fall out of the sky and hundreds of people die, that's the top priority product quality. So we're talking about, you know, medical devices, we're going to get into that, but that's something to keep in mind is, yes, the safety of people producing the devices is important, but the number one priority is not, you know, to avoid producing a device that's going to kill you know, a large fraction of his users.

You know, it's it's a more complicated space than I thought. It's it's always humbling having a subject matter expert on in a new domain. You find out inevitably that the world is a more complicated place than we thought. But I remember, you know, the the topic here is, let's ask you about the FDA rules for medical devices.

I remember, as long as thirty years ago, I was working with a pharmaceutical company that manufactured drugs, and the sense that I had back then was that the rules they were dealing with were not so much you must do X, Y and Z, but rules that were very general, saying you must follow industry best practice. And then the FDA would publish a best practice guideline that well, everybody followed religiously because it was the best practice, and they would update these things regularly rather than pass new laws.

It was just a faster process of updating the guidelines than updating the laws. Is that still how it is? What's it looked like today? Well, so drugs and devices are a little bit different, but it's not dramatically different.

Today, FDA wants manufacturers, whether it's of drugs or devices or food quite frankly, to follow what are called good manufacturing practices, but there's a lot of diversity in how that's actually implemented. So the Food, Drug and Cosmetic Act has specific regulations that talk about, you know, what is in a good manufacturing practice, what does it mean? And part of that is part eight twenty, which is the quality system regulation today. That's going to change in the next year or so.

The FDA is moving to an internationally recognized standard ISO thirteen for eighty five to cover quality system regulation. But FDA, through the. Food, Drug and Cosmetic Act, has specific areas like cybersecurity, where they can go a little bit deeper and be a little bit more prescriptive because good manufacturing practices are evolving very rapidly, and standards don't evolve as rapidly as you know, the threat environment and the practices do, so standards aren't necessarily keeping up and is getting a little more prescriptive, partly through guidance but partly through the explicit statutory authority.

They now have to ensure that cybersecurity implementation and documentation are adequate to ensure safety and effectiveness of medical devices. So it's not dramatically different. FDA tries to not get specific about how to implement, but they do want to ensure that you do implement security. Getting prescriptive is problematic because again, the best practices are changing and evolving with a threat environment, which can be on a daily basis.

But the overall approach and the understanding of how to do secure product development can be generalized nicely and is written into several standards and is largely what FDA is pointing to when they tell you what you should do versus what you must do rulesices. Something you said earlier is bugging me at the back of my head. You talked about Internet connected devices. How many of these medical devices nowadays are connected to the Internet.

How at risk are we The numbers are not explicitly tracked or shared publicly by the Center for Devices in the US. However, I would estimate that somewhere between thirty and fifty percent of medical devices that are submitted to FDA today qualify as a cyber device per the Food Dragon Cosmetic Act. That is, they contain software, they can be connected to the Internet, and the software that they contain could make them vulnerable. It may be higher than fifty percent, it may be quite a bit higher than fifty percent.

But there's a difference between a device that's intended to be connected to the Internet and is explicitly sending data over the Internet by design, and a device that can be made to do so but wasn't intended for that purpose. And that's important because the words in the Act actually states can be connected to the Internet, and a lot of manufacturers say, well, we're not connecting it to the Internet, so it's okay, but they have a USB port. Now this may sound a little bit out there and sci fi e, but it's not a person who wants to play around with your device who finds that you have an open USB port that they have access to, that they have physical access to without drilling into the case or opening it up or anything.

They can plug a commercially available product like the Flipper zero to the USB port. It may require some kind of a connector in order to connect to the USB type that you have on your device, but they can connect it, and that Flipper zero or similar piece of hardware can actually give them the ability to connect us or medical device to the Internet when you didn't intend for that to be possible. There are cybersecurity controls you can put in place to prevent such activity, but if you didn't think about it and you didn't plan for it, you probably didn't implement those controls, and now your device that was not intended to be connected to the Internet may actually be connected to the Internet, which can make it vulnerable and can also give people an opportunity to explore your device over the Internet and try to determine if they can exploit it or reverse engineer it.

So there is a risk there. I'm not terribly concerned that people should all stop using medical devices today because of cybersecurity risks. In fact, quite the opposite. But I do think that people need to be aware that cybersecurity is a consideration in many aspects of their lives that they're somewhat taking for granted today, and that they should be aware that the Food Drug Administration and other such regulatory bodies are out there diligently trying to protect them from these risks.

Of which they're barely aware. You know, there's a risk in what Naomi does that I imagine isn't quite as relevant in most industries that deal with OD security. And I'm wondering, if you have the answer to this, can people outside of organizations in the medical field, hospitals and so on, how difficult is it to obtain one's own medical device that would be deployed in a hospital. I know there are certain devices that are more you know, consumer oriented, and that you can buy them.

But what I'm getting at here is that if you could theoretically obtain for yourself one of these medical devices that we're worried about being hacked, then presumably you can can spend all day and night reverse engineering it such that you know, you could design malware specifically for such a machine, stick a USB into into you know, whoever's you want to attack. It strikes me as more risky than in industries where you know you have most of your machinery and a closed off plant.

Otherwise, it's hard for me to imagine a case scenario where you know some malicious nurse has the technical knowledge to hack a device or you know, a device isn't public enough in a hospital that they even could pull that off, Like how you would really do that in the wild in real time? Two answers there, One is you know, the three answers. Maybe in the industrial space you suggested it might be hard to get hold of the equipment. It might be hard to get hold of the physical equipment.

I mean, if you want to get hold of a I don't know, a two tongue valve into your garage, that it's just logistically physically difficult to get hold of such a thing. And yeah, I don't I don't know, you know, if you can buy these on any kind of secondary market, but industrial researchers, you know, buy stuff on eBay all the time. What's available there, you know old plc's I mean, if you want to shell out the money new PLCs, it's not the physical equipment that they test. It is the automation components, remote terminal units, flow computers.

You know, these these computers do tend to be available on the secondary market for you know, reasonably affordable prices, and they do get pen tested, you know, check for vulnerabilities, et cetera all the time. In the medical space. Again, I don't I don't know. I didn't ask Naomi, but I would imagine that some of the smaller equipment is available just because the space is so huge.

There's there's millions of these I don't know, dosing devices, you know, thousands in in in every large hospital. I would imagine, or at these hundreds in every large hospital, and there's thousands of hospitals around the world. So I would expect that some of the equipment, the smaller stuff, is straightforward to get on a secondary market. But that's that's just me guessing.

What I am also guessing is that the really big stuff, you know, the controllers, you know, forget PLCs, but the devices, the control boards built into MRIs, I mean MRIs are multi ton devices. You can't even get them out of the room they're in without taking them to pieces. So the big stuff, I would imagine it is harder to get hold of. But you know, sort of to the last point you raised, you know, getting hold of something on the secondary market and trying to figure out how to attack it, you know, versus someone malicious plugging a USB.

And to me, the big risk is not that someone malicious is going to plug a USB, WiFi nongle into my MRI or into you know, a diagnostic device whatever. To me, the risk is that well meaning people in the hospital, in the medical profession are going to do this because they think they're doing a good thing, because they think they're going to make the information available to the physician who's on vacation and wants to monitor the patient. You know, they think they're doing a good thing and they really don't understand the cybersecurity implications of what they're doing.

So to me, that's the big risk, not a malicious umus be being plugged in, but you know, a benign intent leaving the device, walking away and leaving it exposed to the Internet for who knows how long because they think they've done a good thing and have in fact put patients at risk thereby. So you talk generally about the FDA regulations, can you drill down in a little more detail. I mean, I'm familiar with NURKSI it's got you know again, the law gives FIRK the authority to regulate cybersecurity in electric sector.

It FIRK delegates that authority to NIRK, who produces the regulations. The regulations go through a long, painful process. They have to be proposed by NIRK back to FIRK has to accept them or reject them. But when they come down, the regulations say things like your passwords have to be this long and that complicated, you need firewalls here, you need intrusion detection there.

They're really quite specific. Is that the case with what the FDA is telling. Us, it is a little bit different. For one thing, what's written into the statute for five twenty four B in the Food, Drinke and Cosmetic Act has only one requirement that is that explicit, and that is that you must submit to FDA a software bill of materials and it is expected to be machine readable.

The other elements that you're managing postmarket cybersecurity vulnerabilities and things like that are more general, but a guidance document that's associated with this spells out in more detail what that means. Additionally, the FDA today manages the quality system following what is called Part eight twenty of the Food, Drug and Cosmetic Act, or the Quality System Regulation, but in about a year they are migrating to following an internationally harmonized standard. Is so thirteen for eighty five and.

That's designed for organizations involved in design, production, installation, and servicing of medical devices and related services. The transition period, though between when FDA made this announcement of moving from eight twenty to thirteen forty eighty five means that manufacturers who have product in multiple markets have to be maintaining a quality system under Part eight twenty until the transition of thirteen forty five for US and under thirteen for eighty five for the rest of the world.

So you're managing two separate quality systems in addition to all the cybersecurity material and that's really burdensome right now. That means that a lot of companies are doing double duty and having people do two sets of documentation to cover these two different areas of regulatory visibility into what they're doing, rather than being able to do it once and be done with it. And that's that's really challenging for manufacturers because they're now adding all of these cybersecurity expectations on top of just documenting their overall approach to quality, which means, you know, reproducible, reliable, repeatable production of whatever the product is with you know, consistent performance.

Let me ask you, I mean you work with medical device manufacturers. You see a lot of different kinds of devices. How exposed are we how you know in practice? How I don't know?

How much trouble are we in How hard is this problem? It's an interesting question. There's a lot of medical devices that are in use today that have been in use for twenty or thirty and sometimes more years. Those devices have more exposure.

Hospitals that use those devices often but not always, implement it security measures to try to contain those systems. An excellent example, University of Vermont Healthcare System had a ransomware attack that happened through email that affected their entire network. Their imaging systems were subnetted. Because these are older systems, they're not typically patchable, they're not well trusted, and they shouldn't be because they're very old and they don't have any security by design.

And those systems stayed online and available throughout the ransomware attack because they were subnetted and basically put in their own little sandbox and not allowed to play with other elements in the hospital ecosystem. The same thing happened with their in vitro diagnostics equipment for very similar reasons. Some of it is older equipment. It hasn't been designed with security in mind.

It is not very trustworthy. Some of these systems are very vulnerable if they are connected to the network without additional protective measures, but because they were subnetted off because the hospitals don't trust them for cybersecurity, especially for HIPO violations, for privacy violations, those systems were available throughout the downtime. The rest of the hospital ecosystem was impacted rather heavily and required quite some time to remediate. So there's some exposure here.

Some of it is managed by hospital infrastructure, some of it is managed by small doctor's. Offices, etc. But there is not enough resourcing in the overall ecosystem to protect against all these problems. And that really means that newer medical devices that are produced today must be designed to have security today and to be maintainable to be secure in the future as the threat environment involves.

So let's dig a little bit deeper. Into those imaging systems that I just mentioned. An MRI system today that is being delivered and installed in a hospital is actually built on site. If you've ever been in an MRI machine, these are really significantly sized machines they don't fit through a standard doorway when they are completely built.

They're very heavy and they are extremely complex systems, so they're built on site. When you have to implement a brand new system like that and you are putting it into your facility, you want to know that it is in good shape to operate today and that you can maintain it for a long time. Because it's capital equipment. It is a huge expenditure, and you do not want to have to replace it in three years because some component is out of date and not secure anymore.

So you want security by design from the day it's built, and you want it to be capable of dealing with new threats over time, so you want it to be updateable. You want a secure patching mechanism that allows you to say, this system is built around Windows ten. Windows ten is about to go end of support at the end of twenty twenty five. I want to know that I can patch this to a newer operating system version like Windows eleven.

And while I use that as an example, it's you know a fact many of these devices are using commercial operating systems, so you do want to have a secure patching mechanism. You also don't want somebody to be able to roll back a patch that is intended to ensure cybersecurity. So there has to be a rollback prevention mechanism. Once I patch this to a new and approved, updated version, I can't go backwards in time and backwards in version to something that is vulnerable and possibly exploitable.

So, Nate, just a quick comment on the incident that Naomi talked about. You know, to me, it's ironic that the most vulnerable equipment in the hospital, that is it by ransomware, the most vulnerable equipment was the least impacted. And it's because the hospital knew that this equipment was vulnerable and so put you know, what they call compensating measures, put secondary protections in place to you know, if there's an incident in the hospital, keep the bad stuff away from this equipment.

You know, the equipment that was arguably more secure, but also thereby more exposure because hospital didn't think it needed to be to be you know, protected to that degree, was more affected. You know, I mean, Naomi is we're talking here about medical devices and manufacturing medical devices. Hospitals use medical devices. But you know, maybe we need to get somebody on in the hospital.

To me, this scenario suggests that that you know, hospitals know how to put you know, at least basic cybersecurity in place, they know how to put effective cybersecurity in place, and if they use that knowledge more routinely, more extensively, we would have fewer outages affecting equipment in hospitals. But so that you know that, I guess we need a different guest to talk about hospitals. We should we should you know, come back to the medical devices here. A big thing that's happening in the world of industrial cybersecurity is something called cyber informed engineering.

And one of the principles, there's many principles in sovereign front of engineering. One of the principles is wherever practical, have an unhackable and electro mechanical safeguard as sort of your last line of defense between you and disaster. And so, you know, if I apply that thinking to let's say, you know, a medical device like let's say a pacemaker or something, you know, I would naively imagine that, you know, inside the body, you could route I don't know, a wire from the heart to somewhere close to the you know, just under the surface of the skin.

You don't want to break the skin. That's an infection risk, is what I assume. But you know, you might have a little switch in there so that if you want to, I don't know, reprogram the pacemaker, the doctor has to touch you, touch your skin, press the switch under the skin, activate the wireless component in the in the pacemaker so that they can reprogram it. And the rest of the time is physically got no power and cannot communicate with you.

To me, that would be CIE. That would be sort of engineering grade protection. Is there such a concept in the world of medical devices? There are very similar concepts electro mechanical safety backstops like that could be problematic on a person because you could accidentally bump your body and trip off the electro mechanical backstop.

However, you know, historically what was done with implantable pacemakers, as an example, was that you had to do something specific to activate their programming mode. So you would send them an RF signal and they would have to wake up, you know, and then they would enter an interactive mode where you could go in and reprogram them. Now, a pacemaker is intended to make a slow heart beat faster if you shut off the pacing for patients who are pacemaker dependent that their heart isn't working quite properly and it's not eating at a high enough rate for them to retain consciousness.

If you increase their heart rate too high, you can actually be causing some kind of muscle damage to the heart. So there's a balance in there, and you do want to protect it, and you want that programming mode to be exclusive to people who are authorized to engage it. But there are new ways. To do that.

It used to be we just sent an RF signal and the thing would say, okay, I'm ready, tell me my reprogramming mode. And if you were nearby and happen to have. RF sniffing equipment, which is not that complicated to procure and not that complicated to operate, you could collect the entire interaction between these two components and potentially replay it, and then potentially modify it and replay that and put the system into a reprogramming mode and then reprogram it in a way that's not in the best interest of the patient.

Today that has been moved from broader RF, which you can do from thirty forty feet away potentially to near field communication modes or inductive activation modes where you have to bring a strong magnet or a device into really close proximity to the body. We're talking tens of centimeters or less in order to activate the programming mode. But even then I'm that close to you on the subway. You don't want somebody who happens to have the right equipment and the right know how to activate your programming mode on the subway.

So you want some additional measures, some added layers of complexity and cybersecurity in there. So you put in measures to authenticate and to ensure that only an authorized user is actually trying to make this connection to get the pacemaker first into programming mode and then to accept the commanding it's getting. So it's a defense in depth constant in medical devices that is very similar to cyber informed engineering, but not reliant on electro mechanical safety switches that could be jostled or bumped as part of your normal daily operating as a human body, right because you know, unlike critical infrastructure, where you have static pieces of hardware mechanically active pieces of hardware, but they're largely separated from each other and they're not moving into each other.

The human body is moving around a lot, and maybe you're bumping your arm where you have an implant. There are implantable cgms that if you bump them, they continue to operate because they're under the skin. But the component that sits on the outside of the skin that pulls the data off of them inductively, that can be knocked off. You can pull it, you know, pull it out, take the glue off, and put it back on your arm.

But you don't want that to be the electro mechanical safety backstop because you can bump it and and at some point you will and that could cause harm as well. You know, we talked a lot about manufacturing the devices, but I'm curious, is there anything in the medical field, in the FDA field that is analogous to the new European CRA. I even forget what it stands for, but it's the rule that one of the rules in the CRA regulation applicable Europe wide is that manufactures of devices that contain software.

In my understanding, are you will starting I don't know, twenty twenty seven or something when the rule comes into effect, will be required to provide security updates for free for the life of the product. You know, is there such a concept about sort of lingering obligations on the part of the manufacturer. Absolutely so. The European Cyber Resilience Act is intended to ensure that products are secure when they're delivered initially and that they're maintained for the lifespan of the device, whatever that may be, commercial product or otherwise.

The FDA has a pre market guidance that tells you what to do to make sure it's secured by design, when it's made and when it's sold, but they have a post market guidance that says you need to do certain things to ensure that this system is not only safe and effective and secure on the day it's delivered, but it's safe, in effective and secure for the lifespan of the device, which may be to your shelf span in ten days after you start it operating and. You activate it. It may be to your shelf life and a twenty year lifespan after it is activated and in use.

So you need to account for today's cybersecurity threat environment with your security. You need to account for a secure patching mechanism to ensure that the product can be maintained of that lifespan, and you need to have some tools and some processes that enable you to identify new security threats that exist, new vulnerabilities in the system as you've designed and built it, and to react to those, to make decisions about software patches that need to be applied, hardware components that maybe need to be switched out, that you have an appropriate supply chain and you can actually handle these kinds of changes in software or hardware.

And really the call to action to industry then is design your systems to be patchable from day one. Design them to be secure at the time that you are delivering them, but secure a ble over that longer term span, and that's not necessarily easy. That means you also need to. Find vendors and tooling that enable you to monitor your software bill of materials, your hardware bill of materials, and make decisions about patching.

That means that you need to have good cryptographic methods to secure your patching itself, signing your software, making sure that you have authentication and authorization in place, and that you're monitoring that software build of materials, reacting to new vulnerabilities, determining whether or not they affect you, making decisions about patching when you determine that they affect you. That's an entire risk management process that needs to exist, and a lot of companies are struggling with this.

They don't have good tooling. My company has developed some tools for that. They don't have good processes. Companies out there are struggling to figure out how to write a good policy.

These are things that can be put together, can follow standards, which means you're using best practices, but sometimes you need help. And so the really the strong recommendation is if you don't have internal staff that can handle this, find yourself a qualified vendor with the appropriate expertise so that you're managing your quality system obligation of vendor qualification and you're getting cybersecurity experts who actually know how to implement things properly to help you build out your program.

So that sounds good in theory. I'm curious though, and I haven't got a good answer for this for the cra I'm curious. In the medical field, Let's say we have a device that usually has a twenty year lifespan. You know, the manufacturer sells the device, and five years later the manufacturer goes bankrupt, and vanishes.

What you know, does the FDA require all of the hospitals that use the device to throw it out because nobody's issuing patches for it? You know, are consumers who use the device supposed to throw it out? Now? What happens when these vendors that are supposed to provide service for the life of the product vanish.

Oh, that's a great question. That is a conundrum in any industry. That's a conundrum whether you're talking about commercial products or or something more complex and less easily obtained like a medical device. The short answer is that FDA does not regulate what hospitals do.

They can't, they're not authorized, and they shouldn't because that's not really their space. When they regulate medical devices, they're regulating them for today and ensuring that they're patchable long term. But there's no impact whatsoever in there no ability to impact what happens with economics and whether a company goes bankrupt and stops selling their product. So that comes back to the contracts that are written between the vendor and the procureur and whether or not they have some kind of protective measure in place.

But there's not a lot of protection for a hospital that's procuring, you know, an MRI from a vendor, just like you know, consumer goods. If you bought a computer from Compac a decade ago, that company may not be selling any products. Today under that brand. They may have been acquired by somebody else, and maybe that company has promised to maintain those those pieces of hardware, but they they aren't necessarily on.

The hook anymore because they don't exist. You know, I can think of dozens of computer companies where that has been the case over the years, and the consumer is kind of out of luck with a hospital that's procured a piece of MRI equipment. Oftentimes, small companies pop up like mushrooms after the rain, offering to maintain these systems and have procured some of the residual hardware that was sold off. As these companies undergo bankruptcy and you know, try to deal with their assets and balance sheets, so you end up with vendors who are non oem who are trying to maintain these things.

But that ends up being a cost plus problem. Right the hospital invested in the component and now they have to separately invest in a new vendor to maintain it. That's still cheaper than buying a brand new one from a different vendor. But that's part of the vendor qualification process at a hospital is making those decisions.

Do we trust that this company will be around for a long time? And if we're not sure about it, does that make it us less likely to buy from them then from competitor A or B. So when you talk about security, though, you know cybersecurity maintenance of these products comes back to largely to software but also to hardware, and you want to know that the security that's built into the system is reactive to all the software component And many of these are off the shelf or open source and may eventually stop being maintained.

You want your vendors to give you some confidence that, hey, if Windows stops maintaining an operating system, you can either update the operating system or you can take over maintenance of it. Now, do you really want to maintain the source code from Microsoft operating systems? Probably not, but there are people who can and do that as a service. So procurement decisions need to be driven by cybersecurity awareness, and there's some methods to do that.

There's some model contract language for medical device cybersecurity out there, it's actually called the MC two that enables procurers to make those kinds of decisions about medical device cybersecurity. If I recall, I use this analogy in our last episode maybe or a recent episode, but it goes back to the refrigerator analogy, Andrew what you guys were just talking about in the interview. If I have a refrigerator, it sits in my kitchen for over a decade, the company goes out of business in the meantime, am I still expected to patch?

I mean what Naomi said, I think the analogy she used was like other companies sprout out to fill the gap, like mushrooms in the rain. Is that? But that also requires effort on my part to like find those companies. And it's just a weird situation.

It is a weird situation, and it's different for consumers versus hospitals versus you know, industrial operations for consumers. You know, I don't think the question has been answered. The CIRA, you know, tries to protect consumers, but bluntly, when was the last time any of us patched our fridge? You know, it's not done.

These patches have to be automatic or they're not going to happen. If the vendor goes out of business, who's going to take over the automatic patching system? You know, if I have a fridge, If I don't, I currently my fridge is very old. If I had a fridge that was Internet connected and the vendor went out of business, I would probably you know, but this is me.

I'm a cybersecurity guy. I would crawl behind the fridge and rip out the antenna so that it cannot be reached by the Internet anymore, because I don't need anybody sabotaging my fridge. Well, other consumers do that, probably not, but we're not talking consumers here. We're talking hospitals.

And you know, hospitals have people on staff with some degree of you know, industrial cybersecurity knowledge. Take the example of the hospital that was hit by by ransomware and the imaging equipment, the most vulnerable equipment had been secured with secondary defenses and was the least affected by the incident. This is commonplace in the industrial world. I'm hope it's commonplace in the world of hospitals.

If you have something where you know the vendor's gone out of business, you know, you know it's not going to get patched anymore. It sounds like hospitals already know enough to put secondary defenses in place. I'm not sure they need to go to a secondary market to buy patches. I'm not sure it's practical to buy those patches.

You know, secondary vendors might pop up like mushrooms in the rain. But it's one thing to take the source code and say, oh, here's a vulnerability. Let me change the source code so that, you know, I check for the size of the buffer before I write into it. It's another thing to say, okay, I've changed the source code.

Now the device is still secure. Rather, it's still safe. Well, you have to test the device. Well, do you have the hardware?

Do I have an MRI in you know? Can I go to the the business that's gone out of business and buy all of their MRIs and set them up in my garage so I can test the software before I release it and say it's safe. You know it it starts to fall apart and again in the industrial world, we routinely apply secondary defenses bluntly. In a lot of industries.

Yeah, the law might require the vendor to produce patches hither and yon, and those patches never get applied because long ago the industry said nuts to this. These devices, you know, even if they're fully patched, are still too sensitive, and so they put additional layers of defenses in. They put Uni directional gateways, they put firewalls, they put encryption, they put VPNs, and make the devices just that much harder to compromise through these secondary defenses. You know, it's frustrating for vendors to produce patches that no one's ever going to use.

I don't think the question has been answered. It sounds like, you know, what Naoma's telling us is that there's this same tension, the same debate, if you like, to some extent or another, going on in the medical device industry as there is in every other industry that patches physical physical devices. Thank you so much Naomi for joining us. You know, before I let you go, can I ask you, you know, can you sum up for our listeners?

What are the key lessons here in the world of medical device cybersecurity. So there are a couple of key takeaways. The first one is when you're designing new medical devices, or if you're in the middle of designing a medical device today and you're partly into the development timeline. Have you thought about security.

Have you designed security into your medical device? It's never too late to add security, but it's really best done at the beginning of the design process. It is more functional and more operational and more effective if it's designed in from day one. You can tack it on towards the end, but it's not ideal that in that way.

If you're struggling to understand and how to do that, if you're a very small company and you don't have any security staff, find help. Get help in understanding how to secure your devices. Get design help, get implementation help, get documentation help. Because this reduces your company's overall risk in the long term.

It reduces the risk to your users, to the patients who are affected, and it reduces your reputational and your business risk, and these are all important things. Documenting your approach well is especially important because regulatory bodies are really ramping up their scrutiny. Before you can go to market, you have to convince not only the US FDA and Health Canada, but the notified bodies under EUSE MDR or IVDR that you have actually done secure by design and that you can maintain this thing for its lifespan, so it's pre market and it's also post market.

What other things can you think about? Educate yourself. You can download white. Papers at medcrypt dot com.

We have a YouTube channel. Just search on YouTube from medcrypt. We have an entire span of webinars that we have offered. They are free.

We want to educate people, so the information is out there and available no paywall, so that people understand what is expected by the regulatory body, what is expected by your customers, the hospitals out there that are really sophisticated or asking difficult questions during procurement. Make sure you've got your device secure today and that you can maintain it, because if you can't maintain it security, you could be subject to liability issues, and you could have patient data breaches, and all of these things lead to other risks with other regulatory bodies.

Than the FDA. So really secure your systems. If you need help, find somebody, find a professional who can help you do it. If you need to educate your staff and your stakeholders, pull from our vast repo of webinars, white papers, blog posts and learn about it and understand what is possible.

So that just about does it Andrew for your interview with Naomi as usual. Is there a word you would like to take us out with today? Yeah, I mean a few things. Regulations in the space seem, on the surface, seem rather more intense than I see in other industries and critical infrastructures.

So I kind of expected that, but you know that, you know, Naomi's confirmed that. I heard Naomi use and you know, echo the language and the regulations talking about confidentiality, integrity, availability, that is sort of first generation terminology, and the industrial securities is we've since moved on saying, you know, it's not primarily information that's the asset, it's the physical asset. What we need to assure is safe, reliable and efficient operation of the physical asset.

And you know cybersecurity is essential to that operation. You know, I would I would have, you know, to me, it would make more sense if you had terminology like that in the medical space as well. And I actually heard and I only say something earlier in the in the interview that I wanted to repete here. She talked about, you know, medical devices must be safe, effective and secure.

So safe, yes, you know, the hypocritical you know, first cause no harm, effective, is sort of the domain of the FDA. You're not allowed to sell devices. You're not allowed to be a quack and be out there selling a magic elixir that does nothing. If you want to sell a medical device, it has to be effective for the purpose that you advertise it.

That that makes sense, and secure sort of wraps up. It's sort of a recursive definition. But you know, I understand that there's elements of confidentiality, there's elements of you know, sabotage prevention. We've got to prevent sabotage that renders the device unsafe or that you know, deliberate misoperation that renders the device ineffective.

To me, that language makes more sense, So I would, you know, I would you know, hope that over time that the the the industry evolves their language as well to make sense to tow meremortals like me. But you know, she did, she did say those words. That's something I've been I've been pondering. So that's what I took away from it there.

You know, it's it's an intense environment. Cybersecurity is important. There's a lot of similarities, especially on the patching side, with debates that are going on in the industrial space, and you know, safe, effective and secure is is something I'm going to think about, as you know, should these really be these the right guiding principles? Is this debate even happening in the space?

You know, I look, if there's other practitioners out there, reach out. I'm on LinkedIn. You know, we'd love to have other perspectives on the show. So, you know, thank you to jaying Me, thank you to you.

Yeah, thank you to Naomi and Andrew, thank you. As always, it's been a great pleasure. Thank you. This has been the Industrial Security podcast from Waterfall.