5 Gaps Exposed In 30+ Real-World Tabletop Exercises - Ashu Savani

So, I get the the fortunate exercise of warming everyone up 10:00 a.m. 10:00 a.m. in the morning. So, hope everyone's buzzed. Everyone's had their coffee. You know, I had my coffee. So, super caffeinated. Excited to chat to all of you about tabletops. So, through the So, you'll occasionally see me look at my phone. That's not because I'm bored talking, but that's because I have a timer and I have some notes. But I'm excited to chat to you around everything we have learned in the past six months. So generally I'd say my recommendation is to a lot of people working in sock and IR teams is do more tabletops, right? Very similar to a fire drill. You want to be prepared for what

happens, but there's technically no way to do it unless you're constantly testing your muscle, unless you are constantly getting better. and we've had a amazing experience running 30 tabletops across a whole bunch of clients across a whole bunch of industries and I'm really excited to share the learnings uh today. So I'll talk a little bit about who we are, who we worked with, what did the methodology look like and we'll cover five key gaps we have seen across the across the the clients we've worked with. And generally I'd say it's been really interesting because we've worked with a very diverse set of clients and even then we've seen a lot of key consistencies and gaps come out through

this process. So a little bit of an intro about me before we jump into more of the fun and exciting uh work that we're going to talk about. I'm the co-founder and co-CEO of Try Hackme. For those of you who don't know TrackMe, we're the largest cyber security training platform out there with 6 million plus users signed up. Uh we work with 900 organizations globally across a various set of different industries. So I h I have my joy of spending time with amazing sock IR security leadership globally and happy to answer any questions around things we've seen, how they operate, what sock and IR maturity looks like. Before try hackme, I did security consulting and pentesting at a

small but amazing company called extent called context which was then acquired by Accenture and I have a background in computer science. So nothing too special or exciting there. So over the past past probably 6 to 12 months we've worked with more than 30 clients to run live tabletops for them. Just to give you an idea on what the scale and the diversity looks like as this will influence how everyone perceives this in the room. We primarily work with people across uh Europe and North America with some distribution of of teams across the Middle East. We work with all shapes and forms of companies and security teams. So everything from you know uh a 10person generalist cyber

security team all the way to a mature sock and IR team that has different teams on you know triage detection engineering instant response and all shapes and forms of different companies. So every everything from you know small MSSPs all the way to large manufacturing financial services companies and I'd say the the exciting thing for me is despite all this variations right you have orgs working with different tools you know people working in a different regulatory landscape and people working with different threat models we saw same five at least at minimum five persistent issues come up over and over again right and to me right this is great because it means that at at a certain baseline. A

lot of a lot of the the sock and IR teams we work with have very similar gaps. Just to give you an idea on how we ran our tabletop before diving into the methodology, I'll give you a quick 30 to 60 second summary of a tabletop. Like I said before, the challenge with working in sock and IR is it's a very reactive environment. Things are changing every day. Attackers are getting better. Unfortunately, most of the teams I know or the ones we work with, the way they test their readiness to security issues is by getting breached or or or having an incident. Ideally, we want to prevent that, right? We want teams to to to know how to

confidently respond, how to coordinate their crisis response, and how to deal and feel ready when an incident comes comes across. The way they do that is through tabletop exercises. You can have different variations of tabletop exercises. You can run some with management that are called crisis management. uh you can run technical hands-on keys ones the ones we have run are with sock and IR teams and they're very scenario based right the way we run our tabletops is by aligning them to the instant handling framework so we'll start with the scenario we'll cover everything from triage all the way to containment eradication recovery and then we'll walk through three stages of an attacker life cycle starting with

initial access lateral movement and privilege escalation and goal execution and that could be the goal execution could be things like deploying ransomware exfiltrating data and and all sorts of scenarios and typically what we'll do is we'll sit down with sock and IR leadership and talk about what exactly they want to test. Uh typically this is mo most of the teams will either run tabletops for two or three reasons. One of them tends to be compliance. So if you're in a regulated industry you need to show that that you're you're you're prepared for incidents. Most of the time teams don't really have or or they're not doing a lot of updated work on their IR playbooks. And as as

