STRIDE Threat Model Explained: The Six Categories and What They Break for CISSP

STRIDE is a threat classification framework from Microsoft that sorts threats into six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each one is the mirror image of a security property it breaks, so naming the category points straight at the control that defends it.

That mirror is what makes the model usable under exam pressure, and it is why STRIDE is the methodology in threat modeling most worth knowing concretely. The framework is not a list of attacks to memorise. It is six threat categories applied systematically across a design, with each element taking the subset assigned to its type, and its value lies in that discipline rather than in stopping at the first threat that comes to mind.

One thing to fix early: STRIDE finds threats, it does not rank them. A threat modeling exercise often ends with a prioritised list, but the prioritising is a separate step using a separate method.

What is the STRIDE threat model?

STRIDE was developed at Microsoft and became part of its Security Development Lifecycle, the process that pushed security analysis into design rather than leaving it to testing. The acronym names six threat categories, and the method is to walk a design and ask, for each component, which of the six could apply and what would mitigate it.

Threat modeling sits in Domain 1 of the published ISC2 exam outline, under objective 1.10, threat modeling concepts and methodologies. It also reappears as a secure design principle in Domain 3, because a model built during design has to be carried through the rest of the lifecycle to stay useful.

The reason a framework is needed at all is that unstructured threat brainstorming is unreliable. A team asked “what could go wrong here” will produce the threats it happens to think of, weighted toward whatever it saw most recently. A team that walks each element against the categories assigned to its type produces more systematic coverage, because the questions do not depend on what anyone happens to remember. It still does not guarantee a complete list: business logic flaws and novel attacks can sit outside every category.

The six STRIDE categories and the properties they break

Each category attacks exactly one property. This mapping is the part worth learning cold, in both directions, since a question may give either side and ask for the other.

Three of these pairs are easy to blur, and the distinctions are worth stating plainly.

Tampering, information disclosure and repudiation all involve data and are separated by what happens to it. Tampering changes data. Information disclosure reads data. Repudiation is about an action that cannot be proved, which usually means the record of it was never made or was removed. Hold the distinction between changing, reading and denying, and a large family of questions becomes routine.

Spoofing and elevation of privilege both end with an attacker holding access they should not have, and are separated by how. Spoofing means becoming someone else, which is why it breaks authentication and is countered by strong credentials and mutual authentication. Elevation of privilege means staying yourself and acquiring more rights than you were granted, which is why it breaks authorisation and is countered by least privilege and by careful checks on what code is allowed to do.

Repudiation and tampering sit closest together when logs are involved. If a user can delete their own entries from an audit log, both apply in a loose sense, but the harm STRIDE points at is the lost ability to hold that user to their action. That is repudiation, and the property is non-repudiation, typically defended with append-only logging, a digital signature over log records, or shipping events to a SIEM the acting user cannot reach.

How STRIDE is applied element by element

STRIDE is not applied to a system as a whole. It is applied to each element of a data flow diagram, which is a picture of the system’s components, the data moving between them, and the boundaries where the level of trust changes.

Drawing that diagram is not optional preparation, it is the first half of the method. Skip it and the analysis floats free of the architecture it is meant to protect, producing threats that sound plausible but are not attached to anything the team can actually change.

Trust boundaries are where you start

A trust boundary is a line on the diagram where the level of trust changes, for example between the public internet and an internal network. Crossings earn particular scrutiny, because a crossing is where data arrives from somewhere less trusted, or leaves for somewhere less protected, and where assumptions that held inside one zone stop holding.

Working the crossings first is a practical ordering rather than a rule that the rest of the diagram can be skipped. Every element gets its applicable questions eventually; the crossings are simply where two elements with different trust assumptions meet.

The shape of an element changes the questions

Data flow diagrams use a small vocabulary of shapes, and the shape matters because not every category can apply to every kind of element. In the STRIDE-per-element form of the method, each element type carries its own subset of the six.

The row that matters most is the process. In this matrix elevation of privilege is assigned to processes rather than to data flows, because gaining rights beyond those granted is a property of something that executes, not of traffic in motion. A flaw in a web tier that lets a request run with more authority than it should carry belongs to the process that runs it, not to the line on the diagram, even though that line may be what carries the request doing the exploiting.

The repudiation row carries a similar caveat. Data stores take T, I and D, with repudiation added where the store is an audit log, since a log that can be altered or emptied is what makes an action deniable. Treat these subsets as the convention that makes the walk systematic rather than as a rule about what is possible, and the point of them stands: keeping each threat on the element that can actually suffer it is what stops a model becoming letters scattered over a picture.

Worked example: six threats on one small web application

Take the data flow diagram from earlier. A user with a browser sits in the untrusted internet zone. A web application sits in the semi-trusted web tier. A customer database and an audit log sit in the trusted internal zone. Three flows connect them, and three of those flows cross a boundary.

At the front door, where the user reaches the application, examining the crossing means examining the elements at each end of it. Spoofing belongs to the user, the external entity an attacker would impersonate, with password guessing as the everyday example. Denial of service belongs to the request flow and to the application process behind it, either of which can be flooded until legitimate users cannot reach the service. One crossing, two entirely different classes of threat sitting on two different elements, which is why the walk asks about elements rather than about lines.

At the database crossing, an attacker who can modify a record while it is in transit between the application and the database is tampering, and the property broken is integrity. The near misses are worth naming: reading that record instead of changing it would be information disclosure, and denying an action that has no proof it occurred would be repudiation.

