Every system you build has assumptions baked in. The database won’t be accessed by unauthorized people. The API will only receive well-formed requests. The admin panel won’t be exposed to the internet. Threat modeling is the process of systematically identifying where those assumptions are wrong — before the usual suspects do it for you. It’s cheaper to find a flaw on a whiteboard than in a breach notification letter.

The TLDR

Threat modeling is a structured approach to identifying, categorizing, and prioritizing threats to a system. You decompose the system into components, map data flows, identify trust boundaries, and then systematically ask “what could go wrong?” The major methodologies — STRIDE (Microsoft), PASTA (risk-centric), and DREAD (scoring) — each approach this differently. STRIDE categorizes threats by type. PASTA walks through seven stages from business objectives to risk analysis. DREAD scores threats for prioritization. The best time to threat model is during design. The second best time is now. The OWASP Threat Modeling resources and MITRE ATT&CK framework provide the building blocks.

The Reality

Most systems are built and deployed without a threat model. The developers think about functionality, the product team thinks about deadlines, and security — if it’s involved at all — gets called in after the architecture is set in stone. By then, the fundamental design decisions that create the biggest vulnerabilities have already been made. Bolting security onto a bad architecture is like adding a deadbolt to a screen door.

The systems that do get threat modeled tend to be the ones that have been burned before. Microsoft formalized STRIDE after years of Windows vulnerabilities that could have been caught in design. The OWASP Top 10 is essentially a list of threats that weren’t modeled — injection, broken authentication, security misconfiguration — showing up in production applications year after year because nobody sat down and asked “what if someone sends something we didn’t expect?”

Threat modeling isn’t just for software. Network architectures, cloud deployments, physical facilities, business processes — anything with assets worth protecting and adversaries worth worrying about benefits from structured threat analysis. The NIST Cybersecurity Framework Identify function explicitly calls for threat identification as a foundational activity.

How It Works

The Fundamentals

Before you pick a methodology, you need three things:

1. A system decomposition. Break the system into components: web servers, databases, APIs, message queues, third-party services, client applications. You can’t analyze what you haven’t identified.

2. Data Flow Diagrams (DFDs). Map how data moves through the system. Where does it enter? Where is it stored? Where is it processed? Where does it leave? DFDs use four elements: external entities (things outside your control), processes (things that transform data), data stores (where data rests), and data flows (arrows showing movement).

3. Trust boundaries. Lines on the DFD where the level of trust changes. The boundary between the internet and your web server. The boundary between the web server and the database. The boundary between your application and a third-party API. Trust boundaries are where threats concentrate because they’re where assumptions about authorization, authentication, and data integrity get tested.

STRIDE

Microsoft developed STRIDE as a mnemonic for categorizing threats. For each component and data flow in your system, you ask whether it’s vulnerable to:

STRIDE is approachable because the categories are intuitive. For every element on your DFD, you walk through the six categories and document what applies. The output is a structured list of threats, each tied to a specific component.

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA is a seven-stage methodology that starts with business context and ends with risk analysis. It’s more heavyweight than STRIDE but produces risk-aligned results:

  1. Define objectives — What are the business objectives? What’s the risk appetite? This grounds the threat model in business reality instead of pure technical analysis.
  2. Define the technical scope — Inventory the technology stack, infrastructure, and dependencies. What are you actually modeling?
  3. Application decomposition — Break down the application architecture. DFDs, trust boundaries, entry points, assets.
  4. Threat analysis — Identify threat actors and their motivations. Nation-states? Financially motivated criminals? Insiders? Each has different capabilities and goals.
  5. Vulnerability analysis — Map known vulnerabilities to the architecture. CVE databases, OWASP Top 10, vendor advisories, penetration test results.
  6. Attack modeling — Build attack trees showing how threats and vulnerabilities combine into realistic attack scenarios. This is where MITRE ATT&CK becomes invaluable — you can map specific techniques to your architecture.
  7. Risk and impact analysis — Score the residual risk. What’s the business impact of each attack scenario? Prioritize mitigations based on risk, not just technical severity.

PASTA’s strength is that it ties directly to business risk. The output isn’t just “here are the threats” but “here are the threats that matter most to the business, ranked by impact.”

DREAD Scoring

DREAD provides a scoring model for prioritizing threats. Originally used at Microsoft alongside STRIDE, it’s fallen somewhat out of favor due to subjectivity, but the categories are still useful:

Each category gets scored 1-10, and the average gives a priority rating. The subjectivity is the weakness — different analysts will score differently. But as a rough prioritization tool for a large list of threats, it works well enough to separate the critical from the noise.

Attack Trees

Attack trees are visual models that decompose a high-level attack goal into sub-goals and leaf nodes representing specific techniques. The root node is the attacker’s objective (“steal customer data”). Branches represent different paths to achieve it. Leaf nodes are the specific actions (“exploit SQL injection in search form,” “compromise admin credentials via phishing”).

Attack trees make complex attack scenarios comprehensible. They also reveal that threats don’t exist in isolation — an attacker chains multiple techniques together, and your defenses need to account for the full chain, not just individual links.

How It Gets Exploited

Design flaws persist. When organizations skip threat modeling, architectural vulnerabilities ship to production. These aren’t bugs that a patch fixes — they’re fundamental design decisions. The Log4Shell vulnerability (CVE-2021-44228) was a design flaw in how Log4j handled JNDI lookups. A threat model asking “what happens if an attacker controls the format string?” would have caught it before it became the most exploited vulnerability of the decade.

Trust boundary violations. Most successful attacks cross a trust boundary that wasn’t properly identified. The usual suspects find the point where the system assumes “this data is trusted” and send data that isn’t. OWASP calls this the root cause of injection attacks — which have topped the vulnerability charts for over 20 years.

Threat models that don’t update. A threat model is a living document. The system changes. New features add new data flows. New integrations create new trust boundaries. New attack techniques emerge. A threat model from 18 months ago is a historical document, not a security tool.

What You Can Do

For Development Teams

Start simple. Grab a whiteboard, draw your system, mark the trust boundaries, and walk through STRIDE for each boundary. Your first threat model will miss things. That’s fine — a partial threat model is infinitely more valuable than no threat model.

Tools help: Microsoft Threat Modeling Tool generates STRIDE-based threats from DFDs automatically. OWASP Threat Dragon is open-source and web-based. Both lower the barrier to entry.

Build threat modeling into your development lifecycle. The ideal time is during design, before code is written. But retroactive threat modeling of existing systems is valuable too — especially for systems handling sensitive data or exposed to the internet.

For Organizations

Make threat modeling a requirement for new projects and significant changes. Not a 200-page document — a focused analysis of the components, data flows, and trust boundaries that matter. Review threat models when the architecture changes.

Map your threat models to MITRE ATT&CK. When you identify a threat, look up the corresponding ATT&CK technique. This connects your theoretical threat model to real-world attacker behavior and gives your defensive teams specific detection opportunities.

For Individuals

You threat model every day without calling it that. When you decide not to click a link because the email looks suspicious, you’ve identified a threat (phishing), assessed the risk (credential theft), and applied a mitigation (don’t click). Formalizing that thinking — asking “what could go wrong?” before making security decisions — makes you harder to compromise.

Sources & Further Reading