DICE – threat modeling in 4 steps

Is securing systems a game or a gamble? As the attacking factor is uncertain and unpredictable, you might have the feeling that security is more like a gamble. However, you can turn security into a game that – when using the right tactics – can be won. In this article we will present threat modeling as an effective way to turn the table and get a better control on your application risk. We will introduce you to the 4 steps of threat modeling with the DICE acronym.

Threat modeling is performed through a series of multi-stakeholder workshops. Architects, developers and system administrators are guided through the threat modeling process. It is the primary security analysis task executed during the software design stage. Threat modeling is typically performed in 4 stages or steps:

• Diagram: what are we building?
• Identify threats: what can go wrong?
• Countermeasures: what are we doing to defend against threats?
• Evaluate: validation of previous steps and act upon them

We named the 4 steps this way to match the acronym DICE. Not only because it is easier to remember the steps. It also introduces the concepts of luck and risk. In a game you throw the dice to advance and possibly win or lose. With threat modeling you get a better understanding of the risks and reduce the amount of luck to prevent or detect an attack on your system.

Step 1: diagram the application

In this step, you gain a comprehensive understanding of the mechanics of your application. In other words: you understand what you are building. That makes it a lot easier for you to uncover more relevant and more detailed threats. This also includes the identification of clear security objectives. They help you to focus the threat modeling activity and determine how much effort to spend in the following steps. When you have documented the important characteristics of your application and actors, you can identify relevant threats during the next step more easily.

Step 2: identify threats with STRIDE

You use details from the previous step in the STRIDE phase to identify threats relevant to your application scenario and context. With STRIDE, you can flawlessly identify what can go wrong.

STRIDE was developed by Microsoft to educate developers on how to think about computer security threats, and is an acronym for:

• Spoofing: can an attacker gain access using a false identity?
• Tampering: can an attacker modify data as it flows through the application?
• Repudiation: if an attacker denies doing something, can we prove he did it?
• Information disclosure: can an attacker gain access to private or potentially injurious data?
• Denial of service: can an attacker crash or reduce the availability on the system?
• Elevation of privilege: can an attacker assume the identity of a privileged user?

Each of these threats is the opposite of a property that you want your system to have. Spoofing – for example – is the opposite of authentication.

Step 3: Countermeasures: mitigate identified vulnerabilities

In this step, you review the layers of your application to identify the necessary security controls related to your threats. Vulnerability categories help you focus on those areas where mistakes are most often made.

Step 4: Evaluate

The final step is to evaluate the whole threat model. Is each threat mitigated or not? And for unmitigated threats: are the residual risks clearly explained and tied into business risks? In this validation step, you also decide and follow-up on the next steps to manage the identified threats.

Do you want to take your application security controls to the next level? Do you want to apply DICE to your system? Then book a seat in one of our upcoming Threat modeling Practitioner trainings.