6 Security-by-Design Principles

6.3 Turn the Slogan Into a Review Question

This section: Turn the Slogan Into a Review Question — Security-by-design is reviewable only when each principle is tied to evidence.

Security-by-design is reviewable only when each principle is tied to evidence. A useful review does not stop at "we follow least privilege" or "we use defense in depth." It records the protected action, the trust boundary, the control that enforces the principle, the evidence that the control is active, the residual risk, and the trigger that requires retesting.

The important idea is to treat every principle as a question about a specific action, path, or asset. Principles earn their value by preventing vague security claims, not by appearing in a design document.

For an IoT product, the review question should name the real boundary. 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. This is why design principles belong in the architecture record beside assets, identities, paths, tests, logs, and retest triggers.

Each principle reduces to a single question. Least privilege: what is the narrowest permission that still lets this identity do its job? Secure defaults: what happens before anyone changes settings? Complete mediation: is every sensitive request checked, or can a cached or alternate path bypass policy? Defense in depth: if this control fails, what independent control still limits impact? Fail secure: when the control cannot decide safely, does the system move to a documented low-risk state?

This is the point where Turn the Slogan Into a Review Question must connect to observable behavior. Figure 6.1 makes that connection with the chapter’s worked configuration-change example: the protected action reaches a gateway-policy boundary, a least-privilege role policy checks the service identity’s group scope, and the resulting allow and deny records preserve the claim limit and retest trigger.

+

The path through Figure 6.1 is meaningful because it follows one concrete configuration-change request from the protected action to a least-privilege role-policy check at the gateway-policy boundary, then shows both the allowed and denied evidence, the claim limit, and the retest trigger. That mechanism is the part of Turn the Slogan Into a Review Question the chapter continues to build upon.

6.4 Follow the Evidence at One Boundary

This section: Follow the Evidence at One Boundary — Security principles usually appear at gates: identity, authorization, input, update, management, and monitoring gates.

Security principles usually appear at gates: identity, authorization, input, update, management, and monitoring gates. 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.

Run the review on one decision at a time. For a firmware update gate, the boundary might be the device-side verifier that accepts or rejects an install package. The least-privilege question asks which updater identity may submit the package. The secure-defaults question asks what happens before provisioning. Complete mediation asks whether recovery, factory, and debug install paths reach the same verifier. Fail-secure behavior asks whether a missing policy, expired certificate, bad signature, or interrupted install leaves the device in a known safe state. The evidence is not a principle name; it is the allow test, deny test, install log, rollback record, and retest trigger.

Write the claim in the same words an operator or test harness will use, so evidence can be repeated without guessing what the reviewer meant.

6.4.1 Build the Review Record

1. State the claim narrowly. Name the protected action and the principle being applied.
2. Name the trust boundary. The gateway rule, broker policy, firmware verifier, API handler, or approval path where the decision is made.
3. Identify the control. The specific mechanism that enforces the principle at that boundary.
4. Collect evidence. Allow logs, deny logs, configuration, policy files, tests, and approval records.
5. Record the decision. The accepted claim, its limits, and the residual risk.
6. Define the retest trigger. The change that invalidates the review.

Build the Review Record introduces a boundary that must remain visible in the design. Figure 6.2 clarifies it by depicting how “Boundary gates: identity, authorization, input validation, and monitoring guard the protected action and leave a record” is explicit in the diagram.

+

Read Identity as the first explicit role in Figure 6.2; valid state? supplies the next constraint, while trigger records the consequence. This label-specific chain shows “Boundary gates: identity, authorization, input validation, and monitoring guard the protected action and leave a record” is explicit in the diagram. That is why Build the Review Record matters to the chapter’s later acceptance decision.

6.5 Check Whether the Layers Still Stand

This 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.

The deeper layer covers the principles that decide whether a layered design is genuinely strong and why allowed-only testing is misleading.