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