What Is Threat Modelling? Thinking Like an Attacker, on Purpose

When you lock your front door on the way out, you are doing a tiny bit of threat modelling. Somewhere in the back of your mind you have asked "what could go wrong while I am away", pictured someone wandering in, and decided the lock is worth the two seconds it takes. You did not draw a diagram or fill in a form. You just thought about the bad thing before it happened and did something cheap to prevent it. That instinct, made a little more deliberate and pointed at the systems we build, is the whole idea.

Threat modelling sounds like a heavyweight enterprise process with committees and thick documents, but at heart it is a habit anyone can build: stopping to ask "what could go wrong here, and what should we do about it" before something goes wrong on its own. Done early, it is one of the cheapest ways to avoid expensive mistakes, because a problem caught while you are sketching an idea costs a five minute rethink, while the same problem caught after launch can cost a breach, a weekend of firefighting, and a very awkward apology. This is a plain introduction, no committees required.

The four questions

The security researcher Adam Shostack boils threat modelling down to four questions, and they really are all you need to start. There is no secret fifth question hiding behind a paywall.

1. What are we working on? Understand the system. What are the pieces, where does data flow, and what are you actually protecting? You cannot defend something you have not looked at clearly.
2. What can go wrong? Think like an attacker. Where could someone interfere, steal, snoop, or break something? This is the imaginative, slightly paranoid part, and it is the heart of the exercise.
3. What are we going to do about it? For each realistic problem, decide on a defence, or make a conscious decision to accept the risk and move on. "We will accept this" is a legitimate answer, as long as it is a choice rather than an accident.
4. Did we do a good job? Review. Did the model match reality, and what did you miss? Threat modelling is never finished in one sitting, because systems change and so do attackers.

Build a picture  ->  find what can go wrong  ->  decide what to do  ->  check your work

That loop, repeated whenever something meaningful changes, is threat modelling. Everything else you will ever read about the topic, every fancy framework and tool, is really just help for answering question two more thoroughly.

Drawing the picture

You cannot threat model what you cannot see, so most sessions start with a simple diagram of the system. This does not need to be beautiful. A whiteboard sketch or a few boxes and arrows on paper is completely fine, and often better than a polished diagram because you will happily scribble on it.

The diagram shows three things: the components (the boxes, such as a web browser, a server, a database), how data moves between them (the arrows, such as "user submits a form"), and crucially the trust boundaries. A trust boundary is a line where data crosses from something you control to something you do not, or from less trusted to more trusted. The edge of your property, in the house version. The moment a stranger's input reaches your code, in the software version.

Here is a tiny example written out in text:

[ User's browser ]  --submits login-->  [ Your web server ]  --queries-->  [ Database ]
                  ^                                          ^
             trust boundary                            trust boundary
        (anyone on the internet)                (sensitive data lives here)

Marking those boundaries is the single most valuable thing you do, because it tells you exactly where to point your suspicion.

A framework for "what can go wrong"

Staring at a diagram and asking "what could go wrong" often produces a blank stare, especially when you are new. Our brains are not naturally good at listing every way something could be abused. So security people use checklists to make question two systematic, and the most common one is STRIDE.

STRIDE is six categories of threat to run through for each part of the system. The name is just the first letter of each category:

• Spoofing: pretending to be someone or something else, like logging in as another user by stealing their password.
• Tampering: changing data or code without authorisation, like altering a price or a stored record.
• Repudiation: denying you did something, with no record to prove otherwise. If there is no reliable log, a user (or an attacker) can plausibly claim "that was not me".
• Information disclosure: leaking data to those who should not see it, like exposing another customer's details.
• Denial of service: making the system unavailable, like flooding it with traffic so real users cannot get in.
• Elevation of privilege: gaining more access than you should have, like a normal user quietly becoming an administrator.

The trick is to walk each component and each arrow in your diagram through all six, one at a time. For that login arrow above you would ask: could someone spoof another user here? Could they tamper with what is submitted? Is there a log so nobody can repudiate it? And so on. Boredom is a feature. The checklist catches the threats your imagination would have skipped past.

Notice how neatly STRIDE maps onto the CIA triad, the three properties security protects. Tampering breaks integrity. Information disclosure breaks confidentiality. Denial of service breaks availability. The other three (spoofing, repudiation, and elevation of privilege) are usually the routes attackers take to reach those harms. Seeing that link is reassuring, because it shows these frameworks are not random. They are different views of the same small set of core ideas.

From "what can go wrong" to "what will we do"

Once you have a list of things that could go wrong, question three sorts them out. You will rarely fix everything, and you do not need to. This is where the language of threat, vulnerability, and risk earns its keep, because it lets you rank problems by how likely they are and how much damage they would cause, rather than treating every item as equally urgent.

For each threat you have roughly four honest choices:

Mitigate  ->  add a defence that reduces the risk (the usual choice)
Accept    ->  decide the risk is small enough to live with, on purpose
Transfer  ->  shift the risk elsewhere, for example with insurance or a vendor
Avoid     ->  drop the risky feature or design entirely

Writing down which choice you made, and why, is quietly valuable. Months later when someone asks "why did we not protect against this", the answer "we considered it and consciously accepted the risk because of X" is a world away from "we never thought about it".

You do not need to be an expert to start

Here is the most important thing for a beginner to hear. Threat modelling is not reserved for security teams with special training. A developer sketching a new feature and pausing to ask "what if someone sends something malicious here" is threat modelling. A student building a hobby project who wonders "what happens if the input is a million characters long" is threat modelling. The instinct is more important than the vocabulary.

The value is in doing it early, while a problem is still a five minute design change rather than a three in the morning incident. So keep it lightweight and frequent rather than heavy and rare. A quick fifteen minute chat at the whiteboard before you build something will catch more real problems than an exhaustive review you keep putting off because it feels too big. Small and often beats perfect and never, every time.

The takeaway

Threat modelling is the deliberate habit of asking what could go wrong before it does, structured around four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job. Draw the system, pay special attention to trust boundaries, and use a checklist like STRIDE to make the risks visible instead of leaving them to your imagination. Then rank what you find by risk and decide honestly what to fix, accept, transfer, or avoid. Do it early and often, keep it light, and you will catch problems while they are still cheap to fix. That is the entire game, and you can start today.