Hook / Why This Matters
CISSP Lens: Pick answers that align business risk, governance intent, and practical control execution.
Saltzer and Schroeder published their design principles in 1975. Nearly fifty years later, most breaches still violate at least one of them. These principles are not academic history. They are the checklist every system design should pass before deployment, and the CISSP exam tests them repeatedly.
Core Concept Explained Simply
Secure system design principles are foundational rules that guide how systems should be built to minimize security risk. Most of them originated from a 1975 paper by Jerome Saltzer and Michael Schroeder, and they remain remarkably relevant because they address fundamental properties of secure systems rather than specific technologies.
Least Privilege
Every user, process, and service should operate with the minimum permissions required for its task. Nothing more. A logging service does not need write access to a payment database. An intern does not need domain admin rights. Least privilege limits the blast radius when something goes wrong.
Fail-Safe Defaults
The default state should be "deny." Access is granted by explicit exception, not assumed by default. If a firewall rule is not defined, traffic should be blocked. If an authorization check fails, access should be denied. Systems should fail closed, not open.
Economy of Mechanism
Simpler systems are easier to secure. Every additional component, feature, or integration adds potential attack surface. This does not mean less capable. It means avoiding unnecessary complexity. A straightforward access control mechanism that can be fully audited is more secure than an elaborate one that nobody fully understands.
Complete Mediation
Every access to every resource should be checked against the access control mechanism every time. No caching of authorization decisions. No "you were authorized an hour ago so you are still authorized now." This principle is the foundation of zero trust architecture, which assumes nothing about prior authorization and verifies every request.
Open Design
The security of a system should not depend on the secrecy of its design or implementation. Kerckhoffs' principle in cryptography is a specific application of this: the algorithm should be public, and only the key should be secret. Security through obscurity is not security.
Separation of Privilege
Require multiple conditions or multiple parties to perform sensitive actions. Two-person integrity for nuclear launch is an extreme example. Requiring both a password and a hardware token for authentication is a common one. No single point of compromise should be sufficient.
Least Common Mechanism
Minimize the amount of mechanism shared between users or between trust levels. Shared resources create shared risk. If two users share the same system component, a compromise of that component affects both users.
Psychological Acceptability
Security controls must be usable. If a password policy requires 30-character passwords changed weekly, users will write them on sticky notes. If MFA adds five minutes to every login, users will find workarounds. When users bypass security, the design has failed, not the users.
Zero Trust as a Modern Expression
Zero trust architecture is essentially complete mediation applied to modern networks. Never trust, always verify. Every request is authenticated and authorized regardless of network location. It is not a product. It is the application of these decades-old principles to current infrastructure.
CISSP Lens
These principles appear across multiple CISSP domains. Least privilege shows up in access control (Domain 5). Fail-safe defaults appear in operations (Domain 7). Economy of mechanism matters in software development (Domain 8). The exam tests your ability to identify which principle is being applied or violated in a scenario.
The two most commonly tested are least privilege and fail-safe defaults. If a question describes excessive permissions, the answer relates to least privilege. If a question describes a system that allows access when it cannot verify authorization, the answer relates to fail-safe defaults.
Zero trust questions are increasingly common and connect directly to complete mediation.
Real-World Scenario
A cloud application used a single broad IAM role for all its microservices. The development team assigned the same permissions to every service for convenience during rapid development. The logging service, the notification service, and the payment processing service all shared identical access to every database, storage bucket, and API.
When an attacker compromised the logging service through a dependency vulnerability, they inherited the permissions of the payment processing service. They accessed customer payment data, exfiltrated records, and the breach affected over 200,000 accounts.
Post-incident analysis revealed that if each microservice had been assigned only the permissions it needed (least privilege) and if the services had been separated so that compromising one did not grant access to others (separation of privilege), the attacker would have gained access only to log data. The blast radius would have been negligible instead of catastrophic.
Common Mistakes and Misconceptions
- Treating least privilege as a one-time configuration. Permissions drift over time. Least privilege requires ongoing review and adjustment as roles and responsibilities change.
- Building overly complex security mechanisms. Complex systems are harder to audit, harder to maintain, and more likely to contain flaws. This directly violates economy of mechanism.
- Caching access decisions for performance. Caching authorization tokens or session decisions without re-checking violates complete mediation and creates windows where revoked access is still honored.
- Making security so painful that users bypass it. If your controls generate complaints and workarounds, you have a psychological acceptability problem, not a user discipline problem.
- Relying on obscurity as a security layer. Hidden API endpoints, undocumented ports, and proprietary algorithms are not security controls. They are delays at best.
Actionable Checklist
- Audit service accounts and application roles for excessive permissions
- Verify that default-deny rules are in place for firewalls, IAM policies, and application access controls
- Review system complexity and identify components that could be simplified
- Check whether access decisions are re-validated on each request or cached with long expiration
- Survey users for security controls they routinely bypass and investigate the root cause
- Evaluate shared resources between trust levels for isolation gaps
- Implement periodic access reviews to catch privilege drift
Key Takeaways
- These principles are nearly 50 years old and still describe most security failures
- Least privilege and fail-safe defaults are the two most impactful in practice
- Economy of mechanism means simpler is more secure, not less capable
- Complete mediation is the foundation of zero trust architecture
- If users bypass your controls, the design has failed, not the users
Exam-Style Reflection Question
An application caches a user's authorization token for 24 hours to improve performance. Which design principle does this most directly violate?
Answer: Complete mediation. This principle requires that every access be checked against the access control mechanism. Caching tokens for 24 hours means changes to permissions (revocation, role changes) are not enforced until the cache expires, creating a window of unauthorized access.