everyone knows right when things happen in an incident that are high pressure the way you follow process and procedure really matters. So a lot of these organizations will run tabletop exercises to test do your IR plans actually hold up in practice. Uh so once we define those objectives we'll then think about the scenarios. So typically the scenarios will relate to something sock and IR leadership care about right it's typically going to be what does your thread profile look like? What are your threat actors in in with within the context of your industry? And three, right? Like you may have had a previous incident that you want to recover and learn from. And you want to test post

incident, have we actually made the changes we said we we set out to make. Once we set all of this up, we'll handle all the logistics. So we'll figure outing, who's available? We'll run these tabletop scenarios. Typically, they can take anywhere from 30 minutes to to 3 hours. is it really depends on how much time you have, what the investment in from security leadership looks like. And essentially the way it works is it's very scenario-driven. The point of the tabletop is really get people on your team to talk through how they would deal with an issue. And this is everything from what alerts are we triaging to like what are the right containment eradication recovery actions. And

towards the ends of the scenario, we'll have a a a debrief session, right? talking through what gaps came out, what do you actually want to what changes do you want to make of it and how do we think how how effective did we think the team was at responding to a particular scenario and for me right the the aim today is is really making sure that someone comes out learning something and I hope it's it's engaging enough for you because I think two to three things will happen right one is you will either see something and you will relate to it and confirm that this is the case in your environment or you will think about

something that you really haven't thought about before, right? And the aim is aim is to to be very thorough around sharing our learning. So we want to do a couple of things. So through each gap, we'll talk about what that highle attack scenario looks like directly from the core tabletop we ran. We'll talk about what we learned. So how did how did the sock and IR teams react in that scenario? uh what did it expose around the gaps around the way they worked and we'll talk about a practical fix. I think the exciting thing about this is we were with clients in the room in most cases facilitating these exercises. So we got a real world view on how is the

teams think they are going to respond during an incident. So, in an effort to make this reflective, but also fun and and hopefully engaging, I have a QR code to menty, which is basically just a polling application. So, across across the slides and across my talk, I'll have different prompts up for polls you can join. This should be super easy. It'll take like 5 seconds of everyone's time. It'll help us understand one like how are our peers really thinking about these problems and two set enough context into the scenarios that that that we are going to talk about. Cool. Let's start with poll one. So in a real incident, how closely does your team actually follow the written IR

plan? Cool. So we should see the results come true.

I'll give it maybe 30 seconds for people to take their time to listen.

Cool. Surprisingly, this is very similar to to to to what we've seen working with our clients. And hopefully this this G gives everyone an idea on for my peers who work in in sock and IR who work in security leadership what what is everyone doing out there or how are they behaving on their their day-to-day environments. So we can see that most people are either referencing elements of their IR plan or relying on on experience. And we see a few people who aren't uh who either have a plan but don't get time to test it or really depends on who is in the room. And I'd say the the last point here is fairly common, especially with teams that have

sock environments distributed globally. I'm sure a lot of you know that various sock teams have a follow the sun model where you'll have teams based in either Europe, America, Asia, Pacific. And one of the challenges there is how do I standardize how one sock team that is distributed globally responds to incidents in the exact same way.

Cool. Let's go on to gap one, which is very similar to what we've seen. What is the plan versus the reality gap? So, the first scenario we ran was with a large manufacturing company that had uh a billion in revenue. So, these numbers to some degree just show the scale at which which these companies operate, right? That's just there as a framing reference. So through this process, the scenario that we were talking about was typically what you see in a lot of environments, right? Where a sock will open, right? They'll have a typical Tuesday morning, but you'll see an alert for anomalous access across some of your systems. This is typically fine, right? When you see anomalous

