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.