Threat Model

Origin & evolution

The structured version of this thinking arrived with STRIDE, created by Loren Kohnfelder and Praerit Garg at Microsoft. On 1 April 1999 they circulated an internal paper, "The Threats☠️ThreatSecurityA specific security threatView reference → to Our Products," proposing six categories an analyst should walk through for each part of a system: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category names a security property under attack, authentication, integrity, non-repudiation, confidentiality, availability, and authorisation, so STRIDE doubles as a checklist of what you are trying to protect. Microsoft folded it into its Security Development Lifecycle, and it remains the most widely taught threat classification in the field. Analysts typically drive it over a data flow↕️Data FlowEngineeringA data flow between systemsView reference → diagram, tracing how information crosses trust boundaries.

The framing matured under Adam Shostack, whose book Threat Modeling: Designing for Security (2014) reduced the practice to four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →. The phrasing is deliberate. "Working on" rather than "building" keeps the practice usable at any stage of a system's life, and the fourth question turns threat modelling into something you can improve rather than a box ticked once. Other structured methods sit alongside it, including attack trees, which decompose a single attacker goal into the steps that would achieve it.

How it works in practice

A team is adding file uploads to a customer portal. They draw a data flow diagram: browser, upload service, virus scanner, object store. Then they walk STRIDE per element. Spoofing: can someone upload as another user? They find the signed URL does not check the caller's identity, so they add it. Tampering: can a file be swapped between scan and storage? Information disclosure: can a user guess another user's file URL? The object keys are sequential integers, so yes, and they switch to unguessable identifiers. Denial of service: a 5 GB upload could exhaust the scanner, so they cap size and add a queue. Each finding becomes a concrete change made in the design review, long before the feature⭐FeatureProduct SpecificationA product capability or featureView reference → reaches users, where the same fixes would cost ten times as much.

Threat model vs. its neighbours

• Threat is one specific way the system can be attacked, a single entry in the model. The threat model is the whole structured exercise that produces and organises those entries. One model surfaces many threats; a lone threat with no model around it lacks the context to be prioritised.
• Vulnerability🔓VulnerabilitySecurityA known vulnerabilityView reference → is an actual weakness present in the system, a flaw that exists. A threat is the abuse that a vulnerability would enable. Threat modelling reasons about threats during design, often before the code that would carry a vulnerability is even written.
• Security control🎚️Security ControlSecurityA security control or mitigationView reference → is a countermeasure put in place to block or detect a threat. The model identifies what could go wrong; the control is the answer to Shostack's third question. A model with no controls flowing out of it is analysis nobody acted on.

In the graph

In the Unified Product Graph, threat_model🏴‍☠️Threat ModelSecurityA threat model for the system anchors the security region as the activity that connects a product to its risks🎲RiskComplianceA risk to the product or businessView reference →. A product runs one through product_models_threats_with_threat_modelProductmodels threats withThreat Modelhierarchy. From the model, two distinct edges fan out: threat_model_identifies_threatThreat ModelidentifiesThreathierarchy records the abuses imagined, and threat_model_surfaces_vulnerabilityThreat ModelsurfacesVulnerabilityhierarchy records the concrete weaknesses found, holding the design-time and discovered concerns apart. Governance closes the loop through security_policy_requires_threat_modelSecurity PolicyrequiresThreat Modelhierarchy, which encodes the rule that a system of a given sensitivity must be modelled before it ships. The structure mirrors Shostack's four questions: the model is the work, the connected threats and vulnerabilities are what could go wrong, and the controls hanging off them are the response.