Threat modelling is the structured practice of asking what could go wrong with a system, who would make it go wrong and how, while the design can still be changed cheaply.
Our take. The cheapest security work on any project happens on a whiteboard before a line of code exists, and it is the work most teams skip because it produces no visible output. Four questions and an afternoon find more flaws than a penetration test of the finished system, and they find them while fixing them is free.
The four questions are the whole method. What are we building? Draw it: the components, the data, where it flows, where trust changes hands. What can go wrong? Walk the diagram and ask, at each arrow and each box, how an attacker would abuse it. What are we going to do about it? Decide, for each threat, whether to fix the design, add a control, accept it or move the risk elsewhere. Did we do a good job? Come back after building and check. Everything else in the discipline, the checklists and the diagrams and the tools, is scaffolding for those four.
STRIDE category
The question it prompts
A typical finding
Spoofing
Can someone pretend to be a user or a component?
A service that trusts any caller on the internal network
Tampering
Can data be altered in transit or at rest?
A price sent from the browser and trusted by the server
Repudiation
Can someone deny having done something?
No log of who approved a payment
Information disclosure
Can data leak to someone who should not see it?
An error message that prints the database query
Denial of service
Can the system be made unavailable?
An endpoint that does expensive work for unauthenticated callers
Elevation of privilege
Can someone gain rights they should not have?
An admin flag stored in the user's own session token
The checklist exists because the second question is hard to answer from a blank page. Given a diagram and six categories, a team that has never done this before will find real threats in the first session; without the categories they will find the two they already worried about and stop. The findings are then ranked by how bad and how likely, which is the risk assessment in miniature, and each becomes a design change, a control, or an accepted risk with a name against it. The practice is examined in the security architecture domains of the management credentials and in the secure-development sections of the developer ones, and it is among the rare security activities that cost nothing but attention.
In practice
A team designing a customer portal draws the diagram: browser, web application, an internal pricing service, a database. Walking the arrow from the browser to the application with the tampering question, someone notices the design sends the calculated price back from the browser at checkout, because it was convenient for the display logic. Under the spoofing question at the pricing service, someone else notices it accepts requests from any internal address. Both are design decisions that would have shipped. The first is fixed by recalculating the price on the server; the second by requiring the service to authenticate its callers. Neither fix costs anything before the code exists; both would have been a security finding, a patch and an apology afterwards.
Tampering at checkout: recalculate the price on the server and ignore the browser's figure.
Spoofing at the pricing service: require callers to authenticate, whatever network they arrive from.
Threat modelling is done on one system's design and asks how it could be attacked. Risk assessment is done across an organisation and asks what to spend on protecting what. The first feeds the second, and both use the same likelihood-and-impact judgement.
Threat modelling predicts weaknesses before a system exists; penetration testing demonstrates them after it does. The model tells the tester where to look, and the test tells the modeller what they missed.
Vulnerability management handles known flaws in software you run. Threat modelling finds flaws in the design of software you are building, which no scanner has a signature for.
Key takeaways
→Four questions: what are we building, what can go wrong, what will we do, did we do it well.
→A diagram and a checklist turn a blank page into findings in one afternoon.
→Fixes found in design are free; the same flaws found in production are patches and apologies.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
Get certified with Salesforce Data Cloud Consultant certification by practicing actual exam type questions. This Course…
Udemy
FAQ
Do I need a tool to threat model?
No. A whiteboard, the four questions and a checklist are the method. Tools help large teams keep models current and generate threats from diagrams, and they are worth it once the habit exists. They do not create the habit.
How long does a threat model take?
For a typical feature or service, an afternoon with the people who designed it. Longer sessions produce diminishing findings; more frequent short ones, one per significant design change, produce more. The first model of a whole system takes longer and is the one most worth doing.
Who should be in the room?
Whoever designed the system, whoever will run it, and at least one person who thinks like an attacker, which is a disposition rather than a job title. Security specialists help; a room of only security specialists models the wrong system, because they do not know how it actually works.
Sources
The primary text this definition rests on. Read it before you trust ours.
Shostack, A., Threat Modeling: Designing for Security (2014)
