STRIDE Threat Modelling Methodology

Before STRIDE, threat modelling tended to be an unstructured brainstorming exercise: gather some engineers in a room, ask what could go wrong, and write down whatever comes up. That approach is heavily dependent on who's in the room and what attacks they happen to remember from the last incident. STRIDE fixes this by giving reviewers a fixed set of threat categories to walk through for every element in a system — every process, every data store, every data flow, every external entity — so coverage doesn't depend on individual recall.

Each letter in STRIDE corresponds to the violation of a specific security property. That mapping is what makes the mnemonic useful beyond just being easy to remember: it tells you which control category to reach for once a threat is identified.

STRIDE maps threats to the security property they violate. Authentication stops spoofing, integrity controls stop tampering, non-repudiation mechanisms stop repudiation, confidentiality controls stop information disclosure, availability controls stop denial of service, and authorisation stops elevation of privilege.

STRIDE is normally applied against a data flow diagram (DFD) rather than against the system as a whole, because a DFD forces you to enumerate the discrete elements — processes, data stores, data flows, and external entities — that actually need threats considered against them. The classic approach, STRIDE-per-element, walks each element and asks which of the six categories apply to it. Not every category applies to every element type: a data store, for instance, is rarely a spoofing target the way a process is, but it's very much a tampering and information disclosure target.

A lighter-weight variant, STRIDE-per-interaction, focuses on the interactions between elements (the arrows on the diagram) rather than the elements themselves. This tends to produce a shorter, more targeted list of threats, at the cost of occasionally missing threats that are properties of a component rather than of an interaction — for example, a data store's encryption-at-rest posture.

• •Draw or obtain an accurate DFD, including trust boundaries — STRIDE without a diagram degenerates back into unstructured brainstorming.
• •For each process: consider spoofing, tampering, repudiation, information disclosure, DoS, and elevation of privilege.
• •For each data store: consider tampering, information disclosure, DoS, and repudiation (if the store lacks access logging).
• •For each data flow: consider tampering, information disclosure, and DoS.
• •For each external entity: consider spoofing and repudiation, since you generally don't control their internals.
• •Record every threat found, even ones you plan to accept — an explicit risk acceptance is very different from a threat nobody noticed.

Take a simple web login flow: browser sends credentials over TLS to an API server, which checks them against a user database and issues a session token. Running STRIDE against this produces threats like: an attacker spoofing the login endpoint via a phishing domain (Spoofing); a man-in-the-middle downgrading TLS to intercept credentials (Tampering); a user later denying they authorised a password change with no audit trail to disprove it (Repudiation); verbose "invalid password" vs "user not found" error messages enabling account enumeration (Information Disclosure); an attacker submitting large volumes of login attempts to exhaust the auth service (Denial of Service); and a logic flaw in session issuance that lets a standard user obtain an admin-scoped token (Elevation of Privilege).

Each of these threats then gets a mitigation, an owner, and — where mitigation isn't immediately feasible — an explicit, time-bound risk acceptance signed off by someone with the authority to accept it.

STRIDE is methodology, not tooling, but several tools operationalise it. Microsoft's own Threat Modeling Tool auto-generates STRIDE-per-element threat lists from a drawn DFD. OWASP Threat Dragon is an open-source equivalent with similar DFD-driven STRIDE generation. Both are useful for consistency and for producing a documented artifact reviewers can sign off on, but neither replaces the judgement needed to decide which generated threats are actually relevant to your system and which are noise.

STRIDE is strongest at generating a broad, structured list of technical threats against a known architecture. It's weaker at prioritisation — it doesn't inherently tell you which threats matter most for your business context, which is where risk-centric methodologies like PASTA add value on top. It also assumes you have an accurate architecture diagram to work from; a stale or oversimplified DFD will produce a stale or oversimplified threat list. Finally, STRIDE was designed with fairly traditional client-server and web architectures in mind, so applying it to newer architectural styles (event-driven microservices, serverless, ML pipelines) sometimes requires adapting the element types you're modelling against.

In practice, most mature threat modelling programmes use STRIDE as the enumeration technique inside a broader process that also handles scoping, prioritisation, and remediation tracking — it's a generator of candidate threats, not a complete programme on its own.