Security: Threats & Defense · Study deck
OWASP IoT Top 10
Choose one familiar OWASP family, such as weak passwords or exposed services, and ask what would prove the local system handles it well.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- use the OWASP IoT Top 10 as a risk-family lens, not a full program or a priority order
- combine risk families into a single finding rather than scoring them independently
- avoid misusing the list as a checklist
- Explain: A useful note says which interface, credential, update path, data store, or management function was checked and what record supports the decision.
Major section
Start Simple: Turn One Risk Family Into Evidence
A useful note says which interface, credential, update path, data store, or management function was checked and what record supports the decision.
- Each item becomes valuable only when it is tied to scope, ownership, a specific control claim, evidence, residual risk, and the change that would require the check again.
Major section
A Review Lens, Not a Checklist
Its value is as a structured prompt for review questions, not as a pass or fail checklist.
- The important idea is how to use the list.
- It reminds a reviewer which areas tend to fail, but ticking "item reviewed" proves nothing.
- The Top 10 names the areas; your evidence is the inspection.
Major section
A Review Lens, Not a Checklist (continued)
If you only need the intuition, this layer is enough: the OWASP IoT Top 10 is a memory aid for common IoT weaknesses.
- The headings remind an inspector which areas to examine, but the headings are not the inspection.
- The inspection is the recorded observation that a specific part was checked and behaved as required.
- For example, a connected camera might already use unique administrator credentials, so the password family is not the first finding.
Major section
A Review Lens, Not a Checklist (continued)
The same camera could still expose a debug service on the local network, send event clips through a weakly authorized cloud API, and report no installed firmware version after an update.
- The Top 10 helps name those separate review areas, but the useful record is narrower: service exposure, ecosystem authorization, update-state evidence, owner, and retest trigger.
- The chapter pauses for Figure: The Top 10 reaches beyond the device so that A Review Lens, Not a Checklist has inspectable evidence.
- With that mechanism visible, A Review Lens, Not a Checklist can serve as a reasoned input to the chapter's continuing decision.
Major section
A Review Lens, Not a Checklist (continued)
The visual's specific claim is that the Top 10 reaches beyond the device: credentials, services, ecosystem interfaces, updates, data handling, management, and physical access.
- The sequence Credentials to verify and recover to debug and secrets is the substantive content of Figure: The Top 10 reaches beyond the device.
- Numeric order is not severity order, and one device may invert the list.
- Beginner ExamplesTaken together, these checks make the section reviewable.
Major section
Map Each Risk Family to Evidence
Collect records for the allowed case, the denied case, and the operating state.
- The next choice is defensible only if the reader can see that the review loop keeps the list active: scope, map a family, ask for evidence, collect records, decide, and assign owner and retest.
- Device firmware looks fine but the API is unprotected.
Major section
Map Each Risk Family to Evidence (continued)
Credential policy, provisioning records, denied shared-default test, account lifecycle.
- Service inventory, zone assignment, allowed-flow and denied-path records.
- Component list, version records, advisory review, patch owner, accepted exceptions.
- Inventory exists but no owner reviews changes.
- Data collected "in case it is useful" with no purpose record.
Major section
Map Each Risk Family to Evidence (continued)
Transport configuration, storage protection, key handling, access tests, log redaction.
- Default config records, disabled debug, first-use setup, hardened service settings.
- Security depends on the operator changing defaults.
- Each cell is a prompt, not a verdict.
- Worked Review: Gateway Update PathA gateway receives firmware updates through an operator-managed service.
Major section
Map Each Risk Family to Evidence (continued)
The claim under review is: the reviewed gateway version accepts only authorized update packages and records the install state.
- Evidence gapsThe review does not cover cloud operator access, mobile app authorization, or physical debug access.
- The component inventory has no named owner for triage.
- ConclusionAccept only the narrow claim: one update-path expectation was reviewed with evidence.
- Retest on bootloader, update-service, package-format, signing-key, or recovery-path change.
Major section
Using the List Without Misusing It
At this depth the list stops being a slide and becomes a way to reason about how weaknesses combine, why order is local, and what counts as strong evidence for the highest-value families.
- A review that records each family separately, then notes how they chain, produces a more honest risk picture than ten isolated checkboxes.
Major section
Using the List Without Misusing It (continued)
Weak credentials (I1), an exposed service (I2), and missing update evidence (I4) often combine: a guessable secret reaches a service that should not be exposed, and there is no trustworthy way to ship a fix.
- A sensor with no personal data may treat privacy (I6) as low priority, while a camera handling video may treat it as the top risk.
- Working strictly from I1 to I10 can spend effort on a low-risk family before a high-risk one.
- Missing any one weakens the claim even if the others are present.
- Common MistakesTaken together, these checks make the section reviewable.
Major section
Using the List Without Misusing It (continued)
Data, Privacy, and Management EvidenceData and privacy families (I6, I7) need evidence across the whole life of the data: collection rationale, movement, storage, access, retention, and deletion.
- Protecting transport while leaking data in logs or storage is a common partial control.
- Physical Access Without Misuse DetailThe physical hardening family (I10) should be reviewed defensively, not as a teardown recipe.
- The list reminds you what to inspect; your records prove what was inspected.
Deck summary
Key takeaways
A useful note says which interface, credential, update path, data store, or management function was checked and what record supports the decision.
- Its value is as a structured prompt for review questions, not as a pass or fail checklist.
- If you only need the intuition, this layer is enough: the OWASP IoT Top 10 is a memory aid for common IoT weaknesses.
- The same camera could still expose a debug service on the local network, send event clips through a weakly authorized cloud API, and report no installed firmware version after an update.
- Collect records for the allowed case, the denied case, and the operating state.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1How is the OWASP IoT Top 10 best used in a security review?
Show answer
Answer: D The list reminds reviewers which areas commonly fail; the value comes from mapping each family to a boundary, a control, and evidence.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A gateway review finds unique admin credentials, but also a network-reachable local debug service, no current component inventory, and no install-state record for updates. Which families should the reviewer map first?
Show answer
Answer: B The debug service maps to insecure network services, the missing install-state record to update mechanism, and the stale inventory to component management.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A vendor states that a device "supports secure updates" and asks you to close the update finding. The device verifies a package signature but cannot report which firmware version is running and has no defined behavior on a failed install. What is the most evidence-bound conclusion?
Show answer
Answer: D A reviewable update claim needs authenticity, integrity, install state, and recovery.
Print reference
Answers
Answer key.
- D · The list reminds reviewers which areas commonly fail; the value comes from mapping each family to a boundary, a control, and evidence.
- B · The debug service maps to insecure network services, the missing install-state record to update mechanism, and the stale inventory to component management.
- D · A reviewable update claim needs authenticity, integrity, install state, and recovery.