16 Threat Modelling Worked Examples
16.1 Start Simple: Read One Narrow Record
Reject One Stale Command at a Named Boundary
Picture a greenhouse fan receiving yesterday’s valid start command after the service reconnects. The sender may be known and the message unchanged, yet acting now could be unsafe.
An actuator means a part that causes a physical action. Telemetry means measured status sent from a device for remote use. A worked threat record ties both to one asset, path, boundary, concern, and result.
Send one fresh command, then delay, repeat, change, and reroute it. Restart the receiver and remove remote service. Record identity, time, version, allowed and denied evidence, local safe state, residual risk, and retest trigger.
This runway does not list every possible attack. The deeper examples show how to scope a path, test a control, preserve evidence, bound a decision, and state what remains unproved.
Start with one short record instead of a complete system review. A telemetry identity tries to reach an actuator command route; the record names the scope, the asset, the boundary, the concern, the expected mitigation, the denied evidence, the decision, and the residual risk.
That small record is the point of the examples. Each worked case shows how to keep the claim bounded, how to avoid turning partial evidence into a broad security promise, and how to name the retest trigger that makes the record stale.
16.2 In 60 Seconds
Worked examples are useful when they show the reasoning record, not just the answer. A defensive IoT threat review should name the scope, asset, path, boundary, concern, mitigation, evidence, retest trigger, decision, and residual risk. The examples in this chapter keep the claims narrow so a reviewer can inspect the evidence and repeat the decision later.
16.3 Learning Objectives
By the end of this chapter, you will be able to:
- Read a worked threat review as a bounded evidence record.
- Identify the asset, path, boundary, and concern in an IoT example.
- Separate mitigation claims from evidence that supports those claims.
- Record residual risk without overstating what the example proves.
- Define retest triggers for future changes.
16.4 Minimum Viable Understanding
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.
16.5 Prerequisites
- IoT Threats Introduction: threat review goals, vocabulary, attack categories, and vulnerability classes.
- IoT Security Hands-On Labs: evidence records and retest triggers for lab-style review.
16.6 Worked Record Pattern
Use the same record shape for every example.
The choice described in Worked Record Pattern has consequences at several named checkpoints. Figure 16.1 gathers them into one view of how “IoT worked threat review record moving from scope through asset, path, boundary, concern, mitigation, evidence, decision, residual risk, and retest” is explicit in the diagram.
Study the named roles in Figure 16.1, beginning at Asset and testing the change introduced by Mitigate before checking on change. This sequence demonstrates “IoT worked threat review record moving from scope through asset, path, boundary, concern, mitigation, evidence, decision, residual risk, and retest” is explicit in the diagram. It gives the Worked Record Pattern discussion a concrete result to carry forward.
Read the pattern this way:
- Scope: the approved system, component, route, identity, or change under review.
- Asset: the data, command, device state, service, or safety property being protected.
- Path: the interface, route, identity, message flow, update path, or management path involved.
- Boundary: the trust, role, network, ownership, or process line crossed by the path.
- Concern: the security property that could fail in this scope.
- Mitigation: the control or process that should change the concern.
- Evidence: the inspectable record, configuration, test result, or log that supports the decision.
- Decision: confirmed, partial, rejected, or inconclusive.
- Residual risk: what remains, including assumptions and evidence gaps.
- Retest: the future change that can invalidate the record.
16.7 Example 1: Telemetry Identity and Command Boundary
Scope: one gateway rule set in a non-production review environment.
Asset: actuator command authority.
Path: telemetry identity attempts to reach a command route.
Boundary: telemetry roles and command roles are supposed to be separated.
Concern: a telemetry-only identity might be able to request an actuator action.
Mitigation under review:
- route policy requires a command role for actuator requests;
- telemetry identities are denied by default on command routes;
- denied decisions are logged with identity, route, and result fields.
Evidence inspected:
- route policy showing separate telemetry and command roles;
- denied-action result for a telemetry identity on the command route;
- monitoring record showing the denied decision.
Decision: confirmed for the reviewed gateway rule set.
Residual risk: this record does not prove every command path is covered. It only supports the reviewed route and identity pair.
Retest trigger: repeat the review after identity, route, gateway, broker, or monitoring changes.
16.8 Example 2: Update Acceptance Record
Scope: one update workflow in a sample device build.
Asset: trusted firmware state.
Path: update package from release storage to device install state.
Boundary: release process to device update process.
Concern: the device might accept an update without enough integrity and provenance evidence.
Mitigation under review:
- update manifest is checked before install;
- install state records success or rejection;
- recovery behavior is documented for failed updates.
Evidence inspected:
- release manifest record;
- device update-state log showing accepted and rejected outcomes;
- recovery note linked to failed update handling.
Decision: partial.
Residual risk: the example has update-state evidence, but the reviewed record does not include a recent recovery exercise. The decision should not claim full update resilience.
Mitigation follow-up: add recovery evidence to the update review record.
Retest trigger: repeat the review after signing, manifest, boot, rollback, or recovery changes.
16.9 Example 3: Management Access Boundary
Scope: one management interface in an approved test environment.
Asset: administrative configuration.
Path: operator session reaches management settings.
Boundary: operator role to administrative role.
Concern: a regular operator might be able to change administrative settings.
Mitigation under review:
- management settings require an administrative role;
- regular operator sessions can view only allowed status fields;
- denied changes are recorded for review.
Evidence inspected:
- role policy for operator and administrative permissions;
- rejected-change result from a regular operator session;
- log entry recording identity, setting group, and denied result.
Decision: confirmed for the reviewed management interface.
Residual risk: the record does not cover other administrative interfaces or emergency recovery access. Those require separate records.
Retest trigger: repeat the review after role, interface, recovery, or configuration changes.
16.11 Example 5: Malformed Payload Validation Gap
Scope: a sensor-to-service data path in a review scenario.
Asset: stored sensor reading and service processing path.
Path: sensor reading from device through gateway to service storage.
Boundary: gateway to service.
Concern: malformed payloads may reach the service before being validated or rejected.
Mitigation under review:
- message shape is validated at the gateway before forwarding;
- the service applies a second validation check before storage;
- rejected messages are logged with source and reason at each boundary.
Evidence inspected:
- gateway validation rule or configuration record;
- rejected-message log entry with source, reason, and timestamp;
- service-side validation configuration or policy record;
- retest note for malformed inputs after validation rule changes.
Decision: partial.
Residual risk: gateway authentication was confirmed, but validation evidence at both the gateway and service boundaries requires separate records. This example does not cover every message shape or processing path.
Retest trigger: repeat after gateway or service validation rule, message schema, or logging configuration changes.
16.13 Evidence Record
Each example can be checked with the same short evidence record.
This part of the narrative asks for an evidence-backed choice. Figure 16.2 provides the necessary view by showing how “IoT worked example evidence record linking scope, asset, path, boundary, concern, mitigation, inspectable evidence, decision, residual risk, and retest trigger” is explicit in the diagram.
Figure 16.2 rewards a label-first reading. Scope identifies one side of the problem, Mitigation names the controlling distinction, and tie to a future change reveals the resulting state. Together they show “IoT worked example evidence record linking scope, asset, path, boundary, concern, mitigation, inspectable evidence, decision, residual risk, and retest trigger” is explicit in the diagram and complete the role of Evidence Record in this chapter.
The record is intentionally small. It should be easy to compare the claim, evidence, and decision without reading a long narrative.
Use this check before accepting the worked example:
- The scope is narrow.
- The asset and path are named.
- The boundary is clear.
- The concern is phrased as a review question.
- The mitigation maps to the concern.
- The evidence is inspectable.
- The decision does not exceed the evidence.
- The residual risk is explicit.
- The retest trigger is specific.
16.14 Decision Outcomes
Worked examples should use plain decision language.
A label such as Decision Outcomes can sound complete while hiding important states or controls. Figure 16.3 opens the label up and shows how “Worked IoT threat example decision outcomes connecting confirmed, partial, rejected, and inconclusive records to residual risk and a retest trigger” is explicit in the diagram.
Use the three visible anchors in Figure 16.3: Decision Record, Residual Risk, and trigger names the change. Their order and contrast demonstrate “Worked IoT threat example decision outcomes connecting confirmed, partial, rejected, and inconclusive records to residual risk and a retest trigger” is explicit in the diagram. The narrative returns from that evidence to Decision Outcomes, where the same distinction governs the next choice.
Use these outcomes consistently:
- Confirmed: evidence supports the narrow claim in the reviewed scope.
- Partial: some evidence supports the claim, but a control, log, or test is missing.
- Rejected: evidence shows the concern is not present in the reviewed scope.
- Inconclusive: the record is not strong enough to accept or reject the claim.
Do not turn a confirmed local record into a broad security claim. The value of a worked example is the boundary around the decision.
16.15 Practical Review Checklist
Before a worked example is accepted, ask:
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.
16.16 Common Mistakes
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.
16.17 Knowledge Check
16.18 Matching Quiz
16.19 Ordering Quiz
16.20 Draw One Boundary Before Asking What Could Go Wrong
Threat modeling replaces guesswork about security with a repeatable process. You draw how data moves through the system, mark where trust changes, and then systematically ask what an attacker could do at each point. STRIDE gives the questions a fixed shape with six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each maps to a security property it breaks - authentication, integrity, non-repudiation, confidentiality, availability, and authorization respectively.
The map you reason over is a data-flow diagram: external entities, processes, data stores, and the flows between them, with trust boundaries drawn wherever data crosses from a less-trusted zone to a more-trusted one. Threats concentrate at those boundaries, because that is where an attacker's input first reaches something that trusts it. A flow that stays entirely inside one trust zone faces fewer crossing threats than one that traverses a boundary.
A small worked example makes the boundary idea concrete. Suppose a telemetry identity can send readings to a gateway, while actuator commands require a separate command role. The model should not claim that "commands are secure" in general. It should record one scoped question: can this telemetry identity reach this command route? The review then names the asset, the route, the telemetry-to-command boundary, the expected policy, the denied-action evidence, and the retest trigger for future route or identity changes. That record is narrow, but it is repeatable; another reviewer can inspect the same policy and logs without relying on memory or confidence.
Intuition only: walk each data flow that crosses a trust boundary and run the six STRIDE questions against it. The boundary crossings are where the interesting threats live.
The Six STRIDE Categories
Spoofing / Tampering
Pretending to be someone (breaks authentication) or altering data (breaks integrity).
Repudiation
Denying an action occurred, defeated by signed, logged, attributable records.
Information disclosure / DoS
Leaking data (breaks confidentiality) or denying service (breaks availability).
Elevation of privilege
Gaining rights beyond one's role, breaking authorization and least privilege.
Overview Knowledge Check
16.21 Run STRIDE Across a Boundary Flow
Take one data flow that crosses a trust boundary and apply all six STRIDE questions, naming a concrete threat and a mitigation for each. This turns a vague "is it secure?" into a checklist that is hard to skip.
Worked Example: The Sensor-To-Gateway Flow
A sensor (external entity) sends readings across a trust boundary to the gateway (process). Walking STRIDE:
- Spoofing: a rogue device impersonates the sensor. Mitigate with per-device authentication.
- Tampering: readings are altered in transit. Mitigate with a message authentication code or transport integrity.
- Repudiation: a device denies sending a command. Mitigate with signed, logged messages.
- Information disclosure: readings are eavesdropped. Mitigate with encryption of the flow.
- Denial of service: a flood of traffic overwhelms the gateway. Mitigate with rate limiting and input validation.
- Elevation of privilege: a sensor-level identity gains admin rights on the gateway. Mitigate with least privilege and strict authorization.
Six categories, six concrete threats, six mitigations - all from one boundary-crossing flow. Repeat for every crossing to build the model.
Keep the pass evidence-led. For the spoofing row, useful evidence is not "the design says devices authenticate." It is the configured per-device credential rule, an accepted message from the expected sensor identity, and a rejected message from a different identity trying the same route. For tampering, the record should point to the message authentication or transport-integrity setting and a failed altered-message test. For information disclosure, it should name the protected flow and the encryption control actually used there. If one row lacks evidence, mark that row partial instead of letting the stronger rows make the whole boundary look confirmed.
STRIDE Pass Ledger
Practitioner Knowledge Check
16.22 Rank Risk and Catch the Missing Flow
A STRIDE pass generates more threats than any team can fix at once, so the model is only useful if it prioritizes. Rank each threat by risk - roughly likelihood times impact - and address the highest first. This ordering often surprises: a dramatic-sounding threat with negligible likelihood can rank below a mundane one that is both easy to perform and damaging. Spoofing a sensor that drives an actuator may outrank eavesdropping on low-sensitivity telemetry, even though eavesdropping sounds worse in the abstract. The point of ranking is to spend limited effort where expected harm is greatest, not where the threat is most vivid.
The deeper hazard is that a threat model is only as complete as its diagram. Any data flow you fail to draw is a set of threats you never assessed, and the most damaging findings frequently live in the flows teams forget: a firmware update channel, a debug or maintenance port, a "temporary" cloud API, or a third-party analytics feed. If the over-the-air update path is missing from the diagram, no STRIDE question is ever asked about it, and a tampering threat on that path - malicious firmware - goes unexamined. The disciplines that follow are to enumerate every flow including the inconvenient ones, state the assumed attacker capability so mitigations are judged against the right adversary, and revisit the model whenever the system's flows change.
Completeness is also a change-control problem. A diagram that was accurate before deployment can become stale when the team adds a mobile maintenance app, a new broker bridge, or a recovery endpoint for field service. The review record should therefore include a retest trigger that names the change that invalidates the model: new identity type, new route, new update mechanism, changed logging, or changed recovery behavior. When that trigger fires, the team does not need to re-run every old argument from scratch; it starts with the affected flows, asks the STRIDE questions again, and updates the residual-risk note where evidence is still missing.
Turning A Model Into Action
Rank by risk
Likelihood times impact orders the fixes; vivid but unlikely threats can wait behind mundane likely ones.
Complete the diagram
A missing flow is an unassessed threat. Update, firmware, and debug channels must all appear.
State the attacker
Mitigations are only valid against the assumed capability; name it, from eavesdropper to physical access.
Revisit on change
New flows bring new threats, so re-run the model when the architecture changes.
Under-the-Hood Knowledge Check
16.23 Summary
Worked examples should make the review trail visible. The strongest examples keep the scope narrow, name the asset and path, identify the boundary, state a defensible concern, map mitigation to evidence, and record a bounded decision. Residual risk and retest triggers make the record usable after the system changes.
16.24 Key Takeaway
Worked examples matter because they show how raw threat ideas become prioritized risks, mitigations, and reviewable evidence.
16.25 Concept Relationships
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.
16.26 What’s Next
- IoT Threats Introduction: revisit the core vocabulary behind the examples.