Back to Blog
Threat Modeling
February 18, 2026
16 min read

Practical Threat Modeling: From STRIDE to Actionable Security Controls

A comprehensive guide to identifying, analyzing, and mitigating security threats using proven threat modeling methodologies including STRIDE, PASTA, and attack trees.

Executive Summary

Threat modeling is the systematic approach to identifying security threats, understanding their likelihood and impact, and designing appropriate mitigations. This guide teaches practical threat modeling techniques that development teams can integrate into their SDLC, moving from theory to actionable security controls.

Why Threat Modeling Matters

Most security breaches exploit design flaws rather than implementation bugs. Threat modeling shifts security left by identifying and addressing threats during the design phase when fixes are 10-100x cheaper than post-deployment patches. According to NIST, finding and fixing a vulnerability in production costs 30 times more than during design.

Key Insight

Organizations that integrate threat modeling into their SDLC report 50-70% fewer critical vulnerabilities in production and reduce remediation costs by up to 60%.

1. When Should You Threat Model?

Ideal Timing for Threat Modeling:

  • ✓ New Features: Before implementation begins, during design review
  • ✓ Architecture Changes: When modifying system boundaries, data flows, or trust zones
  • ✓ New Integrations: Before adding third-party services or APIs
  • ✓ Compliance Requirements: When entering regulated industries (healthcare, finance)
  • ✓ Post-Incident: After security incidents to prevent recurrence
  • ✓ Periodic Review: Annual review of existing systems (minimum)

2. STRIDE: The Most Popular Threat Modeling Framework

Developed by Microsoft, STRIDE categorizes threats into six types. Each letter represents a different threat category that violates a specific security property:

S - Spoofing (Authentication)

Pretending to be something or someone you're not.

Examples: Stealing authentication tokens, session hijacking, email spoofing

Mitigations: Multi-factor authentication, digital signatures, mutual TLS, strong session management

T - Tampering (Integrity)

Modifying data or code without authorization.

Examples: SQL injection, manipulating API parameters, modifying configuration files

Mitigations: Input validation, cryptographic hashing, digital signatures, integrity checks, write-once storage

R - Repudiation (Non-repudiation)

Claiming you didn't do something when you actually did.

Examples: Denying a transaction, manipulating audit logs, deleting evidence

Mitigations: Comprehensive logging, digital signatures, audit trails with timestamps, immutable logs

I - Information Disclosure (Confidentiality)

Exposing information to unauthorized parties.

Examples: Exposing database credentials, verbose error messages, unencrypted data transmission

Mitigations: Encryption (at rest and in transit), access controls, data classification, secrets management

D - Denial of Service (Availability)

Making a system unavailable to legitimate users.

Examples: Resource exhaustion, flooding attacks, algorithmic complexity attacks

Mitigations: Rate limiting, input validation, resource quotas, load balancing, auto-scaling, DDoS protection

E - Elevation of Privilege (Authorization)

Gaining capabilities without proper authorization.

Examples: Privilege escalation, path traversal, insecure direct object references (IDOR)

Mitigations: Principle of least privilege, role-based access control, input validation, authorization checks at every layer

3. The 5-Step Threat Modeling Process

Step 1: Create Architecture Diagrams

Document the system with Data Flow Diagrams (DFDs) showing:

  • • External Entities: Users, external systems, third-party services
  • • Processes: Application components, services, functions
  • • Data Stores: Databases, caches, file systems, queues
  • • Data Flows: How data moves between components
  • • Trust Boundaries: Where privilege levels change

Example: E-commerce Checkout System

┌──────────┐      HTTPS       ┌─────────────┐
│  User    │ ──────────────► │  Web App    │
│ (Browser)│                  │  (Node.js)  │
└──────────┘                  └──────┬──────┘
                                     │ Trust Boundary
                          ┌──────────┼──────────┐
                          │          │          │
                    ┌─────▼────┐ ┌──▼───┐  ┌──▼─────┐
                    │ Payment  │ │ Auth │  │ Product│
                    │ Gateway  │ │ DB   │  │   DB   │
                    │ (Stripe) │ │(PG)  │  │  (PG)  │
                    └──────────┘ └──────┘  └────────┘

