Threat Modeling — Canonical Reference.
STRIDE, LINDDUN, attack-tree, and the Diamond model as a structured note-taking template — paired with the preventive and responsive control maps over the attack lifecycle.
STRIDE — per-component threat enumeration
- Spoofing — identity claim is fake. Defense: authentication.
- Tampering — data modified in transit or at rest. Defense: integrity (signatures, MACs).
- Repudiation — actor denies action. Defense: logging + non-repudiation (signed actions).
- Information disclosure — confidential data leaked. Defense: encryption + access control.
- Denial of service — availability degraded. Defense: rate-limiting, redundancy, isolation.
- Elevation of privilege — actor gains rights they shouldn't. Defense: authorization, least privilege.
- Workflow. Draw data-flow diagram → identify trust boundaries → for each element crossing a boundary, walk STRIDE → record threat + mitigation + residual risk.
LINDDUN — privacy threats
- Linkability — different actions can be linked to same actor.
- Identifiability — pseudonymous data can be re-identified.
- Non-repudiation — actor cannot deny an action (privacy reads this as harm, not as benefit).
- Detectability — actor can be detected as having performed an action.
- Disclosure of information — see STRIDE-I.
- Unawareness — user doesn't know what data is collected/processed.
- Non-compliance — system violates regulation (GDPR, CCPA).
- When. Anywhere personal data flows. Right framework for any GDPR/DPIA work.
Attack trees
- Root = adversary objective. E.g. "exfiltrate customer PII".
- OR-nodes for alternative paths. Phish admin OR exploit web app OR insider.
- AND-nodes for required combinations. Phish admin AND bypass MFA.
- Leaf evaluation. Per leaf: cost, skill, time, detection probability. Cheapest unmitigated leaf = highest-priority defense.
- Mark deployed defenses. Defended leaves cut off subtrees; remaining paths show actual residual exposure.
Diamond model
- Four vertices. Adversary, Capability, Infrastructure, Victim. Two meta-features: socio-political (why), technology (how).
- Pivot relationships. One vertex is anchor (e.g. captured C2 IP = Infrastructure); pivot to other vertices via what's known about that IP (used by which actor? what tooling? hit which victims?).
- Discipline. Every claim tagged with source + confidence. Vertices without source = "unknown", not best-guess. Best-guess in a Diamond is what produces wrong attribution.
Preventive vs responsive controls across the lifecycle
- Recon / weaponization. Preventive: minimize external attack surface, OSINT cleanup. Responsive: monitor for reconnaissance patterns (CT log monitoring of own certs, honeypot subdomains).
- Delivery. Preventive: mail gateway, web gateway, USB controls. Responsive: sandbox detonation alerts, EDR exec telemetry.
- Exploitation. Preventive: patching, exploit mitigations (CFG, CET, ASLR). Responsive: EDR exploit-behavior detections.
- Installation. Preventive: app allowlisting, code signing enforcement. Responsive: persistence-location monitoring (autoruns, scheduled tasks).
- Command & control. Preventive: egress filtering, DNS sinkhole for known-bad. Responsive: NTA detecting C2 beaconing patterns.
- Actions on objective. Preventive: data-loss prevention, segmentation. Responsive: anomalous-data-egress detection, deception (canary files).
Rule of thumbPick the framework by the question you're answering, not by familiarity. STRIDE for component-level threat enumeration. Attack tree for "is X reachable". LINDDUN for privacy. Diamond for incident analysis. Using STRIDE for an incident write-up wastes effort and produces a bad write-up.
From reference to evidence