# Defense Threat Modeling

> Threat-model a system or feature (STRIDE + attack trees) to find design-level risk before code. Load on "threat model", a new design/architecture review, security design questions, or planning controls. Signals: architecture diagram, data-flow, "what could go wrong", pre-build security.

- Skill: `noorqureshi/defense-threat-modeling` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noorqureshi/defense-threat-modeling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noorqureshi/defense-threat-modeling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: NoorQureshi (https://skillmd.com/u/noorqureshi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noorqureshi/defense-threat-modeling

---


# Threat modeling (STRIDE + attack trees)

## When it applies
Before or during design — a new feature, service, or architecture — to find what can go wrong at
the design level, where fixes are cheapest. Pairs offense knowledge with a structured method.

## Why it works
Most breaches exploit design gaps, not just code bugs. Systematically walking each component and
data flow against a threat taxonomy surfaces missing controls (authz, validation, isolation) that
ad-hoc review misses, and produces a prioritized list of controls and tests.

## Method
1. **Model the system**: draw the data-flow diagram — external entities, processes, data stores,
   and trust boundaries (where data crosses privilege levels). The boundaries are where threats concentrate.
2. **Enumerate threats per element with STRIDE**:
   - **S**poofing (authn), **T**ampering (integrity), **R**epudiation (logging),
     **I**nformation disclosure (confidentiality), **D**enial of service (availability),
     **E**levation of privilege (authz).
3. **Attack trees** for high-value targets: root = attacker goal, branches = paths; map each to a
   real technique (link the relevant SploitAgent offensive skill).
4. **Rate & prioritize**: likelihood × impact (or DREAD); focus on trust-boundary crossings.
5. **Define controls & tests**: for each accepted threat, a mitigation and a test/detection
   (→ `defense-hardening-baseline`, `defense-detection-sigma`).

## Anti-patterns
- Modeling implementation detail instead of trust boundaries — boundaries are where risk lives.
- A threat list with no owner, control, or test — it must produce actionable, tracked mitigations.
- One-and-done — re-model when the design changes.

## Verify
A DFD with trust boundaries, a STRIDE-derived threat list, and for each significant threat a
mitigation + a validation test/detection.

## References
Shostack "Threat Modeling"; Microsoft STRIDE; OWASP Threat Modeling Cheat Sheet.