4.1. Secure Design Principles
💡 First Principle: Secure design principles are not a checklist — they are a design philosophy that trades some convenience for a dramatically reduced attack surface. Every principle addresses a different way systems fail: too much access granted, single points of failure, no default protection, trusted perimeters that collapse when breached. Applied together, they create systems that are resistant to both external attack and insider abuse.
The principles in this section are foundational to every other domain. Access control models (Domain 5) implement least privilege. Network architecture (Domain 4) implements defense in depth and segmentation. Incident response (Domain 7) depends on audit and accountability. Understanding these principles as a connected design philosophy rather than isolated rules is what separates architectural thinking from checklist compliance.
Why this matters: Secure design principle questions are almost always scenario-based: "A developer is designing a new API. Which principle does requiring separate credentials for read and write operations implement?" You need to recognize the principle from its manifestation in a real design decision.
⚠️ Common Misconception: Many candidates conflate Bell-LaPadula (confidentiality model) and Biba (integrity model), assuming they are interchangeable or that one supersedes the other. They address entirely different security properties and cannot substitute for each other. A system implementing Bell-LaPadula provides no integrity guarantees; a system implementing Biba provides no confidentiality guarantees. Most real systems need both — which is architecturally complex because their rules point in opposite directions.
