Lately we’ve been running a very cool game with a few of our customers. There’s been some demand for incident response table top exercises. For the most part, these are not fun events. I’ve sat through more than a few stuffy meetings where people walk through an incident and then comb through polices, processes, and procedures. Gah!
Often, there are dry arguments about whether or not a procedure is sufficient or if X technology would really work the way it is should. More often than not people get angry and hurt, and very little changes. When the whole event is over, most involved don’t ever want to do it again. It’s like slamming your hand in a car door… slightly interesting, but mostly just painful.
We didn’t want to do our table tops this way. (Cause we like to have fun, and not leave customers in tears.) Instead we started incorporating a little bit of randomness into the process with… you guessed it, a 20-sided dice, cause we’re cool like that.
The key is not to make it too complex. I understand there are going to be lots of people who insist there should be super duper complicated rules that require years of practice and memorization to get “right”. These people also tend to be the people who love D&D but want to fight for hours over meaningless details instead of moving a narrative forward. Despite appearances, these people are not your friends and should be avoided at all costs.
Growing up, the best D&D games were the ones where the dungeon master moved the story forward. They were willing to simplify and bend the rules for the sake of the story. THAT is what we’re doing here.
The Rules (dead simple)
For every action your IR team takes you roll the 20-sided dice. If the roll is 11-20, the action is successful. If it is ten or under it fails. Ka-pow.
You get a +5 modifier if your organization has documented procedures for the action.
You get a +2 modifier if your organization has someone trained to do that action.
At random intervals the IT Guru Master (Yes, this role might need a better name) gets to inject a random into the game. (It will help if the IGM has some pen testing experience.) Below are some examples:
-The attacker posts the incident data on Pastebin.
-Bobby the intern kills the system you are reviewing.
-It was a blackbox pen-test hired by the CEO… You can sleep well.
-Legal takes your only skilled handler into a meeting to explain the incident.
-Lead handler’s wife has a baby.
-Indian Hammel pulls the memory, while the system is running!!! From the infected system!
-An unrelated DDoS attack breaks out.
Feel free to add more.
If at any point the team tries to take an action and there are no policies or anyone trained, someone should note that as a gap to be addressed.
Quick Run Through
So, let’s take a starting incident and walk through a couple of action rounds.
IT Guru Master (IGM): Monday morning, the fog clears through the assistance of black coffee. You receive an email/ticket from the help desk that a user reported a AV alert pop up. The help desk technician failed to note the name of the malware. What do you do?
Tech #1: We would go and review that system to see if there are any strange processes
IGM: Do you have procedures for live systems forensics?
Tech #1: No.
IGM: Is anyone trained in live systems forensics?
Tech #1: No.
IGM: Please roll.