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.
- Telemetry means measured status sent from a device for remote use.
- Each protected action needs a named boundary, control, allowed case, and denied case.
- This runway does not prove that one principle secures the whole product.
Major section
In 60 Seconds (continued)
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.
- For an IoT product, that action might be installing firmware, changing a lock schedule, accepting telemetry, or opening a management port.
- 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.
Major section
Turn the Slogan Into a Review Question (continued)
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.
- That mechanism is the part of Turn the Slogan Into a Review Question the chapter continues to build upon.
- 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 privilegeScope 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 depthIndependent 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 privilegeA 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
Every path reaches the policy check.
- 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.
- Independent controls on the same path.
- Several controls sharing one credential or address.
Major section
Check Whether the Layers Still Stand (continued)
For the configuration-change example, remove the approval while keeping the role valid; separation of privilege requires the change to be rejected.
- 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.
- The deeper sections turn least privilege, safe defaults, full checks, layered controls, and safe failure into reviewable evidence.
- Security-by-design is reviewable only when each principle is tied to evidence.
- 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.
- 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: B 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: C 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.
- B · 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.
- C · Least privilege needs evidence for the denied cases, not just the allowed action.
- B · Defense in depth depends on independence.