Security: Threats & Defense · Study deck
The Threat Modelling Process
Picture a warehouse door that accepts an open command from a staff tablet.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A new data flow, device identity scheme, update path, management role, or monitoring change can make a previous model incomplete, which is why the loop is meant to be re-run rather than written once.
- Explain: Naming the standard matters for review conversations with auditors or partners who expect the process to carry a citation, even though it is the evidence-record loop below that actually makes the assessment repeatable.
- Explain: Residual risk should be recorded plainly: what remains possible, why it is accepted for now, who owns it, and what change reopens the decision.
Major section
Start Simple: Draw One Flow Before Choosing Controls
The team proposes stronger encryption, but it has not yet asked whether a stolen account, an old command, or a bypass path could still open the door.
- The safety owner needs a threat tied to the real flow.
- A control name is not evidence, and one protected link does not secure the whole action.
Major section
Start Simple: Draw One Flow Before Choosing Controls (continued)
This opening does not list every attacker or guarantee no harm.
- Practitioner turns flows into ranked controls and residual risk.
- Under the Hood examines formal categories, likelihood, impact, control fit, and the evidence loop that keeps the model current.
- This keeps mitigation grounded.
- A useful model chooses the control after it has named the threat and can show the evidence behind the decision.
Major section
A Threat Model Is an Evidence Record
Threat modelling is a structured review of what the system protects, how data and control actions move, where trust changes, what could go wrong, and which mitigations reduce the most relevant risks.
- A useful threat model is not a long list of fears.
- Mitigation is the step after threat identification.
- The model is intentionally iterative.
Major section
A Threat Model Is an Evidence Record (continued)
That sequence matters because the same control can mean different things in different places.
- The review should explain why a control fits a specific threat, what evidence shows the control is present, what risk remains, and what change would reopen the model.
- For an IoT gateway, the protected assets might be device identity, telemetry history, configuration commands, update packages, audit records, and operator roles.
- A threat model makes those boundaries explicit before choosing controls.
Major section
A Threat Model Is an Evidence Record (continued)
Naming the standard matters for review conversations with auditors or partners who expect the process to carry a citation, even though it is the evidence-record loop below that actually makes the assessment repeatable.
- The flows might include device-to-gateway telemetry, service-to-gateway commands, operator dashboard changes, and firmware updates.
- A useful model keeps the control claim attached to the asset, flow, and threat it actually reduces.
- If you only need the intuition, this layer is enough: a threat model is a repeatable record.
- Beginner Examples Taken together, these checks make the section reviewable.
Major section
A Threat Model Is an Evidence Record (continued)
It starts with scope and flows, names threats by category, selects mitigations that fit, attaches evidence, and records residual risk and retest triggers.
- A new data flow, device identity scheme, update path, management role, or monitoring change can make a previous model incomplete, which is why the loop is meant to be re-run rather than written once.
- The result ties A Threat Model Is an Evidence Record to a named test or record later in the narrative.
- Threats before controls Identify threats by category, then select mitigations that fit the named threats, not the other way around.
Major section
Build the Model and Match Mitigations
Scope should be narrow enough to reason about and broad enough to include the paths that matter.
- The movement between them reveals the scope map keeps the model grounded: every threat ties to an asset, flow, boundary, or assumption.
- Integrity checks, signed records, startup and update verification.
- Repudiation: disputed management changes.
Major section
Build the Model and Match Mitigations (continued)
Worked Review A building gateway receives sensor telemetry, forwards commands to devices, and lets operators change device settings.
- Access control and minimization; segmentation and rate limits; least privilege and separation of duties.
- Mitigation records should also name assumptions: if segmentation is selected, state which boundary it protects and which flows remain allowed.
- Scope assets: telemetry, management commands, device identity, configuration, and audit records.
Major section
Build the Model and Match Mitigations (continued)
Figure: The mitigation workflow keeps control selection separate from separates Candidate controls, owner and rationale, and: The control must fit the named threat so the reader can see where the claim might fail.
- EoP: a viewer role changes settings if authorization is only checked at login.
- Residual risk and retest Reopen after changes to enrollment, routing, dashboard roles, command format, monitoring rules, or update behavior.
- If you can scope a model and match mitigations to threats, you can stop here.
Major section
Evidence Quality, Residual Risk, and Findings
The deeper layer is where a threat model becomes an assessment.
- Threat models fail when they stop at "control should exist." A mitigation needs evidence, and a finding needs an owner, a decision, and a retest path.
- Evidence quality should be graded, not just collected.
- Residual risk is not a failure by itself.
Major section
Evidence Quality, Residual Risk, and Findings (continued)
A vague finding cannot be assigned an owner or closed with evidence.
- Residual risk should be recorded plainly: what remains possible, why it is accepted for now, who owns it, and what change reopens the decision.
- Missing evidence is also a finding when the model depends on the claim.
- No decision or owner is assigned.
Major section
Evidence Quality, Residual Risk, and Findings (continued)
A finding is not complete when it is written.
- A threat model is stronger when it says which evidence is direct, which is assumed, and which remains open.
- The record still needs the acceptance owner, the reason, the compensating control, the monitoring signal, and the retest trigger.
- It says only that something is insecure.
Major section
Evidence Quality, Residual Risk, and Findings (continued)
For example, accepting delayed telemetry during a network outage is different from accepting unauthenticated management commands.
- One affects freshness and recovery; the other affects authorization and accountability for physical changes.
- From Threat Notes to Assessment Findings When threat-model notes become findings in a formal assessment, specificity is required.
- No retest trigger is recorded.
Major section
Evidence Quality, Residual Risk, and Findings (continued)
Reviewable finding "The gateway accepts management commands from the service path without evidence of action-level authorization; this affects authorization and accountability for configuration changes." Names path, missing evidence, and properties.
- A reviewable closure path should say what proof changes the finding status.
- If the decision is to monitor instead of change design immediately, the record should name the alert, threshold, owner, and review date.
- Mitigate, monitor, accept with owner, or gather evidence.
Major section
Evidence Quality, Residual Risk, and Findings (continued)
Some risk may be accepted because the affected path is isolated, monitored, rate-limited, or operationally recoverable.
- Without that closure path, the assessment becomes a backlog of labels rather than a risk decision record.
- Direct or indirect evidence is cited, with gaps noted.
- Common Mistakes Taken together, these checks make the section reviewable.
Deck summary
Key takeaways
The team proposes stronger encryption, but it has not yet asked whether a stolen account, an old command, or a bypass path could still open the door.
- This opening does not list every attacker or guarantee no harm.
- Threat modelling is a structured review of what the system protects, how data and control actions move, where trust changes, what could go wrong, and which mitigations reduce the most relevant risks.
- That sequence matters because the same control can mean different things in different places.
- It starts with scope and flows, names threats by category, selects mitigations that fit, attaches evidence, and records residual risk and retest triggers.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1What best describes a useful IoT threat model?
Show answer
Answer: A A threat model is a structured record another reviewer can repeat, not a one-time list of fears.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A threat model says an unauthorized device might submit telemetry to a gateway. Which mitigation record best fits the threat?
Show answer
Answer: B The threat is spoofing a device identity, so the mitigation should address identity verification and supporting evidence.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3An assessment lists the finding "the gateway is insecure." Why can this finding not be closed?
Show answer
Answer: C A finding is complete only when it is specific enough to assign an owner, a decision, and a retest path.
Print reference
Answers
Answer key.
- A · A threat model is a structured record another reviewer can repeat, not a one-time list of fears.
- B · The threat is spoofing a device identity, so the mitigation should address identity verification and supporting evidence.
- C · A finding is complete only when it is specific enough to assign an owner, a decision, and a retest path.