Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust
Key Takeaways
- Least privilege grants only the access required for the task, for the required time, under the required conditions.
- Defense in depth layers controls so one failure does not expose the entire environment.
- Secure by design builds security requirements into architecture and development instead of adding them after deployment.
- Zero trust removes implicit trust and continuously evaluates identity, device, context, and session risk.
- Security+ scenarios often combine these principles with business constraints such as usability, downtime, and auditability.
Security Principles in Practice
Security principles guide control selection when answer choices all sound reasonable. They help you decide which option reduces risk without creating unnecessary access, single points of failure, or unverified trust.
| Principle | Practical meaning | Scenario clue |
|---|---|---|
| Least privilege | Grant only required access | "Excess permissions", "temporary access", "admin rights" |
| Defense in depth | Use layered controls | "If one control fails", "multiple safeguards" |
| Secure by design | Build security in from the start | "New application", "architecture review", "requirements" |
| Zero trust | Verify explicitly and continuously | "No implicit trust", "device posture", "context-aware access" |
| Separation of duties | Split sensitive tasks across roles | "Same person requests and approves" |
| Fail secure | Default to a protected state when failure occurs | "If system fails, what should happen?" |
Least Privilege Scenario
A developer needs to troubleshoot a production application for one weekend.
| Weak answer | Better answer |
|---|---|
| Add the developer to Domain Admins | Grant scoped production read or break-glass access for the approved time |
| Share an administrator password | Use named account access with MFA and logging |
| Leave access in place for convenience | Set expiration and review after the work is complete |
Least privilege is about scope, time, and accountability.
Defense in Depth Scenario
A public web application handles customer profile data. A layered design might include:
| Layer | Example control |
|---|---|
| Edge | WAF, DDoS protection, TLS |
| Application | Input validation, secure session management, code review |
| Identity | MFA for admins, RBAC, privileged access management |
| Network | Segmentation between web, app, and database tiers |
| Data | Encryption at rest, key management, database permissions |
| Monitoring | Centralized logs, alerts, file integrity monitoring |
| Recovery | Tested backups and documented restoration steps |
If an attacker bypasses the WAF, segmentation and database permissions still limit impact.
Secure by Design Scenario
A team is building a new customer portal. Secure by design means security requirements are part of the project before launch.
| Design question | Strong requirement |
|---|---|
| Who can access sensitive records? | RBAC with least privilege and periodic access review |
| How is sensitive data protected? | Encryption in transit and at rest with managed keys |
| How are defects found? | Threat modeling, code review, dependency scanning, testing |
| What happens during failure? | Fail securely and log meaningful security events |
| How is evidence retained? | Centralized logs with retention aligned to policy |
Adding a WAF after launch can help, but it does not replace secure input handling, authentication, authorization, and logging in the design.
Zero Trust at Exam Speed
Zero trust does not mean "block everything forever." It means do not trust a request merely because it came from an internal network.
| Zero trust action | What it verifies |
|---|---|
| Strong authentication | User identity |
| Device posture check | Endpoint health and compliance |
| Context-aware policy | Location, risk, time, behavior |
| Least-privilege authorization | Exact allowed action |
| Continuous monitoring | Session changes and anomalies |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| "Internal network means trusted" | Zero trust requires explicit verification |
| "One strong control is enough" | Defense in depth expects layered failure resistance |
| "Admin rights are faster" | Least privilege favors scoped access, even during urgent work |
| "Security can be added later" | Secure by design starts at requirements and architecture |
| "Fail open is user friendly" | For sensitive systems, fail secure is often preferred |
A contractor needs access to one project repository for 14 days. Which option best applies least privilege?
Which statement best describes zero trust?
Which examples show defense in depth? Select all that apply.
Select all that apply