The Protection of Information in Computer Systems.

Saltzer, & Schroeder. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1278-1308.

Type

Journal article

Intellectual base

Primary research

Year

1975

Volume

63

Issue

9

Pages

1278-1308

DOI

10.1109/proc.1975.9939

DOI registrant

Institute of Electrical and Electronics Engineers

Link

https://doi.org/10.1109/PROC.1975.9939

Cited from

chemistry_materials, computer_science, engineering_design, law_governance, mathematics, military_strategic_studies, philosophy, political_science, security_intelligence, statistics_experimental_design, systems_cybernetics

Cited by

45 citations across 45 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.

• 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.

    Supported in partVerified against the publisher's abstract

    The abstract confirms only that the paper sets out information-protection design principles in Section I; it never names 'separation of privilege' and says nothing about corporate boards.

    “Section I describes desired functions, design principles, and examples of elementary protection and authentication mechanisms.”

    Read by an automated reader; not a human review. How support was checked

• 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.)

• 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.

    Supported in partVerified against the publisher's abstract

    The abstract shows Saltzer & Schroeder present design principles for information protection, but says nothing about the attacker-one-hole / defender-all-points asymmetry attributed to them.

    “The paper develops in three main sections. Section I describes desired functions, design principles, and examples of elementary protection and authentication mechanisms.”

    Read by an automated reader; not a human review. How support was checked

• 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.

    Supported in partVerified against the publisher's abstract

    Abstract frames information protection as an architectural-structure problem, backing 'separate by structure' but not 'filter by content' or the claimed cross-field recurrence.

    “It concentrates on those architectural structures-whether hardware or software-that are necessary to support information protection.”

    Read by an automated reader; not a human review. How support was checked

• 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.

• Data Integrity
  • The layered protection approach (network + application + storage + organizational controls)

    Supported in partVerified against the publisher's abstract

    The abstract supports layered architectural protection and design principles, but never names the network, application, storage, or organizational layers the claim enumerates.

    “It concentrates on those architectural structures-whether hardware or software-that are necessary to support information protection. The paper develops in three main sections. Section I describes desired functions, design principles, and examples of elementary protection and authentication mechanisms.”

    Read by an automated reader; not a human review. How support was checked

• 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.

    Supported in partVerified against the publisher's abstract

    The abstract shows the paper sets out protection design principles and treats capability systems versus access-control lists, but it does not name secure-by-default configuration, least-privilege defaults, or sandboxing.

    “It examines in depth the principles of modern protection architectures and the relation between capability systems and access control list systems, and ends with a brief analysts of protected subsystems and protected objects.”

    Read by an automated reader; not a human review. How support was checked

• 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.

    Supported in partVerified against the publisher's abstract

    The abstract supports S&S 1975 as a treatment of architectural structures and design principles for protection, but it does not state that protection failures stem from mediation architecture rather than operator error.

    “It concentrates on those architectural structures-whether hardware or software-that are necessary to support information protection.”

    Read by an automated reader; not a human review. How support was checked

• 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.

• 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).

• 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.

    Supported in partVerified against the publisher's abstract

    The abstract confirms the paper sets out protection design principles and contrasts capability systems with access-control lists, but it states nothing about least privilege, need-to-know, or any transfer into organizational role design.

    “Section I describes desired functions, design principles, and examples of elementary protection and authentication mechanisms.”

    Read by an automated reader; not a human review. How support was checked

• 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.

    Supported in partVerified against the publisher's abstract

    Supplies the design-principle frame and capability-based protection mechanisms; it does not attest the itemized manifestations (per-process network permissions, user/root separation, sandboxing).

    “It examines in depth the principles of modern protection architectures and the relation between capability systems and access control list systems, and ends with a brief analysts of protected subsystems and protected objects.”

    Read by an automated reader; not a human review. How support was checked

• 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.

• 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.

• 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.

    Supported in partVerified against the publisher's abstract

    Abstract confirms a tutorial on protecting computer-stored information and design principles, but never names least privilege or separation of privilege, and the PDF has no readable text.

    “This tutorial paper explores the mechanics of protecting computer-stored information from unauthorized use or modification. It concentrates on those architectural structures-whether hardware or software-that are necessary to support information protection.”

    Read by an automated reader; not a human review. How support was checked

• 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.

• 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.

Mechanisms

• Access-Controlled Topic
  • Its strength is that it makes the broker safe to share for sensitive streams: authorization travels with the subject, provenance is established at publish, and — with end-to-end protection — even the trusted intermediary is prevented from being a single point of total exposure, honoring least privilege

    This sourceDefines least privilege as granting each user and program only the minimum privileges needed to perform its task.

• Access Restoration Ladder
  • It converts one high-stakes trust decision into several low-stakes ones, and it embodies the security discipline of least privilege

    This sourceDefines least privilege as giving each program or user only the privileges necessary to complete the authorized job.

• Boolean Guard Clause
  • Its fail-closed default is a genuine safety property.

    This sourceDefines fail-safe defaults as granting access only through explicit permission and denying it when authorization cannot be established.

• Capability or Authorization Revalidation
  • Its strength is that authority is checked at every use, so a revocation or role change bites immediately rather than at the next login — the discipline of complete mediation, every access to every object checked against current authority.

    This sourceDefines complete mediation as checking every access to every object for authority and warns that cached authorization results must be updated when authority changes.

