The Tabletop Exercise (TTX)
In this article, we will explore information security tabletop exercises (TTXs)!
Exercising is fun! More precisely, information security tabletop exercises (TTXs) are fun. I've taken part in a few in our company: facilitating the first one, taking notes for the other two as a couple of coworkers aided, and helping out with the design for all of them. (We're taking turns so that we can each put a line on our security repertoire as having been a TTX facilitator–a nice addition to one's experience). And each has been a positive experience and useful tool for everyone involved.
Years ago, I saw the Reduced Shakespeare Company perform their show The Complete Works of Shakespeare (abridged), and although it's not "family friendly," it’s still worth a watch. One of the routines involved one of the actors being hesitant to proceed with the rest of the routine. He didn't believe he could do it justice. They told him, "You don't have to do it justice. You just have to do it."
When beginning with a TTX, don't focus on perfection or excellence–just do it! You will all get better with each subsequent one. I hope that this article provides you with enough information to get started.
NOTE: This is targeted more at SMBs who haven’t done this. Large orgs and enterprises probably have experience doing these; need to develop a more formal, larger, and longer running program; and/or will use its resources to hire a third-party to run the exercise. This is for those who are interested in getting started on their own.
The main basic elements of a TTX are:
1. Ground Rules
2. Attendees
3. Scenarios
4. Final Report
I could put in Scope, Purpose, Goals/Objectives, etc., but I think those all sort of come out in the wash as you work on the main elements. So, I’m presenting the more general aspects with some granular details.
Here's some more definition and clarity for each:
1. Ground Rules
These should be few and straightforward to be memorable, common sense, and set the tone; rules such as:
a. No naming, no shaming.
b. Participation is required.
c. Participants are responsible for working through the scenarios.
d. Unanswered questions should be addressed later.
2. Attendees
a. Invite at least one leader from each department.
b. It might be best to invite the department head.
i. If they can't make it, they need to send a delegate.
c. Schedule it at least 2 weeks in advance.
i. Not Friday – Friday is the most frequent day that people take off; everyone will definitely take off Friday if you plan it then.
d. How long is the meeting?
i. Plan for 4 scenarios at 20 minutes each.
ii. More details below.
e. Make the email short and clear, but not curt.
i. Tell them why you're doing it (regulatory, better security, be prepared).
ii. Include the Ground Rules.
iii. Don't send the presentation ahead of time, but it’s helpful to send the BCP, IRP, and DRP for easy reference.
3. Scenarios
a. The length of time dedicated to each will depend on how many departments and people are involved, but plan on at least 20 minutes for each.
b. Be ready to take notes.
i. If you can have a facilitator, note taker, and perhaps the head of Security/IT to wrap up each scenario with some corporate-specific wisdom, that's a good idea. But if not, no sweat - just do it.
ii. The notes are for the follow-up report.
c. There's nothing wrong with making up each scenario on your own, but there's also nothing wrong with using freely available scenarios. See the references at the end of this article for several examples of what’s out there.
d. You probably don’t have to include all details of each scenario your final report.
i. More details below.
e. Include Conversation Starters
i. These serve three purposes:
1. They include the main questions and points that you want to cover.
2. If the conversation gets stuck, bring one or more of those out in the open.
3. You can show the team the main points that needed to be covered, and if they covered them all then it demonstrates how on-track the group is with handling incidents.
f. Be ready with some complicating factors.
i. Be ready to move people’s thinking along. It may go too easily, or someone may ask for a further description or more detail. Be ready to shake things up with something relevant to your company. And these are non-necessary items, so they’re not Conversation Starters.
g. Include a follow-up or encore scenario in case things go quickly and you have ample time left.
i. We found that, each time, the team's responses followed the response plan without having to look at the response plan, which indicates that our written plan and the natural flow of who to contact, what to do, what to say, etc. matched. This made the response go faster than expected.
4. Final Report
a. The report probably just needs the overview or summary of each scene, what each scenario tested, which departments were involved (we don't like to share names publicly), when it occurred, and who approved the final report. It doesn't necessarily need to have all the notes.
b. If you want full transparency, then prepare for that in your report template.
c. Here's an example of sharing the scenario and what’s tested, without sharing the questions and notes (modified from here: https://blog.rsisecurity.com/top-six-incident-response-tabletop-scenarios/)
Sample Exercise: Peculiar Payments
PURPOSE: This scenario tests the organization’s inter-departmental communication and procedures
SCENARIO: An urgent and disturbing email arrives in your team’s inbox from the CFO of the organization. After a financial audit, the finance team discovers that several people, outside the organization, receive a monthly paycheck. These people are not on payroll and have not received approval from finance. Upon further investigation, it appears that the paychecks are being paid into an offshore account. The payment is made by SaaS application and the report shows that all payments are coming from an Engineering lead. Eventually, your team discovers that an external threat actor has compromised one of the controller’s accounts and approved the payments.
d. The report can be entitled something like Lessons Learned, Follow-Up, After Action, Hotwash – there are all kinds of titles for it. It’s up to you.
e. The report is a good thing to share with your prospects and customers as proof that you have done some testing. We have a Trust Center where we share this and other pertinent security documents.
f. Include 2 sections for Strengths and Improvements. You’ll do some things right, and you’ll do some things that could have been done better (e.g., better call tree, centralized location of documents).
i. Put a Due Date on each of your Improvements to keep people moving.
The Presentation
Just put it all into your slideshare (PowerPoint/Impress/Presentations/Prezi/whatever) and get everyone together, whether onsite, screenshare, or a combination. If at all possible, record it.
Timing
Annually might be just fine to start with (it's AMAZING how fast a year goes by!), but now that we have the hang of it and our processes are more solid, we're looking at doing some forms of TTX for more departments on a regular basis. As an example, we're looking at implementing Backdoors & Breaches (which is focused on technical things) for the Security/IT/Dev/Eng departments.
Main Actors
Overall note: Those who run the test are responsible for setting the tone. It should be positive – in a real incident you’ll want everyone working together positively to solve a disaster.
Facilitator: The Facilitator controls the flow and pace of the exercise, playing referee if needed (though we haven’t had to step in in our exercises).
Designer: The Designer (or whatever you want to call the role) puts the scenarios together, writes the rules (in conjunction with others), etc. Facilitator, Designer, and others work together to make the whole thing work. It’s not a problem if there’s just one person doing it all, but it makes it much easier with more input.
Additional Roles (not necessary, but good to have):
Leader – Someone needs to introduce it all, and perhaps give additional input throughout, and it’s easier if there’s someone to do just that.
Note taker – This role is a must, whether done by the 2 main roles, or by a separate person. There can be so many ideas that flow that it becomes impossible for the facilitator to introduce, take notes, facilitate, wrap up, make the report, etc. The one who takes notes should be free to do just that because it can be really busy. Plus, noting everything makes a good final report, follow-up, lessons learned, etc. possible.
A few more random thoughts:
a. Record the presentation if possible.
b. Put it on your resume!
c. Make it yours! You need to cover potential real threats, but be you when facilitating.
d. Make a 2- or 3-year plan to cover relevant risks to your org.
a. This can help with audits to show that, while you haven't covered everything, at least you will in time.
e. Make your first one cover the highest risks.
f. Start with an easy one to get people thinking.
Happy Exercising!
EXTRAS
EXAMPLE LAYOUT
Here's a sample slide outline (the usual presentation rules apply: good font size, not too much on each slide, and the like):
1: Intro/Why/Purpose
2: Goals (e.g., Test, Learn, Identify gaps)
3: Ground Rules
4: First Topic intro
5: First Topic scenario
6: Conversation Starters
7: Second Topic intro
8: Second Topic scenario
9: Conversation Starters
10: Third Topic intro
11: Third Topic scenario
12: Conversation Starters
13: Fourth Topic intro
14: Fourth Topic scenario
15: Conversation Starters
16: Bonus/Encore Topic intro
17: Bonus/Encore Topic scenario
18: Conversation Starters
14: Debrief Questions/Outro
RESOURCES
Here are plenty of resources to get things going. There are many out there. It's impossible to list everything here because each org differs in its industry, regulatory requirements and goals, size, future plans, etc.
https://www.csoonline.com/article/3041383/how-to-conduct-a-tabletop-exercise.html
https://elitesec.io/blog/what-is-a-gamified-tabletop/
https://www.blackhillsinfosec.com/backdoors-breaches-tabletop-simulator-guide/
https://www.hsdl.org/?abstract&did=789777
https://owasp.org/www-project-cornucopia/
https://croupier.agilestationery.co.uk/
https://www.nist.gov/privacy-framework/nist-sp-800-84
