Threat modelling

Threat modelling is a structured way of reasoning about how a design could be attacked, carried out before the design turns into code. The usual form is a small group at a whiteboard answering four questions: what are we building, what can go wrong with it, what are we going to do about that, and did we do a good enough job. The drawing matters mostly because it makes trust boundaries visible, and the interesting answers cluster wherever data crosses one of them. No specialist tool or formal notation is required, and the modest version that happens regularly is worth considerably more than the elaborate version that happens once.

The economics carry the argument. A missing authorisation check spotted on a diagram is a change to a diagram; the same gap discovered after release is a fix, a review of what was accessed, possibly a disclosure and a difficult conversation with customers. This is also the only security activity that examines what a system is meant to permit rather than how it was implemented, which is the category no scanner covers and the category business logic flaws belong to.

How a session runs

• Draw the system as data in motion: the components, the stores, the flows between them, and a line around anything that is trusted differently from its neighbours.
• Walk each flow against a prompt list. STRIDE is the common one, taking spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege in turn.
• Record every threat with a decision attached: mitigate it, accept it, transfer it, or eliminate it by changing the design. A threat with no decision beside it is a note.
• Convert those decisions into backlog items and test cases, so the model stays connected to the work instead of being filed as a document nobody opens.

The output that matters is the list of decisions rather than the diagram, and a model nobody revisits when the architecture changes describes a system you no longer operate.