Beyond the Breach: Why Your Tabletop Exercise Should be Your Worst Nightmare

Hello. Yeah. >> Good morning everyone. Uh how are we doing today? >> Okay. Welcome to besides Las Vegas and this talk is uh mainly be on the bridge. Why the table tabletop exercise should be your worst nightmare which is given by Madison Richa. And before starting the event, I would like to a few announcements. We begin and our our sponsors would like to thank our sponsors especially our diamond sponsors Adobe and our gold sponsors uh Farm and Run Zero. It's their support along with other sponsors, donors and volunteers that make this event possible and and these talks are being a streamed live as a courtesy to our speakers and audience who like to ask please keep your phones

in silent. All right, now the stage is yours.

All right. Hi, welcome everyone. Thank you so much for coming. Um, I just want to go over a quick agenda of what we're going to talk about today. So, I really want everyone to understand what a tabletop really is. Then we can talk about what we're going to be testing during that tabletop. Um, and then we're going to go over how you can have a holistic approach to your tabletops. Um, we're going to talk about maybe some key objectives that you want to look for in that exercise. Um, how to craft challenging scenarios and then we're going to talk about some of those post tabletop exercises that you should be doing. Uh, just a little bit about myself. My

name is Madison again and I'm a senior consultant at CAI. I work mostly on the offensive side of things, so pen testing and red teaming. I've done a little bit of blue teaming, too. But I've also spent the last um few years writing and designing tabletops both for government agencies as well as in the private sector. And just on a personal note, I'm a huge animal lover, so if anyone sees a dog, I won't turn down petting it. All right. So, I just want to talk about um what a tabletop exercise is. Can I just have a raise of hand? Who's participated in a tabletop exercise before? Okay. So, we have a lot of people in the

audience. Um, and did it go good for you guys? Was it smooth? No. I'm getting so So, yeah. So, really a tabletop is an exercise that's structured to it's a structured discussion that's supposed to be based on a specific scenario and it's going to allow you to test the different policies, plans, and procedures that you have set into place. and it's going to help you to identify any sort of gaps before an actual incident should occur. Um, just to talk about um, what we're really testing here. So, there's three things that we really want to test. We want to test our incident response plan and that's going to test really how we respond to an incident. Um, it's going

to talk about our runbooks, our different escalation points, our points of contact. So that's really the plan for during the incident and it's where we're going to detect, analyze, and contain. And then we have our disaster recovery. Then we have our disaster recovery plan and that's going to test which of our systems are able uh to be maintained when infrastructure might be severely impacted. And that might reveal how quickly our critical machines can also be restored. Um, and it's going to allow you to test your different backup procedures if you haven't tested them before. And then we have our business continuity plans. And our business continuity plans are going to help us to test how our organization can maintain

those essential operations during a period of downtime and how long that can go on for. Um, and it's also going to make sure and determine if your core functions like payroll, finance, HR, and different um, departments like that are able to function while the rest of your systems are down. Um, so I want to talk a little bit about a holistic approach to tabletops. So really a tabletop exercise is beyond purely just a technical incident. It's really something that should involve our entire company. um the IT department is often central to that incident, but real world events affect whole companies, not just the IT department of those companies. So, it's really important that we get different people from

different departments um who are able to participate. Um does anyone have any ideas maybe of people who you think should be involved in a tabletop exercises? Maybe a department or two. >> Legal department. Yeah, that's a good one. Anyone else? >> Public relations. That's another really great one. >> Sales. >> Sales. Yeah, sales would be great. >> HR. >> HR. Yeah, definitely. So, those are all really, really good um answers. That's a lot of what I'm going to talk about here. So, first we have our IT and security department. That's who you really want to make sure is there because they're obviously central to that incident. They're going to help to manage your infrastructure and your

system recovery. Um, they're also going to be the ones who are providing that insight into your detection, your containment. Um, and they're going to be often the leads of that incident. So, even if they're not the ones who pull the final trigger on the call, they're the ones who are going to take charge and make sure that everything is running smoothly. And they're also going to be the ones who are going to advertise on that threat intelligence that they may have collected beforehand to help with a better understanding of that scenario. And then we have our legal department, which I know was mentioned, and they're going to help to add to advise on any regulatory bodies that you might need to