On the web application itself, elevation of privilege applies, because the process is the thing that can execute with more authority than intended. Note that this flag sits on the circle rather than on any of the lines.

At the audit log, two more categories apply, and they sit on different elements again. Information disclosure applies to the flow and to the store, because a log of who did what to which record is itself worth reading, which makes an unprotected audit log a confidentiality problem as well as an integrity control. Repudiation belongs to the log store and to the application that writes to it: an event that is never recorded, or that can be removed afterwards, leaves an action that can later be denied with no evidence to the contrary. Note that the failure of the flow itself, an event altered or dropped in transit, is tampering or denial of service against that flow, and repudiation is the consequence rather than the category.

Six threats on a diagram this small should be read as a teaching minimum rather than a realistic yield. A thorough pass usually surfaces several threats per element, and the point of the exercise is coverage rather than a target number.

When threat modeling happens, and why design time is cheapest

Threat modeling can be done proactively, during design, or reactively, once a system is live. Both are legitimate and the goal is the same, but the economics are not close.

A flaw caught on a whiteboard is changed by redrawing a diagram. The same flaw caught after launch may mean re-architecting, repurchasing hardware or rewriting code. This is why threat modeling is treated as a design-phase activity in the systems development lifecycle and why DevSecOps practice pushes it earlier still rather than later.

The model also has to be maintained. A system changes, and a threat model that is produced once and filed quietly stops describing the thing it was meant to protect.

STRIDE, DREAD and PASTA: what each model is for

The distinction that matters here is between models that do genuinely different jobs. STRIDE enumerates and categorises. DREAD scores and ranks. PASTA is a seven-step, risk-centric methodology that ties the analysis to business objectives.

DREAD rates each threat for Damage, Reproducibility, Exploitability, Affected users and Discoverability, on a scale the team agrees before it starts, then sums or averages the five into a single rating. The structure is the strength: common criteria make assessments more systematic and comparable than unaided judgement. The scores are the weakness, since two assessors can rate the same threat differently, so they are best read as a way of comparing threats rather than as objective measurements.

DREAD is not a required second half of STRIDE, and it is not the only way to rank a list: any agreed risk-assessment method can do that work, and Microsoft itself later moved away from numeric DREAD scoring because consistency between assessors proved hard. What holds is the shape of the sequence. A scenario that hands you a finished list of threats and asks what comes next is pointing at scoring of some kind, since re-running STRIDE would only repeat work already done and treating every threat as equally urgent abandons risk-based prioritisation altogether.

Where STRIDE stops

STRIDE is strong at coverage and silent on almost everything else, and the honest limitations are worth knowing as well as the strengths.

It does not rank, which is the limitation the DREAD pairing exists to answer. It does not tell you whether a threat is likely, only that it is possible for that element type. It says nothing about the cost of a control, so it cannot by itself justify spending. And it is software and design focused, which makes it a poor fit for questions about enterprise-wide organisational risk, where a collaborative framework aimed at the whole organisation is the better answer.

It is also not a test. STRIDE reasons about a design, which is what separates it from a vulnerability assessment that scans a running system, or from static application security testing that inspects real code. The two answer different questions rather than belonging to different halves of the lifecycle: a model can be built for a system that already exists, and a scenario asking what to do before any code exists has only modeling available to it.

Conclusion

STRIDE earns its place because it converts an open-ended question into six closed ones, and because each of those six points at a property and therefore at a control. Learn the mapping in both directions, remember that the method is applied element by element across a data flow diagram rather than to a system in the abstract, and keep the enumerate step separate from the rank step in your head.

The single most useful sentence to carry is that the model is a picture before it is a list. Skip the diagram and the analysis floats free of the architecture; produce the list and then stop, and nothing gets prioritised. Both halves have to happen.

Distinctions this fine are where near misses happen on exam day. Our CISSP practice tests drill STRIDE against DREAD, category against property, and dozens of similar pairings until choosing between them is automatic.

Quick reference for the CISSP exam

The mapping, in one line

Spoofing to authentication, Tampering to integrity, Repudiation to non-repudiation, Information disclosure to confidentiality, Denial of service to availability, Elevation of privilege to authorisation.

The discriminators

• Changing, reading or denying? Tampering changes data, information disclosure reads it, repudiation denies an action that cannot be proved.
• Becoming someone else, or acquiring more rights? Spoofing is impersonation and breaks authentication. Elevation of privilege keeps the identity and adds rights, and breaks authorisation.
• Finding or ranking? STRIDE finds and categorises. DREAD scores and ranks. A question about what to do with a completed list is likely pointing at a scoring step.
• Modeling or testing? Threat modeling reasons about a design and can be done at any point. A vulnerability assessment or a code scan inspects an implementation for weaknesses.

Facts worth memorising

• STRIDE comes from Microsoft and is applied element by element across a data flow diagram.
• In the STRIDE-per-element matrix, elevation of privilege is assigned to processes, not to data flows.
• A trust boundary is a line where the level of trust changes, and the crossings are a useful place to begin, though every applicable element is examined in the end.
• DREAD is Damage, Reproducibility, Exploitability, Affected users, Discoverability, and its scores are subjective.
• Proactive modeling during design is cheaper than reactive modeling after launch, because the fix is a redrawn diagram rather than rework.