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:
   • Spoofing (authn), Tampering (integrity), Repudiation (logging), Information disclosure (confidentiality), Denial of service (availability), Elevation 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.