Game Play

In this chapter, I’m going to walk you through what you need to play Elevation of Privilege (EoP) to threat model your software design. We are going to talk about how the participants should be selected to get the best results from threat modeling and why participants should have different roles in the project. Last but not least, we will see how to play the game and understand what’s the end goal of playing the game – finding out as many threats as possible. However, before we get started with all these, I would like to begin with a couple of words on what threat modeling is, as well as when you should threat model and why.

Threat modeling is a process to identify threats to and design flaws in the system you are designing. A threat is something that could go wrong in the system you are designing; it may be open to attack, it may be subject to some failure, or it may be open to human error. A mitigation is a safeguard or protection you can put in place to protect against a threat or at least reduce the risk a threat poses. So, when we threat model, we are looking for what could go wrong, how we can improve the system to stop that from happening, and finally, deciding whether we’re happy that even if the worst happened, it wouldn’t be all that bad because we’ve done a pretty good job.

When should we start? You should be able to begin threat modeling from the moment you are able to draw what your system will do and what parts it is made up of. Threat modeling is not a one-off exercise; it should be performed continually as your system evolves and it should be performed during the design phase of each version, and if the design changes during development, the process should be repeated to reflect those changes. Now, let’s look at why it should be performed so early in the software development life cycle (SDLC).

When you build a house, it’s built on foundations, and it could be extremely complicated if you need to change those foundations halfway through construction. Design flaws are usually very difficult and costly to remediate once a project is underway.

Implementation flaws, on the other hand, are not necessarily difficult to fix after the fact. Using the housing analogy again, fixing an error in the foundations may mean tearing down parts of a construction and starting again from the foundations, whereas using a faulty or weak lock in a door is simple to fix because doors are designed to support standard lock fittings, you can just change the component.

So, we can conclude that it is always a wise choice to threat model early as it’s an upfront investment that pays dividends.

Threat modeling can be used as a process for finding or eliciting security flaws in the design of a software system, although you could threat model any system. EoP is a category of threat and it is from this that the EoP card game for threat modeling takes its name. The EoP game was invented to facilitate threat modeling in teams as it prompts the participants with types of threats too.

As such, we will be covering the following main topics in the chapter:

• What you’ll need to play the EoP game
• Who should participate?
• How to play EoP

By the end of the chapter, you will be familiar with the EoP card game, you will know where you can find useful resources to facilitate threat modeling with the game both remotely and in a single location, and you’ll know who to invite.