Threat modeling with STRIDE: a practical walkthrough

Threat modeling sounds like something only security architects do. In practice it is a structured conversation about a design, and STRIDE is the easiest way to keep that conversation complete. This guide shows how to run one, and what a GRC or audit person should look for in the result.

Start with four questions

The Threat Modeling Manifesto frames the work as four questions. Every method, STRIDE included, is a way of answering them:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

1. Draw a data flow diagram

Answer the first question with a simple data flow diagram (DFD). It has four kinds of element:

External entities: people or systems outside your control, such as a customer’s browser or a payment provider.
Processes: code that handles data, such as a web app or an API.
Data stores: databases, file shares, queues and logs.
Data flows: the arrows between them.

Then add trust boundaries: dashed lines wherever data crosses between zones you trust differently, such as internet to application, application to database, or your network to a supplier. Threats cluster at these crossings. The most common mistake is leaving things off the diagram, especially admin portals, support tools, logging and third-party scripts. Anything not drawn is not analysed.

2. Walk each element through STRIDE

STRIDE was created at Microsoft and names six threat types. Each one is the opposite of a security property:

Spoofing (breaks authentication): pretending to be another user or system.
Tampering (breaks integrity): changing data or code without permission.
Repudiation (breaks non-repudiation): denying an action because there is no reliable record.
Information disclosure (breaks confidentiality): exposing data to the wrong people.
Denial of service (breaks availability): making the system unusable.
Elevation of privilege (breaks authorisation): gaining rights you should not have.

The “STRIDE per element” approach asks which threat types apply to each element. As a rule of thumb, processes can face all six, data stores mostly face tampering, disclosure and denial of service (plus repudiation if they hold logs), and external entities mostly face spoofing and repudiation.

3. Rate the threats and choose mitigations

Write each threat as a short sentence (“an attacker uses leaked passwords against patient accounts”), rate it on likelihood and impact using your normal risk scale, and pick a response: mitigate, eliminate, transfer or accept. Good mitigations remove the cause. A firewall in front of vulnerable code, or a hard-to-guess admin URL, leaves the weakness in place.

4. Track it like any other risk

Each accepted or open threat belongs in a register with an owner and a date, and residual risk should be accepted by someone with the authority to do so. Re-run the model when the design changes significantly.

What an auditor checks

A current diagram that matches the real architecture, with trust boundaries.
Evidence that every element was considered, not only the obvious ones.
Threats rated consistently with the risk methodology.
Mitigations traced to tickets, tests or controls, and closed with evidence.
Sign-off and a trigger for re-modelling.