Threat Modeling

Threat modeling is a critical skill for security architects. This lesson covers the frameworks and methodologies you'll be asked about in interviews.

What Is Threat Modeling?

Threat modeling is a structured approach to identify, quantify, and address security risks in a system. It answers four key questions:

1. What are we building? (System diagram)
2. What can go wrong? (Threat identification)
3. What are we going to do about it? (Mitigations)
4. Did we do a good job? (Validation)

STRIDE Framework

Microsoft's STRIDE is the most commonly asked framework:

Threat	Description	Example	Mitigation
Spoofing	Impersonating another user/system	Stolen credentials	Strong authentication, MFA
Tampering	Modifying data without authorization	Man-in-the-middle	Integrity checks, signing
Repudiation	Denying an action occurred	"I didn't make that purchase"	Audit logs, non-repudiation
Information Disclosure	Unauthorized data access	Database breach	Encryption, access controls
Denial of Service	Making system unavailable	DDoS attack	Rate limiting, redundancy
Elevation of Privilege	Gaining unauthorized access	Privilege escalation	Least privilege, sandboxing

Interview Question

Q: "How would you threat model a user authentication system?"

Answer using STRIDE:

• Spoofing: Brute force attacks → Rate limiting, account lockout
• Tampering: Modified login requests → HTTPS, CSRF tokens
• Repudiation: Deny login attempts → Comprehensive audit logs
• Information Disclosure: Password leaks → Argon2id hashing, no password hints
• DoS: Login page flooding → CAPTCHA, rate limiting
• EoP: Admin access via injection → Parameterized queries, input validation

DREAD Risk Assessment

DREAD quantifies threat severity (scale 1-10):

Factor	Question	Scale
Damage	How bad is the impact?	1 (minimal) - 10 (complete compromise)
Reproducibility	How easy to reproduce?	1 (difficult) - 10 (trivial)
Exploitability	How easy to exploit?	1 (requires expertise) - 10 (automated)
Affected Users	How many users impacted?	1 (single user) - 10 (all users)
Discoverability	How easy to find?	1 (hidden) - 10 (obvious)

Risk Score = (D + R + E + A + D) / 5

Example Calculation

SQL injection in login form:

• Damage: 10 (full database access)
• Reproducibility: 9 (consistent exploit)
• Exploitability: 7 (tools available)
• Affected Users: 10 (all users)
• Discoverability: 8 (common testing)

Score: (10+9+7+10+8)/5 = 8.8 (Critical)

Data Flow Diagrams

┌─────────────────────────────────────────────────────────────┐
│                      TRUST BOUNDARY                          │
│  ┌─────────┐         ┌──────────┐         ┌──────────────┐ │
│  │  User   │─HTTPS──▶│   API    │─TLS────▶│   Database   │ │
│  │ Browser │◀────────│  Server  │◀────────│              │ │
│  └─────────┘         └──────────┘         └──────────────┘ │
│       │                   │                                  │
│       │                   │ gRPC                            │
│       │                   ▼                                  │
│       │              ┌──────────┐                           │
│       └─WebSocket───▶│  Cache   │                           │
│                      │ (Redis)  │                           │
│                      └──────────┘                           │
└─────────────────────────────────────────────────────────────┘

Threat Points:
1. Browser → API: AuthN, input validation
2. API → Database: SQL injection, access control
3. API → Cache: Session hijacking
4. Trust boundary crossing: All external inputs untrusted

Attack Trees

Visual representation of attack paths:

Goal: Steal User Credentials
├── Phishing Attack
│   ├── Send fake login email
│   └── Clone login page
├── Credential Stuffing
│   ├── Obtain breach database
│   └── Automate login attempts
├── Man-in-the-Middle
│   ├── ARP spoofing on network
│   └── SSL stripping attack
└── Direct Database Access
    ├── SQL injection
    └── Exploit unpatched vulnerability

Interview Whiteboard Exercise

Prompt: "Threat model a file upload feature"

Structured Response:

1. Assets: User files, server storage, application integrity

2. Trust Boundaries: Browser → API → Storage service

3. Threats (STRIDE):

   • Spoofing: Upload as another user → Authentication check
   • Tampering: Malicious file content → Content validation
   • Repudiation: Deny uploading malware → Audit logs
   • Info Disclosure: Access other users' files → AuthZ checks
   • DoS: Upload huge files → Size limits, quotas
   • EoP: Execute uploaded code → Filename sanitization, separate storage

4. Key Mitigations:

def secure_upload(file, user_id):
    # 1. Validate file type (not just extension)
    if not validate_mime_type(file):
        raise InvalidFileError()

    # 2. Scan for malware
    if not virus_scan(file):
        raise MalwareDetectedError()

    # 3. Generate safe filename
    safe_name = f"{uuid4()}{get_safe_extension(file)}"

    # 4. Store outside web root
    path = f"/secure-storage/{user_id}/{safe_name}"

    # 5. Log the upload
    audit_log(user_id, "upload", safe_name)

    return store_file(file, path)

Interview Tip: When asked to threat model, draw a diagram first. It shows structured thinking and helps you systematically identify threats at each component and connection.

Next, we'll cover API security patterns. :::