Security: Threats & Defense · Study deck
The IoT Threat Landscape
Picture one device command doorway: a sensor can send readings, but only a maintainer should change a setting.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The same note should name the evidence needed: an allowed maintainer action, a denied viewer action, and an audit record that records actor, action, target, and outcome.
- Explain: Reviewable "The gateway command path may accept configuration changes without evidence of action-level authorization for the operator role." Names path, action, missing evidence, and property.
- Explain: A reviewable threat note would name the dashboard path, the operator role, the gateway boundary, and the missing proof that viewer accounts are denied change actions.
- Explain: The final label, or authorization code changes, is a reason to test again.
Major section
What an IoT Threat Statement Means
An IoT threat is a condition that could harm an asset through an unwanted action, fault, misuse path, or control gap.
- A useful threat statement is not a dramatic story and not a generic fear.
- This chapter is the vocabulary entry point for the rest of the threats sequence.
- The threat is an unauthorized change.
Major section
What an IoT Threat Statement Means (continued)
The asset is the command that changes the heating, ventilation, and air-conditioning (HVAC) set point.
- For a smart-building gateway, the asset might be the configuration command that changes HVAC set points.
- Keeping these separate is what makes a threat note reviewable.
- The control checks that role again for each change.
Major section
What an IoT Threat Statement Means (continued)
The vulnerability is the local weakness that makes the condition credible.
- A reviewable threat note would name the dashboard path, the operator role, the gateway boundary, and the missing proof that viewer accounts are denied change actions.
- The same note should name the evidence needed: an allowed maintainer action, a denied viewer action, and an audit record that records actor, action, target, and outcome.
- Beginner Examples Taken together, these checks make the section reviewable.
Major section
What an IoT Threat Statement Means (continued)
Condition and weakness The threat condition is what could go wrong for the asset.
- The evidence includes one allowed change, one denied change, and a log of both results.
- The final label, or authorization code changes, is a reason to test again.
- Control and evidence The control is the preventive, detective, corrective, or recovery measure.
Major section
What an IoT Threat Statement Means (continued)
This ordered path keeps the asset, threat, weakness, control, evidence, remaining risk, and retest rule separate.
- The Threat Vocabulary Asset and path The asset is the data, command, identity, function, update path, or record being protected.
- The evidence supports or weakens the control claim, with residual risk and a retest trigger.
- That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
Major section
Write Reviewable Threat Statements
A threat introduction should help you ask reviewable questions.
- From there the reviewer can ask for enrollment records, route policy, accepted-message evidence, denied-message evidence, and the change that would reopen the check.
- Walkthrough: The Review Lens Taken together, these checks make the section reviewable.
- At the device surface, ask which identity and firmware state are accepted.
Major section
Write Reviewable Threat Statements (continued)
Work one surface at a time so the note does not collapse into a vague system warning.
- At the gateway surface, ask which topic, route, or command path is allowed and which case is denied.
- At the application surface, ask which role can view, export, or change data.
- A reviewer has nothing to inspect.
Major section
Write Reviewable Threat Statements (continued)
Reviewable "The gateway command path may accept configuration changes without evidence of action-level authorization for the operator role." Names path, action, missing evidence, and property.
- At the operations surface, ask which support, override, recovery, or update path can change the outcome.
- Configuration change is a sensitive action.
- Authorization and accountability are at risk.
Major section
Write Reviewable Threat Statements (continued)
An operator role may change settings without action-level authorization.
- Weak Statement Versus Reviewable Statement Weak "The gateway could be attacked." No asset, path, weakness, control, or evidence.
- The green “Reviewable” example names a missing authorization decision, but the claim still needs evidence categories.
- Denied configuration-change test for a role outside scope.
Major section
Attack Categories and Vulnerability Classes
The deeper layer adds the category prompts and weakness classes that keep a review systematic.
- A local asset, path, weakness, evidence source, and mitigation are still required.
- A useful category-to-finding transition has three steps.
- STRIDE starts from broken security properties.
- Spoofing: an identity, device, service, or message source may not be trustworthy.
Major section
Attack Categories and Vulnerability Classes (continued)
IoT-focused ENISA-style taxonomies make that list easier to navigate for connected devices by separating device, network, cloud, data, privacy, and operational impacts.
- Tampering: data, commands, firmware, configuration, or logs may be changed without approval.
- Repudiation: events may not be attributable to the right device, account, service, or process.
- Enrollment, credential, role, or revocation records.
Major section
Attack Categories and Vulnerability Classes (continued)
Information disclosure: sensitive data may be exposed through transport, storage, logs, APIs, or physical access.
- Service disruption: devices, gateways, networks, or cloud workflows may become unavailable.
- Privilege escalation: a low-permission identity or component may gain a stronger role.
- Vulnerability Classes Vulnerability classes describe the local weakness that makes a threat condition credible.
Major section
Attack Categories and Vulnerability Classes (continued)
Identity and authorization Shared credentials, unclear device identity, telemetry identities that can request actions, or roles that reach management paths outside their scope.
- The same class can appear at different IoT layers; keep each finding tied to the local system and path.
- Each control class has a matching evidence requirement.
- Data, firmware, and commands are unaltered.
Major section
Attack Categories and Vulnerability Classes (continued)
Indirect evidence, such as an architecture diagram or policy statement, can explain intent but should not close the finding by itself.
- Missing direct evidence is often the finding, especially when the control claim depends on a boundary actually denying the unwanted case.
- Signed, validated, or state-checked records.
- A transport that is encrypted but unauthenticated.
Major section
Attack Categories and Vulnerability Classes (continued)
At this depth, an introductory threat note is a small evidence record: asset, condition, path, weakness, control, evidence, residual risk, and retest trigger.
- Control and Evidence Map Threat review should map findings to evidence, not only to control names.
- Failures are seen and reversible.
- A threat note without a retest trigger silently expires.
Deck summary
Key takeaways
An IoT threat is a condition that could harm an asset through an unwanted action, fault, misuse path, or control gap.
- The asset is the command that changes the heating, ventilation, and air-conditioning (HVAC) set point.
- The vulnerability is the local weakness that makes the condition credible.
- Condition and weakness The threat condition is what could go wrong for the asset.
- This ordered path keeps the asset, threat, weakness, control, evidence, remaining risk, and retest rule separate.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A review note says 'The gateway could be attacked,' with no asset, path, weakness, or evidence. What is the best next step?
Show answer
Answer: A A vague threat note should be rewritten as a narrow condition tied to an asset, path, control, evidence need, and retest trigger.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A review note says, "The gateway could be attacked," with no asset, path, weakness, or evidence. What is the best next step?
Show answer
Answer: A A threat note is useful only when it is specific enough to review, evidence, assign, and retest.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A reviewer writes: "Tampering is the problem." Why is naming the attack category not yet a complete finding?
Show answer
Answer: B Categories like tampering are prompts that point to where to look; the finding is complete only when it is tied to a concrete path, evidence source, and mitigation.
Print reference
Answers
Answer key.
- A · A vague threat note should be rewritten as a narrow condition tied to an asset, path, control, evidence need, and retest trigger.
- A · A threat note is useful only when it is specific enough to review, evidence, assign, and retest.
- B · Categories like tampering are prompts that point to where to look; the finding is complete only when it is tied to a concrete path, evidence source, and mitigation.