Secure Engineering – Threat Modeling

In my previous post, “Security Training for the Development Team,” I shared the experience of building a security training program for the development team. 

In this part of my Secure Engineering blog series, you’ll learn about another essential step of securing engineering: threat modeling. This blog provides an overview of threat modeling. It’s an important method, and some companies use its basic approaches to secure platforms and applications.

More recommended reading on Secure Engineering: 

• Secure Development Lifecycle: Importance & Learning
• Security Training for the Development Team
• Security Requirements For The Development Team

Threat modeling is a process of identifying and mitigating potential threats. You can apply it to software, networks and real-life situations. In the context of software security, it not only ensures security while developing the software but also develops the security culture and mindset of the team. 

Traditionally, threat modeling is a complicated and time-consuming process that is document-centric and manual, which is why most teams try to avoid threat modeling. But understanding and mitigating threats are becoming a critical part of the software development process and can no longer be avoided. Furthermore, if executed correctly, threat modeling pays for itself by reducing the number of security bugs, security patch releases, and attack possibilities. 

Teams should iteratively complete threat modeling during the design phase, although there isn’t a perfect threat model; threat modeling is never “done.” The team must find the right balance for threat modeling according to the security requirements and threat environment to create a ‘good’ threat model. 

A team can start threat modeling as soon as the basic design is ready. Generally, threat modeling has five steps (DCTMD):

1. Define scope 

The team should first define the scope of threat modeling. Teams can use threat modeling for the entire platform, product, sub-system, or a single module or feature. Our recommendation is to start at the single module or feature level as the team does the detail designing because completing threat modeling for the complete platform or product can be overwhelming. Teams can use module or feature level threat models to easily build the threat model. 

2. Create DFD

The data flow diagram will help the team visualize data flow and trust boundaries. Without a good DFD, it is difficult to understand all threats, and the team can miss some crucial threats. DFD details and complexity can be dependent on the security requirements and risks.

3. Threat Analysis

Once a team has DFD(s), they can start with identifying and analyzing threats. There are many different threat modeling methods. Some of the most used include: 

• STRIDE 
• PASTA
• LINDDUN
• CVSS
• Attack Trees
• Persona non Grata

We recommend using STRIDE as it is easy to use, most mature, and focuses on identifying mitigation techniques and threats. 

Not all threats are equal, so a team needs to prioritize them. We recommend using likelihood and impact for this:

• High Priority Threats = High Likelihood and High Impact
• Medium Priority Threats = Medium Likelihood and Low Impact
• Low Priority Threats = Low Likelihood and Low Impact

4. Mitigation 

Once a team identifies all threats, the next step is to mitigate each valid threat. A simple STRIDE table can help a team with it.

5. Documentation 

Documentation is the last step of effective threat modeling. A team doesn’t need to create extensive documentation, but a team should create documentation they can refer to in future threat modeling or during design changes. Without good documentation, a team may need to complete another round of threat modeling. We recommend documenting the following:

• Valid threats
• Test cases for valid threats 
• Mitigation details

Threat modeling is a specialized area, but the above details can help a team to have a basic understanding of what’s involved and begin the threat modeling process. Please feel free to contact us if you would like assistance with threat modeling.