Threat model
Also: Adversary model
A written statement of who the adversary is, what they can do, and what they are trying to reach — the document that makes every other security decision checkable.
Without it, security work is a list of measures with nothing to justify them. With it, every control can be traced to a capability it denies, and every control that traces to nothing can be removed.
The three questions
- Who. A researcher, an opportunistic scanner, a competitor, a state, an insider — these differ in patience and budget, not only in skill.
- What they can do. Read traffic, run code on the host, submit input, hold a valid credential, physically touch the hardware.
- What they want. Funds, data, availability, or the reputational damage of being seen to succeed.
Where it goes wrong
The common failure is not omitting an adversary but assuming one who does not exist. A model built for an attacker who plays fair produces controls that a real attacker walks around, and the most expensive version of this mistake is trusting a component that the adversary is also allowed to influence.
Why it is written down
Because an unwritten model cannot be disagreed with. The value is less in the analysis than in the artefact: a document the next engineer can read, argue against, and update when the system changes — which it will, usually without anyone revisiting the assumptions the design was based on.