CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 5

Playbook 5 of 22 · Secure by Design · Architectural Foundations

Defence in depth

Layers, like a castle: wall, moat, gate and guards, so one failure is not the end.

Architectural FoundationsSecure by Design
CyberForte's summary · not ENISA text

In plain words

No single lock is perfect. Defence in depth means you put several independent protections around the things that matter most, so if one fails or is bypassed, the next one still holds.

The layers should not all share the same weak spot. Two locks that open with the same key are really one lock. Add logging and alerts at each layer too, so you notice when someone is testing the gates, and have a way to isolate a part that has been compromised.

Picture this: A device might check a signed update file, run it only after login, and log the change. Three layers, three chances to stop or spot a bad update.

Your turn

Practical checklist

A short, practical version for small teams, written by CyberForte from the ENISA playbook. The full ENISA checklist, evidence list and release gate are in the original text below. Your ticks are saved only in this browser.

Original text · unchanged

The full ENISA playbook

Source: ENISA Secure by Design and Default Playbooks, 05-defence-in-depth.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Defence in depth

Principle

(secure by design)

Apply multiple layers of security so that the failure or bypass of a single control does not result in full compromise.

Objective

Reduce the impact of security failures by layering independent controls that slow attackers, increase detection and prevent single points of compromise.

Checklist

Layer controls around critical assets

  • Identify the most sensitive assets (e.g. credentials, control functions, customer data).
  • Ensure that more than one independent control protects each asset.
  • Where critical data or commands cross trust boundaries, consider integrity and freshness controls that remain effective if another protection layer, such as transport security, is bypassed.

Assume control failure and design for containment

  • Design systems so that bypass of one control does not grant unrestricted access.

Enable detection at multiple layers

  • Generate security-relevant logs at key layers (identity, network, application, data).
  • Ensure that failed and suspicious actions raise alerts and are not silently blocked.

Use diverse and independent controls

  • Avoid relying on multiple controls that share the same technology, identity source or trust assumption.

Slow attackers and enable response

  • Apply controls that increase attacker effort and time (rate limits, step-up authentication, staged access).
  • Ensure that response mechanisms exist to contain or isolate compromised components when alerts are triggered.

Minimum evidence

  • Layered protection mapped: a simple table or diagram showing critical assets and the multiple security controls protecting each (stored in repo/wiki).
  • Independent controls confirmed: configuration or design notes showing that layered controls do not rely on the same identity source or enforcement point.
  • Multilayer logging enabled: log configuration or sample logs showing security events recorded across controls.
  • Alerts and response defined: alert rules or playbook reference showing how suspicious activity is detected and the associated containment or response action.

Release gate

  • [ ] Critical assets have more than one security control applied and the layering is documented.
  • [ ] Layered controls are independent; no single identity source or enforcement point is a single point of failure.
  • [ ] Security-relevant events are logged at multiple layers
  • [ ] Alerts are in place for suspicious activity and a response action exists
↑ ↓ to moveEnter to openEsc to close