Master Threat Modeling with Toreon’s World-Class Approach

10 April, 2025

Threat modeling shaped my AppSec career. It helped me wrestle with one of security’s most deceptively simple questions: “Is your system secure?”. “No” is clearly not a good answer. But “yes” is even worse. It signals that someone has no idea how security really works. Learning how to do threat modeling gave me a better way to answer that question: “Here are the threats and the risks we identified. And here’s how we are mitigating them.”

Over the past few years, threat modeling has gone through a strange evolution. Once ignored, it is now getting attention. Yet many organizations still struggle to do it right. Some even claim that threat modeling is dead and suggest we should start calling it “attack modeling” instead. Others have embraced it, but often in ways that miss the point entirely. What I have seen time and time again is that most threat modeling efforts fail. They turn into box-ticking exercises, overly complicated rituals, or worse, a solo effort led by a “heroic modeler”.

Toreon has spent more than a decade helping teams get threat modeling right. This blog builds on their work, my own experience, and the OWASP SAMM model. Whether you are new to threat modeling or trying to streamline it in your organization, this guide will help you focus on the key building blocks.

What is not threat modeling?

Before we explain what threat modeling is in a nutshell, let us look at activities that are often confused with threat modeling, but are not.

Penetration testing

Threat modeling is not the same as penetration testing. Pen tests are usually done by external experts with limited context about the system. Their focus is often narrow, targeting technical vulnerabilities. Pen testing and threat modeling work best when combined. In fact, using your threat model as input for a pen test is a smart move. That is exactly what we did with Toreon during a recent assessment of our SAMMY platform. We shared our threat model with them up front. It helped focus their efforts on the areas that mattered most to us. For instance, we told them that SAMMY’s administrative interface is a low risk component as it is only accessible by two people in the entire company. On paper, a critical vulnerability in the admin panel might sound alarming. However the real-world risk is low. Now, if you ask, “What if someone takes over one of their machines?”. Congratulations! You are now threat modeling.

Security testing tool scanning

I often hear teams say they use SAST and DAST scanners as part of their threat modeling. On the surface, that sounds reasonable. After all, the tools find problems, right? But this is not threat modeling. Not even close. Scanners have their place. They are useful, but they do not replace critical thinking. Think of it like training for a sport. Scanners are physical conditioning. Threat modeling is learning how to play. You need both. No scanner will tell you about broken trust boundaries or misuse scenarios. Threat modeling is where those issues come to light. Now imagine this. What if your scanner results leak online? There you go. That is a real threat you would find during threat modeling.

Automated threat modeling with tools and AI

This idea is getting a lot of attention with the rise of AI and large language models. The pitch sounds simple: feed a tool enough context and it should generate a threat model for you.In theory, that sounds great. In practice, we are not there yet. You can provide your architecture, your risk appetite, even your codebase. But I have yet to see any tool create a meaningful threat model on its own.
There is also a deeper issue. Threat modeling is, by definition, a group activity. It is about brainstorming, context sharing, and perspective. Tools can support that process. They can offer ideas when the group hits a wall. But they cannot replace the group. That is not just my opinion. It is one of the core ideas behind the Threat Modeling Manifesto.

A specific control

One of my favorite threat modeling anti-patterns is when teams focus on a single control and assume the job is done. Even worse, they say they completed threat modeling because that one control solves everything. That is not how it works. A mature threat modeling process pushes teams to keep asking the same question: “Is there anything else that could go wrong?”. Ironically, the more mature your process becomes, the more threats you will discover. In security, the more you know, the more you realize how much you do not know. You might have identified all the threats. But it is unlikely you have mitigated every single one. Some threats are so unlikely or expensive to fix that you inevitably end up accepting the risk. That does not mean those threats vanish. They still exist — hopefully in a backlog on your defect tracking board.

Why do threat modeling efforts fail?

The Threat Modeling Manifesto outlines several common anti-patterns. Based on my experience, these are the worst practices I have seen in the field.

The ivory tower threat modeling team

This is when one person or a small group does everything in isolation. They draw the diagrams, list the threats, and then present their findings to the rest of the team. That is not threat modeling. That is a whiteboard architecture review. To be fair, it is not useless. It is better than doing nothing. But it misses the entire point. Threat modeling only works when stakeholders are part of the process, not just the audience for the outcome.