be in compliance with. For example, if you're a hospital, an incident happens, you need to make sure that you're still following HIPPA. Maybe you have some sort of business in Europe, you need to make sure GDPR is still being covered. Um, and just other regulatory bodies. They're also going to coordinate with law enforcement oftent times. So, they're the ones who are going to be talking to law enforcement, communicating with them, making sure that they understand what's going on and pulling them in when they need to be involved. Um, but they're also going to help with your cyber insurance. Oftent times there's specific steps that you need to take in order to get that money for

um an incident if it does occur. So, they're going to make sure that all of those steps are taken properly and all of the right people are involved. So, in the case that you actually do need some sort of money or help with recovery, you can actually get that from your insurance. Then we have our media and communications department as well as public relations. This is another great team to have because really they're going to be the ones who are handling all of your internal as well as your external messaging um to the company. They're the ones who unify and have one voice that's going out instead of a bunch of different people saying a bunch

of different things. Um, oftentimes companies have representatives who will talk if there needs to be any press statements that are issued or if a press state needs to be released online or they're guiding the people who are going to be giving that conversation. So, it's important to have them there so they know what kind of statement that they would need to make in the case of an emergency. Um, then we have our human resources department. This is another really essential department. Our human resources department is going to address any sort of insider threat that we have. That's who we would go through. The steps would be taken through there. They're also going to help with employee

communications. If any employees were impacted during the event, they're the ones who would support that. as well as if something like payroll goes down, they're the ones who would be communicating that to your employees and trying to work out with them, you know, a payment system or letting them know when they would be paid next, when the system's going to be back up. So, it's always important to have HR there. And then we have our executive or our seuite leadership and really oftentimes they're the ones who are making the strategic decisions in the end when it's based on the business. They're the ones who oftentimes have to pull the trigger. For example, they might be the ones who are

deciding if a ransom is going to be paid or not. Um, different decisions like that. Um, they often will be that external communication to the media. Um, depending on your company that would be working with public relations. And then they're also going to communicate to your external stakeholders and your board members what's going on with the incident. Maybe they've heard about it. and they're going to make sure that they remain calm and that they're not trying to jump on everyone in IT during that incident. Um, and they're also going to make sure that you're really in alignment with your organizational priorities and make sure that your risk appetite is being met. So, it's they're the ones who are going to keep you on

track. And then finally, we have our finance and our procurement and they're the ones who are going to manage any sort of costs that are associated with that response. So, they're going to be working with your insurance company. If a ransom needs to get paid, it would go through them most likely, unless your insurance company states otherwise. Um, and they're also going to help to track those financial impacts of the actual incident itself. So, they're the ones who are going to assess how much it's going to cost, how much the damage is going to be during an incident. So, it's pretty important to have them there as well. Um, and then we've got some key

objectives. There's a couple that I really want to highlight here, but there's definitely um a lot of different key objectives that you could go through really. Um simulated incident response is one of them because this is going to allow our team to walk through the existing plan or maybe we don't have an existing plan and we're making it up as we go. Um and it's going to allow them to evaluate how that plan is going. Um it's going to help with that interdep departmental coordination because everybody will be looking at the same plan and practicing the same steps. It's going to prepare our outside stakeholders for a cyber event. Maybe you've involved them as well. Um so that

they would know know what to do in case of an incident. And it's also going to demonstrate how to make timely decisions because oftent times every second counts in an incident. So we can't sit there and you know be confused about if yes or no or are we doing this or are we not. So it really demonstrates the timeliness of the decisions that need to be made during that time. And then we have um identifying gaps. Even the best written incident response plan is going to have gaps because there's things that are unforeseen that are going to come up when you start to test your plan. And this is really going to allow your team to re-examine the

