What Is Threat Modeling and How to Do It With STRIDE

The OWASP threat modeling framework organizes the exercise around four questions:

1. What are we building? Create a data flow diagram (DFD) of the system showing: external actors (users, external services), processes (application components), data stores (databases, caches, file systems), and data flows (API calls, database queries, message queue messages). Every element in the diagram is a potential threat surface.

2. What can go wrong? Apply STRIDE categories to each element. For each data flow: what happens if an attacker spoofs the sender? Tampers with the data? For each data store: what is the impact of unauthorized information disclosure? For each process: what if an attacker gains elevated privilege?

3. What are we going to do about it? For each threat identified, define a mitigation: a technical control (encryption, authentication, rate limiting), an operational control (monitoring, alerting), or an accepted risk (documented decision that the threat is low-probability or low-impact and no additional control is warranted).

4. Did we do a good enough job? Review the threat model against your organization's risk appetite. Verify that high-severity threats have specific, testable mitigations. Schedule a follow-up review when the design changes significantly.

S: Spoofing: An attacker impersonates a legitimate entity: a user, a service, or a system component. The attacker pretends to be someone they are not.

• Examples: Sending an API request with a forged authentication token, a malicious service impersonating a legitimate backend
• Mitigations: Strong authentication (MFA, certificate-based auth), message signing, mutual TLS for service-to-service communication

T: Tampering: An attacker modifies data in transit or at rest without authorization.

• Examples: Man-in-the-middle modification of API responses, modification of data in a shared database, tampering with log files
• Mitigations: Integrity controls (HMAC signatures, digital signatures, checksums), TLS for data in transit, write-access restrictions on data stores

R: Repudiation: A user or system performs an action and later denies having performed it, and there is insufficient evidence to prove otherwise.

• Examples: A user denies making a financial transaction, a service denies sending a request that caused a downstream failure
• Mitigations: Tamper-evident audit logging, digital signatures on critical transactions, non-repudiation tokens

I: Information Disclosure: Sensitive information is exposed to parties who should not have access to it.

• Examples: Verbose error messages exposing stack traces or database queries, unencrypted data in transit, overly permissive API responses returning more fields than the caller needs
• Mitigations: Principle of least privilege for data access, encryption at rest and in transit, output filtering (return only the fields the caller is authorized to see), generic error messages

D: Denial of Service: An attacker degrades or eliminates the availability of a system or resource.

• Examples: Resource exhaustion via unlimited API requests, large file upload attacks, slow-loris HTTP attacks
• Mitigations: Rate limiting, resource quotas, input size limits, timeout configuration, CDN/WAF for volumetric DDoS

E: Elevation of Privilege: An attacker gains capabilities or access beyond what they are authorized for.

• Examples: IDOR/BOLA accessing another user's data, SQL injection gaining database admin, a low-privilege process exploiting a vulnerability to gain OS-level access
• Mitigations: Principle of least privilege, input validation, parameterized queries, sandboxing, authorization checks at every layer

A basic threat model for a single feature or system takes 2-4 hours with 3-5 people: a developer who knows the system design, a security person, and a product owner or architect.

Step 1: Create the data flow diagram (60 minutes)

Draw (on a whiteboard or in a tool like draw.io, Microsoft Threat Modeling Tool, or OWASP Threat Dragon) the system with four element types:

• External entities (rectangles): Users, external services, third-party APIs: anything outside your trust boundary
• Processes (circles/ovals): Application components, microservices, Lambda functions: anything that processes data
• Data stores (parallel lines): Databases, caches, queues, file systems: anywhere data rests
• Data flows (arrows): API calls, database queries, event messages: how data moves between components

Mark your trust boundaries as dashed lines: where does your organization's control end and external/user control begin?

Step 2: Apply STRIDE to each element (60-90 minutes)

For each data flow, process, and data store, work through each STRIDE category. Create a table:

Step 3: Prioritize and assign (30 minutes)

Score each threat by severity (impact * likelihood) using CVSS or a simpler High/Medium/Low scale. Assign each mitigation to a specific person and sprint. High and Critical threats should be mitigated before the feature ships; Medium can be scheduled in the next sprint.

Step 4: Validate in code review

When the feature is implemented, the threat model becomes a security code review checklist: each mitigation in the threat model should have a corresponding test or implementation detail to verify.

Free tools:

• Microsoft Threat Modeling Tool: Free Windows application that auto-generates STRIDE threats from a DFD you draw: good for teams new to threat modeling
• OWASP Threat Dragon: Open-source browser-based tool with STRIDE support, integrates with GitHub
• draw.io / diagrams.net: Flexible diagramming tool for the DFD: use the STRIDE worksheet separately

When to run a threat model:

• Before starting development on any new feature that introduces: authentication, authorization, data storage, API endpoints, external integrations, or cryptographic operations
• Before significant architectural changes (adding a new service, changing the authentication mechanism, integrating a new third party)
• As part of the annual security review for systems handling sensitive data
• After a security incident: threat model what went wrong to identify systemic design issues

Scope management: keeping sessions productive: A threat model that tries to cover an entire application in one session becomes unmanageable. Scope each session to a single feature, integration, or data flow. A series of focused 2-hour sessions is more effective than a single exhausting 8-hour exercise.

The minimum viable threat model: If a full STRIDE session is not feasible, a 30-minute 'security design question' review covers the most critical ground:

1. Where does authentication happen, and can it be bypassed?
2. Where does authorization happen, and is it checked at every data access point?
3. What sensitive data is stored, and who can read it?
4. What happens if this component receives malformed or malicious input?

These four questions surface the majority of design-level security flaws without requiring formal threat modeling training.