Security: Threats & Defense · Study deck
Defense in Depth
Picture a building sensor whose password is stolen.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- place preventive, detective, and corrective controls so no single layer failure is fatal
- plan for compromise instead of assuming any one layer is unbreakable
- build layer independence rather than counting the number of layers
- map a control to the method (preventive, detective, or corrective) it actually performs
Major section
In 60 Seconds · Key Ideas
If that one secret opens every device, command, and stored record, the system has no second chance.
- A safer design expects one barrier to fail and limits what the next step can reach.
- An application programming interface is a defined way for software parts to request work or data; it is often shortened to API.
- A gateway is the device that joins one network to another.
Major section
Make One Failure Survivable
Defense in depth means an IoT system does not rely on a single perfect control.
- A perimeter rule, identity check, encrypted channel, application check, log, and recovery process each protect a different part of the attack path.
- If one layer fails, the next layer should still limit what an attacker can reach, change, observe, or hide.
Major section
Make One Failure Survivable (continued)
The model is not a pile of random tools.
- A useful layered design maps controls to assets, traffic paths, identities, software behavior, and response work.
- Each layer should have a clear purpose and enough evidence to show it works independently of the others.
- Those controls overlap, but they do not all answer the same question.
Major section
Make One Failure Survivable (continued)
A firewall does not prove device identity.
- Segmentation limits where traffic can go, identity proves which device or operator is acting, authorization decides whether the command is allowed, logs expose misuse, and rollback restores a known state after a bad change.
- A reviewer should be able to point to each layer and explain what remains true if the layer before it fails.
- Device identity does not prove a command is allowed.
Major section
Make One Failure Survivable (continued)
If you only need the intuition, this layer is enough: defense in depth changes the question from "Which one control blocks the attacker?" to "What still limits the attacker after one control fails?".
- An IoT deployment connects constrained devices, gateways, local networks, cloud services, maintenance accounts, update channels, and data stores.
- Encryption protects confidentiality, but it does not show whether a command is safe.
- Monitoring makes misuse visible; recovery restores a known state.
Major section
Make One Failure Survivable (continued)
Each labelled layer must add a different limit, detection signal, or recovery capability after the previous control is assumed to fail.
- Each later layer answers what remains true if the preceding layer fails.
- Layers protect different parts Boundary filtering, segmentation, identity, data protection, and monitoring each answer a different question along the path.
- Independence, not count Several controls that share one assumption are not depth; failure of that assumption removes them all.
Major section
Make One Failure Survivable (continued)
A firewall alone is not an architecture: once an allowed path is used, other controls must still limit the attacker.
- "We have monitoring" is incomplete without a response action that follows detection.
- "We use encryption" is incomplete without key handling and a way to detect misuse.
- If you can state why one layer is not enough, you can stop here.
Major section
Place Controls and Check Evidence
Defense in depth needs different control functions, not just different locations.
- A design made only of preventive controls can fail silently; a design made only of detective controls may discover harm after it is underway.
- Evidence should match those boundaries, not just show that a control exists somewhere in the product.
- If This Layer Fails.
Major section
Place Controls and Check Evidence (continued)
Reusing one administrator, store, or credential across all three would weaken that depth.
- For a remote temperature-threshold change, the path might be operator laptop, identity provider, management API, cloud command service, gateway, and room controller.
- Asset.: Name the data, command, device function, or service being protected.
- A gateway accepts remote configuration commands for downstream sensors.
Major section
Place Controls and Check Evidence (continued)
Entry path.: Describe how a request, packet, update, or user action reaches the asset.
- If the same maintenance account can change firewall rules, approve commands, disable logs, and delete rollback images, the design has many controls but little depth.
- Failure behavior.: State what remains true when one control fails.
- Filtering limits where management traffic originates.
Major section
Place Controls and Check Evidence (continued)
The resulting record names the asset, path, control, proof, decision, and retest trigger for one command rather than claiming that every component is simply “secure.”.
- A better record separates responsibilities: network rules are approved through change management, command authorization lives in the application, logs are written to a protected service, and recovery artifacts are stored outside the gateway's administrative zone.
- Later controls must still check identity and authorization.
- Logging and recovery limit and reverse misuse.
Major section
Place Controls and Check Evidence (continued)
At each hop, ask which principle applies, which evidence proves it, and which later control still acts after one failure.
- Preventive controls reduce the chance of misuse, detective controls expose a path that was taken, and corrective controls contain damage and restore service; the evidence column must prove each function independently.
- Evidence.: Record the configuration, log, packet trace, access test, or recovery record that proves the layer works.
- Manual response contains and restores the path.
Major section
Place Controls and Check Evidence (continued)
A firewall configuration or access test can prove prevention, a protected log and alert can prove detection, and a quarantine or rollback record can prove correction.
- A weak review says "the gateway is behind a firewall, so the command path is protected." A defense-in-depth review is narrower and testable.
- If you can place controls and tie each to evidence, you can stop here.
- That format makes weak depth visible quickly because blank proof or a repeated owner shows where the design depends on one hidden assumption.
Major section
Independence and the Method Cross-Walk
Understanding those relationships helps reviewers use defense in depth deliberately.
- One method can support another, but it should not be used as a substitute without evidence.
- The evidence that a chosen control is active.
- Treating a firewall as the whole architecture.: It is one boundary control among many.
Major section
Independence and the Method Cross-Walk (continued)
A strong identity check does not prove messages are authenticated end-to-end; an encrypted channel does not prove commands are authorized; monitoring without a response action leaves damage uncontained.
- Counting controls that share one credential, key, or admin path.: Shared dependence is not depth.
- Treating logs as useful without review or response.: Detection needs a follow-up action.
- Forgetting corrective controls.: Rollback, isolation, and credential reset complete the model.
Major section
Summary
Defense in depth reduces dependence on any single security control.
- Preventive, detective, and corrective controls serve different roles and should be reviewed together.
- Independence matters: a useful design still limits, detects, or recovers after one control fails.
- The method cross-walk keeps layering deliberate; one method should not silently substitute for another.
Deck summary
Key takeaways
If that one secret opens every device, command, and stored record, the system has no second chance.
- Defense in depth means an IoT system does not rely on a single perfect control.
- The model is not a pile of random tools.
- A firewall does not prove device identity.
- If you only need the intuition, this layer is enough: defense in depth changes the question from "Which one control blocks the attacker?" to "What still limits the attacker after one control fails?".
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1What question does defense in depth ask that single-control thinking does not?
Show answer
Answer: A Defense in depth plans for the failure of any single control and checks what independent protection remains.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A gateway is behind a firewall, but a stolen maintenance account can still send configuration commands after reaching the management API. What is the best defense-in-depth response?
Show answer
Answer: A Controls later on the path should ensure that account compromise does not become full command authority.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A reviewer says, "We use an encrypted channel, so commands on this path are authorized." What is the strongest correction?
Show answer
Answer: A One method does not substitute for another.
Print reference
Answers
Answer key.
- A · Defense in depth plans for the failure of any single control and checks what independent protection remains.
- A · Controls later on the path should ensure that account compromise does not become full command authority.
- A · One method does not substitute for another.