access, you typically have an idea on how to triage it. So what was really interesting here about this was we had I think around four to five analysts across L1 to L2 in the room with a sock leader and it was quite interesting because we got three different responses from three different analysts on how they would triage this right so one analyst would say you know this we've investigated it this looks very suspicious we should block it you know another one says oh you know in my experience based on this alert type this seems very common could it be false positive, what do we do? And a third one, a third one goes in the middle and

says, "Oh, you know, we don't need to take any extreme action. Let's just investigate further." And if everyone's ever worked in a soccer and I environment, hopefully these conversations feel feel very normal. And I think the what I wanted to highlight here was very interestingly, similar to what we saw on the poll, we have teams here acting on experience and gut feel. And for most of cases, that's fine, right? If you're an experienced sock and IR team, if you've gone through various incidents, relying on your gut or experience is is not wrong. But I think what we do want across high pressure situations with a sock and IR team is consistency. Right? We want confidence

that everyone is working off the same procedure. They're using that same mindset all the way from triage to containment eradication recovery. And generally right this was quite interesting because when we started the exercise we had the sock and IR leader you know give them like we had a prep call with them and they essentially said we do have playbooks and we do have runbooks before this exercise like everyone should refer to these runbooks. But what happened in practice is everyone thought they were aligned. Everyone thought that they would they would triage the issue in the same way. They would investigate in the same way. And what was even more interesting was the documentation did exist, right? But

no one was actually referring to it. And the challenge with this scenario is maybe with a small sock or IR team where you're incredibly well coordinated, maybe you're in the office, you're chatting a lot, you can work through it, but in a high pressure situation where you know, you may have a distributed team where you may see an alert that doesn't exist in your environment, that ambiguity is not very good, right? because it just means that it gives the attacker more time especially if it is a core security issue and generally I'd say when running tabletops or even more frequently as an organization you should think about one like do what kind of runbooks exist two what do what do the

quality of those runbooks look like and three are people actually reading them right runbooks and playbooks typically are this thing where you have it stored in like confluence and jira for compliance six box you're like great this is amazing you know the auditor is not going to call me Uh but the reality is we want people to to to drive consistency. Runbooks are not the only way to do it, right? But they're they're one way to make sure that the team is working off the same baseline of knowledge. And generally with a lot of the sock and IR teams we work with, when they think about continuous improvement, typically they'll think about updating their runbooks or playbooks quarterly and

they'll have a target, right? will say based on the detections we've seen, based on the threat actors in our environment, we have like a quarterly improvement plan of making sure that our runbooks are updated where we're covering scenarios uh that that we don't and then three, more importantly, everyone feels comfortable and aligned on what that looks like. Cool. Moving over to scenario two where we'll talk about more ambiguity and we'll talk about escalation. Where do we what most often delays escalation in your environment?

Cool. Is everyone able to move over to the next one? Okay. Feel free to if you don't want to participate, obviously totally fine, but just want to make sure it's all working. Okay. So, I'll give it a couple of minutes. Nope.

Okay. Amazing. So, we have most of the spikes on waiting for more evidence, which I think is a very reasonable and very rational response. We have some on unclear ownership which is great because that's what we are going to talk about and a few on management approval and the fear of overreacting. So I'll just move over to the slide. So the second gap we saw was ambiguity on decision-m and the framing for this is we're working again with a financial services company that had uh more than a billion dollar in revenue and the way the scenario unfolded which is obviously typical in any environment but more than financial services is starting with an alert from a fishing email that leads

into a malicious file execution. And I think what was great about the team was was their their the way they investigated, right? So they went through this triage, right? They they looked at where did the email come from? They looked at what inbox does it land at? You know, they tried to find evidence of malicious file execution. And as they're going through that process, the question that comes up is what do we do now? Who owns this? Right? Like we have all this data, right? We sort of we sort of know what is happening here, but who is taking ownership over what happens now, right? And how do we escalate? And I think again tabletops are great because

