WEBVTT 00:00.000 --> 00:01.320 Thanks, everyone, for joining. 00:01.320 --> 00:08.100 This is Securing a Medical Device Network on a Shoestring Budget by Helen and myself, Matt McMahon. 00:08.100 --> 00:10.000 We'll be your presenters today. 00:10.500 --> 00:18.920 This will be recorded, pre-recorded and streamed, but we will be available on Discord to answer any questions. 00:19.580 --> 00:21.820 Just a little bit of an intro in the class. 00:21.820 --> 00:35.040 This initially was a four-hour course, and we cut it down, so we will be trying to cover a good amount of topics in a little bit of a short time, but it will be recorded and played again, so they're available again on YouTube. 00:35.040 --> 00:42.860 So if you need to get up to get a drink or use the restroom, feel free to do that and come back, and you can look at any parts that you missed afterwards. 00:43.520 --> 00:47.440 So just to kind of give a quick synopsis of where this training came from. 00:47.440 --> 00:53.620 So Helen and I both work for a medical device company in their cybersecurity group. 00:53.900 --> 01:02.520 We're also both either current or former adjunct professors teaching courses in cybersecurity, healthcare, digital forensics, and things like that. 01:02.640 --> 01:09.020 So we thought this would be a really good class for hospitals to kind of understand some of the basics. 01:09.020 --> 01:14.240 So this is a totally free course, open to anyone, and we're really just looking to share knowledge. 01:14.980 --> 01:16.900 So a note on our target audience. 01:16.900 --> 01:27.900 We developed this course initially for the target audience being like a small critical access, like 25-bed hospital, with a smaller IT staff and a limited budget. 01:28.180 --> 01:34.360 They may not have any cybersecurity staff currently in the workforce. 01:35.000 --> 01:46.200 So there will be things that larger hospital organizations or other individuals can get out of this course, but if some of the material, at least in the beginning, seems kind of basic, just kind of bear with us. 01:46.200 --> 01:53.720 We're trying to set the stage so that target audience can pick up and kind of follow us for the whole course. 01:55.260 --> 02:00.460 So what we're going to cover today, we're going to have six different distinct modules. 02:00.460 --> 02:15.800 So I'll start with the healthcare threat landscape today, then Helen will take over for basic network security within the hospital, network monitoring and scanning, developing and regular patching strategies, then I'll take back over at the end for physical security, 02:15.800 --> 02:17.820 and then vetting of third parties. 02:18.420 --> 02:30.300 We'll then have a short break, and then we'll come back for a panel discussion, both with Helen and myself, and a number of other experts from the hospital cybersecurity space. 02:30.300 --> 02:33.320 So make sure to come back for that. 02:33.940 --> 02:36.520 As I said before, this training is pre-recorded. 02:36.520 --> 02:44.060 So we are, while we're teaching, we're not teaching right now, this was pre-recorded, so we are able to answer questions on the Discord channel. 02:44.540 --> 02:47.640 And be aware, too, that we do have that panel afterwards. 02:47.640 --> 02:59.340 If there's a question specifically on how a hospital may do something, we may defer to the panel, just because then you'd be able to actually hear from hospital staff on how they would handle certain situations. 03:01.040 --> 03:12.620 So just to kind of start off and set the stage, it's important before you really can secure or defend anything, you kind of need to know your current threat landscape, and certainly healthcare is a little bit different than some other threat landscapes. 03:13.020 --> 03:21.920 So a lot of the data that we'll be pulling from the Verizon Data Breach Investigation Report, obviously that comes out each year, there's a lot of good data that comes with it. 03:21.920 --> 03:25.940 But there's another report called the Protected Health Information Data Breach Report. 03:25.940 --> 03:33.800 It takes the DBIR's data specifically just on healthcare and the healthcare sector related to data breaches. 03:33.800 --> 03:40.320 It takes those stats over the course of three years and extrapolates some data from just the healthcare sector. 03:40.320 --> 03:44.500 So we'll be talking a lot about information from those reports. 03:46.100 --> 03:55.100 PHI, I mean, this is probably not anything new to anyone that's currently working in the field, but just in case you don't know, medical record, why is it valuable? 03:55.100 --> 04:01.000 It could potentially sell for 10 to 20 times on the black market. 04:01.000 --> 04:08.640 What a credit card record could sell for, you can't turn off a PHI record, protected health information record, like you can a credit card. 04:08.880 --> 04:15.460 An attacker could potentially use the stolen data to acquire expensive medical equipments or technology. 04:15.460 --> 04:21.820 And then an attacker could also combine PHI with a provider number to file fraudulent insurance claims. 04:21.820 --> 04:27.180 Just very quick, some possible things that could happen. 04:27.720 --> 04:35.000 One of the things that makes the threat landscape and healthcare really unique is the prevalence of insider threats. 04:35.000 --> 04:44.720 And when we say insider threats, we typically think of malicious insider threats, but healthcare is unique in that there's a lot of error that factors into that as well. 04:44.720 --> 04:50.340 So non-malicious errors and data breaches as a result of that. 04:50.780 --> 04:58.280 In healthcare, 58% of data breaches over the course of those three years that were recorded did have some insider component. 04:58.280 --> 05:02.400 Again, both malicious and non-malicious, but that is important to note. 05:02.400 --> 05:05.440 It's the only critical infrastructure sector in the United States. 05:05.440 --> 05:08.800 They're actually more likely to be compromised internally than externally. 05:08.800 --> 05:12.320 So we want to make sure that we're taking into account that. 05:13.760 --> 05:16.100 So what's the breakdown of some of the threats? 05:16.100 --> 05:21.440 So we talked, I said some of this were non-malicious, so a lot of it is error. 05:21.440 --> 05:26.500 You can see over 30%, 33.5% is just error. 05:26.620 --> 05:35.800 So individual staff, maybe clinical staff working long hours, swing shifts, too many patients than they would normally have certainly in the COVID era. 05:36.380 --> 05:42.820 Working with technology that they might not be familiar with, it's easy to make a mistake and cause a data breach that way. 05:43.340 --> 05:45.760 Misuse would be the second highest, just under 30%. 05:46.980 --> 05:50.120 Misuse in this case would have a deliberate component. 05:50.380 --> 05:55.740 So it could be as simple as nurse A tells nurse B, hey, did you hear about this patient? 05:56.380 --> 06:01.760 And nurse B shouldn't have access to that patient, or it could be selling hundreds of thousands of records. 06:01.940 --> 06:04.220 So there's a broad spectrum there. 06:05.000 --> 06:07.120 Physical, we'll touch on a little bit. 06:07.500 --> 06:19.080 And what's interesting with this graph, is you see, if you look on the news, or just search cybersecurity and healthcare, pretty much what you're going to see is a lot about ransomware. 06:19.080 --> 06:27.160 And certainly we'll talk about ransomware in this presentation about how prevalent it is, and how it's becoming much more prevalent. 06:27.160 --> 06:32.840 But it's just important if you're trying to defend the hospital's network, to kind of know where your threats are really coming from. 06:32.840 --> 06:39.000 Certainly you want to defend against quote, unquote, hacking, or malware, ransomware. 06:39.000 --> 06:51.700 But we'll also want to make sure that we're aware of the fact that our largest threats might actually be already inside the building, someone that we've actually given access to. 06:53.060 --> 06:59.860 So if we dive down into those errors, again, over 30%, misdelivery was the biggest. 06:59.880 --> 07:03.520 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:14.260 Loss, we just lost the data, we didn't know where it went to. 07:14.660 --> 07:15.640 Publishing error. 07:15.640 --> 07:18.000 Publishing error typically would be like a study. 07:18.000 --> 07:28.500 So we've released a study that we think had anonymized data, that data was able to be de-anonymized, and they were able to... basically resulted in a data breach. 07:28.700 --> 07:36.360 What do you find interesting about this is, there was a quote in the report that said healthcare has a paper problem. 07:36.360 --> 07:44.140 Typically when you think data breach, we think electronic, 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:53.580 Data misuse, so again, misuse required that distinct motive. 07:53.580 --> 08:01.280 It could be as simple as nurse A tells nurse B, hey, your ex-significant other is in the hospital, did you hear about it? 08:01.280 --> 08:03.460 Or it could be selling records. 08:04.560 --> 08:10.940 And let's see, and typically this involved at least two-thirds of privilege abuse. 08:10.940 --> 08:16.480 So accessing data that they shouldn't have access to, maybe escalating their own privileges. 08:17.980 --> 08:25.300 Physical, physical was pretty close to 100%, over 95% just stolen on encrypted laptops. 08:25.360 --> 08:36.980 If this was a doctor's laptop that was stolen but encrypted, they don't include that as a potential data breach, just because they assume that an attacker wouldn't be able to get to that data. 08:37.200 --> 08:41.600 But if the data is non-encrypted, then they assume that they are able to get to that. 08:41.600 --> 08:54.980 So yeah, interesting with this picture, that while the attacker did break the window and steal the unencrypted laptop full of PHI, they did at least leave the font So that's nice. 08:56.460 --> 09:04.660 And quote-unquote hacking, this is kind of a broad, broad category, but this included almost 50% was phishing, social engineering. 09:05.180 --> 09:11.940 And again, just try to remember that this is below 15% of the overall data breaches. 09:11.940 --> 09:22.340 So again, we're just talking about data breaches here, not necessarily cyber attacks that bring down hospital networks, but specifically data breaches and breaking that down. 09:22.860 --> 09:30.240 So just under 50% of that was using stolen credentials that were harvested, again, potentially from phishing or social engineering. 09:30.340 --> 09:33.400 Over 20% was brute forcing a password. 09:33.980 --> 09:44.160 17.9%, so almost 18%, was using a backdoor on a device, could be a medical device, could be software, whatever that backdoor is. 09:44.180 --> 09:47.140 And then you see minimal for the other ones. 09:48.240 --> 09:52.900 Malware, so general category of malware is just under 11%. 09:52.900 --> 10:01.700 Again, kind of keep in mind the prevalence of that internal error, and over 70% of that was specifically ransomware. 10:01.700 --> 10:05.720 So obviously, that's a factor. 10:05.740 --> 10:22.380 So while I am trying to highlight the fact that insider threat is statistically a lot bigger for data breach, data breaches within the healthcare sector, obviously, malware, there is certain caveats that we need to talk about, it is certainly increasing. 10:22.980 --> 10:26.680 This was an interesting report that came up from NTT Security. 10:26.680 --> 10:31.740 They published a report back in, it's a little bit dated now, but Q2 of 2016. 10:32.140 --> 10:42.560 They looked at their entire, so their security company, they looked at their entire customer portfolio, 7.4% of their customers, only 7.4% of their customers were hospitals. 10:42.600 --> 10:47.600 But those hospitals made up 88% of their clients that were affected by ransomware. 10:47.600 --> 10:55.560 So it really said, wow, while hospitals make up a small percentage of our actual customer base, they're disproportionately affected by ransomware. 10:55.560 --> 10:58.860 And we'll certainly get in this class as to why that is. 10:58.860 --> 11:05.000 Flat networks, lack of proper security controls, things like that. 11:05.160 --> 11:10.900 And it was predicted that ransomware attacks in the healthcare sector would quadruple in 2020. 11:10.900 --> 11:14.000 And certainly we've seen an increase in that. 11:16.460 --> 11:17.300 All right. 11:17.480 --> 11:21.240 COVID-19, I can't really have a talk now and not talk about COVID-19. 11:21.240 --> 11:24.480 So certainly that's changed the threat landscape as well. 11:24.480 --> 11:33.820 Not just in healthcare, but across the board we've seen a 667% increase in COVID-19 related email attacks, just from February to June. 11:33.820 --> 11:38.980 And then just cyber attacks in general up 37% in May. 11:39.100 --> 11:46.540 And what's interesting with COVID too, is we're not just seeing cyber attacks, but we're also seeing a lot of fraud. 11:46.660 --> 11:50.460 Interpol has seized over $14 million worth of fake PPE. 11:50.460 --> 11:59.220 And certainly hospitals have been caught with purchasing or trying to purchase PPE in the past when it was a little bit harder to get. 11:59.760 --> 12:04.940 Maybe they had to front funds to get those, and then they just never got their equipment. 12:04.940 --> 12:10.100 So there's a lot of different possibilities there for compromise. 12:10.720 --> 12:17.600 For folks that work in the cybersecurity and healthcare space or industry, this was an interesting report that came out in March. 12:17.600 --> 12:31.780 Basically a number of ransomware shops said that, no, we won't specifically target the healthcare sector or hospitals during a pandemic, because that would be incredibly bad. 12:31.980 --> 12:34.960 Unfortunately, that was not the case. 12:34.960 --> 12:39.760 They still have continued to attack the healthcare sector. 12:40.100 --> 12:42.680 And in many cases, it's actually increased. 12:42.680 --> 12:53.580 So we've seen Health ISAC has reported an increase in COVID-19 themed attacks, up 20% to 30% in just phishing, specifically targeting the healthcare sector. 12:53.760 --> 12:56.820 And you can see there, the average ransom payments. 12:57.160 --> 13:03.140 And obviously, during a pandemic, there's a lot of things that make this more difficult. 13:03.140 --> 13:07.640 Obviously, getting physical access to a device, if it's in a quarantined area, to be able to update it. 13:07.640 --> 13:16.000 If you need to physically access the device to update something , that just adds an extra layer of issue. 13:17.760 --> 13:29.240 So how many hospitals do we know of that have actually been attacked or been compromised by ransomware, specifically using a COVID-19 hook? 13:29.440 --> 13:35.960 According to Bill Siegel, the CEO of Coveware, there's been at least half a dozen just in the US. 13:35.960 --> 13:39.600 There's probably significantly more than that, but those are the ones that we're aware of. 13:41.020 --> 13:44.300 There is certainly a good amount of under-reporting. 13:44.300 --> 13:47.300 It's difficult to really understand the scope. 13:47.460 --> 13:50.320 Hospitals, in a lot of cases, pay the ransom. 13:50.820 --> 13:54.980 It may not be reported if we don't believe that there's a data breach. 13:55.120 --> 13:59.620 So it's hard to tell the exact number, but we know of at least half a dozen in the US. 14:00.340 --> 14:05.300 In Canada, a Canadian government hospital there was affected. 14:05.500 --> 14:13.320 It was specifically targeted using a spoofed email that appeared to look like it came from the World Health Organization. 14:13.440 --> 14:20.660 It was procurement-related, so this was a couple months back when procurement of gloves, masks, things like that were quite difficult. 14:20.920 --> 14:27.100 If you read the email, it was really easy to spot if you knew what you were looking for. 14:27.360 --> 14:40.680 The authors really didn't make any attempt to make it look legit in any way, but because of the need for procurement materials at that point, again, gloves and masks, it was clicked on and propagated. 14:41.440 --> 14:42.280 Spain. 14:42.280 --> 14:52.300 Spain at that time was particularly hard-hit by COVID-19, and the Spanish hospital was hit by the Netwalker ransomware. 14:52.300 --> 15:00.740 It specifically targeted Spanish hospitals, specifically during the peak of the virus there, using a malicious attachment. 15:02.080 --> 15:04.360 Czech Republic as well. 15:04.500 --> 15:06.860 Brno, I believe, had that saying. 15:06.860 --> 15:08.800 I hope that's not incorrect. 15:08.800 --> 15:14.200 University Hospital, which was the second largest hospital in the Czech Republic, was taken offline. 15:14.280 --> 15:21.840 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:40.810 A urology consultant company was hit. 15:40.810 --> 15:43.150 Medical device manufacturers have been hit. 15:44.590 --> 15:46.370 So why target healthcare? 15:46.430 --> 15:50.490 Well, hospitals, as we said earlier, unfortunately often pay the ransom. 15:50.630 --> 15:52.310 There is a need to be online. 15:52.450 --> 16:03.750 These technologies are life and death, and often they have less resources to be able to defend themselves, so it might be easier to attack a hospital. 16:04.490 --> 16:06.590 So some quick key takeaways. 16:07.050 --> 16:11.250 Privilege and escalation abuse was two-thirds of all the incidents. 16:11.510 --> 16:25.150 Now, having been someone that worked for a hospital for a while, doing application access and having to monitor access, I can certainly say that this is difficult. 16:26.130 --> 16:33.150 A lot of this really depends on how those individuals are keeping access. 16:33.150 --> 16:35.870 Certainly, you want to restrict access as much as possible. 16:35.870 --> 16:37.330 You don't want to leave it open. 16:37.570 --> 16:49.570 But in my case anyway, it was certainly noted that the application support staff were working on call on the weekends, and they were not being paid to work on call. 16:49.570 --> 17:08.430 So if you're doing that, you're basically creating a situation that encourages or incentivizes your IT staff to leave access more broadly open than it probably needs to be so that they're not getting a call at 11 o'clock at night during shift change when new nurses come on, 17:08.430 --> 17:12.410 maybe temporary nurses that need access. 17:12.410 --> 17:21.430 So just kind of think about that, maybe how your hospital IT staff or application support staff have to deal with access. 17:21.430 --> 17:25.390 Do you have someone that's constantly working, or is it on call? 17:25.390 --> 17:26.930 It certainly comes into play. 17:29.330 --> 17:30.290 Data mishandling. 17:30.290 --> 17:37.370 So this was, you know, kind of a cultural problem that we're talking about where, you know, nurse A tells nurse B, hey, did you hear about this individual? 17:37.990 --> 17:41.350 This was almost 17% of the data breach cases. 17:41.350 --> 17:44.010 So, you know, something to kind of consider. 17:45.110 --> 17:49.870 Certainly, it's human nature, curiosity, so it's difficult, but something to consider. 17:50.430 --> 17:55.150 Fraud in the healthcare sector, there is a large amount of fraud in the healthcare sector. 17:55.150 --> 18:02.810 It's the third highest industry for fraud in the United States, right behind the government sector, and finance was number one. 18:05.050 --> 18:08.130 Breach discovery is also an issue within healthcare. 18:08.270 --> 18:13.690 Approximately one-third of the data breaches in the three-year study were not discovered for years. 18:13.690 --> 18:15.890 Another third were not discovered for months. 18:15.950 --> 18:33.910 So it's important to kind of note that, you know, when you're looking at the numbers or considering if you've been breached, you know, many hospitals may not even be aware of it, so... And just one other thing that kind of complicates this, budgeting and staffing realities, 18:33.910 --> 18:43.230 it's commonly cited by CISOs from hospitals that 3% of the hospital budget goes towards IT, and 3% of that 3% goes to security. 18:43.250 --> 18:51.970 So they really don't have a lot of, you know, either the staff or the resources that they need to dedicate to security. 18:51.970 --> 19:05.910 So that really kind of leads into one of the reasons why we built this course, to try to offer some, you know, free technology, in this case free training, or low-cost technology that could be used to secure a hospital's network. 19:06.450 --> 19:09.970 Another issue is what's called agency staff. 19:10.290 --> 19:16.510 So at any given hospital, up to 10% of the nurses could potentially be agency staff. 19:16.510 --> 19:25.390 So someone calls in, we need someone to, you know, take their shift, they call the agency, they get a nurse, that person then has to be added to all the hospital systems. 19:25.910 --> 19:34.530 Certainly if you're working in IT at a hospital, please fight the urge to just create entries in your system called agency nurse 1, 2, or 3. 19:34.750 --> 19:42.190 It certainly makes it easier for IT staff, but obviously, you know, for logging and things like that, it could be a bit of a nightmare. 19:42.190 --> 19:44.550 So just kind of be aware of that. 19:45.450 --> 19:52.950 Just some quick insights from the 2009 HIMSS report of all of the hospitals that were surveyed. 19:52.950 --> 20:00.890 Over the course of the last 12 months, 82% of hospitals said that they did have a recent significant security incident. 20:01.090 --> 20:05.410 So kind of good to note of the prevalence of how much this is happening. 20:05.550 --> 20:08.010 Legacy systems are also an issue. 20:08.310 --> 20:15.370 72% of hospitals said that up to between 1 and 10% of their technology is outdated legacy tech. 20:16.130 --> 20:32.730 And if you look at 2016, the 2016 HIMSS study, it interviewed or looked at 200 different hospitals, but I believe a third of those, or I shouldn't say hospitals, 200 different medical facilities, but a third of those were like doctor's offices and smaller offices. 20:32.730 --> 20:36.950 So certainly those, that third skewed the stats a little bit. 20:36.950 --> 20:39.730 So you can kind of factor that in when you're looking at these numbers. 20:39.750 --> 20:48.530 But it's still a little bit scary to even think that those, even if it's like an outpatient clinic or a doctor's office, that numbers would be this high. 20:48.530 --> 21:04.950 So 14% of those medical facilities lacked any antivirus or malware, under 20% no firewall protections, 46% no network monitoring, 52% no intrusion prevention, and 41% didn't encrypt data at rest. 21:04.950 --> 21:06.970 Again, this is 2016. 21:07.310 --> 21:15.130 HIMSS doesn't ask the same questions every year, so we can't see trends, but just kind of something to take into account. 21:16.510 --> 21:18.810 So this is the last slide of this. 21:19.090 --> 21:33.730 And again, just to kind of talk about our objective, we're really trying to train those small critical access hospitals on some of the things that they can do to help bolster their cybersecurity posture. 21:33.870 --> 21:35.370 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 --> 22:11.710 I wanted to go ahead and preface that in the interest of time, I've removed demos, but I've added a slew of links on added resources, places where you can get demos, and just manuals and the like to the end of this presentation that all the decks will be available to whomever would like them. 22:11.810 --> 22:21.310 I also included any slides that I removed in order to streamline this presentation and hit our time restraint. 22:21.310 --> 22:25.210 I include them in that slide deck and with my notes. 22:25.210 --> 22:31.570 So if you have any questions, you can go ahead and look through that and then reach out to me or Matt. 22:33.130 --> 22:43.390 We're going to start with the little parts of network security, you know, cyber hygiene, and just the basics. 22:43.670 --> 22:55.950 As Matt said, the 2019 HIMSS study shows the importance of the network security basis, basics. 22:56.210 --> 23:00.770 A pattern of cybersecurity threats are discernible across U.S. 23:00.770 --> 23:12.450 healthcare organizations, and as Matt has just said, the trend has only increased in the current pandemic era. 23:14.740 --> 23:19.060 Elements of network security, there are so many. 23:19.060 --> 23:32.280 I have asked this question of other people, and everybody can give you, you know, 20 talking points of things that they find to be the core of network security. 23:32.280 --> 23:35.360 Here are some of those elements. 23:35.360 --> 23:46.260 We're going to talk about access management, segmentation, we'll go a little bit into firewalls, and we'll finish up with some testing. 23:48.810 --> 23:57.810 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:29.670 Network security for the uninitiated and overworked, I understand it's really difficult, but hopefully with this primary, you'll be armed with the tools to at least ask the right questions of your external consultants or Dr. 24:29.670 --> 24:30.770 Google. 24:33.610 --> 24:37.110 Strong access management is key. 24:37.110 --> 24:43.850 You want to secure your endpoints, ensure your remote workers use a VPN. 24:43.910 --> 24:48.250 You want to have strong but manageable passwords. 24:49.270 --> 24:54.430 You want to use multi-factor when applicable or possible. 24:54.430 --> 25:08.630 I understand that it is very common in a lot of workflows in a hospital staff to use their badge already for access, so having them switch to badge and pin is not a stretch. 25:08.630 --> 25:11.950 It would be within a normal workflow. 25:13.090 --> 25:19.230 Physical controls to limit access to restricted areas are a must, and Matt will get to those later. 25:19.230 --> 25:25.790 You want to review administrative accounts, access to servers and workstations and devices. 25:25.790 --> 25:33.010 You don't want local admin accounts that can lead to unintended privilege access to systems or data. 25:33.010 --> 25:36.770 You don't want generic lab user one. 25:37.030 --> 25:41.430 You really want to know who is accessing your data and why. 25:41.510 --> 25:52.810 Review the process for elevating access as a request and make sure that there's a separation of duty policy for administrative access. 25:52.810 --> 25:59.070 Review shared accounts for necessity and then monitor out for abnormalities or misuse. 25:59.070 --> 26:05.810 And finally, you want to review your terminated employees or people that are on leave of absence. 26:05.810 --> 26:16.630 If those accounts are not terminated quickly, they can be used inappropriately. 26:18.470 --> 26:34.850 The principle of least privilege is one of the basic principles of user access. 26:34.850 --> 26:39.450 You don't want one mastered user that has all the keys to the kingdom. 26:39.510 --> 26:46.690 If that user is compromised, you are compromised. 26:46.830 --> 26:49.690 You don't want one person performing every duty. 26:49.690 --> 26:56.470 You want to spread those duties around and you want to have more than one person accessing an area. 26:57.470 --> 27:02.870 With that in mind, sorry, I do want to start this over. 27:05.330 --> 27:11.410 That was the concept of separations of duty, not the least privilege. 27:11.410 --> 27:22.470 The concept of least privilege is that you want to have the user have the minimum access needed to do their job. 27:28.200 --> 27:30.080 Network segmentation. 27:30.080 --> 27:42.040 Network segmentation is the practice of dividing larger computer networks into several smaller subnetworks that are each isolated from one another. 27:42.040 --> 28:03.220 If you think of this like a fence around your house, if you have a fence around your house and you don't have any other protection to keep your house from being broken into, all somebody needs to do is find a way to get in through your fence, right? 28:03.800 --> 28:12.460 So that's what you would have even if you just have one firewall or one access area of protection. 28:12.460 --> 28:24.600 If you are creating a bunch of smaller networks, smaller segments, even if one area is compromised, the other areas can remain protected. 28:29.160 --> 28:36.880 Here are some examples of what a flat network looks like and that's what we have seen in a lot of hospitals. 28:37.000 --> 28:55.980 You have the internet and everyone can access the internet and all the equipment runs on the same network and it's almost set up like a home network but in a business that runs, that deals with such sensitive information. 28:56.500 --> 29:10.660 The next slide, the next picture is a basic segment and here is an idea of what segmentation in hospitals looks like. 29:13.080 --> 29:25.200 Here are, so a VLAN is a logical partition in the layer two network and here's a background of what a switch would look like and 29:28.400 --> 29:36.420 some ideas of what the logical layout would look like. 29:38.380 --> 29:42.420 So I have removed a section on types of firewalls. 29:42.420 --> 29:50.960 There are several types of firewalls and you should look to find which kind suit your purpose. 29:51.380 --> 29:54.460 There is some great information out there. 29:54.460 --> 29:57.460 I've included that in our resources at the end. 29:58.380 --> 30:05.280 Firewalls are your first line of defense for securing healthcare networks from against the public. 30:05.600 --> 30:12.140 Firewalls are digital walls that stand between protected health data and potentially dangerous threat actors. 30:12.140 --> 30:22.900 You want to start by blocking all, by blocking all traffic by default and then only allowing specific traffic to identify services. 30:22.900 --> 30:28.860 This approach provides quality control over traffic and decreases the possibility of breach. 30:28.860 --> 30:48.780 You're going to want to make changes slowly over time and I understand that sometimes this is impractical but you want to do this in small segments and secure your network over time during downtime and maintenance zones, maintenance periods. 30:49.720 --> 31:05.460 So the approach of quality control over traffic 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:37.300 So you follow an established set of rules and then firewalls can actively monitor incoming and outgoing traffic. 31:37.300 --> 31:46.040 In doing so, a firewall blocks the secure network from the internet, only allowing pre-cleared data to pass. 31:47.460 --> 32:04.560 So you want to know the firewall's purpose, what the affected devices are, what users have access, what date your rule applied, and who's the name of the person who added the rule. 32:05.880 --> 32:26.260 Some inbound rules are whitelists, which are falling out of favor and are being called allow lists or a few other terms, which will be, you know, only allowing Jim and Mary to go to the insurance billing information website. 32:26.540 --> 32:29.820 These are who's allowed to access an area. 32:29.820 --> 32:42.980 There's a deny list, which is, you can go ahead and allow these doctors to go anywhere except ratemymd.com. 32:42.980 --> 32:46.340 You don't want them reading reviews and getting upset on shift. 32:47.760 --> 32:55.700 You want to block, so you're not going to allow one person access to anything, whatever the thing you're saying. 32:55.700 --> 33:02.380 Okay, this guy is in environmental services. 33:02.380 --> 33:04.400 He doesn't need to access financial records. 33:04.400 --> 33:06.320 That's blocked all together. 33:06.360 --> 33:08.440 And then a VPN. 33:08.440 --> 33:19.740 So you say, okay, you're only going to allow this physician that works from home to access our network if they're using our approved remote access avenue. 33:21.140 --> 33:24.020 SANS has some great firewall information. 33:24.020 --> 33:28.240 I'll have links to that in the resources at the end of my deck. 33:28.980 --> 33:32.640 And they have a firewall checklist. 33:32.720 --> 33:42.460 The main purpose of the firewall is to drop all traffic that is not explicitly permitted as a safeguard to stop uninvited traffic from passing through a firewall. 33:42.500 --> 33:48.540 You want to place a drop any, any, well, an any, any, any drop rule. 33:48.540 --> 33:49.760 It's a cleanup rule. 33:49.760 --> 33:54.420 So if you forget about something, this default rule will clean it up. 33:54.760 --> 33:58.420 You want to have this at the bottom of each security zone. 33:58.920 --> 34:04.280 And this will provide just a catch all, catch all mechanism for capturing traffic. 34:05.180 --> 34:08.500 Here's an example of what a cleanup rule would look like. 34:10.200 --> 34:21.600 It's also important to note that with all of this, you need robust documentation and a strict change procedure. 34:23.060 --> 34:28.400 Firewalls rules will need to be updated for any new service or new devices. 34:28.400 --> 34:30.660 They're going to have changes over time. 34:30.660 --> 34:42.660 But before adding or changing or removing any rules, you want to implement a formal change procedure that can make sure you're keeping track of the modifications. 34:42.660 --> 34:49.870 So here are some guidelines for those procedure, change procedures. 34:54.420 --> 35:11.390 I know automation is a important topic and automation is definitely possible with firewalls configuration, for rules, for management of your fleet. 35:11.390 --> 35:19.370 You can manage windows firewalls via domain group policies. 35:19.370 --> 35:24.270 You can use configuration management for traditional firewalls. 35:24.270 --> 35:26.770 You can use something like granted. 35:27.190 --> 35:36.910 Linux has web-based tools to manage network routers, switches, firewalls, etc. 35:38.470 --> 35:48.890 You can have a fleet managed software so, you know, like certain vendors will have their own tools to manage their fleets. 35:49.390 --> 35:52.390 And it's the same with wireless access points. 35:52.390 --> 35:57.890 So you'll want to pick the management tool that works for your particular network. 36:01.550 --> 36:08.230 When working in windows, you can manage all the firewalls via domains, group domain policies. 36:08.530 --> 36:13.810 Here's the Linux note and the other items I just mentioned. 36:14.650 --> 36:15.550 Testing. 36:15.550 --> 36:22.130 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:43.450 You might have a customer or a patient that has questions and if they're a large donor or something you might be motivated enough to test this. 36:43.450 --> 36:53.670 There might be a need for some sort of full red team engagement or overall whatever you want to do to assess risk readiness. 36:54.050 --> 36:57.130 And it is important to pick a strategy. 36:57.310 --> 37:02.330 And there's different levels of depth here. 37:02.350 --> 37:10.350 There's the vulnerability scanning or security scanning which is automated. 37:10.350 --> 37:13.010 There are several tools out there for this. 37:13.070 --> 37:17.850 And it's to get an idea of basic weaknesses. 37:17.850 --> 37:21.790 So are there patches that haven't been applied yet? 37:22.530 --> 37:26.290 Are there ports open that might be suspicious? 37:26.430 --> 37:29.830 What's the idea of traffic going on right now? 37:29.850 --> 37:39.270 It gives you an idea of your risk in an automated way so you don't have to have an extra resource devoting time to that. 37:39.270 --> 37:50.350 It does not by any means replace more robust security measures but it is a way to get an idea of what's going on and what weaknesses you may have. 37:51.090 --> 37:55.210 A pen test is more in-depth. 37:55.210 --> 38:05.850 It involves a person simulating different types of attacks in order to find as many vulnerabilities as possible. 38:05.850 --> 38:23.490 They will provide you with a report and depending on if you're what the agency you're going with to do this or what kind of your internal testers, what their process is, they may also help you find remediations for that. 38:23.710 --> 38:35.370 Risk assessments are more either enterprise risk management or sometimes compliance related. 38:35.370 --> 38:54.070 It's a process of reviewing and analyzing potential risks that later you can prioritize and get business input on and you're going to try to come up with a plan as to see what the possible ways of preventing these risks from becoming a reality. 38:54.850 --> 39:05.250 So you're going to prioritize components that carry the highest risk and you'll say, okay, this stores most of our patient data, for example. 39:05.250 --> 39:15.430 We're going to go ahead and market for some more robust testing so we can get an idea of where our are and really plug those holes to the best of our ability. 39:15.750 --> 39:19.030 Security auditing is verification. 39:19.430 --> 39:22.710 You can audit your access management policy. 39:22.710 --> 39:31.990 You can also use this tied to compliance and you can analyze the system in working conditions. 39:31.990 --> 39:35.330 You're taking a view of what's going on. 39:35.330 --> 39:41.850 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:53.590 Sorry, not so much in auditing or reviews. 39:55.150 --> 40:02.830 Red teams are similar to a pen test, but it's more targeted and it usually involves more than one person. 40:02.970 --> 40:24.950 It is a team of people that are trying to get in using the techniques of a malicious person or some sort of threat actor and they're going to try to get in and access sensitive data as quietly as possible without being detected, just like the bad guys. 40:25.610 --> 40:29.350 They're going to just look to avoid being detected. 40:29.350 --> 40:38.770 They're usually there for a longer period of time than other testers and they use a variety of techniques. 40:39.050 --> 40:49.190 This could even include some physical testing to break in and to get access to things that they probably shouldn't have. 40:54.790 --> 41:01.370 The final note here is application security testing. 41:01.590 --> 41:14.670 At some hospitals, there will be some level of development and this would be the process of testing and analyzing and reporting on the security level or posture of a particular application. 41:14.750 --> 41:25.930 It's used a lot in web development, but also app development like for Apple applications. 41:26.170 --> 41:35.330 It's just an idea, a way to test and gauge the security strength of that application and then find areas that you can remediate. 41:38.790 --> 41:44.410 There are times when you're going to want to bring in outside help. 41:45.110 --> 41:58.630 You want to develop, especially if you're going to have an outside digital forensics incident response team, you're going to want to develop this relationship long before a crisis situation happens. 41:58.670 --> 42:22.070 So find out how many cases they work a year, how many of them are hospitals, get references or testimonials from past clients, find out what experience level their team is at, how many of them have worked in the health care industry, and find out if they can help with overall readiness and not just be there when things go wrong. 42:22.330 --> 42:38.070 Recently, Liz Waddell did a presentation called Help, We Need an Adult, Engaging an External IR Team that provides some great tips and you can find it online just googling the name. 42:39.510 --> 42:44.530 And here are, here's the beginning of the resources. 42:47.370 --> 42:48.510 There are 42:52.490 --> 43:02.870 CIS, so the CIS and NIST and then the open source testing manual as well as links to many articles and demos. 43:04.750 --> 43:10.110 And that is the end of our basic network security section. 43:10.110 --> 43:12.830 Moving on to the next section. 43:13.090 --> 43:22.290 So a question that comes up pretty often is how do you monitor all the devices you have in a network? 43:22.970 --> 43:36.110 And this is going to start with really seeing what you have and then figuring out how to capture that data and monitor what's going on. 43:36.550 --> 43:47.690 Obviously, we don't have the resources to go and look at every device, so you need to have a smart approach to this. 43:49.150 --> 44:02.390 We're going to touch on network discovery, logging, and setting up a strategy for 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:15.130 Some of this is going to be with network discovery. 44:15.130 --> 44:25.090 You're going to want to perform a scan to get the lay of the land and probe a network for all connected devices. 44:25.610 --> 44:41.710 Institutions are going to need to be aware that certain brands of devices or certain device models do not like being scanned, and so you're going to want to avoid doing this kind of heavy network discovery while they're in use. 44:41.710 --> 45:01.010 Or you're going to want to have that dialogue with your medical device manufacturer to see if you have some of those devices, and then perhaps take the device offline or create a strategy for managing that device while you're discovering everything else on your network. 45:01.550 --> 45:07.290 Ultimately, you cannot protect what you if you don't know it exists. 45:07.430 --> 45:24.250 And one strategy is to log as much as possible, get as detailed lay of the land as possible, and then if you find a new device that isn't in your inventory, you're going to treat it as hostile. 45:24.470 --> 45:30.270 So you're really going to want to be as thorough with discovery as possible. 45:31.230 --> 45:40.250 And in this network discovery, you're going to find some items that are immediately glaring. 45:40.250 --> 45:44.130 They're going to be operating systems or firmwares out of date. 45:44.130 --> 45:53.930 You're going to find just some simple vulnerabilities that come up, and you can remediate them along the way as you're doing your asset inventory. 45:54.370 --> 46:04.450 You're going to have to decide what's important to the organization early on, because you can't keep a log of everything. 46:04.450 --> 46:09.930 Long-term storage is expensive for this kind of monitoring. 46:09.930 --> 46:16.090 So you're going to have to prioritize what data you want to keep a track of the most. 46:22.630 --> 46:26.030 You're going to want to structure your log data. 46:26.570 --> 46:30.350 You're going to have some normalization across logs. 46:31.610 --> 46:47.810 There's a common information model that was created to solve this, and a community, an open source community, that also provides some information on this, and I have a link to that in my resources. 46:48.090 --> 47:02.690 If you're unsure of where to start, or you want some structured guidance, there are many different SIEM vendors, and so you can reach out to them and see about writing rules that support your organization devices in these cases. 47:04.250 --> 47:07.210 Don't feel pressured by these salespeople. 47:07.210 --> 47:09.890 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:24.360 Decide what you need from the logs and what you can discard. 47:25.020 --> 47:32.820 Logs are similar... logs are similar to finding the log data that's important to you. 47:32.820 --> 47:42.720 So security logs, system logs, intrusion attempts, connections, figure out what matters to you, and those are the logs you're going to need to keep. 47:42.940 --> 47:50.840 Separate logs come in handy for searching and dashboards, so you can organize your data in a way that's intuitive to you. 47:50.840 --> 47:57.260 If devices are Windows, you may be able to use the window event forwarding to push to the syslog. 47:57.640 --> 48:02.140 If you're using the Linux environment, use existing syslog. 48:02.140 --> 48:11.620 If you're pushing to a SIEM, there's lots of options, so Splunk, Security Onion, AlienVault, etc. 48:11.660 --> 48:23.760 There's paid versions, non-paid versions, obviously the open source ones are an increased level of effort, but everything is going to need fine-tuning. 48:23.760 --> 48:28.060 That is the nature of logging. 48:28.540 --> 48:52.880 So you're going to log devices to ensure communication to only trusted endpoints, log IPs and connections in and out of network, log an alert of large data transfers, you're going to want to log local devices and workstations for USB devices that are plugged in, 48:52.880 --> 49:20.800 you're going to want to log application setups to what's running on startup, you're going to want to search for malicious applications or malicious services, there are different options for inventory based on your operating system, you have a lot of variety in this space, 49:20.800 --> 49:24.180 use whatever works best for your workflow. 49:25.120 --> 49:28.060 You're going to want to correlate data sources. 49:28.320 --> 49:40.740 So you're going to use existing logs and security system events combined with local host logs to detect anything that's out of the normal, out of normal and flag it as a malicious activity. 49:40.740 --> 49:43.640 For this, you're going to need to establish a baseline . 49:43.640 --> 49:49.640 You're going to have to have a period of time where you are figuring out what is normal in your environment. 49:50.060 --> 49:56.260 And once you know what normal is, you can start to define what abnormal looks like. 49:56.360 --> 50:02.100 Your correlation only works if your logs have been normalized. 50:02.100 --> 50:15.540 So you're going to want to use identifiers that work for you as an organization, be consistent, whatever is intuitive for your group, proceduralize that and make it standard. 50:15.540 --> 50:31.520 So you, for example, if the core group in New York file server one, if you want to abbreviate just taking the first letter of every major word, if that works for you, do it. 50:31.520 --> 50:33.220 Do whatever works for you. 50:33.220 --> 50:34.640 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 --> 51:06.040 You want to label your equipment, include warnings or pertinent information, and you want to also log MAC addresses, model numbers, serial numbers, licensing keys, anything that is important, especially if something goes wrong. 51:08.230 --> 51:18.490 So you use those unique identifiers when logging so that you can easily identify in your dashboard what is going on. 51:19.190 --> 51:24.610 Utilize scripting to run searches on interesting data, send this to email for the process. 51:24.610 --> 51:27.670 You're not going to want to do this by hand, use a dashboard. 51:28.850 --> 51:32.230 Perform real-time monitoring. 51:32.230 --> 51:45.590 Again, you're not going to want to do this all by hand, you're going to want to have some dashboard, deploy automation when possible, and work with your vendor if you can. 51:45.590 --> 51:52.350 If you're using a free version, those are often supported by robust communities and reach out to the community. 51:53.390 --> 51:57.810 So things are complex to set up and administer, and I understand. 51:57.930 --> 52:01.950 Small teams have limited cycles, I understand that as well. 52:01.950 --> 52:11.290 You're going to want to take your time to really fine-tune this to work for your particular infrastructure. 52:11.410 --> 52:18.810 And utilize a SIEM, it'll tie together all the information and make network monitoring easy for your staff. 52:20.890 --> 52:29.770 So assets, bad guys, and the things we can't see are really where we have high risk. 52:29.830 --> 52:43.070 With no logging, no asset inventory, and no central logging server, no SIEM to tie everything else, you're really dealing with an issue of the lack of visibility. 52:43.750 --> 52:59.870 This is where that strategy helps, where we're tying all of that information to make a map of what you have as a network, and it's the first step in figuring out where your risk is. 53:00.630 --> 53:04.170 So here is a fun little map. 53:04.910 --> 53:08.230 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:21.070 My last topic of the day is medical device patching. 53:21.950 --> 53:30.910 This is a complex topic, but we start with, like everything else, with a strategy. 53:30.910 --> 53:33.950 Why have a patch management strategy? 53:33.950 --> 53:46.770 It avoids downtime and response efforts, it increases compliance, there's high return on investment for the effort, and ultimately increases the security posture of your organization. 53:48.330 --> 53:53.810 There's also some FDA guidance you might want to look up on the topics. 53:53.810 --> 54:04.970 Security updates are managed by the manufacturer's quality system, but they have made it easier to go ahead and push out to the customer. 54:05.150 --> 54:07.930 What is part of this process? 54:07.990 --> 54:13.630 There will be hazard analysis, formal testing, and then it'll be released. 54:14.610 --> 54:16.530 Why are patches generated? 54:16.530 --> 54:36.990 Well, sometimes it's because there's an uncontrolled risk that has an unacceptable risk to either clinical functionality or patient safety, sometimes it's just maintenance or part of good cyber hygiene, and sometimes it's that a third -party component requires a patch. 54:39.600 --> 54:43.190 There's a lot of challenges, one of them being the variety. 54:43.650 --> 54:59.070 There are hundreds of possible options for operating systems, and then when you add in the hardware and software components, there's a lot of variety in that install base. 54:59.830 --> 55:03.770 The hospital network has some complexity and risks. 55:03.770 --> 55:11.010 You have a lot of vendors, you know, we like to you only use us, but that's just not the case. 55:11.010 --> 55:22.370 There is a number of vendors, there's a number of platforms for remote access, and some devices do not have remote access available at all. 55:22.770 --> 55:26.330 Then there's the availability of a third-party patch. 55:26.330 --> 55:35.410 Just because a third-party component has a risk does not always mean that they will get us the patch in the time we manage to provide it to you. 55:35.570 --> 55:39.710 And then there's dependencies on the back end, servers and the like. 55:39.710 --> 55:44.110 There's organizational issues, so who does this device belong to? 55:44.390 --> 55:47.970 Does IT have a good relationship with the clinical team? 55:47.990 --> 56:03.710 I mean, in smaller places, the bioengineering guy and the IT guy and the IS guy are probably all the same person, but it depends on how that person deals with the clinical staff. 56:03.710 --> 56:06.570 And then what are the functionality risks? 56:06.570 --> 56:12.650 There's also regulatory and compliance concerns, what the change management process is. 56:12.910 --> 56:16.970 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:40.750 And what is impacted if things go wrong? 56:40.750 --> 56:45.090 Patient safety, care, delivery, and you have a reduced revenue. 56:45.170 --> 56:57.590 If you have to divert patients, if you have to delay diagnosis, you're going to have a reduced income. 56:58.370 --> 57:00.990 More complexities. 57:01.650 --> 57:17.610 The diversity of the medical device manufacturer, service level agreements, larger healthcare organization deliveries typically rely on automated patch management systems to coordinate the distribution and installation of patches. 57:18.410 --> 57:26.370 These agents for these programs or security agents are not generally approved for use by medical device manufacturers. 57:26.410 --> 57:38.590 Automated systems might accidentally push a patch to a non-approved 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:55.000 If they may not know that vulnerability exists, they don't have a lot of visibility into what the third-party components are of that product. 57:55.100 --> 58:02.280 Many devices can only be patched when not in use or in service for patient care and patient safety reasons. 58:02.760 --> 58:10.500 And for this, I'm saying leverage your existing preventative maintenance cycles for certain devices. 58:10.500 --> 58:19.300 But when the device is in use 24-7, that cycle might not come more quickly enough. 58:20.000 --> 58:21.760 We hear this a lot. 58:21.760 --> 58:23.700 There's a shared responsibility. 58:23.700 --> 58:45.580 Medical device manufacturers need to make a safe device or as safe as possible and give you the avenues to have safe settings, you know, control your access to your device, protect your data, respect privacy. 58:45.900 --> 58:48.700 They need to have robust security features. 58:48.700 --> 58:50.860 The device needs to be hardened and tested. 58:51.160 --> 58:54.220 We need to disclose vulnerabilities. 58:54.340 --> 59:01.660 We need to tell you what the third-party software is in the device and we need to provide patches in a timely manner. 59:01.820 --> 59:08.120 Hospitals need to deploy devices in a secure environment, which includes segregation. 59:08.120 --> 59:10.120 They need to monitor their network. 59:10.120 --> 59:16.220 They need to have an access management slash traffic control system. 59:16.280 --> 59:20.780 So that could be like physical security vulnerability analysis. 59:20.780 --> 59:23.100 They need to do security awareness training. 59:23.100 --> 59:28.180 We don't touch on security awareness training in this topic, but it is important. 59:29.640 --> 59:32.000 And you want to teach proper use. 59:32.000 --> 59:40.020 You want to have a life cycle and change management policy that includes patching and you're going to want to assess your risk. 59:42.200 --> 59:47.960 So as you may or may not tell by now, I'm pretty keen on processes. 59:48.480 --> 59:56.900 Asset management is an important part of many of the things I've mentioned, including patching. 59:57.860 --> 01:00:10.120 You're going to want to give each device a profile where you're saying you're triaging by exposure, likelihood, and impact in your risk profile. 01:00:10.340 --> 01:00:21.720 So do you have a flat network and a device that has a lot of ports open and not a lot of security controls in place for that device? 01:00:21.720 --> 01:00:24.080 Your network exposure risk is high. 01:00:24.560 --> 01:00:30.540 And then you go, you said, yeah, okay, that's high, but it doesn't actually store any PHI. 01:00:30.540 --> 01:00:35.420 It just may have a couple of values that are anonymized. 01:00:36.520 --> 01:00:39.480 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:08.890 So how do you create this profile? 01:01:08.890 --> 01:01:20.970 If it's networked, you can, as we mentioned earlier, with the discovery portion, you can collect a hostname, MAC address, IP address, wireless interfaces. 01:01:20.970 --> 01:01:23.450 You may also want to note serial number. 01:01:23.450 --> 01:01:29.290 Oftentimes that is an identifier used by service. 01:01:29.290 --> 01:01:42.450 So when there is a problem, they may use, there's a vulnerability that impacts serial numbers one through 10, or ending in one through 10, and all others are fine. 01:01:42.450 --> 01:01:47.190 Or we're rolling out a patch to these serial numbers. 01:01:47.190 --> 01:01:52.810 So you would like to note that information or communication with your device manufacturer. 01:01:54.690 --> 01:02:04.970 You're going to want to create this, part of creating this medical device security profile is the software bill of materials and your security white paper. 01:02:04.970 --> 01:02:12.150 So many, many manufacturers are now in the process of collecting this information. 01:02:12.210 --> 01:02:19.290 As you can tell, the software bill of materials is important for a variety of reasons. 01:02:19.990 --> 01:02:28.510 It's involved in vulnerability analysis, in your privacy concerns, in pretty much everything. 01:02:28.510 --> 01:02:35.350 The white paper should also tell you what your operating system is and patch level and update. 01:02:35.370 --> 01:02:40.530 They're just going to let you know if there's any middleware, any dependencies, there's often network flow diagrams. 01:02:40.530 --> 01:02:50.250 You can get an idea with the documentation that your vendors provide of what your risk is. 01:02:54.400 --> 01:03:00.000 So when you're creating your medical device security profile, you're going to want to take a look at the controls. 01:03:00.000 --> 01:03:02.780 What are the credential management options? 01:03:02.780 --> 01:03:10.440 Is there antivirus or other security technology available with the encrypt? 01:03:10.440 --> 01:03:14.880 You're going to ask what logging capabilities they have and how do they manage remote access? 01:03:14.880 --> 01:03:24.440 You're going to want to keep a copy of the MDS2 security and security white paper for every version of the device that you have in use in your environment. 01:03:24.440 --> 01:03:31.220 There is enough variety at significant releases that you will need this data. 01:03:32.120 --> 01:03:34.300 Make it part of your profile. 01:03:35.200 --> 01:03:38.640 So as I was mentioning, the network exposure. 01:03:38.640 --> 01:03:43.740 Is the device in an internet accessible network zone? 01:03:43.880 --> 01:03:46.540 Does this have dial home capabilities? 01:03:46.540 --> 01:03:48.280 Is it remote accessible? 01:03:48.280 --> 01:03:52.080 These all increase your network exposure risk. 01:03:54.290 --> 01:03:55.830 Data exposure. 01:03:55.830 --> 01:04:00.090 Does the device store PHI or PII? 01:04:00.250 --> 01:04:05.490 Is the sensitive data only stored for a small period of time or is it permanent? 01:04:05.490 --> 01:04:07.670 How many records are stored? 01:04:07.670 --> 01:04:09.130 How is it stored? 01:04:09.690 --> 01:04:13.150 These are all questions you're going to want to ask your MDM. 01:04:13.150 --> 01:04:16.050 They are your partners in this. 01:04:18.460 --> 01:04:25.140 You are also going to need to figure out how critical is this device to care? 01:04:25.280 --> 01:04:27.540 Is it life sustaining? 01:04:27.720 --> 01:04:31.180 Does this represent a single point of failure? 01:04:31.280 --> 01:04:33.920 Has the security evaluation been performed? 01:04:33.920 --> 01:04:40.620 You're allowed to ask your medical device manufacturer, hey, what security testing has been performed on this device? 01:04:41.520 --> 01:04:43.760 What did you do about it? 01:04:44.980 --> 01:04:49.940 And especially if this is critical to care, you might want to have those conversations. 01:04:53.670 --> 01:04:58.670 You're going to need to plan your patch execution safely. 01:04:58.670 --> 01:05:08.970 So if you can, if you have a test device, you're going to want to, one, receive your manufacturer's approval. 01:05:09.070 --> 01:05:13.170 Test it on a device that's not in use at all. 01:05:13.810 --> 01:05:21.970 Verify that it does 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:31.750 Use your device in use safeguards that are in your manual. 01:05:31.970 --> 01:05:37.770 Deploy and apply the patch and validate that the device is ready to return to service. 01:05:40.250 --> 01:05:46.790 So you're going to want to make sure that this is an approved patch. 01:05:46.910 --> 01:05:57.250 If you want to, for some reason, apply a patch that did not come from your manufacturer, you need to reach out to your manufacturer and have that conversation. 01:05:57.670 --> 01:06:00.350 See what your service level agreement says. 01:06:01.010 --> 01:06:08.910 Manufacturers do have a list of approved patches, so get that documentation from them and make sure you're up to date. 01:06:09.030 --> 01:06:20.750 Ensure that the patch management system can isolate authorized patches and employ, ensure that only your authorized and approved patches are deployed on the device. 01:06:25.050 --> 01:06:27.250 Here's some considerations. 01:06:27.530 --> 01:06:31.010 You're going to want to see what your change management policy says. 01:06:31.210 --> 01:06:34.490 Schedule the patch during the prevent and maintenance cycle. 01:06:34.490 --> 01:06:36.350 I can't stress that enough. 01:06:36.350 --> 01:06:38.930 Please do not use a device that's in use. 01:06:39.510 --> 01:06:50.070 Should, by any accident that happens, you know, you don't want to take a device offline that a patient is using. 01:06:50.850 --> 01:06:55.150 When impossible, employ device in use safeguards. 01:06:55.230 --> 01:06:56.730 The two-man rule. 01:06:56.750 --> 01:06:59.750 So, hey, I'm going to patch this MRI machine. 01:06:59.770 --> 01:07:00.710 Can you see it? 01:07:00.710 --> 01:07:05.070 Can you verify that this is actually empty and not in use? 01:07:05.070 --> 01:07:08.690 Because we have it on the schedule that it's not in use today. 01:07:08.710 --> 01:07:13.950 Yes, I'm looking at it, there's nobody in it, and there's no plan to use it today. 01:07:14.330 --> 01:07:20.530 You're going to want to isolate the medical device on a maintenance VLAN and then deploy. 01:07:20.990 --> 01:07:25.010 When everything is back up and running, return it to service. 01:07:26.010 --> 01:07:28.910 So, that is our patch planning. 01:07:28.910 --> 01:07:46.670 I know it's a little more involved than your automated patch deployment that you can do with your workstations and servers, but because these devices are so important to clinical workflow, we need to put in this effort. 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:07:59.190 So, thank you, Helen, for that great overview on a number of topics. 01:07:59.190 --> 01:08:02.430 We only have two more modules left that should be pretty quick. 01:08:02.430 --> 01:08:08.690 We have physical security, and then we're going to cover third-party risk assessments and communication. 01:08:08.990 --> 01:08:11.470 So, we'll jump right into physical security. 01:08:11.470 --> 01:08:14.550 So, why is physical security in healthcare important? 01:08:14.550 --> 01:08:21.850 Well, if we're trying to protect PHI, you know, physical security is certainly one thing that we definitely want to consider. 01:08:21.850 --> 01:08:32.970 If you can't block physical access to the hospital, individuals can come in and potentially get access to data either on a device or something of that nature. 01:08:33.810 --> 01:08:49.350 So, we'll quickly look a little bit at hospital physical security studies that have been done and kind of understand, again, try to lay that foundation of what the current threat landscape is. 01:08:49.450 --> 01:08:59.250 So, of a survey that was done in 2018 for physical security in hospitals, 34% of hospitals did report some incidents of trespassing that year. 01:08:59.250 --> 01:09:01.450 That was up from two years prior. 01:09:01.610 --> 01:09:06.930 And only 42% of hospitals did report having a visitor management system. 01:09:06.930 --> 01:09:19.630 Now, when I say a visitor management system, what the study defined as a visitor management system did require a visitor to both sign in, have a photo ID, and a visible badge while walking around. 01:09:19.630 --> 01:09:27.010 So, if a hospital had two of those but not three, they didn't technically meet the criteria for visitor management systems. 01:09:27.010 --> 01:09:31.290 So, that 42% is of the reporting hospitals that had all three. 01:09:31.410 --> 01:09:42.110 And 20% of hospitals actually had some sort of physical man-trap that stopped individuals from coming in physically before entering the rest of the hospital. 01:09:43.530 --> 01:09:45.210 So, what do we want to restrict? 01:09:45.210 --> 01:09:46.450 Obviously, physical access. 01:09:46.450 --> 01:09:48.630 We're talking about physical access to hospital. 01:09:49.090 --> 01:09:56.270 But again, if we go back to that first slide deck that we had, we're not just talking about visitors, but we also want to consider staff. 01:09:56.270 --> 01:10:04.590 You know, is there certain areas that staff don't need to be in, or do we just give them access kind of carte blanche to all areas of the hospital? 01:10:04.590 --> 01:10:06.710 So, we certainly want to consider that. 01:10:07.490 --> 01:10:14.930 And, you know, definitely 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:22.270 Physical security plan evolution. 01:10:22.270 --> 01:10:41.190 So, obviously, your physical security plan for your hospital wants to evolve, not just with big events like we saw after 9-11, where a number of new doors and walls and things like that certainly were installed to restrict certain areas. 01:10:41.190 --> 01:10:45.670 But, you know, we want it to continuously evolve as the threat landscape evolves. 01:10:47.010 --> 01:10:48.990 This was a great study. 01:10:48.990 --> 01:10:51.370 This was by Marlee McKee. 01:10:51.370 --> 01:10:54.010 Not really a study, but Marlee McKee. 01:10:54.010 --> 01:11:03.130 She has, interestingly enough, a couple million followers, and she is self-identified as America's modern manners and etiquette expert. 01:11:03.270 --> 01:11:09.610 And she claims that opening the door at work was her number two for America's top five manners. 01:11:09.610 --> 01:11:11.710 So, these are things that people should do. 01:11:12.210 --> 01:11:16.750 Obviously, those of us that work in security realize that this is really not good. 01:11:17.630 --> 01:11:19.330 But it is, you know, prevalent. 01:11:19.330 --> 01:11:23.810 Door holding, at least in a number of cultures, is prevalent. 01:11:23.810 --> 01:11:28.490 So, we need to kind of look at that and factor that into our physical security plans. 01:11:29.050 --> 01:11:32.810 This was a study that was done by the University of Omaha. 01:11:32.810 --> 01:11:34.210 It was fairly interesting. 01:11:34.210 --> 01:11:42.850 There was about 1,500 students that were assessed to see if they would basically hold the door if someone walked up behind them. 01:11:42.910 --> 01:11:50.530 Two-thirds of the individuals, if there was someone that immediately tailgated them as they were coming in the door, they would open the door and leave it open. 01:11:50.850 --> 01:12:01.410 There really wasn't any gender difference for that category, but it was interesting that the latter two, significant gender difference. 01:12:01.790 --> 01:12:14.990 Females reported seriously significantly lower for both glancing back and seeing if someone was coming and standing there and holding the door and then holding the door open for a significant amount of time. 01:12:14.990 --> 01:12:21.310 So, didn't really go into why there was that difference with genders. 01:12:21.310 --> 01:12:32.350 But, you know, if you're incorporating this into your incorporating door holding into your physical security plan, it might be something that you might want to look at that study and dive a little bit deeper into. 01:12:32.410 --> 01:12:40.810 Maybe those gender differences are something that you could leverage to make your facility more secure, if you can understand kind of why that's happening. 01:12:42.310 --> 01:12:44.910 We're certainly not going to reinvent the wheel. 01:12:44.910 --> 01:12:47.390 This is a, you know, less than a two hour training. 01:12:47.390 --> 01:12:57.970 So, if you want to see some great physical security training, I definitely recommend Jason Street's DEF CON talk on physical security. 01:12:57.970 --> 01:13:04.570 It goes over a number of different physical security penetration tests that he's done and how easy it is to gain access. 01:13:04.830 --> 01:13:10.070 So, you know, again, this is just this is the very short abbreviated version that's specific to hospitals. 01:13:10.070 --> 01:13:14.650 So, if you want more, I would definitely look at that. 01:13:15.630 --> 01:13:17.730 So, why is any of this important? 01:13:17.730 --> 01:13:22.430 Physical security or at a, you know, cyber security or hacking conference? 01:13:22.430 --> 01:13:24.550 Why is physical security important? 01:13:25.190 --> 01:13:31.570 Well, manufacturers, so medical device manufacturers, make certain assumptions when they create a medical device. 01:13:31.570 --> 01:13:39.350 They assume, as Helen was talking in some of her past presentations, that they assume that a device is going into a secure environment. 01:13:39.350 --> 01:13:40.630 And that's not always the case. 01:13:40.630 --> 01:13:42.090 It's certainly going to vary. 01:13:42.090 --> 01:13:52.270 If it's maybe a large, you know, CT device that they might make assumptions that that's going to be in a secure facility or maybe in a secure laboratory, certain devices. 01:13:52.310 --> 01:14:04.990 But, you know, it is understood there's certain smaller, like, point of care devices that can be physically picked up and carried around or, you know, might be in a ER setting or even in a home setting are obviously gonna have less physical security. 01:14:04.990 --> 01:14:14.910 But you just want to kind of be aware of what physical security assumptions, you know, your medical device manufacturers are assuming. 01:14:14.910 --> 01:14:15.470 Yeah. 01:14:15.650 --> 01:14:17.890 So, testing those assumptions. 01:14:18.270 --> 01:14:28.350 While I was creating this training, I had the unfortunate but fruitful experience of having an individual that was close to me be admitted to a hospital. 01:14:28.350 --> 01:14:44.910 They were first admitted to a local, like, 25-bed critical access hospital, regional hospital, then moved to a larger university hospital, and then in a number of, like, physical rehab facilities. 01:14:44.910 --> 01:14:55.550 So I was able to kind of, you know, visit regularly and observe different situations that were happening with kind of the eye of being a, you know, an occasional medical device penetration tester. 01:14:55.550 --> 01:15:04.950 So I've never done actual hospital penetration testing, though I have some colleagues that have, and I've included some of their insights, but this is kind of what I've noticed. 01:15:05.670 --> 01:15:18.490 So the hospitals that I did visit, they did not check my ID, which was interesting because I could have very easily just provided a name of any patient that was in the hospital at the time and be given access. 01:15:19.230 --> 01:15:32.610 And I actually tested this out, it's kind of an interesting OSINT experiment, but if you go to Facebook and just kind of do a search for, you know, hospital, in probably 30 minutes or less, you're going to be able to find a name of a patient, you know, 01:15:32.610 --> 01:15:46.490 whether it's a friend, distant colleague, whatever, that's currently, you know, in a hospital, maybe social media posts that says, you know, this could be Facebook or any social media post, hey, I had a spill, I'm in a hospital, this is a hospital, come visit me. 01:15:46.750 --> 01:15:58.930 We now know that individual's in that hospital, and a good number of hospitals, you can simply go there, provide their name, maybe provide a fake name, because they're not actually checking your ID, and be given physical access to the hospital. 01:16:00.610 --> 01:16:14.290 Once you're inside, at least I found in the hospitals that I was in, I pretty much had access to go anywhere in the hospital, which with some restrictions, and there were signs that basically told me kind of wherever I wanted to go. 01:16:14.290 --> 01:16:24.850 So, if I was a, you know, nefarious actor, and I wanted to get access to the server room, it clearly showed on the map exactly where that was, and it said on the door, you know, exactly where that was. 01:16:28.970 --> 01:16:30.230 Yeah, keep going. 01:16:30.470 --> 01:16:33.450 I was going to mention one more thing, but I'll mention it at the end. 01:16:33.510 --> 01:16:45.110 At the patient's bedside, there was obviously anyone that's ever visited someone in a hospital, you know, especially if it's a critical case, you know, that patient is surrounded by a number of different medical devices. 01:16:45.490 --> 01:16:54.290 Many of those devices, such as a cow or computer on wheels, which is where the nurse or the clinical staff would sit down and do their documentation. 01:16:54.410 --> 01:16:59.790 So, they would do their vital signs, ask the patient all their questions, then go to this computer to write notes. 01:17:00.830 --> 01:17:12.590 Typically, for what I've seen, most of these were not locked down, at least in the hospital that I was in, and I've installed medical software in a previous role, and that's certainly not the case. 01:17:12.590 --> 01:17:22.330 A number of hospitals do lock down all their computer on cows, computer on wheels, and have a certain timeout to be able to lock that out of, you know, inactivity. 01:17:22.650 --> 01:17:25.470 But in this case, you know, the devices were open. 01:17:25.530 --> 01:17:29.010 That's not a picture of a device, that's just one that I took off the web. 01:17:29.810 --> 01:17:45.190 And there was a number of other medical devices at the bedside that, you know, had USB ports that, you know, if you look at the device and Google it, you can probably identify that it doesn't restrict any type of traffic. 01:17:45.190 --> 01:17:51.850 So, if you had a rubber ducky, things like that, you know, I might be able to either extract data out of the device or potentially run a script on it. 01:17:51.850 --> 01:18:00.330 So, there's a lot of things you can do once you get physical access that, you know, we often think, well, if someone's in the hospital, they're hurt, they need to be there. 01:18:00.330 --> 01:18:07.030 But, you know, nefarious people get hurt too and end up in hospitals or visit family members or friends that are in hospitals. 01:18:07.030 --> 01:18:09.590 So, it's kind of something to consider. 01:18:10.570 --> 01:18:25.350 One thing that I found interesting, so, like I said, I've done some, like, a very small amount of penetration testing for medical devices, but I have a colleague that does actual hospital penetration tests. 01:18:25.410 --> 01:18:30.430 And he says that, you know, with a mop and a bucket, there's essentially nowhere in the hospital that he can't go. 01:18:30.690 --> 01:18:45.170 Anytime he's done a physical penetration test or just a penetration test in general, you know, he always, this is what he does for every hospital he's gone into, he dresses up like a janitor and they generally give him access to anywhere he wants to go, 01:18:45.170 --> 01:18:48.410 including secure facilities or secure areas of the hospital. 01:18:48.410 --> 01:18:55.910 So, if you're looking to do physical penetration testing at a hospital, that's probably a good plan. 01:18:57.850 --> 01:19:11.150 So, health, there was a great talk a couple years ago at one of the Health ISAC summits that specifically looked at printers as kind of, you know, having a lot, basically being chock-full of PHI. 01:19:11.150 --> 01:19:12.910 So, they typically have a lot of records. 01:19:12.910 --> 01:19:27.870 You can do print last 10, you know, especially if this is a discharge printer where, you know, if you go to the hospital, you get discharged, you go sit in front of a nurse, she prints out your, you know, 15, 20, 50 page, whatever medical record, gives it to you, 01:19:27.870 --> 01:19:29.070 and then you go out the door. 01:19:29.070 --> 01:19:33.370 So, that printer is like chock-full of records. 01:19:33.370 --> 01:19:38.610 It's probably right next to an exit door, and it may or may not require authentication. 01:19:38.670 --> 01:19:40.710 So, just something to kind of think of. 01:19:40.810 --> 01:19:47.370 Printers often get overlooked, but it might have just as much, if not more, PHI than an actual medical device. 01:19:48.890 --> 01:19:50.530 Access in the waiting room. 01:19:50.950 --> 01:19:59.670 This was, you know, often we think of, okay, we have to actually get in the building to be able to find a network jack or to be able to get some sort of, you know, access that we need. 01:19:59.750 --> 01:20:12.350 But Helen, if she's still on the line, had a great story of one of her friends that was doing a penetration test for a hospital and found network access right from the lobby. 01:20:12.350 --> 01:20:13.790 I don't know if she's still on. 01:20:14.890 --> 01:20:16.010 I am. 01:20:16.010 --> 01:20:19.150 So, we met up before his test. 01:20:19.150 --> 01:20:20.730 This was his first, like, hospital test. 01:20:20.730 --> 01:20:25.290 And he goes, I imagine hospitals are like a fortress. 01:20:25.650 --> 01:20:26.890 Like, oh, no, dear. 01:20:27.550 --> 01:20:29.230 They are not. 01:20:30.370 --> 01:20:33.130 And he's like, no, no, you're kidding me. 01:20:33.130 --> 01:20:35.010 And I'm like, yeah, they're pretty bad. 01:20:35.010 --> 01:20:37.650 I would totally expect a flat network. 01:20:38.210 --> 01:20:45.570 So, he has a plan to say that he is, you know, waiting for a patient. 01:20:46.190 --> 01:20:47.570 And he doesn't even need it. 01:20:47.570 --> 01:20:48.710 Nobody asks him. 01:20:48.710 --> 01:20:50.810 So, he just sits down with his laptop. 01:20:50.950 --> 01:20:56.330 And there's a network connection there. 01:20:56.330 --> 01:20:58.610 And he's like, it can't be this easy. 01:20:58.610 --> 01:21:01.890 Sure enough, it was live. 01:21:03.730 --> 01:21:08.370 So, definitely interesting as far as the initial gaining of access. 01:21:10.990 --> 01:21:13.790 Emergency waiting rooms are full of people. 01:21:14.430 --> 01:21:18.430 And they aren't necessarily highly monitored as well as lobbies. 01:21:18.430 --> 01:21:20.410 Lobbies don't always have receptionists. 01:21:21.150 --> 01:21:21.810 Yeah. 01:21:22.110 --> 01:21:22.650 Great. 01:21:22.650 --> 01:21:24.330 Well, thank you for that story, Helen. 01:21:24.930 --> 01:21:27.030 So, what can be done about this? 01:21:27.030 --> 01:21:29.850 Obviously, it could require IDs for all visitors. 01:21:29.970 --> 01:21:34.130 So, when they're entering a facility, it requires some visible badge. 01:21:34.130 --> 01:21:35.590 And it could just be a sticker. 01:21:36.070 --> 01:21:39.370 It's certainly helpful if that visible badge actually says where they're going. 01:21:39.370 --> 01:21:43.950 So, that, you know, if they're in an area where they're not supposed to be, it's clearly visible. 01:21:44.650 --> 01:21:49.230 Restricting physical access to only areas that these individuals should be. 01:21:49.230 --> 01:21:52.050 I mean, I've certainly been lost a number of times in hospitals. 01:21:52.050 --> 01:21:55.670 Just, you know, you go in and then you just have access to everywhere. 01:21:55.670 --> 01:21:57.610 They're so big, you get lost. 01:21:58.770 --> 01:22:03.550 You know, if you could actually have individuals kind of guide people to where they're supposed to be going to. 01:22:03.550 --> 01:22:06.710 And in a large hospital, that's obviously never going to happen. 01:22:06.710 --> 01:22:09.070 It's just too large and there's too many visitors. 01:22:09.330 --> 01:22:20.930 But I have seen it work pretty well, again, in like a Midwest, like small critical access, 25-bed hospital, where they have a number of volunteers where they're just, you know, looking for something to do and help out. 01:22:20.930 --> 01:22:30.130 And, you know, I've been surprised to show up at those hospitals to install software and, you know, had a person that actually brought me from the door to right where I needed to be. 01:22:30.130 --> 01:22:41.230 So if you're one of those small hospitals and you're looking for something for volunteers to do, that might be a good thing that they can do to, you know, be friendly with visitors, but also help increase your security posture. 01:22:42.350 --> 01:22:43.930 Train staff on tailgating. 01:22:43.930 --> 01:22:48.930 And again, leveraging those, you know, if you can leverage the differences and understand kind of why that's happening. 01:22:49.390 --> 01:22:51.750 You can lock all devices when they're not in use. 01:22:51.810 --> 01:22:54.250 Require authentication on printers is good. 01:22:54.870 --> 01:23:01.410 And, you know, when we're locking devices too, that's obviously, you know, that's going to be a process. 01:23:01.410 --> 01:23:05.870 You're probably looking at, like, hospitals that do it well are doing like a tap and go system. 01:23:05.870 --> 01:23:12.050 So you just, you know, I have my card on a lanyard and I'm just tapping it on each device that I have access to. 01:23:12.410 --> 01:23:14.570 And that's going to look different across your hospital. 01:23:14.570 --> 01:23:20.490 Certainly in the ER, there's a little bit more risk because you have, you know, people coming into the ER constantly. 01:23:20.490 --> 01:23:26.390 You're certainly a guest of people that are there or patients. 01:23:26.450 --> 01:23:29.470 But, you know, in an ER, like, seconds count. 01:23:29.470 --> 01:23:41.510 So it's understandable that there's going to be less restrictions in that setting where, you know, having to have a doctor stop and actually log into a system is certainly going to slow down and it could adversely affect patient outcomes. 01:23:41.510 --> 01:23:48.990 But, you know, if you can do like a tap and go system or something that is efficient, you know, anything you can lock down, certainly the better. 01:23:49.470 --> 01:23:57.630 But again, do it, you know, do it in a way that is useful. 01:23:58.150 --> 01:24:19.230 Again, going back to that application support staff that I was at a hospital, if, you know, you're not, if your staff's not getting paid over the weekend to be on call and they regularly get calls at 11 at night during shift change, you're basically incentivizing them to open access up more than it should be so that they don't get that call. 01:24:19.230 --> 01:24:22.010 So definitely try to avoid that. 01:24:22.610 --> 01:24:27.610 And, you know, either asking manufacturers to, you know, filter traffic. 01:24:27.610 --> 01:24:45.390 So doing that in your assessments on devices to see if that's an option or physically blocking a USB port, because certainly it wouldn't be the first infusion pump that was plugged into a patient that, you know, crashed when it was actually infusing something into a patient because someone plugged a USB, 01:24:45.390 --> 01:24:52.090 you know, whether it's something malicious or just a phone charger, certainly if it has a USB port, someone's going to eventually try to charge your phone with it. 01:24:52.090 --> 01:24:54.010 So just kind of be aware of that. 01:24:55.910 --> 01:25:06.630 Some other things just to kind of, you know, go with the win-win philosophy, you know, locking down access to a hospital not only protects PHI, but it also protects your employees and patients. 01:25:07.410 --> 01:25:11.150 You know, hospitals are places where injured people go. 01:25:11.150 --> 01:25:12.130 That's fairly obvious. 01:25:12.130 --> 01:25:25.650 But, you know, the reason that they're injured or sick might just be because they're sick, or it might be because they were in some violent altercation where, you know, the assailant is now, you know, going to come back to try to do the job, to finish the job. 01:25:26.110 --> 01:25:33.510 And we've seen an increase from 2017 in actual violence against, specifically against staff for in U.S. 01:25:33.510 --> 01:25:34.450 hospitals. 01:25:34.750 --> 01:25:41.250 It's up 57% in the emergency department and 52% increase outside of the ED. 01:25:41.250 --> 01:25:51.030 So certainly increasing physical security in your hospital, again, not only helps protect PHI, but also helps protect your staff and your patients. 01:25:51.810 --> 01:25:53.190 So thank you for that. 01:25:53.190 --> 01:25:59.810 And we have one last module coming up on vetting third parties and talking about communication. 01:26:00.030 --> 01:26:04.410 Alright, so thanks everyone for sticking with us for the previous five modules. 01:26:04.410 --> 01:26:05.990 This is our last module. 01:26:06.590 --> 01:26:10.630 And this is on third party communication and risk assessments. 01:26:10.630 --> 01:26:28.530 So this is all about how if you are a hospital, and you're wondering how you gather all the information that you need from a maybe a medical device manufacturer, a third party, and incorporate that into some risk calculation to make decisions, purchasing decisions based on or security decisions of, 01:26:28.530 --> 01:26:33.750 you know, what do I do for this device to secure down my network, this would be the module for you. 01:26:34.730 --> 01:26:38.650 So, you know, again, just to try to set some stats and some groundwork. 01:26:38.890 --> 01:26:47.530 If you're wondering how many hospitals are actually if you're a hospital that's maybe not doing these third party risk assessments, but you're wondering what percentage of them do. 01:26:48.030 --> 01:27:01.770 Back to the 2017 HIMSS study, and this is a little bit dated, so it's probably even more so now, but 88% of medical facilities are conducting cybersecurity risk assessments on third party products, so medical devices and other products. 01:27:02.010 --> 01:27:05.550 And 38% of medical facilities are pen testing equipment. 01:27:05.550 --> 01:27:20.130 So if you're a medical device manufacturer, and you're not pen testing your equipment, certainly be aware that your customers most likely are pen testing, or maybe at least going to ask you and inquire about if you know if you are pen testing. 01:27:22.230 --> 01:27:44.770 So the Ponemon study back in 2019, just looking at basically how much hospitals actually spend on this on risk management, and HDO or health delivery organization, just a kind of a big word for a large hospital organization, on average spends about $3.8 million a year on third party vendor risk management. 01:27:44.770 --> 01:27:46.090 And you know, why do they do that? 01:27:46.090 --> 01:27:50.990 Well, juxtapose that with the average cost of a data breach is about $2.9 million. 01:27:52.230 --> 01:28:02.650 And if you look at the just the vast number of vendors that HDOs have under contract, it's over 1300, which is just unfathomable that they're managing that. 01:28:03.550 --> 01:28:14.030 Why they tend to do a really good job assessing all of those third parties initially when they're first looking at them, less than 30% are actually annually reassessed. 01:28:14.030 --> 01:28:26.690 So, you know, it's a big lift and a good amount of work to get them assessed initially, but we're not really looking at them relooking at these technologies a year, two years, five years after they're in the door. 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:35.870 What do hospitals typically typically do? 01:28:35.870 --> 01:28:43.310 Well, again, looking at that same same study, about 21% of the time, the assessment gap leads to the manufacturer remediating it. 01:28:43.330 --> 01:28:50.450 So the customer says, Hey, we, we did a risk assessment, we found this, we're not gonna be able to purchase the product, unless something happens. 01:28:50.450 --> 01:28:54.650 21% of the time, the manufacturer does something to fix that or address it. 01:28:54.890 --> 01:29:01.370 33% of the time, the HDO, or health delivery organization mitigates the gap themselves. 01:29:01.430 --> 01:29:14.530 So it might be, you know, cordoning off that device on its own segments of the network, maybe a separate VLAN, or some other security, security technique to be able to reduce that risk. 01:29:14.550 --> 01:29:20.050 And 28% of the time, medical device manufacturers should be certainly aware of this. 01:29:20.050 --> 01:29:28.310 28% of the time, HDOs just terminate the agreement and say this doesn't, this device does not meet our basic security requirements, so we cannot purchase it. 01:29:28.310 --> 01:29:32.410 So that is definitely happening in the hospital sector currently. 01:29:33.430 --> 01:29:34.630 Why are we doing this? 01:29:34.630 --> 01:29:35.570 What is the risk? 01:29:35.570 --> 01:29:44.870 About 20% of healthcare data breaches are caused by third-party vendors, either by, you know, the vendor or, you know, somehow associated to that vendor. 01:29:45.990 --> 01:29:47.930 What is the cost and labor? 01:29:47.930 --> 01:29:58.950 You know, again, this course kind of focuses on smaller hospitals, but those larger, bigger HDOs, health delivery organizations, how much time are they spending assessing this risk? 01:29:58.950 --> 01:30:14.030 Well, the average hospital or HDO has about 3.21, so that's obviously a percentage, but over three employees on average solely dedicated to just assessing third-party risk. 01:30:14.030 --> 01:30:30.050 And if you do the math on that, that's about 513 hours a month that HDOs are dedicating just specifically to looking at third-party risk of vendors that they're going to partner with or vendors that have devices that they're considering purchasing. 01:30:30.950 --> 01:30:32.770 So can you automate this process? 01:30:32.910 --> 01:30:33.870 Certainly you can. 01:30:33.870 --> 01:30:37.690 About a third of HDOs do use some sort of tool to automate this process. 01:30:38.490 --> 01:30:41.390 There's a number of tools on the right-hand side that you can see. 01:30:41.390 --> 01:30:44.250 Obviously, a pretty broad distribution. 01:30:44.750 --> 01:30:54.870 We're not going to vouch for any one, but, you know, if you have that question, maybe it's a good question for the panel afterwards for the HDOs to see what they're currently using. 01:30:56.370 --> 01:31:03.030 You know, if you're going to do this assessment, you should then have some baseline security standard that you're going to measure it against. 01:31:03.030 --> 01:31:05.930 The Mayo Clinic has what they call a gold standard. 01:31:05.970 --> 01:31:08.510 It's a list of 77 different requirements. 01:31:08.510 --> 01:31:22.590 Most of those requirements went into the new MDS2 or the new document that basically lays out security features that we'll talk about a little bit later. 01:31:23.730 --> 01:31:31.890 And Mayo has presented this at a number of different conferences, so you can probably find a little bit more information from searching that. 01:31:34.750 --> 01:31:49.050 And what that allows you to do, it allows you to... actually, some of the features, I should say, in that 77 where every device is easily patchable, every device receives timely updates, and, you know, certainly a number of other facets. 01:31:49.230 --> 01:31:56.670 And what this allows you to do is focus on the high-priority devices, so the devices that have a high risk score, a potential for high risk. 01:31:57.070 --> 01:32:01.230 And also what you want to look at, too, is assess the whole family of devices. 01:32:01.370 --> 01:32:19.550 If you're purchasing, say, five different point-of-care devices that are all different, and the risk may be low for each of those devices, but all of those devices, you know, send unencrypted traffic to a middleware application, you know, you want to look at that whole family of devices and not miss something, 01:32:19.550 --> 01:32:25.530 kind of understanding that, you know, the sum of all the parts and just looking at the devices individually. 01:32:26.190 --> 01:32:34.550 So communication, we'll talk a little bit about communication and how HDOs and their third parties actually communicate some of this information. 01:32:34.570 --> 01:32:40.330 So we talked about the MDS-2, which is short for Medical Disclosure Statement for Medical Device Security. 01:32:40.390 --> 01:32:47.310 This is a standard form when a medical device goes for FDA approval, 510k approval, this is part of it. 01:32:47.310 --> 01:32:56.030 So if you ask, any medical device manufacturer should be able to give you an MDS-2 for their product, depending on when that product came out, it might be a different version. 01:32:56.030 --> 01:33:08.750 The latest version I was talking about that Mayo has their 77 requirements, most of them incorporated into, came out in 2019, I think it was November or December, so that's the latest update. 01:33:10.030 --> 01:33:12.750 So the MDS-2 is a good place to get information. 01:33:12.790 --> 01:33:22.890 Security white paper as well, a number of medical device manufacturers create security white papers that offer a lot more information above and beyond what's in the MDS-2. 01:33:23.270 --> 01:33:40.250 And some of that information, so you might have a full software bill of material, includes information like which ports and services are running, which ports are open and which services are running on the device, specifically what sensitive data elements are stored or transmitted on the device. 01:33:40.250 --> 01:33:46.560 Probably give you a network diagram of how the is meant to kind of live in your network, so you can see that. 01:33:47.040 --> 01:33:59.140 It'll talk about authentication, malware protection, security testing, if security testing has been completed, so if the device has gone through a rigorous secure development process, there should be notes on that. 01:34:00.540 --> 01:34:11.680 The intended operating environment is important, because that's, again, going back to those manufacturer assumptions, this is what the manufacturer assumes, or where the manufacturer assumes that the device is going to live in. 01:34:11.680 --> 01:34:16.820 So they assume that there's going to be network segmentation, and a firewall, and a number of other things. 01:34:17.780 --> 01:34:34.060 So it's good to certainly look at that, because that will, that will, you'll be able to see the recommendations of how you should secure this device, and network controls, physical controls, logging, how the manufacturer may remotely connect to the device for service, 01:34:34.060 --> 01:34:37.740 and whether you want that or not, you can turn it on or off, likely. 01:34:37.780 --> 01:34:46.640 Any administrative controls, how to contact both service, and then maybe the, for a cybersecurity issue, how to look for that too. 01:34:46.640 --> 01:34:52.180 If the device has any certifications, like ISO 27001, things like that. 01:34:54.930 --> 01:34:58.190 So how do HDOs acquire this information? 01:34:58.190 --> 01:35:00.370 It's pretty common. 01:35:00.470 --> 01:35:08.970 What they're largely doing is sending us security questionnaires, and most medical device manufacturers are receiving hundreds of these from U.S. 01:35:08.970 --> 01:35:10.470 customers each year. 01:35:10.750 --> 01:35:14.330 They're extremely lengthy, extremely detailed questions. 01:35:14.650 --> 01:35:27.310 If you are tasked with creating one of these, if you can, you know, try to create one in a good format that allows manufacturers to just kind of go through and check off, or uncheck things that aren't applicable. 01:35:27.310 --> 01:35:41.170 So if it's, you know, not a cloud product, you can click no, not a cloud product, and it automatically fills in NA to the next 150 questions, and the manufacturer doesn't have to click NA and then put in a comment for each as to why it's not applicable, 01:35:41.170 --> 01:35:42.770 that would be great. 01:35:43.790 --> 01:35:47.950 Just some sample questions, you know, pretty standard, you know. 01:35:49.390 --> 01:35:51.110 How do you get this information? 01:35:51.110 --> 01:36:08.410 Again, I can only imagine on the HDO side if you have 1300 different, you know, third parties trying to, even if each manufacturer has their own information portal where all of the MDS-2s and security white papers and SBOMs are in that one centralized location, 01:36:08.410 --> 01:36:12.210 you still have to go to 1300 different portals to get that information. 01:36:12.390 --> 01:36:24.930 There's been some industry attempts to try to have all of that information centralized to one place, but those haven't, those have either faltered or have haven't really caught on. 01:36:25.130 --> 01:36:34.810 So maybe we'll get there eventually, but in the meantime, you can at least, for a good amount of manufacturers, go to one place and get all of the information that you need. 01:36:35.330 --> 01:36:45.390 You know, as I said, SBOM, MDS-2, white papers, installation guide, you know, any other information, hopefully in that one place to make it a little easier for you. 01:36:47.330 --> 01:36:53.190 Business Associate Agreement, or BAA, this came from the HIPAA Omnibus Rule. 01:36:53.190 --> 01:37:04.410 So this is, you know, basically the requirement or the agreement between the medical device manufacturer or third party that's handling secure data. 01:37:04.810 --> 01:37:10.670 So the third party agreement with the health delivery organization. 01:37:10.670 --> 01:37:29.490 One thing to kind of note of that is this last line, that if you are working with a third party that's offshore or outside of the U.S., the Office of Civil Rights, or OCR, so the group that's tasked with enforcing this, probably doesn't have jurisdiction. 01:37:29.490 --> 01:37:31.510 So just kind of something to consider. 01:37:32.790 --> 01:37:37.050 And if you Google BAA example, there's a number of examples that you can see. 01:37:37.510 --> 01:37:43.750 You know, your legal department is probably going to create this, but just, you know, there are examples. 01:37:44.610 --> 01:37:48.850 ISA, so this would be more if you're actually handling the customer's data. 01:37:49.070 --> 01:37:51.310 So, you know, typically it would have an ISA. 01:37:51.310 --> 01:38:03.170 And again, there's, we could spend a whole class on just creating BAAs and ISAs, but it basically just sets out the minimum expectations for securely hosting someone else's data and follows the framework. 01:38:04.550 --> 01:38:06.250 Security Testing Considerations. 01:38:06.470 --> 01:38:14.890 This has come up a little bit, but, you know, earlier in the class, but we just have to assume that these hospitals are pen testing devices. 01:38:14.890 --> 01:38:24.190 If you're a medical device manufacturer, it is a good practice to reach out to the manufacturer before you do the test and just ask, hey, is there any considerations that I might need to know? 01:38:24.390 --> 01:38:27.170 Is there anything that if I do, it's going to break the device? 01:38:27.270 --> 01:38:30.950 As Helen said a few times, obviously you don't want to test in a live environment. 01:38:31.310 --> 01:38:45.350 You want to test in a test environment and kind of need to be aware that, you know, there could be adverse reactions to pen testing, but certainly, you know, it is a good thing to do, but just, you know, have that open dialogue with the manufacturer so that, 01:38:45.350 --> 01:38:49.570 you know, you can have the best result of that pen test as possible and share the findings, too. 01:38:49.570 --> 01:38:56.250 You know, certainly medical device manufacturers want to know if there's any, you know, issues that they could potentially fix. 01:38:57.130 --> 01:38:57.770 So, thanks. 01:38:57.770 --> 01:38:59.730 That is the class. 01:38:59.730 --> 01:39:17.010 We do have a little bit extra, so that's all the content, but again, as this class, the focus is, you know, that one or two, so either IT or cybersecurity person working in a small hospital, this was, we tried to cram everything into an hour and a half, 01:39:17.010 --> 01:39:22.550 you know, two hours, and here's a little bit more information on, you know, where do I go next? 01:39:22.550 --> 01:39:23.710 How do I keep learning? 01:39:23.710 --> 01:39:26.210 How do I, you know, stay current? 01:39:26.210 --> 01:39:27.030 Things like that. 01:39:27.030 --> 01:39:37.590 So, if you're that, again, that one person that doesn't really, that wants to stay engaged, wants to learn more, wants to get certifications, things like that, stay involved in the security community. 01:39:38.050 --> 01:39:44.730 If you're watching this live at DEF CON, you're probably already engaged, but if you're watching this on YouTube after the fact, you're, you may not be. 01:39:44.730 --> 01:39:48.890 So, obviously, there's traditional coursework out there. 01:39:48.950 --> 01:39:56.030 There's a number of different places or organizations, universities that you can take cybersecurity training in. 01:39:56.050 --> 01:40:00.150 There's not a lot that do specifically healthcare and cybersecurity. 01:40:00.250 --> 01:40:05.970 Salve, Virginia University does have a graduate class on healthcare administration and cybersecurity. 01:40:06.350 --> 01:40:13.550 So, it's the only university that I know that has numerous classes in cybersecurity and healthcare, and are kind of pairing the two together. 01:40:13.910 --> 01:40:22.630 There's also the University of Houston may have an executive program on it, and Coursera has a class on cybersecurity and healthcare, too. 01:40:22.650 --> 01:40:27.530 But there's not too many... I hear that Salve also has some really cool professors in this sector. 01:40:27.970 --> 01:40:29.030 They may. 01:40:29.170 --> 01:40:44.170 So, you know, again, I don't want to hype Salve too much, but it is interesting that they actually have, you know, if you're looking for classes that are specific to healthcare and cybersecurity, they're the only organization that I know that are pairing those two topics. 01:40:45.770 --> 01:40:49.470 Certifications, there's a number of certifications that you can take. 01:40:49.470 --> 01:40:52.350 Security Plus is kind of CompTIA. 01:40:52.590 --> 01:40:55.870 Many of their certifications are kind of considered entry level. 01:40:56.130 --> 01:40:59.030 That's a bad thing, but if you're new, that's great. 01:40:59.030 --> 01:41:07.950 The Security Plus is interesting because it's kind of more entry level in security, but it typically requires that you have the CompTIA A Plus and Network Plus before. 01:41:07.950 --> 01:41:08.510 I shouldn't say that. 01:41:08.510 --> 01:41:10.770 It doesn't require it, but it recommends it. 01:41:10.810 --> 01:41:16.530 So that might be more of an entry level or an earlier career cert. 01:41:16.870 --> 01:41:31.910 The HCISPP, so the Healthcare... was it Healthcare Information and Security and Privacy Practitioners Certification from ISC Squared is kind of the more of the senior level certification. 01:41:31.910 --> 01:41:35.690 It does require two years of working full time in the security field. 01:41:36.290 --> 01:41:39.170 So that's another certification to look at. 01:41:39.170 --> 01:41:40.610 Surely there's others out there too. 01:41:40.610 --> 01:41:44.430 Those are just two that we thought might be applicable to this group. 01:41:44.970 --> 01:41:51.050 There's a number of great free online classes, CyberArea and Coursera. 01:41:51.210 --> 01:41:58.130 I only picked these because they were listed in the link at the bottom for TechRadar as the top two. 01:41:58.130 --> 01:42:01.010 And having taken classes from each, they are good. 01:42:01.210 --> 01:42:05.790 I will note that I don't know about these two, but a lot of the free classes. 01:42:05.790 --> 01:42:11.850 So as a professor, I use some of the free courseware in my classes as like sub-modules for teaching. 01:42:12.350 --> 01:42:30.610 And I don't know why, but basically as of like fall 2019, a lot of these online free education courses or programs started putting some content behind a paywall and anything like HIPAA and cybersecurity related tended to fall under that. 01:42:30.610 --> 01:42:36.670 So just be aware that some of the content may be free and some of it you may have to pay for, but it may be reasonable. 01:42:36.670 --> 01:42:38.010 So it may be worthwhile. 01:42:38.230 --> 01:42:46.950 It may be cheaper to just have all your employees take classes at one of these places and pay for an organizational membership to develop your own course. 01:42:47.970 --> 01:42:49.350 Definitely get involved. 01:42:49.350 --> 01:42:52.850 Join us in some of the industry groups that we work in. 01:42:52.850 --> 01:42:54.310 There's the Health ISAC. 01:42:54.310 --> 01:42:56.330 They have a number of industry groups. 01:42:56.330 --> 01:42:59.410 I was leading the global data privacy group for a while. 01:42:59.410 --> 01:43:01.990 There's groups on just about everything else. 01:43:02.230 --> 01:43:04.570 The Healthcare Sector Coordinating Council. 01:43:04.690 --> 01:43:10.830 They have some great groups on like secure development life cycle and any number of other things. 01:43:10.830 --> 01:43:22.710 There's a work group right now on training and development that I'm involved in that would be a great one to get involved in if you're looking at continuing to get more training. 01:43:23.610 --> 01:43:25.150 And there's certainly other groups out there. 01:43:25.150 --> 01:43:27.270 AIME, a number of other organizations. 01:43:27.270 --> 01:43:30.810 These are just two that tend to be popular in the industry. 01:43:31.690 --> 01:43:35.990 Please don't take any of these as a decisive list of everything that you can look at. 01:43:36.290 --> 01:43:37.730 And local security groups. 01:43:37.730 --> 01:43:47.910 Again, if you're watching this live, you're probably familiar with this, but if you're watching this on YouTube after the fact, local OWASP chapters are great for monthly meetups. 01:43:47.910 --> 01:43:49.270 And then DEF CON. 01:43:49.270 --> 01:43:50.230 So we're at DEF CON. 01:43:50.230 --> 01:43:52.570 There's local DEF CON groups or chapters. 01:43:53.630 --> 01:43:57.210 DEF CON 617 was a Boston group that I was involved for a while. 01:43:57.210 --> 01:44:00.370 And now I'm heavily involved with DEF CON 401. 01:44:00.730 --> 01:44:08.810 So they do, you know, most of these do like monthly, that's kind of like a lunch learn, but they're usually at night where they might have pizza and someone to give a talk. 01:44:08.810 --> 01:44:15.250 And, you know, it might be a technical, it might be, you know, it could be any topic related to security. 01:44:15.250 --> 01:44:18.970 So, and it's good for networking, kind of making contacts within your area as well. 01:44:18.970 --> 01:44:32.450 So, and the, one of the good things, if there's a good thing about COVID-19 is that because we're not meeting in person, a lot of these groups are doing online meetings now that you don't have to geographically live close to, like DEF CON 401. 01:44:32.950 --> 01:44:40.550 If you look at their meetup, they have a number of, I think the next couple months, maybe at least two or three months are going to be online because we can't meet in person. 01:44:40.550 --> 01:44:52.650 So, you know, you can, if you live in an area where there isn't one of these groups and you can't, if you go to like DEF CON groups.org and try to find one in your area, but if there isn't one in your area, maybe at least for the next couple months, who knows how long, 01:44:52.650 --> 01:44:54.650 you can visit one online. 01:44:55.850 --> 01:44:59.330 Again, if you're super new to InfoSec, this is a good book. 01:44:59.330 --> 01:45:01.270 It was free for a while online. 01:45:01.270 --> 01:45:04.170 I don't know if it still is, but there was a PDF for free online. 01:45:04.390 --> 01:45:06.730 If you do have to buy it, maybe it's five bucks. 01:45:07.190 --> 01:45:14.730 But yeah, if you do do InfoSec and trying to figure out how to grow your career, learn more, you know, get certifications, things like that. 01:45:14.730 --> 01:45:16.590 This is a great book to check out. 01:45:17.090 --> 01:45:23.590 Some other good resources, Micah Hoffman's presentation at B-Sides on how to join the InfoSec community. 01:45:23.590 --> 01:45:24.710 Again, getting involved. 01:45:24.710 --> 01:45:34.330 One of the great things about the InfoSec community is that, you know, we're constantly sharing information and training each other and it doesn't really cost a lot of money, which is great. 01:45:34.330 --> 01:45:40.630 You can just kind of go to conferences for fairly cheap and continue to keep learning. 01:45:41.130 --> 01:45:46.810 So things to Google, you know, you can Google hacking the skills shortage, we'll pull up good articles on that. 01:45:46.810 --> 01:45:54.650 Best information security certifications for, 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:05.830 And not necessarily career step of just where, you know, where to go to if you to leave your company and go somewhere else. 01:46:05.830 --> 01:46:13.130 But if you like working at a hospital, how to keep evolving your skills so that you become a better, you know, defender of your hospital organization. 01:46:14.470 --> 01:46:16.670 So we want to keep the conversation going. 01:46:16.670 --> 01:46:18.310 We're going to take a short break. 01:46:18.310 --> 01:46:33.470 So definitely go get some food, get your favorite beverage, and we'll be back in a little bit to actually have a panel discussion where you can not only talk to me and Helen, but a number of other experts in the field that know a lot more than we do. 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:40.030 So let's see. 01:46:40.810 --> 01:46:54.170 Yeah, so, you know, certainly reach out, again, both in the follow-up panel afterwards, but also, you know, if you have a specific question that you don't want to raise there, you can reach out. 01:46:54.630 --> 01:46:56.230 Here's our contact information. 01:46:56.230 --> 01:47:02.710 We'll leave that up for a little bit so you can email us, you know, hit us up on Twitter, you know, however you want to get a hold of us. 01:47:02.710 --> 01:47:04.670 And we look forward to hearing from you more. 01:47:04.670 --> 01:47:12.770 Again, take a take a good break, and then we'll be back for the panel discussion, and we look forward to hearing some of your questions. 01:47:12.770 --> 01:47:20.890 So thanks for all of everyone paying attention and the questions that were in the Discord channel during this training, and we look forward to seeing you at that panel. 01:47:20.930 --> 01:47:21.270 Thanks. 01:47:21.450 --> 01:47:22.830 Thank you for your time.