Threat Modeling Explained: STRIDE and Methodology

Threat modeling is a structured exercise for finding security flaws in a system's design, ideally before any code is written. You draw how data moves, mark where trust changes hands, and systematically ask what could go wrong at each point. A design flaw caught on a whiteboard costs minutes; the same flaw caught in production after a breach can cost everything.

This guide explains STRIDE, the most widely used framework, and the methodology around it: data flow diagrams, trust boundaries, and when to model. It also compares STRIDE to DREAD, attack trees, and PASTA so you know which tool fits which job, and points you at the software that makes the practice repeatable.

What is threat modeling?

Threat modeling is the practice of analyzing a system's design to identify, categorize, and prioritize potential threats so you can address them before they become real vulnerabilities. It answers four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job.

It's a design-phase activity, which is what makes it valuable. Where secure code review and dynamic testing find bugs in code that already exists, threat modeling catches architectural mistakes such as a missing trust boundary, an over-trusted service, or an authentication gap, when fixing them is just an edit to a diagram. It complements rather than replaces hands-on testing like a web application pentest.

What is STRIDE and how does it work?

STRIDE is a threat-classification framework developed at Microsoft that breaks threats into six categories, each the inverse of a security property you want to hold. You walk through each element of your system and ask, for each letter, whether that threat applies.

• S - Spoofing violates authentication: pretending to be another user or system.
• T - Tampering violates integrity: modifying data in transit or at rest.
• R - Repudiation violates non-repudiation: performing an action that can't be proven or traced.
• I - Information disclosure violates confidentiality: exposing data to someone unauthorized.
• D - Denial of service violates availability: making a system unusable.
• E - Elevation of privilege violates authorization: gaining capabilities you shouldn't have.

The power of STRIDE is that it's a checklist against forgetting. Pointing it at each process, data store, data flow, and external entity in your diagram turns "what could go wrong" from an open-ended worry into a finite, repeatable pass.

How do you build a data flow diagram with trust boundaries?

A threat model starts with a data flow diagram (DFD) that shows how data moves through your system, overlaid with trust boundaries where the level of trust changes. The diagram is the map you run STRIDE against, so getting it right is most of the work.

A DFD uses a small vocabulary: external entities (users, third-party APIs), processes (your services and functions), data stores (databases, queues, caches), and data flows (the arrows connecting them). A trust boundary is a line you draw wherever data crosses from a less-trusted zone to a more-trusted one: the internet hitting your load balancer, a browser calling your API, your app reaching into the database, one microservice calling another. Trust boundaries are where threats concentrate, because they're where assumptions about who's calling and what they're allowed to do get made or broken. The same boundary thinking drives API penetration testing, where each service-to-service call is a place trust can be abused.

When should you do threat modeling?

Model during the design phase, before and while you build, and revisit whenever the architecture changes meaningfully. The whole point is to catch flaws when the fix is cheap, so a threat model produced after launch has missed most of its value.

Concrete triggers: a new feature that introduces a trust boundary, a new data store holding sensitive data, a change to authentication or authorization, a new third-party integration, or a shift in who can reach a service. You don't re-model the entire system each sprint; you model the part that changed. Many teams attach a lightweight threat-model review to design docs for anything security-relevant, which keeps the practice continuous rather than a once-a-year event, the same philosophy behind continuous, agentic pentesting on the testing side. This pairs naturally with framework knowledge from the OWASP Web Security Testing Guide.

How does STRIDE compare to DREAD, PASTA, and attack trees?

STRIDE identifies and categorizes threats; the others mostly help you rate, decompose, or align them to business risk. They're complementary, not competing, and most mature programs mix them.

DREAD is a scoring model (Damage, Reproducibility, Exploitability, Affected users, Discoverability) once used to prioritize STRIDE findings. It's fallen out of favor because the scores are subjective and inconsistent between raters, so many teams now prioritize with CVSS or a simple risk matrix instead. Attack trees decompose a single attacker goal into the steps and alternatives needed to achieve it, which is great for reasoning deeply about one high-value target. PASTA (Process for Attack Simulation and Threat Analysis) is a heavier, seven-stage, risk-centric methodology that ties technical threats to business impact, suited to formal programs that need that traceability. A common pattern: use STRIDE to enumerate, attack trees to explore the scary ones, and a risk matrix to prioritize.

Which threat modeling tools should you use?

Tools turn the diagram-and-list exercise into a repeatable, reviewable artifact and suggest threats so you don't rely purely on memory. Pick based on how much process and automation you want.

• OWASP Threat Dragon is free and open source, runs in the browser or desktop, lets you draw DFDs and attach STRIDE threats per element, and stores the model as code in your repo. A good default for most teams.
• Microsoft Threat Modeling Tool is free, Windows-based, and auto-generates STRIDE threats from your diagram using a built-in template. Strong if your stack is Microsoft-heavy.
• IriusRisk is a commercial platform that scales threat modeling across an organization with rule-based automation, control libraries, and integrations into Jira and CI. Built for teams that need governance and consistency at scale.

Whatever you pick, the output should be a living document tied to your design process, not a PDF that's stale the day after the meeting.

Frequently asked questions

Sources and references

• Microsoft STRIDE Threat Model
• OWASP Threat Modeling
• OWASP Threat Dragon
• OWASP Threat Modeling Process