they're supposed to expose what is happening on on real world organizations. It's supposed it's it's it's supposed to expose what happens when you when you see an incident you've never seen before. And the challenge we saw was there was a lot of I like to funnly call it uno reverse is people ping ponging off each other saying you know are are you going to do this am I going to do this what is our escalation procedure look like who actually formally owns this this incident and again these things are about optimizing decision-m right like ultimately when you're when you're facing an incident you want two things you want confidence you're making the right decision and two

is you also want to make sure you're moving quickly right and I I think what was what was really interesting about this was without that unclear ownership in an incident that would have taken a while and would have caused confusion around how you move forward. And the challenge is when when this incident could be complicated and high severity. You don't want people to to to be confused, right? And two is generally depending on how your IR plan is structured or what your processes look like, you want to get to a stage where like escalation is very formally defined either based on the severity of of an alert but also once you do go post escalation like how do you know who

picks it up right you have someone that owns the incident especially if you're multiple people working on a key sock team and generally the conversations we were having with our client was how do we reduce ambiguity right if the if if the entire Our challenge is we want a really good process where people know what to do where the stages are streamlined where coordination and communication is important like your IR plan should actively talk about who is going to like what is good escalation look like how the criteria very specifically split out and two is if if this does get escalated who is going to take ownership of this right there also a lot of other conversations that we

were having that depends on like the size and the maturity of the team so if your team is either built with juniors or If you if if you have an MSSP working uh working with you, we talk a lot about like what does a good shift pattern look like? How do you build confidence and psychological safety for your team where they do feel confident coming to you when they don't know what they're doing? But generally a lot of the the key learning here was oh you know we realized that we don't actually know what to do if things look terrible. So how do we better work towards that? So, step one is making your plan very clear

and reducing ambiguity. And step two is like let's practice, right? Like I'm a obviously big proponent of tabletops or fire drilling. And these don't have to be long or complicated. They could just be quick 15-inut scenarios as you were spending time with your sock team saying if this happened, what do we do? What does that look like? Cool. So lesson three talks more about how do we get better postr running tabletops or even postr running incidents. Generally I'd say from the teams I work with there's no structured process on what happens post incident right typically you're caught up a lot in the firefighting there's a lot of pressure but how do we learn from this

and how do we make sure what what is what is actually happening. So in this case we were working with a an auto automotive manufacturer and a lot of our scenarios previously focus on initial access but this scenario basically went through an end to end kill chain right where an attacker got initial access to an AD environment right they were laterally spreading across across different users and they were at a point where through the attack scenario the team was essentially saying oh you know this this attack vector actually requires like deep forensic skills like what do we do We've never actually reached this scenario in real life. So if it was I think the scenario was to do with

examining registry keys on Windows machines and and what that complexity looked like and this was great, right? Because the team really found out and figured out that you know we're not at the stage where we can do like deep forensic uh analysis. So how do we how we how do we do better here? And what I thought was very interesting was as a team is going through this process, it's really clear they're identifying their gaps, right? They're self-aware. They're saying we don't know what we're doing here. Um this is like a really big gap for us. If this actually happens like what are we going to do next time and the challenge was there was no follow

through on this and I I I think this is this is very common across environments right is you identify a gap you identify learning but what happens that just that gap disappears into ether and when the incident actually happens you do have flashbacks that oh you know we spoke about this but we did not get around to this. So generally right this is I'd say like a probably a key learning that all of you know is like I think structure and follow through is quite important some of the best teams or the most mature teams we work with have a really good process underlying this right so if it's post incident or even if it's

through a tabletop if a gap comes up have a really good process on noting all these actions typically what what what we would do in tabletops is it doesn't have to be this complicated but you'd have a facilitator running the tabletop and you'd have subscribe. So there's someone on your team or it could even be someone with the wider security team just listing observations, right? They're just writing down, okay, I noticed, you know, X person didn't do this. Y person said, oh, you know, we don't have the skill set to do this. So there's someone actually being very thorough on documenting what what is it that we didn't learn. What is it that we're not confident doing? To be more