• 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.

• Data Quality Recertification
  • The classic misuse is scoping the cycle so broadly that no owner can meaningfully judge any single item, violating least privilege

    This sourceDefines least privilege as giving each program and user only the privileges necessary to complete the job.

• Fail-Closed or Fail-Open Design
  • Its failure mode is a mismatched default: choosing the direction that protects the wrong value, so failure fails dangerously — a fail-open where security was the greater hazard, or a fail-closed that traps people.

    This sourceShows why an exclusion-based security default can fail dangerously by allowing access, while default denial fails safely.

• Fallback Mode Register
  • It is also where fail-safe defaults

    This sourceDefines fail-safe defaults as basing access decisions on explicit permission rather than exclusion, so omitted cases default to refusal.

• Firewall
  • Its strength is a cheap, fast, coarse perimeter that enforces least privilege

    This sourceDefines least privilege as giving each user or program only the privileges needed for its task, including through compartmentalized access.

• Graduated Reliance and Bounded-Exposure Trial
  • Its strength is that it produces the most credible evidence there is — direct representative performance — while capping downside, and it embodies the principle of least privilege: grant only the reliance the current evidence supports, and no more.

    This sourceDefines least privilege as operating with only the minimum privileges necessary to complete the task.

• 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.

• Least-Privilege Review
  • Its strength is that it enforces the principle of least privilege
• Output Validation
  • A default of clamping rather than blocking can mask a real defect, letting a broken producer keep shipping "fixed-up" outputs indefinitely; the safer default when a result can't be validated is to fail closed — withhold rather than release.

    This sourceDefines fail-safe defaults as withholding access unless permission has been explicitly granted.

• Permission Inheritance with Explicit Denial
  • The discipline that guards against this is the principle of least privilege

    This sourceStates the principle of least privilege: each user and program should receive only the privileges necessary for the task.

• Permission Scope or Capability Token
  • Its strength is a hard, enforced cap on blast radius: an unauthorized surface stays untouched even when the acting code is buggy, compromised, or an over-eager automated agent.

    This sourceDefines least privilege as a strict authority limit that reduces the damage a buggy program can cause.

• Permission-Scoped Default
  • This is the principle of least privilege

    This sourceDefines least privilege as granting each program and user only the privileges necessary for the task.

• Platform Sandbox and Capability Permissions
  • The discipline is the principle of least privilege

    This sourceDefines least privilege as granting each user and program only the permissions needed for its task, with authorization, accountability, auditing, and revocation treated as protection-system concerns.

• Privilege Scope Restriction
  • The principle behind it is least privilege — during impairment, no actor should retain more power than the immediate, defensible need

    This sourceStates that each program and user should operate with only the least privilege necessary to complete the task.

• Privileged Host Escape Hatch
  • The rare need was met without widening the everyday interface or leaving a permanent hole behind — which is exactly what the principle of least privilege asks for.

    This sourceDefines least privilege as granting a user or program only the privileges necessary to complete its task.

• Protected-Self Allowlist with Expiry
  • It is least-privilege

    This sourceStates the least-privilege principle: every program and user should operate with only the privileges necessary for the task.

• Rejection or Quarantine Queue
  • Its strength is that it turns the failure branch into a designed outcome rather than an afterthought: content is denied by default and held safely, an instance of fail-safe defaults,

    This sourceDefines fail-safe defaults as granting access only by explicit permission rather than by exclusion.

• Safe Default-Map Fallback
  • Its strength is that it converts "unknown context" from the worst failure — a silent, confident mis-selection — into a safe, visible degraded mode; it is the archetype's honest answer to the fact that cues are sometimes genuinely ambiguous, a fail-safe rather than a fail-silent.

    This sourceStates the fail-safe-default principle: deny by default and permit only under explicitly identified conditions.

• Sandbox or Adapter Wrapper
  • The SDK runs with least privilege; its network calls go through an adapter that strips identifiers before anything leaves the device; its callbacks are validated at the boundary rather than trusted.

    This sourceStates the least-privilege principle: every program and user should operate with only the privileges necessary to complete the job.

• Scoped Service-Account Impersonation
  • It is the operational embodiment of least privilege for mediated action,
• Software Execution Sandbox
  • The discipline that keeps it honest is the principle of least privilege

    This sourceDefines least privilege as requiring every program and user to operate with only the smallest set of privileges necessary to complete the job.

• Stale Tooth Review
  • Its strength is that it directly attacks teeth that outlived their reason, and by putting a named owner on each decision it manufactures the removal sponsorship that ratchets structurally lack — the standard cure for privilege creep and the operational form of least-privilege maintenance.

    This sourceStates the least-privilege principle: every program and user should operate with only the privileges needed to complete the task.

• Strict Bidirectional Contract Gate
  • Fail closed on doubt. Anything the contract doesn't clearly permit is refused, not charitably interpreted

    This sourceStates the fail-safe-defaults principle: access is denied by default and granted only when an explicit permission condition is satisfied.

Verification

Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Read against the text for 9 of 45 citations: 9 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.

Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 1 other way.

• https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf ×1

Registry ID ref:7cb140963e57 · see in the full table