STRIDE

framework · cybersecurity · organizing-schema

Microsoft threat modeling categorization: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

STRIDE is the threat-modeling categorization framework developed at Microsoft in the late 1990s, principally by Praerit Garg and Loren Kohnfelder, and substantially popularized through Microsoft's Security Development Lifecycle (SDL) and Adam Shostack's Threat Modeling: Designing for Security (2014). The acronym maps to six threat categories: Spoofing (impersonating someone or something — counter with authentication); Tampering (modifying data or code without authorization — counter with integrity controls); Repudiation (denying having performed an action — counter with non-repudiation, audit logs); Information disclosure (exposing information to unauthorized parties — counter with confidentiality controls, encryption); Denial of service (degrading or preventing legitimate use — counter with availability controls); Elevation of privilege (gaining capabilities not authorized — counter with authorization). The framework provides a memorable taxonomy for systematically considering threats during software design, typically applied to data flow diagrams (DFDs) where each element (process, data store, data flow, external entity, trust boundary) is examined for each STRIDE threat category. Microsoft's Threat Modeling Tool (free, currently SDL Threat Modeling Tool 2016) automates much of the STRIDE-based analysis. STRIDE is commonly used alongside DREAD (a now-deprecated risk-rating method also from Microsoft) or with other risk-rating approaches. Adam Shostack's substantial advocacy through his 2014 book and ongoing work has shaped contemporary threat-modeling practice substantially. The framework remains the most widely-taught threat-modeling categorization, though competing approaches (PASTA, attack trees, LINDDUN for privacy) address different threat-modeling purposes.

Originators

Praerit Garg and Loren Kohnfelder (Microsoft, late 1990s); Microsoft Security Development Lifecycle (SDL); Adam Shostack (substantial popularization) high

Year / Decade

Late 1990s (Microsoft origin); 2014 (Shostack's Threat Modeling); 2016 (current SDL Threat Modeling Tool) high

Primary sources

Howard, M. & LeBlanc, D. (2002). Writing Secure Code, Shostack, A. (2014). Threat Modeling: Designing for Security, Microsoft Security Development Lifecycle documentation (ongoing) high

Core components

Six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
Mapping to security properties: Authentication, Integrity, Non-repudiation, Confidentiality, Availability, Authorization
Application to data flow diagrams (DFDs)
Per-element analysis (process, data store, data flow, external entity, trust boundary)
Microsoft Threat Modeling Tool
Often used with DREAD (deprecated) or other risk-rating
Distinction from PASTA (process methodology) and attack-tree approaches
Foundation of Microsoft Security Development Lifecycle threat modeling

Primary use case

Threat modeling during software design; foundation of Microsoft's Security Development Lifecycle; reference framework in secure development education; basis for many enterprise threat-modeling programs; integration with software development lifecycle and DevSecOps practices; pedagogical reference in software security courses; foundation for several commercial threat-modeling tools (Microsoft Threat Modeling Tool, IriusRisk, ThreatModeler).

Common criticisms

STRIDE is a categorization, not a methodology — applying STRIDE requires substantial complementary process for actually identifying threats, prioritizing them, and addressing them
tends to produce extensive threat catalogs without clear prioritization (DREAD was the original prioritization companion but was deprecated by Microsoft due to inconsistent application)
the data flow diagram approach can become bureaucratic with little security improvement when not paired with substantive design discussion
cloud-native, microservices, and modern architecture patterns create challenges for traditional STRIDE application that haven't been fully resolved in practice
tendency for STRIDE to produce 'check the box' threat models that don't reflect actual adversary thinking
integration with agile and continuous-delivery practices is incomplete — threat modeling at design time misses threats arising from operational and configuration changes
commercial threat-modeling tools vary substantially in usability and analytical fidelity
STRIDE focus on technical threats can underweight social-engineering, supply-chain, and governance-level threats
competing approaches (PASTA for risk-centric, LINDDUN for privacy, attack trees for adversary-perspective) address different needs that STRIDE alone doesn't cover.

Lineage

Siblings: PASTA