specific, most of this would then end up in like a Service Now backlog or a Jira backlog with owners attached. And typically you depending on the organization and the severity of what you found you'll have SLAs's attached to this right but generally what we do want is we just want more structured learnings right we want to make sure if we've identified something and we've we've understood that something like this is critical how is it that we make sure we're consistently actioning actioning this and actioning what what comes out of these core tabletops. A lot of this a lot of the the learnings here also apply to post incident reviews, right? So one thing for everyone to

reflect on is what is your post instant review process look like and how are you making sure that as an organization you are learning and you are getting better. And generally again like consistently test right if you've identified failings as an organization don't wait for an incident to happen to show you that that failing was not fixed. Cool. We'll move over to another poll. So, how well does your sock or IR team know the legal contacts that you'd work with during an incident?

Cool.

These are these are pretty good results for the 13 that said we work together regularly. I would love to buy you lunch or a beer because this is amazing. Um, so I'd say like before jumping in here, a general learning I've noticed with especially when working in regulated environments where you do have you do have a legal obligation to notify a notify a regulated body. This could be the ICO. This could be the SEC. People are very scared of legal teams, right? They I I I don't know if everyone watches too much suits, but people have a very different perception of what lawyers look like. And and what this means for the for the for

for how you're working, whether you're going through a tabletop or you're going through an incident, is that either that the fear of of of what a legal notification looks like or even what the implications look like for a company, prevent people from thinking through what that looks like. the best sock teams I've I've worked with, they'll essentially say, "Oh, you know, Dave, our legal guy, literally sits behind me and even though like we're not at the stage where we formally declared an incident, I'm just going to give Dave a heads up so that if this does evolve, Dave is not caught off guard. We have an amazing working relationship. Dave knows exactly how the sock works. He knows

exactly what our escalation and IR processes look like." And gen going back specifically to this scenario again this was so this was actually with a government or a defense organization and and what we saw through this process was that the team was amazing at at at what the technical analysis looked like. Right? So the scenario was around data xfill. You know we walked through how the thread actor got access to the environment. We we spoke about what how do we detect what data expert looks like and went through the full instant handling life cycle. But what happened was when we reached the end of the exercise, someone had to prompt saying oh this did we actually look at

what data was excfiltrated? Did we figure out whether there was PII on there within the context of our organization? Is is is this a challenge? Right? like do we have are we aware of like all like the legal and and and compliance considerations as part of the exercise? And I'd say the key learning here was right for teams that are technical that are amazing that that that really know how to go through a full incident life cycle sometimes legal and compliance can become an afterthought for a whole bunch of reasons right so one is generally teams teams aren't aware about this right you see times where like the the the the regulatory landscape does change

quickly a lot of the teams I know were taken back by the SEC disclosure uh early this year or late last year uh some people just don't have a good working relationship ships with their legal teams and and three they don't really understand at what point of an instant life cycle do I bring in our legal contact right like what does an escalation look like and a lot of people think it's binary right like we either do it or we don't and if we tell the legal person it's going to be terrible but I think the reality is as everyone knows incidents especially through the investigation stage are not that binary right there'll be times where we won't

know the outcome and we'll have a lot of unknowns and I think what really helps is one really building a good relationship ship with uh with who handles what in this case could be like PR and and and legal notifications trying to understand for them right like what are our obligations as a company like when do we truly need to let people know what considers a risk and three right for those who are ready to do this bring them onto your tabletops right the tabletop doesn't even have to be formal you could just bring in your your legal person and say oh you know hypothetically if this happened like what would we do like what would you

want to know what do you care about like what decisions do you want to see. So to me the the root of of of this is just how do we build good relationships with cross cross functional partners who are involved in an incident right incidents typically start technical they start with a lot of unknowns we don't know a lot of uh we don't have a lot of information around it but as as incidents unfold we go more from from incidents to crisis management right like do we think about what marketing has to do for like any PR notification do we think what legal has to do we know what the escalation paths look like for

