Cyber-Resilienz durch Design

Hello everyone. This is Giles Bruce with Becker’s Healthcare. Thank you for joining us for today’s webinar, Cyber Resilience by Design, covering why incident response is failing and crisis response should be prioritized. Before we begin, I’ll walk us through a few quick housekeeping instructions. We’ll begin today’s webinar with a presentation and we’ll have time at the end of the hour for a question and answer session. You can submit any questions you have throughout the webinar by typing them into the Q and A box you see on your screen. Today’s session is being recorded and will be available after the event. You can use the same link you used to log in to today’s webinar to access the recording. And if at any time you have issues with audio or visuals, please try refreshing your browser. You can also submit any technical questions into the q and a box. We are here to help. With that, I am pleased to introduce today’s speaker, Marty Momdjian, EVP and GM of Semperis Ready1. Thank you, Marty, for being here today. I’ll now turn the floor over to you to get us started. Hey, everyone. Thank you, Giles. Marty Momdjian here. I’m the General Manager and EVP of Ready1 for Semperis. My background is former Department of Defense and been in healthcare for about, nineteen years, mainly focused on incident response and, former CTO and CISO of a couple of major healthcare systems. Over the years over the years, I focused on, hands on incident response and crisis response, really helping organizations get through major ransomware events, supporting them through the actual cyber event, through forensics recovery, and getting them back online to a somewhat normal clinical and operational setting, post cyber event. What we’re gonna cover today is just some of the lessons learned from my experience, really what’s worked well and what has not, as well as just providing feedback and guidance to the community and leaving some time for a q and a at the end. So a little about Semperis. We are a identity security and crisis cyber resilience company. Healthcare is one of our biggest verticals. Really diving into it, from my experience, cyber is a top business risk. Everybody says healthcare is a high value target for threat actors and adversaries. Mainly from my experience, it’s not just healthcare being a high value target. It’s also healthcare is very complex. The heavy reliance on technology for patient care, and now the big buzzword this year is resilience. Resilience for people, process, and technology, and incident response is a core portion of that. Right? And healthcare’s for us, really, from my experience being a former executive, is delivering excellence in patient care. Right? And the reliance for that is technology at the end of the day. The real problem that exists, right, preparedness is burdensome. Most healthcare systems are really focusing on incident response, crisis management, and response is complex. Preparedness is complex. Recovery is very arduous, and there’s a lot of regulatory requirements that organizations have to adhere to. It’s really complex because of the business plus clinical plus technology at the end of the day. And visibility into preparedness, response, and restoration is even more difficult. Most organizations spend a lot of time preparing for crisis management, but it’s really difficult to practice when you’re just doing a tabletop exercise of assimilation. Also, the ever evolving threat landscape where adversaries and stay patient’s sponsored bad actors are focusing on healthcare because it’s critical infrastructure. One of the biggest problems that we come across when it comes to major ransomware or cyber events that occur is just assumptions, Assumptions that backups will be available, assumptions that the right folks will be involved in incident response and know their roles, assumptions around third party cyber insurance, legal support, as well as technology being available like Active Directory and communication tools that are out there. When it comes to people processing technology, what is really critical is just focusing on the crisis management side as well as incident response, making sure you’re operating in unison. From my experience over the years doing incident response and really recovery for health organizations, having those processes that are defined, documented, tested, stored, validated, and making sure they’re continuously updated is very, very difficult. Most organizations will build incident response plans and crisis response plans. What is very critical is the downtime clinical and business operations. What processes do they have in place? How often do they test those processes? And is it during a planned downtime or an unplanned downtime? Technology also has to be reliable. We depend on technology. Every healthcare system depends on technology for patient intake all the way to discharge. Technology for incident response and crisis response has to be reliable, available, out of band, secure, and intuitive, especially for the non cybersecurity resources and teammates that are relying on that to manage a cyber crisis. There’s also the aspect of governance. Right? All the regulatory pressure right now and compliance requirements, policy and reporting requirements, what OCR requires, HHS, what you have to do for the joint commission, as well as the requirements around CERCEA, which is the new reporting policies that are being enacted in October for cyber events and what you have to report on those. A big part of it is also risk. There is a shift now from risk to resilience. Continuous improvement in resilience really does end up being a reduction in risk when it comes to major cyber events or unplanned downtime events that require incident response and crisis management. So, from my experience, what happened? A lot of organizations over the years, including in my prior life as a CTO and a CSA of a healthcare system, went out and bought a lot of solutions and assembled teams. We generally have a business continuity team and a disaster recovery team, a crisis management team, and a cyber incident response team. We went out and surveyed a handful of, partners in health care systems, really covering the technology, people, and process aspect. What was very common is most, if not all, organizations have a business continuity and disaster recovery team that’s composed of IT, some folks on the cybersecurity side as well as business operations. For the crisis management team, it’s generally the emergency management team and business crisis team and, cyber incident response team, which is really focused on IT and cybersecurity. And then processes. Over the years, everybody implemented processes. Right? There’s processes for business continuity when my data center goes offline, when my connectivity to my clinical sites go down, when there is a natural disaster or cyber event relying on failing over to a second data center, and that team of, personnel responsible for the business continuity side. And then you have your crisis management team. Crisis management team really managing the enterprise wide crisis and the emergency management team for incident response, crisis response, communications, PR, legal support, and so on, and managing the actual downtime during an event. And the cyber incident response team that is heavily focused on doing forensics and true hands on cybersecurity incident response with support of the IT team. So what we’ve done over the years, essentially, is take these processes and combine them and say, hey. You can’t really have crisis management without cyber incident response without business continuity, and those processes have to be interwoven because there’s dependencies on the processes. Now what’s been common in the last couple years is deploying out of band solution tools. So this has been one of the biggest problems that exist, is that the business continuity team and the business unit will go out and implement out of band solutions. So what they use for Teams, Webex, so on for communications, SharePoint for downtime documentation storage, they will go out and implement their own solution for their downtime documents and communication. And then you’ll have the crisis management team, and the crisis team really focusing on the communication aspect of it will go implement their own downtime solutions and communication solutions. And then the cyber incident response team will deploy on top of Teams. They will go get Slack. They have their SIM. They have their incident management platform that is a little more secure than the standard ITSM platform. What’s been common is that a cyber event occurs, an adversary, a bad actor, a third actor will gain access to the network, they’ll get past the dwell time, evade detection. And when a malware payload or ransomware payload goes off or privileged accounts are compromised, essentially, access is lost. When you lose active directory, when you lose authentication, you lose the network, storage, anything that impacts the data center or cloud infrastructure with a heavy dependency on authentication and Active Directory. As soon as that environment is compromised, essentially, teams will not be able to communicate with each other. Communication is one of the most critical pieces of incident response and escalating to crisis management. As soon as those communication chains break down and access is lost, that’s when you end up having crisis chaos. Right? Now you have three different teams trying to use three different out of band solutions to communicate access documentation processes, runbooks, and playbooks, but not everybody’s playing on the same page. You’re not on the same communication plan, and it becomes very, very complex. And that’s where we see the significant amount of the failures when it comes to true incident and crisis response. There’s a breakdown in communication, a breakdown in notification, and a breakdown in access to actually continue operating and being resilient during an event versus shutting everything down and having to rebuild from scratch? We did go out and do a couple of surveys. The main, turnout of the surveys were oh, animations are broken. The main outcome of the survey essentially were most organizations, they are targeted by ransomware, especially healthcare. The output of that survey was number one on the list, was disparate tools. Essentially, organizations have communication issues when they go through tabletop exercises and simulations, and that was the number one concern. Now the survey actually showed in healthcare that organizations do have an incident response team and crisis management team. Their biggest worry is the communication aspect of it and also access to documentation and artifacts that you need for runbooks and playbooks when a cyber event happens, and that’s been the commonality. Biggest common challenges. So, really the top eight after doing incident response forensics and recovery over thirty times for major ransomware events that lasted anywhere from seven to thirty days. My findings and our findings were there was always an assumption that crisis technology would be available, that you would be able to communicate offline. Can’t really do that if you can’t log in. Can’t do that if Teams is unavailable or Webex because of active directory integration and then failing back to out of band solutions. Common failure in out of band solutions has been people have to remember credentials. You have to remember your out of band credentials, which is not the same as your standard login to your environment. As well as trying to get that information out to ten thousand, twenty, thirty thousand end users to be able to log in to an application to be able to communicate. Another big challenge, everybody knows about this. Loss of access to playbooks, documents, and contacts. Right? Especially for downstream clinical. If you’re unable to get into EHR, I need to have my playbooks on how to contact patients. I need to know how to do patient intake, patient registration, prior authorizations, make sure their billing code is in, make sure before we send them to triage, what is the process to get them into my ADT system to understand where that patient is if my EMR is not available. Most of the time, that’s on downtime PCs that are on the network that could become unavailable, and they do. And they have limited amount of information as well as they’re sitting on SharePoint or somewhere on the network, and you end up losing access. Most organizations will have a downtime binder. What we find during major incidents is that the information’s out of date because downtime binders are generally not updated. Same thing for downtime processes. They’re not available when it comes to the cybersecurity side and the crisis side, especially around communication. Another common issue and something to really think about is what vendors and partners should be involved in incident response. Unless you have a retainer and a specific agreement in place for confidentiality and business agreements, you should never pull a third party cybersecurity vendor in, somebody that’s not authorized by cyber insurance or the clinical application vendors. You can’t just call the EMR vendor or the integration engine vendor or your revenue cycle vendor and say, hey. We have a cyber incident. We need support. Right? There is processes that need to be implemented for legal and PR support around that. We also rented a common issue of stakeholders not being aligned with responders. Incident response, cybersecurity generally knows what to do. Where we have a breakdown in communication is updating the stakeholders on what we are actually doing on the incident response side, and there’s certain information we can and cannot share. And then taking that information and communicating it downstream so the clinical folks and the people in business operations actually know what they should be doing during a downtime. And if we don’t communicate timelines right, it causes complete chaos downstream. We talked about point solutions, communication solutions, and downtime documentation where we log what the incident is and how it’s occurring. It’s usually fragmented and not accurate. And when we do the after action report, most of our information ends up being lost. Another common problem is third party incident response vendors. They’re very good at incident response, very good at forensics. What they don’t understand is the clinical and business priority because our job function as incident responders is to get the adversaries off the network, do forensics, and recover things as quickly as possible. What we see out there is generally, they don’t understand what that recovery priority is. What does what matters the most when it comes to patient care, revenue cycle, and the actual organization, the brand to getting infrastructure back online, that’s gonna actually lead to patient flow working again. And the big one is recovery playbooks. Everybody has backup and recovery solutions. They’re great. But most organizations don’t actually test out what that recovery looks like hands on. We just do tabletop exercises. You have to go beyond with traditional tabletop exercise. One of the biggest questions I ask, if we engage with a healthcare system that, has or hasn’t had a major incident, it’s have you defined resilience? Recovery is not resilience. Does the organization, does the health care system and the stakeholders, the governance board, the C-Suite, all the way to clinical? Is there a definition to what resilience means to them? And resilience to me is continuing to operate during a cyber event or during recovery or some kind of major impact that occurs to your organization. And then going beyond that, it’s have you defined cyber resilience? There’s a business resilience, and then cyber resilience is a pillar of business resilience. Is that defined? And is that continuing to operate an incident or a crisis during a major event, or what is the actual definition for your organization of cyber resilience? Diving into incident response, it’s a critical function of resilience. Incident response, whether it’s cybersecurity incident response, IT incident response, physical incident response. When it comes to crisis incident response, it’s all a part of the resilience, I would say, governance for the organization and their critical pillars. So, something we put together, making sure that the organization outside of just IT really understands and defines what resilience is and speaks the same language, it’s really staying left of being. Right? We talk about this all the time and making sure everybody holistically at the organization has the same definition of preparedness, what an incident is, and then what a crisis is. Preparing the playbooks and runbooks, not just for IT and cybersecurity. Most of the time when we do incident response and we help an organization recover, the cybersecurity team has their playbooks. Where the delays are is making sure the rest of the organization and clinical and business operations understands why we are doing forensics and how do they get access to their playbooks themselves that they need. And then the definition of an incident, really simplifying that and saying what causes impact to an organization, and is it a cyber incident or a non cyber incident? And is it a significant threat or not a significant threat? And how does it tie into the organization’s strategic objectives? And then moving to the right of that, which everybody wants to avoid, is a crisis. Right? You don’t want a cyber incident to end up being a crisis. You wanna move as far to the left as you can. Diving into risk to resilience. Right? One of the things that, we say all the time is don’t try to prepare and create runbooks and playbooks and everything you need for contactless, doing tabletop exercise simulations for every little thing. Right? Your incident response and crisis response plan should be focused on responding to anything that could be threat to the organization, especially from the cybersecurity side, not creating specific runbooks and playbooks and SOPs Forest everything that could possibly happen because you will never get that done. Health care’s mission from my view, my previous life and current life is streamlining and delivering patient care. Right? It’s that’s what healthcare is there for. It’s take care of patients. We should be doing the same for cyber crisis because everything depends on technology. We wanna bring order to the chaos. When fifty patients show up at an ED, there’s a process to intake those patients depending on how critical, the impact to that patient is and how fast you can triage. We should do the same on the cybersecurity side. This is how, we’ve really defined cyber and IT incident and leading to a crisis. Something we share with a lot of organizations and really sit down and work do this, especially in healthcare. Making sure the whole organization understands incident response, crisis management, and all the goals, and what are the impact levels. My definition generally is there’s events twenty four seven. There is cybersecurity events like suspicious email, business email compromise, account lockouts. There’s events like power loss, Internet loss, applications failing. And then you move right of being and you have incidents. Right? Incidents being something very harmful. It can have negative impact to operations, to patient care, to billing, the vendor third party vendors being compromised, some type of business interruption or clinical care interruption. And then moving to the right of that, escalating and amplifying the response to a crisis. Saying, I had a cyber incident, I gotta invoke my response from my crisis team and my third party vendors. This is when you have a major incident and adversary gains access to privileged accounts, they deploy ransomware, and you’re going to an unplanned downtime. Going into a crisis is really dealing with a rapidly escalating situation. Right? There’s an immediate and severe threat, and you have to react immediately with an amplified response of the IR team, the crisis team, stakeholders, and the clinical and business operations folks on the team. Something to always try to avoid, of course, moving right up being again if you don’t respond fast enough to a crisis is a disaster. Extensive and widespread, long lasting damage, financial and reputational harm. You really should standardize on this before major events do happen prior to doing tabletop exercises and simulations and doing third party engagements with vendors and really define this for your organization. What we generally point out is as events are happening day to day, you’re in a continuous prepared state. You should continue preparing to deal with events that are gonna be incidents. You’re always responding to incidents. Most cybersecurity and IT teams, especially incident response, they’re operating twenty four seven. That’s the function of a cyber incident response team. Right? To avoid a crisis, it’s not just practicing. It’s going beyond the practice and really understanding lessons learned. And when you’re doing planned down times, engage with the crisis team at the same exact time to test out communications so you can move left to the ring and respond as quickly as quickly as possible. Something to really call out. When we do after action reports Forest major cyber events, everybody has people, process, and technology. You have your own cost schedule, roles and responsibilities, external contacts, incident command structure. Most organizations and major cyber events have their people organized, and then they have their processes or some of their processes. Right? You’re never gonna have everything and get to perfection. But you have frameworks that you follow like NIST or SANDS, your incident response playbooks, your crisis management playbooks, your downtime, communications, notification, event logging. What we see constantly is the crisis management team is integrated with the emergency management team, major incident, and the business continuity team. There’s a heavy reliance on people and process. Where the biggest disconnect is, people and process require technology. Right? In every major incident, the reason why we take an extended downtime is that when technology fails, when the adversaries gain access or there’s a flood, a fire, data center goes offline, cloud infrastructure is compromised, third party vendors compromised. You rely on cyber incident response. Cyber incident response is providing the technology to be able to do crisis management, major incident management, and for the people to be able to log in and access what they need and be able to access those processes. The dependency is technology at the end of the day. And incident response relies on technology to give access to everybody else that has to be part of the crisis response team. One of the biggest failures has been that technology becomes unavailable, crisis management turns into chaos. With that being said, what to focus on and really areas you should get right during incident response? Crisis technology has to be available. You have to have access to playbooks and runbooks. Make sure you have those out of band solutions. The animation is not working again. Processes have to be up to date and trusted. Incident response support vendors have to be ready to respond. This is a key piece is your IR vendors that you have retainers with, who contacts them, when do you contact them, how do you contact them, and should they be a part of incident response? Also, a big part is communication paths. This is where everybody should go beyond practice and actually define communication paths because your response is as good as your communication. One of the major things that happens is when communications and notifications go offline, if I can’t send email, I’m gonna fail back to text and SMS. SMS is not secure, especially if you have ten, fifteen, twenty thousand employees. How do you know they actually got that notification? How do you know that they know to go to downtime? Is their contact information up to date? And who’s allowed to send notifications during a major event? Most organizations, if not all, should have a unified command structure, and that command structure being incident response, crisis management, emergency management, clinical site specific incident response, as well as third party vendors that are involved. You have to have that horizontal communication notification documented and tested. Right? You have to have communication from the site leads, from the stakeholders, and really get on the same page. One of the critical parts as well is not just downstream notification. As you’re going to downtime, as you have an incident, what information do you communicate downstream from the command center to the operation side, security, finance, IT, clinical, legal? You have to also monitor that information, and you have to monitor involved communication. When you go to a downtime and the EMR is offline, interface engine is offline, patient portal is offline, revenue cycle is down, our site is unavailable. Generally, the clinical teams know what to do. Right? You do plan down times. Where we see the most amount of issues is monitoring upstream communication because they’re gonna need access, and they need to prioritize what they need access to if it’s not well defined. How does that information get back to the clinical command center? How does it get back to the emergency management team and the incident response team? What we recommend is a common service, common platform, common solutions. Get rid of those point solutions. If your emergency management team is using Webex, your incident response team is using Teams or Slack, your business continuity team has something like box running or they’re using signal to communicate, you’re not communicating on the same channels, and that is very problematic. At that point, you lose control of communications, and recovery becomes exceedingly difficult because we on the incident response and crisis management team will have trouble communicating the right information to the right party, to the right roles, to be able to manage the incident and recover quickly as possible. So diving into being resilient, recovery is not resilience. Right? Just because I have backups, just because I have a Doctor data center, those are gonna get compromised. Resilience to me is the definition of continuing to operate while you’re responding, restoring, and recovery. That being said, if my EMR goes down within fifteen minutes, the gold standard should be my clinical teams get a notification. My clinical business units have a notification. They know to go to downtime. They know that they need to do patient intake, triage, move patients around, give them a ticket to ride, make sure they’re delivering patient care without the EMR being available, which they know to do that because they do it during planned downtime. It’s difficult because most people take organizations take planned downtime in the middle of the night, and the daytime shift that is impacted might not be fully involved. So make sure you’re practicing that, hey. We’re not gonna wait to recover our access, our infrastructure, our VDI infrastructure for the EMR that they know what to do to continue operating and going through patient intake and all the way through discharge while you are going through incident response restoring and recovery. That is the real definition of resilience to me. Common things to really focus on. Right? Your IR team, crisis management team, business continuity together have and you just have to work through continuous preparation and continuous response and continuous recovery. That’s how you get to a resilient state. Access to minimal viable technology has to be available, and that should be a technology standard that you work towards. Not just the EMR because your EMR can be online, but if you can’t log in, you can’t deliver patient care. Right? If you can’t log in, Active Directory is not available, there’s an identity compromise that occurs, ransomware hits domain controllers or your identity system, your EMR can be online. It’s gonna become completely useless at that point. The minimal viable technology also being what you need for out of band communications. Right? You have to feel back to out of band communications for security and legal liability. Also, patient full. To be resilient, focus on patient flow, intake to discharge. What are the critical units for patient intake? And, generally, it’s the ED. Right? That’s really where the high volume is. And then from there, focusing on the patient life cycle and what technology is required and how can you minimally, viably provide technology to continue operating. Also, a big thing that occurs is you have to have a focus on billing and revenue cycle. Right? Just because you get the patients in and out, doesn’t mean that you don’t need to have billing in place and prior authorization, billing, claims, revenue cycle. What happens when a patient shows up going through in the downtime process, the prior authorization process, putting in the claims process, registering the patients, getting insurance verification done. There’s already manual processes in place. What’s the minimal viable technology required to give the registration desk enough technology, Internet access, browser based access so they can continue that process without being more. With resiliency too, third party access is critical. Most organizations have IR retainers. If you do have a major event and there is no access, they can’t do incident response. Right? If they can’t log in over the network, they can’t do incident response. And, also, what kind of support is required for incident response? You can do technical incident response, but at some point, what we see is you always need access to third party clinical application vendors to get systems back online to go through regression and smoke testing post incident, which does end up causing significant delays if you’re not planning for that. And, also, the order of operations. Right? Just because you go through detection and isolation and eradication does not mean you’re gonna restore systems the same exact way and reverse that process because what you should restore is in an organized tier of what you need to do patient intake, ADT, census, and billing, not just I’m gonna undo everything that I did, especially when it comes to forensics because that information has to be logged in a certain order. And, you have to engage generally third party cyber insurance and third party legal. Right? That order is gonna change, so make sure you, like, actually practice that and communicate that down to the clinical teams, that are responsible for the clinical business units. And, of course, communications, which we spent some time on, you have to have internal and external communications. What are those communication mediums? It shouldn’t just be SMS and email because they do become not secure or trusted during cyber events, especially if you don’t have access to it or the bad actors get access to that domain event. Diving into what you can do now. Right? We tell a lot of organizations that we engage with when it comes to simulations and preparedness and doing cyber briefings for healthcare. Rules change. Right? Focus again. Focus on preparing for anything, not just everything that you can document that you might not ever use. We should really pay attention to who’s responsible for what for your crisis management and incident response team and during an event, and does does somebody’s role change? Is my incident responder that does forensics My incident responder does forensics during a cyber event. Is my head of emergency management gonna be my chair of communications during a crisis, or are they gonna have a different role? Because roles do change, and you have to have multiple roles in preparing to deal with the cyber incident. What and how do they communicate? Right? What and how is communication handled during an event? And should legal be involved in the communication chains because you’re gonna need that for privilege? Again, what is the people process dependency on technology? Are you really focusing on cybersecurity only, or is it IT and technology insert response in general? What we see out there is whether it’s a threat after gaining access and deploying ransomware on a network and causing an outage or actually losing a data center or a third party application vendor being compromised. Communications generally should be handled the same exact way or close to the same exact way. Because whether it’s ransomware or my data center going offline and blowing up or a flood or something happening, you still need to stand up and insert response and crisis management. Right? When you’re practicing, involve both of those in your simulations and your scenarios. And is it just crisis response? Is it just disaster recovery? There really is a big shift away from disaster recovery now because if your primary data center is compromised, so is your secondary and tertiary data center, so is your cloud infrastructure at the end of the day. That’s just another data center. Are you really practicing disaster recovery? Or most of the time, you should be practicing incident response and crisis response because disaster recovery is one part of that. When it comes to building teams, build a team in unison. Right? Don’t just build an IR team, a crisis team, and a business continuity team and say they’re part of the same team. Really define the roles because you’re gonna have cross functional roles. Focus on communication and the circuit breakers to escalate from an event to an incident to a crisis with all the parties involved. For processes, centralized and build to always be up to date and available. This is back to you don’t have to document everything. Right? You don’t need every single vendor and every single contact, every single contract up to date every week and every month. But what are the critical ones? Right? What are your cybersecurity retainers, your primary systems that you need for patient care, business operations, and incident response? Who’s responsible for keeping that up to date? And where’s that information stored? Does it have to be up to date every single day or is keeping that information up to date once a month good enough? When it comes to awareness for governance, don’t work in silos. Right? Whenever, customer invokes a retainer or I’ve been involved in a major event, generally, the first action we take is don’t touch anything. Get me the head of crisis management, incident response, disaster recovery, legal, your compliance, your c suite in a room so everybody is aware of what we’re gonna do and what they should communicate. This is where we see breakdown where incident response will go into action without notifying the crisis team quickly enough to send a notification down to the end users, and then it becomes a surprise to have a downtime that they are not ready for. If you give them warning, they can handle that unplanned downtime a lot better, and you can recover a lot quicker. And then back to the continuous improvement for resilience. Right? Really being resilient is making sure you have your house in order and doing just enough to reduce risk, not really making it something you’re doing twenty four seven and not being able to focus on anything else when it comes to, caring, feeding, and upkeep for IT infrastructure. Things we recommend that you can do now that are really low hanging fruit. Right? Most organizations are looking at standing up a governance board and governance around resilience and shifting to that manner. What you can do now is build unified crisis emergency management, incident response, and operational response team. Build the roles, put the names behind the roles, and when you do your next tabletop and simulation or a planned downtime, stand up incident response just so everybody is on the same bridge, on the same call. There is unified crisis response in there, emergency management, incident response. So you’re communicating on the same channels. Get rid of point solutions that are out of band for each team. Again, this is back to the if my IR team is using Slack or Zoom or something else, and my crisis team is using some other technology like Teams, they’re not communicating on the same channel. I’m not gonna join two, three different bridges and repeat the same message because that causes delays and inconsistencies in message. Standardize on what you’re using for out of band from the stakeholders all the way down to your end users. And plan for simulations. Tabletops are great. Most places do tabletop exercises just to check off a box for compliance or cyber insurance. Go a little further than that. When you have a planned downtime, stand up into the crisis response to actually do a simulation Forest cyber event. When you are planning for simulations, include the field. Include the clinical pharmacy labs, the ED, the ICU, the NICU. Include those charge nurses because they’re the ones that know what’s happening in field and what’s happening in a care setting during an unplanned downtime and involve them in your table topics and your simulations. Right? Help, really if you understand what they need to take care of patients, it makes defining resilience a little easier for the organization because they know the minimal viable technology that is required at a care station or a charge nurse station or registration or HIM. And that’ll help make it a little easier to map out the paths that you need for technology to define what resilience is. Once you really have that taken care of and in place, things you can do later on, right, to improve your resilience state of resilience. It’s pick five critical units, and you can get really tactical with this. Pick five critical units where patients enter the health care system. Generally, it’s the ED. Right? That’s really high volume intake. And when you pick them, involve them in your communication plans during your planned downtime and involve them in your tabletop exercise and simulations. And then follow the clinician and follow the patient. From the cybersecurity side, when you have a planned downtime in the incident response and crisis team, go down to the clinical setting for your next EMR upgrade or next upgrade to infrastructure and follow the patients and follow the clinicians to see what that flow looks like and what technology they’re actually touching. That becomes a lot more valuable when you do have a major incident. One of the biggest things that we do in a major incident event is after standing up incident response crisis management, clinical crisis teams, and the communications and incident command chain is we get on the phone with the clinicians downstream just to get a status report. Right? And we wanna understand what is most critical to them if it’s already not defined and documented because that’s our number one priority for patient care. Because the clinicians, specifically the nurses who are the workforce for healthcare, they know what they need to take care of patients. And then, once you get a certain maturity level, you can practice without a downtime. Right? Once a quarter, couple of times a year, do an exercise where you say, hey. We’re gonna activate, crisis response for a couple of different units, and we’re gonna do patient movement, ADT, bed status, while the EMR is still running, while technology is offline. We’re gonna do this on the side to see what it looks like. While I’m registering a patient in the EMR, I’m gonna register them on paper. While we put in orders in the EMR and get results, we’re gonna do that on paper as well and involve the IT and crisis response team. So that way, they see what technology could be required for something as simple as printing out the downtime documentation for that unit, which is critical during an event. Back to what we’re talking about earlier to really unify. Right? Simulated practice is one. Everything you built for your schedules, roles and responsibilities, external contacts, communications, notifications, do it with the cyber emergency crisis, major incident, business continuity team. Right? Standardize on a technology. Standardize on communication tools, storage, recovery tools, what you need for workstation access. And if you have same tools deployed across the board, communications and documentation becomes a lot easier for everybody. Because at that point, they know where to go to. With that being said, I’m gonna stop there so we can do some Q and A. Sounds great. Thank you, Marty, for a wonderful discussion today. We will now begin today’s Q and A. Audience, please feel free to submit your questions via the Q and A box, you see there on your screen. Let’s go ahead and get started with the first audience question here. Let’s see. What is your view on creating isolated recovery environments specifically in the healthcare space? You have to define what an isolated recovery environment is. I come across this a lot where organizations say, I’m gonna build an IRE and I’m gonna put my backup infrastructure in my IRE and then I’m gonna recover there and I’m gonna get infrastructure back online so I can get my EMR back online. That’s great. We just built a second data center. Right? You just moved away from my Doctor data center to building an IRE or that becomes my tertiary data center. I I think the number one thing is for cost control and management, define what the IRE used for. Is it a clean room for forensics? Is it an area that I’m gonna recover everything to and shift my authentication there, make sure it’s sanitized and everybody’s gonna log in to my IRE? Or is it an area that I just use for staging to say, hey. I need to recover critical infrastructure. I’m gonna recover my hypervisor, my authentication, my active directory in a minimal viable state in my IRE, get my forensics team to log in, do forensics, and then from there, push that back to my production environment. Right? I’ve heard many definitions of an isolated recovery environment. My take on it, just my personal input is it can get out of control very fast in healthcare. It doesn’t make sense to build a full blown IRE on prem because every health care system has some kind of cloud component. How do you put your cloud component inside of a physical IRE? Or do you build an IRE in the cloud And are you gonna shift infrastructure and applications there during a cyber event? Which once you do that, you’re never moving it back. Just really spend time with your vendors and your partners defining what the IRE is. And what does the upkeep for it look like, and what are you gonna actually use it for. I hope that helps. Good. Thanks for addressing that question. Next one here. How exactly do you measure resilience? And secondly, how do you schedule security updates in medical devices without disrupting healthcare? May the way I measure resilience is can you continue to operate even in a degraded state when a cyber event happens or there’s some kind of impact to the organization? Right? It’s if I have a major event and I’m actually restoring my infrastructure and doing forensics, am I resilient enough that my people can’t do incident response and crisis management? Do they have access to minimal technology and is it available? Measuring against that is extremely difficult. You can go as far as say, what we do on the ready one side actually is we take infrastructure, we say what tier is it in? Do I have an incident response team, an incident response plan? Do I have downtime plans? How up to date on there? Do I have the vendor contacts? And then assigning a resilience score. That is very difficult to do. That goes back to you for your organization should define what is resilience and start with the building blocks of, do I have an IR team? Are they always on call? Do I have shifts? Do I know what my critical infrastructure is and minimal viable applications I need to operate? Do I have vendor contacts? And how up to date are those, which is critical for the resilience piece? And how often am I updating those at the end of the day? Okay. For the medical device question Yes. Mhmm. I I don’t wanna laugh and say good luck, but medical devices, IOMT is very, very difficult because there’s not specific point solutions to secure those. You have to take downtime to keep them up to date. There’s a lot of third party risk involved, and you don’t see IoT devices get compromised that often. The reason why they go down is because the integration engine or the back end application server was compromised, or we isolated it during an incident to protect it. And then there is a disconnect between vitals, actually reaching the EMR because the interface engine or server is down. The perfect example I can give you is there’s two thought processes in the Syrian arena. There is technology like an Atera that’s out there that does vital monitoring, that is touchless. You put a single device in a room, does nine different things for vital and respiratory monitoring. I now have one thing to secure and apply controls to, and I can build a network around keeping it available when there’s an incident. The opposite side of that is if I have nine different telemetry devices for vitals monitoring, now I have to keep nine different things secure. Right? But there’s also a lot more vendor access involved that way, so I could take half of those devices down and still get just enough vital information. And you’re always gonna take a downtime to keep those devices up to date and secure. It it’s inevitable. Excellent. Okay. And, yeah, please, to the audience members, keep please keep those, questions coming in the the the q and a box on the screen. And next question here, how are third party vendors involved on the clinical side, and how should communication be handled? Third party vendors are, I don’t wanna say interesting, but you have to be careful with what third party vendors you involve during incident response and crisis management. Because if it’s a non cybersecurity issue, my former application team, if not most application analysts, the first thing they do is pick up the phone and call the vendor for support. That’s why you have a support contract. Right? When you do major updates to an application, like a, Pyxis, right, or OBIX, you’re gonna call the vendor for support because that’s what they’re there for. When it’s a cyber incident, you the application person should never pick up the phone and call the vendor. That should be handled by incident response in the crisis team. Specifically, if an event is impacting that manufacturer or that application vendor, legal will need to be involved because of contracts that you already have in place. What I recommend is take all your vendor contracts, hand over to incident response and crisis team, work with the contract management team, and find out do they have a separate line to call when there’s a cyber event, and should legal be involved. And who needs to communicate to them, and are they authorized to communicate with them? And who handles communication? Is it the application analyst or is it somebody from legal that’s involved or your third party counsel? Because that becomes very, very complex and there could be liability issues there. Great. Thanks for the insights there. Third party risk is obviously a big deal in health care nowadays. And with the next question here, how should cyber insurance and legal counsel be involved? With every major incident, the first call should always be to legal counsel because they’re gonna be the ones that apply privilege one way or another and should handle the communications. Most cyber insurers, when you get past the underwriter and the broker, your carrier has a process. Right? Generally, the CISO, knows that process and, whoever handles regulatory and compliance internally should know that process as well. Now my number one recommendation is, work with legal and the CISO on what is the process to notify third party counsel? What is the process to notify cyber insurance? What are the circuit breakers for that? Because if you don’t notify them in time, there could be consequences of not having specific types of coverage depending on the incident. And they have resources there that they can provide when you’re doing tabletop exercises, when you are actually going through an incident that can help you get through it a lot better, I would say, or faster. It is critical that you have that documented and practiced of who notifies cyber insurance and third party counsel, how and are they authorized and approved to do that. Great. Two two important concerns there as well. Next audience question here. What are the major differences that you normally see in cybersecurity postures between large, and small healthcare providers? Any specific recommendation based on the size of the provider? There’s no specific recommendation on the size of the provider. Of course, larger healthcare systems are, they’re gonna have more funding for cybersecurity and IT. But at the end of the day than the small critical access hospital or critical access clinic that is relying on, minimal technology to provide patient care. Right? The bigger healthcare systems are, of course, going to have better budget because they do more revenue, and they have more people and more access to technology to have better controls applied and to have better technology in place when it comes to making sure they have good posture. It’s really hard to define a small, medium, large health care provider because it’s employees, bed count, you know, revenue, patient care. I would say the main difference generally is budget and, people that you would have in place. And it’s not the more you have, the better posture you’re gonna have. It really is what controls are applied, refreshed, and up to date when it comes to posture, and how are you reporting that. Great. We have a few more minutes left if any other audience members have questions, but, we have a couple more here as well. What what is the best way to store downtime process and ensure it’s up to date? Storing downtime process, generally, most organizations have business continuity workstations and servers running. Make sure they’re really off the network because they only contain data for seventy two hours most of the time. It’s somewhat useful, but your reports will expire after a couple of hours. Have something out of band in place. Right? When I say out of band, don’t rely on SharePoint, don’t rely on USB drives, don’t rely on printing things out, at the time of an incident, implement technology that’s in place, that has my downtime documentation, that’s constantly up to date, and that downstream clinical has access to it to get to their documentation and the artifacts they need for manual charting, manual patient registration, ADT census, vet status, and so on. A big part of that is keeping it up to date. It should not be cybersecurity or the crisis team’s responsibility. They should provide the technology and the actual clinical and operational leadership, and the person on using that documentation should be responsible for keeping it up to date. We should provide them access to where they need to store that. Great. We have a minute or two left. We have another question we can address here real quick. How do you select scenarios to practice during simulations and tabletops? My take on this, go for the ED. Go for anywhere high volume because they have the most amount of, touches for each patient, and they’re the ones that are doing the most amount of volume for patient intake and then triage and moving the patient to different units. Be really, really, really careful to not say, hey. I’m gonna focus on the OR or I’m gonna focus on the pharmacy. Yes. They are critical, but you don’t see the whole patient journey. I would take five, talk to the CNIO, the CNO, the CMIO, the CMO. Right? And say, hey. Figure out where do I get the most amount of patients and let’s figure out five patients, de identify them. What does their patient journey look like from the time that they scheduled their appointment to the time that they came in for care and got discharged, or they were at the ED and follow that path. Right? From time of registration, what technology was accessed to triage, did you send them to imaging? Did you send them to an inpatient setting, outpatient setting, and so on? That’ll give you a pretty clear view of what units to start with. And the ED is one of the I don’t wanna say obvious, but, they’re high volume, so you get the most amount of patients and clinicians in that area. Excellent. And yeah. And that is all the time we have for today. So, yeah, I wanna thank Marty for an excellent presentation as well as Semperis Ready1 for sponsoring today’s webinar. Thank you for joining us today. We hope you have a wonderful rest of your day. Thank you.