Threat Modeling: STRIDE, Data Flows & Abuse Cases

Threat Modeling

Threat modeling is a structured way of asking, while a system is still being designed, what could go wrong and what we will do about it. It looks at what the system protects, where untrusted input and actors enter, which trust boundaries data crosses, and how an attacker — or a careless insider, or a compromised dependency — could abuse each of them. The result is a short list of concrete threats, decisions about each, and work items that make the design safer.

It is the cheapest security activity there is, because design changes cost far less than code changes and incomparably less than incidents. It also catches what scanners cannot: broken authorization logic, abusable business features, and missing controls are design flaws, not bugs a tool can spot in a single line of code.

TL;DR

Threat modeling answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job?
Start with a data flow diagram and mark the trust boundaries — most threats live where data crosses them.
Use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a prompt list, not a form to fill in.
Include abuse cases: legitimate features used in harmful ways, such as enumerating accounts through a password reset form.
Every threat ends with a decision — mitigate, eliminate, transfer, or accept — with an owner, and mitigations become backlog items and tests.
Keep it lightweight and continuous: an hour per significant feature beats a big model nobody updates.

Quick Example

A lightweight threat model kept next to the code for a profile-photo upload feature.

Each threat is specific to this feature, has a decision, and points to work that verifies it.

Core Concepts

The Four Key Questions

The Threat Modeling Manifesto reduces the practice to four questions that any method should answer:

What are we working on? — a model of the system: components, data flows, assets, and boundaries.
What can go wrong? — threats identified systematically, not just the ones someone remembers.
What are we going to do about it? — a decision and action for each threat.
Did we do a good job? — a check that the model was useful and the actions happened.

Data Flow Diagrams and Trust Boundaries

A data flow diagram shows external entities (users, third-party services), processes (your services), data stores, and the flows between them. A trust boundary is any line where the level of trust changes — from the internet into your API, from your service into a third-party API, from one tenant's data into another's, from user code into a sandbox.

Every flow that crosses a boundary deserves attention: who is authenticated, what is validated, and what happens if the other side lies.

STRIDE

STRIDE is a mnemonic for six threat categories, each the violation of a security property:

Walk each boundary-crossing flow and ask which STRIDE categories apply.

Abuse Cases

Many serious problems involve no exploit at all — just legitimate features used against the system or its users. Write abuse cases alongside use cases: "an attacker uses the password reset form to discover which emails have accounts", "a user invites thousands of fake accounts to inflate referral credits", "a scraper downloads every public profile through the search API".

Privacy Threats

STRIDE focuses on security. The LINDDUN framework adds privacy threats — linking, identifying, non-repudiation, detecting, data disclosure, unawareness, and non-compliance — which matter whenever the system processes personal data. See Privacy by Design.

Running a Threat Model

When

Model new systems and significant features during design, and revisit when architecture changes: a new external integration, a new data store with sensitive data, a change in authentication, or exposure to a new class of users. Small changes inside an existing, modeled component rarely need a new session.

Who and How Long

The people who know the design best — the engineers building it — plus someone with security experience as a facilitator. One focused hour on a whiteboard or shared diagram is usually enough for a feature. Larger systems are modeled component by component.

Rating and Treating Threats

Rate each threat by likelihood and impact (a simple high/medium/low scale is fine), then choose a treatment:

Mitigate — add controls that reduce likelihood or impact.
Eliminate — remove the feature or data that creates the threat.
Transfer — move the risk elsewhere, for example to a payment provider.
Accept — document the decision, the owner, and a review date.

From Model to Work

Mitigations become backlog items with acceptance criteria. Where possible, each mitigation also becomes a test — an authorization check that must fail, an upload that must be rejected — so the protection cannot silently regress. See Security Regression Test Suites.

Methods Compared

Methods are complementary. Most teams combine STRIDE for breadth with abuse cases for business logic.

Best Practices

Diagram First, Debate Second

A shared diagram exposes misunderstandings immediately — often the most valuable outcome of the session is discovering that two engineers had different pictures of the system.

Focus on Trust Boundaries

Time is limited. Spend it where data crosses boundaries and where sensitive assets live, rather than evenly across every component.

Store Models With the Code

Keep threat models as text or diagrams-as-code in the repository, reviewed in pull requests like designs. Tools such as OWASP Threat Dragon and pytm support this.

Track Decisions to Completion

A threat model is only as good as its follow-through. Link mitigations to tickets and accepted risks to owners and review dates, and revisit them in the next session.

Common Mistakes

Modeling Once, at the End

Boiling the Ocean

Only Imagining External Hackers

Threats Without Decisions

FAQ

What is threat modeling in simple terms?

Looking at a design and asking what could go wrong from a security and privacy point of view, then deciding what to do about each problem before building it. It is structured brainstorming, guided by a diagram of the system and a list of threat categories.

When should we threat model?

During the design of new systems and significant features, and whenever the architecture changes in a security-relevant way — new external integrations, new sensitive data, new authentication flows, or new user groups. Small changes within a modeled component usually do not need a new session.

Who should be involved?

The engineers who are designing and building the system, ideally with a product representative and someone experienced in security as facilitator. Security specialists help, but the builders know where the real complexity is.

What is STRIDE?

A mnemonic for six categories of threats — spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege — each corresponding to a security property. It is a prompt to make sure common threat types are considered for every component and data flow.

How long does threat modeling take?

For a typical feature, about an hour with the right people and a diagram. Large systems take several sessions, one per component. If it routinely takes days, the scope is too broad or the format too heavy.