different policies and procedures that you already have set into place. Maybe it exposes some unclear responsibilities. Maybe you have some outdated protocols. Maybe you've got some people on your incident response plan as contacts that no longer work at the company. So, different things like that would be exposed. Um, as well as it's going to help us to recognize those limitations of our technologies. Maybe we have a lack of critical visibility somewhere in our system. Maybe we need to be collecting more logs or less logs. Maybe we need to, you know, refine our alert settings. So, that's really where you would find that. And it's going to identify whether an organization has enough people to actually respond to an

incident because sometimes we have really small IT departments for really big companies and it's a lot to put on two or three people. But that could also give the IT department or your cyber department a business reason for either more hiring or more funding. So you really want to make sure you could test how many people you would need. if this is too much work for the people we have, if we need less people in the room, um that would be where you would identify that. And it's also going to help to uncover any sort of compliance issues that you have. Maybe you follow um the NIS standards. Maybe again you're under HIPP or GDPR. You might realize that

you're not in compliance with one of those as you're going through your tabletop exercise. Um it's also going to help with cultivating cyber awareness. So really it helps to shift the incident from being just an IT or just a cyber security problem to something that everyone in the company has responsibility in. And it's going to help to educate your non-technical staff members um so that they gain a better understanding of what they need to do during an incident um what an incident might actually look like because the likelihood is that they've never seen one before. Um, it's also going to help to reinforce that security culture within your company. It's going to reduce your complacency, um, and

encourage people to report things as they see them. Maybe it'll make them aware of something that they weren't aware of before. Maybe they weren't, you know, aware of fishing calls or, you know, they didn't really know what to look for on fishing. So, different things like that, different attack vectors, um, they might be able to understand better once they've gone through this exercise. And it's also going to help with that crossf functional uh department coordination because oftentimes especially in larger companies departments don't work together every day. Even if you know people in the other department you're not working directly with them every day. So it's going to help them to work as a team and that's all that is in the

end going to reduce your response time because there will be no confusion as to who needs to talk to who. um there will be no issues with excuse me there will be no issues with who needs to be called because everybody will already know what's happening and then it's also going to highlight how employees might react under pressure. So oftent times situations can be scary even if they're small ones because you don't always know what's going on at first and it can be a high pressure situation for some people. So, it's really going to highlight how your employees would react under those type of scenarios. And as managers um or leaders of a practice, once you see how

your employees are reacting, you can figure out how to best support them during that time. Um what we can do to lessen that reaction and different things like that. And then we have um the potential for optimized response times. I talked a little bit about that earlier. Um but really every second does count during a cyber incident. Um, and if you have speed and clarity in your responses, you're going to be more successful and there's going to be less of an impact. So, um, simulated incident response is going to help us to reduce confusion. Um, it's going to help us to streamline that communication flow and make sure that everybody already knows who they should be contacting. Um, and

there's also going to be no time wasted figuring out where we need to start with an incident because we'll already have those escalation steps set into place and we'll know the first steps that need to be taken for us to declare an incident maybe or to make sure um that everybody who needs to be involved ends up in that room. And also repeating anything leads to muscle memory. So, the more times that you practice, especially with your team, you build teamwork. Um, you build better communication. And if you've been through something before, you're more likely to remember the steps that you took before. Um, or if you it's different, you might be able to take

those steps that you did before and apply them to what you are doing now because you already kind of have an idea of what needs to get done. Um, now I want to talk about crafting challenging scenarios. Really, every tabletop should look different for every company. It's really important to identify what the important vital information is or the crown jewels are for your company specifically. Um, just to give an example. So, a client list might not be a big deal if it got leaked, you know, for your local bakery who sends out a coupon every month. But a bank on the other hand, that would be a really big deal. That would be something that they would definitely be

declaring an incident on and that's something that they would then have to communicate with all their external stakeholders. Maybe if we have customers there, we now have to communicate to all of our customers. So, that would be much more important to them. or denial of service might not be the worst thing for a pet supply company. Um, but if you work in an health care organization or with critical infrastructure, we know that availability is essential because it can often times lead to where human life can be at risk if it's not available. So that would be something that they want to practice for because it's really really important to them that that doesn't happen or they know

