• United States



by CSO staff

How to conduct a tabletop exercise

Jul 20, 20228 mins
Incident ResponseSecurity Practices

Testing your security policies and procedures in real-life scenarios can help you improve your security posture—if you implement the lessons learned.

diverse group people collaborate using Post-It notes to strategize on a glass wall
Credit: Thinkstock

Tabletop exercises give your organization an opportunity to practice incident response plans. They are both an opportunity to rehearse and revise existing plans and a training opportunity for new employees.

Done well, tabletop exercises “allow for the discovery of ways to reduce your threat surface,” says Stephen Jensen, senior director of operations at the Center for Internet Security (CIS). “When you rehearse in a tabletop format, your written policies go from just being plain policies to becoming well-written policies and procedures.”

CIS is best known for its critical security controls and benchmarks, but is also home to the Multi-State Information Sharing and Analysis Center (MS-ISAC) and the Elections Infrastructure Information Sharing Analysis Center (EI-ISAC). In support of those ISACs Jensen oversees incident response and vulnerability management for over 12,000 state, local, tribal, and territorial member agencies.

In his role as exercise coordinator for the MS-ISAC, Jensen works with DHS CISA and local governments to set up and execute tabletop exercises. He is also a member of CIS’s Crisis Management Team.

Jensen delivered a presentation at CSO’s recent Future of InfoSec Summit where he explained how to create and execute a tabletop exercise and how it can help you identify gaps in your security processes and procedures. What follows are edited excerpts from that presentation. For more insights, watch the full video embedded here.

8 steps for effective tabletop exercises

1. Set your objective

The first thing you should do is develop an objective statement. [This] helps the team to define the specific exercise goals, provide a framework for scenario development, and provide exercise evaluation criteria—at least at a general level.

[An] example [objective statement might be]: Evaluate the incident response plan for when an insider threat is discovered. It is very specific, it lets the team who will be participating, understand what the exercise is going to be about, allows them to prepare in advance—to look at the procedures that they have for the security measures that they may put in place or may already have in place—in the event of an insider threat.

2. Establish who is participating

Once we have that kind of overall objective, we need to understand who we are going to have in the room…. It’s really about identifying our intended audience. Sometimes it might be … a larger-scale tabletop—how do we as a company handle this event? Other times it’s going to be a smaller subset—are we practicing and rehearsing response procedures? …[Y]ou have to make sure that the exercise is controlled for the intended audience.

3. Develop your scenarios

Once you have your overall objective,… you have to start developing discussion questions. The tabletop is a lot like a role-playing game, and so you are going to ask leading questions, open-ended questions, to start to create an environment where a conversation can build,… but where you want to continue to focus on your specific objective. If it is a leadership team, [the questions might be around] what do you do with an insider threat: If the person is found, are they reprimanded? Are they fired? What are those kind of procedures that a leadership team might have?

4. Don’t skimp on scheduling

So, we have a plan, we have scenarios built out, and we have got this discussion question so that we can lead our participants kind of down a path. Then we have to work on scheduling. Depending on your overall focus, a tabletop exercise can last anywhere from two to eight hours … you need to provide enough time to have active participation.

5. Set ground rules

Once the tabletop exercise begins, the first thing you need to do is set ground rules … defining the purpose of the exercise. Explain to them how the exercise is going to move forward, and then discuss roles and responsibilities, “Hey, I am the facilitator. This person is the evaluator, and they will be watching. We have observers in the back of the room, but they will not be participating. They will just be watching.” And then begin presenting discussion questions.

6. Do the hot wash

At the end of the tabletop, after all the discussion questions are asked, all the objectives are met, it is really important to do a hot wash. [A]s close as you can to the end of the exercise, sit down with the team, review the objectives, identify what went well, find some best practices, and then it is also a chance to kind of define what did not go well.

And then give the participants the opportunity to suggest improvements—not only to the overall objective, but to your process, to the actual exercise process itself, to say what worked for them, what was confusing to them, so that you as the exercise planner can do a better job next time.

7. Write the after-action report

Everything that comes out of the hot wash then gets put into an after-action report. The after-action report describes the entirety of the exercise, highlights best practices, and proposes an improvement plan. So, that after-action report might come out maybe a week or two after the exercise occurs because it does take a little time when you annotate possible improvements to your processes, your procedures, or your documentation, you then have to kind of write it all out in a timeline and decide who is going to be responsible for those changes.

8. Create an implementation plan

Another thing that we need to remember with a tabletop exercise is the importance of your implementation plan. The implementation plan isn’t just a way for you to take that written guidance and polish it up or dot your i’s and cross your t’s or to ensure that every step is correct; it is also an opportunity to introduce new solutions. So, as you go through and you have these discussions during your tabletop exercise, you might notice that you have a group of really smart people in a room, and they come up with a solution that maybe you did not anticipate or that is not documented anywhere. And so then, as part of your implementation plan, should be also to evaluate that new solution.

An example scenario

[This example from the CIS tabletop exercises guide] will give you a quick example of how easy this can really be for you:

Joe your network administrator is overworked and underpaid. His bags are packed and he is ready for a family vacation to Disney World, when he is tasked with deploying a critical patch. In order to make his flight, Joe quickly builds an installation file for the patch, and deploys it before leaving for his trip.

Sue, the on-call service desk technician, begins receiving calls that nobody can log in. Turns out that no testing was done for the recently installed critical patch.

What is your response?

The discussion questions are, “What is Sue’s response in this scenario? What would she normally do, day to day?”

And then … do any of your on-call technicians have the correct expertise to handle this incident? Are they going to have to call in another tier of help? So, are there defined escalation processes?

Another question would be, “Does your organization have a formal change control policy?” In this example, Joe just did something that was quick and easy for him, but maybe not within the overall change control policy. So along with that, are your employees trained on this? …And then, does your company have disciplinary procedures in place for when an employee fails to follow established procedures? And then finally, does your organization have the ability to roll back patches in the event of an unanticipated negative impact?

So again, [this will test your] documented policies and procedures. But also [it] is a way for those participants in this tabletop exercise to perhaps find a way to innovate the process. Maybe your organization has grown…, but your policies have not grown with you or your technology has not kept up. So maybe now is the time to look at automated patching instead of just having Joe write a script that pushes out a patch. Do you actually have a patch server that kind of is automating this for you? And if not, is that something that you want to put onto your roadmap over the next couple of years to try to budget for and purchase and evaluate? And so that would go into your after-action report.