Threat Modelling with STRIDE: A Practitioner’s Guide to Systematic Security Design

Threat modelling is one of the most underutilised techniques in enterprise security. Despite being a core competency in frameworks ranging from NIST SP 800-154 to ISO/IEC 27001:2022 Annex A (A.8.25 — Secure Development Lifecycle), the discipline is frequently displaced by reactive vulnerability management and compliance-driven control assessments. STRIDE provides a structured, accessible framework for conducting threat modelling at the application and system design level.

What Is STRIDE?

STRIDE is an acronym representing six categories of security threats, developed by Microsoft researchers in 1999. Each category maps to a specific security property being violated:

Threat Property Violated Example
Spoofing Authentication Impersonating a legitimate user or system component
Tampering Integrity Modifying data in transit or storage without authorisation
Repudiation Non-repudiation Denying an action due to insufficient logging
Information Disclosure Confidentiality Exposing sensitive data to unauthorised parties
Denial of Service Availability Exhausting resources to prevent legitimate use
Elevation of Privilege Authorisation Gaining capabilities beyond those intended

The STRIDE Process: Four Steps

Step 1: Define Scope and Create a Data Flow Diagram (DFD). Capture all system components: processes, data stores, external entities, and data flows between them. The DFD is the primary artefact against which threats are enumerated.

Step 2: Enumerate Threats. Systematically apply each STRIDE category to each element in the DFD. Tools such as Microsoft Threat Modeling Tool and OWASP Threat Dragon automate parts of this enumeration.

Step 3: Assess and Prioritise. Use DREAD scoring or CVSS-based assessment to prioritise identified threats by risk, producing an actionable ranked list for architectural decisions and remediation planning.

Step 4: Mitigate and Validate. For each prioritised threat, identify mitigating controls — preventive, detective, or architectural. Maintain the threat model as a living document revisited when the system changes materially.

STRIDE for Cloud and API-Heavy Architectures

  • Spoofing in OAuth/OIDC flows: Token theft, confused deputy attacks, and client impersonation are spoofing threats specific to modern authentication patterns.
  • Tampering in CI/CD pipelines: Supply chain attacks modifying build artefacts or container images are tampering threats at the infrastructure level.
  • Information Disclosure in serverless: Environment variable leakage, excessive IAM permissions, and shared execution environment risks.
  • Elevation of Privilege in Kubernetes: Container escape, pod security misconfigurations, and RBAC weaknesses.

References

  • Shostack, A. — Threat Modeling: Designing for Security (Wiley, 2014)
  • Microsoft — STRIDE Threat Model Documentation
  • OWASP Threat Dragon — owasp.org/www-project-threat-dragon/
  • NIST SP 800-154 — Guide to Data-Centric System Threat Modeling
  • ISO/IEC 27001:2022 — Annex A.8.25: Secure Development Life Cycle
  • (ISC)² CISSP CBK — Domain 3: Security Architecture and Engineering