Question
What is Defense in Depth ("layered security")?
Answer
The idea that no single security control is sufficient — protect each asset with multiple, independent layers, so that if one fails the others still hold.
* Nested layers around the asset — the attacker must breach every one; the defender needs only one to hold. *
A typical onion looks like:
| Layer | What it protects against | Examples |
|---|---|---|
| Perimeter Security | Bulk unwanted traffic | Firewall, edge router, WAF |
| Network Security | Lateral movement, MITM | Segmentation, VLANs, IDS/IPS |
| Endpoint Security | Compromised devices | EDR, disk encryption, OS hardening |
| Application Security | App-level bugs | Secure coding, auth, input validation |
| Data Security | Theft of the data itself | Encryption at rest, access controls |
| Critical Assets | The thing you actually care about | Strict need-to-know, audit logging |
Why layered? Every individual control has a non-zero failure rate (zero-days, misconfigurations, insider mistakes, supply-chain compromises). Stacked controls multiply the attacker's work — they don't just have to find one bug, they have to defeat the whole stack.
Tip: The classic question to ask of any design — "if this control fails, what catches the attacker next?" If the answer is "nothing", you don't have defense in depth.
Go deeper:
Defense in depth (computing) — Wikipedia — layered controls and the assume-each-layer-fails mindset.
Note saved — thanks!
Question
What does Security by Design mean?
Answer
Build security into the system from the first day of design, and consider it in every phase of the lifecycle — not as a bolt-on at the end.
* Security is considered in every lifecycle phase — the earlier a flaw is caught, the cheaper it is to fix. *
The opposite is "build the feature, ship it, then have a security review tell us what's broken." That approach is catastrophically more expensive — the further into the lifecycle a flaw is found, the more rework it costs to fix.
What "from the start" looks like in practice:
- Requirements: security requirements alongside functional ones (data sensitivity, threat model, regulatory needs).
- Design: threat modelling (STRIDE, attack trees) before any code.
- Implementation: secure coding standards, automated SAST in CI.
- Testing: DAST, fuzzing, pen-testing.
- Deployment: hardened configs, secrets management.
- Maintenance: patch cadence, vulnerability monitoring, incident response.
Why it matters: a SQL-injection bug caught in design review costs maybe an hour of conversation. The same bug caught in production might cost a breach disclosure, regulatory fines, and rebuilding customer trust.
Tip: "Shift left" is the modern slogan for the same idea — move security activities earlier in the development pipeline.
Go deeper:
- Secure by design — Wikipedia — the principle and where it sits in the development lifecycle.
Note saved — thanks!