Secure Design Principles & Zero Trust
Nguyên tắc Thiết kế An toàn & Mô hình Zero Trust
Key Terms
8 Secure Design Principles
These principles, originally from Saltzer & Schroeder (1975), form the foundation of every CISSP architecture question. Learn all 8 cold — the exam tests them by scenario, not by name.
| # | Principle | Tiếng Việt | Definition | FinTech Company X Example |
|---|---|---|---|---|
| 1 | Least Privilege | Đặc quyền tối thiểu | Grant only the minimum access needed to perform a function — nothing more | Per-lender scoped tokens in Platform C — Partner A token cannot access Partner D data |
| 2 | Separation of Duties | Phân tách nhiệm vụ | Split critical tasks across multiple people or roles so no single person can commit fraud or error alone | Developers cannot deploy: code requires PR review (peer) + ArgoCD approval (ops) |
| 3 | Defense in Depth | Phòng thủ theo chiều sâu | Layer multiple independent security controls so that if one fails, others still protect the asset | CloudFlare WAF → Kubernetes NetworkPolicies → mTLS → AES-256 encryption → audit trail |
| 4 | Fail-Safe Defaults | Mặc định từ chối | Default access is DENY. Access is only granted by explicit allowance, never by omission | PII incident: missing default encryption → data stored unencrypted in production → shutdown |
| 5 | Economy of Mechanism | Đơn giản hóa | Keep security mechanisms as simple as possible. Complex systems have more vulnerabilities and are harder to verify | HashiCorp Vault as single secrets management mechanism — no ad-hoc secrets scattered across repos |
| 6 | Complete Mediation | Kiểm soát đầy đủ | Check EVERY access to every object, every time — not just at initial login or cached from a previous check | Row-level tenant isolation enforced on EVERY database query — not assumed from login context |
| 7 | Open Design | Thiết kế mở | Security must not depend on keeping the algorithm secret (Kerckhoffs's Principle). Only the KEY must be secret | AES algorithm is publicly known; security depends entirely on keeping the encryption key secret in Vault |
| 8 | Psychological Acceptability | Chấp nhận tâm lý | Security controls must be usable enough that people actually follow them — overly complex controls get bypassed | MFA adds friction but must not be so burdensome that engineers share credentials or create backdoors |
Zero Trust Architecture (ZTA)
Zero Trust rejects the traditional "trust but verify" model (implicit trust inside the perimeter). ZTA operates on the principle: "Never trust, always verify." Every access request is authenticated and authorized regardless of network location.
Always authenticate and authorize based on all available data — identity, location, device health, service, workload, data classification.
Limit user access with just-in-time and just-enough-access policies and risk-based adaptive policies to protect data and productivity.
Minimize blast radius. Segment access. Encrypt all sessions end-to-end. Use analytics to detect threats and improve defenses.
Platform C Application of Zero Trust
| ZTA Pillar | Platform C Implementation | How It Works |
|---|---|---|
| Verify Explicitly | mTLS between all microservices | Every service-to-service call presents a certificate — no implicit trust within the Kubernetes cluster |
| Use Least Privilege | Per-lender scoped JWT tokens | Partner A service token is scoped only to Partner A data — a compromised token has limited blast radius |
| Assume Breach | Datadog alerting + audit trail | All access logged; anomaly alerts fire on unusual query patterns — detect the breach, don't just prevent it |
ZTA vs Traditional Perimeter: Traditional security trusts everything inside the corporate network ("castle and moat"). Zero Trust eliminates this implicit trust — a malicious insider, compromised internal service, or attacker who crossed the perimeter cannot move laterally because every request is re-verified.
- Fail-Safe Default: default = DENY. Any system that defaults to "allow" violates this principle. The PII incident is a perfect example — unencrypted-by-default violates Fail-Safe Default.
- Open Design ≠ open source: Security must NOT depend on keeping the algorithm secret. Only the KEY must be secret (Kerckhoffs's Principle). AES is published; its security comes entirely from the key.
- Complete Mediation: checks every access — not cached from the first login. If a permission is revoked but the cache is not cleared, Complete Mediation is violated.
- Defense in Depth: the controls must be INDEPENDENT. If all controls fail together (same root cause), it's not true defense in depth.
- Kerckhoffs's Principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." This is the basis of modern cryptography.
The PII exposure incident occurred because encryption was NOT the default behavior for new services. When a new data service was deployed, it required the developer to explicitly opt IN to encryption — but in the rush of a release, this step was skipped.
The fix (Platform C ORM layer): AES-256-CTR encryption is now MANDATORY in the ORM layer. A developer cannot call save() on a PII model without it being encrypted automatically. The default state is "encrypted" — unencrypted storage requires an explicit opt-out with a security review approval and justification in Jira.
Principle applied: Fail-Safe Defaults — the system now defaults to the secure state. Economy of Mechanism — one ORM-level control enforces encryption everywhere, rather than each service implementing its own encryption logic.
Practice Questions
Q1. A new microservice deployed to production stored customer PII in plaintext because the team forgot to enable encryption. The security policy did not explicitly require encryption as the default configuration. Which secure design principle was violated?
A. Fail-Safe Defaults — the system should default to encrypted (secure) state, not unencryptedQ2. Platform C issues JWT tokens that are scoped per lending partner (Partner A, Partner D) so that a token issued for Partner A cannot retrieve Partner D customer data. Which design principle does this BEST exemplify?
A. Least Privilege — tokens are granted only the minimum access required for their specific lender contextQ3. A vendor argues that their encryption product is secure because the algorithm is proprietary and secret. A security architect rejects this argument. What principle supports the architect's position?
A. Kerckhoffs's Principle (Open Design) — a system's security must not depend on algorithm secrecy; only the key should be secretQ4. In Zero Trust Architecture, Platform C services mutually authenticate using certificates before any API call. Which ZTA pillar does this implement?
A. Verify Explicitly — mTLS ensures every service presents proof of identity for every connection, regardless of network locationQ5. A web application checks user permissions at login and caches the result for the session. A user's permissions are revoked during the session, but they can still access restricted data until they log out. Which principle is violated?
A. Complete Mediation — access must be verified on every request, not cached from the initial login check