us to raise this to senior management so As much as we focused on on a legal example here, I think the food for thought is as incidents get worse, like what are your obligations to the organization? And have you actually thought through what that looks like? Do the people involved know what they have to do as opposed to just looking at documents?

Cool. We'll move over to the last scenario to do with crown jewels. So, a question for everyone in the room. This could be yourself as a sock analyst. It could be your teams, but does every analyst on your team, can they clearly name what your top three crown jewels or top three most critical assets?

Cool. This is one that probably has an even even spread, which I think I I think reflects the reality of of the the maturity of the teams and and how they're built, right? But yeah, for for those people that that are anywhere from absolutely mostly some good, that's amazing. For people that are probably not, definitely not, we'll talk about why this is important and and where we see the main gap. So we ran a we we were running a scenario with a global MSSP and I think the scenario was unique in that it was very tailored to an MSSP. For all of you that that obviously know how MSSPs work, you know, the environments can be quite

chaotic, right? You have, depending on what your setup looks like, you may have clients on different SIMs, right, with different infrastructures and there are days in which everything goes haywire, right? You have different alerts coming from different clients like because the clients are so unique in their infrastructure, in their threat model, the way you prioritize those alerts is very different, right? And from a and if you think about it from like a sock analyst perspective, so from someone who's on an L1 or L2 role, what you will have is again depending on how your your your your MSSP or MDR is structured, depending on how many clients are allocated to different different teams, you basically have a ton of volume

coming at you and the question becomes like what is actually happening, right? So one is you have different environments. two within the same environment where you do have complex attackers, you just see alerts flooding through, right? And the question becomes like what is what is actually happening? Like how do we know where we start? How do we know what alerts we care about? And what one of our key learnings here was was not just about crown jewels, but do teams really know the criticality and business impact of what's happening. Right? An alert that is on a server with PII might be very different from from an an alert on a dev server that has no

credentials. Right? So as much as again like sock teams and I teams are very good at at thinking through you know what do these technical investigation steps look like the the main disconnect comes between identifying the business problem right like how do we connect what we're seeing what the attacker is trying to do within what the impact of that business look like and I think with large complex organizations that don't uh that are only recently investing in security they may not they may not have true aligned definitions on what critical assets assets look like, right? I think the one the key learning here is like is your organization generally aligned on what we care about from our like digital

infrastructure critical assets. Two, for the people that are part of a crisis, right? These are like stock analysts. These are are our our people involved in crisis management, do we understand the decisions we take when it comes to building when it comes to triaging issues to do with our our crown jewels? And I say generally, right, what typically solves this problem? It sounds very simple on paper, but we we all know it's not. But as an organization, do we know what assets exist? Right? From the from the leaders I've spoken to, this is a very painful exercise. And if you're working on a large corporate organization, you'll probably end up in a black hole asking who owns this

domain, asking where this IP address comes from. So step one is obviously you want like a good asset inventory but step two is really thinking about based on your your company your context your threat model like where will attackers go and what do we care about as a business and you really want your sock analyst to think in terms of this perspective right you want them to know with everything that's happening what is the business impact of this look like how do I use this business impact to make decisions and and three is uh three is just just making sure that on the dayto-day as the teams are are working through their alerts, working through their incidents, they're tight

feedback loops where they're just thinking about what their criticality looks like. Cool. And generally, I'd say if anyone has to take anything away from this, for me, it's talk to your teams, right? Like tabletops are not these like big scary things that you have to like get 100 people on that takes you like weeks to do it. A lot of this just starts with, hey, we had this alert a couple of days ago. What would that what would that look like for a variation of an alert? Right? So that alert could be fishing that ended up in a malicious file execution. But what happens if that malicious file execution was a ransomware? What would we do? Right? U

