Threat Modeling (STRIDE)

Definition: A systematic process for identifying, categorizing, and mitigating potential security threats during system design, most commonly structured around Microsoft’s STRIDE framework.

How It Works

STRIDE breaks threats into six categories, each mapped to the security property it violates and the class of defense that addresses it:

Threat	Violates	Typical Mitigation
Spoofing Identity	Authenticity	Strong authentication, MFA, digital signatures
Tampering with Data	Integrity	Hashing, digital signatures, access controls
Repudiation	Non-repudiation	Immutable audit logs, signed transactions
Information Disclosure	Confidentiality	Encryption at rest and in transit, access controls
Denial of Service	Availability	Rate limiting, redundancy, autoscaling, WAFs
Elevation of Privilege	Authorization	Least privilege, input validation, sandboxing

Practically, threat modeling starts with a data flow diagram (DFD) of the system: processes, data stores, external entities, and trust boundaries between them. Each element and each boundary crossing is then examined against all six STRIDE categories, asking “could this happen here, and if so, what stops it.” The output is a prioritized list of threats with assigned mitigations, ideally produced during design, before code is written, when changes are cheapest.

Under the Hood

Trust boundaries are where STRIDE analysis concentrates, because that’s where an attacker’s assumptions can differ from a defender’s, for example, the line between a public API endpoint and an internal service that trusts anything coming from inside the network. Every place data crosses one is a candidate for spoofing or tampering.
Threat modeling isn’t the same as a vulnerability scan. A scanner looks for known-bad patterns in existing code; STRIDE analysis reasons about a design before implementation exists, catching architectural flaws (like a missing authentication boundary) that no scanner can find because there’s no code yet to scan.
DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is often paired with STRIDE to score and prioritize the threats STRIDE identifies, since not every identified threat warrants equal engineering effort.
Attack trees are a complementary technique: starting from an attacker’s goal and working backward through the specific steps that would achieve it, useful when a single STRIDE category (like elevation of privilege) needs deeper decomposition into a concrete attack path.

Worked Walkthrough

Consider a minimal DFD for a login feature: an external entity (the user’s browser) sends credentials across a trust boundary to a process (the auth service), which reads from and writes to a data store (the user database), and returns a session token back across the boundary. Walking each element against STRIDE:

At the browser-to-auth-service boundary: Spoofing (is this really the claimed user, not a replayed credential?), mitigated by requiring a fresh authentication factor, not just a stored cookie.
At the auth-service-to-database boundary: Tampering (could a compromised auth service or a SQL injection modify user records it shouldn’t?), mitigated by parameterized queries and a database account scoped to only the operations the auth service actually needs.
Within the auth service itself: Repudiation (could a user later deny having logged in from a given location?), mitigated by writing an immutable, timestamped login event to an audit log the auth service can’t itself later modify.
On the return path: Information Disclosure (could the session token or any user data leak in transit or in logs?), mitigated by TLS and by ensuring tokens are never logged in plaintext.
At the auth service’s public endpoint: Denial of Service (could repeated login attempts exhaust the service?), mitigated by rate limiting per source IP and per account.
Within the session logic: Elevation of Privilege (could a regular user’s token be manipulated to gain admin claims?), mitigated by signing tokens server-side so client-supplied claims can never be trusted directly.

This is the mechanical process STRIDE analysis actually looks like in practice: walk every element and every boundary crossing, ask all six questions, and record what specifically stops each one.

Data Flow Diagram with STRIDE Annotations

The same login walkthrough as a DFD, with each STRIDE category placed at the specific boundary crossing it applies to:

Every arrow crossing the trust boundary line, browser into the internal network, and the internal-only arrows within it, is a candidate for a different STRIDE category depending on what that specific flow carries and who could tamper with it.

Why It Matters

Fixing a design flaw during architecture review costs a fraction of what patching it costs after deployment, and a fraction of what a breach costs after exploitation.
Forces a structured walk through the six threat categories instead of relying on whichever risks happen to occur to the reviewer, catching blind spots that ad hoc review misses.
Produces documentation (the DFD and threat list) that remains useful for onboarding, audits, and future design changes, not just a one-time exercise.

Common Pitfalls

Treating threat modeling as a one-time compliance checkbox performed once before launch, rather than an ongoing practice repeated as the system’s design changes
Modeling the system at too high a level to be useful, missing the specific trust boundaries where real threats live
Skipping DREAD or another prioritization step, leaving a long threat list with no signal on what to fix first
Doing threat modeling only for new features and never revisiting the mitigations already in place as the surrounding system evolves
Confusing STRIDE categories, for example treating a Denial of Service threat as an Information Disclosure issue, which leads to the wrong class of mitigation being applied
Drawing the DFD after the system is already built and treating it as documentation rather than analysis, which misses the whole point of catching design flaws before implementation cost is sunk
Stopping at the first mitigation that comes to mind for a threat instead of checking whether it actually closes the gap for every element crossing that boundary, not just the one that prompted the review

