13 STRIDE Framework

security

threats

iot

Keywords

STRIDE threat framework, IoT threat review, spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, trust boundary review

13.1 Start Simple: Ask Six Questions at One Boundary

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.

13.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.

STRIDE threat categories mapped to information-assurance properties: spoofing to authentication, tampering to integrity, repudiation to non-repudiation, disclosure to confidentiality, denial of service to availability, and elevation of privilege to authorization. — Figure 13.1: Each STRIDE category names one security property to ask about: authentication, integrity, non-repudiation, confidentiality, availability, or authorization.

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

A fake device pretending to be a trusted sensor is a Spoofing threat, because it attacks the authentication property.
A command message altered in transit is a Tampering threat, because it attacks integrity.
An admin action with no log that ties it to a person is a Repudiation threat, because no one can later prove who did it.

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.

13.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

Choose the boundary. For example, device to gateway, gateway to service, user to API, or the update-approval path.
Name the protected asset or action. A telemetry value, a command, a credential, a policy, or an update package.
State the control claim. What the design says should protect that path today.
Ask the six prompts. Record only the categories that genuinely apply to this path; do not force all six.
Attach evidence. Use config, logs, a rejected-action result, or a design note, not a general assurance.
Decide. Accept, revise, retest, or request more evidence, and record a retest trigger.

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.

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.

13.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

Labeling instead of reviewing. A category with no boundary, evidence gap, and mitigation is decoration.
Forcing all six. Some categories do not apply to a given path; recording a non-applicable category wastes review attention.
Reading authentication as authorization. Spoofing and elevation of privilege are different properties and need separate evidence.
Mismatched mitigations. The mitigation class must match the property the category attacks.
Ignoring repudiation. Skipping accountability leaves command and update actions unattributable.

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.

13.5 Summary

STRIDE turns “what could go wrong here?” into six concrete questions, one per security property.
The six categories map cleanly to authentication, integrity, accountability, confidentiality, availability, and authorization.
It is applied to one boundary at a time, and a category label only becomes a finding when it carries boundary, evidence, and mitigation.
Categories overlap by design; an unauthenticated update path can raise spoofing, tampering, and elevation of privilege at once.
STRIDE-per-element gives breadth, while STRIDE-per-interaction gives precision at the boundaries that matter most in IoT.
Every mitigation should match the property its category attacks, and every decision should carry a retest trigger.

Key Takeaway

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.