Identity Crisis Readiness: The Leadership Decisions that Make Technical Recovery Possible

Alright. Well, you know, this is fun. Right? Here at HIP, we typically spend a lot of time talking about identity, get to nerd out a little bit, you know, share experiences and stories. But we oftentimes focus on the technical side of our business or or even understanding the containment response and recovery from a technical aspect. But really today, I'm hoping to dive in with these guys to understand what we should know from a business perspective. How can we plan better? How can we prepare better? How do we make better decisions ahead of time so that when we're in the middle of that fire, we're making smart choices, not only to protect ourselves but our organizations as well. It's kinda what our conversation's about. We'd love to hear from you guys. If you have questions during the session, please raise your hand. We want this to be conversational, interactive. And really, when I think about building crisis plans or crisis preparedness runbooks and playbooks from my perspective, oftentimes it's what should I know? What do I need to know? How do I prepare? Because oftentimes, we overengineer these processes and they're almost impossible to execute when things go bad. So how can we make these plans effective as well is something we'd love to cover today. Actually, we were chitchatting before the session started. They're knee deep in a handful of incidents at the moment, and I think you got a call this morning. Yeah. So it sounds like it's been very active, and I don't know if you guys are seeing the same within environments, but activity has definitely picked up over the last month or so. So I guess we'll go ahead and get started. So we're gonna start with when does an identity crisis become a business crisis? And really understanding from your perspective, what are the signals that tell us this isn't just a security incident, but this has kind of moved out into the business? What should we be watching for? Yeah. I think for us the easy answer is really business interruption implications. Right? I mean, if you have an incident that impacts a front facing business unit, right, that may, you know, require the website to be taken down or that may impact customers downstream, it really goes from maybe the smaller prerequisite infosec group to needing to involve cross organizational stakeholder involvement, leadership, legal, as biased as that may sound, even things like, you know, your insurance agent and broker. So escalation paths are critically important when it comes to, you know, when do we notify our superior that something's going on, and and for us, I mean, the easy answer is always the sooner the better, right, just because there can be points of no return, if you will, which I think we'll kind of discuss later on in the panel over, you know, forensic and evidence collection processes and, you know, mistakes that people make and how that can lead to some pretty serious consequences. Yeah. Just one small thing to add. So another way to think about that outside of business interruption is is what kind of spheres of communication are needed based on the type of incident that you're dealing with. So I think for those of you in the room who are kind of, you know, the technical folks, kind of boots on the ground operators, this is a good opportunity for you to kind of step above your role and understand that you can this is an opportunity to communicate with your leadership. Right? Hey, we have this incident and it's impacting, you know, business unit a or or division b. We need to kinda get communicate with the employees in those departments. Right? Their, you know, operations are impacted. They're gonna notice something's going on. So we need to be proactive and have those conversations now. Right? Or, you know, a group of customers or clients or vendors or business partners. Right? You can kind of set this tone of, hey, we need to get out ahead of this and start communicating. And I think that for you guys shows that you're not just thinking you're thinking about the enterprise risk, not just what's in front of you on your computer screen. So oftentimes with an identity incident, everything's offline. Right? It's hard to hide. It escalates quickly because no one can access any of our normal operating systems. We can't communicate with each other. But it sounds like knowing when to escalate in situations that maybe aren't that catastrophic is something that you run into quite often. Do you see companies wait too long or or go too quickly? I mean, is there too soon, too fast? Where's the where's the button there? Well, I mean, touched on this idea that internal communication strategies can differ and require different things than an external communication strategy. Right? Just speaking to the former first, I mean, we're big on, you know, empowering organizations to provide some level of detail and clarity to employees when we know that employees are cognizant of the fact that something's gone on, particularly employees that may be front facing with customers, with vendors, who are gonna be fielding questions. Right? And when there's a lack of clarity or information sharing around what's going on, it just allows opportunities for employees to say things you don't really want them to say, right, or or to, you know, suggest or even assume that, you know, something's going on that at that point in time we may not definitively know from a forensic perspective. So I think it's important to kind of have those two strategies be separate, but then sure there's obviously an interconnectivity to that. And it's about less is is better in the early going. We've seen a lot of clients over the years and have tons of stories where, you know, they've really tried to get out in front of things and provide too much detail before, forensically, there's been a more thorough analysis done. And it's rife for saying things that you later have to walk back. Right? You know, one particular example I've used before was I had a client who was experiencing a SQL injection attack, and we got brought in twenty four to thirty six hours in. And they, you know, had a number of client instances that they were concerned about. And, you know, one of the first questions we always ask on those initial calls is, like, what have you told people, and how have you communicated that this has gone on? And when I asked that, they said, well, we sent out a basically company wide email to all of our customers saying that we we have this problem and we're concerned about impact to customer data. And and that was one where, you know, I wasn't on camera, but I was like, oh, boy. You know? Because it's it's so preemptive to come to that sort of conclusion, and what then happens is exactly what happened in this particular situation. It was just a torrential downpour, if you will, of of customer inquiries saying, like, so were we impacted? Has our data been impacted or exfiltrated? Or I mean, they're just then quick to jump to the worst possible scenario and conclusion. So it speaks to really wanting to have a very tight, contained, overall communication strategy that allows you to maintain a modicum of control, especially in the early going. Yeah. This might be a little redundant, but just to drive home the point that, you know, going too far out over your skis and communicating when you're dealing with an incident is the easiest way to just create way more chaos than necessary. Right? I mean, the minute anybody outside your organization hears ransomware, they're gonna, you know, pull connectivity, they're gonna start sending you emails and asking for information, and it's just gonna blow something out of proportion that, you know, may may not even have anything to do with them. So it's easy to say, it's easy to sit up here and say that, but when you have a ton of pressure, you're getting inbound inquiries from third parties, there's a ton a ton of pressure on you to make a statement and to say something. The the point here is just be very careful. Talk to your lawyer. Talk to your inside counsel. Talk to somebody to make sure that, you know, like Thomas said, we're sticking to the facts, that what we're saying, that our messaging is aligned across the board, and that we have kind of pipelines for communication through, you know, like client managers. Right? Or through an internal, you know, single point of contact within the organization to feel those those inbound inquiries about what's going on. I like that. So we're really looking to understand and control the narrative, try not to induce panic. Right? So internal comms plans, external comms plans, and make sure that we're not getting out too far ahead of ourselves. And I think that leads really well into our next question, which is what are the important decisions leaders or planning teams, preparedness teams? I know I'm building runbooks and playbooks. What should we know beforehand? What should we plan for? What are the decisions that we should be prepped to make ahead of time? At the risk of of being oversimplistic, I mean, who's a part of that core team? Right? We even to this day having done this for the last decade are still fairly surprised at times where when we start talking to folks, particularly preemptively about incident response preparedness, you know, having thought through who they would want on that core CERT team. Right? Who the incident commander would be? Who would back up the incident commander. Because as I'm sure everyone here is so surprised, the bad actors are rather adept at being opportunistic of of knowing when to spring an attack upon organizations should take place. Right? So, you know, you don't want your CISO in The Maldives vacationing when you're undergoing a ransomware attack. And if that were to happen, then who's set to fill his or her place? Right? So I think that core CERT team for me is a big one, and then Ryan and I are just really big on on just being proactive. Right? And it's great if you have an incident response plan, but our next question then becomes, so how often have you tested it? Right? And how often have you thought through some inflection points? And, you know, how have you wargamed different scenarios that are viable issues that could cause really catastrophic consequences should they take place? And that's where we think, you know, understanding who the right people are to have in the room is first and foremost priority, and then really thinking through as best as you can proactively versus reactively how you can, you know, handle it in a manner where you can mitigate as much risk as possible. The the bad guys are are obviously getting a lot smarter and and to Thomas's point, they will wait until the night before a holiday to hit you. They will wait until your security officer is on vacation. They're looking for opportunities and and so redundancy in, you know, management and leadership of those incident response teams, testing that plan, updating it right. I mean, you we handle incidents where we come and say, okay, send us a copy of your incident response plan so we can get an understanding of, you know, who's on the team internally and externally, what role they're gonna fill. And they send us a copy and it hasn't been updated in four years and and they really don't know who's gonna fill that role. Right? Who do we need to talk to from HR? Who do we need to talk to from PR? You know, who do we have to bring in to support our incident response team? And, oh, by the way, the people that we're bringing in have never even heard of an incident response plan. So make sure that you're at least on an annual basis taking a look at that plan and keeping the team updated. And, you know, everybody on that incident response team should know that incident response plan like the back of their hand, right? To add to that, our personal favorite is, well, we actually don't have access to our Incident Response Plan because it's encrypted, right? And it's located on our network. So then a whole lot of good it's going do you then, right? We talk about that a lot, is access to those critical documents, but also phone numbers. Or like you said, do we know who's on the team? Can we get a hold of the people that are on the team? It's some of those basic blocking and tackling where we all really struggle. You know, and I think it's interesting from an identity or kind of a technical perspective, how do we share information back and forth? You know, if we've got a core team that's part of our incident response and recovery, they're really the information liaison for the rest of our groups, right? So are there good tidbits for sharing information back and forth or helping to support our technical leaders as they're working with their executive leadership team? Yeah. I mean, I think it's one of the biggest land mines, if you will, just with respect to incident responses. You know, those early hours of forensic and evidence collection and preservation are so critical, particularly in today's day and age where if you have an incident that results in some sort of legal obligation to notify individuals or regulators, it's it's practically almost a given that you're gonna then get sued, unfortunately. And that could be a talk in and of itself of just the evolution of of, you know, data breach class action lawsuits and the litigation around this space in general. But it's tough. I mean, mentioned earlier, a lot of the folks in this room are in the very difficult position of having to make split second decisions. Right? Do I do I take this system offline that is instrumental to our network architecture or that, you know, would shut down our manufacturing floor. And in doing so, you know, the the legal consequences aren't oftentimes at the forefront of people's minds, understandably so. So that's where, as we said about the planning, really some of the ROI comes into play over thinking through those issues because our jobs really don't, if you will, take place until some of the dust has settled. Like, our our primary objective, particularly if it's a ransomware, is just to stand the business back up, right, and equip people, employees to generate revenue and be able to do day to day functions. When we start working through some of the legal obligations and trying to mitigate risk, unfortunately, we're almost always only as effective as the evidence at hand. Right? So, you know, you pull a system down and you wipe it clean, you're not gonna have any sort of insight or knowledge over, you know, what exactly the threat actor did or maybe more importantly, the information that was subject to unauthorized access. Right? So I think for me, just evidence collection and forensic preservation is an issue that unfortunately we see all too often companies kind of go astray. Just because if you haven't been through something like a ransomware or a more catastrophic type cybersecurity incident, then you oftentimes really have no reason to know, you know, the appropriate protocols. The one last thing I'll say before I'll be quiet is, you know, we see in situations that require out of band comms, sometimes companies that are quick to say, like, well, we'll use a WhatsApp or a signal, right, to communicate. And we always say, like, we we gotta think through again those evidence preservation issues, and you don't wanna find yourself after the fact trying to explain to a judge, you know, spoilage issues, right, of like, okay, so why don't you have any sort of communications that you can produce as part of this interrogatory or request for discovery? It's not going to be a winning argument to say, well, we were using something with, you know, a one hour or one day retention period. So that's another thing where just you gotta think through some of those systematic core business processes and you need to do it ahead of time. We're exposing your personal devices for that kind of discovery. Right? That's what I was gonna say. Yeah. You know, hopefully most of you in the room are gonna think this is this sounds obvious, but you'd be surprised at how many of these that we work and, you know, email tenant is either down or unknown. Right? We don't know if the bad guys are in there. And so we have to move out of band. And when we come into an incident late, usually everybody's like migrated to their personal email accounts. For just obvious reasons, that's the worst thing you can do because all of that is gonna become discoverable and that's how people find out about your mistress and, you know, all of, you know, basically your entire personal life. Right? So have a platform ahead of it ahead of time. Right? There are purpose built platforms to handle out of band communications. You know, WhatsApp is fine, just make sure it's it's programmed correctly. All the way down to, you know, kind of burner Gmail accounts, right, where you have them set up for its, you know, name at company name irt.com or googlegmail.com. Right? So just have something in place, know it's gonna work, and again update, make sure that everybody on the team has one and so that it's the migration from on band to out of band communications is as seamless as possible. So one of the things you guys mentioned was the forensics, making breakneck decisions, you know, with very little information. But I think oftentimes authority or kind of predetermined decision points is missed in the planning. So how do we support our teams when they're having to make these kinds of decisions, maybe feeling like they don't have the authority? Like what recommendations would you make to kind of prepare for those kinds of things? Yeah. I mean, paralysis by analysis, right? It's a very real thing and we see it. And oftentimes, unfortunately, I think information security professionals, when something goes wrong, are immediately thinking like it's my neck, it's going to be on the chopping block, right? And some of that I think speaks to a greater need to have, as I had mentioned earlier, cross organizational involvement. I think there has been some evolution around, you know, it being a security problem or falling within the purview of like the CIO or CISO to now, whether it's a publicly traded company or a healthcare system, you know, a little bit more regulatory impetus behind, like, you as an executive have to own this. Right? And it still surprises us to this day to see executives be so surprised over when something goes wrong, but then also to see how entailed the process becomes, ornate the process becomes over waiting through it. Right? Because it's we get the question a lot of like, so how long is it gonna take until this is behind us? And when it comes to something like, you know, data exfil, inappropriate data access, we have to be the bearer of bad news to say, you know, it could be a while. Especially if, you know, we've got a terabyte worth of data that needs to be forensically examined to determine, you know, who we need to notify. So I think it's, I mean, my sound bite and takeaway for this panel is just generally preparedness. You know, if you think through some of these decisions and go through kind of a general decision matrices via something like a tabletop that's done well, it opens the eyes to executive leadership realizing how do we best equip our people to make good decisions, you know, what sort of tool set can we help them leverage to make better decisions and things of that nature. Yeah, just really fast. The tabletop exercise is your best tool to get what you want as a security professional. Right? I mean, if you find somebody who's really good at running tabletop exercises, whether it's a lawyer or a vendor or a consultant, it doesn't matter, just find somebody that knows what they're doing, that can really poke holes in your program. In our experience, there is no better way to get approvals than to really put that in the face of of your decision makers, of your executives, and say, look, this is this is the result, right? This is actually one day going to happen if we don't make changes because, you know, most most decision makers have never lived through a ransomware incident. They don't know how terrible it's gonna be. So being able to just simulate that to a, you know, a small degree to show them what this is really gonna look like when the roof when the house is on fire is is really your best tool to, you know, get what you need to mature your security program. Semperis team is gonna think I paid them to say that because we just did our tabletop a couple of weeks ago. I didn't, by the way, but we're gonna keep practicing, everybody. And we talk about at the beginning of even our sessions, the goal is to fail. These tabletops exercises are really meant to test our processes, our plans, our team, the RACI structure that we have, poke holes. We know plan a is oftentimes not gonna work. Do we have a plan b? Do we have a plan c? So that's absolutely important, and I'm gonna have you come moderate the next tabletop exercise. You had mentioned kind of forensics and and understanding that in those first couple of hours, but I think knowing what to do or be mindful of in the very early minutes of these situations is important because you're right. You don't always know what decision you're gonna make. But what other things should an identity expert or any of our technical teams be aware of in those first hours, minutes, day or so before we start to understand what's really happening? Well, I think it it speaks to your earlier point about, you know, foundationally, are they empowered to make decisions? Are they concerned or is there anxiety escalating to the appropriate point person? I mean, by no means am I suggesting that, you know, you wanna be emblematic of the boy that cried wolf and be running to your superior at the first sign of, you know, any potential malfeasance. But it's like, we really see clients who significantly shorten the pain that comes with these incidents when they've fostered an environment where people feel empowered to act, but also then escalate and involve a greater group versus, you know, clients that kind of rule with an iron fist. Right? And this sound bite is used a lot, but we think it's particularly true. Right? You're you're only as strong as your weakest link, and your employees speaking to to just outside the information security field or team are your frontline workers. Right? And so, you know, somewhat of an innocuous example, but we see companies that, you know, will do phishing simulations with their employees and they'll ask us, will we punish them if they failed? And my retort and response usually is like, okay, I understand, but what kind of message do you think that's sending? Right? It's not that's not exactly suggestive of an environment where, no, you don't want someone being a repeat offender, but you you want someone who's gonna say, well, this looks odd, and I wanna reach out to someone and ask about it. And and so when you think more specifically to, like, you know, security operations center people, it's better if it's an environment where it's like, yeah, this looks troubling to me and I'm gonna involve someone versus, yeah, just another alert, we're gonna get rid of it, and you know, we'll see what happens. Wow, that's so kind of you, you think I? Well, you know, we're talking about authority, the ability to make decisions, understand what's important. Prioritization. Prioritization and recovery, you kind of alluded to this earlier. The business wants it back up and running yesterday. We know that there's a safe way to do restoration and recovery, obviously, ideally without the bad guys still in there. How do we help bridge the gap between what the technical teams know needs to happen and what the business is expecting from a priority perspective? I mean, I think legal done right and effectively is proverbially that bridge. Right? Like that's we, you know, and lawyers who are in this space, when they've done it right, they kinda help quantify some of that risk, and they explain some of the more technical concerns and the ramifications of point a or decision a versus decision b to executive leadership. And and two, I would add that it's just it's difficult because, as I said, there's such drag oftentimes in those first few days of just standing operations back up. We oftentimes have to prove to clients that, you know, their first thought when lawyers get involved is like, oh gosh, here we go. You know, they're now gonna make everything as complicated as possible, which may be true at times. But the number one priority always needs to be equipping people with the ability to, you know, perform necessary day to day functions of the business. Right? And and that's priority number one. With that though comes caveats and disclaimers of of doing it in a more systematic way to where you're trying to think more long term and forward thinking over, you know, strategies around risk mitigation? Yeah. So Thomas is talking about competing interests, right? We've got to get operations back up and running. We've to start, you know, we're down. We've got to continue making money. We've got to maintain these relationships versus, you know, the investigatory and evidence collection and kind of legal and broader business risk side of things. It's hard to overstate how much failing to do the latter can have a longer term impact on your business. And what I mean by that is obviously when we're investigating a security incident, we're trying to put a frame around what was accessed, what was impacted, what was exfiltrated. And if we don't have the evidence to do that, then a potentially non issue, right, or a non notifiable event can blow up and be like every single person in your network, right, every single record that you have in your entire database, right, might fall into scope just because we we, you know, wiped one server, we took made one misstep, right, you go from, like, a non issue, you know, like, close it up and move on to like an eighteen month issue where we're talking to regulators and, you know, we're notifying people and we spent a million dollars on, you know, notification and data mining. Right? So, you know, yes, the business is the priority. Right? Getting ops up and running. But just for those of you in the war room, just know that, you know, we've got to be very, very, very careful in how we do that. I think I I think I just said exactly what Thomas said in a different way. *****, I apologize. Where am I at on time? Ten thank you, Andrew. You can always count on the back of the room. That's good because I had another question. So with that being said, what are the biggest mistakes you see? What's the biggest pitfall? If I could avoid one thing or you wish I knew one thing as I'm building a preparedness plan or I'm in those first couple of hours in the war room. Make sure anybody with with access that's that's on a technical team, that's on a security team knows your incident response plan isn't going to just start pulling plugs and wiping systems and, you know, trying to get things stood back up. Right? There's a process. And if the people if the people in the room aren't aware of the process, that's where you're gonna make massive catastrophic mistakes. Speaking communicatively, I mean, I I should not be still saying this. I mean, we've we've been giving these talks for a number of years, but you would be surprised by the number of clients who, similar to my earlier anecdote about the company who sent out the blast over, you know, the concerns they had of their environment. I mean, we speak to executives who on that first call are just, like, flippantly referring to the incident as a breach. Think our legal team said the same thing. That's a bad word. And, I mean, it is a bad word. Right? There are legal consequences and implications that come with using that kind of word. I mean, I I physically wince when we get an email, right, from a part of the the CERT team that uses the term breach because, again, we're thinking about should this become subject to discovery, the million dollar question in the minds of plaintiffs, attorneys, or regulators is gonna be what did you know and when did you know it. Right? So incredibly simplistic, but like, please for the love of God, don't use the word breach. You've learned anything today. It's just generally and and that's for, you know, something like a ransomware. Right? We have had instances, not often, where it's been a ransomware that's kicked off and it doesn't result in a breach per se. Right? Because in essence, there's not the unauthorized access to legally protected information. So, yeah, communication wise, you really wanna have folks think through just colloquially speaking, like, what are we how are we referring to it, and what are some of the terms that we're using? And then the other point to expound upon that is just, you know, I don't think you need to rush to share information in those first twenty four to forty eight hours. I don't wanna just unanimously say for every instance that's the case, but I've just seen far too often clients who overshare, and then you'd be surprised by, like, customers and even regulators to a certain extent, you know, being relatively amenable or forgiving, but less so when you've shared something that you then walk back or say, like, oh, wait, as a matter of fact, that information we provided you yesterday is no longer pertinent or applicable. So I think it's the less is better. Right? And and you share information as it comes, and you can do it in a very systematic and strategic manner to where it's valuable to whomever you're sharing it with, but it's not, you know, here's our postmortem of of the incident itself and our, you know, CVEs and ATPs and all all things of that nature. That's gonna come in due time, but it doesn't need to come right off the bat. So have a plan, practice your plan, and if anybody in this group participates in your incident response process, know your role, right? And then be careful about when and how you communicate and the terminology you shouldn't use, I guess. So just for the sake of time, I want to make sure we have time for questions. I guess a parting word from either one of you, some recommendations or a tidbit to leave us with? I mean prepare, prepare, prepare, you know? And I think too, it's like people in this room really advocate to executive leadership, the last thing you want to do is, you know, I'm sure be asking for more money or have them do certain things, but when it comes to this sort of thing, there are just so many nuances to it that, as you said Courtney, the the most effective way to learn is to fail, and it's better that you're failing in a simulated exercise than in an actual incident that has, you know, real world, long range enterprise consequences. A good cyber security attorney is a great tool to have. We are your allies. I know historically that's not really the consensus. Right? We're there to we're there, you know, we're we're seen as as complicating your job. But like I I mentioned earlier, a good cyber security attorney is coming in as an outside third party fiduciary, right, to reinforce the things that you know about your environment and enterprise are lacking. Right? And so finding a finding an ally like that, I think, is extremely valuable. And that's I'm not talking about just us, whoever you find. That's a it's a good tool to have in your toolbox to have somebody out there who can speak the language and who carries some weight and who can come in, you know, after the fact or come in as an outside party and kind of reinforce the things that you need from your organization. No. I love that. I think oftentimes we miss the importance of building trust in a community and that allyship before the event happens. I often see in the incident commander, you know, response role that we haven't built those those external arms or levers to pull to support us. Well, I thank you both so much for all the information. I'd love to open the room for questions. Oh, great. Wonderful. You weren't the fastest. But he sat in the front row. Yeah. It's gotta be worse than the best. Hi. My question is around kind of what you guys have been talking about in terms of restricted communication early on. And I'm a I'm a cyber security with a huge background in all this stuff, but I come out of the defense space, so my perspective is maybe extreme. Right? And it and it lends it tends towards the the action of you should over communicate early to give your partners the opportunity to to restrict the attack from their side to ensure that there's not pivotability. Right? Because I in my experience, that's the best way to sustain the relationship and not burn that bridge in the long term. But what you're saying is kind of counter to that. Right? And that you shouldn't over communicate early. You should so my my question is, should you try to solve that technically, right, and sever the connections internally and not give the message as to why that's happening? Or should you do nothing, but that other vendor at risk for for that pivot? Like, explain. Yeah. I think the important distinction there is the downstream capability. I mean, if there are connectivity concerns and lateral movement that can go from client environment to customer environment, by no means, I think, is the takeaway that you want to necessarily be reticent that that's the case. It's just how you can think through sharing that information when you're in a period of time where you may not have all those sort of good forensic artifacts at your disposal. That's I mean, at the risk of trying to sound like we're passing the buck, it's a the business themselves know that customer relationship infinitely better than we ever will, even for clients who bring us in preemptively. Right? I mean, we're not really capable of assessing a business to client relationship and how best to foster and maintain a a sense of rapport. So by all means, I think are there variables that need to be thought through with respect to if we think this can go from if this is like a Kaseya instance where, you know, it can impact a provider and then move downstream to their clients, man, that is a mess. And, like, we can speak from real world experience of of having gone through that where, you know, waiting too late to communicate that is gonna be far more damning than preemptively communicating it in a manner where it may raise alarm bells, but everyone can kind of, like, breathe a sigh of relief after the fact. Anything to add to that? Just real quick. Yeah. Any sophisticated partner or client or customer or whatever is is gonna more than likely have notification terms in their MSA or whatever contract you have with them, right? So that's going to control at the end of the day. And so my point here is know what those are, right? Catalog those notification requirements on the front end so you're not like doing a huge document review while the bullets are flying. And then if you're on the other side of that, make sure that that is in your contract. If you have control over the paper, make sure that that's a term that you include in your contract. Cool. We have one or two more quest time frame, one or two more questions. So we're talking about time stamps. We're talking about different third parties, maybe, I don't know, the FBI, cyber attorneys. There's a lot of moving parts there. How would something like, Ready1 be a good repository for bringing in the attorneys and bringing in all your internal folks? Are you a plant? Are you a paid spokesperson of the company? We've we've we've never met, Thomas. No. I mean, I think it speaks to just general preparedness. Right? I mean, for edification of people within this room, a platform and a product that basically equips an organization to from everything from, like, a document management repository perspective to out of band comms to, you know, being able to exert control over privilege and communicative escalations can mean everything, literally. And it definitely can make it a little bit smoother of waters when you're going through the more catastrophic events versus having a million different work streams where, you know, it's harder to have visibility into each and every one of those work streams. Right? Anything to add to that? CEOs love being on 12 different email chains in the middle of a ransomware incident, you know? So, yeah, I I think having a product like that, whatever product it is, but especially one where you can kind of organize things, you have critical documents and just kind of put everything in the same place is great. We've heard many a times a CEO or an executive say, well, that wasn't communicated to me, and they're like, well, it was, it was just in one of, you know, three dozen emails that have come through in the last thirty five minutes. Yeah. So you had mentioned that words like breach shouldn't be used. Is there a list of words that would not be legally defensible that you could share with us and alternate terminology that might be better? It's funny, I mean, great question. Think system outage, right? It's like once you become privy to this thing, and now it's funny because you'll go from thinking that something may sound relatively innocuous to then seeing a term like a system outage or a network wide disruption. And Ryan and I, you know, with non clients will see these general holding statements, many of which resemble what we would draft and we're like, yeah, that sounds like a ransomware, you know. But it's it's better, right? It's it's more advantageous to have someone infer that versus them definitively thinking, oh wow, this is like a breach, which again suggests, you know, that you've you've lost data, if you will. So I think network disruption, system outage, security incident, I mean, all very simple sounding stuff, but far better than breach, ransomware, and, you know, it happens. Like we've said, people even in today's age are still using those terms right from the jump. I I was just going to say, ideally, I I think the message for this outbound external communications piece is just get as far get as much on top of the issue as you can before you have to start having the conversations with people outside of the organization. Right? Know as much as you can. Try to get it as under control as you can because then you're much more in control of the narrative and you can come out with a lot more positive facts to say like, hey, this is our response, we're killing it. Right? We're like on top of it. Yes, we had an incident, but look, this is all the stuff that we've done in the interim between then and now. So I I think that just puts you in a much better position. I well, I I know we're out of time. We'll take we'll have a whole conversation on language to use and not to use. I can there was actually one other point John made before he left, which was, around when do I sever ties with my partners or clients or how connected do I stay. Previously on a panel, we were asked the question around where's the trustworthiness to reconnect? And we talked a little bit about kind of predetermining that as part of your contracts and your agreements, your partnerships ahead of time. So what are the attributes that a partner might look for when they wanna reconnect after a severe incident? Or or what are the kind of trust or safety that they'd be looking for? So something to predetermine ahead of time so you can kind of speed up that process too. But we'll take that question offline because we're between you and lunch and we know. So thank you guys very, very much for all your time and your questions. Thank you both so much. Thanks for having