Threat Modeling (STRIDE)
A structured security analysis methodology that identifies and categorizes threats to a system across six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
STRIDE is a threat modeling methodology developed at Microsoft in the late 1990s by Loren Kohnfelder and Praerit Garg, and widely popularized through Adam Shostack's work and the Microsoft Security Development Lifecycle (SDL). The acronym stands for six threat categories: Spoofing (impersonating another user or system), Tampering (maliciously modifying data or code), Repudiation (denying that an action was taken without the ability to prove otherwise), Information Disclosure (exposing data to unauthorized parties), Denial of Service (degrading or denying service to legitimate users), and Elevation of Privilege (gaining capabilities beyond those intended). By systematically examining each component and data flow in a system against these six categories, security architects can identify threats early in the design phase when they are cheapest to mitigate.
A STRIDE threat modeling exercise typically begins by creating a Data Flow Diagram (DFD) of the system under analysis, identifying the external entities (users, systems, services), processes (application components), data stores (databases, file systems, caches), and data flows (network connections, API calls, file reads/writes) that make up the system. Trust boundaries — lines across which data crosses privilege or security domains — are particularly important to identify, as they are where the most significant threats typically arise. Each element in the DFD is then analyzed against all relevant STRIDE categories to enumerate the threat scenarios that could apply.
For each identified threat, the team documents the threat scenario, the potential attack vectors, the existing mitigations in place, and whether residual risk is acceptable or requires additional controls. STRIDE is often combined with DREAD scoring (Damage, Reproducibility, Exploitability, Affected users, Discoverability) or CVSS to prioritize threats for remediation. The threat model output — typically a threat model document and a set of tracked mitigations — should be reviewed whenever the system design changes significantly, and at least annually for high-risk systems.
Incorporating threat modeling into the software development lifecycle (SDLC) requires both process and tooling investments. Microsoft Threat Modeling Tool and OWASP Threat Dragon provide DFD-based diagramming with automated STRIDE threat enumeration. Emerging AI-assisted threat modeling tools can automatically suggest threats based on system descriptions and architecture diagrams. Organizations pursuing NIST SP 800-160, ISO 27001, GDPR Article 25 (privacy by design), or SOC 2 Type II compliance increasingly require documented threat models as evidence of security engineering rigor. Training developers to participate in threat modeling sessions — not just security specialists — broadens security thinking across engineering teams and helps catch design flaws before they become expensive vulnerabilities.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.