Loom Threat Model

Threat Modeling

Structured identification of what can go wrong in a design, before code exists. Answers four questions (Shostack): What are we building? What can go wrong? What are we doing about it? Did we do a good job? This skill is architecture-time analysis — for finding vulns in existing code use loom-security-scan/loom-security-audit; for auth mechanism details use loom-auth.

When

New system design, architecture review, significant feature or trust-boundary change, third-party integration, or compliance evidence. Re-run when the architecture changes — a threat model is a living document, not a one-time deliverable.

Methodologies

STRIDE — the default; apply per element of the DFD

The core technique isn't "brainstorm STRIDE" — it's walking each DFD element and each data flow crossing a trust boundary, asking which STRIDE categories apply to that element.

Element→likely-STRIDE heuristic: external entities → S, R; processes → all six; data flows → T, I, D; data stores → T, I, D (and R if logs).

DREAD — risk scoring (use with caution)

Score Damage, Reproducibility, Exploitability, Affected users, Discoverability (1–10); risk = mean. ⚠ DREAD is widely criticized as subjective and inconsistent across raters (Microsoft dropped it). Prefer a simple Likelihood × Impact matrix, or CVSS for concrete vulns, when you need defensible numbers. Whatever the scale, rank threats to drive mitigation order.

PASTA / LINDDUN

• PASTA — 7-stage, risk-centric, business-objective-driven (objectives → tech scope → decomposition → threat analysis → vuln analysis → attack modeling → risk & mitigation). Use for high-stakes systems needing business alignment.
• LINDDUN — the STRIDE-equivalent for privacy threats (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance). Reach for it on GDPR/PII-heavy systems.

Process

1. Scope & assets

List assets and why an attacker wants them — this drives everything.

2. DFD with trust boundaries (the load-bearing step)

Threats concentrate at trust boundaries — every arrow crossing one is where authn/authz/validation must live. Mark: external entities, processes, data stores, data flows, and boundaries (internet↔DMZ, DMZ↔internal, tenant↔tenant, host↔container, user↔kernel).

[User] --HTTPS--> ║ DMZ ║ [API Gateway] --> ║ Internal ║ [App] --> [DB]
                  ↑ boundary: authn, TLS       ↑ boundary: authz, network policy, mTLS

A boundary you didn't draw is a check you won't add. Enumerate every flow: source, destination, protocol, data classification, boundary crossed.

3. Enumerate threats (STRIDE per element)

### API Gateway
| STRIDE | Threat | Likelihood | Impact |
| ------ | ------ | ---------- | ------ |
| S | Forged/`alg:none` JWT | Med | High |
| I | Verbose error leaks stack/version | High | Med |
| D | Rate-limit bypass | Med | High |
| E | BOLA/IDOR → other users' objects | High | Critical |

4. Attack trees (for high-value goals)

Decompose a goal into OR/AND paths; the cheapest leaf is the likely attack and shows where to spend defense.

             Steal User Data (goal)
        ┌──────────┼──────────┐        (OR)
   Compromise    Exploit App   Social
   Credentials   Vulnerability Engineering
    ┌───┴───┐     ┌───┴───┐
 Phishing Brute  SQLi   BOLA
[L:H I:H][L:M]  [L:M I:C][L:H I:H]

5. Mitigations — track to closure

| Threat | Mitigation | Priority | Status |
| ------ | ---------- | -------- | ------ |
| BOLA/IDOR | Object-level ownership checks (loom-auth) | P0 | Not started |
| SQLi | Parameterized queries | P0 | In progress |
| JWT forgery | Pin alg, validate aud/iss/exp (loom-auth) | P1 | Done |

Every high/critical threat needs a mitigation, an accepted-risk decision (with owner + justification), or a transfer. Silence = unmanaged risk.

High-Signal Threats & Their Real Controls

• BOLA / IDOR (broken object-level authz) — #1 API threat: any object accessed by id must verify caller ownership/tenant, not just "logged in". Details + wrong-vs-right in loom-auth.
• SSRF — attacker makes your server fetch an internal URL (cloud metadata 169.254.169.254, localhost, internal services). Defense is an allowlist of permitted hosts/schemes — never a blocklist. Blocklists are bypassed by DNS-rebinding, HTTP redirects, IPv6 ([::1]), and decimal/octal/hex-encoded IPs (http://2130706433/). Also disable unused URL schemes and block redirects to non-allowlisted hosts.
• Injection (SQL/NoSQL/command/LDAP/XXE) — parameterize/allowlist; treat every trust-boundary input as hostile.
• Mass assignment — client sets fields it shouldn't (role, isAdmin, tenant_id); bind explicit allowlists.
• Cloud metadata & IAM escalation — SSRF-to-credentials via the metadata endpoint; enforce IMDSv2, least-privilege roles.
• Supply chain — dependency confusion, typosquat, unsigned artifacts (see loom-dependency-scan).

Component Quick-Reference

Threat Model Document Template

# Threat Model: <System>   (v1.0, YYYY-MM-DD, author, reviewers)
1. Executive summary — key risks & recommendations
2. System description — purpose, architecture, data classification, trust boundaries
3. Assets — table (asset, classification, owner)
4. Analysis — DFD, STRIDE-per-component, attack trees
5. Risk assessment — table (threat, likelihood×impact or CVSS, level)
6. Mitigations — table (threat, mitigation, owner, timeline, status)
7. Residual risks — accepted risks + justification
8. Review schedule — trigger conditions to revisit

Verification Checklist

• DFD drawn with every trust boundary marked; each boundary-crossing flow enumerated
• STRIDE applied per element, not brainstormed globally
• Assets tied to attacker motivation and classification
• Every high/critical threat has a mitigation, accepted-risk, or transfer with an owner
• BOLA/IDOR checked on every object-addressing endpoint; SSRF defenses are allowlist-based
• Risk ranking uses a defensible scale (Likelihood×Impact or CVSS, not raw DREAD gut-feel)
• Model versioned and has a re-review trigger; privacy threats covered (LINDDUN) if PII-heavy