STRIDE
Also known as: STRIDE model
A memory aid that sorts threats into six kinds, so a team checks every part of a design for each kind in turn.
Draft - this entry has not been reviewed yet.
Formal
A scheme for naming threats, created at Microsoft, whose six letters stand for six kinds of threat - faking an identity (the S), tampering, repudiation, information disclosure, denial of service and elevation of privilege - each the breaking of a property a system should keep, such as authentication, integrity or availability.
In plain English
Like a pilot's pre-flight checklist - rather than trusting memory, you go down the same six questions every time so nothing obvious is skipped.
In practice
Reviewing the design of a new booking system for a regional hospital, a team asks all six questions about the login page and finds that nothing records failed logins, so a user could later deny what they did - a repudiation threat they fix by keeping a log.
Why it matters
Without a fixed list, teams tend to think only of the attacks they have heard about; six plain questions make threat work repeatable, even for people new to security.
Technical deep dive
STRIDE was introduced by Loren Kohnfelder and Praerit Garg in an internal Microsoft paper, "The threats to our products", in April 1999, and was later built into Microsoft's Security Development Lifecycle and its free Threat Modeling Tool. Each letter is the violation of a security property: Spoofing violates authentication, Tampering violates integrity, Repudiation violates non-repudiation, Information disclosure violates confidentiality, Denial of service violates availability, and Elevation of privilege violates authorization. That mapping is the practical value of the model, because each threat category points directly to a family of mitigations: strong authentication and certificate pinning for S, MACs, signatures and access control for T, tamper-evident audit logs for R, encryption and minimisation for I, quotas, rate limits and redundancy for D, and least privilege and input handling for E.
STRIDE is normally applied to a data flow diagram with five element types: external entities, processes, data stores, data flows and trust boundaries. In STRIDE-per-element, only the relevant letters are considered for each type. External entities are subject to S and R; processes to all six; data stores to T, I and D, plus R when the store is an audit log; and data flows to T, I and D. Trust boundaries carry no threats of their own but mark where flows need the most scrutiny. STRIDE-per-interaction instead analyses each flow as a tuple of source, destination and interaction, which produces fewer but more contextual findings, and is the approach the Threat Modeling Tool uses.
The model is a classification and elicitation aid, not a risk rating. Microsoft paired it for a time with DREAD for scoring, but DREAD was dropped because its ratings were too subjective, and teams now usually rate STRIDE findings with CVSS, a simple likelihood and impact matrix or their organisation's risk method. Common misuses are treating the six categories as a complete list, which misses business-logic and abuse cases, and applying STRIDE to a whole system as one box instead of decomposing it. Privacy threats such as linkability or identifiability fall outside STRIDE; LINDDUN was designed as its privacy counterpart, and attack trees or kill-chain models complement it for attacker-centric analysis. Adam Shostack's Elevation of Privilege card game turns the same categories into a structured team exercise.
What to learn first
Everything this builds on, foundations first.
Relationships
- Implements
- Threat modelling
Sources & further reading
Official documentation
Reference works
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…