Security Architecture and Engineering · Topic 1 of 8
Secure Design Principles
CISSP secure design principles: least privilege, defense in depth, secure defaults, fail securely, separation of duties, zero trust, privacy by design.
- 3 min
- Least privilege, defense in depth, secure defaults, fail securely, separation of duties, simplicity.
- Zero trust: verify every request; no implicit trust from location.
- Privacy by design: privacy as the default, built in from the start.
What it is
Secure design principles are rules of thumb that make systems harder to attack and easier to secure. Applying them during design is far cheaper than fixing weaknesses after release. Exam questions describe a design choice and ask which principle it shows, or which principle a flawed design breaks.
How it works
The principles
| Principle | Meaning | Example |
|---|---|---|
| Threat modeling | Identify threats during design | STRIDE review of a new application |
| Least privilege | Give only the rights needed for the task | A reporting account with read access to one table |
| Defense in depth | Several independent layers of control | Input validation at the API plus parameterized queries |
| Secure defaults | Out of the box, the system is in its most secure reasonable state | Default deny, no default passwords |
| Fail securely | On error, fall into a safe state | Deny access when the authorization service is down |
| Separation of duties | Split critical tasks so no one person can complete them alone | Developer cannot deploy their own code to production |
| Keep it simple and small | Less complexity means fewer flaws | Minimal services on a server |
| Zero trust | Never trust by network location; verify every request | Per-request authentication and authorization |
| Privacy by design | Build privacy into systems from the start | Data minimization, privacy as the default setting |
| Trust but verify | Grant trust, but check that it is deserved | Monitoring and auditing privileged users |
| Shared responsibility | Security duties split between parties, for example in cloud | Provider secures the infrastructure; customer secures data and identities |
| Secure access service edge (SASE) | Networking and security delivered together from the cloud | Secure web gateway, CASB and zero trust access as one service |
Defense in depth needs diversity
Layers only help if they fail independently. Three layers that use the same detection engine all miss the same new threat. Add controls that work differently, such as behaviour-based endpoint detection alongside signature scanning.
Fail securely (fail closed) is the default for security controls. For life-safety systems such as emergency exits, the safe state is open: people come first.
Zero trust in practice
Zero trust assumes the network is hostile. Access decisions use identity, device health and context for each request, and grant the least access needed. Micro-segmentation limits lateral movement. It is a strategy, not a single product.
Privacy by design principles
Proactive not reactive, privacy as the default, privacy embedded into design, full functionality (positive-sum), end-to-end security, visibility and transparency, and respect for user privacy.
Shared responsibility models
| Service model | Customer is responsible for (typically) |
|---|---|
| IaaS | Operating system, applications, data, identities, network configuration |
| PaaS | Applications, data, identities |
| SaaS | Data, identities, access configuration |
The customer always remains responsible for its data and who can access it.
How the exam asks about this
- "A bank runs the same malware engine at every layer and a zero-day evades all three." Add diverse, behaviour-based detection.
- "An application denies requests when the authorization service is unreachable." Fail securely.
- "Developers cannot approve their own production changes." Separation of duties.
What to remember for the exam
- Least privilege, defense in depth, secure defaults, fail securely, separation of duties, simplicity.
- Zero trust: verify every request; no implicit trust from location.
- Privacy by design: privacy as the default, built in from the start.
- Shared responsibility: the customer always owns its data and identities.
- Defense in depth needs independent, diverse layers.
Security through obscurity is not a design principle. Hiding how a system works adds little protection on its own.
Common mistakes
Layering identical controls and calling it defense in depth.
Failing open on security controls.
Assuming the cloud provider secures your data.
Check yourself
Which principle is shown when a system denies access because the authorization service is unavailable?
Fail securely.
What does zero trust replace?
Implicit trust based on network location.
In SaaS, which security responsibilities stay with the customer?
Its data, identities and access configuration.
Topic 1 of 8 in Security Architecture and Engineering
Test yourself on Security Architecture and Engineering
The full ISC2 CISSP question bank has 1,113 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.