Security: Threats & Defense · Study deck

Threat Modelling Worked Examples

Picture a greenhouse fan receiving yesterday's valid start command after the service reconnects.

Shield Shelly is your guide for this deck.

worked-examplesthreat-reviewevidence-records

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: 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.
Explain: 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.
Identify the asset, path, boundary, and concern in an IoT example.

Major section

Start Simple: Read One Narrow Record

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.
This runway does not list every possible attack.
That small record is the point of the examples.

Major section

Example 1: Telemetry Identity and Command Boundary

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.
Residual risk: this record does not prove every command path is covered.
It only supports the reviewed route and identity pair.

Major section

Example 6: Update Deployment Authorization Gap

Concern: package signing does not prove that deployment was approved by an authorized role or that rollback behavior is reviewed.

Residual risk: package integrity evidence alone does not cover deployment authorization or recovery state.
Both require separate review records.
This example does not address every update path or device type.

Worked IoT threat example decision outcomes connecting confirmed, partial, rejected, and inconclusive records to residual risk and a retest trigger.

Major section

Evidence Record

Each example can be checked with the same short evidence record.

Scope identifies one side of the problem: Mitigation names the controlling distinction, and tie to a future change reveals the resulting state.
The record is intentionally small.
It should be easy to compare the claim, evidence, and decision without reading a long narrative.

IoT worked example evidence record linking scope, asset, path, boundary, concern, mitigation, inspectable evidence, decision, residual risk, and retest trigger.

Major section

Draw One Boundary Before Asking What Could Go Wrong

You draw how data moves through the system, mark where trust changes, and then systematically ask what an attacker could do at each point.

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.
The model should not claim that "commands are secure" in general.
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.

Worked threat review record flowing from scope through evidence, decision, residual risk, and retest.

Major section

Draw One Boundary Before Asking What Could Go Wrong (continued)

That record is narrow, but it is repeatable; another reviewer can inspect the same policy and logs without relying on memory or confidence.

The boundary crossings are where the interesting threats live.
The Six STRIDE CategoriesSpoofing / Tampering Pretending to be someone (breaks authentication) or altering data (breaks integrity).
RepudiationDenying an action occurred, defeated by signed, logged, attributable records.

Major section

Run STRIDE Across a Boundary Flow

This turns a vague "is it secure?" into a checklist that is hard to skip.

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.

Major section

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.

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.
Completeness is also a change-control problem.
Spoofing a sensor that drives an actuator may outrank eavesdropping on low-sensitivity telemetry, even though eavesdropping sounds worse in the abstract.

Major section

Rank Risk and Catch the Missing Flow (continued)

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

Deck summary

Key takeaways

The sender may be known and the message unchanged, yet acting now could be unsafe.

Path: telemetry identity attempts to reach a command route.
Concern: package signing does not prove that deployment was approved by an authorized role or that rollback behavior is reviewed.
Each example can be checked with the same short evidence record.
You draw how data moves through the system, mark where trust changes, and then systematically ask what an attacker could do at each point.

Retrieval practice

Recall check 1 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q1What makes a worked IoT threat example reviewable rather than just an answer?

AA scoped path, concern, evidence, decision, residual risk, and retest record.

BA final threat verdict backed by the team's prior discussion rather than a recorded path

CThe single most alarming attack scenario that anyone on the team can imagine

DA comprehensive CVE inventory attached to the system diagram

Show answer

Answer: A A worked threat example is reviewable when it records scope, asset, path, concern, mitigation, evidence, retest, decision, and residual risk.

Retrieval practice

Recall check 2 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q2A worked example confirms that one gateway route denies actuator commands from a telemetry-only identity. What is the best residual-risk statement?

AAll command authorization concerns are resolved because one route denied access

BReject the finding because telemetry identities cannot affect command routes

CConfirmed for the reviewed route and identity pair; other paths need records

DOmit residual risk because the reviewed decision was confirmed by evidence

Show answer

Answer: C A worked example should keep the decision bounded to the reviewed scope and record what remains outside that scope.

Retrieval practice

Recall check 3 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q3In STRIDE-based threat modeling of an IoT data-flow diagram, where do threats tend to concentrate?

AInside data stores because persisted records are where the trust boundary is enforced.

BAt trust boundaries where lower-trust input enters a trusted process.

CAt every diagram node equally, without weighting trust boundaries.

DAt the cloud because the service boundary covers the other trust transitions in the system.

Show answer

Answer: B Boundary-crossing flows are where an attacker's input first reaches something that trusts it, so the STRIDE questions concentrate there.

Retrieval practice

Recall check 4 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q4A rogue device pretends to be a legitimate sensor and feeds false readings to the gateway. Which STRIDE category is this?

ADenial of service, mitigated by rate limiting.

BSpoofing, which breaks authentication

CInformation disclosure, mitigated by encryption.

DRepudiation, mitigated by logging.

Show answer

Answer: B Impersonating a legitimate entity is Spoofing, an authentication failure.

Retrieval practice

Recall check 5 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q5A team's threat model looks thorough, yet an attacker compromises devices by pushing malicious firmware through the over-the-air update path. What most likely went wrong in the modeling?

ASTRIDE does not include any category for firmware tampering.

BRisk ranking is what failed; ranking cannot help here.

CThreat modeling cannot address firmware at all.

DThe update data flow was missing from the diagram.

Show answer

Answer: D A threat model only covers the flows it draws.

Print reference

Answers 1 of 2

Answer key.

A · A worked threat example is reviewable when it records scope, asset, path, concern, mitigation, evidence, retest, decision, and residual risk.
C · A worked example should keep the decision bounded to the reviewed scope and record what remains outside that scope.
B · Boundary-crossing flows are where an attacker's input first reaches something that trusts it, so the STRIDE questions concentrate there.
B · Impersonating a legitimate entity is Spoofing, an authentication failure.

Print reference

Answers 2 of 2

Answer key.

D · A threat model only covers the flows it draws.