Threat modelling: find the risks before you build

What threat modelling is

You describe the system, look at it the way an attacker would, ask where it is weakest, and write down what you will do about each weak spot. Because it works on a design rather than finished code, changes are cheap: moving a trust decision, or deciding not to store a piece of data, costs far less before the code exists than after.

At Asphaleia, every project begins with a threat review, and our discovery sprint includes a threat model of the core flows (see how we work and our security practices). Everyone on the team learns the method, because it is a habit and not a task for one specialist. For a shorter introduction, read the glossary entry or threat modelling for small teams.

The four questions

Four questions, popularised by Adam Shostack, give the work its shape:

1. What are we building? Draw it: the components, the data, the users, and where data moves.
2. What can go wrong? Walk through the drawing with a checklist such as STRIDE, or simply ask how you would attack it.
3. What are we going to do about it? For each threat, choose to mitigate it, eliminate it, transfer it or accept it.
4. Did we do a good enough job? Check that the flows that matter were covered, that every threat has an owner, and that the fixes work.

Keep a few minutes for the fourth question. It stops a session from ending with a diagram and no decisions.

Draw the system: data-flow diagrams and trust boundaries

A data-flow diagram (DFD) uses four shapes. External entities are the users and other systems outside your control. Processes are the parts of your code that do work. Data stores are databases, file storage and queues. Data flows are the arrows between them, labelled with what travels along each. Model one feature or flow at a time: a diagram nobody can read at a glance is too big.

Then draw trust boundaries: lines where the level of trust or control changes. Typical ones are:

• The internet and your servers, including a browser or mobile app on a user's device.
• An ordinary user and an administrator.
• One customer's data and another's, in a product that serves several customers.
• Your system and a third-party service, such as a payment provider or an email service.
• Your application and its database or file storage.

Most threats live where a flow crosses a boundary, because that is where data must be authenticated, validated or authorised. Mark the sensitive data too, such as personal data, credentials and payment details, and note where it is stored and sent.

Rule of thumb: if you cannot say who or what sits on each side of a line, and what is checked when data crosses it, you have found your first threat.

What can go wrong: STRIDE

STRIDE is a mnemonic for six kinds of threat. Each one breaks a security property.

Apply STRIDE to each element, not to the system as a whole. External entities raise mostly spoofing and accountability questions, data stores raise tampering, disclosure and denial of service, and processes can face all six. Other methods exist, such as attack trees, or LINDDUN for privacy, but for a small team STRIDE is enough to start.

A workshop format for a small team

A first session for one feature or flow takes 60 to 90 minutes with a handful of people: a developer who knows the code, the person who owns product decisions, someone who knows how the system is deployed and, if you have one, a person with security experience. A designer helps too, because many threats sit in user journeys such as account recovery and invitations.

1. Frame it (5 minutes). Name the feature and what you are protecting: customer data, money movement, admin access, reputation.
2. Draw it (15 to 20 minutes). Sketch the data-flow diagram on a whiteboard or in any diagramming tool, and mark the trust boundaries and the sensitive data.
3. Find threats (30 minutes). Walk every flow and boundary with STRIDE. Write each threat as a sentence: an attacker who has this access can do this, which causes this harm. Do not solve yet, just note ideas.
4. Decide (15 minutes). Rate each threat for likelihood and impact (high, medium or low), then choose to mitigate, eliminate, transfer or accept it. Accepting is fine when someone owns the decision in writing.
5. Close (10 minutes). Assign tickets, ask the fourth question, and list what you did not cover.

Turn findings into tickets

A threat model only changes the product when its output lands in the backlog. For each threat you decided to mitigate, create a ticket with the threat sentence, the chosen fix, an owner, a priority and a way to confirm it is done, ideally an automated test. For example: a user cannot fetch another organisation's invoices by changing the ID in the address, and a test proves it.

Tag these tickets so they can be found, link them to the diagram, and schedule them like any other work. Record accepted risks with an owner and a review date, so an accepted risk is a decision and not an oversight. Our guide to secure app development shows where these tickets fit in a delivery process.

When to repeat it

• A new feature that touches login, payments, personal data or file upload.
• A new integration, third-party service or data store.
• A change in architecture, hosting or who can access what.
• After a security incident, or after a test finding that shows an assumption was wrong.
• On a regular review of the core flows, for example once a year.

Update the existing diagram rather than starting again. A short check on each major change keeps the model true, and a model that no longer matches the system gives false comfort.

How it differs from a penetration test

You do not have to choose. A threat model tells a tester where to dig, and a penetration test shows whether your assumptions held. A secure code review then checks that the mitigations were built correctly.