[00:00.000 --> 00:04.520]  Thanks, everyone, for joining. This is Securing a Medical Device Network on a Shoestring Budget
[00:05.620 --> 00:12.880]  by Helen and myself, Matt McMahon. We'll be your presenters today. This will be recorded,
[00:12.880 --> 00:18.920]  pre-recorded and streamed, but we will be available on Discord to answer any questions.
[00:19.580 --> 00:23.560]  Just a little bit of an intro in the class. This initially was a four-hour course,
[00:23.560 --> 00:29.300]  and we cut it down, so we will be trying to cover a good amount of topics in a little bit
[00:29.300 --> 00:34.520]  of a short time, but it will be recorded and played again, so they're available again on
[00:34.520 --> 00:39.040]  YouTube. So if you need to get up to get a drink or use the restroom, feel free to do that and
[00:39.040 --> 00:45.400]  come back, and you can look at any parts that you missed afterwards. So just to kind of give a quick
[00:45.400 --> 00:51.700]  synopsis of where this training came from. So Helen and I both work for a medical device company
[00:51.700 --> 00:58.060]  in their cybersecurity group. We're also both either current or former adjunct professors
[00:58.060 --> 01:02.520]  teaching courses in cybersecurity, healthcare, digital forensics, and things like that.
[01:02.640 --> 01:08.380]  So we thought this would be a really good class for hospitals to kind of understand some of the
[01:08.380 --> 01:13.240]  basics. So this is a totally free course, open to anyone, and we're really just looking to share
[01:13.240 --> 01:20.240]  knowledge. So a note on our target audience. We developed this course initially for the target
[01:20.240 --> 01:26.460]  audience being like a small critical access, like 25-bed hospital, with a smaller IT staff and a
[01:26.460 --> 01:34.360]  limited budget. They may not have any cybersecurity staff currently in the workforce.
[01:35.000 --> 01:40.080]  So there will be things that larger hospital organizations or other individuals can get out
[01:40.080 --> 01:45.060]  of this course, but if some of the material, at least in the beginning, seems kind of basic,
[01:45.060 --> 01:51.600]  just kind of bear with us. We're trying to set the stage so that target audience can pick up
[01:51.600 --> 01:57.420]  and kind of follow us for the whole course. So what we're going to cover today, we're going
[01:57.420 --> 02:03.980]  to have six different distinct modules. So I'll start with the healthcare threat landscape today,
[02:03.980 --> 02:08.140]  then Helen will take over for basic network security within the hospital,
[02:08.140 --> 02:12.640]  network monitoring and scanning, developing and regular patching strategies,
[02:12.640 --> 02:17.820]  then I'll take back over at the end for physical security, and then vetting of third parties.
[02:18.420 --> 02:23.260]  We'll then have a short break, and then we'll come back for a panel discussion,
[02:23.740 --> 02:30.300]  both with Helen and myself, and a number of other experts from the hospital cybersecurity space. So
[02:31.160 --> 02:37.160]  make sure to come back for that. As I said before, this training is pre-recorded. So we are,
[02:37.160 --> 02:41.040]  while we're teaching, we're not teaching right now, this was pre-recorded, so we are able to
[02:41.040 --> 02:47.640]  answer questions on the Discord channel. And be aware, too, that we do have that panel afterwards.
[02:47.640 --> 02:53.120]  If there's a question specifically on how a hospital may do something, we may defer to the
[02:53.120 --> 02:58.040]  panel, just because then you'd be able to actually hear from hospital staff on how they would handle
[02:58.040 --> 03:05.000]  certain situations. So just to kind of start off and set the stage, it's important before you really
[03:05.000 --> 03:09.240]  can secure or defend anything, you kind of need to know your current threat landscape, and certainly
[03:09.240 --> 03:14.120]  healthcare is a little bit different than some other threat landscapes. So a lot of the data
[03:14.120 --> 03:19.120]  that we'll be pulling from the Verizon Data Breach Investigation Report, obviously that comes out
[03:19.120 --> 03:23.380]  each year, there's a lot of good data that comes with it. But there's another report called the
[03:23.380 --> 03:30.120]  Protected Health Information Data Breach Report. It takes the DBIR's data specifically just on
[03:30.120 --> 03:35.380]  healthcare and the healthcare sector related to data breaches. It takes those stats over the
[03:35.380 --> 03:40.760]  course of three years and extrapolates some data from just the healthcare sector. So we'll be
[03:40.760 --> 03:48.740]  talking a lot about information from those reports. PHI, I mean, this is probably not
[03:48.740 --> 03:53.120]  anything new to anyone that's currently working in the field, but just in case you don't know,
[03:53.120 --> 03:59.280]  medical record, why is it valuable? It could potentially sell for 10 to 20 times on the
[03:59.980 --> 04:05.100]  black market. What a credit card record could sell for, you can't turn off a PHI record,
[04:05.100 --> 04:10.320]  protected health information record, like you can a credit card. An attacker could potentially
[04:10.320 --> 04:16.320]  use the stolen data to acquire expensive medical equipments or technology. And then an attacker
[04:16.320 --> 04:21.940]  could also combine PHI with a provider number to file fraudulent insurance claims. Just
[04:23.320 --> 04:29.660]  very quick, some possible things that could happen. One of the things that makes the threat
[04:29.660 --> 04:36.040]  landscape and healthcare really unique is the prevalence of insider threats. And when we say
[04:36.040 --> 04:40.980]  insider threats, we typically think of malicious insider threats, but healthcare is unique in that
[04:41.640 --> 04:46.580]  there's a lot of error that factors into that as well. So non-malicious errors and
[04:47.320 --> 04:54.400]  data breaches as a result of that. In healthcare, 58% of data breaches over the course of those
[04:54.400 --> 04:59.600]  three years that were recorded did have some insider component. Again, both malicious and
[04:59.600 --> 05:04.420]  non-malicious, but that is important to note. It's the only critical infrastructure sector in the
[05:04.420 --> 05:08.920]  United States. They're actually more likely to be compromised internally than externally. So
[05:08.920 --> 05:15.240]  we want to make sure that we're taking into account that. So what's the breakdown of some
[05:15.240 --> 05:21.440]  of the threats? So we talked, I said some of this were non-malicious, so a lot of it is error.
[05:21.440 --> 05:29.500]  You can see over 30%, 33.5% is just error. So individual staff, maybe clinical staff working
[05:29.500 --> 05:34.900]  long hours, swing shifts, too many patients than they would normally have certainly in the COVID
[05:34.900 --> 05:40.440]  era. Working with technology that they might not be familiar with, it's easy to make a mistake
[05:40.440 --> 05:45.760]  and cause a data breach that way. Misuse would be the second highest, just under 30%.
[05:46.980 --> 05:52.680]  Misuse in this case would have a deliberate component. So it could be as simple as nurse A
[05:52.680 --> 05:58.380]  tells nurse B, hey, did you hear about this patient? And nurse B shouldn't have access to
[05:58.380 --> 06:03.080]  that patient, or it could be selling hundreds of thousands of records. So there's a broad
[06:03.080 --> 06:09.380]  spectrum there. Physical, we'll touch on a little bit. And what's interesting with this graph,
[06:09.380 --> 06:15.280]  is you see, if you look on the news, or just search cybersecurity and healthcare,
[06:16.080 --> 06:20.100]  pretty much what you're going to see is a lot about ransomware. And certainly we'll talk about
[06:20.100 --> 06:26.180]  ransomware in this presentation about how prevalent it is, and how it's becoming much
[06:26.180 --> 06:30.640]  more prevalent. But it's just important if you're trying to defend the hospital's network,
[06:30.640 --> 06:34.400]  to kind of know where your threats are really coming from. Certainly you want to defend against
[06:35.040 --> 06:41.020]  quote, unquote, hacking, or malware, ransomware. But we'll also want to make sure that we're aware
[06:41.020 --> 06:49.560]  of the fact that our largest threats might actually be already inside the building,
[06:49.560 --> 06:55.580]  someone that we've actually given access to. So if we dive down into those errors, again,
[06:55.580 --> 07:03.520]  over 30%, misdelivery was the biggest. So sending PHI somewhere where it wasn't intended to go to.
[07:04.700 --> 07:10.700]  Disposal error, so we think we've properly cleared a device, or this could be paper records as well.
[07:10.960 --> 07:16.320]  Loss, we just lost the data, we didn't know where it went to. Publishing error. Publishing error
[07:16.320 --> 07:20.940]  typically would be like a study. So we've released a study that we think had anonymized data,
[07:20.940 --> 07:27.720]  that data was able to be de-anonymized, and they were able to... basically resulted in a data
[07:27.720 --> 07:34.000]  breach. What do you find interesting about this is, there was a quote in the report that said
[07:34.000 --> 07:39.520]  healthcare has a paper problem. Typically when you think data breach, we think electronic,
[07:39.520 --> 07:44.140]  but 43% of all the data breaches that were recorded were actually still on paper.
[07:44.440 --> 07:49.100]  So moving to electronic could actually reduce the overall data breaches.
[07:49.760 --> 07:54.680]  Data misuse, so again, misuse required that distinct motive. It could be as simple as
[07:54.680 --> 08:01.280]  nurse A tells nurse B, hey, your ex-significant other is in the hospital, did you hear about it?
[08:01.280 --> 08:09.100]  Or it could be selling records. And let's see, and typically this involved at least two-thirds
[08:09.100 --> 08:13.980]  of privilege abuse. So accessing data that they shouldn't have access to,
[08:13.980 --> 08:23.280]  maybe escalating their own privileges. Physical, physical was pretty close to 100%, over 95% just
[08:23.280 --> 08:30.300]  stolen on encrypted laptops. If this was a doctor's laptop that was stolen but encrypted,
[08:30.300 --> 08:35.340]  they don't include that as a potential data breach, just because they assume that an attacker
[08:35.340 --> 08:40.000]  wouldn't be able to get to that data. But if the data is non-encrypted, then they assume that they
[08:40.000 --> 08:47.440]  are able to get to that. So yeah, interesting with this picture, that while the attacker did
[08:47.440 --> 08:53.080]  break the window and steal the unencrypted laptop full of PHI, they did at least leave the font
[08:53.080 --> 09:00.740]  So that's nice. And quote-unquote hacking, this is kind of a broad, broad category,
[09:00.740 --> 09:07.520]  but this included almost 50% was phishing, social engineering. And again, just try to remember that
[09:08.280 --> 09:13.520]  this is below 15% of the overall data breaches. So again, we're just talking about data breaches
[09:13.520 --> 09:19.140]  here, not necessarily cyber attacks that bring down hospital networks, but specifically data
[09:19.140 --> 09:26.400]  breaches and breaking that down. So just under 50% of that was using stolen credentials that
[09:26.400 --> 09:32.140]  were harvested, again, potentially from phishing or social engineering. Over 20% was brute forcing
[09:32.320 --> 09:40.620]  a password. 17.9%, so almost 18%, was using a backdoor on a device, could be a medical device,
[09:40.620 --> 09:47.140]  could be software, whatever that backdoor is. And then you see minimal for the other ones.
[09:48.240 --> 09:55.460]  Malware, so general category of malware is just under 11%. Again, kind of keep in mind the
[09:55.460 --> 10:02.560]  prevalence of that internal error, and over 70% of that was specifically ransomware. So obviously,
[10:02.560 --> 10:12.020]  that's a factor. So while I am trying to highlight the fact that insider threat is statistically a
[10:12.020 --> 10:16.700]  lot bigger for data breach, data breaches within the healthcare sector, obviously,
[10:16.700 --> 10:22.380]  malware, there is certain caveats that we need to talk about, it is certainly increasing.
[10:22.980 --> 10:27.680]  This was an interesting report that came up from NTT Security. They published a report
[10:27.680 --> 10:33.620]  back in, it's a little bit dated now, but Q2 of 2016. They looked at their entire,
[10:33.620 --> 10:39.760]  so their security company, they looked at their entire customer portfolio, 7.4% of their customers,
[10:39.760 --> 10:45.820]  only 7.4% of their customers were hospitals. But those hospitals made up 88% of their clients
[10:45.820 --> 10:51.080]  that were affected by ransomware. So it really said, wow, while hospitals make up a small
[10:51.080 --> 10:55.560]  percentage of our actual customer base, they're disproportionately affected by ransomware.
[10:55.560 --> 11:01.800]  And we'll certainly get in this class as to why that is. Flat networks, lack of proper
[11:02.680 --> 11:07.920]  security controls, things like that. And it was predicted that ransomware attacks in the
[11:07.920 --> 11:14.000]  healthcare sector would quadruple in 2020. And certainly we've seen an increase in that.
[11:16.460 --> 11:21.400]  All right. COVID-19, I can't really have a talk now and not talk about COVID-19. So
[11:21.400 --> 11:26.480]  certainly that's changed the threat landscape as well. Not just in healthcare, but across the board
[11:26.480 --> 11:33.820]  we've seen a 667% increase in COVID-19 related email attacks, just from February to June.
[11:33.820 --> 11:42.000]  And then just cyber attacks in general up 37% in May. And what's interesting with COVID too,
[11:42.000 --> 11:46.540]  is we're not just seeing cyber attacks, but we're also seeing a lot of fraud.
[11:46.660 --> 11:52.700]  Interpol has seized over $14 million worth of fake PPE. And certainly hospitals have been caught with
[11:53.760 --> 11:59.220]  purchasing or trying to purchase PPE in the past when it was a little bit harder to get.
[11:59.760 --> 12:04.940]  Maybe they had to front funds to get those, and then they just never got their equipment. So
[12:06.000 --> 12:10.100]  there's a lot of different possibilities there for compromise.
[12:10.720 --> 12:14.640]  For folks that work in the cybersecurity and healthcare space or industry,
[12:14.640 --> 12:19.640]  this was an interesting report that came out in March. Basically a number of ransomware shops
[12:20.160 --> 12:28.520]  said that, no, we won't specifically target the healthcare sector or hospitals during a pandemic,
[12:28.520 --> 12:34.960]  because that would be incredibly bad. Unfortunately, that was not the case.
[12:34.960 --> 12:41.840]  They still have continued to attack the healthcare sector. And in many cases, it's actually
[12:41.840 --> 12:49.200]  increased. So we've seen Health ISAC has reported an increase in COVID-19 themed attacks, up 20% to
[12:49.200 --> 12:54.960]  30% in just phishing, specifically targeting the healthcare sector. And you can see there,
[12:54.960 --> 12:59.980]  the average ransom payments. And obviously, during a pandemic, there's a lot of things that
[12:59.980 --> 13:06.360]  make this more difficult. Obviously, getting physical access to a device, if it's in a
[13:06.360 --> 13:11.560]  quarantined area, to be able to update it. If you need to physically access the device to
[13:11.560 --> 13:19.140]  update something, that just adds an extra layer of issue.
[13:19.140 --> 13:21.760]  So how many hospitals do we know of that have actually been attacked
[13:22.440 --> 13:29.240]  or been compromised by ransomware, specifically using a COVID-19 hook?
[13:29.440 --> 13:35.520]  According to Bill Siegel, the CEO of Coveware, there's been at least half a dozen just in the
[13:35.520 --> 13:39.600]  US. There's probably significantly more than that, but those are the ones that we're aware of.
[13:41.020 --> 13:45.520]  There is certainly a good amount of under-reporting. It's difficult to really
[13:45.520 --> 13:51.760]  understand the scope. Hospitals, in a lot of cases, pay the ransom. It may not be reported
[13:51.760 --> 13:57.340]  if we don't believe that there's a data breach. So it's hard to tell the exact number, but we
[13:57.340 --> 14:04.180]  know of at least half a dozen in the US. In Canada, a Canadian government hospital there
[14:04.180 --> 14:11.440]  was affected. It was specifically targeted using a spoofed email that appeared to look like it
[14:11.440 --> 14:15.920]  came from the World Health Organization. It was procurement-related, so this was a couple months
[14:15.920 --> 14:21.720]  back when procurement of gloves, masks, things like that were quite difficult. If you read the
[14:22.340 --> 14:28.320]  email, it was really easy to spot if you knew what you were looking for. The authors really
[14:28.320 --> 14:34.100]  didn't make any attempt to make it look legit in any way, but because of the need for procurement
[14:34.100 --> 14:40.680]  materials at that point, again, gloves and masks, it was clicked on and propagated.
[14:41.440 --> 14:49.880]  Spain. Spain at that time was particularly hard-hit by COVID-19, and the Spanish hospital
[14:49.880 --> 14:54.560]  was hit by the Netwalker ransomware. It specifically targeted Spanish hospitals,
[14:54.560 --> 15:00.740]  specifically during the peak of the virus there, using a malicious attachment.
[15:02.080 --> 15:08.800]  Czech Republic as well. Brno, I believe, had that saying. I hope that's not incorrect.
[15:08.800 --> 15:12.360]  University Hospital, which was the second largest hospital in the Czech Republic,
[15:12.360 --> 15:21.840]  was taken offline. It was forced to shut down, and this attack was very want-to-cry-esque.
[15:25.770 --> 15:30.570]  So not just really hospitals, but we're also looking at laboratories and supply chains.
[15:30.570 --> 15:37.910]  So in California, the 10X Genomics Company was hit by COVID-19-related or themed ransomware.
[15:37.910 --> 15:43.150]  A urology consultant company was hit. Medical device manufacturers have been hit.
[15:44.590 --> 15:48.270]  So why target healthcare? Well, hospitals, as we said earlier,
[15:48.270 --> 15:54.050]  unfortunately often pay the ransom. There is a need to be online. These technologies are
[15:54.050 --> 15:58.790]  life and death, and often they have less resources to be able to defend themselves,
[15:58.790 --> 16:07.670]  so it might be easier to attack a hospital. So some quick key takeaways. Privilege and
[16:07.670 --> 16:13.770]  escalation abuse was two-thirds of all the incidents. Now, having been someone that worked
[16:13.770 --> 16:21.750]  for a hospital for a while, doing application access and having to monitor access, I can
[16:21.750 --> 16:30.650]  certainly say that this is difficult. A lot of this really depends on how those individuals are
[16:31.650 --> 16:36.230]  keeping access. Certainly, you want to restrict access as much as possible. You don't want to
[16:36.230 --> 16:43.810]  leave it open. But in my case anyway, it was certainly noted that the application support
[16:43.810 --> 16:49.570]  staff were working on call on the weekends, and they were not being paid to work on call.
[16:49.570 --> 16:52.610]  So if you're doing that, you're basically creating a situation that
[16:53.770 --> 17:01.630]  encourages or incentivizes your IT staff to leave access more broadly open than it probably needs
[17:01.630 --> 17:07.010]  to be so that they're not getting a call at 11 o'clock at night during shift change when
[17:07.010 --> 17:14.170]  new nurses come on, maybe temporary nurses that need access. So just kind of think about that,
[17:14.170 --> 17:21.570]  maybe how your hospital IT staff or application support staff have to deal with access. Do you
[17:21.570 --> 17:26.930]  have someone that's constantly working, or is it on call? It certainly comes into play.
[17:29.330 --> 17:34.310]  Data mishandling. So this was, you know, kind of a cultural problem that we're talking about where,
[17:34.310 --> 17:39.590]  you know, nurse A tells nurse B, hey, did you hear about this individual? This was almost 17%
[17:39.590 --> 17:46.310]  of the data breach cases. So, you know, something to kind of consider. Certainly, it's human nature,
[17:46.310 --> 17:51.810]  curiosity, so it's difficult, but something to consider. Fraud in the healthcare sector,
[17:51.810 --> 17:56.170]  there is a large amount of fraud in the healthcare sector. It's the third highest
[17:56.770 --> 18:01.770]  industry for fraud in the United States, right behind the government sector, and finance was
[18:01.770 --> 18:09.570]  number one. Breach discovery is also an issue within healthcare. Approximately one-third of
[18:09.570 --> 18:14.510]  the data breaches in the three-year study were not discovered for years. Another third were not
[18:14.510 --> 18:21.750]  discovered for months. So it's important to kind of note that, you know, when you're looking at the
[18:21.750 --> 18:26.810]  numbers or considering if you've been breached, you know, many hospitals may not even be aware of
[18:26.810 --> 18:33.250]  it, so... And just one other thing that kind of complicates this, budgeting and staffing
[18:33.250 --> 18:38.730]  realities, it's commonly cited by CISOs from hospitals that 3% of the hospital budget goes
[18:38.730 --> 18:46.670]  towards IT, and 3% of that 3% goes to security. So they really don't have a lot of, you know,
[18:46.670 --> 18:52.770]  either the staff or the resources that they need to dedicate to security. So that really kind of
[18:52.770 --> 18:57.010]  leads into one of the reasons why we built this course, to try to offer some, you know, free
[18:57.010 --> 19:04.630]  technology, in this case free training, or low-cost technology that could be used to secure a
[19:05.090 --> 19:12.430]  hospital's network. Another issue is what's called agency staff. So at any given hospital, up to 10%
[19:12.430 --> 19:18.730]  of the nurses could potentially be agency staff. So someone calls in, we need someone to, you know,
[19:18.730 --> 19:23.970]  take their shift, they call the agency, they get a nurse, that person then has to be added to all
[19:23.970 --> 19:29.870]  the hospital systems. Certainly if you're working in IT at a hospital, please fight the urge to
[19:29.870 --> 19:36.470]  just create entries in your system called agency nurse 1, 2, or 3. It certainly makes it easier
[19:36.470 --> 19:41.690]  for IT staff, but obviously, you know, for logging and things like that, it could be a bit of a
[19:41.690 --> 19:48.690]  nightmare. So just kind of be aware of that. Just some quick insights from the 2009 HIMSS report
[19:49.370 --> 19:56.450]  of all of the hospitals that were surveyed. Over the course of the last 12 months, 82% of hospitals
[19:57.050 --> 20:03.230]  said that they did have a recent significant security incident. So kind of good to note of
[20:03.230 --> 20:09.750]  the prevalence of how much this is happening. Legacy systems are also an issue. 72% of hospitals
[20:09.750 --> 20:16.890]  said that up to between 1 and 10% of their technology is outdated legacy tech. And if you
[20:16.890 --> 20:24.270]  look at 2016, the 2016 HIMSS study, it interviewed or looked at 200 different hospitals, but I believe
[20:24.470 --> 20:28.950]  a third of those, or I shouldn't say hospitals, 200 different medical facilities, but a third of
[20:28.950 --> 20:35.510]  those were like doctor's offices and smaller offices. So certainly those, that third skewed
[20:35.510 --> 20:39.730]  the stats a little bit. So you can kind of factor that in when you're looking at these numbers.
[20:39.750 --> 20:45.330]  But it's still a little bit scary to even think that those, even if it's like an outpatient clinic
[20:45.330 --> 20:51.110]  or a doctor's office, that numbers would be this high. So 14% of those medical facilities lacked
[20:51.110 --> 21:00.230]  any antivirus or malware, under 20% no firewall protections, 46% no network monitoring, 52%
[21:00.230 --> 21:07.750]  no intrusion prevention, and 41% didn't encrypt data at rest. Again, this is 2016. HIMSS doesn't
[21:07.750 --> 21:13.830]  ask the same questions every year, so we can't see trends, but just kind of something to take
[21:13.830 --> 21:21.330]  into account. So this is the last slide of this. And again, just to kind of talk about our
[21:21.330 --> 21:26.550]  objective, we're really trying to train those small critical access hospitals on some of the
[21:26.550 --> 21:35.370]  things that they can do to help bolster their cybersecurity posture. And this is what's up next.
[21:35.370 --> 21:39.070]  Helen will be taking you over next with basic network security.
[21:39.070 --> 21:45.690]  Thanks for that, Matt, and for really just setting the table here.
[21:45.690 --> 21:52.710]  I wanted to go ahead and preface that in the interest of time, I've removed demos, but I've
[21:52.710 --> 22:05.050]  added a slew of links on added resources, places where you can get demos, and just manuals and
[22:05.050 --> 22:10.670]  the like to the end of this presentation that all the decks will be available to whomever would
[22:10.670 --> 22:17.770]  like them. I also included any slides that I removed in order to streamline this presentation
[22:18.410 --> 22:25.510]  and hit our time restraint. I include them in that slide deck and with my notes. So if you
[22:25.510 --> 22:31.570]  have any questions, you can go ahead and look through that and then reach out to me or Matt.
[22:33.130 --> 22:41.030]  We're going to start with the little parts of network security, you know, cyber hygiene, and
[22:41.030 --> 22:52.130]  just the basics. As Matt said, the 2019 HIMSS study shows the importance of the network
[22:52.130 --> 23:01.070]  security basis, basics. A pattern of cybersecurity threats are discernible across U.S. healthcare
[23:01.070 --> 23:12.450]  organizations, and as Matt has just said, the trend has only increased in the current pandemic era.
[23:14.740 --> 23:22.000]  Elements of network security, there are so many. I have asked this question of other people,
[23:22.000 --> 23:28.920]  and everybody can give you, you know, 20 talking points of things that they find to be
[23:28.920 --> 23:36.320]  the core of network security. Here are some of those elements. We're going to talk about
[23:36.320 --> 23:44.920]  access management, segmentation, we'll go a little bit into firewalls, and we'll finish up with some
[23:44.920 --> 23:57.810]  testing. Now, we're not just coming up with network security requirements out of the air.
[23:57.810 --> 24:08.890]  There is HIPAA support, there is industry support, hospitals need to protect their sensitive data.
[24:10.550 --> 24:18.410]  Network security for the uninitiated and overworked, I understand it's really difficult,
[24:18.410 --> 24:25.070]  but hopefully with this primary, you'll be armed with the tools to at least ask the right questions
[24:25.070 --> 24:37.530]  of your external consultants or Dr. Google. Strong access management is key. You want to
[24:37.530 --> 24:46.650]  secure your endpoints, ensure your remote workers use a VPN. You want to have strong but manageable
[24:46.650 --> 24:55.310]  passwords. You want to use multi-factor when applicable or possible. I understand that
[24:55.310 --> 25:02.590]  it is very common in a lot of workflows in a hospital staff to use their badge already for
[25:02.590 --> 25:11.950]  access, so having them switch to badge and pin is not a stretch. It would be within a normal workflow.
[25:13.090 --> 25:18.430]  Physical controls to limit access to restricted areas are a must, and Matt will get to those
[25:18.430 --> 25:24.530]  later. You want to review administrative accounts, access to servers and workstations
[25:24.530 --> 25:29.830]  and devices. You don't want local admin accounts that can lead to unintended privilege
[25:30.430 --> 25:38.730]  access to systems or data. You don't want generic lab user one. You really want to know who is
[25:38.730 --> 25:47.850]  accessing your data and why. Review the process for elevating access as a request and make sure
[25:47.850 --> 25:54.250]  that there's a separation of duty policy for administrative access. Review shared accounts
[25:54.250 --> 26:00.350]  for necessity and then monitor out for abnormalities or misuse. And finally, you want to
[26:00.350 --> 26:07.970]  review your terminated employees or people that are on leave of absence. If those accounts are
[26:07.970 --> 26:21.070]  not terminated quickly, they can be used inappropriately. The principle of least privilege
[26:22.070 --> 26:37.950]  is one of the basic principles of user access. You don't want one mastered user that has all
[26:37.950 --> 26:47.290]  the keys to the kingdom. If that user is compromised, you are compromised. You don't
[26:47.290 --> 26:52.190]  want one person performing every duty. You want to spread those duties around and you want to have
[26:52.190 --> 27:02.870]  more than one person accessing an area. With that in mind, sorry, I do want to start this over.
[27:05.330 --> 27:12.910]  That was the concept of separations of duty, not the least privilege. The concept of least privilege
[27:12.910 --> 27:22.470]  is that you want to have the user have the minimum access needed to do their job.
[27:28.200 --> 27:35.620]  Network segmentation. Network segmentation is the practice of dividing larger computer networks
[27:35.620 --> 27:43.180]  into several smaller subnetworks that are each isolated from one another. If you think of this
[27:43.180 --> 27:51.840]  like a fence around your house, if you have a fence around your house and you don't have
[27:51.840 --> 27:57.920]  any other protection to keep your house from being broken into, all somebody needs to do
[27:57.920 --> 28:06.180]  is find a way to get in through your fence, right? So that's what you would have even if you just
[28:06.180 --> 28:15.080]  have one firewall or one access area of protection. If you are creating a bunch of smaller
[28:15.680 --> 28:24.600]  networks, smaller segments, even if one area is compromised, the other areas can remain protected.
[28:29.160 --> 28:35.720]  Here are some examples of what a flat network looks like and that's what we have seen in a lot
[28:35.720 --> 28:43.700]  of hospitals. You have the internet and everyone can access the internet and all the equipment
[28:43.700 --> 28:53.120]  runs on the same network and it's almost set up like a home network but in a business that runs,
[28:53.120 --> 29:00.860]  that deals with such sensitive information. The next slide, the next picture is a basic
[29:02.920 --> 29:10.660]  segment and here is an idea of what segmentation in hospitals looks like.
[29:13.080 --> 29:20.920]  Here are, so a VLAN is a logical partition in the layer two network and here's a
[29:21.640 --> 29:25.200]  background of what a switch would look like and
[29:28.400 --> 29:41.680]  some ideas of what the logical layout would look like. So I have removed a section on types of
[29:41.680 --> 29:49.940]  firewalls. There are several types of firewalls and you should look to find which kind suit your
[29:49.940 --> 29:56.320]  purpose. There is some great information out there. I've included that in our resources at
[29:56.320 --> 30:03.300]  the end. Firewalls are your first line of defense for securing healthcare networks from against
[30:03.780 --> 30:09.420]  the public. Firewalls are digital walls that stand between protected health data and potentially
[30:09.420 --> 30:18.700]  dangerous threat actors. You want to start by blocking all, by blocking all traffic by default
[30:18.700 --> 30:24.300]  and then only allowing specific traffic to identify services. This approach provides
[30:24.300 --> 30:29.200]  quality control over traffic and decreases the possibility of breach. You're going to
[30:29.200 --> 30:38.420]  want to make changes slowly over time and I understand that sometimes this is impractical
[30:38.420 --> 30:45.380]  but you want to do this in small segments and secure your network over time during downtime
[30:45.380 --> 30:56.680]  and maintenance zones, maintenance periods. So the approach of quality control over traffic
[30:57.660 --> 31:05.460]  can be achieved by controlling the last rule in an access control list to denial traffic.
[31:05.460 --> 31:09.760]  And this can be done explicitly or implicitly depending on the platform.
[31:29.280 --> 31:35.700]  So you follow an established set of rules and then firewalls can actively monitor incoming
[31:35.700 --> 31:42.900]  and outgoing traffic. In doing so, a firewall blocks the secure network from the internet,
[31:42.900 --> 31:52.940]  only allowing pre-cleared data to pass. So you want to know the firewall's purpose,
[31:52.940 --> 32:01.680]  what the affected devices are, what users have access, what date your rule applied,
[32:01.680 --> 32:04.560]  and who's the name of the person who added the rule.
[32:05.880 --> 32:14.260]  Some inbound rules are whitelists, which are falling out of favor and are being called allow
[32:14.260 --> 32:23.580]  lists or a few other terms, which will be, you know, only allowing Jim and Mary to go to the
[32:23.580 --> 32:30.560]  insurance billing information website. These are who's allowed to access an area. There's a deny
[32:30.560 --> 32:43.060]  list, which is, you can go ahead and allow these doctors to go anywhere except ratemymd.com. You
[32:43.060 --> 32:49.660]  don't want them reading reviews and getting upset on shift. You want to block, so you're not going
[32:49.660 --> 32:58.380]  to allow one person access to anything, whatever the thing you're saying. Okay, this guy is in
[33:00.700 --> 33:06.320]  environmental services. He doesn't need to access financial records. That's blocked all together.
[33:06.360 --> 33:13.140]  And then a VPN. So you say, okay, you're only going to allow this physician that works from
[33:13.140 --> 33:19.740]  home to access our network if they're using our approved remote access avenue.
[33:21.140 --> 33:27.100]  SANS has some great firewall information. I'll have links to that in the resources at the end
[33:27.100 --> 33:35.500]  of my deck. And they have a firewall checklist. The main purpose of the firewall is to drop all
[33:35.500 --> 33:41.240]  traffic that is not explicitly permitted as a safeguard to stop uninvited traffic from passing
[33:41.240 --> 33:49.320]  through a firewall. You want to place a drop any, any, well, an any, any, any drop rule. It's a
[33:49.320 --> 33:55.540]  cleanup rule. So if you forget about something, this default rule will clean it up. You want to
[33:55.540 --> 34:01.340]  have this at the bottom of each security zone. And this will provide just a catch all,
[34:01.940 --> 34:08.500]  catch all mechanism for capturing traffic. Here's an example of what a cleanup rule would look like.
[34:10.200 --> 34:18.400]  It's also important to note that with all of this, you need robust documentation
[34:18.870 --> 34:27.220]  and a strict change procedure. Firewalls rules will need to be updated for any new service or
[34:27.220 --> 34:33.460]  new devices. They're going to have changes over time. But before adding or changing or removing
[34:33.460 --> 34:40.820]  any rules, you want to implement a formal change procedure that can make sure you're keeping track
[34:40.820 --> 34:49.870]  of the modifications. So here are some guidelines for those procedure, change procedures.
[34:54.420 --> 35:05.890]  I know automation is a important topic and automation is definitely possible with firewalls
[35:05.890 --> 35:13.810]  configuration, for rules, for management of your fleet. You can manage windows firewalls
[35:14.350 --> 35:22.490]  via domain group policies. You can use configuration management for traditional
[35:22.490 --> 35:31.310]  firewalls. You can use something like granted. Linux has web-based tools to manage
[35:33.690 --> 35:40.950]  network routers, switches, firewalls, etc. You can have a fleet managed
[35:42.390 --> 35:48.890]  software so, you know, like certain vendors will have their own tools to manage their fleets.
[35:49.390 --> 35:55.350]  And it's the same with wireless access points. So you'll want to pick the management tool that
[35:55.350 --> 36:05.490]  works for your particular network. When working in windows, you can manage all the firewalls via
[36:05.490 --> 36:13.810]  domains, group domain policies. Here's the Linux note and the other items I just mentioned.
[36:14.650 --> 36:22.130]  Testing. So it's not enough to assume that you've applied adequate security controls.
[36:22.130 --> 36:30.950]  You want to make sure that you test different aspects of security either for compliance.
[36:31.030 --> 36:37.750]  You might have a customer or a patient that has questions and if they're a large donor or
[36:37.750 --> 36:45.330]  something you might be motivated enough to test this. There might be a need for some sort of
[36:45.330 --> 36:53.670]  full red team engagement or overall whatever you want to do to assess risk readiness.
[36:54.050 --> 37:02.330]  And it is important to pick a strategy. And there's different levels of depth here.
[37:02.350 --> 37:10.970]  There's the vulnerability scanning or security scanning which is automated. There are several
[37:10.970 --> 37:19.250]  tools out there for this. And it's to get an idea of basic weaknesses. So are there patches
[37:19.250 --> 37:27.290]  that haven't been applied yet? Are there ports open that might be suspicious? What's the idea
[37:27.290 --> 37:34.890]  of traffic going on right now? It gives you an idea of your risk in an automated way so you don't
[37:34.890 --> 37:42.650]  have to have an extra resource devoting time to that. It does not by any means replace more robust
[37:42.650 --> 37:50.350]  security measures but it is a way to get an idea of what's going on and what weaknesses you may have.
[37:51.090 --> 37:59.170]  A pen test is more in-depth. It involves a person simulating
[37:59.170 --> 38:06.790]  different types of attacks in order to find as many vulnerabilities as possible. They will provide
[38:06.790 --> 38:15.190]  you with a report and depending on if you're what the agency you're going with to do this or
[38:15.190 --> 38:20.490]  what kind of your internal testers, what their process is, they may also help you find
[38:20.490 --> 38:25.650]  remediations for that. Risk assessments are more
[38:28.010 --> 38:37.010]  either enterprise risk management or sometimes compliance related. It's a process of reviewing
[38:37.010 --> 38:43.570]  and analyzing potential risks that later you can prioritize and get business input on
[38:43.570 --> 38:50.970]  and you're going to try to come up with a plan as to see what the possible ways of preventing
[38:50.970 --> 38:58.190]  these risks from becoming a reality. So you're going to prioritize components that carry the
[38:58.190 --> 39:05.650]  highest risk and you'll say, okay, this stores most of our patient data, for example. We're
[39:05.650 --> 39:11.150]  going to go ahead and market for some more robust testing so we can get an idea of where our
[39:11.150 --> 39:19.030]  are and really plug those holes to the best of our ability. Security auditing is verification.
[39:19.430 --> 39:25.190]  You can audit your access management policy. You can also use this tied to compliance
[39:26.110 --> 39:34.270]  and you can analyze the system in working conditions. You're taking a view of what's
[39:34.270 --> 39:41.850]  going on. You're not... the chances of something going offline or breaking are quite slim.
[39:41.990 --> 39:47.410]  That can happen in a test, in a penetration test, but not so much in a risk assessment.
[39:50.470 --> 39:58.290]  Sorry, not so much in auditing or reviews. Red teams are similar to a pen test,
[39:58.290 --> 40:04.250]  but it's more targeted and it usually involves more than one person. It is a team of people
[40:04.250 --> 40:13.770]  that are trying to get in using the techniques of a malicious person or some sort of threat actor
[40:14.490 --> 40:21.230]  and they're going to try to get in and access sensitive data as quietly as possible without
[40:21.230 --> 40:29.350]  being detected, just like the bad guys. They're going to just look to avoid being detected.
[40:29.350 --> 40:37.110]  They're usually there for a longer period of time than other testers and they use a variety
[40:37.110 --> 40:44.510]  of techniques. This could even include some physical testing to break in
[40:45.550 --> 40:55.510]  and to get access to things that they probably shouldn't have. The
[40:57.810 --> 41:05.270]  final note here is application security testing. At some hospitals, there will be some level of
[41:05.270 --> 41:11.350]  development and this would be the process of testing and analyzing and reporting on the
[41:11.350 --> 41:17.690]  security level or posture of a particular application. It's used a lot in web development,
[41:17.690 --> 41:28.470]  but also app development like for Apple applications. It's just an idea, a way to
[41:28.470 --> 41:33.950]  test and gauge the security strength of that application and then find areas that you can
[41:33.950 --> 41:44.410]  remediate. There are times when you're going to want to bring in outside help.
[41:45.110 --> 41:51.170]  You want to develop, especially if you're going to have an outside digital forensics incident
[41:51.170 --> 41:57.570]  response team, you're going to want to develop this relationship long before a crisis situation
[41:57.570 --> 42:05.150]  happens. So find out how many cases they work a year, how many of them are hospitals, get references
[42:05.150 --> 42:13.190]  or testimonials from past clients, find out what experience level their team is at, how many of them
[42:13.190 --> 42:18.650]  have worked in the health care industry, and find out if they can help with overall readiness
[42:19.190 --> 42:27.510]  and not just be there when things go wrong. Recently, Liz Waddell did a presentation called
[42:27.510 --> 42:34.730]  Help, We Need an Adult, Engaging an External IR Team that provides some great tips and you can
[42:34.730 --> 42:44.530]  find it online just googling the name. And here are, here's the beginning of the resources.
[42:47.370 --> 42:48.510]  There are
[42:52.490 --> 42:57.470]  CIS, so the CIS and NIST and then the open source
[42:58.170 --> 43:02.870]  testing manual as well as links to many articles and demos.
[43:04.750 --> 43:13.690]  And that is the end of our basic network security section. Moving on to the next section. So
[43:14.910 --> 43:22.290]  a question that comes up pretty often is how do you monitor all the devices you have in a network?
[43:22.970 --> 43:32.810]  And this is going to start with really seeing what you have and then figuring out how to
[43:32.810 --> 43:39.230]  capture that data and monitor what's going on. Obviously, we don't have the resources
[43:40.170 --> 43:47.690]  to go and look at every device, so you need to have a smart approach to this.
[43:49.150 --> 43:55.610]  We're going to touch on network discovery, logging, and setting up a strategy for
[43:57.910 --> 44:02.390]  asset management and real-time monitoring.
[44:04.550 --> 44:09.970]  So as I mentioned, before we get started, you're going to have to do some planning.
[44:11.110 --> 44:18.650]  Some of this is going to be with network discovery. You're going to want to perform a scan
[44:18.650 --> 44:25.090]  to get the lay of the land and probe a network for all connected devices.
[44:25.610 --> 44:30.890]  Institutions are going to need to be aware that certain brands of devices or certain
[44:31.770 --> 44:37.750]  device models do not like being scanned, and so you're going to want to avoid doing
[44:37.750 --> 44:43.190]  this kind of heavy network discovery while they're in use. Or you're going to want to
[44:43.190 --> 44:49.650]  have that dialogue with your medical device manufacturer to see if you have some of those
[44:49.650 --> 44:56.370]  devices, and then perhaps take the device offline or create a strategy for managing
[44:56.370 --> 45:03.370]  that device while you're discovering everything else on your network. Ultimately, you cannot
[45:04.130 --> 45:12.050]  protect what you if you don't know it exists. And one strategy is to log as much as possible,
[45:12.050 --> 45:18.870]  get as detailed lay of the land as possible, and then if you find a new device that isn't
[45:18.870 --> 45:26.330]  in your inventory, you're going to treat it as hostile. So you're really going to
[45:26.330 --> 45:33.890]  want to be as thorough with discovery as possible. And in this network discovery,
[45:33.890 --> 45:40.890]  you're going to find some items that are immediately glaring. They're going to be
[45:40.890 --> 45:47.370]  operating systems or firmwares out of date. You're going to find just some simple vulnerabilities
[45:47.370 --> 45:53.930]  that come up, and you can remediate them along the way as you're doing your asset inventory.
[45:54.370 --> 46:00.610]  You're going to have to decide what's important to the organization early on,
[46:00.610 --> 46:08.950]  because you can't keep a log of everything. Long-term storage is expensive for this kind
[46:08.950 --> 46:14.830]  of monitoring. So you're going to have to prioritize what data you want to keep a track
[46:14.830 --> 46:27.650]  of the most. You're going to want to structure your log data. You're going to have some
[46:27.650 --> 46:37.290]  normalization across logs. There's a common information model that was created to solve this,
[46:37.290 --> 46:45.390]  and a community, an open source community, that also provides some information on this,
[46:45.390 --> 46:50.550]  and I have a link to that in my resources. If you're unsure of where to start, or you
[46:50.550 --> 46:57.230]  want some structured guidance, there are many different SIEM vendors, and so you can reach out
[46:57.230 --> 47:02.690]  to them and see about writing rules that support your organization devices in these cases.
[47:04.250 --> 47:09.890]  Don't feel pressured by these salespeople. Make sure you're in control of your conversation.
[47:13.740 --> 47:17.660]  You're going to want to separate and centralize your log data.
[47:20.480 --> 47:28.180]  Decide what you need from the logs and what you can discard. Logs are similar... logs are similar to
[47:30.700 --> 47:36.420]  finding the log data that's important to you. So security logs, system logs, intrusion attempts,
[47:36.420 --> 47:40.960]  connections, figure out what matters to you, and those are the logs you're going to need
[47:41.620 --> 47:48.980]  to keep. Separate logs come in handy for searching and dashboards, so you can organize your data in
[47:49.080 --> 47:54.080]  a way that's intuitive to you. If devices are Windows, you may be able to use the window event
[47:54.080 --> 48:02.140]  forwarding to push to the syslog. If you're using the Linux environment, use existing syslog.
[48:02.140 --> 48:09.940]  If you're pushing to a SIEM, there's lots of options, so Splunk, Security Onion, AlienVault,
[48:10.500 --> 48:19.340]  etc. There's paid versions, non-paid versions, obviously the open source ones are an increased
[48:19.340 --> 48:29.060]  level of effort, but everything is going to need fine-tuning. That is the nature of logging. So
[48:31.780 --> 48:36.440]  you're going to log devices to ensure communication to only trusted endpoints,
[48:36.440 --> 48:45.030]  log IPs and connections in and out of network, log an alert of large data transfers,
[48:45.740 --> 48:52.880]  you're going to want to log local devices and workstations for USB devices that are plugged in,
[48:52.880 --> 49:02.000]  you're going to want to log application setups to what's running on startup,
[49:02.000 --> 49:07.620]  you're going to want to search for malicious applications or malicious services,
[49:08.900 --> 49:17.740]  there are different options for inventory based on your operating system,
[49:17.740 --> 49:24.180]  you have a lot of variety in this space, use whatever works best for your workflow.
[49:25.120 --> 49:30.720]  You're going to want to correlate data sources. So you're going to use existing logs and security
[49:30.720 --> 49:37.280]  system events combined with local host logs to detect anything that's out of the normal,
[49:37.280 --> 49:43.200]  out of normal and flag it as a malicious activity. For this, you're going to need to establish a
[49:43.200 --> 49:48.440]  baseline. You're going to have to have a period of time where you are figuring out what is normal
[49:48.440 --> 49:55.140]  in your environment. And once you know what normal is, you can start to define what abnormal looks
[49:55.140 --> 50:03.260]  like. Your correlation only works if your logs have been normalized. So you're going to want to
[50:03.260 --> 50:11.180]  use identifiers that work for you as an organization, be consistent, whatever is intuitive
[50:11.180 --> 50:18.920]  for your group, proceduralize that and make it standard. So you, for example, if the core group
[50:18.920 --> 50:27.260]  in New York file server one, if you want to abbreviate just taking the first letter of
[50:27.260 --> 50:34.640]  every major word, if that works for you, do it. Do whatever works for you. You can say MRI,
[50:37.840 --> 50:46.960]  diagnostic services, left wing, whatever works for you, figure it out and then make it canon.
[50:46.960 --> 50:52.950]  You want to label your equipment, include warnings or pertinent information,
[50:53.200 --> 51:00.780]  and you want to also log MAC addresses, model numbers, serial numbers, licensing keys,
[51:00.780 --> 51:06.040]  anything that is important, especially if something goes wrong.
[51:08.230 --> 51:15.590]  So you use those unique identifiers when logging so that you can easily identify
[51:15.590 --> 51:22.250]  in your dashboard what is going on. Utilize scripting to run searches on interesting data,
[51:22.250 --> 51:27.670]  send this to email for the process. You're not going to want to do this by hand, use a dashboard.
[51:28.850 --> 51:35.910]  Perform real-time monitoring. Again, you're not going to want to do this all by hand,
[51:35.910 --> 51:41.510]  you're going to want to have some dashboard, deploy automation when possible,
[51:41.510 --> 51:48.290]  and work with your vendor if you can. If you're using a free version,
[51:48.290 --> 51:52.350]  those are often supported by robust communities and reach out to the community.
[51:53.390 --> 52:00.350]  So things are complex to set up and administer, and I understand. Small teams have limited cycles,
[52:00.350 --> 52:08.610]  I understand that as well. You're going to want to take your time to really fine-tune this to work
[52:08.610 --> 52:14.870]  for your particular infrastructure. And utilize a SIEM, it'll tie together all the information
[52:15.350 --> 52:25.610]  and make network monitoring easy for your staff. So assets, bad guys, and the things we can't see
[52:26.090 --> 52:33.350]  are really where we have high risk. With no logging, no asset inventory, and no central
[52:33.350 --> 52:41.750]  logging server, no SIEM to tie everything else, you're really dealing with an issue of the lack
[52:41.750 --> 52:49.270]  of visibility. This is where that strategy helps, where we're tying all of that information to make
[52:49.530 --> 52:59.870]  a map of what you have as a network, and it's the first step in figuring out where your risk is.
[53:00.630 --> 53:08.230]  So here is a fun little map. Next we're going to talk about developing a patch strategy.
[53:08.830 --> 53:15.830]  So now we're moving on to my last topic, and then we'll close out with Matt on his final two topics.
[53:15.830 --> 53:26.790]  My last topic of the day is medical device patching. This is a complex topic, but we start
[53:27.230 --> 53:34.470]  with, like everything else, with a strategy. Why have a patch management strategy? It avoids
[53:34.470 --> 53:39.890]  downtime and response efforts, it increases compliance, there's high return on investment
[53:39.890 --> 53:46.770]  for the effort, and ultimately increases the security posture of your organization.
[53:48.330 --> 53:55.210]  There's also some FDA guidance you might want to look up on the topics. Security updates are
[53:55.210 --> 54:03.750]  managed by the manufacturer's quality system, but they have made it easier to go ahead and push out
[54:03.750 --> 54:11.910]  to the customer. What is part of this process? There will be hazard analysis, formal testing,
[54:11.910 --> 54:18.010]  and then it'll be released. Why are patches generated? Well, sometimes it's because there's
[54:18.010 --> 54:25.950]  an uncontrolled risk that has an unacceptable risk to either clinical functionality or patient
[54:25.950 --> 54:33.330]  safety, sometimes it's just maintenance or part of good cyber hygiene, and sometimes it's that a
[54:33.330 --> 54:43.190]  third-party component requires a patch. There's a lot of challenges, one of them being the variety.
[54:43.650 --> 54:49.710]  There are hundreds of possible options for operating systems, and then when you add in
[54:49.710 --> 54:59.070]  the hardware and software components, there's a lot of variety in that install base.
[54:59.830 --> 55:06.050]  The hospital network has some complexity and risks. You have a lot of vendors, you know, we like to
[55:06.050 --> 55:14.590]  you only use us, but that's just not the case. There is a number of vendors, there's a number
[55:14.590 --> 55:22.370]  of platforms for remote access, and some devices do not have remote access available at all.
[55:22.770 --> 55:28.150]  Then there's the availability of a third-party patch. Just because a third-party component has
[55:28.310 --> 55:34.630]  a risk does not always mean that they will get us the patch in the time we manage to provide it to
[55:34.630 --> 55:40.690]  you. And then there's dependencies on the back end, servers and the like. There's organizational
[55:40.690 --> 55:47.970]  issues, so who does this device belong to? Does IT have a good relationship with the clinical team?
[55:47.990 --> 55:55.470]  I mean, in smaller places, the bioengineering guy and the IT guy and the IS guy are probably
[55:55.470 --> 56:03.710]  all the same person, but it depends on how that person deals with the clinical staff.
[56:03.710 --> 56:09.150]  And then what are the functionality risks? There's also regulatory and compliance concerns,
[56:09.150 --> 56:16.970]  what the change management process is. Devices are in use 24 hours a day, seven days a week.
[56:17.110 --> 56:21.150]  Device systems, like I mentioned earlier, they have dependencies.
[56:22.290 --> 56:26.810]  Hospitals are typically not allowed to install operating system patches directly.
[56:27.190 --> 56:33.690]  This is becoming less of a problem as more software-only solutions are created.
[56:33.710 --> 56:38.330]  But it is still a problem, especially in your legacy devices and install base.
[56:38.410 --> 56:44.030]  And what is impacted if things go wrong? Patient safety, care, delivery, and you have a reduced
[56:44.030 --> 56:54.550]  revenue. If you have to divert patients, if you have to delay diagnosis, you're going to have
[56:54.830 --> 57:05.890]  a reduced income. More complexities. The diversity of the medical device manufacturer,
[57:05.890 --> 57:11.750]  service level agreements, larger healthcare organization deliveries typically rely on
[57:11.750 --> 57:17.610]  automated patch management systems to coordinate the distribution and installation of patches.
[57:18.410 --> 57:24.490]  These agents for these programs or security agents are not generally approved for use by
[57:24.490 --> 57:29.670]  medical device manufacturers. Automated systems might accidentally push a patch to a non-approved
[57:29.670 --> 57:38.590]  device and that patch might bring that device offline or render it unreliable.
[57:38.730 --> 57:44.480]  HDOs have a difficulty for monitoring for and assessing the impact of vulnerabilities.
[57:45.080 --> 57:50.760]  If they may not know that vulnerability exists, they don't have a lot of visibility into what the
[57:50.760 --> 57:58.280]  third-party components are of that product. Many devices can only be patched when not in use or in
[57:58.280 --> 58:07.100]  service for patient care and patient safety reasons. And for this, I'm saying leverage your
[58:07.100 --> 58:13.220]  existing preventative maintenance cycles for certain devices. But when the device is in use
[58:13.220 --> 58:22.240]  24-7, that cycle might not come more quickly enough. We hear this a lot. There's a shared
[58:22.240 --> 58:29.300]  responsibility. Medical device manufacturers need to make a safe device or as safe as possible
[58:29.860 --> 58:40.240]  and give you the avenues to have safe settings, you know, control your access to your device,
[58:41.300 --> 58:49.080]  protect your data, respect privacy. They need to have robust security features. The device needs
[58:49.080 --> 58:55.300]  to be hardened and tested. We need to disclose vulnerabilities. We need to tell you what the
[58:55.300 --> 59:02.280]  third-party software is in the device and we need to provide patches in a timely manner. Hospitals
[59:02.280 --> 59:09.140]  need to deploy devices in a secure environment, which includes segregation. They need to monitor
[59:09.140 --> 59:16.220]  their network. They need to have an access management slash traffic control system.
[59:16.280 --> 59:21.500]  So that could be like physical security vulnerability analysis. They need to do
[59:21.500 --> 59:25.960]  security awareness training. We don't touch on security awareness training in this topic,
[59:25.960 --> 59:34.460]  but it is important. And you want to teach proper use. You want to have a life cycle and change
[59:34.460 --> 59:40.020]  management policy that includes patching and you're going to want to assess your risk.
[59:42.200 --> 59:49.440]  So as you may or may not tell by now, I'm pretty keen on processes. Asset management
[59:50.140 --> 59:56.900]  is an important part of many of the things I've mentioned, including patching.
[59:57.860 --> 01:00:03.160]  You're going to want to give each device a profile where you're saying
[01:00:04.460 --> 01:00:12.020]  you're triaging by exposure, likelihood, and impact in your risk profile. So do you have
[01:00:12.820 --> 01:00:20.760]  a flat network and a device that has a lot of ports open and not a lot of security controls
[01:00:20.760 --> 01:00:26.360]  in place for that device? Your network exposure risk is high. And then you go, you said, yeah,
[01:00:26.360 --> 01:00:32.360]  okay, that's high, but it doesn't actually store any PHI. It just may have a couple of
[01:00:32.920 --> 01:00:39.480]  values that are anonymized. Okay, well, then your data exposure is low.
[01:00:39.620 --> 01:00:45.440]  Patient safety and clinical care risk, does this directly affect a decision in patient care?
[01:00:45.440 --> 01:00:53.340]  Or is it an A1C that may be a factor in a diagnosis or a fasting glucose that may not be
[01:00:56.500 --> 01:01:01.960]  directly impacting a clinical care decision in an emergent moment?
[01:01:05.610 --> 01:01:12.030]  So how do you create this profile? If it's networked, you can, as we mentioned earlier,
[01:01:12.030 --> 01:01:18.550]  with the discovery portion, you can collect a hostname, MAC address, IP address,
[01:01:18.550 --> 01:01:26.310]  wireless interfaces. You may also want to note serial number. Oftentimes that is an identifier
[01:01:26.310 --> 01:01:35.110]  used by service. So when there is a problem, they may use, there's a vulnerability that impacts
[01:01:35.110 --> 01:01:42.450]  serial numbers one through 10, or ending in one through 10, and all others are fine.
[01:01:42.450 --> 01:01:49.650]  Or we're rolling out a patch to these serial numbers. So you would like to note that information
[01:01:49.650 --> 01:01:52.810]  or communication with your device manufacturer.
[01:01:54.690 --> 01:01:59.710]  You're going to want to create this, part of creating this medical device security profile
[01:02:00.530 --> 01:02:06.990]  is the software bill of materials and your security white paper. So many, many manufacturers
[01:02:06.990 --> 01:02:14.510]  are now in the process of collecting this information. As you can tell, the software
[01:02:14.510 --> 01:02:22.610]  bill of materials is important for a variety of reasons. It's involved in vulnerability analysis,
[01:02:22.610 --> 01:02:30.610]  in your privacy concerns, in pretty much everything. The white paper should also tell you
[01:02:31.110 --> 01:02:36.530]  what your operating system is and patch level and update. They're just going to let you know
[01:02:36.530 --> 01:02:40.850]  if there's any middleware, any dependencies, there's often network flow diagrams. You can
[01:02:40.850 --> 01:02:50.250]  get an idea with the documentation that your vendors provide of what your risk is.
[01:02:54.400 --> 01:02:58.320]  So when you're creating your medical device security profile, you're going to want to
[01:02:58.320 --> 01:03:03.280]  take a look at the controls. What are the credential management options? Is there
[01:03:04.520 --> 01:03:11.220]  antivirus or other security technology available with the encrypt? You're going to ask what
[01:03:11.220 --> 01:03:15.800]  logging capabilities they have and how do they manage remote access? You're going to want to
[01:03:15.800 --> 01:03:22.540]  keep a copy of the MDS2 security and security white paper for every version of the device
[01:03:22.540 --> 01:03:29.380]  that you have in use in your environment. There is enough variety at significant releases that
[01:03:29.380 --> 01:03:37.940]  you will need this data. Make it part of your profile. So as I was mentioning, the network
[01:03:37.940 --> 01:03:44.620]  exposure. Is the device in an internet accessible network zone? Does this have
[01:03:44.620 --> 01:03:52.080]  dial home capabilities? Is it remote accessible? These all increase your network exposure risk.
[01:03:54.290 --> 01:04:02.830]  Data exposure. Does the device store PHI or PII? Is the sensitive data only stored
[01:04:02.830 --> 01:04:09.130]  for a small period of time or is it permanent? How many records are stored? How is it stored?
[01:04:09.690 --> 01:04:16.050]  These are all questions you're going to want to ask your MDM. They are your partners in this.
[01:04:18.460 --> 01:04:26.420]  You are also going to need to figure out how critical is this device to care? Is it life
[01:04:26.420 --> 01:04:33.920]  sustaining? Does this represent a single point of failure? Has the security evaluation been performed?
[01:04:33.920 --> 01:04:38.700]  You're allowed to ask your medical device manufacturer, hey, what security testing has
[01:04:38.700 --> 01:04:47.040]  been performed on this device? What did you do about it? And especially if this is critical to
[01:04:47.040 --> 01:04:57.570]  care, you might want to have those conversations. You're going to need to plan your patch execution
[01:04:57.570 --> 01:05:06.970]  safely. So if you can, if you have a test device, you're going to want to, one, receive your
[01:05:07.670 --> 01:05:14.890]  manufacturer's approval. Test it on a device that's not in use at all. Verify that it does
[01:05:14.890 --> 01:05:21.970]  not in any way impact your workflow, just so that we know it works in your environment.
[01:05:22.370 --> 01:05:27.390]  Schedule a patch during a maintenance cycle, so a time that the device will be down anyways.
[01:05:27.690 --> 01:05:34.930]  Use your device in use safeguards that are in your manual. Deploy and apply the patch and validate
[01:05:34.930 --> 01:05:45.190]  that the device is ready to return to service. So you're going to want to make sure that this is an
[01:05:45.190 --> 01:05:52.730]  approved patch. If you want to, for some reason, apply a patch that did not come from your
[01:05:52.730 --> 01:05:57.250]  manufacturer, you need to reach out to your manufacturer and have that conversation.
[01:05:57.670 --> 01:06:03.630]  See what your service level agreement says. Manufacturers do have a list of approved patches,
[01:06:04.330 --> 01:06:08.910]  so get that documentation from them and make sure you're up to date.
[01:06:09.030 --> 01:06:15.690]  Ensure that the patch management system can isolate authorized patches and employ,
[01:06:15.690 --> 01:06:20.750]  ensure that only your authorized and approved patches are deployed on the device.
[01:06:25.050 --> 01:06:31.010]  Here's some considerations. You're going to want to see what your change management policy says.
[01:06:31.210 --> 01:06:36.350]  Schedule the patch during the prevent and maintenance cycle. I can't stress that enough.
[01:06:36.350 --> 01:06:44.550]  Please do not use a device that's in use. Should, by any accident that happens,
[01:06:44.550 --> 01:06:50.070]  you know, you don't want to take a device offline that a patient is using.
[01:06:50.850 --> 01:06:58.390]  When impossible, employ device in use safeguards. The two-man rule. So, hey, I'm going to patch this
[01:06:58.390 --> 01:07:05.070]  MRI machine. Can you see it? Can you verify that this is actually empty and not in use?
[01:07:05.070 --> 01:07:10.310]  Because we have it on the schedule that it's not in use today. Yes, I'm looking at it,
[01:07:10.310 --> 01:07:15.890]  there's nobody in it, and there's no plan to use it today. You're going to want to isolate the
[01:07:15.890 --> 01:07:23.490]  medical device on a maintenance VLAN and then deploy. When everything is back up and running,
[01:07:23.490 --> 01:07:30.850]  return it to service. So, that is our patch planning. I know it's a little more involved
[01:07:30.850 --> 01:07:39.750]  than your automated patch deployment that you can do with your workstations and servers,
[01:07:39.750 --> 01:07:46.670]  but because these devices are so important to clinical workflow, we need to put in this effort.
[01:07:47.710 --> 01:07:54.450]  Next up is Matt, and he has the fun topic of physical security.
[01:07:54.670 --> 01:08:00.530]  So, thank you, Helen, for that great overview on a number of topics. We only have two more modules
[01:08:00.530 --> 01:08:06.310]  left that should be pretty quick. We have physical security, and then we're going to cover third-party
[01:08:06.310 --> 01:08:12.190]  risk assessments and communication. So, we'll jump right into physical security. So, why is
[01:08:12.190 --> 01:08:18.270]  physical security in healthcare important? Well, if we're trying to protect PHI, you know, physical
[01:08:18.270 --> 01:08:23.990]  security is certainly one thing that we definitely want to consider. If you can't block physical
[01:08:23.990 --> 01:08:29.830]  access to the hospital, individuals can come in and potentially get access to data either on a
[01:08:29.830 --> 01:08:39.090]  device or something of that nature. So, we'll quickly look a little bit at hospital physical
[01:08:39.090 --> 01:08:45.950]  security studies that have been done and kind of understand, again, try to lay that foundation of
[01:08:46.270 --> 01:08:53.650]  what the current threat landscape is. So, of a survey that was done in 2018 for physical security
[01:08:53.650 --> 01:08:59.810]  in hospitals, 34% of hospitals did report some incidents of trespassing that year. That was up
[01:08:59.810 --> 01:09:06.930]  from two years prior. And only 42% of hospitals did report having a visitor management system.
[01:09:06.930 --> 01:09:11.330]  Now, when I say a visitor management system, what the study defined as a visitor management system
[01:09:11.330 --> 01:09:19.630]  did require a visitor to both sign in, have a photo ID, and a visible badge while walking around.
[01:09:19.630 --> 01:09:25.770]  So, if a hospital had two of those but not three, they didn't technically meet the criteria for
[01:09:25.770 --> 01:09:31.290]  visitor management systems. So, that 42% is of the reporting hospitals that had all three.
[01:09:31.410 --> 01:09:38.190]  And 20% of hospitals actually had some sort of physical man-trap that stopped individuals from
[01:09:38.190 --> 01:09:45.210]  coming in physically before entering the rest of the hospital. So, what do we want to restrict?
[01:09:45.210 --> 01:09:48.630]  Obviously, physical access. We're talking about physical access to hospital.
[01:09:49.090 --> 01:09:53.290]  But again, if we go back to that first slide deck that we had, we're not just talking about
[01:09:53.770 --> 01:09:57.250]  visitors, but we also want to consider staff. You know, is there certain areas
[01:09:57.250 --> 01:10:02.950]  that staff don't need to be in, or do we just give them access kind of carte blanche to
[01:10:02.950 --> 01:10:08.470]  all areas of the hospital? So, we certainly want to consider that. And, you know, definitely
[01:10:08.470 --> 01:10:14.930]  remember that 58% of healthcare data breaches do involve insiders, both malicious and unintentional.
[01:10:14.930 --> 01:10:18.610]  Certainly, don't forget about your own staff when we're considering these.
[01:10:20.110 --> 01:10:24.650]  Physical security plan evolution. So, obviously, your physical security plan for your hospital
[01:10:24.650 --> 01:10:34.750]  wants to evolve, not just with big events like we saw after 9-11, where a number of new doors and
[01:10:34.750 --> 01:10:41.730]  walls and things like that certainly were installed to restrict certain areas. But, you know, we
[01:10:41.730 --> 01:10:45.670]  want it to continuously evolve as the threat landscape evolves.
[01:10:47.010 --> 01:10:54.010]  This was a great study. This was by Marlee McKee. Not really a study, but Marlee McKee.
[01:10:54.010 --> 01:10:59.990]  She has, interestingly enough, a couple million followers, and she is self-identified as
[01:10:59.990 --> 01:11:05.110]  America's modern manners and etiquette expert. And she claims that opening the door at work
[01:11:05.110 --> 01:11:11.710]  was her number two for America's top five manners. So, these are things that people should do.
[01:11:12.210 --> 01:11:18.390]  Obviously, those of us that work in security realize that this is really not good. But it is,
[01:11:18.390 --> 01:11:24.290]  you know, prevalent. Door holding, at least in a number of cultures, is prevalent. So, we need to
[01:11:24.290 --> 01:11:30.110]  kind of look at that and factor that into our physical security plans. This was a study that
[01:11:30.110 --> 01:11:36.230]  was done by the University of Omaha. It was fairly interesting. There was about 1,500 students that
[01:11:36.230 --> 01:11:42.850]  were assessed to see if they would basically hold the door if someone walked up behind them.
[01:11:42.910 --> 01:11:46.630]  Two-thirds of the individuals, if there was someone that immediately tailgated them as
[01:11:46.630 --> 01:11:51.870]  they were coming in the door, they would open the door and leave it open. There really wasn't any
[01:11:51.870 --> 01:11:59.130]  gender difference for that category, but it was interesting that the latter two,
[01:11:59.130 --> 01:12:09.230]  significant gender difference. Females reported seriously significantly lower for both glancing
[01:12:09.230 --> 01:12:13.130]  back and seeing if someone was coming and standing there and holding the door and then holding the
[01:12:13.130 --> 01:12:19.310]  door open for a significant amount of time. So, didn't really go into why there was that
[01:12:19.310 --> 01:12:26.190]  difference with genders. But, you know, if you're incorporating this into your incorporating door
[01:12:26.190 --> 01:12:29.750]  holding into your physical security plan, it might be something that you might want to look
[01:12:29.750 --> 01:12:34.150]  at that study and dive a little bit deeper into. Maybe those gender differences are something that
[01:12:34.150 --> 01:12:40.150]  you could leverage to make your facility more secure, if you can understand kind of why that's
[01:12:40.150 --> 01:12:46.590]  happening. We're certainly not going to reinvent the wheel. This is a, you know, less than a two
[01:12:46.590 --> 01:12:55.570]  hour training. So, if you want to see some great physical security training, I definitely recommend
[01:12:55.570 --> 01:13:00.390]  Jason Street's DEF CON talk on physical security. It goes over a number of different physical
[01:13:00.390 --> 01:13:05.690]  security penetration tests that he's done and how easy it is to gain access. So, you know, again,
[01:13:05.690 --> 01:13:10.870]  this is just this is the very short abbreviated version that's specific to hospitals. So,
[01:13:10.870 --> 01:13:18.050]  if you want more, I would definitely look at that. So, why is any of this important? Physical
[01:13:18.050 --> 01:13:23.690]  security or at a, you know, cyber security or hacking conference? Why is physical security
[01:13:23.690 --> 01:13:30.150]  important? Well, manufacturers, so medical device manufacturers, make certain assumptions when they
[01:13:30.150 --> 01:13:34.600]  create a medical device. They assume, as Helen was talking in some of her past presentations,
[01:13:34.990 --> 01:13:40.370]  that they assume that a device is going into a secure environment. And that's not always the
[01:13:40.370 --> 01:13:46.370]  case. It's certainly going to vary. If it's maybe a large, you know, CT device that they might make
[01:13:46.370 --> 01:13:51.370]  assumptions that that's going to be in a secure facility or maybe in a secure laboratory, certain
[01:13:51.370 --> 01:13:56.770]  devices. But, you know, it is understood there's certain smaller, like, point of care devices that
[01:13:56.770 --> 01:14:01.910]  can be physically picked up and carried around or, you know, might be in a ER setting or even
[01:14:01.910 --> 01:14:05.750]  in a home setting are obviously gonna have less physical security. But you just want to kind of
[01:14:05.750 --> 01:14:12.370]  be aware of what physical security assumptions, you know, your medical device manufacturers are
[01:14:14.010 --> 01:14:20.750]  assuming. Yeah. So, testing those assumptions. While I was creating this training, I had the
[01:14:20.750 --> 01:14:25.970]  unfortunate but fruitful experience of having an individual that was close to me
[01:14:26.590 --> 01:14:33.630]  be admitted to a hospital. They were first admitted to a local, like, 25-bed critical
[01:14:33.630 --> 01:14:40.830]  access hospital, regional hospital, then moved to a larger university hospital, and then in a number
[01:14:40.830 --> 01:14:47.710]  of, like, physical rehab facilities. So I was able to kind of, you know, visit regularly and observe
[01:14:47.710 --> 01:14:52.970]  different situations that were happening with kind of the eye of being a, you know,
[01:14:52.970 --> 01:14:58.310]  an occasional medical device penetration tester. So I've never done actual hospital penetration
[01:14:58.310 --> 01:15:02.550]  testing, though I have some colleagues that have, and I've included some of their insights,
[01:15:02.550 --> 01:15:09.370]  but this is kind of what I've noticed. So the hospitals that I did visit, they did not check my
[01:15:09.370 --> 01:15:14.530]  ID, which was interesting because I could have very easily just provided a name of any patient
[01:15:14.530 --> 01:15:20.990]  that was in the hospital at the time and be given access. And I actually tested this out,
[01:15:20.990 --> 01:15:25.810]  it's kind of an interesting OSINT experiment, but if you go to Facebook and just kind of do a search
[01:15:25.810 --> 01:15:30.630]  for, you know, hospital, in probably 30 minutes or less, you're going to be able to find a name of
[01:15:31.090 --> 01:15:36.990]  a patient, you know, whether it's a friend, distant colleague, whatever, that's currently,
[01:15:36.990 --> 01:15:41.230]  you know, in a hospital, maybe social media posts that says, you know, this could be Facebook or
[01:15:41.230 --> 01:15:46.490]  any social media post, hey, I had a spill, I'm in a hospital, this is a hospital, come visit me.
[01:15:46.750 --> 01:15:50.910]  We now know that individual's in that hospital, and a good number of hospitals, you can simply go
[01:15:50.910 --> 01:15:55.270]  there, provide their name, maybe provide a fake name, because they're not actually checking your
[01:15:55.270 --> 01:16:04.230]  ID, and be given physical access to the hospital. Once you're inside, at least I found in the
[01:16:04.230 --> 01:16:09.450]  hospitals that I was in, I pretty much had access to go anywhere in the hospital, which with some
[01:16:09.450 --> 01:16:14.790]  restrictions, and there were signs that basically told me kind of wherever I wanted to go. So,
[01:16:14.790 --> 01:16:18.850]  if I was a, you know, nefarious actor, and I wanted to get access to the server room,
[01:16:18.850 --> 01:16:23.490]  it clearly showed on the map exactly where that was, and it said on the door, you know,
[01:16:23.490 --> 01:16:32.270]  exactly where that was. Yeah, keep going. I was going to mention one more thing, but I'll
[01:16:32.270 --> 01:16:37.530]  mention it at the end. At the patient's bedside, there was obviously anyone that's ever visited
[01:16:37.530 --> 01:16:42.750]  someone in a hospital, you know, especially if it's a critical case, you know, that patient is
[01:16:42.750 --> 01:16:47.750]  surrounded by a number of different medical devices. Many of those devices, such as a cow
[01:16:47.750 --> 01:16:53.270]  or computer on wheels, which is where the nurse or the clinical staff would sit down and do their
[01:16:53.270 --> 01:16:58.150]  documentation. So, they would do their vital signs, ask the patient all their questions, then go to
[01:16:58.150 --> 01:17:04.750]  this computer to write notes. Typically, for what I've seen, most of these were not locked down,
[01:17:04.750 --> 01:17:10.510]  at least in the hospital that I was in, and I've installed medical software in a previous role,
[01:17:10.510 --> 01:17:15.230]  and that's certainly not the case. A number of hospitals do lock down all their computer on
[01:17:15.650 --> 01:17:21.410]  cows, computer on wheels, and have a certain timeout to be able to lock that out of, you know,
[01:17:21.410 --> 01:17:27.050]  inactivity. But in this case, you know, the devices were open. That's not a picture of a device,
[01:17:27.050 --> 01:17:33.270]  that's just one that I took off the web. And there was a number of other medical devices at the
[01:17:33.270 --> 01:17:40.370]  bedside that, you know, had USB ports that, you know, if you look at the device and Google it,
[01:17:40.750 --> 01:17:45.830]  you can probably identify that it doesn't restrict any type of traffic. So, if you had a rubber
[01:17:45.830 --> 01:17:50.270]  ducky, things like that, you know, I might be able to either extract data out of the device or
[01:17:50.270 --> 01:17:55.310]  potentially run a script on it. So, there's a lot of things you can do once you get physical access
[01:17:55.810 --> 01:17:59.990]  that, you know, we often think, well, if someone's in the hospital, they're hurt, they need to be
[01:17:59.990 --> 01:18:05.670]  there. But, you know, nefarious people get hurt too and end up in hospitals or visit family members
[01:18:05.670 --> 01:18:11.870]  or friends that are in hospitals. So, it's kind of something to consider. One thing that I found
[01:18:11.870 --> 01:18:19.750]  interesting, so, like I said, I've done some, like, a very small amount of penetration testing
[01:18:19.750 --> 01:18:25.350]  for medical devices, but I have a colleague that does actual hospital penetration tests.
[01:18:25.410 --> 01:18:29.170]  And he says that, you know, with a mop and a bucket, there's essentially nowhere in the hospital
[01:18:29.170 --> 01:18:34.850]  that he can't go. Anytime he's done a physical penetration test or just a penetration test in
[01:18:34.850 --> 01:18:40.890]  general, you know, he always, this is what he does for every hospital he's gone into, he dresses up
[01:18:40.890 --> 01:18:46.170]  like a janitor and they generally give him access to anywhere he wants to go, including secure
[01:18:46.170 --> 01:18:51.970]  facilities or secure areas of the hospital. So, if you're looking to do physical penetration testing
[01:18:51.970 --> 01:18:55.910]  at a hospital, that's probably a good plan.
[01:18:57.850 --> 01:19:03.270]  So, health, there was a great talk a couple years ago at one of the Health ISAC summits
[01:19:03.810 --> 01:19:09.390]  that specifically looked at printers as kind of, you know, having a lot, basically being
[01:19:09.390 --> 01:19:14.390]  chock-full of PHI. So, they typically have a lot of records. You can do print last 10, you know,
[01:19:14.390 --> 01:19:18.210]  especially if this is a discharge printer where, you know, if you go to the hospital, you get
[01:19:18.210 --> 01:19:25.070]  discharged, you go sit in front of a nurse, she prints out your, you know, 15, 20, 50 page,
[01:19:25.070 --> 01:19:31.790]  whatever medical record, gives it to you, and then you go out the door. So, that printer is
[01:19:31.790 --> 01:19:36.910]  like chock-full of records. It's probably right next to an exit door, and it may or may not
[01:19:36.910 --> 01:19:42.330]  require authentication. So, just something to kind of think of. Printers often get overlooked,
[01:19:42.330 --> 01:19:47.370]  but it might have just as much, if not more, PHI than an actual medical device.
[01:19:48.890 --> 01:19:54.450]  Access in the waiting room. This was, you know, often we think of, okay, we have to actually get
[01:19:54.450 --> 01:19:58.670]  in the building to be able to find a network jack or to be able to get some sort of, you know, access
[01:19:58.670 --> 01:20:03.970]  that we need. But Helen, if she's still on the line, had a great story of one of her friends
[01:20:03.970 --> 01:20:11.670]  that was doing a penetration test for a hospital and found network access right from the
[01:20:11.670 --> 01:20:19.870]  lobby. I don't know if she's still on. I am. So, we met up before his test. This was his first,
[01:20:19.870 --> 01:20:26.290]  like, hospital test. And he goes, I imagine hospitals are like a fortress. Like, oh, no,
[01:20:26.290 --> 01:20:34.470]  dear. They are not. And he's like, no, no, you're kidding me. And I'm like, yeah, they're pretty
[01:20:34.470 --> 01:20:43.510]  bad. I would totally expect a flat network. So, he has a plan to say that he is, you know,
[01:20:43.510 --> 01:20:49.810]  waiting for a patient. And he doesn't even need it. Nobody asks him. So, he just sits down with
[01:20:49.810 --> 01:20:58.610]  his laptop. And there's a network connection there. And he's like, it can't be this easy.
[01:20:58.610 --> 01:21:07.350]  Sure enough, it was live. So, definitely interesting as far as the initial gaining of
[01:21:07.350 --> 01:21:17.050]  access. Emergency waiting rooms are full of people. And they aren't necessarily highly
[01:21:17.050 --> 01:21:20.410]  monitored as well as lobbies. Lobbies don't always have receptionists.
[01:21:21.150 --> 01:21:27.630]  Yeah. Great. Well, thank you for that story, Helen. So, what can be done about this? Obviously,
[01:21:27.630 --> 01:21:33.370]  it could require IDs for all visitors. So, when they're entering a facility, it requires some
[01:21:33.370 --> 01:21:37.890]  visible badge. And it could just be a sticker. It's certainly helpful if that visible badge
[01:21:37.890 --> 01:21:41.390]  actually says where they're going. So, that, you know, if they're in an area where they're
[01:21:41.390 --> 01:21:47.110]  not supposed to be, it's clearly visible. Restricting physical access to only areas that
[01:21:47.550 --> 01:21:51.430]  these individuals should be. I mean, I've certainly been lost a number of times in
[01:21:51.430 --> 01:21:55.670]  hospitals. Just, you know, you go in and then you just have access to everywhere.
[01:21:55.670 --> 01:22:01.310]  They're so big, you get lost. You know, if you could actually have individuals kind of
[01:22:01.310 --> 01:22:04.590]  guide people to where they're supposed to be going to. And in a large hospital,
[01:22:04.590 --> 01:22:09.070]  that's obviously never going to happen. It's just too large and there's too many visitors.
[01:22:09.330 --> 01:22:14.030]  But I have seen it work pretty well, again, in like a Midwest, like small critical access,
[01:22:14.030 --> 01:22:18.990]  25-bed hospital, where they have a number of volunteers where they're just, you know,
[01:22:18.990 --> 01:22:23.530]  looking for something to do and help out. And, you know, I've been surprised to show up at those
[01:22:23.530 --> 01:22:28.870]  hospitals to install software and, you know, had a person that actually brought me from the door
[01:22:28.870 --> 01:22:32.530]  to right where I needed to be. So if you're one of those small hospitals and you're looking for
[01:22:32.530 --> 01:22:37.450]  something for volunteers to do, that might be a good thing that they can do to, you know,
[01:22:37.450 --> 01:22:41.230]  be friendly with visitors, but also help increase your security posture.
[01:22:42.350 --> 01:22:46.350]  Train staff on tailgating. And again, leveraging those, you know, if you can leverage the
[01:22:46.350 --> 01:22:50.770]  differences and understand kind of why that's happening. You can lock all devices when they're
[01:22:50.770 --> 01:22:56.890]  not in use. Require authentication on printers is good. And, you know, when we're locking devices
[01:22:56.890 --> 01:23:02.870]  too, that's obviously, you know, that's going to be a process. You're probably looking at,
[01:23:02.870 --> 01:23:06.830]  like, hospitals that do it well are doing like a tap and go system. So you just, you know, I have
[01:23:06.830 --> 01:23:13.010]  my card on a lanyard and I'm just tapping it on each device that I have access to. And that's
[01:23:13.010 --> 01:23:17.390]  going to look different across your hospital. Certainly in the ER, there's a little bit more
[01:23:17.390 --> 01:23:21.850]  risk because you have, you know, people coming into the ER constantly. You're certainly a guest
[01:23:21.850 --> 01:23:29.810]  of people that are there or patients. But, you know, in an ER, like, seconds count. So it's
[01:23:30.250 --> 01:23:34.190]  understandable that there's going to be less restrictions in that setting where, you know,
[01:23:34.190 --> 01:23:38.390]  having to have a doctor stop and actually log into a system is certainly going to slow down
[01:23:38.390 --> 01:23:44.170]  and it could adversely affect patient outcomes. But, you know, if you can do like a tap and go
[01:23:44.170 --> 01:23:48.990]  system or something that is efficient, you know, anything you can lock down, certainly the better.
[01:23:49.470 --> 01:24:00.110]  But again, do it, you know, do it in a way that is useful. Again, going back to that application
[01:24:00.650 --> 01:24:06.290]  support staff that I was at a hospital, if, you know, you're not, if your staff's not getting
[01:24:06.290 --> 01:24:12.390]  paid over the weekend to be on call and they regularly get calls at 11 at night during shift
[01:24:12.390 --> 01:24:18.090]  change, you're basically incentivizing them to open access up more than it should be so that
[01:24:18.090 --> 01:24:25.130]  they don't get that call. So definitely try to avoid that. And, you know, either asking manufacturers
[01:24:25.130 --> 01:24:30.450]  to, you know, filter traffic. So doing that in your assessments on devices to see if that's an option
[01:24:30.450 --> 01:24:36.230]  or physically blocking a USB port, because certainly it wouldn't be the first infusion
[01:24:36.230 --> 01:24:41.790]  pump that was plugged into a patient that, you know, crashed when it was actually infusing
[01:24:41.790 --> 01:24:47.230]  something into a patient because someone plugged a USB, you know, whether it's something malicious
[01:24:47.230 --> 01:24:50.910]  or just a phone charger, certainly if it has a USB port, someone's going to eventually try
[01:24:50.910 --> 01:24:57.990]  to charge your phone with it. So just kind of be aware of that. Some other things just to kind of,
[01:24:57.990 --> 01:25:02.790]  you know, go with the win-win philosophy, you know, locking down access to a hospital not only
[01:25:02.790 --> 01:25:09.730]  protects PHI, but it also protects your employees and patients. You know, hospitals are places where
[01:25:09.730 --> 01:25:14.370]  injured people go. That's fairly obvious. But, you know, the reason that they're injured or sick
[01:25:14.370 --> 01:25:19.310]  might just be because they're sick, or it might be because they were in some violent altercation
[01:25:19.310 --> 01:25:24.130]  where, you know, the assailant is now, you know, going to come back to try to do the job,
[01:25:24.130 --> 01:25:31.590]  to finish the job. And we've seen an increase from 2017 in actual violence against, specifically
[01:25:31.590 --> 01:25:38.310]  against staff for in U.S. hospitals. It's up 57% in the emergency department and 52%
[01:25:39.310 --> 01:25:44.510]  increase outside of the ED. So certainly increasing physical security in your hospital,
[01:25:44.510 --> 01:25:51.030]  again, not only helps protect PHI, but also helps protect your staff and your patients.
[01:25:51.810 --> 01:25:57.870]  So thank you for that. And we have one last module coming up on vetting third parties and
[01:25:57.870 --> 01:26:03.410]  talking about communication. Alright, so thanks everyone for sticking with us for the previous
[01:26:03.410 --> 01:26:10.630]  five modules. This is our last module. And this is on third party communication and risk assessments.
[01:26:10.630 --> 01:26:15.230]  So this is all about how if you are a hospital, and you're wondering how you gather all the
[01:26:15.230 --> 01:26:19.670]  information that you need from a maybe a medical device manufacturer, a third party,
[01:26:19.670 --> 01:26:25.130]  and incorporate that into some risk calculation to make decisions, purchasing decisions based on
[01:26:25.130 --> 01:26:31.550]  or security decisions of, you know, what do I do for this device to secure down my network,
[01:26:31.550 --> 01:26:37.690]  this would be the module for you. So, you know, again, just to try to set some stats and some
[01:26:37.690 --> 01:26:43.030]  groundwork. If you're wondering how many hospitals are actually if you're a hospital that's maybe not
[01:26:43.030 --> 01:26:47.530]  doing these third party risk assessments, but you're wondering what percentage of them do.
[01:26:48.030 --> 01:26:52.230]  Back to the 2017 HIMSS study, and this is a little bit dated, so it's probably even
[01:26:52.230 --> 01:26:58.590]  more so now, but 88% of medical facilities are conducting cybersecurity risk assessments on
[01:26:58.590 --> 01:27:03.790]  third party products, so medical devices and other products. And 38% of medical facilities
[01:27:03.790 --> 01:27:07.950]  are pen testing equipment. So if you're a medical device manufacturer, and you're not pen testing
[01:27:07.950 --> 01:27:15.670]  your equipment, certainly be aware that your customers most likely are pen testing, or maybe
[01:27:15.670 --> 01:27:20.130]  at least going to ask you and inquire about if you know if you are pen testing.
[01:27:22.230 --> 01:27:30.790]  So the Ponemon study back in 2019, just looking at basically how much hospitals actually spend on
[01:27:30.790 --> 01:27:35.790]  this on risk management, and HDO or health delivery organization, just a kind of a big
[01:27:35.790 --> 01:27:42.370]  word for a large hospital organization, on average spends about $3.8 million a year
[01:27:42.370 --> 01:27:46.410]  on third party vendor risk management. And you know, why do they do that? Well,
[01:27:46.410 --> 01:27:50.990]  juxtapose that with the average cost of a data breach is about $2.9 million.
[01:27:52.230 --> 01:27:57.270]  And if you look at the just the vast number of vendors that HDOs have under contract,
[01:27:57.270 --> 01:28:02.650]  it's over 1300, which is just unfathomable that they're managing that.
[01:28:03.550 --> 01:28:09.130]  Why they tend to do a really good job assessing all of those third parties initially when they're
[01:28:09.130 --> 01:28:16.550]  first looking at them, less than 30% are actually annually reassessed. So, you know, it's a big lift
[01:28:16.550 --> 01:28:21.110]  and a good amount of work to get them assessed initially, but we're not really looking at them
[01:28:21.910 --> 01:28:26.690]  relooking at these technologies a year, two years, five years after they're in the door.
[01:28:28.730 --> 01:28:33.890]  So if there is a concern during this risk assessment process, you know, what happens?
[01:28:33.890 --> 01:28:38.490]  What do hospitals typically typically do? Well, again, looking at that same same study,
[01:28:38.490 --> 01:28:43.310]  about 21% of the time, the assessment gap leads to the manufacturer remediating it.
[01:28:43.330 --> 01:28:47.630]  So the customer says, Hey, we, we did a risk assessment, we found this, we're not gonna be
[01:28:47.630 --> 01:28:52.250]  able to purchase the product, unless something happens. 21% of the time, the manufacturer does
[01:28:52.250 --> 01:28:59.490]  something to fix that or address it. 33% of the time, the HDO, or health delivery organization
[01:28:59.490 --> 01:29:04.570]  mitigates the gap themselves. So it might be, you know, cordoning off that device on its own
[01:29:04.570 --> 01:29:12.590]  segments of the network, maybe a separate VLAN, or some other security, security technique to be
[01:29:12.590 --> 01:29:18.990]  able to reduce that risk. And 28% of the time, medical device manufacturers should be certainly
[01:29:18.990 --> 01:29:24.250]  aware of this. 28% of the time, HDOs just terminate the agreement and say this doesn't,
[01:29:24.250 --> 01:29:28.310]  this device does not meet our basic security requirements, so we cannot purchase it.
[01:29:28.310 --> 01:29:32.410]  So that is definitely happening in the hospital sector currently.
[01:29:33.430 --> 01:29:38.370]  Why are we doing this? What is the risk? About 20% of healthcare data breaches are caused by
[01:29:38.370 --> 01:29:44.030]  third-party vendors, either by, you know, the vendor or, you know, somehow associated to that
[01:29:44.030 --> 01:29:51.970]  vendor. What is the cost and labor? You know, again, this course kind of focuses on smaller
[01:29:51.970 --> 01:29:57.350]  hospitals, but those larger, bigger HDOs, health delivery organizations, how much time are they
[01:29:57.350 --> 01:30:05.690]  spending assessing this risk? Well, the average hospital or HDO has about 3.21, so that's
[01:30:05.690 --> 01:30:12.670]  obviously a percentage, but over three employees on average solely dedicated to just assessing
[01:30:12.670 --> 01:30:19.610]  third-party risk. And if you do the math on that, that's about 513 hours a month that HDOs are
[01:30:19.610 --> 01:30:24.310]  dedicating just specifically to looking at third-party risk of vendors that they're going to
[01:30:24.310 --> 01:30:31.930]  partner with or vendors that have devices that they're considering purchasing. So can you automate
[01:30:31.930 --> 01:30:36.870]  this process? Certainly you can. About a third of HDOs do use some sort of tool to automate this
[01:30:36.870 --> 01:30:43.290]  process. There's a number of tools on the right-hand side that you can see. Obviously, a pretty broad
[01:30:43.290 --> 01:30:48.890]  distribution. We're not going to vouch for any one, but, you know, if you have that question,
[01:30:48.890 --> 01:30:54.870]  maybe it's a good question for the panel afterwards for the HDOs to see what they're currently using.
[01:30:56.370 --> 01:31:00.550]  You know, if you're going to do this assessment, you should then have some baseline security
[01:31:00.550 --> 01:31:05.930]  standard that you're going to measure it against. The Mayo Clinic has what they call a gold standard.
[01:31:05.970 --> 01:31:10.570]  It's a list of 77 different requirements. Most of those requirements went into the new
[01:31:11.650 --> 01:31:21.670]  MDS2 or the new document that basically lays out security features that we'll talk about a little
[01:31:21.670 --> 01:31:28.790]  bit later. And Mayo has presented this at a number of different conferences, so you can probably find
[01:31:28.890 --> 01:31:36.770]  a little bit more information from searching that. And what that allows you to do, it allows
[01:31:36.770 --> 01:31:41.910]  you to... actually, some of the features, I should say, in that 77 where every device is easily
[01:31:41.910 --> 01:31:49.050]  patchable, every device receives timely updates, and, you know, certainly a number of other facets.
[01:31:49.230 --> 01:31:53.630]  And what this allows you to do is focus on the high-priority devices, so the devices that have a
[01:31:53.630 --> 01:31:59.670]  high risk score, a potential for high risk. And also what you want to look at, too, is assess the
[01:31:59.670 --> 01:32:05.210]  whole family of devices. If you're purchasing, say, five different point-of-care devices that are all
[01:32:05.210 --> 01:32:10.770]  different, and the risk may be low for each of those devices, but all of those devices, you know,
[01:32:10.770 --> 01:32:16.390]  send unencrypted traffic to a middleware application, you know, you want to look at that
[01:32:16.390 --> 01:32:22.030]  whole family of devices and not miss something, kind of understanding that, you know, the sum of
[01:32:22.030 --> 01:32:27.770]  all the parts and just looking at the devices individually. So communication, we'll talk a
[01:32:27.770 --> 01:32:33.590]  little bit about communication and how HDOs and their third parties actually communicate some of
[01:32:33.590 --> 01:32:38.530]  this information. So we talked about the MDS-2, which is short for Medical Disclosure Statement
[01:32:38.530 --> 01:32:45.290]  for Medical Device Security. This is a standard form when a medical device goes for FDA approval,
[01:32:45.290 --> 01:32:50.550]  510k approval, this is part of it. So if you ask, any medical device manufacturer should be able to
[01:32:50.550 --> 01:32:55.210]  give you an MDS-2 for their product, depending on when that product came out, it might be a
[01:32:55.210 --> 01:33:01.770]  different version. The latest version I was talking about that Mayo has their 77 requirements,
[01:33:01.770 --> 01:33:07.650]  most of them incorporated into, came out in 2019, I think it was November or December, so that's the
[01:33:07.650 --> 01:33:14.450]  latest update. So the MDS-2 is a good place to get information. Security white paper as well,
[01:33:14.450 --> 01:33:18.850]  a number of medical device manufacturers create security white papers that offer a lot more
[01:33:18.850 --> 01:33:25.610]  information above and beyond what's in the MDS-2. And some of that information, so you might have a
[01:33:25.610 --> 01:33:30.910]  full software bill of material, includes information like which ports and services are running,
[01:33:30.910 --> 01:33:36.220]  which ports are open and which services are running on the device, specifically what sensitive data
[01:33:37.590 --> 01:33:42.260]  elements are stored or transmitted on the device. Probably give you a network diagram of how the
[01:33:42.260 --> 01:33:48.920]  is meant to kind of live in your network, so you can see that. It'll talk about authentication,
[01:33:48.920 --> 01:33:54.320]  malware protection, security testing, if security testing has been completed, so if the device has
[01:33:54.320 --> 01:33:59.140]  gone through a rigorous secure development process, there should be notes on that.
[01:34:00.540 --> 01:34:04.980]  The intended operating environment is important, because that's, again, going back to those
[01:34:04.980 --> 01:34:09.680]  manufacturer assumptions, this is what the manufacturer assumes, or where the manufacturer
[01:34:09.680 --> 01:34:13.100]  assumes that the device is going to live in. So they assume that there's going to be network
[01:34:13.500 --> 01:34:19.660]  segmentation, and a firewall, and a number of other things. So it's good to certainly look at
[01:34:19.660 --> 01:34:23.360]  that, because that will, that will, you'll be able to see the recommendations of how you should
[01:34:23.360 --> 01:34:31.300]  secure this device, and network controls, physical controls, logging, how the manufacturer may
[01:34:31.300 --> 01:34:36.220]  remotely connect to the device for service, and whether you want that or not, you can turn it on
[01:34:36.220 --> 01:34:43.120]  or off, likely. Any administrative controls, how to contact both service, and then maybe the,
[01:34:43.120 --> 01:34:48.700]  for a cybersecurity issue, how to look for that too. If the device has any certifications, like
[01:34:48.700 --> 01:35:00.370]  ISO 27001, things like that. So how do HDOs acquire this information? It's pretty common.
[01:35:00.470 --> 01:35:05.950]  What they're largely doing is sending us security questionnaires, and most medical device
[01:35:05.950 --> 01:35:11.790]  manufacturers are receiving hundreds of these from U.S. customers each year. They're extremely
[01:35:11.790 --> 01:35:17.290]  lengthy, extremely detailed questions. If you are tasked with creating one of these, if you can,
[01:35:17.290 --> 01:35:24.130]  you know, try to create one in a good format that allows manufacturers to just kind of go through
[01:35:24.130 --> 01:35:29.370]  and check off, or uncheck things that aren't applicable. So if it's, you know, not a cloud
[01:35:29.370 --> 01:35:34.830]  product, you can click no, not a cloud product, and it automatically fills in NA to the next 150
[01:35:34.830 --> 01:35:39.690]  questions, and the manufacturer doesn't have to click NA and then put in a comment for each as
[01:35:39.690 --> 01:35:46.210]  to why it's not applicable, that would be great. Just some sample questions, you know, pretty
[01:35:46.210 --> 01:35:54.010]  standard, you know. How do you get this information? Again, I can only imagine on the HDO side if you
[01:35:54.010 --> 01:36:01.330]  have 1300 different, you know, third parties trying to, even if each manufacturer has their
[01:36:01.330 --> 01:36:06.690]  own information portal where all of the MDS-2s and security white papers and SBOMs are in that
[01:36:06.690 --> 01:36:12.210]  one centralized location, you still have to go to 1300 different portals to get that information.
[01:36:12.390 --> 01:36:19.010]  There's been some industry attempts to try to have all of that information centralized to one place,
[01:36:19.610 --> 01:36:26.210]  but those haven't, those have either faltered or have haven't really caught on. So maybe we'll get
[01:36:26.210 --> 01:36:31.970]  there eventually, but in the meantime, you can at least, for a good amount of manufacturers,
[01:36:31.970 --> 01:36:38.150]  go to one place and get all of the information that you need. You know, as I said, SBOM, MDS-2,
[01:36:38.150 --> 01:36:43.670]  white papers, installation guide, you know, any other information, hopefully in that one place
[01:36:43.670 --> 01:36:50.950]  to make it a little easier for you. Business Associate Agreement, or BAA, this came from the
[01:36:50.950 --> 01:36:57.650]  HIPAA Omnibus Rule. So this is, you know, basically the requirement or the agreement between
[01:36:57.650 --> 01:37:06.810]  the medical device manufacturer or third party that's handling secure data. So the third party
[01:37:06.810 --> 01:37:13.610]  agreement with the health delivery organization. One thing to kind of note of that is this last
[01:37:13.610 --> 01:37:19.730]  line, that if you are working with a third party that's offshore or outside of the U.S.,
[01:37:19.730 --> 01:37:26.870]  the Office of Civil Rights, or OCR, so the group that's tasked with enforcing this,
[01:37:27.690 --> 01:37:31.510]  probably doesn't have jurisdiction. So just kind of something to consider.
[01:37:32.790 --> 01:37:37.690]  And if you Google BAA example, there's a number of examples that you can see. You know,
[01:37:37.690 --> 01:37:43.750]  your legal department is probably going to create this, but just, you know, there are examples.
[01:37:44.610 --> 01:37:49.810]  ISA, so this would be more if you're actually handling the customer's data. So, you know,
[01:37:49.810 --> 01:37:54.090]  typically it would have an ISA. And again, there's, we could spend a whole class on just
[01:37:54.090 --> 01:37:59.470]  creating BAAs and ISAs, but it basically just sets out the minimum expectations for securely
[01:37:59.470 --> 01:38:06.250]  hosting someone else's data and follows the framework. Security Testing Considerations.
[01:38:06.470 --> 01:38:11.710]  This has come up a little bit, but, you know, earlier in the class, but we just have to assume
[01:38:11.710 --> 01:38:16.550]  that these hospitals are pen testing devices. If you're a medical device manufacturer,
[01:38:17.250 --> 01:38:21.310]  it is a good practice to reach out to the manufacturer before you do the test and just
[01:38:21.310 --> 01:38:25.830]  ask, hey, is there any considerations that I might need to know? Is there anything that if I do,
[01:38:25.830 --> 01:38:29.650]  it's going to break the device? As Helen said a few times, obviously you don't want to test
[01:38:29.650 --> 01:38:35.290]  in a live environment. You want to test in a test environment and kind of need to be aware that,
[01:38:35.290 --> 01:38:40.690]  you know, there could be adverse reactions to pen testing, but certainly, you know, it is a good
[01:38:40.690 --> 01:38:45.650]  thing to do, but just, you know, have that open dialogue with the manufacturer so that, you know,
[01:38:45.650 --> 01:38:49.750]  you can have the best result of that pen test as possible and share the findings, too. You know,
[01:38:49.750 --> 01:38:54.970]  certainly medical device manufacturers want to know if there's any, you know, issues that they
[01:38:54.970 --> 01:39:01.000]  could potentially fix. So, thanks. That is the class. We do have a little bit extra,
[01:39:01.790 --> 01:39:08.290]  so that's all the content, but again, as this class, the focus is, you know, that one or two,
[01:39:09.110 --> 01:39:15.570]  so either IT or cybersecurity person working in a small hospital, this was, we tried to cram
[01:39:15.570 --> 01:39:21.470]  everything into an hour and a half, you know, two hours, and here's a little bit more information on,
[01:39:21.470 --> 01:39:26.210]  you know, where do I go next? How do I keep learning? How do I, you know, stay current?
[01:39:26.210 --> 01:39:30.950]  Things like that. So, if you're that, again, that one person that doesn't really, that wants to stay
[01:39:31.450 --> 01:39:35.610]  engaged, wants to learn more, wants to get certifications, things like that, stay involved
[01:39:35.610 --> 01:39:40.890]  in the security community. If you're watching this live at DEF CON, you're probably already
[01:39:40.890 --> 01:39:45.830]  engaged, but if you're watching this on YouTube after the fact, you're, you may not be. So,
[01:39:45.830 --> 01:39:51.550]  obviously, there's traditional coursework out there. There's a number of different places or
[01:39:51.550 --> 01:39:56.830]  organizations, universities that you can take cybersecurity training in. There's not a lot
[01:39:56.830 --> 01:40:02.910]  that do specifically healthcare and cybersecurity. Salve, Virginia University does have a graduate
[01:40:02.910 --> 01:40:08.250]  class on healthcare administration and cybersecurity. So, it's the only university that I
[01:40:08.250 --> 01:40:12.670]  know that has numerous classes in cybersecurity and healthcare, and are kind of pairing the two
[01:40:12.670 --> 01:40:19.570]  together. There's also the University of Houston may have an executive program on it, and Coursera
[01:40:19.570 --> 01:40:24.630]  has a class on cybersecurity and healthcare, too. But there's not too many... I hear that Salve also
[01:40:24.630 --> 01:40:30.770]  has some really cool professors in this sector. They may. So, you know, again, I don't want to
[01:40:30.770 --> 01:40:34.670]  hype Salve too much, but it is interesting that they actually have, you know, if you're
[01:40:34.670 --> 01:40:40.150]  looking for classes that are specific to healthcare and cybersecurity, they're the
[01:40:40.150 --> 01:40:47.150]  only organization that I know that are pairing those two topics. Certifications, there's a number
[01:40:47.150 --> 01:40:53.750]  of certifications that you can take. Security Plus is kind of CompTIA. Many of their certifications
[01:40:53.750 --> 01:40:59.030]  are kind of considered entry level. That's a bad thing, but if you're new, that's great.
[01:40:59.030 --> 01:41:03.510]  The Security Plus is interesting because it's kind of more entry level in security,
[01:41:03.510 --> 01:41:08.310]  but it typically requires that you have the CompTIA A Plus and Network Plus before. I shouldn't say
[01:41:08.310 --> 01:41:12.830]  that. It doesn't require it, but it recommends it. So that might be more of an entry level
[01:41:13.450 --> 01:41:20.570]  or an earlier career cert. The HCISPP, so the Healthcare... was it Healthcare Information
[01:41:20.570 --> 01:41:27.710]  and Security and Privacy Practitioners Certification from ISC Squared is kind of the
[01:41:29.030 --> 01:41:34.130]  more of the senior level certification. It does require two years of working full time
[01:41:34.130 --> 01:41:39.670]  in the security field. So that's another certification to look at. Surely there's
[01:41:39.670 --> 01:41:44.430]  others out there too. Those are just two that we thought might be applicable to this group.
[01:41:44.970 --> 01:41:53.650]  There's a number of great free online classes, CyberArea and Coursera. I only picked these
[01:41:53.650 --> 01:41:58.450]  because they were listed in the link at the bottom for TechRadar as the top two. And having
[01:41:58.450 --> 01:42:04.290]  taken classes from each, they are good. I will note that I don't know about these two, but a lot
[01:42:04.290 --> 01:42:09.910]  of the free classes. So as a professor, I use some of the free courseware in my classes as like
[01:42:09.910 --> 01:42:19.430]  sub-modules for teaching. And I don't know why, but basically as of like fall 2019, a lot of these
[01:42:19.430 --> 01:42:26.530]  online free education courses or programs started putting some content behind a paywall and anything
[01:42:26.530 --> 01:42:32.530]  like HIPAA and cybersecurity related tended to fall under that. So just be aware that some of the
[01:42:32.530 --> 01:42:37.090]  content may be free and some of it you may have to pay for, but it may be reasonable. So it may be
[01:42:37.090 --> 01:42:42.730]  worthwhile. It may be cheaper to just have all your employees take classes at one of these places
[01:42:42.730 --> 01:42:49.350]  and pay for an organizational membership to develop your own course. Definitely get involved.
[01:42:49.350 --> 01:42:54.710]  Join us in some of the industry groups that we work in. There's the Health ISAC. They have a
[01:42:54.710 --> 01:42:59.550]  number of industry groups. I was leading the global data privacy group for a while. There's
[01:42:59.550 --> 01:43:04.570]  groups on just about everything else. The Healthcare Sector Coordinating Council.
[01:43:04.690 --> 01:43:10.170]  They have some great groups on like secure development life cycle and any number of
[01:43:10.170 --> 01:43:14.990]  other things. There's a work group right now on training and development that I'm involved in
[01:43:15.750 --> 01:43:21.170]  that would be a great one to get involved in if you're looking at continuing to get
[01:43:21.170 --> 01:43:26.390]  more training. And there's certainly other groups out there. AIME, a number of other
[01:43:26.390 --> 01:43:32.210]  organizations. These are just two that tend to be popular in the industry. Please don't
[01:43:32.210 --> 01:43:37.730]  take any of these as a decisive list of everything that you can look at. And local security groups.
[01:43:37.730 --> 01:43:41.310]  Again, if you're watching this live, you're probably familiar with this, but if you're
[01:43:41.310 --> 01:43:47.910]  watching this on YouTube after the fact, local OWASP chapters are great for monthly meetups.
[01:43:47.910 --> 01:43:52.570]  And then DEF CON. So we're at DEF CON. There's local DEF CON groups or chapters.
[01:43:53.630 --> 01:43:58.270]  DEF CON 617 was a Boston group that I was involved for a while. And now I'm heavily
[01:43:58.270 --> 01:44:03.190]  involved with DEF CON 401. So they do, you know, most of these do like monthly,
[01:44:03.750 --> 01:44:07.570]  that's kind of like a lunch learn, but they're usually at night where they might have pizza
[01:44:07.570 --> 01:44:12.850]  and someone to give a talk. And, you know, it might be a technical, it might be, you know,
[01:44:12.850 --> 01:44:17.170]  it could be any topic related to security. So, and it's good for networking, kind of making
[01:44:17.170 --> 01:44:22.490]  contacts within your area as well. So, and the, one of the good things, if there's a good thing
[01:44:22.490 --> 01:44:28.110]  about COVID-19 is that because we're not meeting in person, a lot of these groups are doing online
[01:44:28.110 --> 01:44:33.370]  meetings now that you don't have to geographically live close to, like DEF CON 401. If you look at
[01:44:33.370 --> 01:44:37.910]  their meetup, they have a number of, I think the next couple months, maybe at least two or three
[01:44:37.910 --> 01:44:41.970]  months are going to be online because we can't meet in person. So, you know, you can, if you
[01:44:41.970 --> 01:44:46.050]  live in an area where there isn't one of these groups and you can't, if you go to like DEF CON
[01:44:46.050 --> 01:44:50.550]  groups.org and try to find one in your area, but if there isn't one in your area, maybe at least
[01:44:50.550 --> 01:44:56.690]  for the next couple months, who knows how long, you can visit one online. Again, if you're super
[01:44:56.690 --> 01:45:02.250]  new to InfoSec, this is a good book. It was free for a while online. I don't know if it still is,
[01:45:02.250 --> 01:45:08.070]  but there was a PDF for free online. If you do have to buy it, maybe it's five bucks. But yeah,
[01:45:08.070 --> 01:45:12.850]  if you do do InfoSec and trying to figure out how to grow your career, learn more, you know,
[01:45:12.850 --> 01:45:19.190]  get certifications, things like that. This is a great book to check out. Some other good resources,
[01:45:19.190 --> 01:45:24.050]  Micah Hoffman's presentation at B-Sides on how to join the InfoSec community. Again, getting
[01:45:24.050 --> 01:45:28.730]  involved. One of the great things about the InfoSec community is that, you know, we're constantly
[01:45:28.730 --> 01:45:33.210]  sharing information and training each other and it doesn't really cost a lot of money,
[01:45:33.210 --> 01:45:39.210]  which is great. You can just kind of go to conferences for fairly cheap and continue to
[01:45:39.210 --> 01:45:44.430]  keep learning. So things to Google, you know, you can Google hacking the skills shortage,
[01:45:44.430 --> 01:45:49.270]  we'll pull up good articles on that. Best information security certifications for,
[01:45:49.270 --> 01:45:54.650]  you know, insert the year, five grade starter cybersecurity certifications, things like that.
[01:45:54.650 --> 01:45:59.870]  We'll all kind of put you in line of understanding, you know, kind of maybe your next career step.
[01:45:59.870 --> 01:46:04.570]  And not necessarily career step of just where, you know, where to go to if you to leave your
[01:46:04.570 --> 01:46:09.190]  company and go somewhere else. But if you like working at a hospital, how to keep evolving your
[01:46:09.190 --> 01:46:13.130]  skills so that you become a better, you know, defender of your hospital organization.
[01:46:14.470 --> 01:46:18.310]  So we want to keep the conversation going. We're going to take a short break.
[01:46:18.310 --> 01:46:24.890]  So definitely go get some food, get your favorite beverage, and we'll be back in a little bit to
[01:46:24.890 --> 01:46:28.010]  actually have a panel discussion where you can not only talk to me and Helen,
[01:46:29.510 --> 01:46:33.470]  but a number of other experts in the field that know a lot more than we do.
[01:46:33.470 --> 01:46:37.390]  And some of them work at hospitals, so they can give you that perspective as well.
[01:46:38.730 --> 01:46:46.550]  So let's see. Yeah, so, you know, certainly reach out, again, both in the follow-up
[01:46:48.610 --> 01:46:52.570]  panel afterwards, but also, you know, if you have a specific question that you don't want
[01:46:52.570 --> 01:46:56.570]  to raise there, you can reach out. Here's our contact information. We'll leave that
[01:46:56.570 --> 01:47:01.290]  up for a little bit so you can email us, you know, hit us up on Twitter, you know,
[01:47:01.290 --> 01:47:04.670]  however you want to get a hold of us. And we look forward to hearing from you more.
[01:47:04.670 --> 01:47:09.250]  Again, take a take a good break, and then we'll be back for the panel discussion,
[01:47:09.250 --> 01:47:14.870]  and we look forward to hearing some of your questions. So thanks for all of everyone paying
[01:47:14.870 --> 01:47:18.730]  attention and the questions that were in the Discord channel during this training,
[01:47:18.730 --> 01:47:22.830]  and we look forward to seeing you at that panel. Thanks. Thank you for your time.