talking through like having a really good culture on on encouraging these learnings, having good follow-through from these learnings. And and three is think about the entire business, right? stock teams that are ultimately doing a lot of firefighting and that can be very reactive. When it comes to crisis management, a lot of that is going to be dependent on, you know, knowing who needs to be involved, the relationships you're building and two, just having a really good rhythm where if the if this did happen, you know, how to deal with it. But it looks like I have finished 11 minutes early. So I appreciate everyone for listening to my listening to to to all the learnings we've had. I spend a

lot of my time with sock and IR clients. So if anyone has any questions, it could be on tabletops. It could be on how teams are working. It could be anything else. Feel free to either grab me here or grab me after. But yeah, I think we have a few minutes for questions. [applause]

Does anyone have any questions over here?

>> Hey there. Thanks for the talk. Um, so obviously real world incidents can take days, weeks, months to go through. when you've got such constrained time for tabletops half an hour 3 hours how do you convey the concept of time uh to the analysts to the team that you're dealing with do you have any tips on that >> so the question is how do you convince your team to spend more time on this >> so it's it's more a case of sorry there you go it's more a case of um real world response takes a long time how do you convey the passage of time and how that affects your response when you're doing a tabletop

Yeah, that's a great question. So, does does everyone know what an inject is within a tabletop? Okay, amazing. Yeah, so what we would typically do is like for those of you who don't know, an inject is basically just a scenario or a change in scenario. And like you said, we we we we really do want to reflect what attackers are doing, what we do see is instead of communicating how long something takes, we add more urgency to it because typically what you want to do is prepare teams for the unknown. So what we'll do is when we run tabletops you basically throw a curveball or an inject saying oh you know you're now triaging this like oh fishing issue but

the attacker is actually four steps ahead and we've seen evidence of this. So less less advice on on oh you know an incident takes time how do we convey this? For for us, we want teams to really care about urgency because that's typically what happens, right? You want to prepare them more for the unknowns as opposed to the known. Did that answer your question? >> We have a question here. >> Uh, hi, great talk. So you talked about so I teams responding to the crisis and tabletop exercises but what's your experience with the board and leadership uh when it comes to tabletop and how do you think we can uh utilize this to educate them also especially with the

fifth gap that you discussed about >> that's a great question so I can I can speak to some hypothesis because we spend more time with with with with sock and IR teams but generally what happens is most companies especially that are regulated will run annual exercises with with with their with their leadership team. Typically, this is driven by regulation. In some cases, this is like a board mandate because security is now starting to get uh starting to get get more recognition on on the role it plays really securing a business. And I'd say generally the like unfortunately what is really helping security leadership do more exercises and prep more is all the incidents. So with the companies we work

with you know when we see when we see some industries get hit by like thread actors more than others what we'll see is we'll see a spike in conversation saying oh you know we saw what happened to this like I don't know retail financial services industry we need to prepare there so unfortunately part of it is still reactive and is driven by by what is happening in the in the threat landscape. Think we have one more. Got time for one more question.

>> Quick one. How much demand do you see for more interactive um exercises? Um is there any interest in >> When you say interactive, do you mean more like technical hands-on or more facilitator driven? >> Yeah, more more hands-on, more kind of Yeah. >> Yeah. I'd say the ones that are are more hands-on are driven by more mature teams. So to me, the definition of a mature team are probably teams that that that are are they have specialties within their sock team. So they'll have built out like detection engineering functions, built out IR functions, built out sock functions. And two is these are teams that are in regulated environments, right? Right? So if you're like a bank, insurance, healthcare

company, and three is if you've run uh if you've run red teams or purple teams, then that demand is going to be higher because the the more technical tabletops are cheaper and scaled down versions of this. So I'd say the the challenge is right most people don't feel comfortable jumping to I'd say like on a scale of 0 to 100, jumping to 80, which is a technical if you've not actually done a a hypothetical tabletop because you may not see the value in it, right? Cool. Well, thank you very much, Rashi. Brilliant talk. And the next talk is at 10:55. Thank you very much. Thanks for your time, everyone.