Comparison

	STRIDE	PASTA	Attack Trees
Approach	Categorize threats by security property violated	Risk-centric, seven-stage process aligned to business impact	Goal-driven decomposition of attacker paths
Best for	Design-time review, developer-friendly	Enterprise risk management, tying threats to business impact	Deep-diving one specific attack scenario
Output	List of threats by category with mitigations	Risk-prioritized threat list with business context	Hierarchical breakdown of attack steps
Learning curve	Low, widely taught	Higher, more process-heavy	Low, but scope is narrower per tree
Originates from	Microsoft (1999)	OWASP-affiliated methodology	Bruce Schneier’s writing (1999), older security engineering tradition
Typical artifact produced	DFD plus categorized threat list	Risk report tied to business assets	Tree diagram of attack steps to a goal

Example

Threat-modeling an online payment pipeline: a Spoofing threat exists at the login boundary (mitigated with MFA), a Tampering threat exists where the cart total is passed from client to server (mitigated by recalculating server-side rather than trusting a client-supplied price), an Information Disclosure threat exists in transit (mitigated with TLS) and at rest (mitigated by encrypting stored card data or better, not storing it at all and using a tokenized payment processor), and a Denial of Service threat exists at the checkout endpoint (mitigated with rate limiting). Microsoft’s own Threat Modeling Tool, which originated STRIDE internally in the late 1990s, is still widely used to draw the DFD and walk through this analysis systematically.

Real-World Case Study

The 2013 Target breach began with stolen credentials from a third-party HVAC vendor’s access to Target’s vendor portal, then relied on insufficient network segmentation between that vendor-facing portal and the payment card systems running Target’s point-of-sale terminals. Once inside, attackers moved laterally from a low-privilege vendor access point to systems that should have been isolated behind a much stronger trust boundary, eventually installing malware on POS terminals that harvested roughly 40 million card numbers. Viewed through STRIDE, the incident is a case where an Elevation of Privilege threat, an external vendor’s limited access being used to reach unrelated, more sensitive systems, went unmitigated because the trust boundary between vendor systems and payment systems wasn’t enforced strongly enough at the network level. It’s frequently cited in threat modeling training specifically because the individual pieces (a phished vendor, a flat internal network) were each unremarkable; the failure was in not treating the vendor-to-payment-network boundary as a boundary at all.

Data Flow Diagram Elements

STRIDE analysis is applied on top of a DFD, which uses a small, standard vocabulary of elements:

External entity: something outside the system’s control, a user, an external service, a third-party API.
Process: a unit of the system that transforms or handles data, an API endpoint, a background job, a microservice.
Data store: where data persists, a database, a cache, a file system, a message queue.
Data flow: the movement of data between the above elements, drawn as an arrow.
Trust boundary: a line drawn across data flows where the level of trust changes, the internet-to-server boundary, the app-to-database boundary, the process-to-process boundary between two teams’ services. Nearly every meaningful STRIDE threat is found at one of these boundaries.

History

1999: Loren Kohnfelder and Praerit Garg, while at Microsoft, developed STRIDE internally as a way to structure security review during design, before it became public methodology.
Early 2000s: Microsoft’s Security Development Lifecycle (SDL) formalized threat modeling as a mandatory design-phase gate for internal product teams, popularizing the practice industry-wide.
2000s onward: DREAD was introduced alongside STRIDE for prioritization, though it was later de-emphasized even within Microsoft due to inconsistent scoring between reviewers.
2010s: alternative frameworks (PASTA, VAST, Attack Trees) emerged to address STRIDE’s gaps, particularly for organizations wanting threat modeling tied more directly to business risk rather than technical categories.
Present: threat modeling has moved from a manual whiteboard exercise toward semi-automated tooling (Microsoft Threat Modeling Tool, IriusRisk, OWASP Threat Dragon) that generates DFDs and suggests STRIDE threats from architecture diagrams or infrastructure-as-code.

FAQ

Who should run a threat modeling session? Ideally a mix of the engineers building the system and someone with a security background, since developers know the real design details a security specialist might miss, and vice versa.

Does STRIDE replace penetration testing? No, they’re complementary. STRIDE happens at design time and reasons about the architecture; penetration testing happens against a running implementation and finds where the built system deviates from the intended design.

How often should a system be re-threat-modeled? Whenever its architecture changes meaningfully, a new trust boundary, a new external integration, a new data store, not on a fixed calendar schedule disconnected from actual design changes.

Is STRIDE only for web applications? No, it applies to any system with identifiable data flows and trust boundaries, including embedded systems, mobile apps, and internal microservice architectures.

What’s the fastest way to start if a team has never threat-modeled anything? Draw the DFD for one feature, not the whole system, walk it against the six STRIDE letters in a single meeting, and record only threats with no existing mitigation. A narrow, complete first pass teaches the method faster than an ambitious, incomplete one.

Referenced by

Dig deeper

Spot an error in this note?