To get started, you’re going to need a couple of things, depending on how you intend to play the game. Firstly, you are going to need a detailed architecture diagram showing the data flows and preferably the trust boundaries.

Figure 1.1: Diagram showing data flows and trust boundaries

What are the trust boundaries? They are the boundaries where data passes from one level of trust to another, for example, user input, which is untrusted data and data that has then been sanitized (had any invalid characters or commands removed), or data coming from the internet through the firewall and onto your network. In both cases, the second example is something you should be more willing to trust.

If you’re going to be playing remotely, read the next section.

Having the cards either digitally or physically is going to be a help, so reading the section entitled The cards will point you to where you can download them digitally or purchase them online.

Remote threat modeling

If you’re doing remote threat modeling exercises and you have a Miro account, you might find my Threat Modeling with EoP Miro template handy: https://miro.com/miroverse/threat-modeling-with-eop/.

The board contains instructions on how to get set up and a working example showing how the Miro board was intended to be used.

To deal with the cards for the remote exercise, Agile Stationery has kindly created a card-dealing web application:

https://croupier.agilestationery.co.uk/

Here, you can download TNG Technology Consulting GmbH’s online multiplayer version of the threat modeling card games that you can host on-premises, such as EoP, OWASP Cornucopia, and Cumulus:

https://github.com/tng/elevation-of-privilege

The cards

The following resources are where you can get your hands on a copy of the EoP cards or those of one of its extensions required to play the game, either virtually or physically:

• Here’s Adam Shostack’s GitHub repository for EoP where you can download the cards: https://github.com/adamshostack/eop
• Mark Vinkovits Privacy Extension can be found here: https://logmeincdn.azureedge.net/legal/gdpr-v2/eop-cards-ready-to-print.pdf
• F-Secure Corporation’s Elevation of Privacy (T.R.I.M.) Extension can be found here: https://github.com/WithSecureOpenSource/elevation-of-privacye
• You can buy physical copies of the cards from Agile Stationery as well: https://agilestationery.com/collections/cybersecurity-games

Alternative games

Two other threat modeling games that are quite similar to EoP in how you use them are Cornucopia from OWASP and Cumulus from TNG Technology. Many of the examples from this book will be applicable to cards in these games. Cornucopia is specifically designed for e-commerce applications and there are more threat categories, however, it doesn’t map directly to STRIDE (which stands for the following threat categories: spoofing, tampering, repudiation, information disclosure, and EoP) if you have chosen to use this methodology. Cumulus, as the name suggests, is aimed at threat modeling cloud solutions. You can download these two games at the following links:

• OWASP Cornucopia: https://owasp.org/www-project-cornucopia/#div-cards
• TNG Technology Consulting GmbH’s Cumulus Cloud Threat Modeling Cards: https://github.com/TNG/cumulus

Now that we have the resources we need to play the game, let’s see who you should invite to play this game

Preferably, you want between four and six players, covering different roles in the project and not necessarily technical roles. For example, you should include the software architect, a frontend/UI engineer if there is a UI component to the system, a backend engineer, a quality engineer, someone from the product team, and perhaps someone from compliance with knowledge of your privacy policies. The reason you want people from these different roles is to have a broader context. The product team is usually customer facing and so will be able to add context from that side of things; compliance will know what customers have signed up for, and what regulations and certifications the company needs to maintain, which will give additional context. People in different roles usually think differently because there is a certain amount of neurodiversity, so something one person misses others might spot.

You might find that people from product and compliance don’t believe they will be useful because they may not feel they have the technical background. An analogy I like to use to make them more comfortable and feel more at ease is that you don’t have to be a locksmith to know that if your key breaks in your front door lock, there is nobody home, and you’ve not got a key for another door, then you have a problem.

Now that we have our resources and we’ve invited the team members, we need to play the game. Let’s see how the game is played.

It’s like any other card game, in so far that you win hands by playing the highest card. You have different suits; the cards have values and the aces are high cards. You win the hand by playing the highest card either of the same suit or by playing a trump card. With some variants, the cards go beyond ace as you will see in future chapters.

The difference is the objective, which is to find as many threats as possible, and if helping one another means you achieve that objective, then even better. It might seem less competitive that way, but later, you will see there are ways around that.

If you think of each hand as a battle and the game as a war, then what I am about to tell you will make sense. During each hand, you get points for finding threats, and those points, although won’t win the hand, will accumulate and may mean you win the game.

Preparation

To play the game, you should deal the cards to each player until all the cards have been dealt. Depending on which variant you are playing, you will have between 6 and 11 suits. You can remove suits to reduce the time required / scope of the exercise if playing remotely. You can do this using the Croupier app and then distribute the cards to the players over chat or email, or, if you are all together, you can deal from a deck.

Aim

As the aim is to find as many threats as possible, players should avoid thinking about mitigations. This means they shouldn’t think, “We’ve already protected against that type of threat so it’s not valid anymore.” Instead, they should think, “Aren’t we clever spotting that threat and documenting both the threat and the protection that was put in place?”

