Learn how to threat model using an interactive board game
Threat modelling is a very hot topic within security. With many companies struggling to roll out this methodology, we needed a solution that would allow us to do this at scale
Threat modelling allows us to look at any given application and the infrastructure it lives in, as well as document and prioritise the security flaws. For more detail check out the following OWASP entry: https://www.owasp.org/index.php/Application_Threat_Modeling.
Aligning almost 100 scrum teams in their approach to threat modelling is a challenge we have at ASOS. Along with my Secure Development team, I embraced this challenge, and took the opportunity to come up with some innovative ideas.
One of these ideas came to me in what felt like an epiphany — a relatively straightforward way that we could roll out threat modelling.
What if we were to focus our efforts on the core skill sets and attempt to teach each of these individually?
I remembered when I was at school, and I learned how to multiply, my teacher told me how five multiplied by five is the same as adding five together five times. Here we reduced multiplication down to addition. I wanted to apply this concept of reducing a complex task to one that I already understood to threat modelling.
Once these skills had been identified, I could then build it back up to threat modelling, focusing on the individual skill sets. Whilst doing it in a way that is interactive and collaborative. The interactivity was important, as everyone involved would be encouraged to put forward their views.
As any scientist would do before testing a theory, I entered a research phase. I played a few games including Cards Against Humanity, Monopoly and Risk, and even thought about Dungeons & Dragons, all in the name of science. It became apparent that the only way that this would work would be to create an eco-system purely around software, engineering, and, more specifically, security.
The first part of any good threat modelling exercise is to identify the assets. When I threat model with a team, I ask them to draw their architecture first. I used an extremely simplified version of an e-commerce company base architecture. You can see in the board further down, that it’s clear what each of the components are, and how they work together to provide an e-commerce service.
The board has been partially obscured, but I encourage you to create one of your own that fits your use cases better.
Now that we have the architecture articulated, I would highlight the high-value assets. High-value assets are those assets we seek to protect, or attack if we are thinking with the hacker mindset.
The high-value assets differ based on perspective and context, but we should be conscious that we understand what is important to us and why.
Because the system view was only partial, I decided it would be best not to short cut the game and call out where the high-valuable assets are. Rather I’d let the people I’m playing with decide which assets they want to defend or attack.
Depending on how you threat model, there are a number of things you can do next. A very simple example would be: how can I attack that thing? To give the game some direction, and also provide guidance to those that aren’t aware of the various methods available to attackers, I brainstormed and came up with a number of attack vectors that have been put on cards.
I enticed a few of my colleagues to play it through with me using cookies and sweets, and the promise of becoming threat-modelling pros. I didn’t tell them that I had no idea of how the game really worked. I did what I do best and improvised as I went along.
‘This game makes no sense’ — quote from player in the first game
I borrowed the practice of continuous improvement, using iterations, to improve the gameplay and specifically the rules.
I spent a few evenings using GIMP, and managed to create a slightly nicer board, which is the board we use today. And I even made a hard copy of the board.
I’ve played through the game a few times, and I’ve got the rules ironed out now. So, without further ado, here’s how to play my game…
Threat hunters
A threat modelling RPG board game
The goal is to take turns attacking and defending the system.
Clone this repo to get access to the latest file https://github.com/ASOS/threat-hunters-rpg/
Introducing AcmeCorp
AcmeCorp is an online retailer. They provide direct-to-door delivery of Acme- related memorabilia and Acmes to people of all ages. Their CEO, Acme Ackleson, is very concerned about cyber security and has committed to invest in the correct places. Luckily, the new security team has the best threat hunters in the world. That includes you!
How to play
Game set-up. Split in to four–six teams of varying ability and experiences, of any size. I personally recommend three–four per team, to ensure everyone can be involved in the discussions. Ensure each team has a notepad, a nominated spokesperson and a scribe.
Place the attack cards on the board where everyone can see and access them. Sometimes it helps to have a copy of the board on the screen for visibility.
The game consists of rounds, each broken down into different parts and taking approximately one hour to complete.
Each round. At the beginning of a round, a member from each team takes an attack card from the deck, keeping it secret for a short while. Simultaneously, all teams are then given three-five minutes to discuss how they will attack. Once the team is satisfied with the attack, the scribe notes it down — this will serve as evidence in the event that two teams have the same attack. You’ll ultimately need to present it to the defending teams, including talking about the assets you’re targeting, and how your attack will spread into the system. Have fun with this, you have one minute to present.
Presenting the attack. Each round involves a number of further rounds of attack. The first team presents the attack to the other teams. It’s important to note here that the attack has not yet happened, but is imminent. The company has time to react. The whole point of being a threat hunter is that you’re able to find intimate details of an imminent attack using the contacts on the dark web. The attack needs to reference high-value assets that are either on the board, or whose existence is implied by the presence of an icon on the board. An example could be the SMTP service, or the security at the entrance of the distribution centre.
Defending. Once the attack team is satisfied that everyone understands their attack, the defending teams have three–five minutes to work out one thing they would change on the infrastructure of the board to mitigate this attack. We don’t have to be too prescriptive, as this is only a reference. If a team has a defence using a system that is either implied by the attacker, or implied by the board, this is also fine. As previously mentioned, some examples include an SMTP service, or the security at the entrance of the distribution centre.
Success in a round. Success in an attack round is defined as an undefended attack — when the attack team and defence team agree that the attack has not been defended by the mitigation.
Success in a defence round is when a defence successfully mitigates the attack. As in an attack round, this needs to be agreed by both the attack and defence teams.
In the event of a deadlock, where teams can’t agree, the other defending teams are allowed to offer their opinion. If there are still no concessions, we resort to the very scientific method of rock, paper, scissors.
This is about playing together. We all win as a team.
Example round
Attack card: Careless employee
We’ll email a virus to a developer whose details we retrieved from Instagram, and whose email we guessed based on business email naming conventions. The virus will send us a copy of his Git repository’s SSH key, and we’ll make a commit on his behalf, injecting a vulnerability that will allow me to make tomato purchases for free. I’ll ship these to a drop mail box once a week until the exploit is patched.
Defence
Defence 1: Will vet all emails to all staff to ensure there are no malicious payloads
Defence 2: Will implement code reviews across the business to ensure change can’t go live
Defence 3: Blacklist the attacker’s customer account
Which would you choose?
Most importantly — what did we learn?
Attack team
Threat modelling
Looking at the infrastructure for vulnerabilities is threat modelling. Identifying threats and looking out for the high-value assets. Articulating how you can abuse the system to gain access and potentially pivot through the system.
Hacker mindset
Using the attack trees to identify assets and gaining access to other parts of the system allowed us to use a hacker mindset. If you used more than one step in your attack, you demonstrated attack fanning though the system. With an understanding of how attacks change based on the initial vector.
You’re all hackers now.
Defending team
Defining counter-measures
We spent time thinking about what things we can change to make the biggest impact. We also found that it is possible from our choices to target this specific attack or the general case. Teams that chose multiple defences and weighed them up to find an overall winner had to weigh up the pros and cons of doing each one, against each other. In threat modelling we use DREAD to accomplish this.
Thanks for reading — I hope this sounds fun and was clear. If you have any questions let me know.
This blog post was written by Harjit. He loves to code and he loves security. He’s always happy to have a discussion even if it’s not related to software or security.
