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
A gateway is the device that joins one network to another.
- 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.
- More controls can add cost and new mistakes, so layers must have distinct jobs.
Major section
In 60 Seconds (continued)
An application programming interface is a defined way for software parts to request work or data; it is often shortened to API.
- At each boundary, state what checks identity, limits permission, protects the message, records the action, and stops unusual behavior.
- The deeper sections compare prevention, detection, response, and recovery and show how to avoid several barriers that all fail for the same reason.
- A firewall, certificate, encrypted channel, log, or rollback image is useful only when it protects a different part of the path and leaves a record a reviewer can check.
Major section
Key Ideas
A layer protects one part of the command path, while the failure assumption tests whether another control can still contain the attack.
- Evidence turns each claimed protection into something a reviewer can inspect.
- Failure assumption: the review deliberately asks what happens after one layer is bypassed, misconfigured, or compromised.
- Control mix: preventive, detective, corrective, and recovery controls do different jobs and need each other.
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)
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.
- Monitoring makes misuse visible; recovery restores a known state.
- Each later layer answers what remains true if the preceding layer fails.
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?".
- Layers protect different partsBoundary filtering, segmentation, identity, data protection, and monitoring each answer a different question along the path.
- Independence, not countSeveral controls that share one assumption are not depth; failure of that assumption removes them all.
- A firewall alone is not an architecture: once an allowed path is used, other controls must still limit the attacker.
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.
- Identity sets who may act.
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.
- Data protection covers storage and use.
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.
- If This Layer Fails.
Major section
Place Controls and Check Evidence (continued)
Evidence: Record the configuration, log, packet trace, access test, or recovery record that proves the layer works.
- 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.
- Link protection guards data in flight, while code integrity limits what can run.
- A gateway accepts remote configuration commands for downstream sensors.
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.
- Logs must reveal a fault, and recovery proof must show a safe return.
- Filtering limits where management traffic originates.
- Later controls must still check identity and authorization.
Major section
Place Controls and Check Evidence (continued)
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.
- The result names the asset, path, control, proof, choice, and retest trigger instead of making one broad claim that the whole system is secure.
- Logging and recovery limit and reverse misuse.
- Manual response contains and restores the path.
Major section
Independence and the Method Cross-Walk
The evidence that a chosen control is active.
- For the gateway example, assume boundary filtering has failed, then check that command authorization still rejects an unauthorized configuration change and monitoring records the attempt.
- Understanding those relationships helps reviewers use defense in depth deliberately.
- Forgetting corrective controls: Rollback, isolation, and credential reset complete the model.
Major section
Independence and the Method Cross-Walk (continued)
One method can support another, but it should not be used as a substitute without evidence.
- 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.
- Treating a firewall as the whole architecture: It is one boundary control among many.
- Counting controls that share one credential, key, or admin path: Shared dependence is not depth.
Major section
Summary
It assigns distinct jobs to boundary controls, identity, authorization, data protection, application checks, monitoring, and recovery.
- The reviewer then assumes one control has failed and identifies the remaining limit, signal, or repair path.
- 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.
Deck summary
Key takeaways
A gateway is the device that joins one network to another.
- An application programming interface is a defined way for software parts to request work or data; it is often shortened to API.
- A layer protects one part of the command path, while the failure assumption tests whether another control can still contain the attack.
- Defense in depth means an IoT system does not rely on a single perfect control.
- The model is not a pile of random tools.
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: D 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: C 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: B One method does not substitute for another.
Print reference
Answers
Answer key.
- D · Defense in depth plans for the failure of any single control and checks what independent protection remains.
- C · Controls later on the path should ensure that account compromise does not become full command authority.
- B · One method does not substitute for another.