Pick the system with the highest cost of failure and the lowest current threat model quality. Form the pair: the system architect and the security architect. Run the four-question model, in writing, for the system as it is currently designed. Resist the temptation to model the system as it should be. The first model is always the actual system, not the ideal system. Then iterate.
Threat Modeling
Threat modeling is the discipline of asking "what would have to be true for this system to fail catastrophically, and what do we do about that?" Run continuously, not annually.
On this page
§ 01 ·
What threat modeling is
Threat modeling is the architectural discipline of identifying, for a given system, who would want to attack it, what they would want, what they could touch, and what would stop them. The output is a model of the system's threat surface: not a list of vulnerabilities, not a penetration test report, not a risk register. The model is the input to control selection, to test prioritisation, to the security architecture.
The four questions that any threat model has to answer:
1. What are we building? (the system, in enough detail that the rest of the conversation is grounded) 2. What can go wrong? (the threats, named as concrete adversary actions, not abstract categories) 3. What are we going to do about it? (the controls, with explicit traceability to the threats) 4. Did we do a good job? (the validation: review, test, red team, the model's own quality)
These are the four questions Shostack formalized in "Threat Modeling: Designing for Security." The contribution that has held up is the framing of threat modeling as a design activity, not an audit activity. The work happens at design time, with the system architect and the security architect in the same room. A threat model produced after the system is built is a finding list, not a threat model.
§ 02 ·
What threat modeling is not
Three things threat modeling is often confused with, that it is not.
It is not a STRIDE exercise. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a useful mnemonic for brainstorming threats. It is not a methodology. STRIDE without a model of the system produces a generic threat list, not a threat model.
It is not a penetration test report. A penetration test validates a threat model; it does not produce one. The penetration tester is testing the model's predictions. If the model is wrong, the test will be wrong in interesting ways, but neither is the threat model.
It is not an annual review. A threat model that has not been updated since the system was designed is documentation, not architecture. The system changes; the threat model has to change with it. The cadence is continuous, not annual.
§ 03 ·
State of the practice
4
Questions every threat model has to answer (Shostack, 2014)
Adam Shostack, 'Threat Modeling: Designing for Security', Wiley, 2014
6
STRIDE categories — useful as a brainstorm prompt, not a methodology
Microsoft, 1999 (current STRIDE variants)
~3
Hours per thousand lines of code, for an embedded threat modeling practice
Industry observation; varies by system complexity and team experience
§ 04 ·
Questions we get asked
The methodology matters less than the discipline. STRIDE is the most common starting point and is adequate for most systems. PASTA is more rigorous and is the right choice when the system has regulatory or contractual requirements. LINDDUN is the right choice when the threat model is about privacy rather than security. Attack trees are a useful supplement, not a methodology on their own. The methodology is the lens; the threat model is the output. Pick the lens your team can sustain.
You model the system as you currently understand it, and you mark the gaps. The model is not a representation of perfect knowledge; it is a representation of current knowledge with the uncertainties surfaced. The model is updated as understanding improves. The thing to avoid is pretending the model is complete when it is not. A model that says "we don't know what happens in this subsystem" is more useful than a model that confidently asserts something wrong.
The four questions still apply, but the answers are different. "What can go wrong" includes prompt injection, model inversion, training data extraction, jailbreaks, and supply chain attacks against the model and its training data. "What are we going to do about it" includes input validation, output filtering, model evaluation, rate limiting, and human-in-the-loop review for high-stakes decisions. The threat model is the right place to decide which of these controls are worth the cost.
The threat model has to live in the same place as the design documentation, with the same review cadence. A threat model in a separate repository, maintained by a separate team, on a separate schedule, goes stale by definition. The right answer is to embed threat model updates in the design review process: when the design changes, the threat model is reviewed as part of the same change.
§ 05 ·
Patterns we design our practice to avoid
Threat modeling is a practice, not an event. A single meeting produces a document, not a model. The model has to be updated as the system changes, and the update has to be part of the design process. A team that does threat modeling in a quarterly review is not doing threat modeling; it is producing a finding list on a schedule.
A threat model that nobody has read in two years is documentation, not architecture. The model has to be living: reviewed when the system changes, consulted when the controls are selected, updated when the controls are insufficient.
The first model is the actual system, including the legacy parts, the workarounds, the parts that are not supposed to be in production but are. The model of the ideal system is a wish list, not a threat model.
A threat model that produces no findings is more often a sign of insufficient rigour than sufficient security. The validation question (did we do a good job?) is the part that catches the failure mode. The model needs adversarial review.
Threat modeling is a design activity. The system architect has to be in the room. A threat model produced by the security team, for the security team's records, is a finding list with extra steps. The model has to be owned by the system team, with the security team as the discipline.
Most modern systems have supply chain dependencies: libraries, services, infrastructure. A threat model that stops at the system boundary is a model of the parts the team controls and a blind spot on the parts they don't. The supply chain threat model is part of the system threat model, not a separate document.
§ 06 ·
Evidence & references
Public frameworks and writing that inform our practice.
Threat Modeling: Designing for Security
Adam Shostack, Wiley, 2014
The book that formalised the four-question model. The book's contribution is not the methodology (there are several); it is the framing of threat modeling as a design activity.
NIST, 2016 (draft)
The data-centric variant. The shift from system- centric to data-centric is the right move for any system where the data is the asset, which is most modern systems.
STRIDE (and the modern variants)
Microsoft, 1999 - present
The most-cited threat categorisation. STRIDE is a useful brainstorm prompt and not much more. The value of STRIDE is the discipline of naming threats by category, not the specific categories themselves.
PASTA — Process for Attack Simulation and Threat Analysis
Tony UcedaVélez and Marco Morana, 2015
The risk-centric methodology. The right choice for systems with regulatory or contractual requirements, where the threat model has to be defensible to a non-technical audience.
KU Leuven, 2019 (current)
The privacy threat modeling methodology. LINDDUN is the right choice when the threat model is about privacy rather than security. The categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) map to GDPR and other privacy frameworks.
Building a threat modeling practice?
If you are weighing a threat modeling initiative, evaluating a methodology, or trying to make an existing practice more than a documentation exercise, we are useful at the boundary between the model and the implementation. A short conversation is the right next step.
Learn more