STRIDE · Threat Modeling · Rolling Thunder Security

STRIDE was created at Microsoft in 1999 by Loren Kohnfelder and Praerit Garg. It is a threat taxonomy — a fixed list of six classes of attack that you systematically walk through against each element of a system. Two decades on, it is the most widely-used threat modeling vocabulary in technical practice.

The clean part of STRIDE: each of the six letters maps exactly to a property the system is supposed to provide. If you can violate the property, you've found a threat in that category.

The six letters

SSpoofing

Violates: Authentication

An attacker pretends to be someone (or something) they are not. Username and password phishing. Stolen API key. Faked email From: line. Forged JWT. SIM-swap into MFA.

Question to askHow do we know the principal making this request is who they claim to be?

TTampering

Violates: Integrity

Data is modified in transit or at rest by someone who shouldn't be able to. Man-in-the-middle altering an HTTP request. Modifying a database record. Editing a backup file. Forging a log entry to cover tracks.

Question to askHow do we detect (and prevent) someone changing this data?

RRepudiation

Violates: Non-repudiation

Someone performs an action and successfully denies having done it. Insider deletes a file and there's no log; admin disables CloudTrail before exfiltrating; a customer disputes a transaction with no audit trail to refute.

Question to askIf something bad happens, can we prove who did it?

IInformation Disclosure

Violates: Confidentiality

Data leaks to someone who isn't authorized to see it. Public S3 bucket. SQL error message that includes the database schema. Memory dump that contains credentials. IDOR exposing other users' records.

Question to askWhat data lives here, and who is supposed to be able to read it?

DDenial of Service

Violates: Availability

A legitimate user can't use the system. Network DDoS. Resource exhaustion in a backend service. A poison-pill input that crashes the parser. A rate-limit-free expensive query.

Question to askWhat stops one bad request from taking down service for everyone?

EElevation of Privilege

Violates: Authorization

A user gains permissions they should not have. Local user becomes root via kernel exploit. Regular user becomes admin via parameter tampering. SQL injection becomes RCE.

Question to askWhat's the worst thing this principal could become?

How STRIDE is used

STRIDE is applied to a data-flow diagram (DFD) of the system. Draw the system's external entities, processes, data stores, and data flows. For each element, walk the six STRIDE categories and ask: can this happen here? if so, what's the impact, and what's the mitigation?

User Browser ───HTTPS───> Web App ───SQL───> Database │ └───OAuth───> Identity Provider [STRIDE pass against "Web App" process:] S - Can an attacker pretend to be the Web App to the Database? (e.g., compromised credential) T - Can an attacker modify requests in flight between User and App? (TLS protects this) R - Does the App log enough to prove who took an action? (audit log exists) I - Can the App leak data to an unauthorized user? (auth check on every endpoint) D - Can one user make the App unavailable to others? (rate limiting? backpressure?) E - Can a normal user become an admin via the App? (role checks consistent?)

Which STRIDE letter applies to which element type?

Not every threat category applies to every element. STRIDE-per-element narrows the walk by mapping the letters to the DFD element types that can experience them:

Element	S	T	R	I	D	E
External Entity (user, system)	✓		✓
Process (web app, microservice)	✓	✓	✓	✓	✓	✓
Data Store (DB, file, S3)		✓	✓	✓	✓
Data Flow (HTTPS, SQL, message)		✓		✓	✓

A useful exercise: for each process in your DFD, write all six letters down a column and force yourself to write one sentence per category. The discipline catches the threats you'd otherwise dismiss as "nobody would do that."

Strengths and weaknesses

Strength: teachable in 30 minutes. The acronym is the entire model.
Strength: systematically catches categories of threat you'd otherwise miss — especially Repudiation (which non-security people rarely think about) and Elevation of Privilege (which non-security people often conflate with authentication).
Weakness: tells you what the threat is, not how serious. Combine with DREAD (or a simpler scoring system) for prioritization.
Weakness: assumes you can draw a useful DFD. Complex distributed systems make this expensive; you end up modeling subsystems separately.
Weakness: technical lens. Doesn't capture business risk, regulatory exposure, or "we shouldn't be storing this data at all" questions. Use PASTA or LINDDUN for those.

The point

STRIDE is the vocabulary of threat modeling. Six letters; one property per letter. If you can describe an attack as "spoofing the API gateway" or "tampering with the JWT payload," you're using STRIDE whether you call it that or not.

For most application architecture reviews, STRIDE-per-element on a DFD is the right starting move. It's cheap, it's repeatable, and it catches the threats that come up in 90% of real systems.

References

Formatted in APA 7. Alphabetized by first author's last name.

Hernan, S., Lambert, S., Ostwald, T., & Shostack, A. (2006). Uncover security design flaws using the STRIDE approach. MSDN Magazine. Microsoft.
Kohnfelder, L., & Garg, P. (1999). The threats to our products. Microsoft Interface.
Microsoft. (n.d.). Microsoft Threat Modeling Tool. Microsoft Security Development Lifecycle. https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
Shostack, A. (2014). Threat modeling: Designing for security. Wiley.