CISSP Made Easy

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 — Microsoft’s threat categorisation model — provides a structured, accessible framework for conducting threat modelling at the application and system design level, and for communicating findings to non-security stakeholders in terms they understand.

What Is STRIDE?

STRIDE is an acronym representing six categories of security threats, developed by Microsoft researchers Loren Kohnfelder and Praerit Garg in 1999 and widely adopted as a foundational threat modelling methodology. Each category maps to a specific security property being violated:

Threat Category	Security 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 having performed 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 Threat Modelling Process

STRIDE is applied through a four-step process that can be conducted at design time (most effective) or retrospectively against existing systems:

Step 1: Define the Scope and Create a System Model

Produce a Data Flow Diagram (DFD) that captures all components of the system: processes, data stores, external entities, and the data flows between them. The DFD is the primary artefact against which threats are enumerated. Each element type has a default set of applicable STRIDE threats: processes are susceptible to all six; data stores are primarily susceptible to tampering, information disclosure, and denial of service; external entities are primarily susceptible to spoofing.

Step 2: Enumerate Threats

Systematically apply each STRIDE category to each element in the DFD. The question for each combination is: “How could an attacker exercise this threat category against this component?” Tools such as Microsoft Threat Modeling Tool and OWASP Threat Dragon automate parts of this enumeration and maintain DFD-to-threat mappings.

Step 3: Assess and Prioritise Threats

Use DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS-based scoring to prioritise identified threats by risk. This produces an actionable ranked threat list that can inform architectural decisions, security requirements, and remediation planning.

Step 4: Mitigate and Validate

For each prioritised threat, identify mitigating controls — whether preventive (authentication strengthening, encryption), detective (logging, monitoring), or architectural (trust boundary redesign, attack surface reduction). The threat model is then maintained as a living document and revisited when the system changes materially.

STRIDE in the Context of CISSP and Secure Architecture

STRIDE maps directly to CISSP CBK Domain 3 (Security Architecture and Engineering) and Domain 8 (Software Development Security). Understanding threat categories at a design level is a prerequisite for producing security architectures that address actual risk — as opposed to architecture that simply implements a control checklist.

In my work at Cboe, threat modelling forms part of the security review process for new application deployments. The DFD approach is particularly valuable because it creates a shared vocabulary between security architects and application development teams — reducing the friction that often arises when security reviews are perceived as compliance gates rather than design contributions.

STRIDE for Cloud and API-Heavy Architectures

STRIDE remains relevant in cloud-native environments, but its application requires adaptation. Key considerations for modern architectures include:

• 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 that modify 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 are information disclosure threats native to serverless architectures.
• Elevation of Privilege in Kubernetes: Container escape, pod security misconfigurations, and RBAC weaknesses are privilege escalation threats that STRIDE helps enumerate systematically.

References and Further Reading

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