Take the example of Transport Layer Security (TLS) or Hypertext Transfer Protocol Secure (HTTPS) for encryption in transit (sending data securely); not using it is a threat, using it means you have mitigated that threat (put a safeguard in place), and, as such, you should document this as part of your model. So, players should try and think where something can happen and then determine whether there is protection in place, document it, and, if not, propose one.

Why document something that has already been considered? So that if, at some point in the future, you are the victim of a threat actor and your company is held accountable, you can show that you did your due diligence and tried to protect your customers from as many threats as possible to the best of your ability.

To start

The player with the 3 of tampering starts the game. They should read out the card they are playing for the benefit of the other players. They should look at their architecture diagram and try to recognize where the threat described on the card can occur. In the case of the 3 of tampering, “An attacker can take advantage of your custom key exchange or integrity control, which you built instead of using standard crypto,” they should look for anywhere that cryptography or hashing is being performed in your architecture. If you are using standard crypto or hashing, then the threat still exists, and you can add what you are using as the mitigation of this threat.

If the player cannot find the threat or is unsure how the threat might occur, other players can help or make suggestions. They can also make suggestions of other places where the threat might occur. As a variant of the standard game, you could use this to assign extra points or even to steal points from other players. This can keep going until all other places where the threat can occur have been exhausted.

Don’t forget!

It’s a card game, so it should be fun as well. Like any other card game, the player who plays the highest card in the suit chosen at the start of the hand wins the hand.

There is a catch though; Elevation of Privilege cards are trump cards and if a player doesn’t have a card in the suit you are playing, they can play a trump card. Playing a trump card doesn’t guarantee you’ll win the hand either, though, as someone might play a higher trump.

Points

Winning the hand gets you a point. As the point of the game is to find threats, finding a threat also gets you a point. The way I play it, finding multiple threats in a hand can get you a bonus point. This makes it possible to get a maximum of three points for your card in a hand, one if you win the hand, one for finding at least one threat, and one if you find any additional threats. You can, however, get extra points for finding occurrences of a threat for the card of an opponent.

So, how many points can you make in a hand? Let’s see:

• One for winning the hand
• One for finding your threat
• One for finding more occurrences of your threat
• n (players – 1) points if you find a threat for each card that your opponents play

  This means that if there are six players, you could get eight points in a hand.

You might consider giving points for suggesting mitigations for any new threats found, but you can decide as a team what works best for you.

Who goes next?

If you’re playing in a room, it could be the person next clockwise or anticlockwise around the table; if you’re playing online, it could be whoever was next when the names were put into the Croupier app. It doesn’t really matter; just make a note of the order for future hands.

When one hand finishes, the winner of the hand (not who has the most points) gets to choose what suit comes next and they open the hand playing the first card. The player after them will be whoever followed them in the last hand.

Keep going until you’ve run out of suits or cards in your hand, whichever you prefer.

While playing, you should be making a note of the threats found on the scorepad, potentially creating tickets for those threats and proposals for mitigating them. If you’re playing remotely, this can be done by adding stickies to the collaboration board; I’ve used red ones for threats, green ones for mitigations, either already implemented or already in the design, and orange ones for mitigation proposals.

Who’s won?

The customer, because the product is more secure.

Joking aside, whoever has accrued the most points during the game is the winner, just like any other game. What do you win? Well, that is entirely at the discretion of the team or your management. It could be kudos to your team, it could be a voucher, or it could be something else; I leave it up to your imagination.

Variations of gameplay

Some teams prefer to pick a suit and go through all the cards one by one discussing them as a team. This removes some of the gamification aspects but is still an effective way of threat modeling the architecture.

Other teams prefer individually adding threats where they believe they can occur simultaneously and then discussing each other’s ideas once all the players are happy that they can’t find any other threats. Again, it can be an effective means, but it removes some of the gamification aspects of threat modeling with the EoP game.

The group discussion can also be a very powerful means to spark ideas in others where something similar can occur. Some players favor this approach over another, perhaps because there is a very outspoken member of the team or because they are timid. If you are facilitating a threat modeling session, you should be aware of the team dynamic and you should try and help each player feel comfortable and able to give their input.

Obstacles

Initially, you may need to find teams that are willing to experiment and open to championing the approach with their colleagues. Product teams are often under pressure with tight deadlines; these deadlines are often driven by a need to sell new features. So, this is all the more reason to involve people in defining these deadlines because it will help them understand that the upfront investment could save time and effort later. Once they start to see the benefits, you will find the time is included in the planning.

Initially, there is a learning curve because teams will be learning the technique by doing, and engineers will undoubtedly complain that it takes time. As they improve, they will get faster, but initially, they will be threat modeling both the legacy and the new. However, soon they can concentrate on the new features.

Some will complain that there is repetition between projects; this is a problem relating to the documentation or processing of the models rather than the models themselves. I would recommend using what I call a hybrid approach. Using a tool that will allow you to draw your architecture from your existing models either through templating or as components will promote re-use. If the tool also offers some level of automated threat modeling, then even better. This will allow you to capture the basic threats or low-hanging fruit related to the standard components in your system, letting you concentrate on the proprietary technology in your system. It will also speed up the process.

