Threat Modelling
Defensive view: threat modelling. Authorised work only - the goal is to prevent issues before they become incidents.
Defender-first overview
EXAMPLE
# Threat modelling - defender perspective > A threat model is a forward-looking risk exercise tied to a system you are > building or operating. Authorised work only; outputs should drive > engineering decisions, not score lookups. ## Frameworks worth knowing - STRIDE - Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation - LINDDUN - privacy-oriented (Linkability, Identifiability, Non-repudiation, Detectability, etc.) - PASTA - 7-stage risk-led approach - attack trees for surface mapping - MITRE ATT&CK for behavioural context ## A minimum-viable threat model 1. What are we building? - 1-page system diagram 2. What can go wrong? - apply STRIDE to each element 3. What are we going to do about it? - controls + design changes 4. Did we do a good job? - track outcomes; revisit after incidents ## High-value questions - Who is the most likely attacker, and what do they want? - Which data classes are most sensitive? - Where does the trust boundary actually sit? - What is the blast radius if any one element is compromised? - What is the detection surface for each entry point? ## Practical workflow - Threat model alongside design docs - not after release - Use a checklist (OWASP Cheat Sheet, NIST 800-53 controls) - Track mitigations as engineering work items - Revisit when architecture changes materially - Pair with red/blue teams for adversarial perspective ## Outputs - A short doc (often 2-5 pages) with diagram + threats + mitigations - A backlog of mitigations with owners and target dates - A short summary of accepted residual risk ## Common pitfalls - Treating it as a one-time compliance artefact - Threat-modelling at infrastructure level only; missing the business logic - Over-engineering for unlikely threats; under-engineering for likely ones - No follow-through on the mitigation backlog
Why it matters
Threat modelling is engineering risk management - a small cost up front that prevents incidents later. Keep it lightweight (2-5 pages), tie it to architecture changes, and treat the mitigation backlog as real work, not paperwork.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
# Threat-model before features ship, not after a breach. # Use STRIDE per data flow. Write down the assumptions + invariants. # See the OWASP Top 10 track for the modelling chapter.Try it Yourself »
Discussion
Loading…