threat

# Threat Modeling (Deep Workflow) Threat modeling turns **architecture** into **attack scenarios** and **mitigations** before code hardens incorrectly. It is **team-facing**—security is a **collaborative** exercise, not a gate at the end. ## When to Offer This Workflow **Trigger conditions:** - New service, major data flow change, public API, partner integration - Compliance asks for “threat model” artifact - Post-incident “how do we prevent class of issues” **Initial offer:** Use **six stages**: (1) scope & assets, (2) diagram & trust boundaries, (3) threats (STRIDE), (4) mitigations & controls, (5) prioritize & owners, (6) validate & iterate. Confirm **time box** (1–2 hour workshop vs async). --- ## Stage 1: Scope & Assets **Goal:** Agree **what** we model and **what we protect**. ### Questions 1. **In scope**: apps, infra, data stores, admin tools, CI/CD? 2. **Crown jewels**: data (PII, keys), money, availability, reputation 3. **Adversaries**: script kiddies, malicious insiders, nation-state (usually pick **realistic** tiers) ### Output **Scope paragraph** + **asset list** with sensitivity. **Exit condition:** Shared understanding of **what hurts if lost**. --- ## Stage 2: Diagram & Trust Boundaries **Goal:** Visual model with **boundaries** where trust changes. ### Practices - **DFD-ish** diagram: external actors, services, data stores, queues - Mark **trust boundaries**: internet boundary, partner VPC, employee laptop, CI system - Note **auth** mechanisms crossing boundaries (mTLS, JWT, API keys) ### Pitfalls - **Missing** CI/CD and admin paths—attackers love them - **Over-detailed** diagram—keep level consistent **Exit condition:** Diagram everyone in the room **recognizes** as their system. --- ## Stage 3: Threats (STRIDE) **Goal:** Systematic **brainstorm**—not exhaustive fantasy. ### STRIDE prompts - **Spoofing**: impersonation of user/service - **Tampering**: data/code/config changed in transit or at rest - **Repudiation**: actions not attributable—audit gaps - **Information disclosure**: leaks to unauthorized - **Denial of service**: resource exhaustion, dependency attacks - **Elevation of privilege**: user becomes admin, lateral movement ### Technique - Walk **each boundary** + **each asset** with STRIDE columns—**rapid ideation**, defer judgment - Capture **threats** as short scenarios: “Attacker with leaked API key calls admin endpoint” **Exit condition:** **Threat list** with **assumptions** stated (e.g., “requires MITM”). --- ## Stage 4: Mitigations & Controls **Goal:** Map threats to **controls**—prevent, detect, respond. ### Control types - **Prevent**: authZ checks, input validation, encryption - **Detect**: logging, alerts, IDS, anomaly detection - **Respond**: kill switches, incident playbooks ### Avoid - **Control theater**—checkbox without real enforcement **Exit condition:** Each **high** threat has at least one **planned** control or accepted risk with **owner**. --- ## Stage 5: Prioritize & Owners **Goal:** **Ruthless** prioritization—fix what matters. ### Factors - **Impact** × **likelihood** (even qualitative MoSCoW) - **Ease of exploitation** vs **cost to fix** ### Tracking - **Tickets** per mitigation; **link** to threat ID - **Residual risk** explicitly accepted by appropriate authority when not fixed **Exit condition:** **Roadmap** of mitigations with **dates**. --- ## Stage 6: Validate & Iterate **Goal:** Model **ages**—revisit on major changes. ### Triggers for refresh - New data flow, new integration, auth redesign - **Pen test** findings that contradict assumptions ### Light validation - **Red team** scenarios for top threats if mature org --- ## Final Review Checklist - [ ] Assets and scope agreed - [ ] Trust boundaries diagram current - [ ] STRIDE pass completed for boundaries - [ ] Mitigations mapped; owners assigned - [ ] Residual risk explicit where unmitigated ## Tips for Effective Guidance - **Facilitate**, don’t lecture—engineers own the system facts. - Prefer **scenarios** over abstract “Tampering risk.” - Link to **requirements** (“every admin action audited”) for traceability. ## Handling Deviations - **No time workshop**: async diagram + STRIDE spreadsheet review. - **Tiny feature**: **mini** threat model—still document **trust boundary** with external API.