10 Foundational Principles for Secure System Design

Posted on Dec 12, 2025 in Computers

10 Core Security Principles in One Line

  1. Economy of Mechanism

    Keep it small and simple.

    • Do: Minimize features and Lines of Code (LoC) in the TCB.
    • Don’t: Add non-critical features in the critical path.
    • Why: Fewer bugs, easier audits.
    • Example: Remove optional TLS extensions; use minimal parsing libraries.

  2. Fail-Safe Defaults

    Default deny; whitelist, not blacklist.

    • Do: Permit access only when explicitly allowed; fail-closed on errors.
    • Don’t: Expose services publicly by default.
    • Example: Firewalls drop traffic by default; S3 buckets are private by default.

  3. Complete Mediation

    Check every access, every time.

    • Do: Re-validate authorization on use (short-lived claims or sessions).
    • Don’t: Authorize once at login and trust forever (Time-of-Check to Time-of-Use, or TOCTOU).
    • Example: Check subscription status on each video fetch, not only at sign-in.

  4. Open Design

    Security doesn’t depend on secrecy of design.

    • Do: Assume attackers know the internals; keep only cryptographic keys secret.
    • Don’t: Rely on hidden URLs, obscure ports, or obfuscation for protection.
    • Example: Public protocol specifications and audited code; private keys remain secret.

  5. Separation of Privilege

    Require two or more independent conditions.

    • Do: Implement the Two-Person Rule, 2FA, or dual signatures.
    • Don’t: Allow one role to create and approve the same payment transaction.
    • Example: Both Dany’s and Jorah’s keys are needed to open the crypt.

  6. Least Privilege

    Just-enough, just-in-time, then revoke.

    • Do: Apply scope and duration limits; use read-only access by default.
    • Don’t: Run services as root; grant overly broad tokens.
    • Example: sudo with per-command policy; short-lived cloud credentials.

  7. Least Common Mechanism

    Avoid shared components.

    • Do: Use per-tenant storage or queues; utilize private temporary directories.
    • Don’t: Write privileged files into shared /tmp directories.
    • Example: Use O_NOFOLLOW flags and random private directories for privileged writes.

  8. Psychological Acceptability

    Usable defaults that match mental models.

    • Do: Use clear labels and warnings; ensure safe defaults are visible in the UI.
    • Don’t: Use ambiguous terms (e.g., “Any authenticated user”).
    • Example: Display “Public internet access = OFF (recommended)”.

  9. Work Factor

    Raise attack cost above the attacker’s budget.

    • Do: Implement rate limits, proof-of-work mechanisms, and strong keys.
    • Don’t: Ignore brute-force economics.
    • Example: Implement lockouts and backoffs; use 128-bit security for long-lived data.

  10. Compromise Recording

    Make tampering evident; log reliably.

    • Do: Use tamper-evident logs (hash chains, digital signatures, Write Once Read Many/WORM storage).
    • Don’t: Allow attackers to edit or delete audit trails.
    • Example: Use append-only logs with external timestamps.

Reference Monitor and TCB: A Quick Mental Model

  • Reference Monitor: Interpose on every subject-to-object access; enforce policy; audit.
  • Must be complete, tamper-proof, and verifiable.
  • TCB (Trusted Computing Base): Minimal code and configuration the policy depends on. Smaller is better.

Common Security Pitfalls and Violations

  • “Hidden URL/port” violates Open Design.
  • “Authorize at login only” breaks Complete Mediation, causing Time-of-Check to Time-of-Use (TOCTOU) vulnerabilities.
  • “Wide admin token forever” violates Least Privilege.
  • “Install = public, no auth” violates Fail-Safe Defaults.
  • “Shared /tmp for root logs” violates Least Common Mechanism.
  • “One person can create and approve” violates Separation of Privilege.
  • “Hard to configure safely” violates Psychological Acceptability.

Security Assessment Rubric and Answer Template

  1. Goal and Threat: Which of CIA (Confidentiality, Integrity, Availability) plus Authentication (AuthN) or Non-repudiation is at stake?
  2. Principle: Name the relevant principle; provide a one-line definition.
  3. Application: Provide one concrete Do, one Don’t, and one relevant Example.
  4. Result: State a clear yes/no verdict; provide a short justification. Use falsifiable statements (e.g., “re-validates each request” versus “secure”).

Essential Security Checklists

  • Defaults: Deny by default; private; no public binding; minimal scopes.
  • Authorization (AuthZ): Per-request checks; short sessions; revoke access on change.
  • Secrets: Keep keys secret; rotate regularly; never rely on obscurity.
  • Operations (Ops): Logs are append-only; alerts on anomalies; backups stored offline.
  • Design: Keep the TCB tiny; avoid shared primitives; document clearly.

Security Principles Mnemonics for Quick Recall

  • S-S-S: Simple (Economy), Safe by default (Fail-Safe), Separation (Privilege).
  • 3L: Least privilege, Least common mechanism, Log compromise (Recording).
  • ROK: Re-check on use (Mediation), Open design, Keep keys secret.