14 STRIDE Framework
14.1 Start Simple: Ask Six Questions at One Boundary
Threat-Check One Update Crossing
Picture a field unit receiving a software update through a site bridge. The useful review does not say the whole system is risky. It asks six exact questions where the update crosses into install state.
Denial of service means preventing a system from doing useful work for its intended users. A gateway means a device or service that joins two system paths. Telemetry means measurements and status sent for remote use.
Try the wrong sender, one changed byte, a missing approval record, an exposed secret, a stalled transfer, and a low-authority install request. Record which control rejects each case and whether the unit keeps a safe version and local service.
This runway does not prove that six labels find every threat. The deeper sections map spoofing, tampering, repudiation, disclosure, service denial, and excess privilege to boundaries, controls, and evidence.
STRIDE is easiest when it is not aimed at the whole system. Pick one boundary first: a device sending telemetry to a gateway, an operator changing configuration, or an update package crossing into install state. Then ask the six questions at that crossing.
The beginner move is to translate each letter into evidence. Who might be spoofed, what could be tampered with, what action might lack a record, what data could leak, what service could be denied, and what role could gain more authority? Each answer should point to a mitigation and a record that can be inspected.
14.2 Six Questions Instead of Vague Worry
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.
If you only need the intuition, this layer is enough: pick one place where data or a command crosses a boundary, then walk the six STRIDE questions in order. Each question you cannot answer with evidence is a threat worth recording.
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
A category names a property
Every STRIDE letter is the violation of one property you want, which is why it points straight at the evidence to ask for.
It runs on a boundary
STRIDE is applied to a specific crossing point, not to a whole system at once. Scope first, then ask the six questions.
A label is not a finding
Writing "S: spoofing" is a sticky note. A finding names the boundary, the missing evidence, and the mitigation.
Beginner Examples
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
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.
14.3 Walk One 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
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led 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.
Evidence present
Spoofing has device authentication evidence at enrollment, so the identity claim has some support.
Evidence gaps
Tampering lacks validation for unexpected message shape; Repudiation lacks accepted-and-rejected event records; Elevation of privilege lacks a denied-command result for telemetry-only identities.
Decision
Revise the claim. It cannot be accepted until validation, attributable logging, and command-authorization evidence are attached.
The surrounding prose sets a requirement; Figure 14.2 shows its working parts. Study it to determine whether “The decision comes last: boundary and prompt lead to evidence, then a matched mitigation and retest, then accept or revise” is explicit in the diagram.
Begin the technical reading of Figure 14.2 with Prompt. Next determine how control change alters the case, then verify the end condition at accept or revise. This is the visible basis for “The decision comes last: boundary and prompt lead to evidence, then a matched mitigation and retest, then accept or revise” is explicit in the diagram, and it carries Decision into the chapter’s evidence trail.
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.
14.4 Properties, Overlap, and Application Style
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 duality 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 and information disclosure, 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
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
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.
14.5 Summary
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter’s evidence-led review sequence.
STRIDE is a prompt for systematic thinking: map spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege to real assets and boundaries, then defend each with matched evidence and mitigation.
14.6 See Also
Threat Modelling and Mitigation
Turn STRIDE prompts into scoped findings, mitigation records, and retest evidence.
OWASP IoT Top 10
Compare STRIDE categories with a vulnerability-oriented list of common IoT weaknesses.
IoT Security Fundamentals
Revisit the assets, boundaries, and evidence that every STRIDE prompt depends on.