Threat Modeling: The Only Proactive Security Assessment
Learn how threat modeling prevents security vulnerabilities before they happen. Discover why it's the only proactive security assessment, plus practical guidance on implementation, tools, and ROI.
In the previous article, we explored the landscape of security assessment types and introduced five key features that distinguish them: Goal, Scope, Time, Effort, and Automation. Today, we’ll examine threat modeling through this lens—arguably the most unique assessment type in our toolkit.
What makes threat modeling special? Unlike other security assessments that find problems after they exist, threat modeling prevents them from occurring in the first place. It’s the only truly proactive security practice in the SDLC, allowing teams to identify and address potential vulnerabilities before writing a single line of code.
In this article, I’ll demystify threat modeling by covering:
What threat modeling actually is and what it produces
The strategic objectives it helps achieve
How scope affects implementation across different organizational levels
Practical considerations for time, effort, and automation
Why it’s foundational to modern secure development practices
Whether you’re implementing threat modeling for compliance, cost reduction, or genuine security improvement, understanding these fundamentals will help you navigate the practice effectively.
This article series includes:
Part 2: Threat Modeling (you are here)
Part 3: Security Audits Explained (coming soon)
Part 4: Vulnerability Assessment Guide (coming soon)
Part 5: Penetration Testing Deep Dive (coming soon)
Part 6: Red Teaming for Organizations (coming soon)
TL;DR: Threat modeling is the only proactive security assessment—it prevents vulnerabilities rather than finding them. By answering “What are we working on?”, “What can go wrong?”, and “What are we going to do about it?”, teams identify and address security issues before implementation. It serves two strategic goals: reducing defect costs and demonstrating compliance. Scope varies from entire organizations to individual features, with time requirements scaling accordingly. Best conducted with 3-6 diverse participants in focused sessions. While tools can help, the real value lies in embedding security thinking into teams through repeated practice. Unlike other assessments that verify security after the fact, threat modeling builds it in from the start.
What is Threat Modeling? Definition and Core Concepts
For starters, let’s define what threat modeling actually is. The best definition I know comes from the Threat Modeling Manifesto and goes like this: “Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.”
This analysis occurs during a threat modeling session, where we address three fundamental questions:
What are we working on?
What can go wrong?
What are we going to do about it?
To these three fundamental questions, we can add a bonus one: Did we do a good enough job?
Our analysis ends with an artifact in the form of a threat model. Such a threat model can look like this:
Or like this:
Or even like this:
The form of the resulting threat model isn’t important, as there are many ways it can be represented. However, what is important is that by conducting threat modeling, you deliberately create a threat model that can later be used to prevent issues, demonstrate compliance, or serve as a baseline for further verification (i.e., answering the bonus question—did we do a good enough job)… but I got ahead of myself here, so let’s step back.
Why Use Threat Modeling: Strategic Benefits and ROI
Now that we know what threat modeling is and what are its products, we can dive deeper and answer questions like when, where, and why we would use it. Among these, answering the why question seems like a good first step.
So, why would we bother with threat modeling in the first place? Or, to put it more professionally: What are the strategic objectives we might want to achieve with threat modeling?
While working on implementing this process, I identified only two such objectives:
Reducing the cost of software defects and security verification
Demonstrating compliance
As I already mentioned, we can use threat modeling to prevent issues from escalating into vulnerabilities. We can also use the resulting threat models to serve as a baseline for further verification through other assessments (e.g., penetration testing). Both of these reduce the overall cost of the SDLC:
As for compliance with regulations or industry standards, performing threat modeling and storing the resulting threat models is direct proof of the practice. Furthermore, if compliance is the sole reason for the practice of threat modeling, then we could perform it retroactively (i.e., after the thing we are building is built). Of course, working retroactively decreases ROI, but it often meets regulatory obligations and might be a good first step in initiating threat modeling as a practice.
Threat Modeling Scope: From Features to Enterprise
The scope of threat modeling can vary significantly, which is why it is often challenging to understand for newcomers. To clarify this matter, let’s consider a typical tech-savvy organization as an example to illustrate how we could approach threat modeling.
To begin, we could perform threat modeling for the entire organization to identify potential threats, such as advanced persistent threats (APTs) that could lead to serious incidents. This process would consider all aspects, including people, processes, and IT. Subsequently, we could intensify our focus by conducting threat modeling exclusively on the IT infrastructure. We could then analyze a specific network segment, such as a Kubernetes cluster, or an individual system within that segment, like a group of microservices. From there, we could further narrow our focus to a specific application within the system, like an individual microservice. Finally, we could zero in on specific features within this application, such as a feature developed during the current sprint.
In all these cases, we would perform threat modeling, but since our POV is changing, we would require different people and different tools for each perspective.
How Long Does Threat Modeling Take? Time Requirements by Scope
Time depends on the scope, meaning the breadth and depth of the perspective we take—if we’re talking about threat modeling for a specific feature, it will take less time than threat modeling for the entire IT infrastructure. There is a simple relation here:
more elements to analyze = more time required.
In one of the gazillion podcasts I listen to, I learned that threat modeling for the Xbox ecosystem took several months, which is entirely feasible considering its scope. This doesn’t mean all work stopped while everyone focused solely on threat modeling. Rather, I assume it was part of a larger architectural design process for the solution considering Microsoft SDL.
One thing to keep in mind is that scope and time required significantly affect the frequency of threat modeling. So, how often should it occur? It depends on what is being modeled.
For example, if we’re talking about threat modeling at the feature level and we’re using Agile methodology, then each sprint could include a dedicated threat modeling session to focus on the security aspects of what we intend to build. However, this doesn’t mean that each time we need to create a comprehensive threat model for the entire system. Instead, we could allocate 45-60 minutes to address the questions “what can go wrong” and “what are we going to do about it” with regard to the scope defined by the sprint itself (“what are we working on”). These insights can then be documented and added to the relevant tasks within the backlog.
On the other hand, if we were to perform threat modeling for an entire organization, then it would take more time and could be more infrequent (e.g., annually).
Who Should Participate in Threat Modeling Sessions?
When considering the size of the working group conducting threat modeling, it is recommended to keep it small.
Avoiding overly large groups is important because each additional member increases communication issues non-linearly. Based on my experience, the ideal group size for a single threat modeling session is 3 to 6 people, including the facilitator who leads the discussion.
I’d also like to emphasize the crucial role of having a diverse array of roles involved in a threat modeling session. For example, when conducting threat modeling for an application’s features, the working group might include developers, architects, QA engineers, and even product owners. On the other hand, modeling threats for infrastructure requires the involvement of security professionals and operations staff, rather than software engineers.
Can You Automate Threat Modeling? Tools vs. Human Analysis
Threat modeling can be enhanced with the use of specialized tools. A popular choice is the Microsoft Threat Modeling Tool or its OWASP counterpart, Threat Dragon. Both of these tools are available for free, alongside various commercial alternatives. These tools primarily aim to automate certain aspects of the threat modeling process. However, it is important to understand that this semi-automation cannot yet replace the analysis performed by those who build and maintain the system. It remains fundamentally limited since it often generates only generic threats and frequently results in false positives.
The advancements in LLMs offer a promising future, but based on my experience and that of others (warm regards, Filip 😊), they work best with an operator who is already proficient in threat modeling and knows what to ask for.
So, while certain aspects of threat modeling can be automated, I believe its primary value lies in raising the baseline for security awareness. When a team actively engages in these sessions, security thinking gradually becomes embedded in their daily work through repeated iterations. As a result, during feature implementation, team members instinctively start to consider potential issues and what might go wrong.
A similar effect on the improvement of security awareness can be observed with a well-executed SAST process, which not only establishes guardrails but at the same time gradually elevates the team’s baseline security awareness.
Bottom Line: Threat Modeling as Your Security Foundation
In the home building analogy I introduced in the first post of this series, threat modeling takes place at the very beginning; we conduct it before we start constructing anything in order to understand the threats we need to consider. Here, we answer, “What are we working on?”—which is our home. We address “What can go wrong?” in the context of our property, location, and fence, and finally we determine “What are we going to do about it?”
This process helps us avoid potential vulnerabilities, both architectural and implementation-related. Furthermore, we can later utilize this threat model to verify our assumptions during other types of assessments. Additionally, the threat model can serve compliance purposes during a security audit.
In my opinion, threat modeling is one of the fundamental practices in the SDLC because it enables you to avoid mistakes, setting it apart from other security assessment types as the only proactive action.
That’s all for today. Next, I’ll concentrate on security audits. Subscribe to receive updates directly in your inbox.