The perfectionist

Some threat modeling sessions get carried away trying to create the perfect diagram. That is a trap that ends up consuming most of the time you have allotted for threat modelling. Even worse, it leads to long debates about how the system works instead of focusing on what could go wrong.
Your threat model does not need to mirror the system exactly. In fact, having a few rough diagrams with different viewpoints is often more helpful than one polished version. What matters most is giving your team enough context to start thinking. Then let them explore freely.

The one and done activity

This is my personal favorite. A team tries threat modeling once, calls it a success, and never does it again.In reality, the session felt pointless. It delivered little value, but nobody dares to admit it. Compared to pen testing or security scanning tools, it seemed like a waste of time.
Here is the problem. If you are doing it alone, your first threat modeling session is just a warm-up. And going home after a warm-up is pointless. You might as well not go to the gym at all. Now, if Toreon is helping you, your first session will actually feel like a great workout. You will leave with results and a bit of soreness. But no matter who guides you, consistency is what makes threat modeling effective. Not a one-off event.

How Toreon helps you get it right

Avoiding these pitfalls is not easy. Many teams start with the right intentions but quickly lose direction. That is where Toreon makes a big difference.

Toreon provides practical, no-nonsense training. You will not get lost in theory. Instead, you will learn the core principles of threat modeling through real-world examples, group exercises, and yes, even homework. The training is hands-on, effective, and delivered by experts who have guided hundreds of teams across various industries.
Most importantly, Toreon helps you create a repeatable, pragmatic process that makes threat modeling stick. Their Threat Modeling Playbook is built on years of field experience. It shows you how to set clear expectations, involve the right people, and avoid wasting time on diagrams or circular debates.
That is what sets Toreon apart. They do not just run a session. They help you build a habit that lasts.

What is threat modeling?

So what is threat modeling then and how to do it right? Most of us in the AppSec community refer to Adam Shostack’s four key questions as the foundation. I like to simplify them a bit. To run a solid threat modeling session, you need to:

• Create a shared understanding of the system and its scope
• Identify what could go wrong
• Decide what to do about it
• Make sure it was done properly

At its core, threat modeling is a team exercise. It is not about perfect diagrams or strict methods. It is about helping people think critically, spot risks, and take action.
OWASP SAMM fully supports this mindset. It guides organizations from informal, ad hoc efforts to structured and mature practices. In fact, SAMM includes threat modeling across three distinct streams, showing just how central it is to a strong application security program.

Application risk: Understand what matters to your business

Before you model threats, you need to understand what matters to your business. This is exactly what the Application Risk Profile stream in OWASP SAMM helps you do. It gives you the big picture. What are your executives worried about? What are they willing to accept?
This is where threat modeling should begin. It starts with a high-level, business-driven view of your organization’s risk context. That context is the foundation of any meaningful threat modeling effort.

A simple risk profile could be a list of your key applications with a few basic attributes. Toreon has written an excellent blog on this topic [todo: link to their blog]. Here is a slightly adapted and simplified version of the example they share:

Even though this profile is simple, it is more than what I see in most organizations. And it is incredibly useful. Why? Because it helps you prioritize. You instantly know which applications require a deeper threat modeling effort. But even more importantly, this profile gives your threat modeling session the right context.
For example, if your Electronic Health Record software handles personal health data, the team should definitely explore insider threats in addition to anything else. One likely scenario is a curious nurse accessing a famous patient’s records. That is not something a scanner will flag, but your team can.

Threat modeling: identify what could go wrong

In the Threat Modeling stream of OWASP SAMM the core activities of threat modeling happen. Books are written on this topic, but SAMM highlights three key aspects of a successful threat modeling program.
First of all, threat modeling is not a solo exercise. It is a collaborative effort that brings together developers, architects, product owners, and security professionals. Everyone sees risk from a different angle. That diversity is what makes the session valuable.
Secondly, SAMM defines a clear maturity path for threat modeling. At the lowest level, threat modeling happens occasionally, with no clear structure. As maturity grows, the process becomes more systematic, consistent, and above all, naturally integrated into your development lifecycle.
Finally, threat modeling does not live in a silo. It connects to other activities like security requirements, architectural assessments, testing, and penetration testing. It even feeds into more technical tasks like tuning SAST or DAST tools based on known threats. This creates a feedback loop that strengthens your entire security program.