what to do when it does. Um, so really we should be embracing um, complexity. What do you guys think? What is the worst thing that could happen maybe at some of your companies? Do you guys have an idea? Anyone? >> I work in financial services. So I financial data. >> Yeah. Financial data slipping out. That would definitely be an incident to declare. Anyone else? >> My internal audit findings that show all of the gaps in my organization. Yeah, the internal audit findings with all your gaps that definitely don't want those to be leaked out anywhere. Yeah. So, different things like that. It's going to be different for everyone. But when we embrace complexity, um it real world incidents, they're very

rarely just that simple. Even if they do end up being simple, the steps to get there, trying to figure out what it actually is might make the situation complicated in itself. So if we have simply or overlinear scenarios, it's going to lead to a false sense of security, which is not what we want. We want to be able to introduce uncertainty. We want to introduce multiple threat vectors. And we also want to introduce shifting variables. That way, an organization can simulate the chaos of an actual exercise um in a real life crisis and better evaluate their adaptability to that crisis itself. Um, tabletops are also designed for you to lose. And that's something that's really scary for a lot of people. But

losing in a tabletop exercise isn't just acceptable. It should really be your goal because these sessions are not pass fail evaluations. Um, you know, oftentimes people don't understand that and they're worried they're going to look bad in front of their boss. But really failing forward is the goal here because that way we're discovering the breakdowns and those gaps in a controlled environment before this h happens in an actual incident. And we'd much rather it happen in a controlled environment than during an actual incident. Um, and it's really gonna provide that space to analyze, correct, and improve without those real world consequences. So, if somebody makes a stake, a mistake, we can pause and we can back up a couple steps and see what

they would do differently. Um, we have the opportunity to redo things which you wouldn't be able to do if it was an actual incident. Um, and we always need to prepare for the worst. Really challenging scenarios. They're going to be pushing teams for high impact, low probability events. And if you train for the worst case scenario, the easy ones you will be able to handle with ease. So that's really important. And if your exercise, if it's too easy, if it's too generic, if it's not tailored to your company, it you risk being blindsided when something is actually disrupted with that false sense of security that you have. And then we always want to individualize our responses. We want to craft layered

realistic scenarios that are going to allow people to respond based on their specific roles in the company, not just a generic role of what maybe somebody would do, but we really want to make it specific to each person that we know needs to be in that room. We want to um I like to do open source intelligence on all of the companies that I write exercises for. Kind of see what I can identify as their pain points. Maybe I can find some of the people who are on the sea suite and I can you know target them or maybe that ends up being the threat vector of the scenario. So you can really tailor these as much as you

want to be able to customize them and make them as realistic as possible. You could even include your third party vendors. Maybe there's like a specific tool that you use um and you can use that as part of the incident. So just different things like that that are going to make the scenario more realistic and it's going to avoid that mentality of well that would never happen to us because oftentimes people hear things and if they think it sounds ridiculous they say well that would never happen here. So the more we can customize and tailor our exercises to the specific company the less likely that that kind of attitude which will lead to disaster in an incident is to

occur. And we also want to make sure that we're balancing complexity because if our scenarios are too convoluted and they're too confusing, we can overwhelm the participants and that really is not the goal of the exercise. Our goal is to lose forward and to continue to learn. Um, but we don't want to derail those learning objectives by confusing everyone. Our scenarios need to be challenging but clear. They need to include moments of ambiguity without complete chaos. and they should focus on a specific theme while still allowing those different unexpected dynamics to emerge. Um, and a balanced scenario is going to challenge a team without completely paralyzing them. And it can be a little bit discouraging when people get

paralyzed. So, it's really important that we make sure that while these should have complexity, we there is a balance in it. Um, as far as post tabletop exercises, um, we want to make sure that we conduct a lessons learned. Um, we want to talk about what went well, um, and preserve those for future responses. We want to talk about where improvements can be made. Maybe we wrote down some gaps during that exercise that have been identified. Um, and we want to evaluate um, if the scenario has exposed any sort of risk that was previously unknown to us. We also want to develop a remediation plan. And this is a really important part of it because it allows for the

