How to Run a Security Tabletop Exercise

Tabletop meetings are opportunities to test out your employees, processes, and procedures to see how a particular scenario would play out.

In this blog post, we’re going to explain how you may want to plan a tabletop meeting, describing the process by starting with the planning phase and then–as if it were different points of a plot in a story–the hook, twist, climax, and resolution.

Plan before you schedule

The very first thing you’ll do is create a list of 10 or so tabletop scenarios and pick one or two that you think will be the best for the goals you are trying to reach. Your goals can be based on a common incident that needs more practice or an event that’s never happened which you’d like to test out–or maybe one of each. You can also use current events and recently publicized breaches to come up with possible scenarios. If you pick two or more scenarios, you’ll want to make sure you still have plenty of time during the meeting for discussion and to explore different approaches to the exercise.

Before you even schedule your tabletop meeting, define the scope, requirements, and resources available to you for the exercise. Then, depending on the resources and scope, pick the participants and teams involved in the scenarios. The teams should be willing to implement any takeaways.

Starting the meeting

When you’re ready to start the meeting, make sure everyone is prepared to take notes. Inform them of what you’d like for them to take note of. Some ideas:

• Each step that was taken to resolve the scenario
• Resources and tools used
• Documentation used (you can even make a rule that only current documentation can be used–and followed exactly–when determining what steps to take so gaps in documentation can be identified)
• Logs that were pulled
• Any additional data or reports that were involved
• Potential areas of improvement to target
• Goals of the tabletop and how they were achieved (or how they were not)

As you move through the exercise, there are three key aspects of the scenario to cover: the hook, the twist, and the climax. Remember: during these points, keep track of everything that you may want to bring up during the post-tabletop discussion.

Hook

Start off the exercise by explaining the hook, which is the beginning of a story that sets it apart from other stories. This is what makes the tabletop scenario unique. Include points such as:

• The initial trigger of the incident–the alert, a user reporting something, a vulnerability finding (from scans or a 3rd party contacting the security team)
• All the details that would come in with the trigger
• Logs and reports that are involved
• What resources are you going to use? Consider who is participating in the tabletop and what they have access to in order to make it more realistic.

Once your scenario’s hook has been established, it’s time to add a twist so the experience doesn’t follow a linear, predictable path. When tabletop scenarios follow an expected path, it leaves little room for anomalies and situations that require a creative solution.

Twist

Always have a few twists ready if you have time during the tabletop meeting and want to include them. You don’t need to have twists, but you can use one like “the backups are corrupted” if you would like to challenge assumptions. If all backups are assumed good, for example, then that’s a potential point of failure that you may want to address.

You can also use a twist to create more detail, but it’s not necessary if the scenario is already going to take awhile.

Possible twists to consider:

• Incomplete or missing logs
• Unavailable systems or unavailable data
• Data that has been tampered with and is unreliable

Climax

The climax covers the steps taken to resolve the incident. When deciding what steps to take, consider:

• Are the steps achievable based on available resources? For example, you can’t use firewall logs if you aren’t able to access them or have not been storing them correctly.
• Read through any playbooks, policies, or procedures instead of assuming or running off how you do things. Are you following everything as it is written?
• How efficient are the steps you are taking? What are some additional ways you can resolve the scenario?

After the exercise

Once the exercise is completed, you’ll want to hold a post-tabletop discussion to check the resolution and its effects. Use the following checklist to evaluate the process.

• Were the participants involved able to complete all the tasks required? Do you need additional participants next time? If there were firewall changes involved for example, and nobody in the tabletop meeting could do that, then the networking team may need to be involved next time.
• Review–What were the takeaways? What needs to be updated as far as the playbooks, policies, training materials, and so on?
• Where could it have gone wrong? What are potential points of failure for future tabletops?

Conclusion

After your post-tabletop discussion, it’s time to update any documentation and policies. Communicate changes to the teams that they affect and be willing to take feedback–including from those who could not participate. Every tabletop meeting will result in takeaways and lessons learned so put them to good use.