Secure Engineering – Threat Modeling

URL copied!

Categories: SecurityTechnology

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:

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

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.

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.

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.

Category	Definition	Applicability
Spoofing	Pretend to be someone or something else to gain access or trust.	Identity and Process
Tampering	Deliberately modifying data.	Process, Data storage and Data flow
Repudiation	Not able to track users’ actions.	Identity, Process and Data storage
Information Disclosure	Leakage of private and confidential information.	Process, Data storage and Data flow
Denial of Service	Making system or information not available	Process, Data storage and Data flow
Elevation of Privilege	Elevate the system access	Process

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

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.

Category	Control
Spoofing	Strong Authentication (like MFA)
Tampering	Encryption of Data at Rest, Data at Motion and Data at Use
Repudiation	Logging, Tracing and Monitoring
Information Disclosure	Encryption
Denial of Service	Site Reliability
Elevation of Privilege	Authorization

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.