Step 2: Identify Threats Using STRIDE

For each component and data flow, ask STRIDE questions:

  • • Can an attacker spoof identity? (Spoofing)
  • • Can data be tampered with in transit or storage? (Tampering)
  • • Can users deny performing actions? (Repudiation)
  • • Could sensitive information leak? (Information Disclosure)
  • • Can the service be made unavailable? (Denial of Service)
  • • Can privileges be elevated? (Elevation of Privilege)

Step 3: Rate and Prioritize Threats

Use DREAD or Risk = Impact × Likelihood scoring:

DREAD Scoring (1-10 each):

  • • Damage potential
  • • Reproducibility
  • • Exploitability
  • • Affected users
  • • Discoverability

Total Score: 40-50 = Critical | 30-39 = High | 20-29 = Medium | 10-19 = Low

Step 4: Design Mitigations

For each threat, choose response strategy:

  • • Mitigate: Implement controls to reduce likelihood or impact
  • • Eliminate: Remove vulnerable feature/component
  • • Transfer: Shift responsibility (e.g., use managed service)
  • • Accept: Document decision to accept risk (with justification)

Step 5: Validate and Document

  • • Create threat model document with all identified threats
  • • Link threats to security requirements and controls
  • • Track mitigation implementation in backlog
  • • Review with security team and stakeholders
  • • Update threat model as system evolves

4. Real-World Example: API Authentication System

Let's apply STRIDE to a JWT-based API authentication system:

System Component: JWT Token Generation & Validation

Threat: JWT Token Spoofing (Spoofing)

Description: Attacker creates valid-looking JWT without proper credentials

Impact: Complete authentication bypass, access to any user account

Mitigations:

  • ✓ Use strong signing algorithm (RS256, not none or HS256 with weak secrets)
  • ✓ Validate signature on every request
  • ✓ Store private keys in secure key management system
  • ✓ Rotate signing keys regularly

Threat: JWT Payload Tampering (Tampering)

Description: Attacker modifies JWT claims (userId, role) to elevate privileges

Impact: Privilege escalation, unauthorized access to resources

Mitigations:

  • ✓ Cryptographic signature prevents tampering (if validated properly)
  • ✓ Validate all claims server-side, never trust client data
  • ✓ Use short expiration times (15-60 minutes)
  • ✓ Implement token revocation for sensitive operations

Threat: Token Theft via XSS (Information Disclosure)

Description: Attacker injects script to steal JWT from localStorage/cookies

Impact: Session hijacking, account takeover

Mitigations:

  • ✓ Store tokens in HttpOnly, Secure, SameSite cookies (not localStorage)
  • ✓ Implement Content Security Policy (CSP)
  • ✓ Sanitize all user input to prevent XSS
  • ✓ Use short-lived access tokens with refresh token rotation

Threat: Brute Force Token Guessing (Denial of Service)

Description: Attacker floods authentication endpoint attempting to guess tokens

Impact: Service degradation, account lockouts, resource exhaustion

Mitigations:

  • ✓ Rate limiting on authentication endpoints (per IP and per account)
  • ✓ Account lockout after failed attempts
  • ✓ CAPTCHA for repeated failures
  • ✓ Monitor for unusual authentication patterns

5. Alternative Threat Modeling Methodologies

PASTA (Process for Attack Simulation and Threat Analysis)

Risk-centric methodology focusing on attacker perspective. Seven stages:

  1. Define business objectives and security requirements
  2. Define technical scope (infrastructure, software components)
  3. Application decomposition and analysis
  4. Threat analysis using threat intelligence and attack libraries
  5. Vulnerability and weakness analysis
  6. Attack modeling and simulation
  7. Risk and impact analysis

Best For: Organizations with mature security programs wanting attacker-centric analysis.

Attack Trees

Graphical representation showing how an attacker might achieve goals. Tree structure:

Goal: Steal Customer Data
├── OR: Exploit Application Vulnerability
│   ├── AND: Find SQL Injection
│   │   ├── Identify vulnerable endpoint
│   │   └── Bypass WAF
│   └── AND: Exploit XSS
│       ├── Find injection point
│       └── Exfiltrate data
└── OR: Compromise Infrastructure
    ├── AND: Steal AWS Credentials
    │   ├── Phish employee
    │   └── Access S3 bucket
    └── AND: Compromise Database
        ├── Exploit unpatched PostgreSQL
        └── Extract data

Best For: Visualizing attack paths, prioritizing defenses, penetration test planning.

LINDDUN (Privacy Threat Modeling)

STRIDE equivalent for privacy threats: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Essential for GDPR and privacy-sensitive applications.

6. Threat Modeling Tools and Resources

Recommended Tools:

Microsoft Threat Modeling Tool (Free)

STRIDE-based, DFD creation, automated threat generation, Windows only

OWASP Threat Dragon (Free, Open Source)

Web-based, STRIDE support, rule engine, cross-platform

IriusRisk (Commercial)

Enterprise platform, automated threat modeling, compliance mapping, developer integrations

ThreatModeler (Commercial)

Automated threat modeling, CI/CD integration, extensive threat libraries

Draw.io / Lucidchart (General Purpose)

Create DFDs manually, good for starting out or simple systems

7. Integrating Threat Modeling into SDLC

Planning Phase

  • • Define security requirements from threat model
  • • Include threat modeling effort in story estimates
  • • Assign security champion to facilitate sessions

Design Phase

  • • Conduct threat modeling workshop (1-2 hours)
  • • Create/update architecture diagrams
  • • Document identified threats and mitigations
  • • Review with security team before implementation

Implementation Phase

  • • Implement security controls from threat model
  • • Code review with focus on identified threats
  • • Security testing targeting threat model scenarios

Verification Phase

  • • Validate mitigations address identified threats
  • • Update threat model based on implementation learnings
  • • Document residual risks and acceptance

8. Common Threat Modeling Mistakes

❌ Mistake: Threat Modeling Too Late

Solution: Start during design phase, not after code is written. Retrofit threat modeling is 10x more expensive.

❌ Mistake: Too Much Detail Upfront

Solution: Start with high-level DFDs, drill into critical components. Iterate rather than trying to model everything.

❌ Mistake: Security Team-Only Activity

Solution: Involve developers, architects, product managers. Team-based threat modeling builds security culture.

❌ Mistake: Threat Models Become Shelf-ware

Solution: Keep threat models living documents. Update with architecture changes. Reference in security reviews.

❌ Mistake: No Validation of Mitigations

Solution: Test that implemented controls actually prevent the identified threats. Use penetration testing to validate.

Conclusion: Making Threat Modeling Practical

Threat modeling doesn't need to be perfect to be valuable. Start simple with STRIDE on new features, use templated DFDs, and iterate. The goal is shifting security left and making informed risk decisions, not producing exhaustive documentation. Even a 30-minute threat modeling session during design review prevents costly vulnerabilities in production.

Key Takeaways

  • Start threat modeling during design phase before implementation begins
  • Use STRIDE for most applications - it's well-understood and practical
  • Create Data Flow Diagrams showing trust boundaries and data flows
  • Prioritize threats using risk scoring (DREAD or Impact × Likelihood)
  • Make threat modeling collaborative - involve dev, security, and product teams
  • Validate mitigations actually prevent identified threats through testing

Streamline Your Threat Modeling Process

Securus Mind's Threat Modeling module integrates into your SDLC with automated threat identification, risk scoring, and tracking of mitigations through implementation and validation.

Schedule a Demo