Speaker 1: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: Then, without further ado, here's your conversation with Naomi.
Speaker 3: 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.
Speaker 4: Sure.
Speaker 1: 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.
Speaker 4: In our review group.
Speaker 1: 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.
Speaker 4: In some cases.
Speaker 1: 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.
Speaker 4: And Medcrypt is really focused.
Speaker 1: 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.
Speaker 3: 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?
Speaker 4: Sure?
Speaker 1: 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.
Speaker 4: This is a chunk of metal.
Speaker 1: 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.
Speaker 3: 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?
Speaker 4: Sure?
Speaker 1: 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.
Speaker 4: When it shouldn't be.
Speaker 1: 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.
Speaker 4: Most people do.
Speaker 1: 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.
Speaker 4: They're they're they're not they're not going to.
Speaker 1: 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.
Speaker 2: 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.
Speaker 3: 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?
Speaker 1: 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.
Speaker 4: But FDA, through the.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 4: Of which they're barely aware.
Speaker 2: 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?
Speaker 3: 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.
Speaker 1: 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.
Speaker 4: Is so thirteen for eighty five and.
Speaker 1: 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.
Speaker 3: 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?
Speaker 4: It's an interesting question.
Speaker 1: 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.
Speaker 4: Offices, etc.
Speaker 1: 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.
Speaker 4: So let's dig a little bit deeper.
Speaker 1: 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.
Speaker 3: 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?
Speaker 1: 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.
Speaker 4: To do that.
Speaker 1: It used to be we just sent an RF signal
and the thing would say, okay, I'm ready, tell me
my reprogramming mode.
Speaker 4: And if you were nearby and happen to have.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 4: You activate it.
Speaker 1: 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.
Speaker 4: That means you also need to.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 4: Today under that brand.
Speaker 1: 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.
Speaker 4: The hook anymore because they don't exist.
Speaker 1: 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.
Speaker 4: But that ends up being a cost plus problem.
Speaker 1: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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?
Speaker 4: Educate yourself. You can download white.
Speaker 1: 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.
Speaker 4: Than the FDA.
Speaker 1: 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.
Speaker 2: 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?
Speaker 3: 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.
Speaker 2: Yeah, thank you to Naomi and Andrew, thank you.
Speaker 3: As always, it's been a great pleasure. Thank you.
Speaker 2: This has been the Industrial Security podcast from Waterfall. Thanks
to everyone out there listen