# STRIDE Threat Model
STRIDE is a structured threat modeling methodology developed at Microsoft in the late 1990s that gives security teams a repeatable, categorical framework for identifying what can go wrong in a system before that system is built or modified. The method organizes threats into six named categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category corresponds to a specific security property it violates, creating a bidirectional map between attack class and defensive objective.
STRIDE exists because ad hoc threat brainstorming produces inconsistent results; different analysts identify different risks, and entire threat classes get overlooked. By providing a fixed taxonomy applied systematically to every component in a system diagram, STRIDE transforms threat modeling from an informal exercise into an auditable engineering discipline. The framework operates at the design level, not against running systems, making it a preventive control rather than a detective one.
---
STRIDE is a mnemonic-based threat classification framework applied during the design phase of software and system development. Each letter represents a distinct threat category paired with the security property it undermines:
The methodology operates through systematic application of these six categories to every element in a Data Flow Diagram (DFD). Elements include external entities (users, partner systems), processes (services, applications), data stores (databases, file systems), and data flows (communication channels). Trust boundaries separate zones of different privilege levels, and every boundary crossing becomes a candidate for threat analysis.
STRIDE is not a risk scoring system. It identifies and categorizes threats but does not assign probability or impact scores independently. Practitioners typically pair STRIDE with scoring methods such as DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS to produce prioritized risk outputs. STRIDE is also not a penetration testing methodology; it operates prospectively during architecture review, before adversaries have a target to exploit.
The framework differs from attack libraries such as MITRE ATT&CK in scope and purpose. ATT&CK documents observed adversary behaviors in production environments across the attack lifecycle. STRIDE identifies design-level threat categories before systems are deployed. The approaches are complementary: STRIDE reveals what categories of threat exist in an architecture; ATT&CK maps specific techniques adversaries might use to realize those threats once the system is operational.
---
STRIDE analysis follows a five-phase process applied to a formal system representation, typically a Data Flow Diagram. The phases are system decomposition, DFD construction, threat enumeration, risk assessment, and mitigation planning.
Phase 1: System Decomposition
The analyst breaks the system into constituent elements mapped to DFD components. External entities represent actors outside the system boundary: users, third-party services, partner organizations, or upstream/downstream systems. Processes represent components that transform, route, or make decisions about data: web applications, microservices, message queues, or decision engines. Data stores represent persistent storage: relational databases, document stores, file systems, or caching layers. Data flows represent communication channels between elements: API calls, database connections, file transfers, or message bus topics.
Trust boundaries separate zones of differing privilege or security posture. Common boundaries include the line between public internet and corporate network, between user space and administrative functions, between authenticated and unauthenticated contexts, and between different security zones within cloud environments. Each trust boundary crossing represents a potential attack vector.
Phase 2: DFD Construction
The DFD must reflect actual architecture, not intended or idealized design. This requires input from developers, system architects, and operations teams. Common construction failures include omitting background processes (scheduled jobs, maintenance scripts), ignoring administrative interfaces (database admin tools, configuration panels), understating external integrations (monitoring systems, logging platforms), and missing implicit data flows (error reporting, audit logging).
DFD accuracy directly impacts threat model completeness. An omitted process cannot be analyzed for threats. An unmapped trust boundary cannot be secured. Teams should validate DFDs through architectural walk-throughs with multiple stakeholders before proceeding to threat enumeration.
Phase 3: Threat Enumeration
For each element and trust boundary crossing, the analyst systematically applies all six STRIDE categories. Not every category applies equally to every element type. The standard mapping is:
The analyst asks structured questions for each applicable category:
Concrete Example: E-commerce Checkout System
Consider an e-commerce system with these elements: customer browser (external entity), web application (process), payment service (process), order database (data store), and payment processor API (external entity). Trust boundaries exist between browser and web application, and between payment service and external payment processor.
At the browser-to-web-application boundary:
Spoofing: An attacker might forge session tokens to impersonate legitimate customers. Mitigation: implement server-side session validation with cryptographically secure session identifiers that rotate after authentication events.
Tampering: An attacker might modify request parameters, such as product prices or quantities, before server processing. Mitigation: validate all input server-side; implement price verification against authoritative product catalog; never trust client-supplied transactional data.
Information Disclosure: Error responses might expose application internals such as database schema, file paths, or stack traces. Mitigation: return generic error messages to clients while logging detailed error information server-side only.
Denial of Service: An attacker might flood the checkout endpoint to exhaust server resources during peak shopping periods. Mitigation: implement rate limiting per source IP, connection throttling at the load balancer, and auto-scaling policies for checkout processing capacity.
Elevation of Privilege: A customer might attempt to access administrative functions by manipulating URLs or request parameters. Mitigation: enforce role-based access controls on every endpoint with server-side authorization checks independent of client-side restrictions.
For the payment service data store, the analysis focuses on three primary categories. Tampering threats include unauthorized modification of order amounts or payment status. Information Disclosure threats include unauthorized access to payment card data or customer financial information. Denial of Service threats include database connection exhaustion or storage capacity attacks.
Phase 4: Risk Assessment
Each identified threat receives a risk score using a consistent methodology. Organizations using DREAD score threats across five dimensions: Damage potential, Reproducibility, Exploitability, Affected user base, and Discoverability. Organizations aligned with NIST frameworks may map threats to likelihood and impact ratings from Special Publication 800-30. The output is a prioritized threat list enabling resource allocation decisions.
Phase 5: Mitigation Planning
For each threat, the team identifies specific mitigation approaches: technical controls (encryption, input validation, access controls), compensating controls (monitoring, incident response procedures), or accepted risks with documented rationale and approval. Accepted risks require explicit sign-off from designated risk owners. All mitigations are tracked in a threat model document that becomes part of the system's security architecture documentation.
---
STRIDE prevents entire vulnerability classes from reaching production environments. Organizations that skip systematic threat modeling typically discover security weaknesses through incidents rather than design reviews. The remediation cost difference is substantial: addressing design-level flaws before deployment requires hours of engineering time; remediating the same flaws after exploitation involves incident response costs, regulatory penalties, potential legal liability, and reputation damage.
The 2017 Equifax breach demonstrates the consequence of inadequate design-level threat analysis. The exploited vulnerability (Apache Struts CVE-2017-5638) involved insufficient validation of untrusted input, a threat that maps directly to STRIDE's Tampering category. Systematic STRIDE analysis of the application's data flows would have prompted the question: "Can an attacker modify data passing through this component without authorization?" The answer would have directed implementation of input validation and sanitization controls. The absence of that systematic questioning contributed to exposing 147 million consumer records.
STRIDE applies beyond new system development. Any architectural change requires threat model updates: integration with new third-party services, infrastructure migrations, authentication system modifications, new API endpoints, or changes to data processing workflows. Each change potentially introduces new trust boundaries, alters existing data flows, or modifies the attack surface available to potential adversaries.
A critical misconception treats threat modeling as a point-in-time activity completed during initial system design. Threat models become outdated as systems evolve. New features introduce new data flows. Cloud migrations alter trust boundaries. Third-party integrations change the external entity landscape. Organizations that treat threat modeling as a project kickoff checkbox rather than an ongoing design discipline accumulate unanalyzed threat surface with every release cycle.
STRIDE also improves communication between security specialists and engineering teams. The six categories provide developers with concrete vocabulary for discussing security concerns without requiring deep expertise in cryptographic implementation or attack techniques. A software engineer who understands that "Tampering means an attacker could modify this data in transit" can meaningfully participate in threat discussions and implement appropriate controls without needing to understand TLS handshake mechanics or HMAC construction details.
The methodology scales across organization sizes and system complexity. Small teams can apply STRIDE manually using diagramming tools and spreadsheets. Large enterprises can integrate STRIDE into automated design review workflows with tools like Microsoft Threat Modeling Tool or custom implementations that generate threat catalogs from architectural diagrams stored in enterprise repositories.
---
CDA implements STRIDE as a continuous design assurance activity within the Perpetual Compliance Assurance (PCA) methodology, not as a project-phase deliverable. PCA's foundational principle that "compliance is not an event; it is a state" applies directly to threat modeling: a threat model produced at system inception and never updated is not a security control; it is historical documentation with diminishing relevance to current risk posture.
Within the Planetary Defense Model (PDM), STRIDE analysis spans three domains with distinct responsibilities. Risk Governance and Architecture (RGA) owns threat models as governance artifacts, ensuring every system with defined security classification maintains current, reviewed threat models linked to architecture documentation. Vulnerability and System Defense (VSD) consumes STRIDE outputs to prioritize vulnerability remediation efforts and validate that identified threat categories have corresponding preventive or detective controls. Threat Intelligence and Detection (TID) maps STRIDE-identified threats to detection use cases, ensuring that design-level threats have corresponding alert logic in security operations platforms before system deployment.
CDA's operational differentiation from standard STRIDE implementations centers on automated update triggers rather than manual review scheduling. While conventional implementations rely on project management processes to initiate threat model reviews, CDA's PCA framework defines system-integrated triggers: any change modifying DFD elements, introducing external integrations, altering trust boundaries, or changing authentication/authorization logic automatically initiates STRIDE review workflows through integration with change management systems and architecture repositories.
CDA extends STRIDE analysis to supply chain elements, applying the six threat categories to third-party components and vendor integrations, not only internally developed systems. This reflects PDM's recognition that supply chain compromise and trust boundary violations represent frequently exploited attack vectors in modern threat landscapes. Third-party integrations receive the same systematic STRIDE analysis as internal system components, with particular attention to data flows crossing organizational boundaries.
The CDA approach also emphasizes threat model validation through red team exercises and purple team collaborations. After STRIDE analysis identifies potential threats and teams implement corresponding mitigations, CDA validates threat model accuracy by attempting to realize identified threats against implemented controls. This validation loop ensures that theoretical threat identification translates to practical security improvements rather than documentation compliance alone.
---
---
---