Would You Like To Play A Game? Increasing Security and Compliance Through Gamification of Tabletop Exercises
Tabletop exercises have been used for years to mimic incident response and disaster recovery situations. They are designed to test people or processes to allow teams to practice getting out of trouble before the trouble happens. These exercises are scoped tightly to a pre-existing disaster scenario and, if the person running them knows what they are doing, will generally hit all the required high notes for regulatory or internal compliance.
Because traditional exercises are designed to test people or processes before the worst happens, they are widely used to meet compliance requirements. For example, while it is possible to pass an ISO audit without a tabletop exercise, it is unlikely; you would need evidence learning from information security incidents to meet requirement A.13.2.2. (That’s unless you have an actual disaster and happen to be taking good notes during it.) Simply put, traditional tabletop exercises are a limited experience designed to test a specific situation or scenario in the quickest and most efficient way possible, but by their more “traditional” nature, tend to be somewhat circumscribed and rote. They are designed to confirm the status quo, not to move forward.
Traditional tabletop exercises are often more about checking off boxes than exploring possibilities. They can be stressful for the players because they fear “Failing”, maybe by getting something wrong or looking foolish in front of their boss. By keeping these exercises firmly grounded in the real world, creativity can be inhibited. More than that, the checkbox nature of most tabletop exercises means they are boring. Forgettable. Not something people generally want to do unless they have to. And they rarely make use of dice, and dice are awesome.
Tabletop games, on the other hand, move. Games make you solve problems together in an immersive setting. At their best, they are a form of collaborative storytelling that makes the players want to see what happens next. They evolve, they draw you in. Anyone who has ever played Dungeons & Dragons with a group of friends, sat at a computer on a World of Warcraft raid, or fought with a squad in Call of Duty will immediately understand this. Most importantly, games are a journey, and they make you take ownership of that journey.
Why do we care about the difference between tabletop exercises and tabletop games at Leviathan?
Because, as humans, we learn through play. As adults and colleagues, we can use play to strengthen our ties by going on a journey together, learning how each other operates, and making memories as a team. Completing one journey together makes us more eager to take another, then another, resulting in increased trust and security across your organization.
Tabletop games, on the other hand, are more suspenseful than stressful. Instead of wanting to just get it over with, a well-designed and run tabletop game will have the players on the edge of their seats waiting for the next twist. Tabletop games encourage novel solutions and welcome failure. And they often use dice, which, as I’ve said, are awesome.
In these ways, games are different from exercises, though they can certainly perform the same function for your company and your players. The difference is in the design and facilitation. When you take the time to take your players on a journey through a briefing, solid ruleset, fun rounds of play, and a satisfying ending, everyone at the table has a worthwhile experience. Worthwhile experiences lead to better security by providing memorable points and teaching moments in an enjoyable context. And in the end, better security is why we’re here. But why not roll a few dice while we’re at it?
Tabletop games can be considered to have two broad sections: Setup/Briefing and Gameplay/Aftermath.
Setup/Briefing:
This is where you set the stage. Traditional tabletop exercises usually limit the setup to a tech stack and an initial problem to solve, usually a breach or other incident. While this sort of briefing is generally short and to the point, it generally lacks anything that draws the players in. A game briefing, on the other hand, can include a fictional company or scenario, or a fictionalized version of the players’ company. This is a ripe field for puns and cat memes, which are generally more interesting than a lengthy recital of their network diagram or an organization chart handout.
In most scenario, the briefing includes two things: company description and resources, and player roles. The company description tells players what sort of industry the company is in, their tech stack, and their general budget. In most games, tech stack and budget are intentionally kept lean, as the idea is to give the players freedom to create some interesting attacks and defenses without getting bogged down with the numbers they are dealing with. Importantly, it does not include information on the incident. That comes later.
Player roles generally break down into two types: individual and organizational. Individual roles are the traditional roles you might see in a company, like CTO, Legal, Finance, DevOps, etc. Games using these roles are usually focused on incident response and getting teams to identify their strengths and weaknesses in a crisis. Organizational roles are roles where the players are acting as the company itself, or a particular department, like security. These scenarios are usually designed to get the players thinking in terms of hardening and defense on the company level.
The Rules phase is a critical part of setup. So important that, while the rules are obviously part of setup, they warrant their own subsection here. At their heart, rules are the basic framework on which your game will be built. Along with the scenario briefing, the rules set the parameters of the sandbox. Well-designed rules allow you to rein in difficult players while letting more creative ones run wild. Both ends of this spectrum have value, both in terms of social engineering and pedagogy. We’ll get into this later, but for now, think of the rules as the outline for your game, which effects both how the players play and how you run your game.
Gameplay/Aftermath:
The next phase is the actual gameplay. This is generally composed of a series of injects and responses. Injects are surprise events that the GM introduces during the scenario. This is where the rubber meets the road for the players, and it requires mental agility on the part of the GM. No scenario ever survives first contact with the players, but solid preparation on the part of the GM can make this part a lot easier. And dice. Bring dice. Dice introduce an element of randomness to a scenario. Especially in an incident response game, having the players realize that sometimes things Just Don’t Work adds to the verisimilitude of the game, and thus the learning experience.
Finally, after you’ve taken a journey with your players and gotten to either a resolution or another sort of stopping place, it’s time to look back and reflect on your journey in the aftermath or hotwash phase. It’s the place to identify what worked, what didn’t, and what steps the company or players need to take moving forward.
This is the point where your real security gains are realized. After having taken this journey together, your team is in a much better place to feel free to discuss what is going on in your organization. People who were uptight at the start of the game are looser now, and everyone has succeeded and failed together. It’s here where your team can crystallize lessons and build on the teamwork they practice during the game. If, two weeks later, you asked your players what they learned from the game, it’s the information that comes up at this stage that they are going to describe.
Quarterly games are an excellent thing to work into your security cadence, and are much more effective if the team is looking forward to them. If the game was done right, they will describe it with some excitement, and tell a story about the terrible dice roll someone made, or the brilliant save the Security Lead came up with. This is the linchpin that ties it all together. Players who enjoyed the experience will internalize it and come back for more, perpetuating a cycle of teambuilding and useful compliance that can serve an organization or years to come.
Looking to learn more?