Thanks, everyone, for joining. This is Securing a Medical Device Network on a Shoestring Budget
by Helen and myself, Matt McMahon. We'll be your presenters today. This will be recorded,
pre-recorded and streamed, but we will be available on Discord to answer any questions.
Just a little bit of an intro in the class. This initially was a four-hour course,
and we cut it down, so we will be trying to cover a good amount of topics in a little bit
of a short time, but it will be recorded and played again, so they're available again on
YouTube. So if you need to get up to get a drink or use the restroom, feel free to do that and
come back, and you can look at any parts that you missed afterwards. So just to kind of give a quick
synopsis of where this training came from. So Helen and I both work for a medical device company
in their cybersecurity group. We're also both either current or former adjunct professors
teaching courses in cybersecurity, healthcare, digital forensics, and things like that.
So we thought this would be a really good class for hospitals to kind of understand some of the
basics. So this is a totally free course, open to anyone, and we're really just looking to share
knowledge. So a note on our target audience. We developed this course initially for the target
audience being like a small critical access, like 25-bed hospital, with a smaller IT staff and a
limited budget. They may not have any cybersecurity staff currently in the workforce.
So there will be things that larger hospital organizations or other individuals can get out
of this course, but if some of the material, at least in the beginning, seems kind of basic,
just kind of bear with us. We're trying to set the stage so that target audience can pick up
and kind of follow us for the whole course. So what we're going to cover today, we're going
to have six different distinct modules. So I'll start with the healthcare threat landscape today,
then Helen will take over for basic network security within the hospital,
network monitoring and scanning, developing and regular patching strategies,
then I'll take back over at the end for physical security, and then vetting of third parties.
We'll then have a short break, and then we'll come back for a panel discussion,
both with Helen and myself, and a number of other experts from the hospital cybersecurity space. So
make sure to come back for that. As I said before, this training is pre-recorded. So we are,
while we're teaching, we're not teaching right now, this was pre-recorded, so we are able to
answer questions on the Discord channel. And be aware, too, that we do have that panel afterwards.
If there's a question specifically on how a hospital may do something, we may defer to the
panel, just because then you'd be able to actually hear from hospital staff on how they would handle
certain situations. So just to kind of start off and set the stage, it's important before you really
can secure or defend anything, you kind of need to know your current threat landscape, and certainly
healthcare is a little bit different than some other threat landscapes. So a lot of the data
that we'll be pulling from the Verizon Data Breach Investigation Report, obviously that comes out
each year, there's a lot of good data that comes with it. But there's another report called the
Protected Health Information Data Breach Report. It takes the DBIR's data specifically just on
healthcare and the healthcare sector related to data breaches. It takes those stats over the
course of three years and extrapolates some data from just the healthcare sector. So we'll be
talking a lot about information from those reports. PHI, I mean, this is probably not
anything new to anyone that's currently working in the field, but just in case you don't know,
medical record, why is it valuable? It could potentially sell for 10 to 20 times on the
black market. What a credit card record could sell for, you can't turn off a PHI record,
protected health information record, like you can a credit card. An attacker could potentially
use the stolen data to acquire expensive medical equipments or technology. And then an attacker
could also combine PHI with a provider number to file fraudulent insurance claims. Just
very quick, some possible things that could happen. One of the things that makes the threat
landscape and healthcare really unique is the prevalence of insider threats. And when we say
insider threats, we typically think of malicious insider threats, but healthcare is unique in that
there's a lot of error that factors into that as well. So non-malicious errors and
data breaches as a result of that. In healthcare, 58% of data breaches over the course of those
three years that were recorded did have some insider component. Again, both malicious and
non-malicious, but that is important to note. It's the only critical infrastructure sector in the
United States. They're actually more likely to be compromised internally than externally. So
we want to make sure that we're taking into account that. So what's the breakdown of some
of the threats? So we talked, I said some of this were non-malicious, so a lot of it is error.
You can see over 30%, 33.5% is just error. So individual staff, maybe clinical staff working
long hours, swing shifts, too many patients than they would normally have certainly in the COVID
era. Working with technology that they might not be familiar with, it's easy to make a mistake
and cause a data breach that way. Misuse would be the second highest, just under 30%.
Misuse in this case would have a deliberate component. So it could be as simple as nurse A
tells nurse B, hey, did you hear about this patient? And nurse B shouldn't have access to
that patient, or it could be selling hundreds of thousands of records. So there's a broad
spectrum there. Physical, we'll touch on a little bit. And what's interesting with this graph,
is you see, if you look on the news, or just search cybersecurity and healthcare,
pretty much what you're going to see is a lot about ransomware. And certainly we'll talk about
ransomware in this presentation about how prevalent it is, and how it's becoming much
more prevalent. But it's just important if you're trying to defend the hospital's network,
to kind of know where your threats are really coming from. Certainly you want to defend against
quote, unquote, hacking, or malware, ransomware. But we'll also want to make sure that we're aware
of the fact that our largest threats might actually be already inside the building,
someone that we've actually given access to. So if we dive down into those errors, again,
over 30%, misdelivery was the biggest. So sending PHI somewhere where it wasn't intended to go to.
Disposal error, so we think we've properly cleared a device, or this could be paper records as well.
Loss, we just lost the data, we didn't know where it went to. Publishing error. Publishing error
typically would be like a study. So we've released a study that we think had anonymized data,
that data was able to be de-anonymized, and they were able to... basically resulted in a data
breach. What do you find interesting about this is, there was a quote in the report that said
healthcare has a paper problem. Typically when you think data breach, we think electronic,
but 43% of all the data breaches that were recorded were actually still on paper.
So moving to electronic could actually reduce the overall data breaches.
Data misuse, so again, misuse required that distinct motive. It could be as simple as
nurse A tells nurse B, hey, your ex-significant other is in the hospital, did you hear about it?
Or it could be selling records. And let's see, and typically this involved at least two-thirds
of privilege abuse. So accessing data that they shouldn't have access to,
maybe escalating their own privileges. Physical, physical was pretty close to 100%, over 95% just
stolen on encrypted laptops. If this was a doctor's laptop that was stolen but encrypted,
they don't include that as a potential data breach, just because they assume that an attacker
wouldn't be able to get to that data. But if the data is non-encrypted, then they assume that they
are able to get to that. So yeah, interesting with this picture, that while the attacker did
break the window and steal the unencrypted laptop full of PHI, they did at least leave the font
So that's nice. And quote-unquote hacking, this is kind of a broad, broad category,
but this included almost 50% was phishing, social engineering. And again, just try to remember that
this is below 15% of the overall data breaches. So again, we're just talking about data breaches
here, not necessarily cyber attacks that bring down hospital networks, but specifically data
breaches and breaking that down. So just under 50% of that was using stolen credentials that
were harvested, again, potentially from phishing or social engineering. Over 20% was brute forcing
a password. 17.9%, so almost 18%, was using a backdoor on a device, could be a medical device,
could be software, whatever that backdoor is. And then you see minimal for the other ones.
Malware, so general category of malware is just under 11%. Again, kind of keep in mind the
prevalence of that internal error, and over 70% of that was specifically ransomware. So obviously,
that's a factor. So while I am trying to highlight the fact that insider threat is statistically a
lot bigger for data breach, data breaches within the healthcare sector, obviously,
malware, there is certain caveats that we need to talk about, it is certainly increasing.
This was an interesting report that came up from NTT Security. They published a report
back in, it's a little bit dated now, but Q2 of 2016. They looked at their entire,
so their security company, they looked at their entire customer portfolio, 7.4% of their customers,
only 7.4% of their customers were hospitals. But those hospitals made up 88% of their clients
that were affected by ransomware. So it really said, wow, while hospitals make up a small
percentage of our actual customer base, they're disproportionately affected by ransomware.
And we'll certainly get in this class as to why that is. Flat networks, lack of proper
security controls, things like that. And it was predicted that ransomware attacks in the
healthcare sector would quadruple in 2020. And certainly we've seen an increase in that.
All right. COVID-19, I can't really have a talk now and not talk about COVID-19. So
certainly that's changed the threat landscape as well. Not just in healthcare, but across the board
we've seen a 667% increase in COVID-19 related email attacks, just from February to June.
And then just cyber attacks in general up 37% in May. And what's interesting with COVID too,
is we're not just seeing cyber attacks, but we're also seeing a lot of fraud.
Interpol has seized over $14 million worth of fake PPE. And certainly hospitals have been caught with
purchasing or trying to purchase PPE in the past when it was a little bit harder to get.
Maybe they had to front funds to get those, and then they just never got their equipment. So
there's a lot of different possibilities there for compromise.
For folks that work in the cybersecurity and healthcare space or industry,
this was an interesting report that came out in March. Basically a number of ransomware shops
said that, no, we won't specifically target the healthcare sector or hospitals during a pandemic,
because that would be incredibly bad. Unfortunately, that was not the case.
They still have continued to attack the healthcare sector. And in many cases, it's actually
increased. So we've seen Health ISAC has reported an increase in COVID-19 themed attacks, up 20% to
30% in just phishing, specifically targeting the healthcare sector. And you can see there,
the average ransom payments. And obviously, during a pandemic, there's a lot of things that
make this more difficult. Obviously, getting physical access to a device, if it's in a
quarantined area, to be able to update it. If you need to physically access the device to
update something, that just adds an extra layer of issue.
So how many hospitals do we know of that have actually been attacked
or been compromised by ransomware, specifically using a COVID-19 hook?
According to Bill Siegel, the CEO of Coveware, there's been at least half a dozen just in the
US. There's probably significantly more than that, but those are the ones that we're aware of.
There is certainly a good amount of under-reporting. It's difficult to really
understand the scope. Hospitals, in a lot of cases, pay the ransom. It may not be reported
if we don't believe that there's a data breach. So it's hard to tell the exact number, but we
know of at least half a dozen in the US. In Canada, a Canadian government hospital there
was affected. It was specifically targeted using a spoofed email that appeared to look like it
came from the World Health Organization. It was procurement-related, so this was a couple months
back when procurement of gloves, masks, things like that were quite difficult. If you read the
email, it was really easy to spot if you knew what you were looking for. The authors really
didn't make any attempt to make it look legit in any way, but because of the need for procurement
materials at that point, again, gloves and masks, it was clicked on and propagated.
Spain. Spain at that time was particularly hard-hit by COVID-19, and the Spanish hospital
was hit by the Netwalker ransomware. It specifically targeted Spanish hospitals,
specifically during the peak of the virus there, using a malicious attachment.
Czech Republic as well. Brno, I believe, had that saying. I hope that's not incorrect.
University Hospital, which was the second largest hospital in the Czech Republic,
was taken offline. It was forced to shut down, and this attack was very want-to-cry-esque.
So not just really hospitals, but we're also looking at laboratories and supply chains.
So in California, the 10X Genomics Company was hit by COVID-19-related or themed ransomware.
A urology consultant company was hit. Medical device manufacturers have been hit.
So why target healthcare? Well, hospitals, as we said earlier,
unfortunately often pay the ransom. There is a need to be online. These technologies are
life and death, and often they have less resources to be able to defend themselves,
so it might be easier to attack a hospital. So some quick key takeaways. Privilege and
escalation abuse was two-thirds of all the incidents. Now, having been someone that worked
for a hospital for a while, doing application access and having to monitor access, I can
certainly say that this is difficult. A lot of this really depends on how those individuals are
keeping access. Certainly, you want to restrict access as much as possible. You don't want to
leave it open. But in my case anyway, it was certainly noted that the application support
staff were working on call on the weekends, and they were not being paid to work on call.
So if you're doing that, you're basically creating a situation that
encourages or incentivizes your IT staff to leave access more broadly open than it probably needs
to be so that they're not getting a call at 11 o'clock at night during shift change when
new nurses come on, maybe temporary nurses that need access. So just kind of think about that,
maybe how your hospital IT staff or application support staff have to deal with access. Do you
have someone that's constantly working, or is it on call? It certainly comes into play.
Data mishandling. So this was, you know, kind of a cultural problem that we're talking about where,
you know, nurse A tells nurse B, hey, did you hear about this individual? This was almost 17%
of the data breach cases. So, you know, something to kind of consider. Certainly, it's human nature,
curiosity, so it's difficult, but something to consider. Fraud in the healthcare sector,
there is a large amount of fraud in the healthcare sector. It's the third highest
industry for fraud in the United States, right behind the government sector, and finance was
number one. Breach discovery is also an issue within healthcare. Approximately one-third of
the data breaches in the three-year study were not discovered for years. Another third were not
discovered for months. So it's important to kind of note that, you know, when you're looking at the
numbers or considering if you've been breached, you know, many hospitals may not even be aware of
it, so... And just one other thing that kind of complicates this, budgeting and staffing
realities, it's commonly cited by CISOs from hospitals that 3% of the hospital budget goes
towards IT, and 3% of that 3% goes to security. So they really don't have a lot of, you know,
either the staff or the resources that they need to dedicate to security. So that really kind of
leads into one of the reasons why we built this course, to try to offer some, you know, free
technology, in this case free training, or low-cost technology that could be used to secure a
hospital's network. Another issue is what's called agency staff. So at any given hospital, up to 10%
of the nurses could potentially be agency staff. So someone calls in, we need someone to, you know,
take their shift, they call the agency, they get a nurse, that person then has to be added to all
the hospital systems. Certainly if you're working in IT at a hospital, please fight the urge to
just create entries in your system called agency nurse 1, 2, or 3. It certainly makes it easier
for IT staff, but obviously, you know, for logging and things like that, it could be a bit of a
nightmare. So just kind of be aware of that. Just some quick insights from the 2009 HIMSS report
of all of the hospitals that were surveyed. Over the course of the last 12 months, 82% of hospitals
said that they did have a recent significant security incident. So kind of good to note of
the prevalence of how much this is happening. Legacy systems are also an issue. 72% of hospitals
said that up to between 1 and 10% of their technology is outdated legacy tech. And if you
look at 2016, the 2016 HIMSS study, it interviewed or looked at 200 different hospitals, but I believe
a third of those, or I shouldn't say hospitals, 200 different medical facilities, but a third of
those were like doctor's offices and smaller offices. So certainly those, that third skewed
the stats a little bit. So you can kind of factor that in when you're looking at these numbers.
But it's still a little bit scary to even think that those, even if it's like an outpatient clinic
or a doctor's office, that numbers would be this high. So 14% of those medical facilities lacked
any antivirus or malware, under 20% no firewall protections, 46% no network monitoring, 52%
no intrusion prevention, and 41% didn't encrypt data at rest. Again, this is 2016. HIMSS doesn't
ask the same questions every year, so we can't see trends, but just kind of something to take
into account. So this is the last slide of this. And again, just to kind of talk about our
objective, we're really trying to train those small critical access hospitals on some of the
things that they can do to help bolster their cybersecurity posture. And this is what's up next.
Helen will be taking you over next with basic network security.
Thanks for that, Matt, and for really just setting the table here.
I wanted to go ahead and preface that in the interest of time, I've removed demos, but I've
added a slew of links on added resources, places where you can get demos, and just manuals and
the like to the end of this presentation that all the decks will be available to whomever would
like them. I also included any slides that I removed in order to streamline this presentation
and hit our time restraint. I include them in that slide deck and with my notes. So if you
have any questions, you can go ahead and look through that and then reach out to me or Matt.
We're going to start with the little parts of network security, you know, cyber hygiene, and
just the basics. As Matt said, the 2019 HIMSS study shows the importance of the network
security basis, basics. A pattern of cybersecurity threats are discernible across U.S. healthcare
organizations, and as Matt has just said, the trend has only increased in the current pandemic era.
Elements of network security, there are so many. I have asked this question of other people,
and everybody can give you, you know, 20 talking points of things that they find to be
the core of network security. Here are some of those elements. We're going to talk about
access management, segmentation, we'll go a little bit into firewalls, and we'll finish up with some
testing. Now, we're not just coming up with network security requirements out of the air.
There is HIPAA support, there is industry support, hospitals need to protect their sensitive data.
Network security for the uninitiated and overworked, I understand it's really difficult,
but hopefully with this primary, you'll be armed with the tools to at least ask the right questions
of your external consultants or Dr. Google. Strong access management is key. You want to
secure your endpoints, ensure your remote workers use a VPN. You want to have strong but manageable
passwords. You want to use multi-factor when applicable or possible. I understand that
it is very common in a lot of workflows in a hospital staff to use their badge already for
access, so having them switch to badge and pin is not a stretch. It would be within a normal workflow.
Physical controls to limit access to restricted areas are a must, and Matt will get to those
later. You want to review administrative accounts, access to servers and workstations
and devices. You don't want local admin accounts that can lead to unintended privilege
access to systems or data. You don't want generic lab user one. You really want to know who is
accessing your data and why. Review the process for elevating access as a request and make sure
that there's a separation of duty policy for administrative access. Review shared accounts
for necessity and then monitor out for abnormalities or misuse. And finally, you want to
review your terminated employees or people that are on leave of absence. If those accounts are
not terminated quickly, they can be used inappropriately. The principle of least privilege
is one of the basic principles of user access. You don't want one mastered user that has all
the keys to the kingdom. If that user is compromised, you are compromised. You don't
want one person performing every duty. You want to spread those duties around and you want to have
more than one person accessing an area. With that in mind, sorry, I do want to start this over.
That was the concept of separations of duty, not the least privilege. The concept of least privilege
is that you want to have the user have the minimum access needed to do their job.
Network segmentation. Network segmentation is the practice of dividing larger computer networks
into several smaller subnetworks that are each isolated from one another. If you think of this
like a fence around your house, if you have a fence around your house and you don't have
any other protection to keep your house from being broken into, all somebody needs to do
is find a way to get in through your fence, right? So that's what you would have even if you just
have one firewall or one access area of protection. If you are creating a bunch of smaller
networks, smaller segments, even if one area is compromised, the other areas can remain protected.
Here are some examples of what a flat network looks like and that's what we have seen in a lot
of hospitals. You have the internet and everyone can access the internet and all the equipment
runs on the same network and it's almost set up like a home network but in a business that runs,
that deals with such sensitive information. The next slide, the next picture is a basic
segment and here is an idea of what segmentation in hospitals looks like.
Here are, so a VLAN is a logical partition in the layer two network and here's a
background of what a switch would look like and
some ideas of what the logical layout would look like. So I have removed a section on types of
firewalls. There are several types of firewalls and you should look to find which kind suit your
purpose. There is some great information out there. I've included that in our resources at
the end. Firewalls are your first line of defense for securing healthcare networks from against
the public. Firewalls are digital walls that stand between protected health data and potentially
dangerous threat actors. You want to start by blocking all, by blocking all traffic by default
and then only allowing specific traffic to identify services. This approach provides
quality control over traffic and decreases the possibility of breach. You're going to
want to make changes slowly over time and I understand that sometimes this is impractical
but you want to do this in small segments and secure your network over time during downtime
and maintenance zones, maintenance periods. So the approach of quality control over traffic
can be achieved by controlling the last rule in an access control list to denial traffic.
And this can be done explicitly or implicitly depending on the platform.
So you follow an established set of rules and then firewalls can actively monitor incoming
and outgoing traffic. In doing so, a firewall blocks the secure network from the internet,
only allowing pre-cleared data to pass. So you want to know the firewall's purpose,
what the affected devices are, what users have access, what date your rule applied,
and who's the name of the person who added the rule.
Some inbound rules are whitelists, which are falling out of favor and are being called allow
lists or a few other terms, which will be, you know, only allowing Jim and Mary to go to the
insurance billing information website. These are who's allowed to access an area. There's a deny
list, which is, you can go ahead and allow these doctors to go anywhere except ratemymd.com. You
don't want them reading reviews and getting upset on shift. You want to block, so you're not going
to allow one person access to anything, whatever the thing you're saying. Okay, this guy is in
environmental services. He doesn't need to access financial records. That's blocked all together.
And then a VPN. So you say, okay, you're only going to allow this physician that works from
home to access our network if they're using our approved remote access avenue.
SANS has some great firewall information. I'll have links to that in the resources at the end
of my deck. And they have a firewall checklist. The main purpose of the firewall is to drop all
traffic that is not explicitly permitted as a safeguard to stop uninvited traffic from passing
through a firewall. You want to place a drop any, any, well, an any, any, any drop rule. It's a
cleanup rule. So if you forget about something, this default rule will clean it up. You want to
have this at the bottom of each security zone. And this will provide just a catch all,
catch all mechanism for capturing traffic. Here's an example of what a cleanup rule would look like.
It's also important to note that with all of this, you need robust documentation
and a strict change procedure. Firewalls rules will need to be updated for any new service or
new devices. They're going to have changes over time. But before adding or changing or removing
any rules, you want to implement a formal change procedure that can make sure you're keeping track
of the modifications. So here are some guidelines for those procedure, change procedures.
I know automation is a important topic and automation is definitely possible with firewalls
configuration, for rules, for management of your fleet. You can manage windows firewalls
via domain group policies. You can use configuration management for traditional
firewalls. You can use something like granted. Linux has web-based tools to manage
network routers, switches, firewalls, etc. You can have a fleet managed
software so, you know, like certain vendors will have their own tools to manage their fleets.
And it's the same with wireless access points. So you'll want to pick the management tool that
works for your particular network. When working in windows, you can manage all the firewalls via
domains, group domain policies. Here's the Linux note and the other items I just mentioned.
Testing. So it's not enough to assume that you've applied adequate security controls.
You want to make sure that you test different aspects of security either for compliance.
You might have a customer or a patient that has questions and if they're a large donor or
something you might be motivated enough to test this. There might be a need for some sort of
full red team engagement or overall whatever you want to do to assess risk readiness.
And it is important to pick a strategy. And there's different levels of depth here.
There's the vulnerability scanning or security scanning which is automated. There are several
tools out there for this. And it's to get an idea of basic weaknesses. So are there patches
that haven't been applied yet? Are there ports open that might be suspicious? What's the idea
of traffic going on right now? It gives you an idea of your risk in an automated way so you don't
have to have an extra resource devoting time to that. It does not by any means replace more robust
security measures but it is a way to get an idea of what's going on and what weaknesses you may have.
A pen test is more in-depth. It involves a person simulating
different types of attacks in order to find as many vulnerabilities as possible. They will provide
you with a report and depending on if you're what the agency you're going with to do this or
what kind of your internal testers, what their process is, they may also help you find
remediations for that. Risk assessments are more
either enterprise risk management or sometimes compliance related. It's a process of reviewing
and analyzing potential risks that later you can prioritize and get business input on
and you're going to try to come up with a plan as to see what the possible ways of preventing
these risks from becoming a reality. So you're going to prioritize components that carry the
highest risk and you'll say, okay, this stores most of our patient data, for example. We're
going to go ahead and market for some more robust testing so we can get an idea of where our
are and really plug those holes to the best of our ability. Security auditing is verification.
You can audit your access management policy. You can also use this tied to compliance
and you can analyze the system in working conditions. You're taking a view of what's
going on. You're not... the chances of something going offline or breaking are quite slim.
That can happen in a test, in a penetration test, but not so much in a risk assessment.
Sorry, not so much in auditing or reviews. Red teams are similar to a pen test,
but it's more targeted and it usually involves more than one person. It is a team of people
that are trying to get in using the techniques of a malicious person or some sort of threat actor
and they're going to try to get in and access sensitive data as quietly as possible without
being detected, just like the bad guys. They're going to just look to avoid being detected.
They're usually there for a longer period of time than other testers and they use a variety
of techniques. This could even include some physical testing to break in
and to get access to things that they probably shouldn't have. The
final note here is application security testing. At some hospitals, there will be some level of
development and this would be the process of testing and analyzing and reporting on the
security level or posture of a particular application. It's used a lot in web development,
but also app development like for Apple applications. It's just an idea, a way to
test and gauge the security strength of that application and then find areas that you can
remediate. There are times when you're going to want to bring in outside help.
You want to develop, especially if you're going to have an outside digital forensics incident
response team, you're going to want to develop this relationship long before a crisis situation
happens. So find out how many cases they work a year, how many of them are hospitals, get references
or testimonials from past clients, find out what experience level their team is at, how many of them
have worked in the health care industry, and find out if they can help with overall readiness
and not just be there when things go wrong. Recently, Liz Waddell did a presentation called
Help, We Need an Adult, Engaging an External IR Team that provides some great tips and you can
find it online just googling the name. And here are, here's the beginning of the resources.
There are
CIS, so the CIS and NIST and then the open source
testing manual as well as links to many articles and demos.
And that is the end of our basic network security section. Moving on to the next section. So
a question that comes up pretty often is how do you monitor all the devices you have in a network?
And this is going to start with really seeing what you have and then figuring out how to
capture that data and monitor what's going on. Obviously, we don't have the resources
to go and look at every device, so you need to have a smart approach to this.
We're going to touch on network discovery, logging, and setting up a strategy for
asset management and real-time monitoring.
So as I mentioned, before we get started, you're going to have to do some planning.
Some of this is going to be with network discovery. You're going to want to perform a scan
to get the lay of the land and probe a network for all connected devices.
Institutions are going to need to be aware that certain brands of devices or certain
device models do not like being scanned, and so you're going to want to avoid doing
this kind of heavy network discovery while they're in use. Or you're going to want to
have that dialogue with your medical device manufacturer to see if you have some of those
devices, and then perhaps take the device offline or create a strategy for managing
that device while you're discovering everything else on your network. Ultimately, you cannot
protect what you if you don't know it exists. And one strategy is to log as much as possible,
get as detailed lay of the land as possible, and then if you find a new device that isn't
in your inventory, you're going to treat it as hostile. So you're really going to
want to be as thorough with discovery as possible. And in this network discovery,
you're going to find some items that are immediately glaring. They're going to be
operating systems or firmwares out of date. You're going to find just some simple vulnerabilities
that come up, and you can remediate them along the way as you're doing your asset inventory.
You're going to have to decide what's important to the organization early on,
because you can't keep a log of everything. Long-term storage is expensive for this kind
of monitoring. So you're going to have to prioritize what data you want to keep a track
of the most. You're going to want to structure your log data. You're going to have some
normalization across logs. There's a common information model that was created to solve this,
and a community, an open source community, that also provides some information on this,
and I have a link to that in my resources. If you're unsure of where to start, or you
want some structured guidance, there are many different SIEM vendors, and so you can reach out
to them and see about writing rules that support your organization devices in these cases.
Don't feel pressured by these salespeople. Make sure you're in control of your conversation.
You're going to want to separate and centralize your log data.
Decide what you need from the logs and what you can discard. Logs are similar... logs are similar to
finding the log data that's important to you. So security logs, system logs, intrusion attempts,
connections, figure out what matters to you, and those are the logs you're going to need
to keep. Separate logs come in handy for searching and dashboards, so you can organize your data in
a way that's intuitive to you. If devices are Windows, you may be able to use the window event
forwarding to push to the syslog. If you're using the Linux environment, use existing syslog.
If you're pushing to a SIEM, there's lots of options, so Splunk, Security Onion, AlienVault,
etc. There's paid versions, non-paid versions, obviously the open source ones are an increased
level of effort, but everything is going to need fine-tuning. That is the nature of logging. So
you're going to log devices to ensure communication to only trusted endpoints,
log IPs and connections in and out of network, log an alert of large data transfers,
you're going to want to log local devices and workstations for USB devices that are plugged in,
you're going to want to log application setups to what's running on startup,
you're going to want to search for malicious applications or malicious services,
there are different options for inventory based on your operating system,
you have a lot of variety in this space, use whatever works best for your workflow.
You're going to want to correlate data sources. So you're going to use existing logs and security
system events combined with local host logs to detect anything that's out of the normal,
out of normal and flag it as a malicious activity. For this, you're going to need to establish a
baseline. You're going to have to have a period of time where you are figuring out what is normal
in your environment. And once you know what normal is, you can start to define what abnormal looks
like. Your correlation only works if your logs have been normalized. So you're going to want to
use identifiers that work for you as an organization, be consistent, whatever is intuitive
for your group, proceduralize that and make it standard. So you, for example, if the core group
in New York file server one, if you want to abbreviate just taking the first letter of
every major word, if that works for you, do it. Do whatever works for you. You can say MRI,
diagnostic services, left wing, whatever works for you, figure it out and then make it canon.
You want to label your equipment, include warnings or pertinent information,
and you want to also log MAC addresses, model numbers, serial numbers, licensing keys,
anything that is important, especially if something goes wrong.
So you use those unique identifiers when logging so that you can easily identify
in your dashboard what is going on. Utilize scripting to run searches on interesting data,
send this to email for the process. You're not going to want to do this by hand, use a dashboard.
Perform real-time monitoring. Again, you're not going to want to do this all by hand,
you're going to want to have some dashboard, deploy automation when possible,
and work with your vendor if you can. If you're using a free version,
those are often supported by robust communities and reach out to the community.
So things are complex to set up and administer, and I understand. Small teams have limited cycles,
I understand that as well. You're going to want to take your time to really fine-tune this to work
for your particular infrastructure. And utilize a SIEM, it'll tie together all the information
and make network monitoring easy for your staff. So assets, bad guys, and the things we can't see
are really where we have high risk. With no logging, no asset inventory, and no central
logging server, no SIEM to tie everything else, you're really dealing with an issue of the lack
of visibility. This is where that strategy helps, where we're tying all of that information to make
a map of what you have as a network, and it's the first step in figuring out where your risk is.
So here is a fun little map. Next we're going to talk about developing a patch strategy.
So now we're moving on to my last topic, and then we'll close out with Matt on his final two topics.
My last topic of the day is medical device patching. This is a complex topic, but we start
with, like everything else, with a strategy. Why have a patch management strategy? It avoids
downtime and response efforts, it increases compliance, there's high return on investment
for the effort, and ultimately increases the security posture of your organization.
There's also some FDA guidance you might want to look up on the topics. Security updates are
managed by the manufacturer's quality system, but they have made it easier to go ahead and push out
to the customer. What is part of this process? There will be hazard analysis, formal testing,
and then it'll be released. Why are patches generated? Well, sometimes it's because there's
an uncontrolled risk that has an unacceptable risk to either clinical functionality or patient
safety, sometimes it's just maintenance or part of good cyber hygiene, and sometimes it's that a
third-party component requires a patch. There's a lot of challenges, one of them being the variety.
There are hundreds of possible options for operating systems, and then when you add in
the hardware and software components, there's a lot of variety in that install base.
The hospital network has some complexity and risks. You have a lot of vendors, you know, we like to
you only use us, but that's just not the case. There is a number of vendors, there's a number
of platforms for remote access, and some devices do not have remote access available at all.
Then there's the availability of a third-party patch. Just because a third-party component has
a risk does not always mean that they will get us the patch in the time we manage to provide it to
you. And then there's dependencies on the back end, servers and the like. There's organizational
issues, so who does this device belong to? Does IT have a good relationship with the clinical team?
I mean, in smaller places, the bioengineering guy and the IT guy and the IS guy are probably
all the same person, but it depends on how that person deals with the clinical staff.
And then what are the functionality risks? There's also regulatory and compliance concerns,
what the change management process is. Devices are in use 24 hours a day, seven days a week.
Device systems, like I mentioned earlier, they have dependencies.
Hospitals are typically not allowed to install operating system patches directly.
This is becoming less of a problem as more software-only solutions are created.
But it is still a problem, especially in your legacy devices and install base.
And what is impacted if things go wrong? Patient safety, care, delivery, and you have a reduced
revenue. If you have to divert patients, if you have to delay diagnosis, you're going to have
a reduced income. More complexities. The diversity of the medical device manufacturer,
service level agreements, larger healthcare organization deliveries typically rely on
automated patch management systems to coordinate the distribution and installation of patches.
These agents for these programs or security agents are not generally approved for use by
medical device manufacturers. Automated systems might accidentally push a patch to a non-approved
device and that patch might bring that device offline or render it unreliable.
HDOs have a difficulty for monitoring for and assessing the impact of vulnerabilities.
If they may not know that vulnerability exists, they don't have a lot of visibility into what the
third-party components are of that product. Many devices can only be patched when not in use or in
service for patient care and patient safety reasons. And for this, I'm saying leverage your
existing preventative maintenance cycles for certain devices. But when the device is in use
24-7, that cycle might not come more quickly enough. We hear this a lot. There's a shared
responsibility. Medical device manufacturers need to make a safe device or as safe as possible
and give you the avenues to have safe settings, you know, control your access to your device,
protect your data, respect privacy. They need to have robust security features. The device needs
to be hardened and tested. We need to disclose vulnerabilities. We need to tell you what the
third-party software is in the device and we need to provide patches in a timely manner. Hospitals
need to deploy devices in a secure environment, which includes segregation. They need to monitor
their network. They need to have an access management slash traffic control system.
So that could be like physical security vulnerability analysis. They need to do
security awareness training. We don't touch on security awareness training in this topic,
but it is important. And you want to teach proper use. You want to have a life cycle and change
management policy that includes patching and you're going to want to assess your risk.
So as you may or may not tell by now, I'm pretty keen on processes. Asset management
is an important part of many of the things I've mentioned, including patching.
You're going to want to give each device a profile where you're saying
you're triaging by exposure, likelihood, and impact in your risk profile. So do you have
a flat network and a device that has a lot of ports open and not a lot of security controls
in place for that device? Your network exposure risk is high. And then you go, you said, yeah,
okay, that's high, but it doesn't actually store any PHI. It just may have a couple of
values that are anonymized. Okay, well, then your data exposure is low.
Patient safety and clinical care risk, does this directly affect a decision in patient care?
Or is it an A1C that may be a factor in a diagnosis or a fasting glucose that may not be
directly impacting a clinical care decision in an emergent moment?
So how do you create this profile? If it's networked, you can, as we mentioned earlier,
with the discovery portion, you can collect a hostname, MAC address, IP address,
wireless interfaces. You may also want to note serial number. Oftentimes that is an identifier
used by service. So when there is a problem, they may use, there's a vulnerability that impacts
serial numbers one through 10, or ending in one through 10, and all others are fine.
Or we're rolling out a patch to these serial numbers. So you would like to note that information
or communication with your device manufacturer.
You're going to want to create this, part of creating this medical device security profile
is the software bill of materials and your security white paper. So many, many manufacturers
are now in the process of collecting this information. As you can tell, the software
bill of materials is important for a variety of reasons. It's involved in vulnerability analysis,
in your privacy concerns, in pretty much everything. The white paper should also tell you
what your operating system is and patch level and update. They're just going to let you know
if there's any middleware, any dependencies, there's often network flow diagrams. You can
get an idea with the documentation that your vendors provide of what your risk is.
So when you're creating your medical device security profile, you're going to want to
take a look at the controls. What are the credential management options? Is there
antivirus or other security technology available with the encrypt? You're going to ask what
logging capabilities they have and how do they manage remote access? You're going to want to
keep a copy of the MDS2 security and security white paper for every version of the device
that you have in use in your environment. There is enough variety at significant releases that
you will need this data. Make it part of your profile. So as I was mentioning, the network
exposure. Is the device in an internet accessible network zone? Does this have
dial home capabilities? Is it remote accessible? These all increase your network exposure risk.
Data exposure. Does the device store PHI or PII? Is the sensitive data only stored
for a small period of time or is it permanent? How many records are stored? How is it stored?
These are all questions you're going to want to ask your MDM. They are your partners in this.
You are also going to need to figure out how critical is this device to care? Is it life
sustaining? Does this represent a single point of failure? Has the security evaluation been performed?
You're allowed to ask your medical device manufacturer, hey, what security testing has
been performed on this device? What did you do about it? And especially if this is critical to
care, you might want to have those conversations. You're going to need to plan your patch execution
safely. So if you can, if you have a test device, you're going to want to, one, receive your
manufacturer's approval. Test it on a device that's not in use at all. Verify that it does
not in any way impact your workflow, just so that we know it works in your environment.
Schedule a patch during a maintenance cycle, so a time that the device will be down anyways.
Use your device in use safeguards that are in your manual. Deploy and apply the patch and validate
that the device is ready to return to service. So you're going to want to make sure that this is an
approved patch. If you want to, for some reason, apply a patch that did not come from your
manufacturer, you need to reach out to your manufacturer and have that conversation.
See what your service level agreement says. Manufacturers do have a list of approved patches,
so get that documentation from them and make sure you're up to date.
Ensure that the patch management system can isolate authorized patches and employ,
ensure that only your authorized and approved patches are deployed on the device.
Here's some considerations. You're going to want to see what your change management policy says.
Schedule the patch during the prevent and maintenance cycle. I can't stress that enough.
Please do not use a device that's in use. Should, by any accident that happens,
you know, you don't want to take a device offline that a patient is using.
When impossible, employ device in use safeguards. The two-man rule. So, hey, I'm going to patch this
MRI machine. Can you see it? Can you verify that this is actually empty and not in use?
Because we have it on the schedule that it's not in use today. Yes, I'm looking at it,
there's nobody in it, and there's no plan to use it today. You're going to want to isolate the
medical device on a maintenance VLAN and then deploy. When everything is back up and running,
return it to service. So, that is our patch planning. I know it's a little more involved
than your automated patch deployment that you can do with your workstations and servers,
but because these devices are so important to clinical workflow, we need to put in this effort.
Next up is Matt, and he has the fun topic of physical security.
So, thank you, Helen, for that great overview on a number of topics. We only have two more modules
left that should be pretty quick. We have physical security, and then we're going to cover third-party
risk assessments and communication. So, we'll jump right into physical security. So, why is
physical security in healthcare important? Well, if we're trying to protect PHI, you know, physical
security is certainly one thing that we definitely want to consider. If you can't block physical
access to the hospital, individuals can come in and potentially get access to data either on a
device or something of that nature. So, we'll quickly look a little bit at hospital physical
security studies that have been done and kind of understand, again, try to lay that foundation of
what the current threat landscape is. So, of a survey that was done in 2018 for physical security
in hospitals, 34% of hospitals did report some incidents of trespassing that year. That was up
from two years prior. And only 42% of hospitals did report having a visitor management system.
Now, when I say a visitor management system, what the study defined as a visitor management system
did require a visitor to both sign in, have a photo ID, and a visible badge while walking around.
So, if a hospital had two of those but not three, they didn't technically meet the criteria for
visitor management systems. So, that 42% is of the reporting hospitals that had all three.
And 20% of hospitals actually had some sort of physical man-trap that stopped individuals from
coming in physically before entering the rest of the hospital. So, what do we want to restrict?
Obviously, physical access. We're talking about physical access to hospital.
But again, if we go back to that first slide deck that we had, we're not just talking about
visitors, but we also want to consider staff. You know, is there certain areas
that staff don't need to be in, or do we just give them access kind of carte blanche to
all areas of the hospital? So, we certainly want to consider that. And, you know, definitely
remember that 58% of healthcare data breaches do involve insiders, both malicious and unintentional.
Certainly, don't forget about your own staff when we're considering these.
Physical security plan evolution. So, obviously, your physical security plan for your hospital
wants to evolve, not just with big events like we saw after 9-11, where a number of new doors and
walls and things like that certainly were installed to restrict certain areas. But, you know, we
want it to continuously evolve as the threat landscape evolves.
This was a great study. This was by Marlee McKee. Not really a study, but Marlee McKee.
She has, interestingly enough, a couple million followers, and she is self-identified as
America's modern manners and etiquette expert. And she claims that opening the door at work
was her number two for America's top five manners. So, these are things that people should do.
Obviously, those of us that work in security realize that this is really not good. But it is,
you know, prevalent. Door holding, at least in a number of cultures, is prevalent. So, we need to
kind of look at that and factor that into our physical security plans. This was a study that
was done by the University of Omaha. It was fairly interesting. There was about 1,500 students that
were assessed to see if they would basically hold the door if someone walked up behind them.
Two-thirds of the individuals, if there was someone that immediately tailgated them as
they were coming in the door, they would open the door and leave it open. There really wasn't any
gender difference for that category, but it was interesting that the latter two,
significant gender difference. Females reported seriously significantly lower for both glancing
back and seeing if someone was coming and standing there and holding the door and then holding the
door open for a significant amount of time. So, didn't really go into why there was that
difference with genders. But, you know, if you're incorporating this into your incorporating door
holding into your physical security plan, it might be something that you might want to look
at that study and dive a little bit deeper into. Maybe those gender differences are something that
you could leverage to make your facility more secure, if you can understand kind of why that's
happening. We're certainly not going to reinvent the wheel. This is a, you know, less than a two
hour training. So, if you want to see some great physical security training, I definitely recommend
Jason Street's DEF CON talk on physical security. It goes over a number of different physical
security penetration tests that he's done and how easy it is to gain access. So, you know, again,
this is just this is the very short abbreviated version that's specific to hospitals. So,
if you want more, I would definitely look at that. So, why is any of this important? Physical
security or at a, you know, cyber security or hacking conference? Why is physical security
important? Well, manufacturers, so medical device manufacturers, make certain assumptions when they
create a medical device. They assume, as Helen was talking in some of her past presentations,
that they assume that a device is going into a secure environment. And that's not always the
case. It's certainly going to vary. If it's maybe a large, you know, CT device that they might make
assumptions that that's going to be in a secure facility or maybe in a secure laboratory, certain
devices. But, you know, it is understood there's certain smaller, like, point of care devices that
can be physically picked up and carried around or, you know, might be in a ER setting or even
in a home setting are obviously gonna have less physical security. But you just want to kind of
be aware of what physical security assumptions, you know, your medical device manufacturers are
assuming. Yeah. So, testing those assumptions. While I was creating this training, I had the
unfortunate but fruitful experience of having an individual that was close to me
be admitted to a hospital. They were first admitted to a local, like, 25-bed critical
access hospital, regional hospital, then moved to a larger university hospital, and then in a number
of, like, physical rehab facilities. So I was able to kind of, you know, visit regularly and observe
different situations that were happening with kind of the eye of being a, you know,
an occasional medical device penetration tester. So I've never done actual hospital penetration
testing, though I have some colleagues that have, and I've included some of their insights,
but this is kind of what I've noticed. So the hospitals that I did visit, they did not check my
ID, which was interesting because I could have very easily just provided a name of any patient
that was in the hospital at the time and be given access. And I actually tested this out,
it's kind of an interesting OSINT experiment, but if you go to Facebook and just kind of do a search
for, you know, hospital, in probably 30 minutes or less, you're going to be able to find a name of
a patient, you know, whether it's a friend, distant colleague, whatever, that's currently,
you know, in a hospital, maybe social media posts that says, you know, this could be Facebook or
any social media post, hey, I had a spill, I'm in a hospital, this is a hospital, come visit me.
We now know that individual's in that hospital, and a good number of hospitals, you can simply go
there, provide their name, maybe provide a fake name, because they're not actually checking your
ID, and be given physical access to the hospital. Once you're inside, at least I found in the
hospitals that I was in, I pretty much had access to go anywhere in the hospital, which with some
restrictions, and there were signs that basically told me kind of wherever I wanted to go. So,
if I was a, you know, nefarious actor, and I wanted to get access to the server room,
it clearly showed on the map exactly where that was, and it said on the door, you know,
exactly where that was. Yeah, keep going. I was going to mention one more thing, but I'll
mention it at the end. At the patient's bedside, there was obviously anyone that's ever visited
someone in a hospital, you know, especially if it's a critical case, you know, that patient is
surrounded by a number of different medical devices. Many of those devices, such as a cow
or computer on wheels, which is where the nurse or the clinical staff would sit down and do their
documentation. So, they would do their vital signs, ask the patient all their questions, then go to
this computer to write notes. Typically, for what I've seen, most of these were not locked down,
at least in the hospital that I was in, and I've installed medical software in a previous role,
and that's certainly not the case. A number of hospitals do lock down all their computer on
cows, computer on wheels, and have a certain timeout to be able to lock that out of, you know,
inactivity. But in this case, you know, the devices were open. That's not a picture of a device,
that's just one that I took off the web. And there was a number of other medical devices at the
bedside that, you know, had USB ports that, you know, if you look at the device and Google it,
you can probably identify that it doesn't restrict any type of traffic. So, if you had a rubber
ducky, things like that, you know, I might be able to either extract data out of the device or
potentially run a script on it. So, there's a lot of things you can do once you get physical access
that, you know, we often think, well, if someone's in the hospital, they're hurt, they need to be
there. But, you know, nefarious people get hurt too and end up in hospitals or visit family members
or friends that are in hospitals. So, it's kind of something to consider. One thing that I found
interesting, so, like I said, I've done some, like, a very small amount of penetration testing
for medical devices, but I have a colleague that does actual hospital penetration tests.
And he says that, you know, with a mop and a bucket, there's essentially nowhere in the hospital
that he can't go. Anytime he's done a physical penetration test or just a penetration test in
general, you know, he always, this is what he does for every hospital he's gone into, he dresses up
like a janitor and they generally give him access to anywhere he wants to go, including secure
facilities or secure areas of the hospital. So, if you're looking to do physical penetration testing
at a hospital, that's probably a good plan.
So, health, there was a great talk a couple years ago at one of the Health ISAC summits
that specifically looked at printers as kind of, you know, having a lot, basically being
chock-full of PHI. So, they typically have a lot of records. You can do print last 10, you know,
especially if this is a discharge printer where, you know, if you go to the hospital, you get
discharged, you go sit in front of a nurse, she prints out your, you know, 15, 20, 50 page,
whatever medical record, gives it to you, and then you go out the door. So, that printer is
like chock-full of records. It's probably right next to an exit door, and it may or may not
require authentication. So, just something to kind of think of. Printers often get overlooked,
but it might have just as much, if not more, PHI than an actual medical device.
Access in the waiting room. This was, you know, often we think of, okay, we have to actually get
in the building to be able to find a network jack or to be able to get some sort of, you know, access
that we need. But Helen, if she's still on the line, had a great story of one of her friends
that was doing a penetration test for a hospital and found network access right from the
lobby. I don't know if she's still on. I am. So, we met up before his test. This was his first,
like, hospital test. And he goes, I imagine hospitals are like a fortress. Like, oh, no,
dear. They are not. And he's like, no, no, you're kidding me. And I'm like, yeah, they're pretty
bad. I would totally expect a flat network. So, he has a plan to say that he is, you know,
waiting for a patient. And he doesn't even need it. Nobody asks him. So, he just sits down with
his laptop. And there's a network connection there. And he's like, it can't be this easy.
Sure enough, it was live. So, definitely interesting as far as the initial gaining of
access. Emergency waiting rooms are full of people. And they aren't necessarily highly
monitored as well as lobbies. Lobbies don't always have receptionists.
Yeah. Great. Well, thank you for that story, Helen. So, what can be done about this? Obviously,
it could require IDs for all visitors. So, when they're entering a facility, it requires some
visible badge. And it could just be a sticker. It's certainly helpful if that visible badge
actually says where they're going. So, that, you know, if they're in an area where they're
not supposed to be, it's clearly visible. Restricting physical access to only areas that
these individuals should be. I mean, I've certainly been lost a number of times in
hospitals. Just, you know, you go in and then you just have access to everywhere.
They're so big, you get lost. You know, if you could actually have individuals kind of
guide people to where they're supposed to be going to. And in a large hospital,
that's obviously never going to happen. It's just too large and there's too many visitors.
But I have seen it work pretty well, again, in like a Midwest, like small critical access,
25-bed hospital, where they have a number of volunteers where they're just, you know,
looking for something to do and help out. And, you know, I've been surprised to show up at those
hospitals to install software and, you know, had a person that actually brought me from the door
to right where I needed to be. So if you're one of those small hospitals and you're looking for
something for volunteers to do, that might be a good thing that they can do to, you know,
be friendly with visitors, but also help increase your security posture.
Train staff on tailgating. And again, leveraging those, you know, if you can leverage the
differences and understand kind of why that's happening. You can lock all devices when they're
not in use. Require authentication on printers is good. And, you know, when we're locking devices
too, that's obviously, you know, that's going to be a process. You're probably looking at,
like, hospitals that do it well are doing like a tap and go system. So you just, you know, I have
my card on a lanyard and I'm just tapping it on each device that I have access to. And that's
going to look different across your hospital. Certainly in the ER, there's a little bit more
risk because you have, you know, people coming into the ER constantly. You're certainly a guest
of people that are there or patients. But, you know, in an ER, like, seconds count. So it's
understandable that there's going to be less restrictions in that setting where, you know,
having to have a doctor stop and actually log into a system is certainly going to slow down
and it could adversely affect patient outcomes. But, you know, if you can do like a tap and go
system or something that is efficient, you know, anything you can lock down, certainly the better.
But again, do it, you know, do it in a way that is useful. Again, going back to that application
support staff that I was at a hospital, if, you know, you're not, if your staff's not getting
paid over the weekend to be on call and they regularly get calls at 11 at night during shift
change, you're basically incentivizing them to open access up more than it should be so that
they don't get that call. So definitely try to avoid that. And, you know, either asking manufacturers
to, you know, filter traffic. So doing that in your assessments on devices to see if that's an option
or physically blocking a USB port, because certainly it wouldn't be the first infusion
pump that was plugged into a patient that, you know, crashed when it was actually infusing
something into a patient because someone plugged a USB, you know, whether it's something malicious
or just a phone charger, certainly if it has a USB port, someone's going to eventually try
to charge your phone with it. So just kind of be aware of that. Some other things just to kind of,
you know, go with the win-win philosophy, you know, locking down access to a hospital not only
protects PHI, but it also protects your employees and patients. You know, hospitals are places where
injured people go. That's fairly obvious. But, you know, the reason that they're injured or sick
might just be because they're sick, or it might be because they were in some violent altercation
where, you know, the assailant is now, you know, going to come back to try to do the job,
to finish the job. And we've seen an increase from 2017 in actual violence against, specifically
against staff for in U.S. hospitals. It's up 57% in the emergency department and 52%
increase outside of the ED. So certainly increasing physical security in your hospital,
again, not only helps protect PHI, but also helps protect your staff and your patients.
So thank you for that. And we have one last module coming up on vetting third parties and
talking about communication. Alright, so thanks everyone for sticking with us for the previous
five modules. This is our last module. And this is on third party communication and risk assessments.
So this is all about how if you are a hospital, and you're wondering how you gather all the
information that you need from a maybe a medical device manufacturer, a third party,
and incorporate that into some risk calculation to make decisions, purchasing decisions based on
or security decisions of, you know, what do I do for this device to secure down my network,
this would be the module for you. So, you know, again, just to try to set some stats and some
groundwork. If you're wondering how many hospitals are actually if you're a hospital that's maybe not
doing these third party risk assessments, but you're wondering what percentage of them do.
Back to the 2017 HIMSS study, and this is a little bit dated, so it's probably even
more so now, but 88% of medical facilities are conducting cybersecurity risk assessments on
third party products, so medical devices and other products. And 38% of medical facilities
are pen testing equipment. So if you're a medical device manufacturer, and you're not pen testing
your equipment, certainly be aware that your customers most likely are pen testing, or maybe
at least going to ask you and inquire about if you know if you are pen testing.
So the Ponemon study back in 2019, just looking at basically how much hospitals actually spend on
this on risk management, and HDO or health delivery organization, just a kind of a big
word for a large hospital organization, on average spends about $3.8 million a year
on third party vendor risk management. And you know, why do they do that? Well,
juxtapose that with the average cost of a data breach is about $2.9 million.
And if you look at the just the vast number of vendors that HDOs have under contract,
it's over 1300, which is just unfathomable that they're managing that.
Why they tend to do a really good job assessing all of those third parties initially when they're
first looking at them, less than 30% are actually annually reassessed. So, you know, it's a big lift
and a good amount of work to get them assessed initially, but we're not really looking at them
relooking at these technologies a year, two years, five years after they're in the door.
So if there is a concern during this risk assessment process, you know, what happens?
What do hospitals typically typically do? Well, again, looking at that same same study,
about 21% of the time, the assessment gap leads to the manufacturer remediating it.
So the customer says, Hey, we, we did a risk assessment, we found this, we're not gonna be
able to purchase the product, unless something happens. 21% of the time, the manufacturer does
something to fix that or address it. 33% of the time, the HDO, or health delivery organization
mitigates the gap themselves. So it might be, you know, cordoning off that device on its own
segments of the network, maybe a separate VLAN, or some other security, security technique to be
able to reduce that risk. And 28% of the time, medical device manufacturers should be certainly
aware of this. 28% of the time, HDOs just terminate the agreement and say this doesn't,
this device does not meet our basic security requirements, so we cannot purchase it.
So that is definitely happening in the hospital sector currently.
Why are we doing this? What is the risk? About 20% of healthcare data breaches are caused by
third-party vendors, either by, you know, the vendor or, you know, somehow associated to that
vendor. What is the cost and labor? You know, again, this course kind of focuses on smaller
hospitals, but those larger, bigger HDOs, health delivery organizations, how much time are they
spending assessing this risk? Well, the average hospital or HDO has about 3.21, so that's
obviously a percentage, but over three employees on average solely dedicated to just assessing
third-party risk. And if you do the math on that, that's about 513 hours a month that HDOs are
dedicating just specifically to looking at third-party risk of vendors that they're going to
partner with or vendors that have devices that they're considering purchasing. So can you automate
this process? Certainly you can. About a third of HDOs do use some sort of tool to automate this
process. There's a number of tools on the right-hand side that you can see. Obviously, a pretty broad
distribution. We're not going to vouch for any one, but, you know, if you have that question,
maybe it's a good question for the panel afterwards for the HDOs to see what they're currently using.
You know, if you're going to do this assessment, you should then have some baseline security
standard that you're going to measure it against. The Mayo Clinic has what they call a gold standard.
It's a list of 77 different requirements. Most of those requirements went into the new
MDS2 or the new document that basically lays out security features that we'll talk about a little
bit later. And Mayo has presented this at a number of different conferences, so you can probably find
a little bit more information from searching that. And what that allows you to do, it allows
you to... actually, some of the features, I should say, in that 77 where every device is easily
patchable, every device receives timely updates, and, you know, certainly a number of other facets.
And what this allows you to do is focus on the high-priority devices, so the devices that have a
high risk score, a potential for high risk. And also what you want to look at, too, is assess the
whole family of devices. If you're purchasing, say, five different point-of-care devices that are all
different, and the risk may be low for each of those devices, but all of those devices, you know,
send unencrypted traffic to a middleware application, you know, you want to look at that
whole family of devices and not miss something, kind of understanding that, you know, the sum of
all the parts and just looking at the devices individually. So communication, we'll talk a
little bit about communication and how HDOs and their third parties actually communicate some of
this information. So we talked about the MDS-2, which is short for Medical Disclosure Statement
for Medical Device Security. This is a standard form when a medical device goes for FDA approval,
510k approval, this is part of it. So if you ask, any medical device manufacturer should be able to
give you an MDS-2 for their product, depending on when that product came out, it might be a
different version. The latest version I was talking about that Mayo has their 77 requirements,
most of them incorporated into, came out in 2019, I think it was November or December, so that's the
latest update. So the MDS-2 is a good place to get information. Security white paper as well,
a number of medical device manufacturers create security white papers that offer a lot more
information above and beyond what's in the MDS-2. And some of that information, so you might have a
full software bill of material, includes information like which ports and services are running,
which ports are open and which services are running on the device, specifically what sensitive data
elements are stored or transmitted on the device. Probably give you a network diagram of how the
is meant to kind of live in your network, so you can see that. It'll talk about authentication,
malware protection, security testing, if security testing has been completed, so if the device has
gone through a rigorous secure development process, there should be notes on that.
The intended operating environment is important, because that's, again, going back to those
manufacturer assumptions, this is what the manufacturer assumes, or where the manufacturer
assumes that the device is going to live in. So they assume that there's going to be network
segmentation, and a firewall, and a number of other things. So it's good to certainly look at
that, because that will, that will, you'll be able to see the recommendations of how you should
secure this device, and network controls, physical controls, logging, how the manufacturer may
remotely connect to the device for service, and whether you want that or not, you can turn it on
or off, likely. Any administrative controls, how to contact both service, and then maybe the,
for a cybersecurity issue, how to look for that too. If the device has any certifications, like
ISO 27001, things like that. So how do HDOs acquire this information? It's pretty common.
What they're largely doing is sending us security questionnaires, and most medical device
manufacturers are receiving hundreds of these from U.S. customers each year. They're extremely
lengthy, extremely detailed questions. If you are tasked with creating one of these, if you can,
you know, try to create one in a good format that allows manufacturers to just kind of go through
and check off, or uncheck things that aren't applicable. So if it's, you know, not a cloud
product, you can click no, not a cloud product, and it automatically fills in NA to the next 150
questions, and the manufacturer doesn't have to click NA and then put in a comment for each as
to why it's not applicable, that would be great. Just some sample questions, you know, pretty
standard, you know. How do you get this information? Again, I can only imagine on the HDO side if you
have 1300 different, you know, third parties trying to, even if each manufacturer has their
own information portal where all of the MDS-2s and security white papers and SBOMs are in that
one centralized location, you still have to go to 1300 different portals to get that information.
There's been some industry attempts to try to have all of that information centralized to one place,
but those haven't, those have either faltered or have haven't really caught on. So maybe we'll get
there eventually, but in the meantime, you can at least, for a good amount of manufacturers,
go to one place and get all of the information that you need. You know, as I said, SBOM, MDS-2,
white papers, installation guide, you know, any other information, hopefully in that one place
to make it a little easier for you. Business Associate Agreement, or BAA, this came from the
HIPAA Omnibus Rule. So this is, you know, basically the requirement or the agreement between
the medical device manufacturer or third party that's handling secure data. So the third party
agreement with the health delivery organization. One thing to kind of note of that is this last
line, that if you are working with a third party that's offshore or outside of the U.S.,
the Office of Civil Rights, or OCR, so the group that's tasked with enforcing this,
probably doesn't have jurisdiction. So just kind of something to consider.
And if you Google BAA example, there's a number of examples that you can see. You know,
your legal department is probably going to create this, but just, you know, there are examples.
ISA, so this would be more if you're actually handling the customer's data. So, you know,
typically it would have an ISA. And again, there's, we could spend a whole class on just
creating BAAs and ISAs, but it basically just sets out the minimum expectations for securely
hosting someone else's data and follows the framework. Security Testing Considerations.
This has come up a little bit, but, you know, earlier in the class, but we just have to assume
that these hospitals are pen testing devices. If you're a medical device manufacturer,
it is a good practice to reach out to the manufacturer before you do the test and just
ask, hey, is there any considerations that I might need to know? Is there anything that if I do,
it's going to break the device? As Helen said a few times, obviously you don't want to test
in a live environment. You want to test in a test environment and kind of need to be aware that,
you know, there could be adverse reactions to pen testing, but certainly, you know, it is a good
thing to do, but just, you know, have that open dialogue with the manufacturer so that, you know,
you can have the best result of that pen test as possible and share the findings, too. You know,
certainly medical device manufacturers want to know if there's any, you know, issues that they
could potentially fix. So, thanks. That is the class. We do have a little bit extra,
so that's all the content, but again, as this class, the focus is, you know, that one or two,
so either IT or cybersecurity person working in a small hospital, this was, we tried to cram
everything into an hour and a half, you know, two hours, and here's a little bit more information on,
you know, where do I go next? How do I keep learning? How do I, you know, stay current?
Things like that. So, if you're that, again, that one person that doesn't really, that wants to stay
engaged, wants to learn more, wants to get certifications, things like that, stay involved
in the security community. If you're watching this live at DEF CON, you're probably already
engaged, but if you're watching this on YouTube after the fact, you're, you may not be. So,
obviously, there's traditional coursework out there. There's a number of different places or
organizations, universities that you can take cybersecurity training in. There's not a lot
that do specifically healthcare and cybersecurity. Salve, Virginia University does have a graduate
class on healthcare administration and cybersecurity. So, it's the only university that I
know that has numerous classes in cybersecurity and healthcare, and are kind of pairing the two
together. There's also the University of Houston may have an executive program on it, and Coursera
has a class on cybersecurity and healthcare, too. But there's not too many... I hear that Salve also
has some really cool professors in this sector. They may. So, you know, again, I don't want to
hype Salve too much, but it is interesting that they actually have, you know, if you're
looking for classes that are specific to healthcare and cybersecurity, they're the
only organization that I know that are pairing those two topics. Certifications, there's a number
of certifications that you can take. Security Plus is kind of CompTIA. Many of their certifications
are kind of considered entry level. That's a bad thing, but if you're new, that's great.
The Security Plus is interesting because it's kind of more entry level in security,
but it typically requires that you have the CompTIA A Plus and Network Plus before. I shouldn't say
that. It doesn't require it, but it recommends it. So that might be more of an entry level
or an earlier career cert. The HCISPP, so the Healthcare... was it Healthcare Information
and Security and Privacy Practitioners Certification from ISC Squared is kind of the
more of the senior level certification. It does require two years of working full time
in the security field. So that's another certification to look at. Surely there's
others out there too. Those are just two that we thought might be applicable to this group.
There's a number of great free online classes, CyberArea and Coursera. I only picked these
because they were listed in the link at the bottom for TechRadar as the top two. And having
taken classes from each, they are good. I will note that I don't know about these two, but a lot
of the free classes. So as a professor, I use some of the free courseware in my classes as like
sub-modules for teaching. And I don't know why, but basically as of like fall 2019, a lot of these
online free education courses or programs started putting some content behind a paywall and anything
like HIPAA and cybersecurity related tended to fall under that. So just be aware that some of the
content may be free and some of it you may have to pay for, but it may be reasonable. So it may be
worthwhile. It may be cheaper to just have all your employees take classes at one of these places
and pay for an organizational membership to develop your own course. Definitely get involved.
Join us in some of the industry groups that we work in. There's the Health ISAC. They have a
number of industry groups. I was leading the global data privacy group for a while. There's
groups on just about everything else. The Healthcare Sector Coordinating Council.
They have some great groups on like secure development life cycle and any number of
other things. There's a work group right now on training and development that I'm involved in
that would be a great one to get involved in if you're looking at continuing to get
more training. And there's certainly other groups out there. AIME, a number of other
organizations. These are just two that tend to be popular in the industry. Please don't
take any of these as a decisive list of everything that you can look at. And local security groups.
Again, if you're watching this live, you're probably familiar with this, but if you're
watching this on YouTube after the fact, local OWASP chapters are great for monthly meetups.
And then DEF CON. So we're at DEF CON. There's local DEF CON groups or chapters.
DEF CON 617 was a Boston group that I was involved for a while. And now I'm heavily
involved with DEF CON 401. So they do, you know, most of these do like monthly,
that's kind of like a lunch learn, but they're usually at night where they might have pizza
and someone to give a talk. And, you know, it might be a technical, it might be, you know,
it could be any topic related to security. So, and it's good for networking, kind of making
contacts within your area as well. So, and the, one of the good things, if there's a good thing
about COVID-19 is that because we're not meeting in person, a lot of these groups are doing online
meetings now that you don't have to geographically live close to, like DEF CON 401. If you look at
their meetup, they have a number of, I think the next couple months, maybe at least two or three
months are going to be online because we can't meet in person. So, you know, you can, if you
live in an area where there isn't one of these groups and you can't, if you go to like DEF CON
groups.org and try to find one in your area, but if there isn't one in your area, maybe at least
for the next couple months, who knows how long, you can visit one online. Again, if you're super
new to InfoSec, this is a good book. It was free for a while online. I don't know if it still is,
but there was a PDF for free online. If you do have to buy it, maybe it's five bucks. But yeah,
if you do do InfoSec and trying to figure out how to grow your career, learn more, you know,
get certifications, things like that. This is a great book to check out. Some other good resources,
Micah Hoffman's presentation at B-Sides on how to join the InfoSec community. Again, getting
involved. One of the great things about the InfoSec community is that, you know, we're constantly
sharing information and training each other and it doesn't really cost a lot of money,
which is great. You can just kind of go to conferences for fairly cheap and continue to
keep learning. So things to Google, you know, you can Google hacking the skills shortage,
we'll pull up good articles on that. Best information security certifications for,
you know, insert the year, five grade starter cybersecurity certifications, things like that.
We'll all kind of put you in line of understanding, you know, kind of maybe your next career step.
And not necessarily career step of just where, you know, where to go to if you to leave your
company and go somewhere else. But if you like working at a hospital, how to keep evolving your
skills so that you become a better, you know, defender of your hospital organization.
So we want to keep the conversation going. We're going to take a short break.
So definitely go get some food, get your favorite beverage, and we'll be back in a little bit to
actually have a panel discussion where you can not only talk to me and Helen,
but a number of other experts in the field that know a lot more than we do.
And some of them work at hospitals, so they can give you that perspective as well.
So let's see. Yeah, so, you know, certainly reach out, again, both in the follow-up
panel afterwards, but also, you know, if you have a specific question that you don't want
to raise there, you can reach out. Here's our contact information. We'll leave that
up for a little bit so you can email us, you know, hit us up on Twitter, you know,
however you want to get a hold of us. And we look forward to hearing from you more.
Again, take a take a good break, and then we'll be back for the panel discussion,
and we look forward to hearing some of your questions. So thanks for all of everyone paying
attention and the questions that were in the Discord channel during this training,
and we look forward to seeing you at that panel. Thanks. Thank you for your time.