Scaling your threat modeling program

Gamified threat modeling is a great way to train engineering teams to threat model; it will help them develop the skills needed and they will be able to self-serve. The security team should still be involved but more in a supervisory role, reviewing threat modeling reports or offering consultancy when teams feel they need support with a particularly security-sensitive project.

As teams mature, members from one team will be able to facilitate for members in another team, allowing for accelerated diffusion of the know-how within the organization.

Again, a hybrid approach would also allow for your program to scale because teams would be able to make use of existing models of components parts of their system.

Performance metrics and reporting

Most organizations will already have metrics around the number of escaped vulnerabilities or issues found during penetration/security testing. Over time, you should see a reduction in these.

If you record the threats found during modeling and create tickets for all the suggested mitigations, labeling them as coming from threat modeling, you should be able to track them. Recording the number of threats found, the effort in implementing the mitigations, the reduction in the number of escaped vulnerabilities reaching pen-testing, and the associated average cost of those escaped vulnerabilities, should allow you to demonstrate the value of the program in monetary terms.

Coming up

In the coming chapters, I will introduce the chapter with a brief explanation or definition of what the threats category name means. Then, I give examples for each of the threats described on the cards; some cards may have multiple examples. Each example is structured as follows:

2. of EoP Suit

The description of the type of threat from the card is as follows:

As you can see, the title of an example (2. of EoP Suit in this case) is the card value followed by its suit or threat category as you might prefer to call it. This is followed by the card description as you would read it on the face of the physical cards.

Next in the red threat table, an example threat is described to guide you and help you understand how this threat might manifest itself in a real-world application.

Following the example are references coming from Mitre and Open Worldwide Application Security Project (OWASP):

• Mitre Common Attack Pattern Enumeration and Classification (CAPEC), which you can look up here: https://capec.mitre.org/index.html
• Mitre Common Weakness Enumeration (CWE), which you can look up here: https://cwe.mitre.org/index.html
• OWASP Application Security Verification Standard (ASVS), which you can look up here: https://owasp.org/www-project-application-security-verification-standard/
• You can also use my CAPEC STRIDE Mapping Mind maps that map the CAPEC entries to the STRIDE categories and it contains many threats you won’t find on the cards that you may be able to use for the ACE cards: https://www.ostering.com/blog/2022/03/07/capec-stride-mapping/

CAPEC

CAPEC is a directory containing almost all known threats, created by Mitre with the following license: https://capec.mitre.org/about/termsofuse.html.

Each threat in the directory is classified and any associated threats, macro categories, or child categories are included along with a detailed description of the threat.

CWE

CWE is a directory containing an extensive list of software and hardware weaknesses that cause vulnerabilities, created by Mitre under the following license: https://cwe.mitre.org/about/termsofuse.html.

Each weakness in the directory is classified, and any related weaknesses, macro categories, or child categories are included, along with a detailed description of the weakness.

STRIDE

STRIDE is a framework for threat modeling and was invented at Microsoft by Praerit Garg and Loren Kohnfelder. The framework helps by giving you key threat types, which can help you reason where the software architecture might be susceptible. In EoP, these categories are used for the different suits in the card deck. CAPEC has its own classification and isn’t classified according to STRIDE, so I created the mind maps to help you if you want to advance your threat modeling skills further.

Important note

There are three things you can do to protect yourself from a risk:

a. One is to mitigate the risk (you would use compensating controls here)

b. Another is to transfer the risk (insurance, terms and conditions, and contracts are all examples of this)

c. The last is to avoid the risk (don’t do what it is that causes the risk, for example, skydiving has a risk of death if your parachute doesn’t open; if you don’t do skydiving, the risk of dying from skydiving doesn’t exist)

Ignoring a threat is not something that will reduce your risk.

Next, the green table contains a list of potential mitigations or compensating controls that in some cases will reduce the risk of the threat, in others they may remove the risk of the threat entirely. You can use a combination of multiple mitigations to reduce the risk even further in some cases.

In this chapter, you’ve learned the following:

• What you’ll need to perform the threat modeling session.
• Where you can get the cards to play the game.
• The different decks of cards you have available.
• Where you can find a number of additional resources to support you in threat modeling, including a Miro template for remote threat modeling, a web app for dealing the cards remotely, and an online version of the game that you can run on your local network.
• Who should participate in the threat modeling and why.
• How you play the game and what the aim of playing EoP is.
• Some variations of play that may work better for you as a team.

I’ve then given you a sneak peek at what’s to come in the next chapters and where you can go and look up all those references you’ll see going through the book.

In the following chapters, you will see examples for each of the cards in EoP and some of its extensions. Having read this chapter, you are now in a position to jump straight in and start threat modeling, and for each card being played, either by you or other players, you can look it up and see one or more examples to help you understand the threat and give you an indication of where it might occur in your architecture. Happy threat modeling!