Threat Model
A threat model records what is being protected, what could go wrong, and how those risks will be treated. NIST describes threat modeling as risk assessment that represents both attack and defense aspects of an entity such as data, an application, a host, or an environment. The term is used for the maintained artifact as well as the modeling process.
State the scope and assumptions behind the assessment. Prioritize risks and document treatment decisions, including unresolved decisions and accepted residual risk where applicable. A list of threats alone does not explain how the system will address them.
Questions the model should answer
The clearest framing of the process is a set of questions it has to answer. OWASP’s guidance, quoting the Threat Modeling Manifesto, puts them as: “What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?“
Each question corresponds to a part of the artifact, and knowing which part is thin tells you what the exercise actually produced.
| Question | What the artifact holds | Thin when |
|---|---|---|
| What are we working on? | The assets, the components, and the trust boundaries between them — including boundaries inside a single service | It is a deployment diagram. Boxes and arrows are not boundaries; a boundary is where the assumptions change |
| What can go wrong? | Paths from an attacker’s position to an asset, described as sequences of crossings rather than as adjectives | Entries read SQL injection rather than unauthenticated caller reaches the reporting endpoint, which builds a query from a parameter |
| What are we going to do about it? | Per path: the chosen treatment, its assumptions, and evidence. Include accepted residual risk and the authority and rationale for acceptance where applicable | Treatment labels have no supporting decision or evidence. Record accepted residual risk when it exists; an empty acceptance list alone does not prove omission |
| Did we do a good enough job? | Coverage review and evidence that agreed mitigations were implemented and reduce risk | Coverage or mitigation effectiveness remains unexamined |
Review both coverage and mitigation effectiveness. Compare modeled paths with incidents in comparable systems and examine them from specific attacker positions: a low-privilege account, a compromised dependency, or physical access to a laptop. Then check that agreed mitigations exist, operate within their intended scope, and reduce risk sufficiently. OWASP includes stakeholder review and testing of security measures in this feedback step. Finding more paths and demonstrating an implemented defense are different parts of the assessment.
Structured prompts help with the second question
STRIDE provides prompts for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Applying them to components, flows, and boundary crossings can make a discussion more systematic than relying only on what participants recall.
These prompts do not prove completeness, but neither do they exclude insider misuse or business-logic flaws. A permitted user leaking data can surface under information disclosure; a harmful transaction sequence can surface under tampering. Ask separately how legitimate authority could be abused and which sequences violate business rules, since a team can miss those scenarios while mechanically completing a category list.
Maintain the model and show its scope
OWASP recommends maintaining and refining the model alongside the system as part of ordinary development. Attach review to decisions and changes that can affect assets, boundaries, threats, or defenses.
An older model can retain useful conclusions about unchanged parts of a system. It becomes misleading when invalidated assumptions or unexamined changes are treated as current evidence. Record the version, review date, system scope, and unresolved changes. As with dependency records and blast radius assessments, visible limits help readers decide which conclusions need confirmation.
A new integration, data store, or caller should trigger a check for changes to trust boundaries and attack paths; it does not necessarily create a new boundary. Update affected sections and retain the detail required to assess them. An overview can link to service or subsystem models and multiple data-flow diagrams when the system’s scale requires it. A fixed one-page limit would hide that complexity rather than resolve it.
How the model connects to the asset inventory, the boundary count, and the control types is worked through in The Control Everyone Passed.
References
- NIST Computer Security Resource Center Glossary, threat modeling
- OWASP Cheat Sheet Series, Threat Modeling
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.