Security Design Principles

EncryptionEncryption, Firewalls, and SQL Injection each cover one specific technique or vulnerability. This page covers the layer above all of them: the design principles a system should be built against in the first place, so that the specific techniques have something coherent to serve.

The CIA Triad

AlmostAlmost every security goal reduces to some combination of three properties:

The three genuinely trade off against each other rather than always reinforcing one another — a system locked down so tightly that legitimate users are routinely denied access has sacrificed availability for confidentiality; a system replicated across ten servers for availability has multiplied its attack surface and made confidentiality harder to guarantee everywhere at once. A security design that only asks "is this confidential enough" while ignoring what it costs the other two properties is incomplete by construction.

Saltzer and Schroeder's Design Principles

SaltzerSaltzer and Schroeder's 1975 paper set out a small set of principles for designing secure systems that has aged remarkably well — most of it still describes exactly what goes wrong in modern security failures¹.

• Economy of mechanism — keep the design as simple as possible. A smaller, simpler access-control system has fewer places for a subtle flaw to hide than a large, flexible one with many special cases.
• Fail-safe defaults — default to denying access, and require an explicit grant to allow it, rather than defaulting to allow and requiring an explicit deny. A forgotten permission then fails toward "too restrictive," not "wide open."
• Complete mediation — check every single access to every resource, every time, rather than checking once and caching the result indefinitely. A permission revoked after the first check must still be enforced on the second access.
• Open design — the system's security should not depend on attackers not knowing how it works (security through obscurity), but survive its design being fully public, with only keys and credentials kept secret. A cryptographic algorithm that only stays secure because nobody has reverse-engineered it yet is not, by this principle, actually secure.
• Separation of privilege — require more than one condition to grant access to something sensitive, rather than a single check. Two-factor authentication is a direct, modern instance of this principle: a stolen password alone is no longer sufficient.
• Least privilege — every process and user should operate with the minimum access actually needed for its current task, not the maximum it might conceivably need someday. A web server process that only needs to read static files shouldn't run with permission to write to the whole filesystem.
• Least common mechanism — minimise the amount of infrastructure shared between users or processes with different trust levels, since shared mechanism is a shared channel for one to affect another. A single database account used by every microservice violates this even if each service's own logic is otherwise sound.
• Psychological acceptability — a security mechanism people find so cumbersome they route around it (writing a complex password on a sticky note, disabling a screen lock) provides less real security than a slightly weaker mechanism people actually use as intended.

What unifies all eight is a consistent scepticism about relying on things going right — fail-safe defaults, complete mediation, and least privilege all assume something will eventually be misconfigured or exploited, and ask how to limit the damage when it happens, rather than assuming a single well-designed check at the perimeter is enough.

References