Threat modelling

Most methods can be reduced to Adam Shostack's four questions, which the Threat Modeling Manifesto (2020) also adopts: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? The first question is answered with a model of the system, usually a data flow diagram showing external entities, processes, data stores, data flows and trust boundaries, or a sequence diagram for protocol-heavy designs. The quality of everything that follows depends on this model being accurate and at the right level of detail, which is why threat modelling is most effective as a conversation between architects, developers and security staff rather than a document produced by a security team alone.

The second question is answered with an elicitation technique. STRIDE, applied per element or per interaction, is the most widely used; attack trees, introduced by Bruce Schneier in 1999, decompose an attacker goal into AND/OR subgoals; PASTA is a seven-stage, risk-centric process that ties technical threats to business impact; LINDDUN covers privacy threats; and MITRE ATT&CK or CAPEC catalogues can be used to check coverage against known techniques. The third question produces decisions for each threat: mitigate, eliminate by redesign, transfer, or accept with a named owner. Findings are recorded as security requirements or backlog items so they can be tracked and tested, and the fourth question closes the loop by checking that mitigations were built and that the model still matches the system.

In a secure development lifecycle, threat modelling happens at design time and again when a change crosses a trust boundary, adds a new data type or introduces a new external dependency. NIST SP 800-218 (SSDF) practice PW.1.1 explicitly lists threat modelling, attack modelling and attack surface mapping as forms of risk modelling to evaluate security requirements. Tooling ranges from whiteboards to Microsoft Threat Modeling Tool, OWASP Threat Dragon and code-based approaches such as pytm and Threagile, which generate diagrams and findings from a model kept in version control.

Common failure modes are modelling once and never updating, producing a long list of generic threats with no decisions attached, and going too deep in one component while missing the integrations where most real flaws sit. Threat modelling differs from risk assessment in scope and timing: a risk assessment ranks risks to the organisation's assets, while a threat model examines how a specific system could be attacked, early enough to change its design. It also differs from penetration testing, which finds flaws in what has already been built.