So our next speaker is part of the healthcare security and privacy expert. He is an active
member in the security community. He is also an author of such books as Visual Basic and
Visual Basic.net for scientists and engineers as well as Pro Pearl parsing. And he is the
project lead for OWASP's anti ransomware guide and OWASP secure medical device deployment
standard projects. Now here to present his talk, standardizing the secure deployment of
medical devices, ladies and gentlemen, Chris Frentz. Thank you. It should come as
no surprise to anyone in this room, but hospitals are routinely pretty insecure. And
going back the last few years, there's been a number of healthcare data breaches. We see in
2015, MIT announced it was going to be the year of the hospital hack. We had a bunch of major
breaches throughout 2016. And a lot of the security risks in hospitals were further
emphasized with all of the ransomware attacks that were predominant last year within
healthcare. The first being Hollywood Hospital, roughly March of last year. They were
brought down for several days and ended up paying $17,000 to recover all their data. So we're
going to talk about medical record data. And that was the first of many, many hospitals. We saw a
similar trend with MedStar following shortly afterwards, as well as many other hospitals
throughout the U.S. Now there's several reasons why hospitals like these and all other
hospitals make prime targets for attackers. Number one being is medical record data is
actually worth quite a bit. Much more so than a credit card. You steal a credit card number, you
might get a few thousand dollars out of the account before the bank notices the fraud and cuts
you off. You might get a few thousand dollars out of the account before the bank notices the fraud
and cuts you off. A medical record has a lot more useful data. It could be used for much more
comprehensive identity theft, because it contains social security numbers, all kinds of other
stuff in it. You could establish false identities, open lines of credit with it. You could use it
for insurance fraud. You can even use it to buy pharmaceuticals and medical devices that you
could then resell for profit. So there's lots of things you can do with medical data that make it
quite, quite valuable. And a lot of it, too, can be valuable in ways that you wouldn't normally
expect. Like, for example, to get a medical record, you have to have a medical record. You can
get a visa to the U.S. from a lot of different countries. They require a clean lung x-ray. And
in countries where tuberculosis is prominent, like China and stuff like that, there's actually a
huge black market for clean lung x-rays right now. So medical data can often be used in a lot of
ways that you wouldn't typically expect. So that's one thing that makes hospitals a fairly
ideal target for attackers to go after. The other and more concerning thing that makes hospitals an
ideal target is, within health care, there are still a ton of bacteria that are tested against
legacy systems. If we think about it, a lot of medical equipment is quite expensive, it's hard
to replace, and it was designed with doing whatever clinical function it had in mind. It might
do that clinical function well, might have a 10, 15 year life span in which it still does that
clinical function very well. But a lot of that equipment was not built with security in mind. We
see that in a lot of medical devices now. We're seeing reports almost daily of medical devices
being vulnerable to hacking. There's been a number of demonstrations, even at this conference
here, of various medical devices that were easily exploited. In the news recently, we saw
both Hasbira, they made the news for the FDA recall for their infusion pumps, and we're
probably all familiar with the issue with some of the St. Jude pacemakers that were also all
over the media. Going back for some other examples, some medical devices, because of the
usage of Windows XP and other stuff, it was found to have over 1,400 vulnerabilities,
and just one system alone. This raises a lot of interesting questions, because a lot of the
previous attacks, they focused on patient data, but what would occur if attackers targeted
medical devices instead? And this was largely theoretical until about two months ago, when
WannaCry broke out. We're all pretty familiar with it. It was pretty much a pandemic ransomware
attack. Could have actually even been much worse than it actually was if the kill switch wasn't
found in time.
But even so, many, many companies throughout the entire world, you can see the map there,
showing where they were struck. It was quite widespread, brought a lot of companies down, and
most telling in healthcare actually occurred in Britain. Their National Health Service pretty
much was brought to its knees by the WannaCry virus. But the malware and stuff outbreak wasn't
unique to healthcare there. Hospitals throughout the world were affected, including in the U.S.
But one of the distinct things that's different about WannaCry than a lot of past ransomware
outbreaks is past ransomware outbreaks targeted the computer systems that housed patient data,
which while that still has an impact on patient care, one of the interesting things about
WannaCry is WannaCry actually spread to the medical devices themselves. Very, very different. A lot
of radiology equipment in this particular case was actually brought down by WannaCry. Those systems had the
same vulnerabilities that a lot of the computer systems affected by WannaCry actually had. Because if
you think about it, all of these medical devices, basically under the hood, they are computers.
They're either running some form of Linux or some form of embedded Windows. But those same
vulnerabilities we find in our PCs, they're going to be present in these medical devices as well.
And this is pretty scary because it really can give a whole new meaning to the term denial of
service in a way that really could cause somebody to die, depending on what the device, you know, the
device actually is. You know, if you have a stroke patient coming in and they can't get the cat's gun
down in time to determine if you need surgery or something else like that, it could have fatal
consequences. If a heart monitor misses a defect, the patient goes, starts to have a heart attack, the
nurse doesn't notice because the monitor was shut off or brought down by some kind of virus. There's
many indications like that where you could have potentially lethal outcomes. Okay. Now the question
is, is what to do about it.
There's a lot of information out there. There's a lot of information out there. There's a lot of
organizations, thankfully, that are starting to look at it. One is I Am the Cavalry. About two
years ago they released their Hippocratic Oath for Connected Medical Devices. And basically it
covers things that manufacturers can do to help make devices more and more secure. Through a lot
of their efforts to improve medical device security, I know they've been working with the FDA,
and the FDA also has released a lot of guidance within the last couple of years. Some things
about the FDA guidance, they released both premarket and
post-market guidance. Basically that makes security recommendations for medical devices. Okay.
The premarket guidance is mostly in terms of how the devices are manufactured. The post-market
guidance mostly deals with things like keeping devices up to date and other stuff companies
should ideally do once the device is put on the market. Now this is a huge, huge step in the
right direction. Very essential. But one of the, I guess, downsides right now is the guidance is
currently non-binding. So it's a recommendation to manufacturers. It's a recommendation to
manufacturers, but not something they legally have to follow yet. And my other concern with this
type of stuff is if we think about it, even if manufacturers comply with all this guidance
tomorrow, they make the theoretically perfectly secure device starting tomorrow, there's still a
lot of medical devices that are going to exist for a long time in hospital and health care
institutions that are not going to be replaced overnight. You know, in many cases these systems
cost hundreds of thousands, millions of dollars depending on the systems that are going to be
used. And no hospital has the budget to go about and replace all their devices because a new, more
secure model came on the market. So even in the perfect world where everything became secure
tomorrow, which is not going to happen, it's still going to be years and years before all of the
older and secure devices are removed from our health care institutions. So the real question is,
is what can we do now to help make medical devices more secure? What can we do in our current
environments?
Okay. So how do health care institutions that have current deployments, where replacing them
tomorrow is not going to be a possibility, what can they do to make devices more secure? And on
top of that is even if we assume these perfectly securable devices will one day come to market,
you could have a device with all the security features in the world in your environment, but if
you don't take the time to configure and deploy it properly, it's still going to be highly
insecure. So one of the things that was heavily lacking was a standard for how hospitals should go
about and securely deploy medical devices. Okay. And that's one of the things a lot of my work is
focused on. I did release the standard through OWASP, but basically what the goal of this project
is, is it's designed to complement the work done by the FDA, complement the work done by I Am the
Cavalry, and not focus on the manufacturing side, but focus on the hospital side, on the actual
people who will be deploying these devices. Okay. Now some of the things that we've done in the
guidance, I'm not going to go through every control in depth. There was the Google link in the
preceding slide, and I'll make the slides available to anybody who wants them. But one of the
first things I think should be touched upon by hospitals is purchasing controls. This is one of
the most effective ways to get organizations to change over the long term, to get manufacturers
to increasingly adopt security and put security into their products. So in my opinion, any
hospital is going to be acquiring new medical devices. One of the first things that we're going to
do is they should audit the devices that they're going to buy for both security and privacy.
Which devices, before they purchase them, are going to best meet the needs in terms of keeping the
data secure and keeping the patients secure. And when doing this, organizations should remind
doctors and stuff that that is a big part of patient safety nowadays. Because if the device is
not secure and it goes down, that really can put patients at risk. So that needs to be considered
as well.
In terms of evaluating the patient, the privacy and the security controls, some of the other
things to consider is also this long-term support for the device. Which vendors are willing
to provide patches and other stuff over the long term for those devices? Because the reality is,
is these devices do have 10 to 15 year lifespan sometimes. So which vendors are going to
continue to keep those platforms under support? And another recommendation, not going to go
into the guide yet, but what I'm going to add in the next version of the guide, is I think when
people do buy these devices, they should request a list of all the software components that are
contained in the device. Because it's not uncommon to find that even if they have an up-to-date
version of Windows or Linux or something else in the device, that they're using an ancient
version of Apache or some other old library and stuff like that. And having a list of all the
components can help you in your security auditing. So my number one thing, and I think more and
more hospitals should do it, is vote with their wallet. And only if you have a device that's not
a security device. And only bring devices into the environment that do meet some semblance of
security and privacy principles. Additionally, one of the scary things, particularly exposed by
WannaCry, but exposed in other sources as well, is a lot of the medical devices that were
brought down by WannaCry were brought down because they were publicly accessible over the
internet. Now that's pretty scary because in 99% of the cases, there's probably no need for
those devices to be run. So if a device is being used to run it, you can get a lot of data, but it's not going
accessible over the Internet. So, I mean, not going to go through in depth with a firewall,
that kind of stuff is, but taking basic mechanisms to ensure that your medical devices are
not publicly reachable, pretty simple, straightforward security control, missing in an
awful lot of hospitals. So one section of the guide does go through different perimeter
protections you can put in place to ensure that these devices are not publicly available. And
if they do need access to the Internet and other stuff like that, things you can do to actually
control and restrict access to just what is needed.
Additionally, just like you should have defense at the perimeter, a lot of organizations fail in
this area as well, is these devices do not need to talk to every other device on your network.
Yes, all modern medical equipment is pretty much network enabled, often for perfectly valid
reasons to improve patient
care, because, you know, let's say you have a heart monitor sitting on a patient, and, you
know, the heart rate can automatically be sent to a nursing station where the nurse is monitoring
it, and having that kind of stuff networked, it can improve response times much better for
patient care. There's a lot of valid reasons for having this equipment networked. But the
output of that heart monitor does not need to go to every device in your organization.
Likewise, every device in your organization does not need to connect to that particular heart
monitor.
So a lot of the controls here focus on, you know, very basic network security, but stuff you often
find lacking in a lot of hospitals, basic things like network segmentation, taking time to do
vulnerability scanning of devices you have inside, making sure they're secure, making sure patches
are applied, things like that. Very basic controls we commonly reply to, regular desktop endpoints
or servers in our environment are oftentimes missing from medical device deployments. So this
section here, basically,
advocates putting those types of controls inside. And even things like internal firewalls and stuff
like that, you know, if you're going to spend three quarters of a million dollars on an MRI machine,
spending an extra $300 on a small sonic wall to put in front of it and protect it is really not,
you know, too much to ask. So, okay. Now, device security controls. What are the security
controls that should be configured on the devices themselves? And, yes, once again, a lot of
these things are very, very basic. Changing the default credentials on the device, changing the
default password on the device. It should be common sense to do, but if you look at a recent outbreak
like Mirai, it was a list of pretty much 61 passwords that were used to compromise hundreds of
thousands of devices. So, in a lot of cases, just having basic mechanisms like this in place can be a
huge improvement. So, you know, there are basic controls to prevent attacks similar to what we saw at
Mirai, like changing default credentials, account lockouts, things like that. But there's a lot of
other things that hospitals don't think of to do. Like, let's say you have something like WannaCry,
hit your environment. Do you actually have a spare copy of your firmware? How are you going to
restore that device to a functional state if it's taken down? Much better to prepare for that kind of
stuff ahead of time, be ready for it, than to go, uh-oh, I have no way to recover this device once
an attack hits. You're having a backup of your configuration. Okay, maybe you applied the new
firmware. You got it back in place, but that device probably had special settings to make it work
in your environment. Do you have those backed up as well? Things like that that can help you
recover from an attack.
Baseline configurations, make sure things are deployed securely. Having the ability to encrypt data,
things like that. Having update mechanisms in place, making sure that you do go around, have the
latest firmware on each device. Compliance monitoring to make sure devices stay secure. Physical
security, make sure the devices can't be tampered with. And also things like asset management as
well. You'll find in most hospitals, if biomedical devices were to come under attack, it probably
wouldn't be IT or security that was notified right away. It would probably be the group that
handles the medical devices. And what they'd probably do to start is they'd probably swap the
device out for a new one and wouldn't even think to troubleshoot it. So having proper asset
management in place if you were to come under attack would be good because it would help you
track what devices were compromised, what were not, and help you from putting an affected device
back into production. Okay. Another thing you'll find in a lot of medical device deployments is
they're either what they call an interface or central stations that the devices connect to. So
basically how I'm going to define the central station is let's say you have a series of heart
monitors. There's going to be a computer that all that data is going to. Okay. So it's used to
collect and analyze a lot of the data collected by these devices. And that may function as an
interface even if you have an isolated network for your medical devices where that particular
computer is then used to send data off to your medical record system or something else. So you
might have proper network for your medical system. You might have a network for your medical system.
You might have network segmentation and everything else. But this particular interface device
is going to be a potential weak point because that's going to be what links the rest of your
production network from your isolated medical device network. So you want to make sure that
there's proper steps here as well in order to secure the devices. Things like standard OS
hardening, making sure the data is encrypted as you transport it. Basically have message
security in place and that once again you keep these devices and all of the software in place.
The software that runs on them is up to date as possible. This is an area I particularly like,
there's a lot of recommendations that we have so far, but I don't think you can consider anything
secure until you actually go ahead and test it and prove it's secure. Yes you might have put a
great firewall in, you might have put a bunch of rules in your firewall, but how do you know those
rules actually do what you think they're doing unless you actually go ahead and actually go
ahead and test it. So I'm a big advocate of once you actually have these systems, have a few rules,
actually do these deployments once you put the controls in place that you actually go ahead
and run a penetration test. See, does my security actually keep this device secure? I'm also
big on having instant response plans done ahead of time and I'm very, very big on doing mock
incidents to actually run through scenarios where you will actually simulate the device being
under attack. How would you respond to it? You don't want a situation where the first time
you're dealing with an incident is when the incident actually happens and people are lost and
don't know what to do because they've never run through the drill before. You can actually see a
screenshot here. It wasn't done for medical devices, it was done for desktop PCs, but it's an
incident that we actually did at the hospital I work at. We actually did take over some desktops.
I changed out Explorer EXE for another EXE that popped up this ransomware screen. And we
actually saw how IT and the staff actually dealt with a simulated ransomware outbreak like
that. So I'm very, very proud of that.
I'm very big on actually testing stuff ahead of time. Okay. Now some things about the
standard is it is starting to gain some attention. So there is some growing adoption. It's been
covered in magazines such as CSO Magazine, the IAPP Privacy Perspectives, Health Net
Security, Health System CIO, a few other things. Also pretty interesting is it was recently
translated into Turkish because the Turkish Ministry of Health is actually considering adopting
some of the recommendations as part of their own internal policies. So that's pretty interesting.
And hopefully the adoption of something like this continues to develop and continues to grow because
I think it's a heavily unaddressed area of security right now. Just as a side note, if anybody's
interested, doesn't directly deal with the talk, but I'm also the author of the OWASP Anti-Ransomware
Guide. And that's another guide. It has a set of 45 different controls in the categories. They are
designed to protect an organization against ransomware using a defense in-depth approach. At this
point, I'll take any questions.
Some devices have been taken home and they control and plant medical devices. Obviously, you can't have all that primitive stuff over there.
That's true.
Through iPhone applications and stuff. Can you speak about that?
Sure. Most of the framework I've laid out so far.
Some devices, the patients take them home, they connect to implantable medical devices. In fact, some software may be like on iPhones. So you can't have this level of perimeter security with it. They may have to talk back to the medical provider. Could you give some advice on that? Thank you.
Sure. That's definitely true. Most of the guide I did focus on was for hospital and healthcare institutions. So I was focusing more on, I guess, the institution-level
institutions themselves. But implantable devices are definitely a risk. That's part of what we saw at the St. Jude pacemakers was, it was their Merlin at home transmitter that was used to communicate with the device, was found to be insecure. And yes, home users are not going to follow the same kind of security recommendations and things like that. I think that that much more falls to the manufacturing standards the FDA is putting out to basically put security in place that way because you have much less control over what you can do with a person at home. So I think that's a big risk.
I guess my standard was more focused on things hospital IT security staff can do to secure their deployments. But that's definitely a real valid concern. And I think that's better addressed, though, by the FDA guidelines rather than the project I was working on.
So jumping on the kind of the last question there, I know it's not exactly the topic of this conversation, but for blood glucose meters, insulin pumps, things that are embedded or worn on the actual patient, what is the FDA even trying to address these sorts of concerns?
Are there any sorts of security concerns on those devices, things that are connecting to their iPhones and Androids?
They did release some guidance. It's non-binding right now, but there is some FDA both pre- and post-market guidance that has recently been released.
But like I said, it's currently non-binding. So there's recommendations to manufacturers. And I think the rally on most implantable devices, it comes down to a question of risk.
If you consider a pacemaker, prior to the devices being wireless in some form, you could adjust the settings. If you needed your pacemaker adjusted, you had to go back in for surgery and stuff like that.
There's a huge risk for surgery. Making these devices wireless did take away a lot of that risk.
So yes, some risk was reintroduced by making it wireless in a different way.
But for a lot of it too, it comes down, for the average person, is the risk of dying from surgery worse than the risk of having their pacemaker hacked?
And maybe for a real famous person, like you saw with Cheney, he had the special shielded pacemaker.
The hacking risk was greater than the surgical risk.
But for the average person, there's a lot of risk.
It's a question that there's not an answer to yet, but that's really what I think the question comes down to in a lot of cases.
Thank you.
A quick point of clarification. The FDA guidance is actually legally binding. The methodology to achieve the effect is not.
So in the post-market example that you gave, there is a risk assessment methodology that's provided in there.
That is non-binding. That's a suggestion.
But actually, to address cybersecurity risk in the post-market, that is actually a legal requirement.
To address the gentleman's question that came up before.
There is no specific device guidance with respect to cybersecurity.
But the pre- and post-market largely apply to all devices that come through the center for devices.
Thank you.