Video: Dress Rehearsal for Disaster - Incident Response Made Simple. | Duration: 2528s | Summary: Dress Rehearsal for Disaster - Incident Response Made Simple.

Transcript for "Dress Rehearsal for Disaster - Incident Response Made Simple.": Welcome, everybody. We're just gonna give a a couple moments for people to join the webinar today. And good morning, Kevin and Lee. Good morning. Good morning. Alright. I don't wanna take up any extra time. So welcome, everybody. I'm Torrey Pasda, director of marketing at Thryv, and thank you so much for joining our webinar, dress rehearsal for disaster, incident response made simple. Hopefully, by the end of the webinar today, you'll have a more complete understanding of incident response and how it is a critical component in mitigating the devastating effects of cyberattacks and how Thrive and VinylYze can help. A couple housekeeping things. The length of today's webinar is gonna be roughly 45 minutes including q and a. We are very grateful that you're spending this time with us, and we do wanna be respectful of that. Speaking of q and a, we do have a q and a tab that is going to be open during the entire presentation, So please make use of that throughout. We're gonna be answering as many questions as we can at the end. And any that we don't respond to live, you will receive a follow-up email with an answer to your question. We will also be providing the slides and the recording via email to everyone that registered for the webinar, in the coming days, today or tomorrow. So we wanted to kick off the webinar today with a few polling questions. I'm gonna give everybody a few seconds to answer each question and then move on to the next one. Your responses to these questions are going to help aid in the discussion today, so we do encourage you to, please participate in those. Now I did say that this is going to help aid in our discussion today, but the first one we wanted to do is just a bit of an icebreaker since tomorrow is Halloween. So what is your favorite type of Halloween candy? Chocolate, a gummy, like a sweet, sour, you know, a lifesavers or a Laffy Taffy, a salty snack, or you're you're not discriminating against any treats on Halloween. We got a lot of chocolate as suspected. Yep. No surprise here. And, also, the one I would have chosen, chocolate is the the clear winner of Halloween as to be expected. Okay. Next question and actually into the ones that are going to aid in today's discussion. The first one is, how long would you expect it to take to return to normal business operations after a cybersecurity incident? Would you expect that to be one day, one week, 4 weeks, or more than 4 weeks? Alright. We've got some one day, 1 week. Oh, 1 week is really taking the lead here. Okay. Oh, couple more came in. Still 1 week. Alright. We're gonna move on to the final polling question, and that is, do you have a written incident response plan today? Yes, no, or you're not sure? A lot of yeses. That's great news. Definitely okay for the noes. We'll we'll talk about this throughout. And unsures, thank you for being honest. Give a couple more seconds here. Okay. Thank you for participating in those. So now we're gonna get into the the actual presentation. So our agenda today so you're gonna hear, who Thrive and VinylYze are, hear more about incident response, security incident challenges, incident response planning, VinylYze, power of fast resolution, and then q and a. We will have q and a at the end. So with that, I do wanna hand it over to our experts on the topic at hand, Kevin Lant, who is our VP of product cybersecurity at Thryv, and Lee Sault, who is the chief investigator at VinylYze. So thank you guys for being here today. I'm gonna I'm gonna hand it over to you both. Sounds good. I'll get things ticked off. So, Vitalize, we are an automated incident response platform, and we're a close partner, a good partner here with the the folks at Thryv. We have the opportunity to work together on on some incidents, and, that's what we're here to talk about today. And as far as Vinylize, we were founded back in 2018. I've actually been a customer prior to joining. I was a customer of Vinylize, for quite a while, and AIR was designed to help, help investigations become more approachable to more analysts and more investigators because, historically, it's been very, very difficult nuanced on this wizard like work to do some of these digital forensics investigations. We were headquartered, we are headquartered in Estonia, and we have major offices in both London and the United States. I'm based here in North Carolina. I look forward to this conversation today, and, Kevin, I'll let you take it from here. Thanks, Lee. So a little bit about Thryv. If you're not familiar with us, we, do offer traditional MSP services like network management and help desk, but we also have a dedicated cybersecurity practice, and we offer disaster recovery and business continuity solutions. So those are the ones that are that are pertinent to today's conversation. A little bit more about Thryv, we were founded back in 2000, so we've been at this for a while, have have learned some things over the years that, hopefully, we can we can use to help you as well. We have a number of certifications, and over 26100, clients now, and a lot of them are in regulated industries like financial services, health care, state and local government, where, there is a lot of need for cybersecurity, but also incident response, planning. We'll send this slide out so you can you can read through the rest of this at your leisure. Thrive is is, all across North America now, also in the UK and the Asia Pacific region, continuing to grow. So we have a local presence in in a lot of of areas. I think we've recently added an office in the Detroit area, so we'll have to get another pin on the map here, but continuing to grow, and serve clients, all over the world. So let's get into incident response. One of the key things to note here is is that incident response is one part of a comprehensive cybersecurity program, which include a a few different things here. Most people are are familiar with prevention. So that's that's trying to prevent incidents from happening in the first place. Things like, antivirus, firewalls, VPNs, user training so that that people know not to click on on phishing emails. Most businesses now have, some form of prevention in place, which which is good. The next is is detection, and here, we see businesses and organizations starting to catch up and implement detection capabilities. This helps you know if something is going on in real time so that you can respond to it in a timely manner. We include things like MDR and and detection capabilities, in in that space, SIM, and and other technologies like that. But what we have found is that that the last 2 here, response and recovery, a lot of organizations are are lagging behind, in implementing things in that space. Now large enterprises typically have response and recovery, in in place, but as you move down into the the medium sized businesses and the small businesses, that's that's an area where people are still, trying to figure out what they need to do, and and put something in place. And I think our our poll at the beginning of this perfectly captured that. I think it was around 58 to 60% of you said, yes. We have a written documented incident response plan, but others, haven't gotten there yet, and that matches surveys that that are that are out there. I put a couple up here on the screen. In the US, a recent survey found that that less than half of businesses said they had an incident response plan. Similar numbers in the UK where, 55% of medium sized businesses, had a a response plan. You know, that increases as as as the business size grows and and is more of a a challenge as you go down into the smaller space. Why does that matter? Well, those of you that have been through a security incident, I think, can relate with with a lot of of these statements. There's the initial confusion of understanding what is going on, what is the incident, what is it impacting, and and trying not to let panic set in when that first happens. Because at the same time, you've got your stakeholders, your management. They're all calling you. They want updates. They wanna know what's going on. How soon can we get back online? They care about their that that recovery. And so there's some risk here of sharing information that might not be complete or accurate. You might be unsure of who you're you're supposed to notify, how you're supposed to notify them. So, it really helps to have planned this out ahead of time so that when you're in this situation, you have something to to to fall back on, something that you've practiced, that you've trained on to help you through this. And and Lee is gonna talk about this in more detail. He's been through a lot of these situations, probably more than he can count, and can talk through what what that's like. So how do you plan for this? It's really important to to have a written document that that everyone is, familiar with, knows what their role is. At Thryv, we like to use the the Center For Internet Security Critical Security Controls as a security framework. And critical security control number 17 is all about incident response planning, how to establish a program, what needs to go into it. And I I called out a few highlights here, but I encourage everybody to go to the CIS website. I've got the the the link at the bottom there, and and read up on this. But crucial to incident response planning are things like designating the personnel who are gonna manage the incident. Who's in charge here? Right? We can't have everyone running around trying to figure out, who to go to. What are our reporting responsibilities? What what is the contact info for that? What is the process for for doing the reporting? That's not something you wanna try to figure out on the fly, while you're in the middle of an incident. What are the different roles and responsibilities for other parts of the business? An incident is gonna touch a lot of different folks, like legal, IT, HR, PR, you name it. Different parts of the business are probably gonna be involved in in some way. When is it appropriate to bring that team in, and and what are their responsibilities when when you do so? That's all something that should be part of your incident response plan. Defining the communication, processes. This is an important one, that gets overlooked sometimes. It's important to remember that during the incident, your email server might be compromised. You don't wanna be communicating about the incident, through a means that the attacker might be able to monitor. So, these are all things that that you need to plan out ahead of time. How do we how do we communicate? Who's in charge of setting that up, making sure it's working, all important things to think about. And then last thing I've got here is establishing security incident thresholds. What qualifies as a security incident? That's important because if we're talking about pulling the pulling the lever or hitting the red button and bringing in all these different teams, doing all this communication out of band, shutting things down. We wanna make sure that that this actually qualifies as an incident. Everybody's on the same page about what that means and how it's defined so that we're not trying to figure that out, again, on the fly and and making mistakes. So really important to document this, as part of your your incident response planning. You should also be planning for recovery, though. So incident response, once you've got the threat contained, once you've got it mitigated, you think you've got the secure environment, how do you get back up and running? At the end of the day, this is what the business cares about. Right? Because every minute that that the business is down is is costing money or it's affecting services to your your patients or to your clients. So getting back and and recovering at the end of the end of the day is is is the key here. So some things that that we ask clients, to to provoke thought here and make sure we have plans are things like, do you have a full asset inventory, and and know who the business owners are for each of those? Have you define which of those are mission critical that need to be brought back up first. Is that data backed up, and and what's the retention period? Does it go back far enough? In case we have an incident that spans weeks or months and we need to go back, do we have the right backups? Are they encrypted, so that they can't be modified by the attacker who's got the password? That's not something we wanna figure out, while we're trying to trying to recover the business. So a lot of different things to think through here in terms of recovery planning. And then I'll give my, sales pitch slide here and and keep it short before I turn it over to Lee to talk more about, the the tools. But Thryv offers an incident response retainer, to our clients. As part of that, we include some pre incident planning. So we'd like you to share your documented, incident response plan with us. We'll have one of our virtual CISOs review it with you, make sure it covers everything that's in that CIS critical security control, and give you some feedback on anything we think, you know, might need to to think through or or or add to your plan. If you don't have a plan, we can help with that as well. That's a little outside the the retainer scope, but it's something Thryv can absolutely help with. So if you're you're part of that group that doesn't have a plan today and you'd like some assistance putting one together, we can help with that. The other things we do as part of this retainer, we're gonna go ahead and predeploy the finalize incident response tools ahead of time. So we've got those prepositioned. They're in place. So if we need to activate them, we can. And that's that's gonna cut down on that incident response time in terms of getting you up and running again. Going back to our other poll question, how long does it take to recover? The answer is it depends, which which no one likes, but it really depends on what's the extent of the incident, how how much planning has have you done, do you have backups, are those backups secure and and having integrity, and how fast can you deploy incident response tools? One way to cut down on that time is to have the tools predeployed ahead of time. Once we've got those installed, we'll run a compromise assessment. That means we test out and make sure the collection's working. We can get all the evidence and artifacts from all your machines, run it through, the automated, compromise assessment tools and finalize and and see what we've got. Make sure we don't have preexisting, issues in the environment already. And then we'll give you prioritized incident, management. That means we'll assign an incident manager on the Thrive side during an incident. That person will work with you to lead lead through all of the processes. So with that, I will go ahead and turn it over to Lee to talk more about what goes on, during the incident and and some experiences he's had. Awesome. Thanks, Kevin. We had that poll at the beginning of this, and the question was, how long would you expect it to take to return to normal business? And we had answers ranging from, ranging from, from a day or less over to to over 4 weeks. And, to kinda put some, to kinda put some boundaries around that, when we when we are conducting an investigation or when Throb is conducting investigation, we try to wrap this around a simplified chain of attack. Now, of course, we have a lot of very technical investigators, and there's a much much more technical depth that goes beneath this. But as far as trying to, you know, our job as investigators is to is to provide an easy easy to understand understand timeline of events so that we can make changes, identify which systems are affected, and get you back into business as quickly as possible. What I'll say is if there is no prep work, and we don't have any sort of predeployed agents or anything along those lines, it can take more than a week. It can sometimes take more than a month to get response, tooling even deployed. If the attacker has what we call dominant control of the network, they have administrative access and they're locking out of other administrators, it can take a long time just to get, antivirus EDRs or the finalized agent deployed. However, on the the other extreme of that, if you do have these things predeployed, you do have a a, incident response plan in place, and these are the things that you're testing regularly, it's not unusual to return a normal business, in, say, 24 hours. Even in the case of ransomware, if you have good if you have good backups, it's possible, but I would say that's the exception rather than the rule. Somewhere in the between 1 to 4 week time frame is more realistic. The more you practice, the closer you get to 1 week. The less you practice, the more you get to, to a month, and that's fully normal business. Your business will come back online in in phases, generally speaking. But for us, as we're going through an investigation, the questions that we try to answer rapidly are the ones that are most important to the business or or the insurers or the regulators or law enforcement, that the business is going to have to be answering questions for. The first question is how do they get in? And we wanna know this, so, we we wanna block that that entry vector, so that once we remediate things and once we get things put back together, they can't come back in. The second question is, are they still here? This is we talked about dominant control just a minute ago. If do they still have that administrative access to the directory service? Do they have some sort of command and control malware installed somewhere that that you haven't seen yet? We go through and we answer that question really quickly, and, you know, there's a variety of ways to handle that. Throb is really excellent to this at one of our better partner partners at at, remediate remediating these problems. Next, the longer burn questions, especially from insurance insurers or regulators, is which systems were affected and subsequently which data on those systems might be at risk? And that's that last question there. Which data which data did they steal? We've got this condensed down quite well. We can we can rapidly answer most of those questions and get you back in normal business if you're preparing for these things. Most of the time, you know, most of the time if I get pulled into an incident, which is rare, I'm here to support support partners. It's in those situations where the the attacker has dominant control. It's very difficult. There's technical problems where we don't know how to regain control of the net the network or there's some obscure technology, something something along those lines. And in all of those situations, it's a it's a the outage is measured in months versus days. And what that what that looks like is, when someone's experiencing a crisis, whether that's cyber or otherwise, we'll generally have what's called an amygdala response. You might call this the fight flight or fight response. A third option there is the freeze. This is generally that's the most common thing that we see in cyber crises is the freeze response. We just don't know what to do. There's no muscle memory. There's no practiced response to that, so people just don't make decisions. And sometimes they just want the problem to go away and they hope it will, and that when we go in there again these are the sort of things that I I get pulled into because we don't we just don't have answers. The victim doesn't know what the end goal really is. They have this nebulous, you know, nebulous goal of returning to business, and because they're having such a high stress moment, they they can't even clearly define what normal business looks like. So in lieu of that, we we tend to collect everything. So if you have a 100,000 systems, we'll end up collecting data from a 100,000 systems, and it's very difficult. Every every step after that becomes difficult because we have to, comb through all of that with a fine tooth comb. It's not clear what necessarily what needs to be analyzed. You know, what are your critical systems? I've been in situations where where victims can't answer that. Like, outside of the active directory, the domain controllers in that situate or those situations, which are you know, what are your critical database servers? Do you guys have, PCI data anywhere? Is there any sort of personally identifiable information, Social Security numbers, other sort of, other sort of controlled data? If if you're not thinking about these ahead of time, you're gonna be on a back foot as, you know, when we have to come in and respond. And then this is where you end up with those long investigation investigation times where it takes months just to answer the question, is the attacker still here? And you you just if you don't know, you just have to assume assume the answer is yes. However, if you go through this and you practice these, and you practice these types of things through both nontechnical and technical means. You know, nontechnical, let's practice that plan. Let's figure out who needs to who needs to get the phone call when when an incident happens. Let's categorize those types of incidents. Are we talking about, say, a, you know, a piece of, unwanted advertising malware on 1 laptop, or are we talking about ransomware on a 1000 laptops or workstations or servers? Those are totally different categories of incidents. If we can go through and practice those ahead of time with the plan and we also know exactly how how to collect data and which data collect, that's where finalize platform comes in, then we can answer those questions quickly. We can get a list of systems that need to be that need to have malware removed or systems that need to be reinstalled, and we can get you back in business in, you know, a week or less in most in some cases, probably most cases. More importantly on that on that piece is, we're starting to get we're starting to see much more pressure from regulators on how quickly you need to report an incident and any broader set of definitions for what a reportable incident actually is. I think this is another critical area where Throb's experience and the combination of VinylYze's technology comes into play. We're starting to provide very strong and clear answers to these regulators, so that you don't get the subsequent list of of challenging questions. And, Kevin, I can hand it back over over to you, from here. Thanks, Lee. So one last thing we we wanted to highlight. Since incident response is part of, an overall cybersecurity program, we did want to structure our retainer in in such a way to to make it easy to add for those Thryv clients that are already doing some of the other pieces of cybersecurity with Thryv. These things all go hand in hand and work together. So we do offer discounts on the retainer. If you've got our our MDR service or EDR service, it's a 50% discount. If you're working with us to reduce that attack surface by doing vulnerability management or our autonomous testing service already, then you're already working on that incident response planning in in other parts of the CIS security controls. It's an additional 25% off, so we can actually, give the retainer at no cost. Now there are situations where once we get in there and we have to do, incident response time with our team, that there could be some additional additional cost based on the the time spent there if it goes beyond the scope of our regular managed services, and we can help you figure out what what that that type of situation would be. But we think this is a pretty attractive offer. We don't think a lot of, providers are are offering something like this, and we really wanna reward clients that are already doing the right things in terms of cybersecurity, to make this easy to add. So with that, I think we will head into, q and a time. And I see we've got some questions already in the chat or, in the QA. Let me take a look here. Yep. We did have a few come in, and I just put a note in the chat for everybody in case you you don't wanna be the 1st person to ask a question. Don't worry. You're not. We we don't you won't see any of the questions that we answer until or that you've asked until we answer them. So please keep those questions coming. Alright. Back to you, Kevin. Sure. So let me grab let's see the first one here. Oh, I think the Microsoft one is good for Lee, if Lee wants to go ahead and answer that. Yeah. Sure. I can take that one. So generally speaking, when it comes to any of these cloud platforms, so, Microsoft 365 or Google Suite or AWS or or Google Cloud or any of these things, they have what's called a shared responsibility model. So they're responsible for the uptime of those platforms. And if those platforms go offline, then they will, they're responsible for getting them back. However, if there's a data compromise within those environments where an unauthorized access, that generally that generally falls on the consumer, so yourself, if you're using those platforms, to to secure those. Those would absolutely be in scope of a of a, I guess, incident response plan provided by Thrive. I've seen a lot of customers. Again, this is the sort of situation that I get called into is who do we call? And I would say, if you're curious about that, try to find the phone number or the email address to call if you have an incident for any of these platforms because I've been doing this for a while, and I haven't found one yet. And please don't make that assumption that, Microsoft, lot of good people I've got a lot of good friends at Microsoft and on their security team, but as far as whose responsibility it is, it's they're gonna push back and say, this is a shared responsibility, and it's on the user. Alright. And then we've got a question about, email security and how that fits in overall. So what I would say there is is certainly it's prevention because it can try to stop phishing emails and other types of of malicious email from getting to the inbox in the first place. It does help with detection, as well, can give us some indications that an email inbox might be compromised. In terms of whether it really helps with the response and recovery, kinda depends on what type of email threat it was. Often, email threats are just a way to get to another part of the the IT infrastructure. So a phishing email might trick someone into giving their Microsoft, credentials or their VPN credentials. At that point, when we go to do the response and the recovery, we really need to go look at those other systems to determine, you know, if if they've been compromised and take action on those. So I would say yes and no in in terms of of of that one. Then we got a question about, how the retainer's priced. So, we try to keep this simple. It's just based on the number of servers and workstations in the environment. We will be installing the the finalized agents on those, systems, and so we just wanna count those up. That gives us a good in in indication of the size of the environment, and the the complexity of the environment. Helps us scope out what what incident response costs might look like. Let's see. We've got one here about, is the incident response review only available if you have the retainer? Well, there's a there's a couple ways, to get an incident response review. One way to do it is through the retainer, so it's included in that. Some other ways you can do it is, by subscribing to our v, virtual CISO services and have an ongoing CISO working with you. They would obviously review the incident response plan as one of the first things they do when they engage with you, and they can help develop one. We also have some consulting services, that can go in and and do some assessments of of what you have in place today. So a few different options, and and, feel free to contact us and get more information on those. Lee, any you wanna pick out here? Yeah. I've got I've got 2 of them here. I'll talk about the cloud stuff, and, I had a friend of mine who just got into into or just got out of barber school, cut my hair, and got a little bit ambitious with with, yeah, how short they wanted to cut it. It was shorter than this. It was it was it was comical. I didn't think so, but it is now. Don't make way for the haters, Lee. It's all good. So what incidents have we seen with applications like net NetSuite or or SAP, and how do we set up incident response for that? I'm gonna say, with those sorts of things, any with that aggregate data, there's 2 things that we wanna understand. It's 1 is how did they gain access? Is this gonna be through stolen generally speaking, it's gonna be is it through stolen credentials or is it through a vulnerability? So with that, we're looking at a very number of logs for those types of platforms. They're generally fairly mature, so you'll have authentication logs and you'll know, which users authenticated to a platform. The second thing is gonna be, any sort of error or activity logs, And the third thing is gonna be the data that actually resides inside the platform. So the ultimate goal there is which data within this platform is at risk. Many times when they have access to something like a NetSuite or an SAP, they will gain administrative access, and it will be all of that data. However, our job as an investigator is to reduce that down. When did the attacker get in? How did they get in? Which which data existed within the platform at that time, and is there any subset of the database that was compromised versus versus the whole thing? We try to break it down that way, and then, as we as we clearly define what that critical evidence is or that critical, control data is, we'll back out or we'll we'll start mapping our way backwards and figure out how they got access to the credentials in the first place, whether they have access to the to that environment at large or if it's just a web access, and so on. Hopefully, that answers that question. As, the second part, how how would we set up an incident response for that? As far as the incident command component is is concerned, it's set up generally the same. We can generally install the finalized agent on any of those individual systems. Separate second, the, the logs that come out of those systems would be analyzed with a log analysis platform. Thanks, Lee. And, Lee, maybe I can throw another one over to you because I I know besides being a a an investigator, you're involved in in other parts of emergency management more generally. So we have a question, about how you connect the dots here between cyber incident management, general incident management, health and c c safety risk, and and some other areas of crisis management. Sure. For those who who have who work in crisis management or emergency management, FEMA puts a really good program out there as part of the National Incident Management System. Lots of acronyms, guys. Lots of acronyms. It's called, the ICS, the incident command system. And, generally speaking, any type of incident you have, whether that's a chemical related incident, a nuclear incident, cyber incident, or so on, it falls under, the incident command framework. I think the most relevant part of that that is overlooked or misunderstood, in cyber, I mean, all of the practitioners generally understand this, but it's not kind of it's not as known known quite as well. It's called unified command. So you'll have, as defined by FEMA, you'll have an incident commander or a set of incident commanders at the top that rotate out on a 24 hour basis or for for the duration of the incident. And within that, you'll have different functions, and this is where we called out during the planning session. This is even represented in CIS where you'll have, the legal team is called out. That legal team will more or less report into the incident commander, the IT team. You may have, like, facilities coordinator for getting access to the building logistics, things along those lines. We organize all of those. I mean, all incidents in in general are organized that way if they're managed effectively. So the the thing that would be different, the dot to draw would be who gets included, who does the incident commander include in that general that that command and general staff for that incident. We might not need a health care professional, for example, in a cybersecurity incident. Hopefully, that answers that question also. Thanks. And then, a a couple in here more specific to Thrive. So I'll I'll try to summarize a few of these. One of them is is about how Minalyze would add to the mix of of of things that that are already being done with Thrive, so things like DNS filtering, email security, user awareness training, backup, and and disaster recovery. The the way this fits in is it gives our investigators a lot more information if we ever do get into an incident. So some of those tools are there to try to prevent an incident from happening in the first place. Some of those tools are on the recovery side to get you back up and running as fast as possible. Finalize kinda fits in the middle there, so it helps our investigators answer those 4 questions that that Lee mentioned, which are, you know, how did it get in, and are they still in, and and what did they access, and and what what data did they they steal, if I if I got all 4 of them there, Lee? Answering those questions can be very difficult and time consuming, and what finalize does is allows us to do that a lot faster. I can give you an actual example from from just a few weeks ago. We did have a client that had had some ransomware. We were able to identify how it got in so they could fix that. We identified, how far back they were in the environment so they knew, which backups were safe to recover from. They were able to to to bring those backups back online, with with Thrive's assistance, and they they told the the attackers to to get lost. We're not gonna pay a ransom. We're back up and running, and they learned from that. They learned based on how they got in. They knew what changes they need needed to make to the environment. So it's it's not, you know, it's not a badge of shame to have these things happen. It's how you respond to them and what you do in response to them. And if you can actually fix things, you come out the other end of it stronger than you were, when you started. Question about, oh, one just came in about out of band communications. That's that's a good one. I've I've seen some some products that are out there that that offer alternate ways to communicate during an incident. I haven't tested any of those or or or I'm not able to recommend them specifically. I know these those exist, and some of our clients use them where it's an actual platform that sets up, an out of band communication that you can activate. I've also seen clients do, separate email servers that they only use, during an incident. Lee, you've probably seen seen all kinds of, options here. I mean, it's a it's a it's a complex question because there's different modes of communication, asynchronous, synchronous, etcetera. Generally speaking, my answer for this question is signal. Get everybody make everybody install signal and just get on that. I I would say out of band out of band email is also pretty good. If you have a secondary Google Suite or Office 365 account, then that would be good for setting up video calls and things along those lines. But generally speaking, if you have an incident, being able to being able to set up signal, a group with everybody in there, that means that you can have encrypted phone calls. You can have encrypted text messages, and you'll be able to get in the in the early hours of that crisis when you really need to make rapid decisions. That's the best way to do it. After you get there, establish some other forms of email and video, video conferencing. Alright. If there's, I know that there's still a few more questions, but I think that you guys answered great. Almost all of them. I did just add a ticker here. If anybody wants more information on Thryv's incident response and remediation, you can click out to that. But were there any other questions you guys wanted to get to before we end? Yeah. I've I'll, the second half of that question, I just Oh, I'm sorry, Lee. No worries at all. The what is the what is the proper cadence? I would say the most common thing that increases stress level that I see so when I come into an incident, I'm normally playing the incident commander role, you know, as defined by FEMA and all that. The first question I ask is when are we having a meeting? And, generally, everybody says every day, we're gonna have a meeting at 7 AM. We're gonna have a second meeting, a third meeting, or we might just leave the conference bridge open. This burns everybody out, not just the investigators, but the victim and everything else. So what what needs to what needs to get established is a, basically, a staffing plan of when you actually need to get these. That that's probably the first conversation to have for whoever the the senior folks are. And in some cases, Monday, Wednesday, Friday makes sense. In other cases, it really does make sense to get on the line and just leave that line open 24 hours a day over some video teleconference. If you're gonna do that longer form thing, you need to make sure you have enough staff for that. So this is this is, you know, how many investigators do you have? Is it realistic for them to work 16 or 20 hour days for 7 days or 14 days straight? How long can your can your executive staff or your management actually last and make good decisions? Because after about 48 or 30 or, 48 or 72 hours, everybody's judgment starts to degrade, and then you accidentally start making making decisions that are that are detrimental to your business. So those are the factors that I would consider. Monday, Wednesday, Friday work great. I would say mid afternoon meetings if you want everyday meetings. You can have a short one stand up meeting in the mornings and then findings meetings in the afternoon if you want one every day. If at all possible, If the attacker is not in the environment, I would skip weekend meetings and give the entire team, the entire crisis management team, some rest so they can come back fresh and have good judgment. Great point. Okay. So, thank you to everyone who joined today. We really do appreciate the time that you spent with us. Again, you will receive the, presentation and the recording, after the webinar today. I hope that you've taken away some useful information and that you have a great rest of your day. Thank you again so much, Kevin and Lee. You guys brought so much insight to this topic, so really appreciate you guys being here. Thanks, everyone. Thanks, everyone. Thank you.