follow-up. So, we want to categorize all of our risks or gaps that we find um, by either risk level or maybe you're doing it by area, whether that's technical, procedural, communication. We want to we want to group them somehow. And then we want to assign specific measurable actions to each of those points. And we want to set timelines and checkpoints for completion. That way it doesn't fall through the cracks um and we didn't realize we never fixed it. We want to really set specific people in charge of fixing those and then follow through and follow up with them to make sure that they've actually been remediated. We also want to document our findings in an afteraction report. Um really it

should include an overview of the scenario, the objectives of your scenario. You should write down everybody that's in the room. Um identify the strengths and weaknesses of the exercise, where things went well, where things didn't go well. Um and you should write down recommendations for improvement. So after you've gone through your exercise and you've identified those gaps or maybe you noticed the communication was a little bit off, write down those things that you need to improve on and make some recommendations on it. Don't just write down what needs to get done. Make some actionable recommendations that can be um set in place for people to actually start practicing. And something a lot of people forget to do if it's not your

first tabletop, compare your previous after action reports to the one that you have now. Because maybe um we want to make sure progress is being made. Maybe there's some gaps that we identified in the last one that we still have in this plan. So, we want to make sure that things are actually being remediated and that we're continuing to move forward in our plans. And we also want to strive for continuous improvement. Tabletops should not be a one-time event. It should be something that's part of an ongoing process and cycle of preparedness for you. Um, we need to evolve our future tabletops based on new scenarios. We have different zero days that are coming out every single day.

So, there's always a new opportunity to learn through a different exercise. Um and also maybe your business changes, maybe you've been absorbed by another company, maybe something has happened and things have changed the structure. So really um that ongoing cycle of preparedness um is going to allow you to be ready for an event because security threats are going to continue to evolve no matter what. So our response plans should re really be um re evolving with those events. Um just a quick review um of some of the key insights that we learned today. Um simulating real world events through tabletops helps to identify gaps. It helps to improve reaction time and it's going to help us with cultivating a

culture of cyber awareness. And this is really essential because if everybody recognizes this as a team effort and not just an IT problem, the more successful you're going to be in your tabletop exercise. Um, also effective tabletops, they're going to require the involvement of those multiple departments. Um, and they're going to ensure holistic coverage. So, every department should be involved in that scenario. There should be a role for each of them. They shouldn't just be sitting there watching the IT department follow through with their steps, but they should be actively participating in this incident as well. Um, we also want to design our tabletops to be difficult. um because learning through losses is going to help us to

prepare for those high uh pressure realities that are going to happen. And it's also going to help uh with that decision- making process to streamline it. It's going to ease the nerves of people because they kind of already know what they're doing. They feel a little bit more prepared before an actual incident occurs. And then we want to make sure that we follow through and do those post exercise activities. Um we want to do a lessons learned. We want to have a remediation plan and we want to make sure that we are um constantly improving. We want to continue practicing our tabletops. We want to write different tabletops every time. We don't want to just keep practicing the

same one over and over again. Because really in today's world, it's not if an incident will happen. It's it's really when now. It's going to happen at some point. whether it's from human error or an outside threat actor, maybe from a natural disaster, but some sort of incident is going to happen to your company at some point. So, our tabletops, I know oftent times they're a box that we have to check for compliance through our cyber insurance or through, you know, a different regulatory body, but they really shouldn't just be a check box that we do every year. They should be used for a strategic tool for building true incident preparedness and the resilience to real world events

because we should be using those failures that we have as fuel for growth. And we also want to regularly conduct those um well-prepared tabletop exercises. And we want to have concrete improvements that are measurable that our team can um and that way our team can go into an incident with the confidence that they need. they know that the gaps have already been identified and in the end it may save your organization from catastrophic damage. All right, thank you so much everyone. Here is my LinkedIn as well as my contact information. Please feel free to reach out with any questions. We also have some time for questions here at the end if anyone has questions. Yeah.

>> So my question is what defines a loss? So, um, really that that's a good question. It said, "What was defining a loss versus a win in a tabletop exercise?" So, winning would be that everything goes right and that everything was smooth and that you didn't have any gaps to identify. Um, but that's not the goal. We always want to lose. That's the goal. So, really losing is winning in a tabletop exercise because it's allowed you to identify those gaps that you had previously not known about. So in other words, you're saying you want to win in a real hack, but in a tabletop. >> Yes. >> Yeah. We want to win during a real

