Life comes at you pretty fast, and security incidents can come at you even faster. When it comes down to it, a good plan is the cornerstone of dealing with incidents. 

I had the privilege of being at the Microsoft Security Response Center during the formation of their incident response planning. It’s a challenging thing to create as well as maintain. The concept of removing people from the equation and supplying a base level playbook is integral to the difference between a security incident bouncing bad or bouncing to a level where it can be handled. 

But how do you test the plan by itself and remove the people element? Many solutions to this involve doing drills much like safety or emergency response drills. The problem with that is no matter how much you communicate that the intent of the exercise is to examine gaps in the process, people feel like they are being put on the spot and it alters in some small way their reaction to the drill.  

So as a best practice Leviathan used a solution that I got to test out with a client the other day that rather effectively removed the element of the individuals involved and focused on stress testing the process: We ran the drill as a Dungeons and Dragons (TM) style role playing game, dice and all. 

The exercise unfolded like this: representatives from all the stakeholders in the response plan were there. I was the DM which, in game-playing terms, meant I wrote the scenario and was a combination of story teller, opponent of the players, and referee. Everyone was assigned hit points, and got a major and minor action per turn with me constructing the story we were about to explore. Through the randomization of the dice rolls and the roles being played, the players could work as a team without regard to individual concerns about being in the spotlight. 

We protect client confidentiality so the details I can share that are relevant are that, like most companies today, the client uses cloud technology to provide their service and at a base level customer data is stored in the cloud. 

The scenario was a two-fold incident. On the one hand, an attacker had successfully breached one virtual machine instance within the cloud due to a previously unknown Remote Code Execution vulnerability on an Internet-facing port and dropped a bitcoin miner on the instance. At the same time, coincidentally, a Twitter user claiming to be a hacker stated they had breached the company’s security, even though they had not. The two issues were unrelated but in a turn of bad fortune, they happened at the same time. 

This allowed us to test both the engineering forensic and recovery action and response steps, as well as the customer facing public communication portions of the plan. Players had to use dice to roll initiative checks in reaction to real-time events, and saving throws against how much they could discern from log files or auditing as the incident/disaster recovery plan laid out, or engagement with the Twitter user unfolded. Their rolls were compared to predetermined outcomes or the DM's roll against them. If they beat the number by rolling higher, the better the outcome for them. 

Certain players were taken out of the game at key points by the DM, and the entire exercise was observed through one-way glass by those in charge of the client’s infosec team to take the element of scrutiny out of the player's reaction to the game. 

We. Had. A. Blast.  

Few of the players were familiar with role playing but took to it immediately. When one player rolled a natural 20 on a log check I got to explain what rolling a natural 20 means in gaming terms and gave them a bonus on the information revealed in the log check. 

Most importantly, we found gaps in process as well as areas for improvement. All without people feeling like they were being put on the spot due to the nature of the random acts of the dice. Which, if you think about it, is precisely how security incidents actually unfold. 

This is what we try to consider when we offer ways to improve the methods that our customers use to help increase security. Take a unique approach, and then share that approach, where appropriate, to make the greater environment of interactive communication more secure. 

So! Security incident drills done as a tabletop game has advantages. Just watch out though, you might get taken out of the scenario for 5 minutes because your character ate some bad gas station sushi*. 

*Actual thing in the game that happened.