Architecture Mitigation: verify the correct implementation

In the Architecture Mitigation stream of OWASP SAMM, you make sure the identified threats have actually been addressed. Ideally, this step helps drive your broader security strategy across the rest of the SDLC. That said, I remain somewhat puzzled by SAMM’s philosophy here. In my experience, validation usually happens during implementation itself or during the next round of threat modeling. It is rarely a separate or explicit step. The feedback loop tends to be continuous, not staged.

So, when is the best time to threat model? Experts will tell you to threat model before you write a single line of code. And they are right — in theory. But that is not how things usually work. I helped build the LINDDUN methodology. Even so, in my own organization, we always run threat modeling after several sprints. That is not a failure. That is how real-world software development works. And this is exactly why I appreciate Toreon’s Threat Modeling Playbook. It is designed for how teams work, not just how things should work. Why would you invest in threat modeling if you are not even sure your product will survive the next quarter? Early modeling is great and might even be required for, for example, nuclear plants and medical devices [ref to US medical devices legislation]. But that is a tiny fraction of the software being built today. When your system is live, you have more context, more visibility, and better access to stakeholders.

Key success factors for threat modeling

Toreon’s world class training

Threat modeling is not something you can master by reading a blog or a book. It requires experience and coaching. Toreon has trained over a thousand professionals and regularly runs sessions at major conferences like OWASP AppSec and Black Hat. If you are serious about starting strong, attend one of their training sessions. You can also request in-house training tailored to your specific application types.

Host effective brainstorming sessions

Threat modeling works when the right people are in the room. That includes:

• Business stakeholders
• Architects
• Developers
• Security or DevOps engineers
• Project managers
• Quality assurance and testers
• A threat modeling specialist to facilitate

Most of these people have packed schedules. That is why you should timebox the sessions and, ideally, start with external facilitation. The threat modeling specialist helps keep the session focused and productive.

Standardize the process

Create a threat modeling process that is fun and does not feel like a bureaucratic burden to check the boxes. Once you have a model, save it for future reference. There are two key deliverables that matter:

• A system representation (e.g., a high-level DFD or architecture diagram)
• The list of identified threats

And most importantly, follow up. Log threats in your defect tracking system. Just make sure the issues do not vanish. Threat modeling should never happen in isolation. Use pen test reports, architecture reviews, and business cases to feed into your session. They often reveal valuable context and hidden risks.

From zero to hero

Let us wrap up with a simple scenario. Imagine your organization is not doing any threat modeling. But you have executive buy-in to start. Here is how success can look.

1. Start with training
   Begin by joining Toreon’s world-class training. They run sessions at major conferences and also offer private sessions for teams. The training is hands-on, practical, and tailored to cloud systems, mobile apps, and delivered software.
2. Prepare for your first threat modeling session
   Pick one system. Do your homework. Do not send out a vague invite like “We are threat modeling today.”. Instead, prepare a basic application risk profile, a short business impact analysis, and a high-level system overview. Keep it simple. The goal is to set the right context.
3. Host the session
   Start by presenting your system overview. Do not worry about perfection. Use the diagram to guide the conversation. Focus on collaboration and critical thinking. Facilitate the session with one clear goal: find threats that matter.
4. Consistency is key
   Repeat the process. Improve with each session. Over time, threat modeling will become part of how your team thinks and builds. And your security posture will start to speak for itself.

Conclusion

Threat modeling is often misunderstood. Some teams treat it like a checklist. Others over complicate it. Many give up after trying it once. But when done right, it brings alignment, visibility, and real improvement. It helps teams think clearly about risk, work better together, and build more secure systems.
OWASP SAMM gives you the structure. Toreon gives you the experience and practical know-how to get started the right way.

Ready to get started?

Take the first step toward building a mature, effective threat modeling practice.

• Explore Toreon’s training programs and learn from the best in the industry.
• Use SAMMY to track your progress and align your threat modeling efforts with OWASP SAMM.

Start threat modeling and do it right.