incident, but we want to make sure that we lose during that tabletop so that we can win during that real incident. >> Any other questions? Yeah. So during an incident real world uh everybody around the grounds just tabletops let people know who they need to talk to. >> Yeah, that can be really difficult. So I often suggest that you have a form of communication that you're aware everyone is using beforehand. Um some government agencies have pagers that can go out and that's what they're using. But even setting something up that's outside of your organization. So if you're using Microsoft, well, what if Microsoft goes down? So let's make sure that we have a couple of Gmails or we have everyone's

cell phone number so that we know who we can communicate with. And it's also really helpful on your incident response plan to put a page just with everybody's contact information, maybe a couple of flowcharts for escalation with the person's name next to it so they understand who needs to be contacted. That way if they forget in an incident um you know they can very easily look it up and see okay this is who I need to contact because this is the roles and responsibilities of this person and then they'll be able to talk to them from there. >> Yeah. >> Testing your plans and you're practicing. So if that stuff is in those plans to begin would you suggest putting

in cards in your disaster recovery plan I plan as well as >> yeah I would s so the question was um if you're testing your incident response plan your disaster recovery plan and your business continuity plan what kind of safeguards should we be putting into place for all of those ideally you want to test all three that's not always possible because sometimes we have limited times for incidents Um, if we can test all three at once, that would be great because then we have the complete start to end of a tabletop exercise and we can go through what would happen if things were down, which is also going to be part of an incident even if it's not the original incident.

And we also know what we can do when things are disrupted, how we can continue on with business. That's not always possible. The incident response plan is really really should be the goal if you can pick one because your incident response is going to help you to contain that incident and if you don't have the incident contained it doesn't really matter if you have a disaster recovery plan or a business continuity plan because it there will be nothing to continue until you can contain it. So you should try to test all three but I if you can only test one ideally your incident response plan would be it. But I deal with the team, so it's like the same players

and the same systems and it's like I don't I don't know how to spice it up. I like Is it just a trended thing? I don't know. Is everybody else is that is that the general >> sentiment? Like um so he's talking about fatigue in our employees. Um it can be a little bit fatiguing if we continue to do similar exercises. Um I can there's some companies that I conduct a tabletop for once a year and I like to give them a completely different incident that I did before. So I don't involve the same systems every time. So maybe like uh one year their sales force will go down and then we're focusing on that how that

would happen or maybe one year we have ransomware. So continuously developing different scenarios is definitely going to help with that fatigue. Um, but we also want to make sure that we are repeating things enough to where it's kind of muscle memory for people. So, I would say just continue to write, you know, different types of scenarios. There's different threats that came out every day. You know, we just had a SharePoint vulnerability that came out using something like that. Maybe our whole SharePoint sites are down. What are we going to do? and kind of walking through it like that because even though the steps are going to be similar, they're going to be a little bit

different every single time because no even if you have ransomware twice, no incident is going to be the same. So, it's important to write different scenarios um and kind of just encourage people to move forward and think about what they can do differently during this incident than a previous one. >> Yeah. advice for places like MSPs where it might be hard to get or they're not. >> Yeah. So, the question was about managed service providers and maybe if they don't have um some of those other departments that are involved because they're not internal. Um, ideally if you could reach out to those people and see if you could have somebody there to represent, um, that's the ideal

situation, but there's not always an ideal situation. So, you want to make sure that you have somebody from your side of the team who at least knows what needs to be communicated to that person. Maybe you have a representative um, from a different department that's there who's going to be communicating with your finance people or who are going to be communicating with some of your thirdparty vendors. You want to make sure that the people on your side understand who they need to contact, the steps that they would need to take with those providers and then you can communicate those steps to them. You can give them a little kind of action report of this is what we're going to do in

