An overview of threat modeling: Securing your applications proactively

7 min readMay 22, 2024

In today’s rapidly evolving digital landscape, security is still being seen as a cost center for many companies, since securing products does not directly make any money. But, if no action is taken to harden our products it can cause a loss of millions of dollars and company reputation.

Some time ago I created an overview of Thread Intelligence which had a lot of interaction and interest between people willing to learn more about security, today, I’ll provide an overview of what threat modeling is, its importance, and how to implement it effectively in your security strategy.

What is Thread Modeling?

Threat modeling has roots in military strategy! The concept of threat modeling isn’t just a modern cybersecurity practice; it has historical parallels in military strategy. Just like threat modeling in software involves identifying potential threats and vulnerabilities to devise defensive measures, ancient and modern military strategists have long used similar approaches to assess and mitigate risks on the battlefield.

If we google for thread modeling in software we will find some results like:

Thread modeling is a powerful guide to protect our valuable assets in the early stages of development, saving time and identifying weak areas to have an action plan when a weakness is discovered.

But what does this mean? Well to understand what threat modeling is and its benefits we need to start from the basics of SDLC (Software Development Life Cycle)

As you can see in the next image, the traditional SDLC consists of 6 different phases, where you plan what you want to execute, analyze if it is feasible, design the architecture, then you implement it and then QA tests and integrates everything, and the last phase is maintenance of the application.

But what is wrong with this? In reality, there is nothing wrong but as you can see security is not in any part of the diagram, even though some companies can execute security tests during the testing & integration phase, it will be harder to fix since several months have passed since the early stages started, so changing a critical vulnerability will be difficult since it could also require changes in the initial proposed architecture.

During these last years, a couple of new concepts have been gaining popularity, such as SSDLC (Secure Software Development Life Cycle) and the Shift-Left approach in the Development Security Operations (DevSecOps)

When we talk about Shift Left, this incorporates software testing procedures, such as security, as early in the software development lifecycle as feasible, on the other hand, SSDLC covers from the beginning to the final product with security in mind, let’s take a look:

In the next image, we can see that we have similar phases of SDLC, Requirements, design, implementation, test, deployment, and maintenance but we also have a couple of security assessments that can be performed during these development phases, such as SAST, PENTEST, Thread modeling, so we work with different vulnerability and risk assessment. Cool isn’t it?

So, why am I explaining all this? Well, when working on thread modeling roles you are expected to have a full understanding of SDLC as well as know how to code, as you can see thread modeling relies on the early stages of the SDLC, specifically during the design phase.

When working with Thread Modeling we have access to architecture diagrams, we meet with developers to understand what they are building, and around that we can spot weak areas and suggest changes to the teams to mitigate possible vulnerabilities.

So what Threat modeling is? It is a formal and structured examination of the application components to identify weak areas and how we can mitigate them, allowing us to improve the security posture and have high confidence that our application meets the needed standards.

The primary goal for Thread modeling, is to visualize the application’s attack surface, identifying possible attack vectors, and devising appropriate defensive measures.

How can I start performing thread modeling?

Thread modeling is a never-ending process, it starts when you are building a new application, and if new features are added, the outputs of the thread modeling process must be updated accordingly.

To start implementing the thread modeling, you should know that some frameworks such as STRIDE from Microsoft, or PASTA (if you are working closely with development) are a good start, they work as a guide to make sure that we are covering different scenarios, let’s deep dive into STRIDE.

STRIDE

As I’ve mentioned, STRIDE was developed by Microsoft, and it stands for different threads:

S(spoofing): Which affects Authenticity
T(tampering): Which affects Integrity
R(Repudiation): Which affects Non-repudiability
I (Information Disclosure ): Which affects Confidentiality
D(denial of service): Which affects Availability
E (escalation of privilege): Which affects Authorization

Using this, we can evaluate different threats within our application, but how can I achieve this? Well let’s deep dive now into the DFD (Data Flow Diagrams)

Data Flow Diagrams (DFD)

When working in thread modeling, the DFD are our best friends, they are an abstraction of what the application, it allow us to identify the flow of data within the application, allowing us to spot trust boundaries, and also weak areas

There are different levels of DFD, starting from 0 to 2 or higher, the higher the level, the deeper into details it goes, and allows us to identify more weaknesses.

Here is what a DFD-0 looks like (Level-0): As you can see a pretty simple and high-level perspective, abstracting a lot of the complexity

Here is what a DFD-2 looks like (Level-2): In this level dive deeper into the subprocess, and we can keep increasing the level by identifying everything that is being done by each of the components

So as an example, let’s assume that we are performing thread modeling for a bank:

Level 0 DFD: Shows the entire banking system as a single process interacting with users, third-party payment gateways, and external databases.
Level 1 DFD: Break down the system into processes like “User Login”, “Account Management”, “Transaction Processing”, and “Report Generation”.
Level 2 DFD: Further decomposes “Transaction Processing” into sub-processes like “Input Validation”, “Transaction Validation”, “Database Update”, and “Notification”.

Here is a pretty cool article about DFD if you want to learn more https://www.linkedin.com/pulse/data-flow-diagram-dfd-levels-dfd-0-dfd-1-dfd-2-how-impacts-shachar/

Trust Boundaries

I did mention trust boundaries in the previous section, these are important since will allow us to connect the DFD to the STRIDE model. Trust boundaries are meant to spot places where the level of access of a user or process changes

For example, let’s assume that a user needs to log into the system to perform some actions, well we are passing from an unauthenticated session to an authenticated session with some privileges, and when we are storing that info at the db level, a subprocess with authentication with the database perform the write operation.
The trust boundaries are marked with lines and labeled. This is important since it will allow us to identify how the different components interact

Unifying DFD with STRIDE

It is nothing fancy usually we can write a report in Excel, but the trust boundaries will help us define the level of access required for each tool.

Once we have the different DFD and trust boundaries in place, we create a table to compare the communication of a component with another one, in this case, The User with the App Backend and vice-versa, the AppBackend with the User, also the App Backend with the DB and vice-versa, you got the point, right?

So in this table, we put the STRIDE and identify the Strengths and weaknesses of each component, one weakness of the app backend could be that it is not performing input sanitization and a strength, that it uses HTTPS.

The idea is to understand what the application does, be familiar with the common attacks and techniques, the broader knowledge you have, the better thread modeling reports you will get!

Conclusion

Threat modeling is a critical component of a proactive security strategy. By systematically identifying, assessing, and mitigating potential threats, organizations can significantly enhance their security posture and protect their applications from evolving cyber threats. Implementing threat modeling early in the development lifecycle not only helps in managing risks more effectively but also contributes to building secure, resilient applications that stand up to the challenges of today’s threat landscape.

Start incorporating threat modeling into your security processes today to stay ahead of potential threats and safeguard your valuable assets.