Security: Threats & Defense · Study deck
Security-by-Design Principles
Picture a door controller offered an old software file by a valid service account.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- apply security-by-design principles (least privilege, fail-safe defaults, defense in depth) from the start of a design
- connect a design principle to the architecture layer and threat it addresses
- review a design against principles before implementation, not after
- Explain: A slogan such as "secure by design" helps only when the device rejects this exact case and records why.
Major section
In 60 Seconds
A slogan such as "secure by design" helps only when the device rejects this exact case and records why.
- Firmware means the software stored on a device.
- Telemetry means measured status sent from a device for remote use.
- Each protected action needs a named boundary, control, allowed case, and denied case.
Major section
In 60 Seconds (continued)
This runway does not prove that one principle secures the whole product.
- The deeper sections turn least privilege, safe defaults, full checks, layered controls, and safe failure into reviewable evidence.
- Security by design starts with a small, testable claim.
- If it cannot, the principle is still only a slogan.
Major section
Turn the Slogan Into a Review Question
Security-by-design is reviewable only when each principle is tied to evidence.
- The important idea is to treat every principle as a question about a specific action, path, or asset.
- For an IoT product, the review question should name the real boundary.
- Each principle reduces to a single question.
Major section
Turn the Slogan Into a Review Question (continued)
That mechanism is the part of Turn the Slogan Into a Review Question the chapter continues to build upon.
- A sensor joining a gateway, a mobile app changing a lock schedule, a broker accepting a publish request, and a device installing firmware are different decisions.
- They may all cite the same principle, but each needs its own control and evidence.
- If you can restate a principle as a testable question, you can stop here.
Major section
Follow the Evidence at One Boundary
A gate is useful only when the review can show who reaches it, what it checks, what it allows, what it denies, and what record it leaves.
- For a firmware update gate, the boundary might be the device-side verifier that accepts or rejects an install package.
- Retest on role, topic, or gateway change.
Major section
Follow the Evidence at One Boundary (continued)
The least-privilege question asks which updater identity may submit the package.
- The evidence is not a principle name; it is the allow test, deny test, install log, rollback record, and retest trigger.
- Collect evidence.: Allow logs, deny logs, configuration, policy files, tests, and approval records.
- Evidence: failure-mode tests, reject logs, recovery records.
Major section
Follow the Evidence at One Boundary (continued)
Least privilege Scope permissions to the reviewed action: a device identity publishes telemetry but cannot subscribe to other classes' commands.
- Evidence: access rules, topic policies, deny logs, failing tests for unrelated actions.
- Evidence: request-path maps, enforcement locations, denied-request logs, tests against alternate paths.
- Defense in depth Independent controls each answer a different question.
Major section
Follow the Evidence at One Boundary (continued)
Evidence: approval records and tests that one missing condition blocks the action.
- Evidence: control maps, failure-mode reviews, and tests that a second control still limits impact when the first is unavailable.
- A device management service can send configuration changes to deployed devices.
- Service identity changes config for its assigned group only.
Major section
Follow the Evidence at One Boundary (continued)
Separation of privilege A sensitive action requires more than one independent condition: identity plus management-zone origin, signed manifest plus version policy, operator role plus change ticket.
- The same pattern applies when the protected action is not a management command.
- New groups need their own review.
- New paths must be added to the map.
Major section
Follow the Evidence at One Boundary (continued)
The negative evidence is often the most important artifact because it proves the boundary rejects paths the architecture says should not exist.
- Direct, API, and scheduled-job paths use the same check.
- Failed policy lookup rejects and logs; action needs role plus approval.
- Retest on policy schema or approval-workflow change.
Major section
Check Whether the Layers Still Stand
The deeper layer covers the principles that decide whether a layered design is genuinely strong and why allowed-only testing is misleading.
- Layers are weak when they share an unprotected assumption.
- Every path reaches the policy check.
- Independent controls on the same path.
- Several controls sharing one credential or address.
Major section
Check Whether the Layers Still Stand (continued)
That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
- Failure leaves the action open by default.
- Force the control to fail; observe the state.
- A defensible chapter-level claim names the control, the evidence, the limit, and the retest trigger.
Deck summary
Key takeaways
A slogan such as "secure by design" helps only when the device rejects this exact case and records why.
- This runway does not prove that one principle secures the whole product.
- Security-by-design is reviewable only when each principle is tied to evidence.
- That mechanism is the part of Turn the Slogan Into a Review Question the chapter continues to build upon.
- A gate is useful only when the review can show who reaches it, what it checks, what it allows, what it denies, and what record it leaves.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1Why is "the system is secure by design" a weak claim for a security review?
Show answer
Answer: D A principle becomes reviewable only when it is tied to a narrow action, a boundary, a control, and evidence for the allowed and denied cases.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A document says a management service follows least privilege, but the review only shows that one expected command succeeds. What evidence is still needed?
Show answer
Answer: A Least privilege needs evidence for the denied cases, not just the allowed action.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A design lists six controls and calls it defense in depth, but all six trust the same unauthenticated source address. What is the strongest objection?
Show answer
Answer: B Defense in depth depends on independence.
Print reference
Answers
Answer key.
- D · A principle becomes reviewable only when it is tied to a narrow action, a boundary, a control, and evidence for the allowed and denied cases.
- A · Least privilege needs evidence for the denied cases, not just the allowed action.
- B · Defense in depth depends on independence.