How to Play

Rules 1, 2 & 3

Don’t be a arsehole.

The goal and aim of this game, and Threat Modelling in general, is to find vulnerabilities and help us make our software more secure. This is all that really matters and the game & its structure is a tool to help you perform this.

If someone spots a bug in the game and chooses to exploit it, feel free to fix it by adapting the rules. I’d also be keen to hear about it (@OxygenAddictUK).

Getting Prepped

In order to play you will need:

• A data flow diagram (DFD) already made.
  • This is part of the threat modelling process but is a pre-condition for the game.
  • Ideally draw this up together, or review it together, at the start of the session.
• Either:
  • Each player accessing the Threat Agents Remote page.
  • Or a physical copy, which can be bought from store(s) on the BUY page.
• Optionally a few copies of the Counter Agents sheet printed out (especially if you’re a bit unsure on cyber security measures that may be in place).
• Your notepad, laptop or preferred way of jotting down scores, vulnerabilities and actions.
• Time. The most valuable of resources.

Setup

See the instructions for more detailed info but you want it to look like this:

Some of the cards are face down in the picture. This is because the photo is of the game in mid play.

Note that this is a dated version of the same. Users will have Counter Agent cards rather than Defender booklet.

An Example Turn

Disclaimer: I made up the system in the Data Flow Diagram just as an example and does not reflect any systems that I’ve worked on, or claim to be a good design.

Each player will take it in turns to make an attack. This involves picking their Threat Agent from those face up and using them to attack an element on the board.

For example in my above setup I have a SDK. This doesn’t go through the Auth Service and interacts with the Client Service. As a result the player might say “I will play The Imitator to attack the Client Service. Having performed a man-in-the-middle attack I will steal the token and pretend to be the SDK.”

Notice here how the player doesn’t say exactly how the man-in-the-middle attack would be performed. That is perfectly fine. The player has correctly identified that there is potential for a malicious individual to spoof the SDK.

The other players might then look at their Defenders. Sure, we have the Bouncer in the form of the token but the concern here is that it could be compromised. We are using HTTPS plus the token itself is encrypted (Trustworthy) so we think it there’s great mitigation in place to prevent this. However if the attacked did get in then we’re screwed. Sounds like they’ve got 5 points but then an engineer asks the question “do the tokens expire?”. Good question. After a quick discussion we believe that there is an expiry but it in days so not a huge help. Let’s give them 5 points for that. Nice one. We’ll also take an action to look into that expiry and maybe make a note on the DFD.

You might be thinking “OK, having done this man-in-the-middle attack so I can spoof being the SDK, what more can I do?”. Interesting questions. Perhaps the next player might build upon it by playing The Gossip by saying they would request personal information in the clients. Or they may wish to focus elsewhere, like playing The Tinkerer against the DB.

Turning cards over

At the end of your turn, the card(s) you played should be left face down. This is to avoid people learning one means of attack and sticking with it all the time.

There are two opportunities to turn the cards so that they are facing up. The first is when you’ve If you have no more cards that are facing up then you can turn them all over. You can also skip your go and turn the cards back over.

However if your team is relatively junior, doesn’t have great knowledge of the system (e.g. after switching projects) or you’ve never done threat modelling before, this might be a little hard and stifle creativity. You might decide that it is OK to turn the cards back over when you only have one or two face up.

Find what works for your team.

Q & A

Who should/can be involved?

This will depend based on how you work. For example if you have scrum teams, you might have the whole team plus a SME. If you are in functional teams then a bunch of people from the different areas should be pulled in.

Ideally you should have people from different roles/skillsets who will be working on the software that you are threat modelling.

In terms of the roles themselves:

• Business Analysts: Yes. They don’t have to be there but I’d certainly encourage it if they have the time.
• Product Owners: As above.
• Architect / Principal Engineers: Yes. It would be really beneficial.
• Senior / Lead Software Engineers: Yup.
• Mid-Level Software Engineers: Of course.
• Junior Software Engineers: Yup.
• Test Engineers: Yes, yup and YEAH. Maybe I’m biased but why wouldn’t you want someone who’s spends a huge amount of their time identifying gaps, risks and flaws in a system at your session to find gaps, risks and flaws?
• Managers: Not because they are managers, no. However if they are managers because they are the sort of software wizards that would contribute then go for it!

If you haven’t guessed already – I believe job titles are unimportant when sending out invites.

What training do I need?

You need to know what your software is. That is about it. Although even if you don’t, I’ve ran a session with a guest who hadn’t even heard of our product beforehand and they contributed well! You don’t need to be a security expert, a networking expert, decades of development experience or to be a DB admin.

Can I play 2 Threat Agents at once?

Providing they are face up, sure. You may find it easier to explain an attack by using multiple agents. However if this is being used as a means of getting cards turned over quickly, feel free to block this from happening.

What if someone came up with a reasonable attack but using the incorrect Threat Agent?

Within S.T.R.I.D.E., which Threat Agents is based upon, the lines between the different principles can be blurred. As the goal is to find vulnerabilities in software, try to be forgiving to players who get it wrong. However if players are clearly not caring about using the Threat Agents correctly, don’t give them points (or reduce their points given).

What if I spot a superb 5-pointer but don’t have the available Threat Agent?

The intention of turning the cards over is to ensure that you have to mix up your attacks, not play denial of service against each element in turn, but this is secondary to finding threats. In the event that you want to bend the rules for the benefit of the team:

1. You must inform the team of your intent to invoke this “loop hole”.
2. If it isn’t a 5 pointer, you get no points.

There is a dispute over the legitimacy of the attack or the points to award. How do we settle this?

Pistols at dawn.

Alternatively the recommended approach is that the quickest to volunteer to take an action gets their way. Obviously they then need to follow up on it! If no one volunteers, either suggest a compromise score or put it to a vote.

Can we use the same vulnerability twice?

Repeating someone else’s attack? Of course not. However there will be times where you are using the same “way in” as a means to perform multiple attacks.

For example lets say that your system in an appliance and you’ve set default Windows credentials of Administrator / DefaultPw1. On the back of this it is perfectly valid to look at how you might tamper with the database, expose confidential information that is stored or delete log files showing the naughty things that you’ve been up to.

As a team you might want to say “Okay, lets call it there with these attacks.” to help people focus on other areas.

Something else

Give me a shout on Twitter (@OxygenAddictUK) or email me at my gmail account that I use for side projects, also oxygenaddictuk.

Pro Tip: Don’t type your email address as plain text on webpages unless you like spam.