Security: Threats & Defense · Study deck
IoT Security Fundamentals
Picture a heating controller receiving a command from the right account after that account was stolen.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
A security claim becomes testable when the asset, boundary, and expected behavior are explicit.
- Name the asset before selecting its control.The protected thing may be a command, credential, firmware image, identity, or operational record.
- Interfaces expose crossings into different trust contexts.Data, commands, identities, and responsibility can change hands at each boundary.
- Review device, communication, service, lifecycle, and monitoring evidence together.An encrypted link can coexist with a weak boot path or unverified update process.
- Refusal, detection, and recovery test different control types.Each control needs an observation that demonstrates the behavior it was meant to provide.
Major section
Test the command beyond login
A stolen account can pass login checks while sending commands the owner never intended.
- Identify the command path and physical action at risk.The chapter heating controller can receive an unwanted command through a stolen account.
- An allowed command provides the baseline for changed-condition tests.Change the sender, content, time, route, and software version to exercise the boundary.
- Record refusals, alerts, safe local behavior, and recovery.Network removal and device restart reveal behavior that a successful login cannot establish.
- Login leaves permission and current policy to be checked.The right account does not prove that this command belongs with this device.
Major section
Trace the asset-to-evidence map
Read the map left to right: a named asset needs protection at a reachable surface, with observed behavior proving the control.
- The asset card names what needs protection.Commands, credentials, firmware, and records can each be read, altered, or disrupted.
- Follow the surface card to the interfaces reaching that asset.Radios, ports, accounts, APIs, and update paths create places to test.
- The control card identifies protection at the crossing.The measure must address a stated threat at a specific trust boundary.
- Finish at evidence of allowed and denied behavior.Observed results complete the claim that the selected control actually works.
Major section
Separate secrecy, integrity, availability, and safety
Security properties describe different ways a connected product can fail its owner.
- Confidentiality limits who can read protected information.For a smart lock, the credential that opens the door must stay private.
- Integrity concerns unauthorized changes to data, commands, and code.The lock's unlock command needs protection against alteration without permission.
- Availability concerns whether the required function remains usable.The owner still needs access when the connected lock is required.
- Safety adds the consequences of physical action.A tampered actuator can move a real object and harm what the system touches.
Major section
Follow exposure across cloud, network, and device
Cloud, network, and device reviews follow the same asset through different exposure points.
- Cloud review checks private data and account access.The same review includes theft, corruption, and misuse of stored information.
- Network review checks unauthorized access and protected routing paths.Wireless links and machine-to-machine traffic need evidence instead of automatic trust.
- Device review includes stolen hardware and exposed secrets.A node may be hacked, broken, or recruited into another attack.
- A claim can cross several tiers.Record where each check runs so the response follows the asset's actual exposure.
Major section
Identity and permission answer different questions
Separate the identity check from the decision about permitted actions.
- Authentication establishes the identity a party presents.The security record still needs a separate decision about what that identity may do.
- Authorization decides which actions an identity may perform.Broker rules can allow gateway commands while refusing the same publish from a sensor.
- Encryption does not decide who may publish actuator commands.Protecting the channel leaves the command permission boundary to be enforced.
- Permitted and forbidden senders are both tested.Keep the accepted gateway command and logged sensor refusal with the authorization rules.
Activity 1 · Predict
✎ An encrypted command from the wrong role
I want you to separate a protected channel from permission to move the actuator.
A sensor identity uses an encrypted connection to publish an actuator command. Only gateway identities are allowed. Predict the broker outcome and write the allowed and denied tests needed to support the claim.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Turn feature claims into observed behavior
A product feature becomes evidence only when its claimed behavior is exercised.
- An encrypted link needs separate identity and permission checks.It also leaves availability as its own claim requiring evidence.
- A firewall diagram does not demonstrate traffic refusal.Exercise the boundary with the unwanted traffic it is supposed to reject.
- A smart lock needs several properties at once.Private credentials, authorized commands, and usable access support different parts of its purpose.
- Attach each observed result to the property being tested.A feature list cannot replace reproducible evidence for a specific control.
Major section
Inventory the doors into the device
The attack surface includes local access and maintenance paths as well as network traffic.
- Inventory radios, ports, accounts, APIs, and update paths.Every reachable interface contributes to the surface where the asset can receive input.
- Physical access can expose maintenance and storage paths.Reset buttons, debug ports, and removable storage need review alongside network services.
- Remove unused interfaces before hardening required ones.Disabling an unnecessary port or closing a service reduces the reachable attack surface.
- Keep ownership visible across the installed lifetime.The device still needs accountable maintenance when updates or recovery become necessary.
Major section
Match controls to device capability
Device capability changes which update and monitoring promises are credible.
- Top-tier devices usually support mature operating systems and endpoint controls.The chapter examples include laptops, tablets, and smartphones with stronger update support.
- Middle-tier products vary in updates and monitoring.Televisions, thermostats, and appliances do not all have the same endpoint capability.
- Bottom-tier devices combine limited compute with diverse firmware.Tags, lightbulbs, and simple sensors make patching and inventory harder at fleet scale.
- Choose evidence that fits the deployed maintenance capacity.The review must establish what the actual devices and their owners can support.
Major section
Plan maintenance for a diverse fleet
A larger population of simpler devices makes inventory and long-term support harder.
- Low compute capacity can restrict local protection and diagnostics.Simple sensors and controls may not support the endpoint tools used on larger devices.
- Diverse software complicates consistent patching.Differences in hardware, firmware, and operating systems make fleet inventory essential.
- Establish maintenance ownership and reachable network paths.The review needs to know who can fix the device and which systems it can reach.
- Small devices still need a credible update path.Long field life does not remove the need to recover devices already installed.
Major section
Learn from the Mirai defaults
The Mirai example connects weak defaults with consequences beyond the compromised device.
- Mirai recruited cameras, routers, and recorders through known default credentials.The chapter's 2016 example shows how weak defaults enabled remote control of devices.
- Compromised devices contributed traffic to large DDoS attacks.The damage extended beyond the individual camera, router, or recorder that was recruited.
- Replace shared defaults and close unnecessary management services.Failed-login logs provide evidence of attempted access rather than leaving it invisible.
- Segment devices awaiting repair and retain a tested update path.Field recovery needs a way to restore devices that cannot be fixed immediately.
Major section
Follow the five domain spokes
Start at the wheel’s central assets, then follow the domain spokes that protect them.
- Firmware, data and commands sit at the centre of the claim.The wheel keeps the same protected assets visible across every domain.
- Follow device and communication spokes toward their exposure points.Hardware controls, peer identity, and message protection contribute different evidence.
- The service spoke covers identity, permissions, and data handling.Authentication, authorization, input checks, and stored-data protection belong in that review.
- Lifecycle and monitoring connect maintenance with detection and response.Provisioning, update, retirement, logs, and alerts support the same asset over time.
Major section
Match the control to its proof
Different control types need different demonstrations of success.
- Preventive evidence shows an unauthorized action being refused.Authorization or segmentation needs a denied case alongside its configured rule.
- Detective evidence shows the intended event producing a log or alert.The observation must exercise the event the control is meant to catch.
- Corrective evidence compares states before and after recovery.Credential rotation or firmware rollback needs a tested recovery run.
- A configured feature alone does not establish these outcomes.Each control type needs evidence that demonstrates its own purpose.
Activity 2 · Match
✎ Match each control to its proof
I want you to pair each control with an observation that actually tests its purpose.
Match authorization, segmentation, audit logging, credential rotation, and firmware rollback to these proofs: denied publish, blocked traffic, recorded event, tested credential recovery, and tested firmware recovery. Mark each pair preventive, detective, or corrective.
4 minutes · Pen and paper · Answer: Activity 2
Major section
Test the actuator-command boundary
The actuator-command example makes a narrow security claim reviewable.
- Name the broker entry point enforcing command permissions.A narrow claim can state that only gateway identities may publish actuator commands.
- Tie each identity to its permitted publish topics.The sensor and gateway roles must produce different decisions at the same boundary.
- Keep the accepted gateway test and logged sensor refusal.Together with the rules, they show both allowed and denied behavior.
- Retest after changes that affect the claim.New roles, credential rotation, broker configuration changes, or incidents reopen the review.
Major section
Read the durable security review record
Read down the review sheet from its narrow claim to the change that requires retesting.
- The review sheet starts from the asset and boundary rows.They identify what is protected and the crossing where the claim is enforced.
- Follow the threat and control rows together.The unwanted action must connect to a measure intended to reduce that risk.
- Observed evidence records both allowed and denied tests.The review sheet preserves actual behavior instead of an assurance based on configuration alone.
- Finish with the retest trigger.Role, firmware, configuration, or topology changes can make the earlier result insufficient.
Major section
Make the protection layers independent
Layering helps when defeating one control does not defeat the remaining protections.
- Device, network, and service controls must be independently enforced.Authentication, segmentation, and authorization help when defeating one leaves the others effective.
- Controls sharing one secret can collapse together.A single compromise can defeat layers that appear separate in the diagram.
- Residual risk remains after controls are tested.The review must name what remains instead of promising that every risk disappeared.
- Changes to roles or system configuration can require fresh evidence.Firmware and topology changes can also alter the boundary that was tested.
Deck summary
Key takeaways
A trustworthy claim stays narrow, testable, and explicit about remaining risk.
- Name assets and reachable surfaces before selecting controls.A command path or credential needs a specific boundary where its protection can be tested.
- Keep security properties, identity, permission, and safety claims distinct.Evidence for a private channel does not establish permission to move an actuator.
- Independent layers limit the effect of one defeated control.Shared secrets or assumptions can make several apparent protections fail together.
- Record residual risk and the changes that reopen the review.A trustworthy claim remains narrow, reproducible, and tied to its observed operating conditions.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says their thermostat is secure because all of its network traffic is encrypted. What is the strongest correction?
Show answer
Answer: A Confidentiality is one property.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A design claim says only gateway identities can publish actuator commands. Which evidence best supports it?
Show answer
Answer: A A role boundary needs both the allowed case and the denied case, with the rejection visible in evidence.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A reviewer is told a device is protected by three layers: a device certificate, network segmentation, and service authorization. What is the most important thing to verify about the layers?
Show answer
Answer: A Defense in depth only adds strength when layers fail independently.
Print reference
Answers
Answer key.
- A · Confidentiality is one property.
- A · A role boundary needs both the allowed case and the denied case, with the rejection visible in evidence.
- A · Defense in depth only adds strength when layers fail independently.
Print reference
Activity 1 answer
Model answer.
Predict: The broker should reject the sensor command under its authorization rules and log the rejection. A gateway command should be accepted. Encrypted traffic alone does not prove that these role permissions hold.
Print reference
Activity 2 answer
Model answer.
Match: Authorization → denied publish and segmentation → blocked traffic are preventive. Audit logging → recorded event is detective. Credential rotation → tested credential recovery and firmware rollback → tested firmware recovery are corrective; record their before-and-after states.