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

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.

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.

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)

The Six STRIDE Categories Spoofing / Tampering Pretending to be someone (breaks authentication) or altering data (breaks integrity).

The model should not claim that "commands are secure" in general.
The boundary crossings are where the interesting threats live.
Repudiation Denying 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

The point of ranking is to spend limited effort where expected harm is greatest, not where the threat is most vivid.

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.

Major section

Rank Risk and Catch the Missing Flow (continued)

Spoofing a sensor that drives an actuator may outrank eavesdropping on low-sensitivity telemetry, even though eavesdropping sounds worse in the abstract.

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 confident final conclusion offered with no supporting detail behind it at all

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

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

DA long exhaustive list of every possible published CVE identifier in existence

Show answer

Answer: C 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

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

CReject the finding because telemetry identities cannot affect command routes

DOmit residual risk because the reviewed decision was confirmed by evidence

Show answer

Answer: B 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?

AOnly inside data stores, never on data flows.

BAt every node equally, because STRIDE treats boundaries as optional notes.

CAt trust boundaries where less-trusted data first enters a more-trusted process.

DOnly at the cloud, since that is the most valuable target.

Show answer

Answer: C 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, and what mitigation fits?

ASpoofing, which breaks authentication

BDenial of service, mitigated by rate limiting.

CInformation disclosure, mitigated by encryption.

DRepudiation, mitigated by logging.

Show answer

Answer: A 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.

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