14 STRIDE Framework

STRIDE is a memory aid that turns the open-ended question "what could go wrong here?" into six specific questions. It originated at Microsoft as a way to categorize threats, and each letter names a category of attack together with the security property that category violates.

The six categories are Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. The trick worth remembering is that each one is the opposite of a property you want: spoofing breaks authentication, tampering breaks integrity, repudiation breaks accountability, information disclosure breaks confidentiality, denial of service breaks availability, and elevation of privilege breaks authorization.

Think of a guard at a single doorway who works from a fixed checklist instead of a general feeling of unease. Is this person who they claim to be? Has the parcel been opened? Is there a record of who entered? Could someone read what is being carried? Can the door be jammed shut? Can a visitor reach a staff-only room? The same six questions, asked at one IoT boundary, are STRIDE.

For a gateway update boundary, the six prompts become concrete evidence questions. Spoofing asks whether the release service identity is trusted. Tampering asks whether the package is verified before install. Repudiation asks whether approval and install events are attributable. Information disclosure asks whether sensitive package metadata or keys are exposed. Denial of service asks what happens when update traffic stalls the gateway. Elevation of privilege asks whether a low-authority operator can trigger an update route.

This is the point where Six Questions Instead of Vague Worry must connect to observable behavior. Figure 14.1 makes that connection by depicting how “Each STRIDE category names one security property to ask about: authentication, integrity, non-repudiation, confidentiality, availability, or authorization” is explicit in the diagram.

+

The path through Figure 14.1 is meaningful because its labels are specific: Threat, Information Disclosure, then Information Assurance Properties. Their roles make visible how “Each STRIDE category names one security property to ask about: authentication, integrity, non-repudiation, confidentiality, availability, or authorization” is explicit in the diagram. That mechanism is the part of Six Questions Instead of Vague Worry the chapter continues to build upon.

The One-Minute View

Beginner Examples

Overview Knowledge Check

If you can match a scenario to the property it attacks, you have the core idea. Continue to Practitioner to walk a real boundary with evidence.

STRIDE earns its value when it is run as an evidence review, not a labeling exercise. The discipline is to choose a single boundary, name the asset or action that crosses it, state the current control claim, then ask each of the six prompts and attach the evidence that supports or refutes it.

The Review Sequence

The Evidence Map

Worked Boundary Review

A gateway receives telemetry from devices and forwards accepted readings to a service. The packet says devices authenticate to the gateway, but it does not show how accepted telemetry is validated or how command paths are kept separate from telemetry paths.

Inspect Figure 14.2 and ask which evidence must precede the accept-or-revise decision for one update boundary.

+

Follow Figure 14.2 from the gateway update boundary to the tampering prompt: is the package verified before installation? Signed-update verification and a rejected-change event are the requested evidence. Missing evidence creates a recorded threat and a matched integrity-control change, not an immediate acceptance. The one-changed-byte retest must show rejection while the safe version and local service remain available. Only that result supports accept; failure returns the record to revise. The decision is the end of the evidence chain.

Practitioner Knowledge Check

If you can run a boundary, attach evidence, and match a mitigation to the category, you can use STRIDE in practice. Continue to Under the Hood for how the categories relate and where they overlap.

The deeper layer explains why STRIDE is reliable and where it gets subtle. The reliability comes from a clean correspondence with security properties; the subtlety comes from overlap between categories and from the choice of how to apply the framework.

STRIDE as the Dual of the Properties You Want

STRIDE is not an arbitrary list. It is the set of violations of the properties a system tries to hold: authentication, integrity, non-repudiation, confidentiality, availability, and authorization. This pairing of a threat with its violated property is what makes a finding actionable. When you label a threat, you are also naming the property to defend, which in turn names the evidence to request and the class of mitigation that fits. A mismatch, such as proposing encryption (a confidentiality control) to fix an authorization gap, is a sign the category was mislabeled.

Why Repudiation Gets Forgotten

Repudiation is the category teams skip most often, because it is not about stopping an action but about being able to prove afterward who took it. For IoT this matters at command and update paths: if an actuator moved or firmware was approved, the system should be able to attribute that to an identity with a record that resists later tampering. Non-repudiation depends on integrity of the log itself, which is why repudiation and tampering frequently appear together.

Categories Overlap, and That Is Expected

A single weakness can sit under more than one category. An unauthenticated firmware update path is a Spoofing concern (who is pushing the image), a Tampering concern (was the image altered), and an Elevation of privilege concern (can a low-privilege actor change what runs). The categories are review prompts, not mutually exclusive bins. The goal is coverage of the properties, not a tidy one-threat-one-letter mapping.

STRIDE-per-Element and STRIDE-per-Interaction

There are two well-established ways to apply STRIDE to a data-flow diagram. STRIDE-per-element asks which categories are relevant to each element type: external entities are prone to spoofing and repudiation, data stores to tampering, information disclosure, and denial of service, processes to most categories, and data flows to tampering, disclosure, and denial of service. STRIDE-per-interaction instead walks each interaction across a trust boundary and asks the six prompts there. Per-element is faster and good for breadth; per-interaction is more precise at the boundaries that matter, which suits IoT command, telemetry, and update paths.

Common Pitfalls

Under-the-Hood Knowledge Check

At this depth, STRIDE is a disciplined way to test whether each security property survives at a boundary. It does not produce findings on its own; it produces good questions, and the value comes from answering each one with evidence, a matched mitigation, and a retest trigger.