4.1.1. Foundational Principles: Least Privilege, Defense in Depth, Fail Securely
💡 First Principle: Each secure design principle corrects a specific architectural failure mode. Applying them is not about following rules — it is about anticipating how a system will fail and designing out those failure modes before they become exploits.
Least Privilege — grant subjects (users, processes, services) only the minimum permissions necessary to accomplish their defined function, for only as long as needed.
Why it matters: An attacker who compromises a low-privilege account can only damage what that account can access. Misconfigured service accounts running as DOMAIN ADMIN have repeatedly enabled complete domain compromise from a single software vulnerability.
Implementation: Role-based access control (RBAC), just-in-time (JIT) privilege escalation, service accounts with minimal permissions, regular access reviews to remove accumulated rights.
Separation of Duties (SoD) — no single individual should have sufficient access to complete a sensitive, high-risk, or fraud-prone process alone.
Why it matters: SoD is the primary control against insider fraud. A purchasing manager who also approves invoices and processes payments can create fraudulent vendors and pay them without a second person seeing the transaction.
Classic SoD pairs: Code developer ≠ code deployer to production; transaction initiator ≠ transaction approver; security rule writer ≠ security rule auditor; data entry ≠ data verification.
Defense in Depth — layer multiple independent security controls such that an attacker must defeat several layers to succeed, and failure of any single control does not result in full compromise.
Why it matters: No single control is perfect. Layering controls provides resilience: if the perimeter firewall is bypassed, the internal network segmentation limits lateral movement; if lateral movement occurs, EDR detects the malicious behavior; if EDR is evaded, the privileged access management system blocks credential escalation.
Fail Secure (Fail Closed) — when a system fails or encounters an error, it should default to a more secure state rather than a less secure state.
Why it matters: Systems fail. The question is whether failure opens or closes doors. A firewall that fails open (allows all traffic when it crashes) is worse than no firewall — it provides a false sense of security. A firewall that fails closed (blocks all traffic when it crashes) impacts availability but maintains security.
Fail open vs. fail secure: Availability-critical life-safety systems (hospital door locks during fire) intentionally fail open — this is the rare justified exception where security is traded for safety. Most systems should fail secure.
Zero Trust Architecture — never implicitly trust anything based on network location. Verify every access request as if it originates from an untrusted network, regardless of where it comes from.
Core Zero Trust principles:
- Verify explicitly — authenticate and authorize every request; use all available signals (identity, location, device health, service, data)
- Use least privilege access — limit access with just-in-time, just-enough-access policies
- Assume breach — design as if the attacker is already inside; minimize blast radius; verify end-to-end encryption
Why it matters: The traditional perimeter model ("trust inside the network, block outside") fails when attackers gain internal network access (via phishing, supply chain, insider threat). Zero Trust eliminates the concept of a trusted perimeter.
Additional principles:
| Principle | Definition | Design Implication |
|---|---|---|
| Keep it simple (KISS) | Complexity is the enemy of security; complex systems have more failure modes | Prefer simple, understandable designs over clever, complex ones |
| Open design | Security should not depend on secrecy of the design (only the keys/credentials) | Security through obscurity is not security |
| Complete mediation | Every access attempt to every object must be verified — no caching of authorization | Access control checks cannot be skipped for performance |
| Economy of mechanism | Security mechanisms should be small and simple enough to be verified correct | Audit and certify code; limit attack surface |
| Psychological acceptability | Security mechanisms must be usable enough that users don't circumvent them | Unusable security gets bypassed; design for real user behavior |
| Audit and accountability | All security-relevant actions must be logged with sufficient detail for forensic reconstruction | Nonrepudiation requires complete, tamper-evident audit trails |
⚠️ Exam Trap: "Fail secure" and "fail safe" mean different things in different contexts. In security architecture, "fail secure" means default to denied access. In safety engineering, "fail safe" means default to the state that prevents physical harm (which may require opening locks). The CISSP exam uses "fail secure" to mean security-first failure; know both meanings and apply the correct one given the scenario context.
Reflection Question: A new API endpoint processes financial transactions. The architect proposes that authenticated users can call any transaction endpoint — access is verified at login, not per-request. Which secure design principle is being violated? What is the correct design, and what attack does the current design enable?
