STRIDE per element
Six categories of threat, each tied to a property they violate:
- Spoofing: violates authenticity.
- Tampering: violates integrity.
- Repudiation: violates non-repudiation.
- Information disclosure: violates confidentiality.
- Denial of service: violates availability.
- Elevation of privilege: violates authorization.
The trick is per-element. Walk every node in your data-flow diagram - process, data store, external interactor, data flow - and ask which STRIDE categories apply. Microsoft's STRIDE-per-element table tells you that data stores can be tampered with and disclosed but cannot themselves spoof; external interactors can spoof and repudiate but cannot directly tamper with data they do not own; and so on.
Attack trees
An attack tree starts with a goal at the root ("read CEO's email") and branches into ways to achieve it ("phish CEO", "compromise mail server", "subpoena the provider"). Each branch can be further decomposed into sub-goals.
What attack trees give you over flat lists:
- Boolean structure: OR-nodes (any child suffices) vs AND-nodes (all children needed). Defenses on AND-nodes are cheaper.
- Annotated leaves: cost, difficulty, detectability. Multiplying through tells you which attack path is most attractive to which adversary class.
- Reuse: once drawn, the same tree applies to similar goals on similar systems.
DREAD: honest about its limits
DREAD scores each threat on five 1-10 axes:
- Damage potential
- Reproducibility
- Exploitability
- Affected users
- Discoverability
Average the five and you get a rough priority. Microsoft itself abandoned DREAD in 2008 because different engineers scored the same threat very differently; the numbers gave false precision. It is still useful in a workshop to force teams to talk about each axis, especially Affected users and Damage, but treat the final number as approximate and the discussion as the actual value.
LINDDUN: for privacy threats
STRIDE covers security but barely touches privacy. LINDDUN is its privacy-focused twin:
- Linkability
- Identifiability
- Non-repudiation (as a privacy harm: a person cannot deny their action)
- Detectability
- Disclosure of information
- Unawareness
- Non-compliance
Apply LINDDUN per data flow on the same DFD STRIDE uses. If a system logs every action with a unique user ID, STRIDE sees accountability (good); LINDDUN sees linkability and identifiability (a privacy harm). Both views are valid; you choose based on the threats that matter.
Where threat modelling actually fails
The honest pitfalls:
- Done once, then filed. The model that does not get updated with the system is worse than no model, because it gives false comfort.
- Treated as compliance. A threat model done to satisfy an auditor and never to inform a design decision is theater.
- Wrong granularity. Modelling at the level of "the application" misses most threats. Modelling at the level of every function is unreadable. Component-level is usually the sweet spot.
- No follow-through. A threat identified but not assigned an owner and a deadline is just an item on a list.