defense-threat-modelinglisted

# 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 HackAgent 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