The Protection of Information in Computer Systems.¶
Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1278-1308.
Cited by¶
21 citations across 21 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Brandolini's Law
- Cybersecurity — an attacker needs one working exploit; a defender must close every vulnerability, so defender cost scales with the attack surface while attacker cost scales with a single path through it.
This sourceEstablishes the defender's negative-requirement burden — the protection mechanism must block all unauthorized access paths while an attacker needs only one — grounding the cybersecurity offense-defense cost asymmetry.
- Cybersecurity — an attacker needs one working exploit; a defender must close every vulnerability, so defender cost scales with the attack surface while attacker cost scales with a single path through it.
- Checks and Balances
- The same logic Saltzer and Schroeder (1975) formalized as "separation of privilege" in computer security applies broadly: corporate boards distribute authority between CEO, board committees (audit, compensation, nominating), and shareholder meetings.
This sourceFoundational paper establishing engineering principles — including least privilege and separation of privilege — as computational analogues of constitutional separation of powers, bridging the doctrine to security and software architecture.
- The same logic Saltzer and Schroeder (1975) formalized as "separation of privilege" in computer security applies broadly: corporate boards distribute authority between CEO, board committees (audit, compensation, nominating), and shareholder meetings.
- Complement
- The legal complement transfers into regulatory and security design: a regime in which the default is "permitted unless prohibited" and one in which it is "prohibited unless permitted" are the same structural construction — declare a universe, specify the explicit set, reason about the complement — differing only in which side receives the complement, and the same polarity choice reappears as allow-list versus deny-list in software security and as default-permitted versus default-blocked in content moderation.
This sourceStates the fail-safe-defaults principle — base access decisions on permission (allow-list / default-deny) rather than exclusion (deny-list) — the polarity choice over a declared universe in security design. (Resolves needs-source-935 with the canonical security-design reference.)
- The legal complement transfers into regulatory and security design: a regime in which the default is "permitted unless prohibited" and one in which it is "prohibited unless permitted" are the same structural construction — declare a universe, specify the explicit set, reason about the complement — differing only in which side receives the complement, and the same polarity choice reappears as allow-list versus deny-list in software security and as default-permitted versus default-blocked in content moderation.
- Containment
- This asymmetry—that an attacker needs only find one hole while a defender must protect all points—is fundamental to containment design, as Saltzer and Schroeder (1975) articulate in their classic principles of secure system protection.
This sourceFoundational paper establishing secure-system design principles — least privilege, separation of privilege, complete mediation, fail-safe defaults — that operationalize the defender-must-protect-all-points discipline of perimeter design.
- This asymmetry—that an attacker needs only find one hole while a defender must protect all points—is fundamental to containment design, as Saltzer and Schroeder (1975) articulate in their classic principles of secure system protection.
- Control / Data Channel Confusion
- What stays substrate-specific is only the recognition of which structural mechanism the medium offers and where the crafted-data crossing point sits; once those are located, the qualitative-not-quantitative logic — separate by structure, do not filter by content — applies without modification, which is why the same advice recurs verbatim from telephony engineers, database designers, browser architects, and language-model safety teams who never coordinated.
This sourceFoundational security-design paper establishing least privilege, capability-based protection, and structural (not content-based) separation as durable defenses.
- What stays substrate-specific is only the recognition of which structural mechanism the medium offers and where the crafted-data crossing point sits; once those are located, the qualitative-not-quantitative logic — separate by structure, do not filter by content — applies without modification, which is why the same advice recurs verbatim from telephony engineers, database designers, browser architects, and language-model safety teams who never coordinated.
- Data-Control Plane Breach
- The pattern compresses a sprawling cross-substrate vocabulary — parameterised queries, sandboxing, escaping, immune recognition, signature verification, source authentication, formal data-control separation — into one structural problem with one intervention family that travels across substrates. Structurally separate the channels: physically separate channels, parameterised interfaces, schema-constrained inputs, signed control directives, sandboxes with no host authority. Inertise at the crossing point: escaping, encoding, sanitisation, quoting, content scanning that runs before the interpreter sees the content. Mark-don't-trust: treat all incoming content as data by default and require explicit, strongly authenticated elevation to control.
This sourceFoundational security principles including least privilege (authority reduction) and complete mediation, underpinning the mark-don't-trust and reduce-authority remedies.
- The pattern compresses a sprawling cross-substrate vocabulary — parameterised queries, sandboxing, escaping, immune recognition, signature verification, source authentication, formal data-control separation — into one structural problem with one intervention family that travels across substrates. Structurally separate the channels: physically separate channels, parameterised interfaces, schema-constrained inputs, signed control directives, sandboxes with no host authority. Inertise at the crossing point: escaping, encoding, sanitisation, quoting, content scanning that runs before the interpreter sees the content. Mark-don't-trust: treat all incoming content as data by default and require explicit, strongly authenticated elevation to control.
- Data Integrity
- Designed-Out Misuse
- Cybersecurity: secure-by-default configuration, least-privilege defaults, sandboxing, capability-based security
This sourceCanonical statement of secure-design principles including least privilege, fail-safe defaults, and economy of mechanism — the security instance of designing out the misuse path.
- Cybersecurity: secure-by-default configuration, least-privilege defaults, sandboxing, capability-based security
- Escape and Leakage
- The signature emphasizes that escape is not primarily a failure of design intent but an inevitable consequence of boundary geometry, paralleling Saltzer and Schroeder's (1975) observation that protection failures stem from the architectural structure of mediation rather than from operator error.
This sourceFoundational survey of protection mechanisms and design principles (least privilege, complete mediation, separation of privilege); grounds the claim that protection failures stem from the architecture of mediation rather than operator error.
- The signature emphasizes that escape is not primarily a failure of design intent but an inevitable consequence of boundary geometry, paralleling Saltzer and Schroeder's (1975) observation that protection failures stem from the architectural structure of mediation rather than from operator error.
- Mandatory vs. Default Norms
- The architectural logic mirrors Saltzer and Schroeder's (1975) "fail-safe defaults" principle for protection mechanisms in computer systems: the baseline state should be the safe one, and any deviation must be the result of an explicit, auditable decision rather than a passive lapse.
This sourceFoundational paper establishing engineering principles—including least privilege and separation of privilege—as computational analogues of constitutional separation of powers, providing the theoretical bridge for transposing the doctrine to security and software architecture.
- The architectural logic mirrors Saltzer and Schroeder's (1975) "fail-safe defaults" principle for protection mechanisms in computer systems: the baseline state should be the safe one, and any deviation must be the result of an explicit, auditable decision rather than a passive lapse.
- Offensive Action
- The structural move is unilateral commitment of resources to a frame that puts rivals on the back foot. Litigation. Filing first to choose jurisdiction and court, framing the dispute around a narrow favorable question, and using motions practice and discovery to force the opponent to defend rather than prosecute its own theory. Cybersecurity. The attacker's asymmetric advantage is the offensive-action advantage: the defender must cover every surface, the attacker needs only one.
This sourceEstablishes security design principles underlying the attacker/defender asymmetry (the defender must cover every surface; the attacker needs one weakness).
- The structural move is unilateral commitment of resources to a frame that puts rivals on the back foot. Litigation. Filing first to choose jurisdiction and court, framing the dispute around a narrow favorable question, and using motions practice and discovery to force the opponent to defend rather than prosecute its own theory. Cybersecurity. The attacker's asymmetric advantage is the offensive-action advantage: the defender must cover every surface, the attacker needs only one.
- Permeability
- The vocabulary further clarifies the diagnostic of unintended permeability: information leaks, contaminant migration, mission creep, role bleed, and side-channel attacks all share the structure "a pathway exists through a medium assumed sealed against this carrier," and the intervention is to identify and gate that pathway, not to strengthen a perimeter that is doing fine on the intended carrier.
This sourceStates the principle of least privilege and need-to-know as design discipline for information-permeability/role-permission boundaries.
- The vocabulary further clarifies the diagnostic of unintended permeability: information leaks, contaminant migration, mission creep, role bleed, and side-channel attacks all share the structure "a pathway exists through a medium assumed sealed against this carrier," and the intervention is to identify and gate that pathway, not to strengthen a perimeter that is doing fine on the intended carrier.
- Principle of Least Privilege
- In operating systems and software, it appears as per-process file, network, and memory permissions, the separation of user from root, sandboxing, and capability-based security.
This sourceCanonical statement of the principle of least privilege and separation of privilege as design principles for protection mechanisms.
- In operating systems and software, it appears as per-process file, network, and memory permissions, the separation of user from root, sandboxing, and capability-based security.
- Rule of Least Power (Minimum Sufficient Capability)
- In security and systems administration, it appears as granting a process, user, or token only the rights its task requires, reducing blast radius on compromise.
This sourceStates the principle of least privilege: grant each component only the rights its task requires, reducing blast radius on compromise.
- In security and systems administration, it appears as granting a process, user, or token only the rights its task requires, reducing blast radius on compromise.
- Selective Information Severance
- In computer security, the principle of least privilege, compartmentalization, and need-to-know are severance: each process, service, or person is granted exactly the access required for its function and no more, so that a compromised component cannot reach data or systems it never had access to — the channel to everything beyond its need is severed precisely to limit the blast radius of a breach.
This sourceStates the principle of least privilege and need-to-know: each program and user should operate with the minimum access required for its function, so a compromise reaches only what it already held.
- In computer security, the principle of least privilege, compartmentalization, and need-to-know are severance: each process, service, or person is granted exactly the access required for its function and no more, so that a compromised component cannot reach data or systems it never had access to — the channel to everything beyond its need is severed precisely to limit the blast radius of a breach.
- Separation of Powers
- Modern applications extend the principle to corporate governance (board/management/audit separations), software architecture (separation of concerns in modular design), security protocols (separation of duties preventing single-actor compromise), data architecture (role-based access control), and AI safety guardrails (multiple independent oversight mechanisms)—a transposition foreshadowed by Saltzer and Schroeder's (1975) treatment of protection mechanisms in computer systems, where least privilege and separation of privilege were articulated as engineering analogues of the same structural principle.
This sourceFoundational paper establishing engineering principles—including least privilege and separation of privilege—as computational analogues of constitutional separation of powers, providing the theoretical bridge for transposing the doctrine to security and software architecture.
- Modern applications extend the principle to corporate governance (board/management/audit separations), software architecture (separation of concerns in modular design), security protocols (separation of duties preventing single-actor compromise), data architecture (role-based access control), and AI safety guardrails (multiple independent oversight mechanisms)—a transposition foreshadowed by Saltzer and Schroeder's (1975) treatment of protection mechanisms in computer systems, where least privilege and separation of privilege were articulated as engineering analogues of the same structural principle.
- Sequestration
- Saltzer and Schroeder (1975) make this distinction explicit in computer security: their "principle of complete mediation" and "least privilege" treat isolation as an active enforcement property, not a passive partition.
This sourceFoundational paper establishing engineering principles—including least privilege and separation of privilege—as computational analogues of constitutional separation of powers, providing the theoretical bridge for transposing the doctrine to security and software architecture.
- Saltzer and Schroeder (1975) make this distinction explicit in computer security: their "principle of complete mediation" and "least privilege" treat isolation as an active enforcement property, not a passive partition.
- Union
- In access control and capability systems it is the granting of additional rights: a principal's effective permissions are the union of the permissions conferred by each of its roles, so adding a role can only expand capability (the upward-monotone dual of intersection's restriction).
This sourceFoundational treatment of access control whose principles underlie role-based permission grants, where effective rights are the union of each role's permissions and adding a role can only expand capability.
- In access control and capability systems it is the granting of additional rights: a principal's effective permissions are the union of the permissions conferred by each of its roles, so adding a role can only expand capability (the upward-monotone dual of intersection's restriction).
Mechanisms¶
- Cross-Boundary Flow Gate
- A gate is only as good as its rules, and a single over-permissive rule or one forgotten side-path can defeat the whole thing — which is why the safe default is least privilege
This sourceDefines least privilege as granting each program and user only the privileges necessary to complete the job.
- A gate is only as good as its rules, and a single over-permissive rule or one forgotten side-path can defeat the whole thing — which is why the safe default is least privilege
- Least-Privilege Execution Context
- Its strength is that it degrades gracefully: it is the mechanism that makes an interpreter compromise survivable, and it applies even when the input defenses are imperfect or the parser is a black box, because it constrains the environment rather than the content
This sourceExplains that limiting a program to the privileges needed for its task constrains its operating environment and limits damage from compromise or error.
- Its strength is that it degrades gracefully: it is the mechanism that makes an interpreter compromise survivable, and it applies even when the input defenses are imperfect or the parser is a black box, because it constrains the environment rather than the content
- Least-Privilege Review
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Registry ID ref:7cb140963e57 · see in the full table