Saltzer and Schroeder: the first eight principles

A checklist, not a philosophy

In 1975 Jerome Saltzer and Michael Schroeder wrote down eight principles for the design of protection mechanisms. Half a century later they are still the checklist an architect runs a design against, and they are still what an exam asks you to reproduce. Two things about them are worth knowing before you start memorising. First, they are design principles: they constrain how a mechanism is built, not which threats it stops. Second, they are not independent — honouring one sometimes costs you another, and the design work is in the trade.

The examinable demand is specific: state the principle and give an example. A definition alone is worth roughly half. So the whole of this lesson hangs on one system, and every principle is applied to it in turn.

The system: Northgate Labs

Northgate Labs is a research building. Every door has a card reader; every employee, contractor and visitor carries a badge; a central access controller holds the rules and decides. A desk in reception issues badges. Somewhere in the basement there is an isotope store that must not open for the wrong person, ever. Everything below is a decision someone actually has to make about Northgate.

1. Economy of mechanism

Keep the security design as small and as simple as it can be, because you can only test and verify what you can hold in your head, and every extra branch is somewhere for a flaw to hide. It is the hardest of the eight to honour, because feature requests always argue against it.

At Northgate the whole rule engine is one table: (badge, door group, time window). Three columns, one lookup, reviewable in an afternoon. A rejected alternative let each department upload its own rule script; that design reached four thousand lines nobody could review, and one department's pattern match — meant to grant the loading bay to couriers — matched every badge whose number began with C, which was a third of the building.

2. Fail-safe defaults

Base access decisions on permission rather than exclusion. The default is no access; you name what is allowed, not what is forbidden. Note carefully what this is not: it is not "the system should fail into a safe state after a crash". That is fault tolerance. Fail-safe defaults is about the default answer being deny.

A newly issued Northgate badge opens nothing at all until a door group is attached to it. The alternative — a badge that opens everything except a deny list — fails in the direction that hurts: the day nobody remembers to add the new isotope store to the deny list, every contractor in the building can walk in. There is a second, sharper argument. A bug in a permit-listing mechanism denies access that should have been granted: somebody is locked out, they complain within the hour, you fix it. A bug in a deny-listing mechanism grants access that should have been refused: nobody complains, and you find out from the incident report.

3. Complete mediation

Every access is checked against the access-control authority — every access, every time. The temptation this principle exists to resist is caching a decision. Northgate's readers ask the controller on each swipe. The cheaper design pushes a permitted-badge list to each reader overnight; dismiss someone at 09:00 and their badge still works until midnight.

Be honest about the concession, because examiners like it: real systems violate complete mediation routinely. A UNIX process that has a file open keeps its access when the file's permissions change, because the check happened at open and is not repeated per read. Full compliance would mean an authority check on every field of every record, which is usually too expensive to do. Knowing that it is a concession, and what the concession buys and costs, is the answer.

4. Open design

The design of the mechanism is open; only the keys are secret. The reasoning is about review: a published mechanism gets examined by people who do not work for you, and flaws surface before an attacker finds them privately. This is why the modern encryption and hash standards were chosen through open, public competitions rather than designed behind a door.

Northgate's badges run a published challenge–response protocol with a per-badge key held in the card's secure element. Publishing the protocol costs nothing, because knowing how the challenge works does not tell you the key. The building this design replaced used a proprietary scheme whose security rested on nobody knowing the algorithm; once it was reverse-engineered, a cloner that fitted in a coat pocket copied any badge held near it. Note the boundary: open design is not the same claim as "you must publish your source code". It is that your security must not depend on the design staying secret.

5. Separation of privilege

Require more than one privilege attribute to reach the protected thing. In its original sense this is multifactor: two independent credentials, so compromising one is not enough. In its modern extended sense it also means splitting a program so that the high-privilege operations live in their own small component and the day-to-day interface runs unprivileged.

Northgate's isotope store needs a badge and a PIN typed at the door. And issuing a badge that carries isotope-store rights takes two people: a requester and a separate approver, each with their own credential. Neither the receptionist nor the lab manager can do it alone. Before that rule, one receptionist under social-engineering pressure could mint a badge for any door in the building.

6. Least privilege

Every user and every process operates using the fewest privileges the task needs — and, the part people forget, only for as long as the task lasts. Role-based access control is the usual implementation.

At Northgate a cleaner's badge opens corridors, cleaning cupboards and the loading bay, and no laboratory. The facilities manager does hold an open every door role, but it is granted for the duration of a declared incident and expires after two hours; the rest of the year her badge behaves like everyone else's. The design this replaced gave everybody a role called staff that opened every door, which is one privilege too many for 400 people, every day, forever.

7. Least common mechanism

Minimise the mechanisms shared between users. A shared mechanism is two liabilities at once: it is a potential communication path between users who should not be able to signal each other, and it is a single component that every user depends on, so it must be verified to the standard of the most sensitive user.

Northgate gives each department its own rule set and its own badge-printing station, so the visitor pass produced in reception and the staff badge produced in security do not flow through one machine. The design it replaced had a single pool of numbered temporary badges handed out at the desk and returned at the end of the day. Everybody's exceptional access ran through one shared credential, no swipe could be attributed to a person, and one lost badge was an anonymous key to the shared pool's whole door group.

8. Psychological acceptability

Security must not unduly obstruct the work the user is there to do, and the mechanism should match the user's mental model of what is being protected — because a mechanism people find intolerable is a mechanism they route around, and one they misunderstand is a mechanism they misconfigure.

Northgate's door unlocks in under a second from a badge already clipped to a lanyard, so nobody has a reason to defeat it. The first design was a two-door airlock at the single main entrance that took twelve seconds per person; within a week the staff had wedged the fire door open with a block of wood, and the building's real access control was that block of wood. The mechanism was not weak. It was unacceptable, which turned out to be the same thing.

Reading the eight back

Run a design past them in order and you will usually find the gap. Is it small enough to verify? Does it deny by default? Does it check every time? Does it survive publication? Does it demand more than one credential where it matters? Does it hand out the least it can, for the least time? Does it share as little as possible between users? And will the people who have to live with it actually leave it switched on?