case of an incident. Do you have any suggestions on things we can change to help um you know streamline our processes according to what you guys have set into place? >> Any other questions? Yeah. >> How long exercise last day. >> How long should they last in a day? Um, so I normally I would say um they last about four or five hours and we do like a little lunch break in between. We don't want it to go like so long that everyone is just exhausted by the end of the day even though that might happen in a real incident. Um, but we also don't want it to be 1 hour because that doesn't give us enough time to really

identify all of the gaps in our plan and it definitely doesn't give us time to rewind um and redo something if a mistake was made. >> Yeah. >> So, uh, on your presentation you mentioned seuite should be >> even on the tabletops. >> Yes, sea suite even in the tabletops if we can get them. Um, it's I know it seems intimidating, but it's important because oftentimes they're the ones who are going to be doing that outside communication. So, you know, they're the ones who need to have an understanding. They're probably the least technical people that are at your company. So, they're really the ones who need to understand what is going to happen in case of an incident. They maybe don't

need to get into the nitty-gritty of all of the details of what's happening. And, you know, we saw this alert come through on our scene. they maybe don't need to know that, but they need to be there to understand what's going on in their company. That way, when they talk with their communications department, they'll have one clear, concise message to send out, and they'll also be able to put your third party um your third party stakeholders and your board members at ease because if they don't really know what's going on and if they go into the incident blind, the likelihood is they're going to accidentally say something that might freak people out. you know, people hear the word

ransomware, you know, immediately everybody starts to panic. So, if you've got third party um stakeholders and they hear that, that's going to be a panic. But if we just tell them, hey, we have an incident. We're working on fixing it right now. We have a couple machines that are down, but we've contained it and now we're trying to, you know, make sure that everything is clean. That's something that sounds a lot better than, hey, we have ransomware for a million dollars on all of our computers. So, it's important to have them there. even if they're not participating in the IT side of it, they know what's going on so that they can find a more PC way to

communicate that to all of your external people.

Yeah, that's a great point. A tabletop is another uh place where you can teach your seauite people how to communicate. Um >> yeah, focus. >> Yeah. So, we should be talking to the seauite and we should be explaining to them different things that they can say and that's why it's also really important that your communications department is there because they can help them with what to say to those external stakeholders to put them at ease but still make them aware that an incident has occurred. Any other questions? Yeah. >> What are some of the red flags you look for when the tabletop? >> Red flags when the tabletop is going off the rails. Um that's a good one. I would

say um I've I've run some tabletops where um nobody really knows who's in charge of what. And that's my, you know, first red flag because somebody goes, "Well, I'm the one who's declaring the incident." No, I'm the one who's declaring the incident. So really like defining those roles and responsibilities ahead of time if we can is a great idea. Um also um making sure that everyone is communicating. We don't want any like yelling or fighting in the room. Um I've been on a couple tabletops where that's happened and it's really unproductive. We want to make sure that everything kind of even though it's an incident, you know, screaming at each other during an incident is not going to

help. So that's definitely a red flag when I see something like that. Um and then a lot of times people just don't have an incident response plan. you know, they kind of shrug their shoulders. Well, I don't really know. So, you know, anytime I see an incident response plan, whether it's a skeleton of one or they're still building it, that's always a good sign. Any other questions? >> Yeah. No, please ask away. >> How important is it to have a network? Nobody has a network diagram. >> Network maps are very important. They could be um they are going to save you a lot of time during an incident. If you know where everything is in your

network, you know what portions you can isolate and you know what's going to go down when that isolation needs to happen. We actually had um one of our employees who had to map out a network for an entire um government agency for transportation because they didn't have one and that was revealed during their incident response um plans. So yeah. So, what information needs to be on network? >> Um, it's really up to your company specifically, but you want to make sure that um you obviously want to make sure you know your different networks. Really, everything that you can put on there without, you know, giving out sensitive information um is going to be important because the more information

that you know about your network during an incident, the easier it's going to be to be able to um isolate and control that network. Any other questions? We've got five minutes left. No. All right. Well, thank you everyone so much for coming. Again, my email is up here. Please feel free to email me with any questions or um if you come up with something else, I'd be happy to answer them. Thank you so much everyone.