How to play EoP

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:

Threat
	A description of the example threat
CAPEC	One or more CAPEC entries that you can lookup
ASVS	One or more ASVS entries you can lookup
CWE	One of more CWE entries you can lookup

Mitigations
	A potential mitigation Another potential mitigation

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.