Don't Panic — Security Principles

Security principles are not a security appliance, a compliance form, or a particularly stern firewall. They are durable rules for deciding what a system must protect, who may act, and what happens when the machinery becomes uncooperative. Without them, a design tends to become a pile of product settings, exceptions, and hopeful glances at the audit log.

Start with the asset and the mission. Then name the harm worth preventing. Confidentiality limits unauthorized disclosure, integrity resists improper change, and availability keeps authorized use possible when it matters. Those goals do not always agree. More isolation can make a service harder to use. More redundancy can add more paths to defend. Security is therefore less a hunt for a magic setting than a record of which tradeoff is acceptable, for which threat, and why.

The useful chain is pleasantly bureaucratic because reality is worse: asset, threat, weakness, risk, requirement, principle, control, evidence, residual risk. A control is the safeguard you build. A principle explains why it has that shape. Narrow permissions are least privilege. A default-deny policy is fail-safe defaults. Checking an access request each time it reaches protected data is complete mediation, not an especially enthusiastic sign-in screen.

The classic principles are compact enough to fit on a card and inconvenient enough to keep earning their rent. Keep protection mechanisms understandable. Protect keys rather than the secrecy of the mechanism. Require independent approval for a sensitive action. Avoid shared components where they join trust domains. Make the safe path workable for a person doing ordinary work; otherwise the bypass will acquire a fan club.

The surprising part is that a secure failure does not always mean the same thing. A missing policy service might mean deny a sensitive request. A safety-critical exit can demand another behavior. The question is not whether a setting has the word secure attached to it. The question is what remains permitted, what evidence survives, and who owns the residual risk when a dependency fails.

Read the Intro when you need the full reasoning path and the eight classic principles. Use the Slides when you need the relationships between access, layers, and trust boundaries in one view. Keep the Cheatsheet nearby when reviewing a request path or a failure. The Practice Reference turns the principles into a repeatable design review, and the Exercise supplies a small system whose cheerful shortcuts deserve suspicious attention.