Threat modeling in 4 steps

We convinced you of the use of threat modeling in a previous post. But where and how do you start? Threat modeling is performed through a series of 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 steps:

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

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: 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: validate

The final step is to validate 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 the 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? Say no to threats and book a seat in our open Hands-on Threat modeling training.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *