Threat Modelling

Also Known As

TL;DR

Explanation

Threat modelling (STRIDE, PASTA, LINDDUN) is a proactive security activity performed during design — typically cheaper than fixing vulnerabilities post-deployment. The process involves: identifying assets to protect, decomposing the application into data flows and trust boundaries, enumerating threats using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), and defining mitigations. Regular threat modelling sessions on new features integrate security into the development cycle rather than bolting it on.

Diagram

flowchart TD
    SCOPE[Define Scope<br/>what are we protecting?] -->
    ASSETS[Identify Assets<br/>user data, credentials, APIs] -->
    THREATS[Identify Threats<br/>STRIDE analysis] -->
    VULN[Find Vulnerabilities<br/>how could each threat succeed?] -->
    MITIGATE[Design Mitigations<br/>controls for each threat] -->
    VALIDATE[Validate<br/>test mitigations work]
    subgraph STRIDE
        S[Spoofing]
        T[Tampering]
        R[Repudiation]
        I[Info Disclosure]
        D[Denial of Service]
        E[Elevation of Privilege]
    end
style SCOPE fill:#1f6feb,color:#fff
style VALIDATE fill:#238636,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Threat modelling only once at project start and never revisiting as the system evolves.
• Identifying threats without assigning mitigations — a threat list with no actions provides no value.
• Focusing only on technical threats and missing business logic abuse scenarios.
• Not involving developers in threat modelling — security teams alone miss domain context.

Code Examples

// Feature built without threat modelling:
// New feature: users can export their data as CSV
// Shipped without asking: can users export OTHER users' data? (IDOR)
// Can the export be triggered to DoS the server? (resource exhaustion)
// Does the export include fields that should stay internal? (data exposure)
// All found in pentest 6 months later — expensive to fix

# Threat modelling — STRIDE framework for PHP apps

# S — Spoofing (impersonation)
#   Threats: credential stuffing, session theft
#   Mitigations: MFA, SameSite cookies, session regeneration on login

# T — Tampering (data integrity)
#   Threats: SQLi, XSS, request modification
#   Mitigations: prepared statements, CSP, input validation

# R — Repudiation (deny actions)
#   Threats: no audit trail
#   Mitigations: immutable audit log with user, action, timestamp, IP

# I — Information Disclosure
#   Threats: verbose errors, debug endpoints, IDOR
#   Mitigations: display_errors=Off, auth on all endpoints

# D — Denial of Service
#   Threats: rate limit bypass, ReDoS, large uploads
#   Mitigations: rate limiting, regex review, upload size limits

# E — Elevation of Privilege
#   Threats: mass assignment, broken access control
#   Mitigations: fillable/guarded, policy-based authorisation

References

• ↗ https://owasp.org/www-community/Threat_Modeling
• ↗ https://owasp.org/www-project-threat-modeling-playbook/

Tags

Related Terms