The Security Models That Are Still Running Under Everything You Use

CISSP Domain 3.2

In 1973, at the MITRE Corporation in Bedford, Massachusetts, David Elliott Bell and Leonard La Padula were trying to name a rule.

The rule was the important half of what would become the most-recited model in computer security. They had already worked out that a subject cleared to a given level must not be able to read anything above it. That one named itself: the simple security property. The other direction was harder to see and harder to say — that a subject holding secret information must not be permitted to write it somewhere less secret, whether or not it means to, whether or not it knows it is doing so. It is the rule that stops a Trojan horse running with your clearance from copying your mail into a world-readable file.

Thirty-two years later, Bell wrote down how they named it, at the 21st Annual Computer Security Applications Conference in Tucson in December 2005:

A condition to prevent deleterious flows was easily formulated, but a descriptive name was elusive. When I first raised the idea, I scribbled the heading “*-property” on the blackboard over a figure much like figure 2. After a burst of energetic discussion, I pointed out that if we didn’t change the name right then, we’d be stuck with it forever. Nothing came to us and we continued our discussion. “*-property” it remained.

Every CISSP candidate learns the star property. Tens of thousands of people have written it on an exam. It is drawn on whiteboards in security awareness sessions, printed in glossaries, tested in practice questions, and argued about in study forums. The star is a placeholder. Bell put it up because he needed a heading over a diagram, said out loud that they should replace it before it stuck, and nothing better arrived. It has been the name for fifty-three years.

A note on the date and the place, because this article is about checking things. Bell’s naming passage carries neither: the section is headed “Origin of *-property” and gives no year, no location and no head count. The 1973 and the Bedford come from his own reference list, which dates MTR-2547 Volume II — the volume that introduces the *-property — to 31 May 1973 at the MITRE Corporation, Bedford, Massachusetts.

That is a small story, and it is worth telling first for a reason that goes well past charm. CISSP Domain 3, section 3.2 — Understand the fundamental concepts of security models — is the most-recited and least-examined material in the whole syllabus. “No read up, no write down” is the single most repeated sentence in security education. Almost nobody reading it has opened the paper. And when you do open the papers, the certificates, the penalty notices and the evaluation reports behind this section, three things happen at once.

The first is that the models turn out not to be history. They are running, right now, in the operating system on your desk, in the phone in your pocket, in a European regulation about lorry tachographs, and in a court order that cost ten investment banks $1.4 billion.

The second is that the industry built on top of the models — the evaluation and accreditation machinery that the exam spends four of its seven subsections on — is in a much worse state than the exam suggests, and its own governing bodies have said so in writing.

The third is that a surprising amount of what is taught about this section is wrong in checkable ways. Not shades-of-emphasis wrong. Dates that are off by a decade, a statistic with no source anywhere, a classification level that does not exist, and a claim that a standard died ten years before its last certificate was issued.

This article walks all seven of the book’s subsections — 3.2.1 through 3.2.7 — and gives each one a real, named, dated case from the world outside the exam. Where CISSP is right, which is most of the time, that is said plainly. Where it is wrong, the correction comes with a source you can open yourself.

What the exam actually asks, which is one line

Start with the map, because the map is not what most candidates think it is.

The ISC2 CISSP Certification Exam Outline, effective 15 April 2024, states this objective in full as:

3.2 Understand the fundamental concepts of security models (e.g., Biba, Star Model, Bell-LaPadula)

That is the entire thing. There are no ISC2 sub-objectives 3.2.1 through 3.2.7. The seven-part breakdown that structures this article — Security Models, Enterprise Security Architecture, Layer-based Models, Rule-based Models, Certification and Accreditation, Evaluation Criteria, Common Criteria — is CISSP‘s own pedagogy laid over a single line. Domain 3, “Security Architecture and Engineering,” carries an average weight of 13% of the adaptive exam.

That is worth knowing for two reasons. It tells you the depth ISC2 is signalling, which is conceptual rather than encyclopaedic. And it means the book’s structure is a teaching decision that can be judged on its merits rather than a specification that must be obeyed.

There is also a small oddity in the official line, and it deserves exactly one sentence before we move on. ISC2’s three examples are “Biba, Star Model, Bell-LaPadula.” There is no security model called the Star Model. The *-property is a rule inside Bell–LaPadula — the very rule Bell named on the blackboard — not a model standing beside it. The outline lists a component of one of its own examples as a third example. It is a drafting slip, it has been there for years, and if a question ever leans on it, the answer it wants is Bell–LaPadula’s write rule. Now forget it; this article is not about ISC2.

---

3.2.1 — Security Models

What the book says

CISSP‘s core concept for this subsection is two sentences long:

A model is a representation of something real. A security model is a representation of what security should look like in an architecture.

The section then makes an argument that is the reason the whole of 3.2 exists:

Many people don’t value the importance of security models because many of them date back to the early ’70s, like Bell–LaPadula; but these still apply today. The conceptual, fundamental ways to address confidentiality that Bell–LaPadula highlights are the same today as they were in the ’70s… Technology changes, but the fundamental rules on how confidentiality is addressed remain the same.

And it closes with the decomposition principle that runs through all of Domain 3: to protect an architecture you break it into components, secure each one, remember that the chain is only as strong as its weakest link — and secure each component “to the degree that value dictates doing so.”

All of that is defensible. It is also, as printed, under-argued: the book asserts that the old models still apply and then moves on. The evidence for the assertion is much stronger than the book makes it look, and it is available in vendor documentation anyone can read.

The plain-English version, before the precision

A security model, stripped of its formality, is a set of rules about who may move information where. That is all. The models differ in what they are trying to stop.

Bell–LaPadula is trying to stop secrets leaking downhill. Biba is trying to stop garbage flowing uphill. Clark–Wilson is trying to stop a well-meaning authorised person from making a mess. Brewer–Nash is trying to stop somebody knowing two things at once that they should not know together. Information-flow models are trying to keep track of where data went so you can answer the previous four questions at all.

Everything else in this section — lattices, properties, access triples, tranquillity — is the machinery for stating one of those five intentions precisely enough that a computer can enforce it and a mathematician can check it. The precision is the point. “Don’t leak secrets” is an instruction to a person. *-property is an instruction to a kernel.

The models are shipping in current products, by name

The strongest answer to “why should I care about a 1973 paper” is that the vendors say the paper’s name in their own documentation.

Red Hat Enterprise Linux. SELinux’s multi-level security policy implements Bell–LaPadula explicitly. Red Hat’s own product documentation for RHEL 9:

To implement MLS, SELinux uses the Bell-La Padula Model (BLP) model. This model specifies how information can flow within the system based on labels attached to each subject and object.

The basic principle of BLP is “No read up, no write down.”

By default the MLS policy provides sixteen sensitivity levels, s0 through s15.

And then the detail that shows this is engineering rather than recitation. RHEL does not implement plain Bell–LaPadula. It implements what Red Hat calls

a modified principle called Bell-La Padula with write equality. This means that users can read files at their own sensitivity level and lower, but can write only at exactly their own level.

Red Hat adds a note directly beneath that passage, and it is worth keeping in view before treating write equality as absolute: “Security administrators can adjust this behavior by modifying the system’s SELinux policy.”

Look at what that is. The book lists three Bell–LaPadula principles: simple security (no read up), the *-property (no write down), and the strong star property, which permits reading and writing only at the subject’s own level. The strong star property gets one sentence in the book and is the principle candidates most often skip. Red Hat shipped it, because plain * permits write-up — a subject at s3 writing into an s9 file it cannot read back — and blind writes into data you cannot verify are an integrity disaster. The model gave them a menu; they picked the option the book treats as a footnote.

Red Hat also publishes the honest caveat, which is more useful to a working professional than the enthusiasm. From the RHEL 9 page:

Using MLS is complex and does not map well to general use-case scenarios.

(The equivalent RHEL 10 page words it slightly differently — “does not map well to typical use cases” — so quote the version you are citing.) MLS, Red Hat says, “meets a very narrow set of security requirements based on information management in rigidly controlled environments such as the military.” Hold that sentence; the whole “MLS failed commercially” argument is built on it, and we come back to it in 3.2.3.

Windows. Every Windows machine since Vista runs an integrity lattice modelled on Biba — and Microsoft published, in 2007, precisely which parts of Biba it declined to implement and why. That document is the single best real-world example in this entire article and it gets its own treatment in 3.2.3.

Meta. An information-flow lattice, in production, over an exabyte-scale data warehouse, enforcing privacy purpose limitation rather than military classification. Published July 2025. That one belongs to 3.2.4.

Three products, three of the models on the exam, all currently shipping, all documented by the vendor. The book’s claim is correct. It is just told in the wrong tense.

The result the book leaves out, and it is the reason models exist

CISSP gives the Harrison–Ruzzo–Ullman model a single sentence: it “focuses on the integrity of access rights via a finite set of rules available to edit the access rights of a subject. It adds the ability to add generic rights to groups of individuals.”

That is true and it is the least interesting thing about the paper.

Michael Harrison, Walter Ruzzo and Jeffrey Ullman published “Protection in Operating Systems” in Communications of the ACM in August 1976. They formalised protection as an access matrix — subjects down the side, objects across the top, rights in the cells — with six primitive operations that can change it: enter a right, delete a right, create a subject, create an object, destroy a subject, destroy an object. Then they asked the only question that matters about such a system. Given a configuration, can you determine whether some subject might eventually acquire some right over some object? They called it the safety problem.

From the paper’s abstract:

The “safety” problem for protection systems under this model is to determine in a given situation whether a subject can acquire a particular right to an object. In restricted cases, it can be shown that this problem is decidable, i.e. there is an algorithm to determine whether a system in a particular configuration is safe. In general, and under surprisingly weak assumptions, it cannot be decided if a situation is safe.

And, stated as a theorem:

THEOREM 2. It is undecidable whether a given configuration of a given protection system is safe for a given generic right.

The proof works by showing that a protection system of this general kind can simulate an arbitrary Turing machine, with — in the authors’ words — “leakage of a right corresponding to the Turing machine entering a final state, a condition we know to be undecidable.” Note the technical phrasing: entering a final state, which is not the same condition as halting, and the difference is theirs, not a nicety. Undecidable does not mean hard, or expensive, or not yet solved. It means no algorithm can exist. Not with more compute, not with better tooling, not in 2026 and not in 2126.

Sit with the operational consequence, because it is enormous and almost nobody teaches it. If you build a sufficiently general permission system — arbitrary rights, arbitrary delegation, subjects able to grant what they hold — then the question “can this configuration ever leak?” has no general answer. Your IAM policy language, your cloud permissions model, your role hierarchy with delegated administration: the more expressive you make it, the closer you get to the region where its own safety is not computable.

This is the intellectual spine of the entire section. It is why real systems do not use a general access matrix. It is why Bell–LaPadula constrains flow to a lattice, why SELinux compiles a fixed policy, why Kubernetes RBAC prevents privilege escalation by default and makes the exceptions explicit — the escalate verb, which lets a subject create or edit a role granting permissions it does not itself hold, and the bind verb, which lets it bind such a role, are named opt-outs precisely because the general case is the dangerous one — and why AWS built its policy analysis tooling on a restricted logic instead of on the general question. (That tooling is Zelkova, described in Backes et al., “Semantic-based Automated Reasoning for AWS Access Policies using SMT,” FMCAD 2018: IAM policies are encoded into SMT over strings, regular expressions, bit-vectors and integer comparison, and the resulting problem is PSPACE-complete — hard, but decidable, which is the entire point of not being general.) Every model on this exam is a deliberate reduction in expressiveness, bought in exchange for the ability to say something provable. Harrison, Ruzzo and Ullman are the reason that trade exists, and the book files them under “lesser known.”

If you take one idea from 3.2.1 into the exam room and into your job, take that one. Security models are not descriptions of good practice. They are restrictions chosen so that a question about the system becomes answerable.

Getting the citations right

The book says the models “date back to the early ’70s.” For Bell–LaPadula that is exact. For the rest of the table it is off by a decade or more, and precision here is cheap. These are the origins, verified against the UC Davis Early Computer Security Papers collection and against Bell’s own 2005 reference list:

Model	Origin
Bell–LaPadula	Bell & LaPadula, Secure Computer Systems, MITRE MTR-2547 / ESD-TR-73-278, Vols. I–III, 1973–74; unified with the Multics interpretation as MTR-2997, 1975, revised 1976
Graham–Denning	Graham & Denning, “Protection — Principles and Practice,” AFIPS Spring Joint Computer Conference, 1972
Lampson (confinement, covert channels)	Lampson, “A Note on the Confinement Problem,” CACM 16(10), October 1973
Biba	Biba, Integrity Considerations for Secure Computer Systems, MITRE MTR-3153, June 1975; reissued as ESD-TR-76-372, April 1977
Denning (information flow)	D.E. Denning, “A Lattice Model of Secure Information Flow,” CACM 19(5), May 1976
Harrison–Ruzzo–Ullman	“Protection in Operating Systems,” CACM 19(8), August 1976
Lipner	“Non-Discretionary Controls for Commercial Applications,” IEEE Symposium on Security and Privacy, 1982
Clark–Wilson	“A Comparison of Commercial and Military Computer Security Policies,” IEEE S&P, 1987
Brewer–Nash	“The Chinese Wall Security Policy,” IEEE S&P, 1989

Two corrections worth carrying. Biba is 1975, not 1977 — the 1977 date universally cited is the reissue. And the models span seventeen years, not one decade: Clark–Wilson and Brewer–Nash are products of the commercial 1980s, written to solve problems the 1973 military work could not express. That progression is the story of this section, and flattening it into “the early ’70s” throws it away.

---

3.2.2 — Enterprise Security Architecture

What the book says

The core concept, in the book’s words: “An architecture is a group of components that work together,” and “security architecture involves breaking down a system to its components and protecting each component based upon its value.”

The book then names three frameworks — Zachman, SABSA and TOGAF — says they “each basically do the same thing to protect any architecture,” and gives each a paragraph. Zachman answers “how, where, who, when, and why” by directing those questions at designers, owners, architects, strategists, engineers and operators. SABSA “focuses on security architecture risk and allows security to be embedded in IT functions.” TOGAF “focuses on efficient resource utilization and cost minimization” with a modular structure and a content framework.

Then it lays out the taxonomy that the following two subsections unpack: most security models are either lattice-based (which the book also calls layer-based, and illustrates with a ladder) or rule-based. Bell–LaPadula and Biba are the lattice ones. Information Flow, Clark–Wilson, Brewer–Nash, Graham–Denning and Harrison–Ruzzo–Ullman are the rule ones. Lattice models contain rules too, the book acknowledges, but “those rules are confined to layers within the model.”

That taxonomy is the book’s, and it is a reasonable teaching device rather than a fact about the literature. Denning’s 1976 lattice model is the general case of which Bell–LaPadula and Biba are instances — a point the book itself concedes three pages later when it says the information flow model “serves as the basis for both Bell–LaPadula and Biba.” Learn the table for the exam. Do not carry “two lattice-based models exist” into a design review.

Two of the three framework paragraphs contain a date problem, and one of them is a straightforward error.

Zachman is 1987, and here is probably where the wrong date came from

The book says Zachman is “an older model dating back to the ’70s.”

The framework was published in 1987. The paper is J.A. Zachman, “A framework for information systems architecture,” IBM Systems Journal, Volume 26, Number 3, 1987, pages 276–292, IBM reprint order number G321-5298, carrying the copyright line “© Copyright 1987 by International Business Machines Corporation.” It was extended in 1992 by John Sowa and Zachman in the same journal, renamed “Enterprise Architecture — A Framework” in 1993, and given graphic revisions in 2001, 2004 and 2011. Zachman International is careful to note that Version 3.0 in 2011 “is NOT a new Framework – it is a new Framework graphic.”

Zachman’s own account puts the first draft at 1984, with three columns rather than six. So the honest range is conceived 1984, published 1987. Either way, not the ’70s.

There is a plausible explanation for the error sitting on the last page of the paper itself. The author biography on page 292 says Zachman “joined IBM in 1965… has been involved with Strategic Information Systems Planning methodologies since 1970 and came to his present position in 1973.” That is a career start, not a framework birth. Somebody read the bio, took the 1970, and dated the framework from it; the date then propagated through a generation of secondary summaries. I offer that as a likely path rather than a proven one — the bio text is verifiable, the causal story is inference.

Why does a seventeen-year date error matter? Because it changes what the framework is. A 1970s artefact predates the personal computer, relational databases in commercial use, and the entire discipline of enterprise architecture. A 1987 artefact is a response to the mid-1980s explosion of distributed systems inside large enterprises, written by a man whose day job at IBM was helping enormous organisations work out what they even had.

And there is a second dating error to avoid while correcting the first, one that a great deal of secondary material commits — including, very nearly, this article. The six-by-six grid that people picture when they hear “Zachman” is not what the 1987 paper contains. Zachman limits himself, on page 279, in terms that leave no room:

Therefore, the remainder of this paper will be limited to the three types of descriptions contained in Table 3. For future reference, Appendix A is included and contains a preliminary, Table 3-like characterization of the additional descriptive types related to people (who), time (when), and motivation (why).

Three columns in the body — the data, process and network descriptions, the what, how and where — with who, when and why sketched in an appendix “for future reference.” The rows in 1987 are the ballpark or scope view, the owner’s, the designer’s, the builder’s and the out-of-context view. The remaining three columns were formalised by Sowa and Zachman in 1992. The six perspective names that circulate today — executive, business management, architect, engineer, technician, enterprise — belong to the Version 3.0 graphic of 2011, twenty-four years after the paper. Zachman International’s own evolution page says of the 1984 draft: “Notice it has only 3 Columns.”

So the 1987 framework is a classification scheme, and a deliberately small one, precisely because its author’s problem was inventory and coherence, not security. The book is right that Zachman “merely focuses on classification and organization.” That is what it was for — and the small version makes the point better than the big one, because a three-column inventory scheme is an even more obvious answer to “what do we even have” than a six-by-six ontology is.

The real Zachman adopter: the US federal government

The named, documented, primary-source adoption is the US Federal Enterprise Architecture Framework. From A Practical Guide to Federal Enterprise Architecture, published by the Chief Information Officer Council, Version 1.0, February 2001:

In September 1987, John Zachman published an important article in the IBM Systems Journal identifying what he called “A Framework for Information Systems Architecture”… In fact, the Zachman Framework provides much of the foundation for the FEAF and the frameworks of several Federal Departments and Agencies.

And, specifically:

The FEAF currently includes the first three columns of the Zachman framework and the Spewak EA planning methodology.

That is the whole US federal executive branch’s architecture guidance, resting on the first three columns of a 1987 IBM paper — and note that those are precisely the three columns the 1987 paper actually develops. Read against the six-by-six graphic, “the first three columns” looks like an arbitrary truncation. Read against the paper, it is the whole of it. Note also that the CIO Council says “September 1987” while the journal article itself carries only Volume 26, Number 3, 1987 with no month — cite the volume and issue, not a month.

SABSA: an honest gap, reported as a gap

This is the one place in this article where the example you would expect does not exist, and saying so is more useful than filling the hole.

What is verifiable about SABSA: it was developed in 1995 by David Lynas, John Sherwood and Andy Clark, and first published in 1996 — J. Sherwood, “SALSA: A method for developing the enterprise security architecture and strategy,” Computers & Security, Volume 15, Number 6, 1996, pages 501–506. Note the original acronym in that title: SALSA, not SABSA. The three authors published Enterprise Security Architecture: A Business-Driven Approach with CRC Press in 2005. The SABSA Institute’s own submission to NIST says “The first SABSA paper was published 1996” and gives no 1995 date at all.

So the book’s “adopted in 1995” should read devised in 1995, first published in 1996. “Adopted” is a word no source supports; nobody adopted anything in 1995 because nothing had been published yet.

The book also calls SABSA “an open source framework.” That description could not be verified. The SABSA Institute operates a paid certification scheme, and no licence text stating open-source terms could be found on its site. Treat “open source” as unconfirmed rather than wrong.

And here is the gap. I could not find a named enterprise SABSA deployment in an independent primary source. There is a named deployment — Sherwood’s own account on sabsa.org returns repeatedly and first-hand to S.W.I.F.T., the interbank messaging cooperative: “I need to develop an information security architecture for S.W.I.F.T.” But that is the framework’s co-author writing about his own consulting work, which is a different evidential thing from a user organisation publishing its own architecture. The two claims that circulate most widely — that the UK Ministry of Defence adopted SABSA as an information assurance standard in 2007, and that the Government of Canada adopted it as an architecture development standard — could not be traced to any government document; they appear in search snippets and vendor marketing. They are not printed here as adoptions.

The closest verifiable thing is genuinely better than a case study would have been — and note that it is a different claim from the untraceable Canadian one above: adopting the framework as a standard is not the same act as citing its layer model inside a document. The second is what can be shown. The Canadian Centre for Cyber Security builds its published technical guidance on the SABSA layer model. From Calculating robustness for boundary controls, ITSP.80.032, March 2019, footnote 1:

The words control, service, mechanism, and product refer to architectural elements at the conceptual, logical, physical, and component layers of architecture respectively, based on the Zachman and SABSA enterprise architecture models.

A national cyber agency’s live guidance, structuring its own vocabulary on SABSA’s layering, and naming Zachman in the same breath. That is a framework doing work. It is also the shape of how these frameworks actually spread — not as branded programmes with case studies, but as vocabulary that ends up inside somebody else’s standard.

TOGAF is a declassified Department of Defense artefact

The book describes TOGAF accurately: efficient resource utilisation, cost minimisation, modular structure, a content framework for consistency, architectural flexibility. What it does not say is where TOGAF came from, and the answer reframes this whole domain.

From The Open Group’s own document W061, The Open Group Architecture Framework (TOGAF) and the US Department of Defense Architecture Framework (DoDAF), November 2006:

The US Department of Defense developed a series of architecture guidance documents in the early 1990s known as the Technical Architecture Framework for Information Management (TAFIM)… The TAFIM was matured to Version 3.0 and then provided to The Open Group… TAFIM was the baseline for the development of The Open Group Architecture Framework (TOGAF) in 1995 and was subsequently retired. The US Defense Information Systems Agency (DISA) contributed heavily to the development of TOGAF 1.0…

The current release is The TOGAF Standard, 10th Edition, launched 25 April 2022.

Now count. TOGAF, the vendor-neutral commercial architecture framework, is a handed-over US Department of Defense artefact. The Orange Book is a Department of Defense standard. Bell–LaPadula was MITRE work for the US Air Force Electronic Systems Division. SELinux began at the NSA. Four of the seven subsections in this section of the syllabus trace to the same funder. Whatever you think about that, it explains the shape of the material: everything here was built by people whose threat model was a nation-state adversary and whose budget was not a constraint, and the commercial world has spent fifty years working out which parts it can afford.

The real TOGAF adopter: Indian Railways

Named, documented, and recent. The Centre for Railway Information Systems (CRIS), under the Ministry of Railways, Government of India, built the freight and parcel segment architecture for Indian Railways under Project VISTAR, using the India Enterprise Architecture (IndEA) framework developed by India’s Ministry of Electronics and Information Technology, which is itself based on the TOGAF standard. It is published by The Open Group as document Y251, Indian Railways Freight Business Architecture: A Segment Architecture of the Indian Railways Enterprise Architecture, dated 17 June 2025.

That is enterprise architecture applied to one of the largest freight operations on earth, through a national framework derived from TOGAF, documented last year. Other current, named Open Group TOGAF case studies include Nan Shan Life Insurance (Y256) and Beijing UINO Technology (Y254).

A note for anyone building their own reading list: the classic TOGAF case studies that circulate in training material — Dairy Farm Group, Westpac, Litton PRC, the UK MoD — no longer resolve on The Open Group’s site. Use the current ones.

What to take from 3.2.2

The exam wants three names, their focus, and the lattice/rule taxonomy. Take those. But the professional lesson in this subsection is the one the book’s framing obscures: these frameworks are classification schemes, and a classification scheme’s value is entirely in whether the organisation actually uses its vocabulary. Zachman’s win is that the US federal government wrote three of its columns into FEAF. SABSA’s most verifiable win is a footnote in a Canadian standard. TOGAF’s is a freight architecture for Indian Railways. None of those is a product purchase. All of them are somebody else’s document adopting the words.

---

3.2.3 — Layer-based Models: Bell–LaPadula, Biba, Lipner

What the book says

The core concepts, verbatim: layer-based models are also lattice-based models; “Bell–LaPadula addresses only confidentiality”; “Biba addresses only integrity”; and “Lipner implementation is not a model; it is an implementation that combines the best features of Bell–LaPadula and Biba.”

Bell–LaPadula, three principles as the book gives them:

1. Simple security property — “no read up.” A subject at a security level may not read an object at a higher level.
2. The star (*) property — “no write down.” A subject at a security level may not write to an object at a lower level.
3. The strong star property — read and write at your own layer, “nothing higher and nothing lower.”

Biba, three principles as the book gives them:

1. Simple integrity property — “no read down.” A subject at an integrity level may not read an object at a lower integrity level.
2. Star (*) integrity property — “no write up.” A subject may not write to an object at a higher integrity level.
3. Invocation property — a subject cannot send information to someone rated at a higher layer than the subject holds.

Lipner separates objects into data and programs, and applies sensitivity levels and job categories to subjects, to get confidentiality and integrity at once.

That is all accurate. What follows is what those rules look like when somebody has to ship them.

What a lattice actually is, in plain English

The book’s ladder image is fine but it is a chain, and a lattice is not a chain. A chain is Unclassified below Confidential below Secret below Top Secret: everything comparable to everything else. Real classification is not like that. Real classification is a level plus a set of compartments — Secret with access to CRYPTO, Secret with access to NUCLEAR, Secret with both.

Now ask: is “Secret / CRYPTO” higher or lower than “Secret / NUCLEAR”? Neither. They are incomparable. Neither dominates the other, and information must not flow in either direction.

That is the whole reason the word lattice is used instead of ladder. A lattice is a partial order in which any two elements have a unique least upper bound — a smallest label that dominates both. For “Secret / CRYPTO” and “Secret / NUCLEAR” that least upper bound is “Secret / CRYPTO, NUCLEAR.” Which gives you the operational rule that matters: when you combine two pieces of data, the result carries the join of their labels. Mix anything with anything and the answer is the smallest label that covers both.

That single rule is why the lattice formulation won, and it is exactly the rule Meta wrote for its data warehouse in 2025 without using any of this vocabulary. We get there in 3.2.4.

The pairing of the two models is best remembered by what each is afraid of. Bell–LaPadula is afraid of a secret escaping, so it lets you read below you and write above you. Biba is afraid of contamination arriving, so it does the opposite — reads above you and writes below you. Confidentiality flows up, integrity flows down. That inversion is the most-tested thing in this section and the most-forgotten under pressure.

Biba in the wild: Windows, and the half Microsoft deliberately did not build

This is the best-documented real-world example in this article, because it contains all three things you almost never get in one place: the model, the shipping product, and the vendor’s own written reason for the compromise.

Since Windows Vista, every Windows object carries a mandatory integrity level. Ross Anderson’s Security Engineering, third edition:

Windows, since version 6 (Vista), marks file objects with an integrity level, which can be Low, Medium, High or System, and implements a default policy of NoWriteUp. Critical files are at System and other objects are at Medium by default – except for the browser which is at Low.

The browser sits at Low. That is Biba’s *-integrity property doing its job: the browser is the process most likely to be executing an attacker’s content, so it is placed where it cannot write to anything that matters. Every Windows user has been running a Biba lattice since 2007 without being told.

Now the interesting half. Microsoft published an architecture paper, What is the Windows Integrity Mechanism?, dated 5 July 2007, which sets out the resemblance and then the departure. First the resemblance:

The Windows integrity mechanism resembles the Biba model in the following ways:

• It uses a hierarchy of integrity labels (integrity labels are not the same as security labels in the Bell-LePadula model).
• The system uses a set of ordered subjects, objects, and integrity levels.
• The subject’s integrity level dominates (is greater than or equal to) the object’s integrity level.
• Integrity policies inhibit access to objects but are not used primarily to limit the flow of information.
• Preventing information disclosure is not a goal of the integrity mechanism in Windows Vista.

Then the departure, and this is the passage worth memorising:

The strict integrity model in Biba does not allow a higher-integrity process to read lower-integrity data. This is sometimes called a “no-read-down” integrity policy. The Windows integrity policies… do not inhibit or prevent higher-integrity subjects from reading or executing lower-integrity objects. There are many examples of attacks where reading malformed, untrusted input data results in an exploit of a vulnerability in an application and arbitrary code execution. The Windows integrity mechanism does not inhibit or prevent reading data at any level. Windows does not enforce a strict integrity policy described in the Biba model.

Microsoft names the exact attack class that no-read-down would have prevented — a privileged process parsing hostile input and being taken over — and then says it does not prevent it. And in the same document:

Although the Windows integrity mechanism is similar to earlier integrity models in computer security, Windows Vista does not try to implement any of the models.

Why not? Anderson gives the reason in a single clause:

In the case of Windows, Microsoft even dropped the NoReadDown restriction and did not end up using its integrity model to protect the base system from users, as this would have required even more frequent user confirmation.

There it is. The model was cut because enforcing it fully would have produced too many confirmation prompts, and a security control that generates too many prompts gets switched off — by users, by administrators, or by the vendor pre-emptively. Every reader of this article has made the same trade in their own environment: the alert that fires too often, the blocking rule downgraded to logging, the MFA prompt loosened after the helpdesk complained.

Microsoft is also explicit about two further limits: the Windows mechanism “does not implement a dynamic, or ‘Low-Water-Mark,’ policy,” and it “is not designed for integrity protection of data to support military or commercial requirements as described in the Clark-Wilson model” — no constrained data items, no certified transformation procedures.

The lesson to carry out of 3.2.3 is not “Windows implements Biba.” Almost every write-up says that and it is wrong. The lesson is: Windows implements the half of Biba that survives contact with users, published exactly which half it dropped, and named the reason. That is what mature engineering against a formal model looks like, and it is a better answer to “do these models matter” than any amount of insisting that they do.

If you want a cleaner Biba illustration for teaching, Anderson supplies one: a medical device such as an ECG with two modes, calibration and use. Calibration data must be readable by normal users but writable only by an authorised technician. Read down, write up prohibited — Biba with two levels and no mathematics. And the broadest one: safety integrity levels in safety-critical engineering are a Biba lattice under another name.

Bell–LaPadula in the wild: a certified OS, a mainstream Linux, and a helicopter

Trusted Solaris 8. A real, purchasable, Bell–LaPadula-derived commercial operating system, certified in the UK scheme against the Labeled Security Protection Profile at EAL4 augmented — the full certificate is dissected in 3.2.7, because the sentences in it are worth more there. Watch the date, because it is easy to get wrong: the certification report is Issue 3.0 of March 2004, but the report says of itself that “certification to the EAL4 Evaluation Assurance Level was previously completed in June 2002,” and was then updated twice to add flaw-remediation augmentations. June 2002 is the certification; March 2004 is the third issue of the paperwork.

The relevant fact here is that the report describes an operating system “developed to meet the requirements for secure computing, including ‘Multi-Level’ and ‘System High’ operation,” and then says of the two profiles it was evaluated against:

It meets the requirements of the Common Criteria (CC) Labeled Security Protection Profile (LSPP) [d] and Controlled Access Protection Profile (CAPP) [e], which are respectively equivalent to those of the B1 and C2 classes of the Trusted Computer System Evaluation Criteria.

The Trusted Computer System Evaluation Criteria is the Orange Book — that gloss is mine; the report uses the full name. Solaris later stopped shipping a separate MLS kernel: from Solaris 10 11/06 the labels moved into mainstream Solaris as Trusted Extensions, which Sun’s own transition guide describes in one line — “Unlike Trusted Solaris software, Trusted Extensions is a configuration of the underlying Solaris OS.” Whether you call that a discontinuation or an absorption is a framing choice; no Sun or Oracle document I could open uses the word “discontinued.”

SELinux MLS in RHEL 9 and 10 — with the write-equality modification, covered in 3.2.1.

seL4, and the helicopter DARPA’s red team could not break out of. This is where the lattice section should land, because it is what the Orange Book’s highest class was asking for, delivered decades later by people nobody asked.

seL4 is a microkernel with a machine-checked mathematical proof of implementation correctness. Klein et al. put the kernel they verified in 2009 — the ARMv6 version — at “8,700 lines of C code and 600 lines of assembler,” proved against a formal specification. From the seL4 Foundation’s own whitepaper:

seL4 comes with a formal, mathematical, machine-checked proof of implementation correctness… seL4 is the world’s first OS kernel with such a proof at the code level.

Besides implementation correctness, seL4 comes with further proofs of security enforcement. They say that in a correctly configured seL4-based system, the kernel guarantees the classical security properties of confidentiality, integrity and availability.

The underlying paper is Gerwin Klein et al., “seL4: Formal Verification of an OS Kernel,” presented at the 22nd ACM SIGOPS Symposium on Operating Systems Principles in October 2009, and it is the source of those line counts.

A proof is only ever as good as its assumptions, so state them — and note that they have narrowed since 2009. The 2009 work assumed the correctness of the compiler, the assembler and the hardware. The Foundation’s current whitepaper lists three: that the hardware behaves as expected, that the specification says what its authors think it says, and that the theorem prover is correct. The compiler has come off the list, because translation validation now carries the proof down to the binary: “our assumptions on C semantics drop out of the assumptions made by the proofs.”

And one limit that matters directly for the covert-channel material in 3.2.4 — the whitepaper states that seL4’s confidentiality proofs “rule out covert storage channels but presently not covert timing channels, which are used by such attacks as Spectre.” The strongest formal-methods result in production computing draws its boundary at exactly the channel the Orange Book found hardest to reason about, and says so on its own front page.

And then the deployment, from the same whitepaper:

A great example is the work our HACMS project partners did on cyber-retrofitting the Boeing ULB autonomous helicopter. The original system ran on Linux, and in a first step, the team put seL4 underneath.

The upshot was that while the initial system was readily hacked by the professional penetration testers hired by DARPA, the end state was highly resilient. The attackers could compromise the Linux system and do whatever they wanted with it, but were unable to break out and compromise any of the rest of the system. The team was confident enough to demonstrate an attack in-flight.

Read that last sentence again. The red team owned the Linux partition, in the air, and it did not matter, because the kernel underneath had a proof that it could not matter. The Orange Book’s class A1 was called “Verified Design” and demanded formal methods. Common Criteria’s EAL7 says “formally verified, designed, and tested.” For decades both were treated as aspirational categories that no real product occupied. seL4 is what the requirement looks like when somebody finally does it — in open source, on a flying aircraft, against paid attackers.

The Lipner implementation: 1982’s answer to a 2026 problem

The book is right that Lipner is not a model. What it does not convey is how concrete, how commercial, and how modern the paper is.

Steven B. Lipner wrote it in 1982 from the Corporate Research Group at Digital Equipment Corporation. The title is the thesis: “Non-Discretionary Controls for Commercial Applications.” From the introduction (this is a scanned original and the text is OCR-derived, so it is quoted sparingly):

The lattice model of non-discretionary access control in a secure computer system was developed in the early Seventies. The model was motivated by the controls used by the Defense Department and other “national security” agencies to regulate people’s access to sensitive information.

The paper’s major conclusions are that the lattice model may in fact be applicable to commercial data processing, but that such application will require ways of looking at security requirements different from those prevalent in the national security community.

The construction itself is the part nobody teaches. Lipner defines two security levels — System-Low and Audit-Manager — and five categories: Production-Data, Production-Code, Development, System-Development and Tools. (A caution for anyone who goes to the paper to check: Figure 4 prints only four of the five — Production-Code is missing from that figure, though it is used throughout Figures 5, 6 and 7. The model has five; count from the later figures.) Then he assigns access classes:

• An ordinary user gets System-Low with Production-Data and Production-Code.
• An application developer gets System-Low with Development and Tools.
• A system programmer gets System-Low with System-Development and Tools.
• System Control gets System-Low with everything, plus a downgrade privilege.

The requirements he is satisfying were, in his own words, “taken from the suggestions of a senior EDP auditor,” aimed at production systems running “financial, material control, or order-entry data.”

Look at that lattice with 2026 eyes. Developers can touch development and tools but not production data. Production code and production data are separate categories. Exactly one role can move something from the development compartment into the production compartment, and that is a distinct, named privilege rather than a side effect of seniority.

That is environment separation and a promotion gate. Lipner’s “downgrade privilege held by System Control” is the merge-to-main approval, the production deploy button, the change advisory board. The industry rediscovered this in the 2010s, called it CI/CD hygiene, and wrote a great many blog posts about it. A DEC engineer working from an auditor’s requirements list drew it as a lattice in 1982. That comparison is my own reading rather than a claim in the paper — but the categories are on the page and the mapping is not subtle.

Lipner also states, honestly, the flaw that forces him to add Biba on top:

if a programmer could somehow introduce a “system low” program for use by production users, there would be nothing in this lattice model to prevent that program from corrupting the production data base to which the users have (lattice model) access.

A confidentiality lattice cannot stop bad code getting into good data. You need an integrity lattice for that. Which is the entire argument for why the book puts Lipner in this subsection: it is the worked demonstration that neither Bell–LaPadula nor Biba alone is sufficient for a commercial system.

The objection: “MLS failed commercially, nobody buys this”

This is the strongest attack on the whole of 3.2.3 and it deserves a straight answer rather than a dodge, because on its own terms it is correct.

Anderson’s list of practical problems is unanswerable:

Multilevel secure systems are surprisingly expensive and difficult to build and deploy… They are built in small volumes… MLS systems have idiosyncratic administration tools and procedures. A trained Unix administrator can’t just take on an MLS installation without significant further training; so many MLS systems are installed without their features being used.

There is a specific technical failure mode too, and it is worth knowing by name. Label explosion: components accumulate every label they have ever seen until they hold a collection no single principal can access. The workaround is to put those components in the trusted computing base — the part of the system exempt from the rules — which ends up containing, as Anderson puts it, “a quite uncomfortably large part of the operating system.” He calls the result TCB bloat, and notes that it “constantly pushes up the cost of evaluation and reduces assurance.” The more of the system you exempt to make it usable, the less the proof is worth.

And then the case study that settles it. The Royal Air Force’s Logistics Information Technology System:

In the UK, the Royal Air Force’s Logistics Information Technology System (LITS) was a 10 year (1989–99), £500m project to provide a single stores management system for the RAF’s 80 bases. It was designed to operate on two levels: “Restricted” for the jet fuel and boot polish, and “Secret” for special stores such as nuclear bombs. It was initially implemented as two separate database systems connected by a pump to enforce the MLS property… One of these changes was the easing of classification rules with the end of the Cold War. As a result, it was found that almost all the “Secret” information was now static… To save money, the “Secret” information is now kept on a CD and locked up in a safe.

Ten years, £500 million, two databases and a one-way pump, and the answer in the end was a CD in a safe.

One honesty note about that first ellipsis, because it hides a sentence that qualifies the case. The elided text contains Anderson’s own diagnosis: “The project became a classic tale of escalating costs driven by creeping changes in requirements.” LITS is not, on Anderson’s telling, a story of multilevel security collapsing under its own weight. It is a story of requirements creep in a system that happened to be multilevel. The broader argument does not need LITS to carry more than that; Anderson’s list of generic MLS problems, quoted above, does the work by itself. (Two smaller renderings worth flagging: Anderson uses single quotes for ‘Restricted’ and ‘Secret’, and the “surprisingly expensive” passage above is items 1 and 2 of a numbered five-item list, run together here as prose.)

Also true: Trusted Solaris stopped shipping as a separate product. Red Hat’s own RHEL 9 documentation says MLS “does not map well to general use-case scenarios.” The product category did fail.

And the mechanism won anyway, sideways. Anderson again:

Mandatory access control was initially developed for military applications, where it is still used in specialized firewalls (guards and data diodes). The main use of MAC mechanisms nowadays, however, is in platforms such as Android, iOS and Windows, where they protect the operating systems themselves from malware.

although multilevel security concepts were originally developed to support confidentiality in military systems, many commercial systems now use multilevel integrity policies. For example, safety-critical systems use a number of safety integrity levels.

The phone in your pocket runs SELinux. Not to keep Secret away from Confidential, but to keep an untrusted app away from the system partition. The labels stopped meaning classification and started meaning provenance and trust, and once they did, mandatory access control went from a specialist military product to something running on every consumer device on earth.

So the honest position on MLS is this: as a product you could buy, it failed, for reasons that were about administration cost and usability rather than about the mathematics. As a mechanism, it is the most widely deployed access control model in history, and it got there by changing what the levels mean. Nobody sells you a lattice any more. You are just running several.

---

3.2.4 — Rule-based Models

What the book says

The core concepts: information flow models track the flow of information and can help uncover covert channels; covert channels are unintentional communication paths, of two types, storage and timing; Clark–Wilson is an integrity-focused rule-based model with three goals and three rules; and Brewer–Nash, the Chinese Wall model, is designed to prevent conflicts of interest.

This is the longest subsection in the book and the richest in the world outside it. It also contains the two claims in the whole of 3.2 that do not survive checking. Both are fixed below, and in both cases what replaces them is better than what it replaces.

Information flow, and the 2025 system that is a lattice without knowing it

The origin is Dorothy E. Denning, “A Lattice Model of Secure Information Flow,” Communications of the ACM, Volume 19, Number 5, May 1976. This is the paper that made “lattice” the operative word in the field, and — as the book correctly states — it is the general frame beneath both Bell–LaPadula and Biba.

The modern example is not military and not classified. It is Meta.

On 23 July 2025, Meta’s engineering organisation published “Policy Zones: How Meta enforces purpose limitation at scale in batch processing systems,” by Lucas Waye, Wenlong Dong, Boris Shulman, Yizhou Yan and Yuxuan Zhang. The system leverages, in Meta’s own words, “Information Flow Control (IFC) principles.” Its core propagation rule:

The restrictions on downstream data must be equal to or more restrictive than those of the upstream source from which the data originates.

That sentence is a lattice ordering. Not “resembles” — it is the join rule from the plain-English explanation above, with the labels renamed from classification levels to permitted purposes. Data inherits the most restrictive constraint of anything that fed it. Denning 1976, with GDPR-style purpose limitation in place of Confidential and Secret.

The scale is the reason to use this as the example rather than a classified network:

• “controlling access for millions of datasets”
• “analyzing the processing of tens of millions of data flows per day”
• “Performing batch user consent checks that performs trillions of consent checks per hour across datasets that span different purpose-use boundaries”
• integrated with an “exabyte-scale data warehouse”

One caveat stated plainly: Meta’s post does not cite Denning, Bell–LaPadula or non-interference by name. It names information flow control as the principle and states the propagation rule. The identification of that rule as a lattice ordering is my reading of the sentence they published, not a claim Meta makes.

Why this is the right modern example for a CISSP reader: it shows what happened to information-flow control when the driver changed. For forty years the funder was military classification. The thing that finally put an information-flow lattice over an exabyte of production data was privacy regulation — the requirement that data collected for one purpose not be used for another. Purpose limitation is an information-flow problem. Any organisation that has tried to answer “can this dataset be used for that?” at scale has discovered the same thing, usually the hard way.

The pizza index: the story is real, the version everybody tells is not

Now the correction that every CISSP course in the world needs.

CISSP uses the pizza index as its covert-channel illustration: that in the run-up to Desert Storm, journalists tracked pizza deliveries to the Pentagon, that a normal night was three or four pizzas and the night before the conflict was thirty or forty, and that — the load-bearing claim —

CNN and other news outlets were able to piece together the inadvertent disclosure of sensitive information and predict when military strikes in the Middle East would commence.

The spikes are real. They were contemporaneously reported, in ordinary daily journalism, and they are more colourful than the version in the book.

The Christian Science Monitor, 17 January 1991, “Pizza Orders Rise with War Tension,” compiled from wire services: White House staff “sent out for 55 pies from Domino’s Pizza” as the UN deadline passed. “The White House orders five pizzas on an average night. Just before Iraq invaded Kuwait Aug. 2, presidential aides ordered 24.” Pentagon orders after 10 p.m. “surged to 101” against an average of 3. Domino’s, the piece says, thought it “has discovered a nearly infallible barometer of war and peace.”

The better-documented instance is seven years later. The Washington Post, Sarah Schafer, “With Capital in Panic, Pizza Deliveries Soar,” Saturday 19 December 1998, page D1 — impeachment weekend, and Operation Desert Fox running simultaneously. It opens: “Call it the Washington pizza index.” Frank Meeks, owner of 59 Domino’s franchises in the Washington area and described as “the capital’s unofficial pizza historian,” says: “It’s going haywire.” White House three-day orders ran $2,600 in mid-January 1998 against $3,100 that week. Capitol Hill’s previous record of $9,100, set during the 1995 government shutdown, was beaten with $11,600. And, delightfully: “The White House ordered 32 percent more extra-cheese pizzas than normal.”

So: a real, measurable, unintended signal, leaking from the physical world, correlated with confidential activity. As an illustration of a covert channel it is excellent.

What cannot be supported is the sentence the book builds it on. No source establishes that any outlet used pizza deliveries to predict the start of Desert Storm. (Be precise about what is being denied: Slate does report that the Chicago Tribune once published a pizzeria owner’s own claim to have predicted imminent action from his order book. An outlet reporting a vendor’s prediction is not an outlet predicting.) The line that circulates — Wolf Blitzer’s supposed “Bottom line for journalists: Always monitor the pizzas” — traces to precisely one place: a 2016 Slate article which hedges it as “supposedly” and attributes it to “online anecdotes.” That piece’s headline calls the whole genre “1990s Pop Pseudoscience,” and in its prose it describes the method as “horrendously unscientific data collection” — the first of those is the title, the second is the writing, and they are worth keeping apart. There is no transcript, no date, no broadcast. The chain runs: anonymous 1990s internet anecdote → a hedged line in a 2016 magazine piece → an encyclopaedia entry → a generation of security textbooks.

Three further details the courses get wrong. The often-repeated “the CIA ordered 21 pizzas on 1 August 1990” rests on an LA Times clipping (16 January 1991, p. P2) whose archive URL no longer resolves, so it cannot be read; the contemporaneous source that can be opened gives a different number and a different building — 24 pizzas, the White House. In the actual 1998 record, CNN appears as a pizza customer, not a pizza analyst; Armand’s on Capitol Hill was filling orders for CNN’s local bureau. And no Snopes fact-check on any of this could be found under current search, despite frequent citation of one — which is a negative finding about searching, not a proof that none was ever published.

The lesson is better than the story. The canonical covert-channel anecdote in the security profession is itself a low-bandwidth signal that got amplified, distorted and repeated until the signal became noise. It is taught in a section about inferring truth from indirect evidence, by people who did not check the indirect evidence. If you are going to teach inference, teach it on a channel somebody measured.

Those exist, and the measurements are extraordinary.

What the Orange Book actually says about covert channels, in bits per second

Two corrections to the book’s treatment before the good part.

First: the “roughly 99 percent” figure. CISSP says storage channels “represent the majority of covert channels (roughly 99 percent).” That number has no source. The three documents where such a claim would have to live were searched in full:

• TCSEC (DoD 5200.28-STD, December 1985): the string “percent” appears zero times. No prevalence claim of any kind.
• NCSC-TG-030, A Guide to Understanding Covert Channel Analysis of Trusted Systems (the Light Pink Book, November 1993): 62 occurrences of “timing channel,” 49 of “storage channel.” The guide does contain percentage figures — five of them — but not one of them makes a prevalence claim about storage versus timing.
• Lampson 1973, the paper that introduced the confinement problem: the paper contains no percentages at all. The nearest thing is a list he numbers 0 through 6 and then himself refers to as “the six examples above,” of which all but two use storage — four of six, or about 67%. That percentage is my arithmetic on his list, not a figure Lampson prints.

Do not repeat the 99%. What the authoritative guide actually says is far more interesting. NCSC-TG-030, section 2.2.1:

a distinction between covert storage and timing channels … is made even though theoretically no fundamental distinction exists between them

In this guide, we retain the distinction between storage and timing channels exclusively for consistency with the TCSEC.

The storage/timing split — the thing the exam asks you to memorise — is described by the government’s own guide to covert channel analysis as a convention retained for backward compatibility with an earlier standard, over a distinction its authors say does not fundamentally exist. Learn the two categories for the exam. Know that the people who wrote the guide thought they were a labelling convenience.

There is also a likely origin for the folk belief, and it is checkable. The Orange Book’s requirements introduce the two kinds at different classes. Class B2 requires:

The system developer shall conduct a thorough search for covert storage channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel.

Class B3 widens it, dropping the word “storage”:

The system developer shall conduct a thorough search for covert channels…

And class A1 adds: “Formal methods shall be used in the analysis.” So storage channels came first in the requirements, one class earlier than timing channels — an asymmetry that is regulatory, not statistical, and that would very naturally harden into “most covert channels are storage” over forty years of retelling.

Second: the RAM example. The book illustrates a storage covert channel with sensitive data left in memory after a process finishes, readable by a later process. That is a real risk, but it is data remanence, not a covert channel in the Orange Book’s sense. The definition requires deliberate signalling between two processes:

Covert storage channels include all vehicles that would allow the direct or indirect writing of a storage location by one process and the direct or indirect reading of it by another. Covert timing channels include all vehicles that would allow one process to signal information to another process by modulating its own use of system resources in such a way that the change in response time observed by the second process would provide information.

A sender, a receiver, and an encoding. Leftover data in RAM has none of those; it is a cleanup failure. Worth knowing the difference, because the same distinction will decide whether you class a finding as a data-handling issue or a channel that needs bandwidth analysis.

And now the number that makes the whole subject land. The Orange Book quantifies what counts as a dangerous channel, and the figures are wonderful:

A covert channel bandwidth that exceeds a rate of one hundred (100) bits per second is considered “high” because 100 bits per second is the approximate rate at which many computer terminals are run. It does not seem appropriate to call a computer system “secure” if information can be compromised at a rate equal to the normal output rate of some commonly used device.

…those with maximum bandwidths of less than one (1) bit per second are acceptable in most application environments.

a Trusted Computing Base should provide, wherever possible, the capability to audit the use of covert channel mechanisms with bandwidths that may exceed a rate of one (1) bit in ten (10) seconds.

One hundred bits per second, in 1985, disqualified a system from being called secure. One bit per second was tolerable. One bit every ten seconds was worth logging. Hold those numbers.

A storage covert channel with a measured rate: Meltdown

CVE-2017-5754, published 4 January 2018. The paper is “Meltdown: Reading Kernel Memory from User Space,” presented at the 27th USENIX Security Symposium, by Moritz Lipp, Michael Schwarz and Daniel Gruss of Graz University of Technology; Thomas Prescher and Werner Haas of Cyberus Technology; Anders Fogh of G DATA; Jann Horn of Google Project Zero; Stefan Mangard of Graz; Paul Kocher; Daniel Genkin of the University of Michigan; Yuval Yarom of the University of Adelaide and Data61; and Mike Hamburg of Rambus.

The thing most write-ups miss is that the covert channel is not a detail of Meltdown. It is the mechanism. Speculative execution lets the processor read kernel memory it should not; the read is then rolled back and the value never reaches an architectural register. So how does the attacker get the value out of a state the CPU has officially discarded? A covert channel. In the authors’ words:

an attacker can dump the entire kernel memory by reading privileged memory in an out-of-order execution stream, and transmit the data from this elusive state via a microarchitectural covert channel (e.g., Flush+Reload) to the outside world.

The advantage of the Flush+Reload cache covert channel is the noise resistance and the high transmission rate.

And the measurement:

While the performance heavily depends on the specific machine, e.g., processor speed, TLB and cache sizes, and DRAM speed, we can dump arbitrary kernel and physical memory with 3.2 KB/s to 503 KB/s.

Note that it is a range, and quote it as one. The paper’s conclusion also uses the ceiling on its own — reading sensitive data from other processes or virtual machines in the cloud “with up to 503 KB/s” — and the version that circulates in write-ups quietly merges the two, keeping the fast number and dropping the slow one.

Now do the arithmetic against the Orange Book, at both ends. 503 KB/s is 503 × 1024 × 8 ≈ 4.12 million bits per second; 3.2 KB/s is 26,214 bits per second. The DoD’s 1985 threshold for a channel so fast that a system carrying it should not be called secure was 100 bits per second. Meltdown’s covert channel runs roughly 260 to 41,000 times that rate, depending on the machine. That arithmetic is mine, from the paper’s published figures; both inputs are quoted above so you can redo it. The floor is the honest number to lead with, and it costs the argument nothing: 262 times a threshold set in 1985 is already catastrophic, and quoting only the ceiling would be exactly the habit this article spends its length arguing against.

Spectre is the companion — CVE-2017-5753 and CVE-2017-5715, also published 4 January 2018, with the paper appearing at the 40th IEEE Symposium on Security and Privacy in 2019. Its structure is described in the same vocabulary. From the preprint, arXiv:1801.01203: the attacker finds an instruction sequence which “when executed acts as a covert channel transmitter which leaks the victim’s memory or register contents,” then “retrieves the victim’s information over the covert channel,” using “a cache-based covert channel using Flush+Reload or Evict+Reload.” (Cite the preprint for those two spans, not the 2019 conference paper — the published version rewords both, to “that leaks the victim’s memory” and to “use cache-based covert channels [64], i.e., Flush+Reload and Evict+Reload.”)

The underlying technique predates both. Yuval Yarom and Katrina Falkner presented “FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack” at the 23rd USENIX Security Symposium on 22 August 2014, recovering “96.7% of the bits of the secret key by observing a single signature or decryption round” from GnuPG 1.4.13 — working across processes and across separate virtual machines. Earlier still, Daniel J. Bernstein’s self-published “Cache-timing attacks on AES” of 14 April 2005 achieved “complete AES key recovery from known-plaintext timings of a network server on another computer,” and Osvik, Shamir and Tromer at CT-RSA 2006 recovered a full AES key from a Linux dm-crypt partition “after just 800 writes to the partition, taking 65 milliseconds.”

Two decades of work, all of it the same idea: the shared resource is the channel. In 1985 the DoD’s threshold for unacceptable was a hundred bits per second. Today, cache state on a shared CPU carries megabits per second between security domains that the architecture says cannot communicate at all. Covert channel analysis is not a historical curiosity from the B2 requirements. It is the entire microarchitectural security field, and it was named forty years before it became urgent.

For a classical storage channel in a protocol rather than a processor, the reference is Craig H. Rowland, “Covert channels in the TCP/IP protocol suite,” First Monday, Volume 2, Number 5, 5 May 1997 — data hidden in the IP identification field and TCP sequence numbers, with working proof-of-concept code. And for the ancestor of every tunnelling tool since, “Project Loki: ICMP Tunneling,” Phrack issue 49, 8 November 1996 — whitepaper by daemon9 (AKA route), source code by daemon9 and alhambra, as the file header itself sets out.

A timing channel with a CVE number: the book’s own example, made real

CISSP‘s Table 3-4 illustrates a timing channel with a hypothetical: a web server that takes three seconds to respond for an existing username and one second for a non-existent one, allowing enumeration.

That exact bug is real, has a CVE, a named reporter, a vendor advisory and a fix.

CVE-2016-6210, OpenSSH. The MITRE record:

sshd in OpenSSH before 7.3, when SHA256 or SHA512 are used for user password hashing, uses BLOWFISH hashing on a static password when the username does not exist, which allows remote attackers to enumerate users by leveraging the timing difference between responses when a large password is provided.

The mechanism is beautiful in its simplicity. For a real account, sshd hashes the supplied password with the configured algorithm — SHA256 or SHA512. For an account that does not exist, it hashes against a fixed dummy value, using BLOWFISH. Blowfish hashing is faster. Send a very long password and the difference becomes measurable over the network. The system leaks the existence of an account through nothing but how long it takes to say no.

The vendor fix, in the OpenSSH 7.3 release notes:

sshd(8): Mitigate timing differences in password authentication that could be used to discern valid from invalid account names when long passwords were sent and particular password hashing algorithms are in use on the server. CVE-2016-6210, reported by EddieEzra.Harari at verint.com

Do not trim that final conditional, as most write-ups do. “Particular password hashing algorithms are in use on the server” is the whole bug: the leak exists only where the configured algorithm is slower than the fixed BLOWFISH fallback.

And the original disclosure, posted by Eddie Harari of Verint to the Full Disclosure list on 14 July 2016:

By sending large passwords, a remote user can enumerate users on system that runs SSHD. This problem exists in most modern configuration due to the fact that it takes much longer to calculate SHA256/SHA512 hash than BLOWFISH hash.

Replace the book’s hypothetical with this. It is the same channel, it happened, it was fixed, and it demonstrates the defence: the mitigation is not to make the error message vaguer, it is to make the time constant regardless of the answer.

One thing not to conflate: CVE-2018-15473 is the more famous OpenSSH enumeration bug and it is a different class — a protocol-response difference, where the server bails out before fully parsing a packet, rather than a timing measurement. And CVE-2013-1443 in Django, sometimes cited here, is described by MITRE as denial of service through CPU consumption, not timing enumeration.

Also, while we are removing wrong examples: Heartbleed is not a covert channel. CVE-2014-0160 is a buffer over-read — direct memory disclosure, with no encoding, no sender and no receiver-by-inference. It gets filed under storage covert channels with some regularity and it does not belong there.

Clark–Wilson: an auditor and an internet architect, writing together

The book’s treatment is correct and compact. Clark–Wilson is a rule-based integrity model meeting three goals:

1. Prevent unauthorised subjects from making any changes — the only one of the three Biba addresses.
2. Prevent authorised subjects from making bad changes.
3. Maintain consistency of the system.

Through three rules: well-formed transactions (only operations that cannot compromise integrity), separation of duties (one person should not perform all tasks in a critical function), and the access triple — subject, program, object — in which “a subject cannot directly access an object… access must go through a program that enforces access rules.”

What the book does not mention is who wrote it, and the answer explains everything about why this model maps to commercial practice when the military ones do not. David D. Clark was at the MIT Laboratory for Computer Science — the chief protocol architect of the internet. David R. Wilson was Director of Information Security Services at Ernst & Whinney, one of the Big Eight accounting firms. The 1987 paper, “A Comparison of Commercial and Military Computer Security Policies,” is literally an internet architect and an audit partner writing a paper together, and it shows on every page.

On well-formed transactions:

Perhaps the most formally structured example of well-formed transactions occurs in accounting systems, which model their transactions on the principles of double entry bookkeeping. Double entry bookkeeping ensures the internal consistency of the system’s data items by requiring that any modification of the books comprises two parts, which account for or balance each other… If an entry is not performed properly, so that the parts do not match, this can be detected by an independent test (balancing the books).

And then the sentence that is the best thing in the paper, and possibly in this entire section of the syllabus:

(Before the computer, bookkeepers were instructed to write in ink, and to make correcting entries rather than erase in case of error. In this way the books themselves, being write-only, became the log, and any evidence of erasure was indication of fraud.)

Write in ink. Correct with a new entry, never by erasing. The ledger becomes its own audit log, and tampering is visible as tampering rather than absent as data. That is append-only storage, immutable logging, event sourcing, and the entire design philosophy behind write-once audit trails — described as a rule for clerks with pens, quoted in 1987 to explain what a computer should do.

On separation of duty, with the fraud spelled out:

the correspondence is ensured indirectly by separating all operations into several subparts and requiring that each subpart be executed by a different person. For example, the process of purchasing some item and paying for it might involve subparts: authorizing the purchase order, recording the arrival of the item, recording the arrival of the invoice, and authorizing payment… If one person can execute all of these steps, then a simple form of fraud is possible, in which an order is placed and payment made to a fictitious company

And on the access triple, in language considerably sharper than the usual gloss:

a user is not given authority to read or write certain data items, but to execute certain programs on certain data items. The distinction between these two mechanisms is fundamental.

That distinction is the model’s real contribution, and it is the one most often lost. Clark–Wilson does not say “control who can write to the ledger.” It says nobody writes to the ledger. People are authorised to run transactions, and the transactions write. Your permission is not “update the account table”; it is “execute post-payment.” Every constraint you want — balance checks, approval thresholds, audit entries, referential integrity — lives inside the program, and there is no path around it. That is why direct database access for application support staff is the control finding it is, and why “we gave the analyst read-write on prod to fix a data issue” breaks Clark–Wilson at the definitional level rather than as a matter of degree.

The failure case: Société Générale, and a correction to the story everyone tells

In January 2008 Société Générale announced a loss of €4.9 billion caused by unauthorised trading by Jérôme Kerviel. It is the standard Clark–Wilson case study, and the standard version of it is wrong in an instructive way.

The numbers first, from SG’s own documents — the General Inspection department’s synthesis report, codenamed Mission Green, dated 20 May 2008, and the Special Committee of the Board’s progress report of 20 February 2008. The fraudulent activity began in 2005 and became massive from March 2007. There was a short index-futures position of €28 billion at 30 June 2007, a further short reaching €30 billion at 31 October 2007 (that second leg appears only in the May French report, not in the February English translation), and then, between 2 and 18 January 2008, a long position of €49 billion. It was discovered on 20 January and unwound between the 21st and 23rd, producing a €6.4 billion loss; netted against a €1.5 billion gain booked in 2007, that is the €4.9 billion figure.

Now the control failure, in the bank’s own words, and it is a Clark–Wilson sentence:

JK utilisait la possibilité, normalement réservée aux assistants traders (mais sans blocage informatique pour les traders) … pour corriger des biais de modélisation, de saisir des provisions positives ou négatives venant modifier la valorisation calculée par le système front office.

He used a booking capability normally reserved for trader assistants — but with no technical block preventing traders from using it — to enter positive or negative provisions, for the purpose of correcting modelling biases, that altered the valuation calculated by the front-office system.

Do not skip the purpose clause, because it is what makes this a Clark–Wilson case rather than a permissions mistake. This was not a back door. It was a sanctioned tool, built for a legitimate job, that no technical control confined to the role it was written for.

Read that against the access triple. The separation of duties existed as a policy. It did not exist as an enforced control. A trader could execute the assistants’ transaction because nothing in the software stopped him. Clark–Wilson’s entire point is that authorisation attaches to the subject-program-object triple in the system, not to a matrix in a document; the moment the program will run for a subject the policy says should not run it, the policy is a description of intent and nothing more.

And the second sentence, which should be printed above every control-testing programme in the world:

les contrôles prévus ont dans l’ensemble été effectués et menés conformément aux procédures mais n’ont pas permis d’identifier la fraude avant le 18/01/2008.

The prescribed controls were, on the whole, carried out in accordance with procedure — and did not identify the fraud. Every control passed. Everyone did their job as documented. Five billion euros.

(The two dates in that sentence and the paragraph above are not in conflict, though they read as if they were. 18 January 2008 is when an alert reached the group’s equity derivatives support function; 20 January is when the position itself was identified. Two days sit between the signal arriving and anyone understanding it.)

Now the correction. The line every retelling uses is that Kerviel knew how to hide his positions because he had previously worked in the back office. That claim is not what SG’s own investigators concluded. Neither Mission Green nor the Special Committee report attributes the fraud to prior middle- or back-office employment. What Mission Green actually found is different and more uncomfortable:

• Indications of internal complicity. The report records “des indices de complicité interne” — specifically an assistant trader in the operational middle office dedicated to Kerviel’s activity. That assistant booked seven provision flows over €50 million during 2007–08, where normal flows were a few hundred thousand, including €1.5 billion on 10 January 2008, and personally entered about 15% of the fictitious transactions. On 31 December 2007 he emailed Kerviel with the subject line “Valo JK + 1 464 129 513 €” — a figure obtainable only by someone who knew the fictitious trades were there.
• A network inside the control functions. From the English-language report: “the extensive internal network of personal relationships which JK maintained, in particular with operational staff in support and control roles.”
• Chronic middle-office understaffing through 2007 following departures.
• Motive, stated bluntly in the same report: “JK had earned a EUR 60,000 bonus for the fiscal year 2006. He had asked for EUR 600,000 for 2007 but had obtained only EUR 300,000.”

The popular version — a clever man who learned the plumbing — makes this a story about one individual’s knowledge. The primary sources make it a story about the relationships between the people the separation of duties was supposed to separate, plus a missing technical block. That is a much harder problem, and a much more useful one, because you can fix the missing block with an access control change and you cannot fix the other thing at all except by making the control independent of who is friendly with whom.

The regulatory response to this class of failure is worth one paragraph, because CISSP candidates are asked where separation of duties is mandated rather than merely recommended. The European Banking Authority’s Guidelines on internal governance, EBA/GL/2021/05, 2 July 2021, paragraph 107, requires institutions’ conflict-of-interest measures to include:

a. an appropriate segregation of duties, e.g. entrusting conflicting activities within the processing of transactions or when providing services to different persons…
b. establishing information barriers, e.g. through the physical separation of certain business lines or units.

Note the phrase information barriers — hold it for the next section. And a precision worth having: the “four-eyes principle” is often attributed to those guidelines and the phrase does not appear in them. The binding requirement is in the Capital Requirements Directive itself, Directive 2013/36/EU, Article 13(1): authorisation is granted “only where at least two persons effectively direct the business” of the credit institution.

Brewer–Nash: a model of the law, and then the law of the model

Brewer and Nash published “The Chinese Wall Security Policy” at the 1989 IEEE Symposium on Security and Privacy, from Gamma Secure Systems Limited in Camberley, Surrey. The book describes its single goal correctly — preventing conflicts of interest — and gives the classic example of separating an investment bank’s mergers-and-acquisitions department from its retail investment side.

What is remarkable about the paper, and never taught, is that the authors are not proposing a security policy. They are modelling an existing legal obligation. From page 206:

It should be noted that in the United Kingdom the Chinese Wall requirements of the UK Stock Exchange have the authority of law and thus represent a mandatory security policy whether implemented by manual or automated means.
Furthermore, correct implementation of this policy is important to English Financial Institutions since it provides a legitimate defence against certain penal classes of offence under their law.

Their two citations for that are the Securities and Investment Board Rules, Chapter III Part 5:08, and the Financial Services Act 1986, section 48(2)(h).

Read what that means for the CISSP framing. Bell–LaPadula is mandatory access control because a government classification system says so. Brewer–Nash is mandatory access control because the Financial Services Act says so, and a correctly implemented wall is an affirmative legal defence. The authors say as much:

One of these, the Chinese Wall security policy is perhaps as significant to some parts of the commercial world as Bell and LaPadula’s policies are to the military. It can be most easily visualized as the code of practice that must be followed by a market analyst working for a financial institution providing corporate business services.

And their conclusion, with the sentence that most summaries ellipse straight past — the one that actually earns the phrase “affirmative legal defence”:

Failure to obey this policy would be considered, at best, unprofessional and potentially criminally fraudulent… In some countries, showing that the policy has been enforced is sufficient to provide legal protection against charges of insider dealing… Thus this is a real commercial policy which can be formally modelled, but not using a Bell-LaPadula based approach.

The mechanism, in plain English, is the bit that distinguishes it from every other model here: your permissions depend on your history. On your first day, every client dataset is open to you. The moment you read one, every dataset belonging to a competitor of that client closes. It stays closed, because the paper’s matrix N — the record of what a subject has already accessed — only ever flips from false to true. (The word “permanently” is mine, not theirs; what the paper supplies is a matrix that never resets.) The lattice does not move; you do. It is the only model on the exam where the access control decision is a function of what the subject has previously accessed, which is why it cannot be expressed as a static Bell–LaPadula label and why the paper says so explicitly.

The paper also carves out an exception that working professionals should know, because it is the standard way real firms make the wall survivable: sanitized data is exempt. “This restriction can, however, be removed if we use a sanitized form of the information required… It is unnecessary to restrict access to such sanitized information.” Strip the identifying detail and the conflict disappears with it — which is the same move as aggregation and anonymisation in privacy engineering, arriving at the same place from the other end.

One correction for anyone teaching this: the paper does not mention the 1986 “Big Bang” deregulation of the London markets. That connection is drawn in a great deal of secondary material; the paper cites the SIB Rules and the Financial Services Act 1986 and nothing about Big Bang. If you make the link, mark it as your own inference.

The $1.4 billion wall: the 2003 Global Research Analyst Settlement

Fourteen years after Brewer and Nash observed that the analyst’s wall had the authority of law in the UK, the United States priced the same wall’s absence and wrote it into a court order.

On 28 April 2003 the SEC announced enforcement actions against ten firms: Bear Stearns; Credit Suisse First Boston; Goldman Sachs; Lehman Brothers; J.P. Morgan Securities; Merrill Lynch; Morgan Stanley; Citigroup Global Markets (formerly Salomon Smith Barney); UBS Warburg; and U.S. Bancorp Piper Jaffray. The conduct was research analysts producing coverage shaped by their firms’ investment banking interests.

Component	Amount
Penalties	$487.5 million
Disgorgement	$387.5 million
Independent research (five years)	$432.5 million
Investor education	$80 million
Total	≈ $1.4 billion

The settlement was approved by Judge William H. Pauley III of the Southern District of New York on 31 October 2003.

But the money is not why this is the perfect Brewer–Nash case. The structural remedies are, because they are the model restated as a court-enforced obligation. From the SEC’s own description:

The firms will physically separate their research and investment banking departments to prevent the flow of information between the two groups.

Research analysts’ compensation may not be based, directly or indirectly, on investment banking revenues or input from investment banking personnel, and investment bankers will have no role in evaluating analysts’ job performance.

Research analysts will be prohibited from participating in efforts to solicit investment banking business, including pitches and roadshows.

Plus: research budgets set by senior management independently of investment banking, coverage decisions made by research management alone, five years of independent third-party research, and public disclosure of analysts’ historical ratings.

“Physically separate… to prevent the flow of information between the two groups.” A regulator, in 2003, describing the remedy in exactly the vocabulary of a 1989 information-flow model — and note that the regulator’s own phrasing is closer to Denning than the tidied-up paraphrase that circulates, because “the flow of information” is the field’s term of art, arriving here in an enforcement document. The compensation clause is the subtler and better part: Brewer–Nash controls what information may cross the wall, but an analyst whose bonus depends on banking revenue does not need information to cross — the incentive crosses instead. The settlement blocks both channels. If you ever have to explain to an executive why a technical control is insufficient without a corresponding change to how people are paid, this is the case.

Two related walls worth knowing, briefly. Auditor independence is the same structure written into statute: SOX section 201, codified at 15 U.S.C. § 78j-1(g), lists nine categories of non-audit service a firm may not provide to an audit client, from bookkeeping to investment banking to legal services, with any other non-audit service requiring audit committee pre-approval. The SEC enforces it: on 24 January 2014 it charged KPMG with independence violations, including providing prohibited non-audit services to affiliates of audit clients and hiring a recent retiree from a senior post at an audit-client affiliate and then loaning him back to do the same work, settling for roughly $8.2 million. The framing, from John T. Dugan, associate director for enforcement in the SEC’s Boston Regional Office, is pure Brewer–Nash: “Auditors are vital to the integrity of financial reporting, and the mere appearance that they may be conflicted in exercising independent judgment can undermine public confidence in our markets.” The mere appearance. The wall exists to make the conflict impossible to allege, not merely impossible to commit.

And law firm ethical screens, where the model appears as procedure. ABA Model Rule 1.10(a)(2), as amended in 2009, allows a firm to avoid imputed disqualification when a lawyer moves firms only if the disqualified lawyer is “timely screened from any participation in the matter and is apportioned no part of the fee therefrom,” written notice is “promptly given” to the affected former client, “which shall include a description of the screening procedures employed,” and “certifications of compliance… are provided to the former client.” Note what makes the screen effective there: not just the barrier, but the notice and the certification. And the caveat in Comment [7], which is the thing to remember: “even where screening mechanisms have been adopted, tribunals may consider additional factors in ruling upon motions to disqualify a lawyer from pending litigation.” That closing qualifier matters — the comment is about disqualification motions in live litigation, not a general warning that screens are unreliable.

Why your compliance team says “information barrier” and your exam says “Chinese Wall”

A short human note before leaving this subsection.

The profession has been retiring the term “Chinese Wall” since 1988, when Harry W. Low, Presiding Justice of Division Five of California’s First Appellate District — and the first Chinese American judge in the Bay Area — wrote a concurring opinion in Peat Marwick Mitchell & Co. v. Superior Court objecting to it: “The term has an ethnic focus which many would consider a subtle form of linguistic discrimination.” He supplied the replacement in the same paragraph: “If the image of a wall must be used, perhaps ‘ethics wall’ is more suitable phraseology.”

A note on the name, because it is a small case study in how errors propagate. The reporter prints the concurrence as “LOW, P. J.” — “P. J.” is the title Presiding Justice, not a set of initials — and a considerable amount of secondary material has read those two letters as a first name and produced a judge who does not exist. If you have seen “Justice Peter Low” cited on this point, that is where he came from. The replacements now in general use are ethical wall, ethical screen, firewall, and the one that appears in the SEC’s own regulations and in the EBA guidelines quoted above: information barrier.

So the exam will say Chinese Wall, because Brewer and Nash titled their paper that way in 1989 and the body of knowledge follows the literature. Your organisation’s policies will almost certainly say information barrier. Both refer to the same model. Knowing why the vocabulary diverged saves a confusing conversation with a compliance officer.

Graham–Denning and Harrison–Ruzzo–Ullman

The book gives each a sentence and moves on, which is a fair allocation for exam purposes but leaves the pair looking interchangeable. They are not.

Graham–Denning — Graham and Denning, “Protection — Principles and Practice,” AFIPS Spring Joint Computer Conference, 1972 — is the constructive one. It sets out a set of primitive protection rules governing how subjects and objects are created and destroyed and how access rights are granted, deleted and transferred: the answer to “what operations does a protection system need in order to be complete?”

Harrison–Ruzzo–Ullman (1976) is the destructive one, in the best sense. It formalises the same territory and then proves, as covered in 3.2.1, that the general safety question over such a system is undecidable.

Read in order, they are a two-paper arc: here is the general model of how permissions change, and here is the proof that the general model cannot be checked. Everything else on this exam — every lattice, every fixed set of properties, every restricted policy language — is a response to that result. The book’s “lesser known, rule-based” is accurate and radically undersells them.

---

3.2.5 — Certification and Accreditation

What the book says

The core concepts are two definitions, and they are the most examinable sentences in the whole of 3.2:

Certification is the comprehensive technical analysis of a solution to confirm it meets the desired needs.

Accreditation is management’s official sign-off of certification for a predetermined period of time.

The book’s elaboration matters as much as the definitions. Certification is the technical work: you understand your requirements, you analyse the candidate solutions against them, you determine which one meets them. Accreditation is the decision to use it — “and one important note, accreditation is not performed by the security function; rather, it’s performed by the asset owner or management.” Management accredits for a period, “let’s say, the next eighteen months,” and when the period expires the process repeats: re-accredit the same solution, or select a different one.

The section also introduces evaluation criteria systems as the answer to a real problem — every firewall vendor says their firewall is the best, so you need “an independent and objective measurement system that vendors can use for evaluation purposes and companies for purchasing purposes.”

Learn the two definitions in exactly those words. The division of labour they encode — technical people establish the facts, accountable management accepts the risk — is correct, is the single most durable idea in this subsection, and is still how it works today under entirely different names.

Which brings us to the first correction.

The vocabulary the exam teaches has been formally dead for years

Certification and accreditation, as a named process, was retired by the organisations that invented it.

The DoD chain is documented and unambiguous:

Document	Title	Date
DoDI 5200.40	DoD Information Technology Security Certification and Accreditation Process (DITSCAP)	30 December 1997
DoDI 8510.01	DoD Information Assurance Certification and Accreditation Process (DIACAP)	28 November 2007
DoDI 8510.01	Risk Management Framework (RMF) for DoD Information Technology (IT)	12 March 2014

The 2014 instruction states: “The RMF replaces the DoD Information Assurance Certification and Accreditation Process (DIACAP) and manages the life-cycle cybersecurity risk to DoD IT in accordance with References (g) through (k).” Its reference list carries the previous version marked “hereby cancelled.” (DoDI 8510.01 was reissued again on 19 July 2022 and renamed “Risk Management Framework for DoD Systems.” That date is corroborated by three independent listings but is secondary-sourced: esd.whs.mil blocks every retrieval method attempted, so the text could not be opened and nothing is quoted from it here.)

The NIST chain is the one most readers will actually encounter. SP 800-37 Revision 1, February 2010, says what it is doing in its own opening section:

This publication, developed by the Joint Task Force Transformation Initiative Working Group, transforms the traditional Certification and Accreditation (C&A) process into the six-step Risk Management Framework (RMF).

Revision 1 still translated for readers who knew the old words. Its footnote 59:

Security control assessors may be called certification agents in some organizations… making specific determinations for or recommendations to authorizing officials (known in some communities of interest as certification recommendations or certification determinations).

Revision 2, December 2018, does not translate. In its full text — 183 pages — the phrase “certification and accreditation” appears zero times, and the word “accreditation” appears zero times. Not deprecated, not explained, not mentioned. One revision explained the old vocabulary; the next behaves as though it never existed.

What replaced it maps almost one-for-one, and the mapping is the thing to carry into the exam room and out of it:

• Certification → assessment. The technical analysis, performed by a security control assessor, producing a security assessment report.
• Accreditation → authorization, resulting in an Authorization to Operate (ATO).
• The accrediting authority → the Authorizing Official.

And the book’s insistence that accreditation belongs to management rather than to security survives verbatim in current language. SP 800-37 Rev 2:

The authorizing official is a senior official or executive with the authority to formally assume responsibility and accountability for operating a system…

…the only organizational official who can accept the security and privacy risk to organizational operations, organizational assets, and individuals.

(Those are two consecutive sentences, quoted separately rather than joined by an ellipsis, and the second is given in full — the tidier short version that circulates drops the three things the risk is to.)

The only official who can accept the risk. The book said accreditation “is not performed by the security function,” and NIST says the same thing eight years later with more force. The concept is entirely alive; only the words changed. Answer the exam question in the book’s vocabulary. Speak to an auditor in NIST’s.

The eighteen months, and the three years, and where they went

The book illustrates the accreditation period with “let’s say, the next eighteen months.” As an illustration that is harmless. Generalised into a rule, it is wrong, and so is the three-year figure that circulates even more widely.

NIST SP 800-37 Rev 2 sets no fixed period at all:

For ongoing authorization, the authorization frequency is specified in lieu of an authorization termination date.

Ongoing authorization is a time-driven or event-driven authorization process.

Reauthorization is defined as the static, single point-in-time risk determination and risk acceptance decision that occurs after initial authorization… under ongoing authorization, reauthorization is in most instances, an event-driven action.

The three-year rule did not survive to Revision 2; it was deleted from Revision 1 itself in the update of 5 June 2014. Revision 1’s own change log marks as substantive: “Deleted ‘For example, if the maximum authorization period for an information system is three years…’ from Task 5-4, Supplemental Guidance, paragraph 3.”

Where three years still lives is the Department of Defense. DoDI 8510.01, Change 3 of 2020: “An ATO authorization decision must specify an ATD that is within 3 years of the authorization date unless the IS or PIT system has a system-level continuous monitoring program compliant with DoD continuous monitoring policy as issued.”

And there is a detail inside that instruction worth the paragraph. Its stated legal basis is “Appendix III to Office of Management and Budget Circular No. A-130… November 28, 2000.” A-130 was revised on 28 July 2016 — the PDF itself carries no printed revision date, so cite the Federal Register notice, 81 FR 49689 of 28 July 2016, for that. The 2016 circular contains zero occurrences of “every three years,” zero occurrences of “accreditation,” and no Appendix III at all. What it says instead, as item 4 of a numbered list, is:

Reauthorize information systems and common controls as needed, on a time- or event-driven basis in accordance with agency risk tolerance;

As of its 2020 text, the Department of Defense’s three-year mandate cited an appendix to a circular that had been rescinded four years earlier. That is a small bureaucratic curiosity and also a precise illustration of how compliance requirements outlive their authority — a theme that returns, much larger, in 3.2.6.

The useful modern answer to “how long does an ATO last?” is therefore: it depends, and increasingly it does not expire on a date at all. The direction of travel is from a periodic re-blessing to continuous monitoring with event-driven reauthorization, on the reasonable ground that a system’s risk changes when the system changes, not when the calendar turns.

What a real accreditation looks like: named, dated, and one that was taken away

The book’s abstraction becomes concrete in FedRAMP, the US government’s programme for authorising cloud services. As of 8 September 2026, the marketplace lists 528 FedRAMP Certified Services, of which 30 came through the newer FedRAMP 20x path. Note the “of which”: the 20x services are a subset of the 528, not an addition to them.

A vocabulary warning before the examples, because this trips people up. The marketplace now labels services “FedRAMP Certified” rather than “FedRAMP Authorized,” and the Joint Authorization Board path that the CISSP body of knowledge still teaches — JAB P-ATO versus Agency ATO — is now legacy, with current paths being Agency and Program. Say which vocabulary you are using.

Two straightforward examples:

• AWS GovCloud, package F1603047866, impact level High, JAB path, certified since 21 June 2016, with 83 authorization letters on file. That last number is the reuse mechanism the whole programme exists for: certify once, and 83 separate agencies issue their own authorisations on the strength of it.
• Appian Government Cloud – High, package FR2318051429, impact level High, Agency path, sponsored by the Drug Enforcement Administration, certified since 3 April 2025. A named agency accepting the risk on behalf of the government — the Authorizing Official function, visible in public.

But the case that teaches the book’s definition properly is the one where the accreditation was withdrawn.

CircleCI Cloud, FedRAMP package FR1814240140, a low-impact SaaS authorisation on the Agency path. Its public status event log records the arc in full:

• Authorised 26 September 2018.
• Then, on 2 October 2023, the entry reads, verbatim: “Status changed from Authorized to Legacy FedRAMP Ready. SBA rescinds ATO which is why we drop to FedRAMP Ready” (the source line carries no closing full stop).
• Re-entered agency authorisation 21 November 2024.
• Re-certified 23 January 2025.

An agency withdrew its authorisation. Be careful with the agency’s identity: “SBA” appears exactly once on that marketplace page, inside that free-text log line, and is never expanded, while the package’s structured fields record partnering_agency: null and name the General Services Administration for the agency authorisation. The obvious reading is the Small Business Administration, since only a sponsor holding the ATO can rescind one — but that is an inference, and no primary source states it. Call it the agency FedRAMP’s log identifies only as “SBA.”

The product did not disappear; it dropped back to “Ready,” did the work, found a sponsor again, and returned fifteen months later.

That is the complete cycle the book describes — grant, expiry of management’s confidence, withdrawal, remediation, re-grant — happening in public, with dates, to a continuous integration service that a large number of readers have run pipelines on. It is worth knowing that it is a real lever and not a theoretical one. An accreditation is a management decision that can be revoked when management stops believing it, and here is the log line where somebody did.

Three ways accreditation fails, escalating

The failure mode of certification and accreditation is not usually a wrong decision. It is a decision that was never really made, or was made and then not honoured. Three documented US federal cases, in ascending order of consequence.

One: systems running with no valid authorisation at all. NASA’s Office of Inspector General, report IG-21-019, NASA’s Cybersecurity Readiness, 18 May 2021. One of its chapter headings is the finding: “NASA’S ASSESSMENT AND AUTHORIZATION PROCESS REMAINS INCONSISTENT AND INEFFECTIVE.” The number:

as of March 2021 we identified 35 systems whose authority to operate has expired and 82 systems that are overdue for contingency plan testing.

Two: an authorisation granted despite known unresolved critical findings. GAO-19-164, FEMA Grants Modernization: Improvements Needed to Strengthen Program Management and Cybersecurity, April 2019 — and it is the subtitle that carries the finding. The section heading tells the story on its own: “GMM Obtained Authorization to Operate, but Had Not Addressed Known Vulnerabilities or Tested All Controls.” The ATO

was granted on February 5, 2018… based on the important stipulation that the remaining 11 critical- and high-impact vulnerabilities associated with multifactor authentication would be addressed within 45 days… the program did not meet this deadline and, instead, approximately 2 months after this deadline passed, obtained a waiver that extended the deadline to May 9, 2019…

That final date is the part worth not eliding: a 45-day condition attached to a February 2018 authorisation was waived out to May 2019 — fourteen months.

and, separately, “by October 2018, FEMA had not fully tested 190 security controls.”

Look at the shape of that. The Authorizing Official did the right thing — accepted risk conditionally, with a named condition and a deadline. The condition was missed. And the response to missing the condition was not to withdraw the authorisation but to issue a waiver for the condition. A conditional acceptance whose conditions are waived on non-compliance is an unconditional acceptance with extra paperwork.

Three: the case where the bill came due. Michael R. Esser, Assistant Inspector General for Audits at the Office of Personnel Management, testifying before the House Committee on Oversight and Government Reform at the hearing “OPM: Data Breach” on 16 June 2015 — twelve days after OPM disclosed the compromise of records on millions of federal employees and applicants:

In FY 2014, 21 OPM systems were due for Authorization, but 11 of those were not completed on time and were therefore operating without a valid Authorization.

…there are currently no consequences for the owners of OPM IT systems that do not have a valid Authorization to operate.

…we also recommended that the OPM Director consider shutting down systems that were in violation. None of the systems in violation were shut down.

…represents a material weakness in the internal control structure of the agency’s IT security program.

More than half the systems due for authorisation did not get one. There were no consequences for that. The Inspector General recommended shutting the violating systems down and none were shut down. Then the breach happened — disclosed on 4 June 2015 — and the Assistant IG read those sentences into the congressional record twelve days later.

This is what the book’s definition is protecting against, and it is why the definition insists that accreditation belongs to management. Certification is a technical activity that can be done well or badly. Accreditation is an act of accountability — a named senior person putting their name to the acceptance of a specific residual risk for a specific period. When there is no consequence for operating without that signature, the signature stops being a decision and becomes a form. OPM had a process. What it did not have was anybody for whom the absence of an authorisation was a problem.

“It’s just a paperwork exercise” — the objection, and the honest answer

Anyone who has been through an accreditation has heard, or said, that it is theatre. The critique is real and it is worth stating in the voice of people who cannot be dismissed as cynics.

A federal Inspector General, in NASA’s own report:

…have resulted in some NASA organizations questioning the value of the A&A process. In our opinion, all of this leads to an environment where inappropriate levels of risk are accepted simply to avoid the perceived burdens associated with the A&A process.

Responsible officials explained that the A&A process is often viewed as cumbersome and arbitrary…

And in the same report, the consequence of that culture in one sentence:

in a March 2015 report we found a system used for command and control of spacecraft incorrectly categorized as if it did not provide command and telemetry for the spacecraft; this system later fell victim to a cyber incident.

A system that flew spacecraft was categorised as though it did not, presumably because the lower categorisation carried a lighter compliance burden — and it was subsequently compromised. That is the real failure mode of a burdensome process. Not that people do the paperwork badly, but that they route around it by misdescribing the asset, which corrupts the input to every control decision downstream.

The foundational quality critique is older. GAO-04-376, Information Security: Agencies Need to Implement Consistent Processes in Authorizing Systems for Operation, transmitted 28 June 2004, found that agency processes “do not ensure the quality of the certifications and accreditations.” Of 32 systems reviewed, only 17 documented the residual risk that the accrediting official was accepting — 53%, which is GAO’s own printed figure in its Table 3, not this article’s arithmetic. Just over half of the accreditation decisions recorded what was being accepted. That report is twenty-two years old and uses pre-RMF vocabulary, so pair it with the NASA report rather than leaning on it alone.

NIST’s answer to all of this is in the boxed sidebar closing the Executive Summary of SP 800-37 Rev 2, on printed page xv, and it is the right counterweight:

In the end, it is not about generating additional paperwork, artifacts, or documentation. Rather, it is about ensuring greater visibility into the implementation of security and privacy controls which will promote more informed, risk-based authorization decisions.

Both things are true at once. The process degrades into paperwork wherever nobody is accountable for the decision it documents — OPM, where there were no consequences; FEMA, where the condition was waived. And it works wherever somebody is — CircleCI’s sponsoring agency, which rescinded an authorisation and made a vendor earn it back. The difference is not the framework. It is whether the signature means anything.

---

3.2.6 — Evaluation Criteria: TCSEC and ITSEC

What the book says

Three core concepts: TCSEC, the Orange Book, is the first evaluation criteria system; ITSEC followed it, developed by Europeans, incorporating elements of the Orange Book and others; and ITSEC applies to networked environments and measures functional and assurance elements separately from one another.

The book explains that the Orange Book was published by the US Department of Defense in the 1980s as part of the “rainbow series,” named for the different coloured covers — the Light Blue Book on passwords, the Red Book on network security, the Orange Book on measuring security products. It notes that TCSEC “only measures confidentiality, which reflects the Department of Defense’s mission in the early ’80s,” that it measures single-box architectures and “does not map well to networked environments,” that ratings run from lowest to A1, and that most products were rated at C2 or B1. Each level inherits the characteristics of the one below.

ITSEC, it says, measures more than confidentiality, works in a network environment, and splits the rating in two: F levels for function, E levels for assurance, from E0 to E6.

The concepts are right. The tables contain three errors and one significant omission, and the closing sentence about ITSEC’s death is false in a way that turns out to be the best story in this subsection.

Correction one: there is no class D1

CISSP‘s Table 3-7 lists the lowest TCSEC class as “D1 — Failed or was not tested.”

There is no class D1. The Orange Book — DoD 5200.28-STD, 26 December 1985 — says:

Class (D): Minimal Protection
This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class.

There is Division D, containing a single unnamed class, then C1, C2, B1, B2, B3 and A1. And “or was not tested” is wrong twice over: Division D is explicitly for systems that were evaluated and failed. A system that was never evaluated has no rating at all — that is the entire difference between “we failed” and “we did not enter.”

That distinction is not pedantry, and it is directly examinable in the ITSEC section too, because ITSEC has the same shape: section 1.16 of the criteria states “E0 represents inadequate confidence.” E0 is a fail, not a floor. Both schemes reserve their lowest label for products that showed up and did not make it.

Correction two: nothing at any class “verifies no covert channels”

The book’s table describes B2 as “security labels and verification of no covert channels” and B3 as “security labels, verification of no covert channels, and must stay secure during start up.”

No class of the Orange Book requires or provides verification that no covert channels exist. What the classes actually require, quoted in 3.2.4 above: B2 requires a thorough search for covert storage channels and a bandwidth determination for each one found, by measurement or engineering estimate; B3 widens the search to covert channels generally; A1 adds that “formal methods shall be used in the analysis.” The requirement is search, measure and document, and the Orange Book then tells you which bandwidths are tolerable — under one bit per second in most environments, over 100 bits per second disqualifying.

That is a far more defensible engineering position than “verify none exist,” which, given Harrison–Ruzzo–Ullman, is not a thing anyone should be promising.

The real products, with real ratings

The Orange Book is often taught as though it were an abstraction. It was an evaluation programme with an Evaluated Products List, and the list is preserved. Some entries worth knowing:

Product	Class	Note
SCOMP, STOP Release 2.1 (Honeywell)	A1	CSC-EPL-85/001
Boeing MLS LAN Secure Network Server System	A1	28 August 1991, a network component under the Trusted Network Interpretation
Gemini Trusted Network Processor v1.01	A1	6 September 1994, also a network component
Multics MR11.0	B2	1 September 1985
Trusted XENIX 3.0	B2	8 April 1992, from Trusted Information Systems
Windows NT 3.5 with SP3	C2	31 July 1995, CSC-EPL-95/003
Windows NT 4.0 with SP6a	C2	November 1999

SCOMP is the one to know. The Final Evaluation Report states that “the SCOMP STOP Release 2.1 satisfies all the requirements of the Criteria Class A1.” The evaluated entity was hardware plus operating system together — the Honeywell Secure Communications Processor running the SCOMP Trusted Operating Program — so the correct name is “SCOMP STOP 2.1,” not “the STOP operating system.” Anderson describes it as a derivative of Multics whose STOP operating system “used Multics’ system of rings to maintain up to 32 separate compartments,” deployed in “military mail guards,” and adds that “SCOMP’s most significant contribution was to serve as a model for the Orange Book.” He also writes that SCOMP was the first system rated A1 — one authoritative secondary source, worth attributing rather than asserting, since no primary page examined says “first.” There is also a date conflict on the record itself: the Evaluated Products List row says 24 December 1984, while the Final Evaluation Report is signed 23 September 1985 and cites the 1983 criteria. Both are reported here; neither is chosen.

Two corrections for anyone reusing training material. Trusted XENIX was Trusted Information Systems, Inc., not IBM. IBM does appear on the EPL entry, twice — as the evaluated hardware (the IBM PC AT and the PS/2 Models 50, 60, 70, 70T, 70P and 80) and for binary compatibility with IBM Personal Computer XENIX 1.0 and 2.0 — but the vendor of record is TIS. And the famous Windows C2 caveat is true for NT 3.5 and false for NT 4.0. The NSA’s EPL entry for NT 3.5 states: “Because the evaluated configuration does not include a network environment, both products are considered stand-alone workstations.” So “Windows was only C2 if you unplugged the network” is accurate for the 1995 rating. The November 1999 entry for NT 4.0 says “a networked configuration was evaluated,” and Microsoft’s own archived statement agrees. NT 3.51, incidentally, never held TCSEC C2 at all; its rating was UK ITSEC E3 with functionality class F-C2.

When did TCSEC end? Two dates, both true, and they are not in conflict. Evaluations ended around 2000 — the Evaluated Products List’s last TCSEC entries are dated 09/00 (Sybase Adaptive Server Anywhere 7.0.0, at C2), while the page’s own footer reads “Last updated Wed Aug 16 10:34:01 2000.” Those two do not reconcile: a row post-dates the stamp on the page carrying it. Both are reported here as they read. A 2006 NIAP briefing gives the sequence as TPEP under TCSEC from 1983 to 1997, then TTAP, then NIAP/CCEVS from 2000. The standard was formally cancelled on 24 October 2002, by DoD Directive 8500.1, whose reference list carries “DoD 5200.28-STD… December 1985 (hereby canceled).”

ITSEC: the axis everybody drops

ITSEC is properly cited as Information Technology Security Evaluation Criteria, Version 1.2, dated 28 June 1991 on every page footer, printed and published by the UK Department of Trade and Industry as the “Harmonised Criteria of France – Germany – the Netherlands – the United Kingdom,” approved by SOG-IS. (The commonly repeated date for version 1.0 — May 1990 — has no source that could be opened, so it is not printed here.)

The book gets the two-axis structure right and misses that there are three. Section 1.15 of the criteria:

Three strength levels are defined – basic, medium, and high – which represent ascending levels of confidence in the ability of the security mechanisms of the TOE to withstand direct attack.

(That is the full clause; the version that circulates stops after “high” and puts a full stop where the criteria have a dash.)

A complete ITSEC rating is a reference to the security target, plus an assurance level, plus a strength of mechanism. Note the first axis carefully: the criteria say a rating names the security target, not necessarily a predefined functionality class, because those classes are optional. So a real rating reads “E3, high,” not “E3.” Strength of mechanism asks a different question from either of the other two: not what the product does, and not how carefully it was built, but how much effort an attacker must expend to defeat a given mechanism directly. A well-built implementation of a weak algorithm can score well on assurance and badly on strength. Dropping the third axis, as almost every CISSP summary does, removes the only part of ITSEC that measures resistance to attack.

For completeness: the ten classes ITSEC offers are F-C1, F-C2, F-B1, F-B2, F-B3, F-IN, F-AV, F-DI, F-DC and F-DX. The criteria are more tentative about them than any summary suggests — it calls them “example predefined classes,” says they “are in draft form only,” and adds at section 2.62 that “the use of predefined classes is not obligatory.” Section 1.39 gives the mapping back to the Orange Book — F-C2/E2 corresponds to C2, F-B1/E3 to B1, F-B3/E6 to A1.

Correction three: ITSEC was not replaced in 2005 — and a lorry tachograph proves it

The book’s ITSEC section ends with a single flat sentence: “ITSEC was replaced by Common Criteria in 2005.”

That is false, and the evidence against it is a much better lesson than the claim.

First, the SOG-IS Mutual Recognition Agreement version 3.0, dated 8 January 2010, Article 2:

This Agreement covers claims of compliance against any of the Common Criteria Evaluation Assurance Level 1 through 4 or ITSEC Assurance Level E1 through E3 with Strength of Mechanisms “basic”.

An international recognition arrangement, five years after ITSEC’s supposed death, explicitly recognising ITSEC assurance levels. There is no version 4; v3.0 remained the applicable agreement.

Second, and this is the good part: European law had written ITSEC into itself. From European Commission document COM(2011) 454 final, on digital tachographs — the devices that record driving hours in commercial vehicles across the EU:

The current tachograph legislation has set a certain security level… (called “ITSEC level E3 high”).

A European regulation hard-coded a specific ITSEC rating as a legal requirement for a mass-market device fitted to every lorry in the Union. Once that phrase is in the legal text, no product can be certified against anything else — and the standard cannot die until the law is changed.

Third, therefore, the certificate. Stoneridge Electronics AB SE5000 digital tachograph, version 7.6, certificate BSI-DSZ-ITSEC-0959-2015, issued by the German Federal Office for Information Security on 18 August 2015. BSI’s own list prints the level as “E3/hoch” — the German word, in an otherwise English document; “E3 / high” is a translation, so say which you are giving. A national certification body issuing an ITSEC certificate ten years after the book says the scheme was replaced, because a regulation about lorries required it. (A second full example, if you want one with a published report: Setec Signature Card SetEID v1.0, E3 with strength “high,” certificate T-Systems-DSZ-ITSEC-04016-2003, Bonn, 18 July 2003.)

There is no single defensible end date for ITSEC. Three anchors are defensible: 8 January 2010, the last agreement recognising it; 18 August 2015, the latest verified certificate; and 27 February 2026, the date from which, in SOG-IS’s own banner wording, “SOG-IS cease to emit certificates” — the notice says as of, not that anything was announced that day.

This is the most concrete illustration available of why compliance regimes ossify, and it is worth carrying into any regulated environment. A standard does not die when the technical community moves on. It dies when the last instrument of law that names it is amended. Write a version number into a regulation and you have created an obligation that will outlive the thing it points at, be maintained at public expense, and require a legislative act to retire. Every reader who has argued with an auditor about a control requirement traceable to a superseded standard has met this problem; the tachograph is its purest form.

The change that actually mattered, and the book does not mention it

The book presents ITSEC as a straightforward improvement on the Orange Book: more than confidentiality, works in networks, separates function from assurance. All true. But the structural change ITSEC introduced was not in the criteria. It was in who pays the examiner.

Anderson:

European countries developed the Information Technology Security Evaluation Criteria (ITSEC), a shared scheme to help their defense contractors compete against US suppliers. This introduced a pernicious innovation – that the evaluation was not arranged by the relying party (the government) but by the vendor. Vendors started to shop around for the lab that would give their product the easiest ride… Contractors could obtain approval as a commercial licensed evaluation facility (CLEF), and in theory the CLEF might have its license withdrawn if it cut corners. That never happened.

Under TCSEC, the US government evaluated products because the US government was going to buy and rely on them. The evaluator’s client was the party bearing the risk. Under ITSEC — and therefore under Common Criteria, which inherited the model — the vendor selects and pays the laboratory that will assess the vendor’s product.

This is not a subtle conflict of interest and it is not hypothetical; it is the same structural problem that produced the Global Research Analyst Settlement in 3.2.4, and the same one that auditor independence rules exist to prevent. Every criticism of Common Criteria you will read in the next section flows from this single change, and it is the fact the book’s account of 3.2.6 is missing.

Which is a strange thing to notice about a section of the syllabus that comes immediately after one about conflicts of interest.

---

3.2.7 — Common Criteria

What the book says

ISO 15408, the Common Criteria, is “the most used of the evaluation criteria systems and is also the most popular.” Several countries joined together to create a measurement system trusted globally, so that a rating earned in Germany can be relied on in the United States. Licensed organisations around the world perform the evaluations.

The process, as the book lays it out:

• Protection Profile (PP) — the security capabilities a category of product should possess. There is one for firewalls, one for access controls, one for intrusion detection systems.
• Target of Evaluation (TOE) — the specific product being evaluated.
• Security Target (ST) — the vendor’s written statement of how its product’s functional and assurance capabilities meet the Protection Profile’s requirements.
• Security Functional Requirements and Security Assurance Requirements — the two lenses each target is examined through.
• Evaluate, then assign an EAL from 1 to 7, where EAL1 is “functionally tested,” EAL4 “methodically designed, tested, and reviewed,” EAL6 “semi-formally verified, designed, and tested,” and EAL7 “formally verified, designed, and tested.”

And the book adds three practical points: most organisations will not buy a product rated above EAL4; operating systems are typically at EAL3 and firewalls at EAL4; and once assigned, an EAL stays the same for the product’s life span through patches and updates, unless a major functional change prompts re-evaluation.

The component vocabulary is exactly right and highly examinable. Learn PP, TOE, ST, SFR, SAR, EAL in those words. Three of the practical points need updating, and the most important fact about Common Criteria today is absent from the book entirely.

A real certificate, in full

Here is a current, named, fully specified Common Criteria certificate, so the vocabulary above attaches to something.

Field	Value
TOE	Red Hat Enterprise Linux 9.4, build cc-config-9.4-1
Certificate ID	CCEVS-VR-VID11526-2025
Date	25 February 2025 (evaluation completed November 2024)
Scheme	US NIAP Common Criteria Evaluation and Validation Scheme
Validation body	NIAP (joint NSA/NIST); validators from MITRE and JHU/APL
Evaluation laboratory	Lightship Security USA, Inc., Baltimore MD
Sponsor / developer	Red Hat, Inc., Raleigh NC
Protection Profile	Protection Profile for General Purpose Operating Systems v4.3 (27 September 2022), plus the Functional Package for Secure Shell v1.0 and the Functional Package for TLS v1.1
EAL	None claimed — conformance result “CC Part 2 extended, CC Part 3 extended”
CC version used	CC and CEM v3.1 Revision 5, April 2017

Two things there should stop a reader who learned this section from the book.

The certificate claims no EAL at all. Not EAL3, not EAL4. The conformance result is “CC Part 2 extended, CC Part 3 extended” against a Protection Profile. The book teaches EAL as the thing a product gets; this 2025 certificate for one of the most widely deployed operating systems in the enterprise world does not have one.

And it was issued under CC 3.1 Revision 5, in 2025 — which tells you that version is still live, even though it is no longer current.

Note also the TOE boundary, from the report’s physical boundary section: “The TOE is a software TOE and is comprised of the following: Red Hat Enterprise Linux 9.4, build cc-config-9.4-1.” The hardware is explicitly outside the TOE. The report’s section 3.3 lists three evaluated platforms, not one — Intel Xeon Silver x86-64 UEFI (Cascade Lake microarchitecture), IBM z16 under PR/SM (LPAR), and Power10 under PowerVM (LPAR) — alongside the other required non-TOE components: an update server, an SSH client and an SSH server. Hold that too. It matters enormously in a few paragraphs.

The single most consequential fact about Common Criteria, which the book omits

Why does a 2025 enterprise operating system certificate carry no EAL?

Because of a decision the Common Criteria’s own signatories took in 2014, and it is the fact that reframes this entire subsection.

The governing document is the Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security, dated 2 July 2014 and ratified 8 September 2014. Article 2, on scope:

This Arrangement covers certificates with claims of compliance against Common Criteria assurance components of either:

1. a collaborative Protection Profile (cPP), developed and maintained in accordance with Annex K, with assurance activities selected from Evaluation Assurance Levels up to and including level 4 and ALC_FLR, developed through an International Technical Community endorsed by the Management Committee; or
2. Evaluation Assurance Levels 1 through 2 and ALC_FLR.

In plain English: since 2014, mutual international recognition of a Common Criteria certificate stops at EAL2, except along a specific route — conformance with a collaborative Protection Profile developed by an endorsed international technical community.

A product can still be evaluated at EAL5, EAL6 or EAL7. The certificate is still issued. What it no longer carries is the thing the scheme exists to provide: automatic recognition by the other signatory nations. A German EAL6 certificate is a German document with a national reputation behind it, not a globally recognised rating.

Three nuances that most write-ups get wrong, and this is where a CISSP candidate can be more precise than almost any published summary:

1. The second branch reads “Evaluation Assurance Levels 1 through 2 and ALC_FLR.” ALC_FLR — flaw remediation — is listed as a recognised component alongside EAL1–2, not as an augmentation bolted onto EAL2.
2. Even the cPP branch is capped at EAL2 by default. Annex K.1: “cPPs shall only include assurance components to a maximum of EAL2, except where the International Technical Community can demonstrate a rationale that activities up to and including EAL4 can be reproduced between schemes.” So “cPPs go up to EAL4” is the exception, requiring a demonstrated rationale, not the rule. The default everywhere is EAL2.
3. The cap is printed on the certificate itself. The Arrangement’s annex specifies that where the confirmed assurance package includes components above EAL2, the recognition logo is amended to read: “CCRA recognition for components up to EAL 2 and ALC_FLR only.”

Sit with the third one. The scheme requires a product’s own certificate to carry a printed statement that most of what it just certified is not internationally recognised.

Why did the signatories do this? The Arrangement does not say. I read all forty-nine pages looking for a stated reason and there is none; the preamble offers a general observation instead, that “the complexity of information systems is such that even the most carefully written security Evaluation criteria… cannot cover every eventuality.” So do not put a finding in their mouths.

What the document does supply is the test they set themselves, and it is nearly as damning. Anything above EAL2 travels between countries only where an International Technical Community can “demonstrate a rationale that activities up to and including EAL4 can be reproduced between schemes.” Cross-scheme reproducibility is the bar the signatories wrote — and by default, everything above EAL2 does not clear it. That is not a critic’s characterisation of Common Criteria. It is the scheme’s own condition, in the scheme’s own instrument.

The book never mentions the cap. Everything else in its treatment of EAL follows from that omission.

Correcting the book’s EAL claims

“The Common Criteria, in its third and most recent version, is by far the best one available today.” CC 3.1 Revision 5 is no longer the most recent version. The current release is CC:2022 Release 1, November 2022, CCMB-2022-11-001, published by ISO as ISO/IEC 15408-1:2022 through 15408-5:2022 — five parts, of which parts 4 and 5 are new. (Release 1 is not the whole story: CC:2022 carries mandatory errata, currently at v1.2, so a citation to the release alone is incomplete.) Under transition policy CCMC-2023-04-001 of 20 April 2023, CC v3.1 R5 “may optionally be used for evaluations of Products and Protection Profiles starting no later than the 30th of June 2024,” and Security Targets conformant to CC:2022 that are based on CC v3.1 Protection Profiles “will be accepted up to the 31st of December 2027.” So: no new 3.1 evaluations could start after June 2024, existing 3.1 work is still being certified (see RHEL 9.4, February 2025), and the book is one major version behind.

For the version chain, since it is occasionally asked: CC 1.0 was completed in January 1996 and distributed by ISO in April 1996 as a committee draft — though the Common Criteria Portal’s own ICCC history page, currently live, states that “Common Criteria version 1.0 was issued in 1994.” That is a contradiction inside the scheme’s own material, worth knowing about rather than resolving. CC 2.0 was issued in May 1998 and adopted by ISO/IEC JTC 1 with minor editorial modification in June 1999; ISO/IEC 15408 was first published in 1999.

“Operating systems are typically at EAL3 and firewalls at EAL4.” This describes a world that ended in 2014. Modern certificates for both categories are conformance claims against collaborative Protection Profiles, frequently with no EAL. The RHEL 9.4 certificate above is the demonstration.

“If a product is at EAL7, it could become more vulnerable to compromise, due to being more complex and harder to maintain.” This is backwards as a mechanism, and the book’s conclusion is nonetheless right, so it is worth fixing carefully. A higher EAL does not make a product more complex. EAL measures assurance work performed on the product, not features in it: the same unchanged product can be evaluated at a higher level purely by doing more design analysis, more testing and more documentation. Nothing about EAL7 adds attack surface.

What is true is the consequence. High-assurance evaluation is so slow and so expensive that products carrying it are old by the time they ship, sell in tiny volumes, and cost a great deal. As Anderson puts it, “Evaluated products were always obsolete, so the market stayed small, and prices stayed high.” An organisation buying at EAL6 is buying a product designed years ago, maintained by a vendor with few customers, at a price that will discourage replacement. That is a real risk, and it is worth the book’s warning — but the mechanism is procurement economics, not product complexity. Keep the conclusion; fix the reason.

“If a product is patched or receives software/firmware updates, the EAL level remains the same.” This is correct and it is the point at which candidates should feel uneasy, because the next section is about what that means in practice.

What a certificate actually certifies: read the scope

The most useful thing a working professional can learn from Common Criteria is how to read a certificate’s scope statement, because the scope is where the value is decided.

From the RHEL 9.4 Validation Report, section 6, “Clarification of Scope,” in the validators’ own words:

The scope of this evaluation was limited to the functionality and assurances covered in PP_OS_v4.3… Other functionality included in the product was not assessed as part of this evaluation. All other functionality provided by the devices needs to be assessed separately, and no further conclusions can be drawn about their effectiveness.

This evaluation did not specifically search for, nor attempt to exploit, vulnerabilities that were not “obvious”…

And the assumptions the evaluation rests on, from its section 5:

• A.PROPER_USER — “The user of the OS is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy. At the same time, malicious software could act as the user, so requirements which confine malicious subjects are still in scope.”
• A.PROPER_ADMIN — “The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.”
• A.PLATFORM — “The OS relies upon a trustworthy computing platform… This underlying platform is out of scope of this PP.”

Quote those in full, because the halves that usually get trimmed are the load-bearing ones. A.PROPER_USER does not simply assume good users and stop: it goes on to say that malicious software may act as the user, and that confining malicious subjects therefore remains in scope. That is NIAP reasoning precisely about the gap this section is about, in the assumption that looks most like hand-waving.

Read the set as a purchaser. This certificate says: we tested the parts named in one Protection Profile, we did not test anything else in the product, we did not look for non-obvious vulnerabilities, and we assumed that users and administrators are working within the enterprise’s security policy and that the hardware underneath is trustworthy — while still holding the product responsible for malicious code running with a user’s privileges.

That is not a criticism of NIAP. It is NIAP being scrupulously honest about what an evaluation is, printed in the report, for anyone who reads past the certificate number. The failure is not in the document. It is in an industry that treats “Common Criteria certified” as a security claim when the document itself says, in its own section headed Clarification of Scope, that no conclusions can be drawn about anything it did not examine.

The older, EAL-based world said the same thing more bluntly. From the UK certification report for Trusted Solaris 8:

Certification is not a guarantee of freedom from security vulnerabilities; there remains a small probability (smaller with greater assurance) that exploitable vulnerabilities may be discovered after a certificate has been awarded.

The issue of a Certification Report is not an endorsement of a product.

When the gap in the scope is the vulnerability

Two cases where certified products were broken, and in both the certification did not merely fail to prevent the break — its own boundary drawing helped create it.

ROCA, and the certificate that names the broken library. In 2017, Matúš Nemec, Marek Sýs, Petr Švenda, Dušan Klinec and Vashek Matyáš published “The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli” at ACM CCS in Dallas. Their abstract:

The library in question is found in NIST FIPS 140-2 and CC EAL 5+ certified devices used for a wide range of real-world applications, including identity cards, passports, Trusted Platform Modules, PGP and tokens for authentication or software signing.

(Keep the two assurance levels apart: the abstract says EAL 5+, describing the affected device population generally, while the specific certificate named below is EAL 6 augmented. Both statements are true and they are not the same claim.)

The flaw was in how a widely used cryptographic library generated RSA primes, and the authors are precise about the cause:

Optimizations that were motivated by a higher performance in the key generation process have inadvertently led to significantly weakened security of the produced keys.

The paper anonymises the vendor, but its own EMVCo reference names the master component, and that chip’s certificate is public: BSI-DSZ-CC-0782-V2-2015, covering the “Infineon Security Controller M7892 B11 with optional RSA2048/4096 v1.02.013, EC v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 libraries and with specific IC dedicated software (firmware),” at assurance level “EAL 6 augmented by ALC_FLR.1,” issued in Bonn on 3 November 2015. The vulnerable RSA library version is named in the title of an EAL6+ certificate.

The UK’s National Cyber Security Centre published guidance on 20 October 2017 confirming the affected devices as “Trusted Platform Modules (TPMs) and Secure Elements (SEs) produced by Infineon Technologies AG,” and reporting the researchers’ estimate of the cost to break an individual key at about $20,000 for 2048-bit and about $40 for 1024-bit. (Those figures are attributed in the guidance to “the researchers,” not asserted by NCSC. NCSC does not comment on Common Criteria there either; no CC opinion should be attributed to them.)

Infineon did publish. Its page, headed “Information on software update of RSA key generation function” — the page NCSC’s own guidance linked to — contained this:

Infineon immediately informed its related customers and offered mitigation paths. In parallel, the affected software function was updated in close co-operation with the research team, customers and the German certification body.

That URL now redirects away, so the accurate statement is that the vendor’s statement existed and has since been taken down. Read the sentence anyway: the vendor is describing coordination on the fix with the certification body that issued the EAL6+ certificate naming the broken library. This article’s argument about the limits of certification, stated by the vendor, in the vendor’s own announcement. (BSI has also published on ROCA, including a 2020 technical overview of Microsoft’s interim measures against CVE-2017-15361.) What I could not find is any record of a certificate being withdrawn over ROCA — a failure to find, not a finding that none was.

And there is a detail on that certificate that ties this whole section together in a single image. It carries the recognition mark described in the CCRA above — reading, in this case, “Common Criteria Recognition Arrangement for components up to EAL 4,” alongside a separate SOG-IS mark. (It reads EAL4 rather than EAL2 because it entered evaluation under the earlier arrangement.) So: an EAL6+ certificate, whose international recognition is capped far below its own stated level, naming by version number a cryptographic library that was subsequently broken.

And three inches above the EAL6 rating, that same certificate carries this:

This certificate is not an endorsement of the IT Product by the Federal Office for Information Security or any other organisation that recognises or gives effect to this certificate…

The document that everybody in this story treated as a warranty says on its own face that it is not one.

Taiwan’s national identity cards — the stronger case, because the certificate’s own text opened the gap. In 2013, Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja Lange and Nicko van Someren published “Factoring RSA keys from certified smart cards: Coppersmith in the wild” at ASIACRYPT. They factored 184 keys out of more than two million 1024-bit keys in Taiwan’s national Citizen Digital Certificate database — real identity keys, belonging to real citizens, on government-issued smart cards.

From section 7 of the paper:

The AE45C1 chip was certified conformant with Protection Profile BSI-PP-0002-2001 at CC assurance level EAL4+. The HD65145C1 card and HICOS operating system were accredited to FIPS 140-2 Level 2. The CC certification stated “The TOE software for random number postprocessing shall be implemented by the embedded software developer”, and the FIPS certification was limited to “FIPS mode”. However, neither certification prevented the same card from also offering a non-FIPS mode, and neither certification caught the underlying RNG failures. We recommend that industry move to stronger certifications that prohibit error-prone APIs and that include assessments of RNG quality.

And, from section 1.2:

This demonstrates a failure of the underlying hardware and the card’s operating system, both of which are covered by certification.

Look at the sentence in the middle. “The TOE software for random number postprocessing shall be implemented by the embedded software developer.” That is a certification explicitly moving responsibility for a critical security function out of the evaluated boundary and onto somebody else. It is the same move as A.PLATFORM in the RHEL certificate — a reasonable, standard, entirely proper piece of scope definition. And through that gap, 184 citizens’ national identity keys were factored by academics with a laptop and a good algorithm.

This is what the narrow-TOE problem looks like when it stops being an abstraction. It is not that evaluators are lazy or that schemes are corrupt. It is that a certificate is a statement about a boundary, security failures happen at boundaries, and the party reading the certificate is usually not the party who drew it.

For a third instance, Anderson’s summary of the IBM 4758 cryptoprocessor: “the IBM 4758 was evaluated by the U.S. government to the highest standard of physical tamper-resistance, and yet broken easily. The evaluators looked only at the tamper-resistant platform, while the attackers also looked at the software that ran on it.”

The objection: “Common Criteria is compliance theatre”

The strongest form of this objection comes from Anderson, and it should be quoted rather than paraphrased, because a piece that only argues one way is a brochure.

That world is now moribund: the idea that a device should be secure because someone spent $100,000 getting an evaluation lab to test it five years ago would strike most people nowadays as quaint. Assurance is no longer static.

Third-party evaluation schemes such as the Common Criteria were supposed to make these risks more transparent and mitigate them, but ended up acting as a liability shield – particularly in the public sector and in regulated industries such as banking.

The biggest complaint for years has been the cost and bureaucracy… A startup wanting to sell devices such as HSMs will nowadays have to spend several million Euros and several years of effort to navigate the process. In practice the CC have become a moat that defends established cartels.

friendly reviews, by people who want the system to pass, are essentially useless compared with contributions by people who are seriously trying to break it. That’s the basic reason evaluations paid for by the vendor from one of a number of competing evaluators, as in the Common Criteria and ISO 27001, are fundamentally broken.

The first word carries the whole sentence, and it is routinely dropped in quotation. Anderson is not saying review is useless; he is contrasting friendly review with hostile review, which is the difference between an evaluation and an attack.

On what the cPP route has become in practice:

Outside Europe… the CC system has been completely captured by vendor interests. American firms offer many firewalls, routers and other networking products, evaluated according to industry cPPs; and Japanese firms offer a range of printers and fax machines. So what is a secure fax machine – does it encrypt faxes? Not at all; it just behaves as you’d expect a fax machine to (if you’re old enough to remember them).

In short, cPPs have become a marketing mechanism, and are now undermining the traditional CC core.

And on Protection Profiles as a purchaser’s tool: “look hard at the protection profile: check whether it maps to what you really need. (Usually it doesn’t — it protects the vendor, not you.)”

That last one is the most immediately actionable sentence in this entire article. When a vendor tells you a product is Common Criteria certified, the only useful next question is against which Protection Profile, followed by reading it and asking whether the properties it requires are the properties you need. A firewall certified against a firewall PP has demonstrated that it behaves as a firewall is expected to behave. That is not nothing. It is also not a statement that it will resist your adversary.

The objection has institutional teeth as well as rhetorical ones. The UK’s National Cyber Security Centre states plainly: “On 1 October 2019 we ceased to be a certificate producer under the Common Criteria Recognition Agreement (CCRA).” One of the founding nations stopped issuing certificates. Be exact about the reasons NCSC gives, though, because they are narrower than the slogan version: it says the scheme’s relevance “in the wider cybersecurity context, is diminishing,” and that “the operation of a national common criteria certification scheme is no longer an appropriate use of our resources.” It does not say the Criteria are neither necessary nor sufficient for security — that formula is this article’s, not NCSC’s — and it explicitly does not repudiate the scheme, adding that “the UK will continue to recognise CCRA compliant certificates.” Withdrawing as a producer is not the same act as denouncing the product. (Note also NCSC’s own “Agreement” where the instrument itself says “Arrangement”; the quotation is theirs, verbatim.) And Anderson’s 2020 count of the top of the scheme: “in 2020 there are 85 products at EAL6 or above out of 1472 certified under CC” — about 5.8% of certificates in the levels the exam spends the most time on. That percentage is arithmetic on his two figures, not his.

The honest answer is not a defence. The critique is largely correct, and — this is the point the exam will never tell you — the scheme’s own governance has written the limit into its own instrument. The 2014 CCRA cap is that limit. The signatories made cross-scheme reproducibility the condition for recognising anything above EAL2, did not extend recognition past it, and then required certificates carrying higher levels to print the limitation on their own face. They give no reason for the cap in the text; they did not need to, because the condition says it.

The sharpest criticism of the Common Criteria is a clause inside the Common Criteria.

What remains, and it is not nothing, is the documentation. The book is right that the value of the process is in what it produces: a Security Target and a validation report, published, naming exactly what was tested, what was assumed, and what was excluded. Used as a rating, “CC certified” is close to meaningless. Used as a document — read, with its scope statement and its assumptions — it is the most detailed public description of a product’s security behaviour that most vendors will ever release.

---

The last objection: “this is exam trivia with no field use”

Two of the three standard objections to this section have already been answered where they arose — MLS as a failed product category in 3.2.3, Common Criteria as compliance theatre in 3.2.7. The third is the broadest: that the whole of 3.2 is a museum, memorised for an exam and never used again.

The strongest version of that objection does not come from a sceptic. It comes from David Bell, in the same 2005 paper that opens this article, looking back at the field he helped create:

At the beginning of the 21st Century, product evaluation for high-security systems is moribund. DARPA correctly views computer and network security as past the research stage. Individual program offices rightly have primary focus on their program, not on the greater good. No one has the mission of “selfless acts of security.”

On the certification and accreditation front, quick was the enemy of strong security. System acquisitions and deployments increasingly began to face hard choices between sound security and speedy approval… The running joke is that everyone wants to be second through the gate.

The structural changes to product evaluation initiated in the early 1990’s had the effect of terminating community evaluation of highly secure systems. The stock of secure-system resources was therefore frozen and attrition further thinned the ranks. Without sales of their secure products, the vendors rightly viewed them as under-performers.

Everyone wants to be second through the gate. Twenty-one years later that sentence still describes most security programmes accurately, and it was written by the man who wrote the model.

But read what Bell is actually indicting. He is not saying the models were wrong. He is saying the institutions built to certify systems against them collapsed — the evaluation programmes, the specialist vendors, the community of people who knew how to do the work. That is a claim about an industry, and it is true.

The models themselves went the other way, and the evidence is in this article:

• Red Hat’s documentation names Bell–LaPadula and implements the strong star property, in a current enterprise Linux.
• Microsoft’s architecture documentation names Biba and specifies exactly which of its properties Windows enforces, on a mechanism running on hundreds of millions of machines.
• Meta names information flow control as the principle behind a system doing trillions of consent checks an hour.
• Every Android and iOS device on earth runs mandatory access control, protecting the operating system from applications.
• A European regulation and a German certificate kept an evaluation standard alive a decade past its reported death.
• A US enforcement settlement in 2003 required firms to “physically separate their research and investment banking departments to prevent the flow of information between the two groups,” which is Brewer–Nash’s conclusion in a regulator’s language.
• A DARPA red team took a helicopter’s Linux partition in flight and could not get out of it, because the microkernel underneath had a proof.

None of that is a museum. What is a museum is the evaluation industry: the labs, the classes, the rating letters, the idea that a certificate five years old tells you something about a system today.

Bell’s own conclusion, in that same paper, is not that the work was wasted:

Multilevel secure components are unavoidable.

We have known for nearly a third of a century how to build and deploy strong and secure systems… It is time we got started.

What to actually take from this section

Strip out the corrections and this material does not get weaker. It gets more useful, and it reduces to four ideas that are worth more than the vocabulary.

A model is a deliberate loss of expressiveness, bought to make a question answerable. Harrison, Ruzzo and Ullman proved in 1976 that safety in a general protection system is undecidable. Every model on this exam is a restriction chosen so that something can be proved, enforced, or at least reasoned about. When you next design a permissions system, the instinct to make it maximally flexible is the instinct to make it unanalysable.

The interesting part of any deployed model is the part the engineer dropped. Microsoft dropped no-read-down and said why. Red Hat swapped the *-property for write equality. Windows is not Biba and Red Hat’s MLS is not Bell–LaPadula, and both vendors documented the departure. Read those departures; they are where the model meets the constraint that actually governs — user tolerance, in Microsoft’s case, which is the same constraint that governs your alert thresholds.

Separation of duties is a property of software, not of policy. Société Générale had the segregation. It existed in the procedures and it did not exist in the front-office system, and the difference cost €4.9 billion. Clark–Wilson’s access triple is precise about this for a reason: authorisation attaches to running a program, not to touching data. If a person can reach the object without going through the program, you do not have the control; you have a description of one.

A certificate is a statement about a boundary. The RHEL certificate excludes the hardware. The Taiwanese card’s certificate excluded random number post-processing. Both exclusions were proper and documented, and one of them cost 184 citizens their identity keys. Whenever you are handed an assurance artefact — a Common Criteria certificate, a SOC 2 report, a penetration test, a vendor questionnaire — the value is entirely in the scope statement, and the scope statement is always the part nobody reads.

---

Fifty-three years ago, at MITRE, Bell and La Padula could not think of a name for a rule, so the placeholder on the blackboard became the name, and it is still the name. The rule outlived the naming, the model outlived the machines it was written for, the evaluation industry built on top of it did not, and the mechanism is now running on every phone on the planet under labels that mean something entirely different from what its authors intended.

Which is roughly what the models were always for. Not to be right about the world, but to be precise enough about one narrow question that somebody could check the answer.

That is also why the last word here belongs to a sentence printed on a certification report, by the body that issued it, about the product it had just certified:

The issue of a Certification Report is not an endorsement of a product.

The people who do this work know exactly what their instruments can and cannot say. The problem has never been the instruments. It is everyone downstream who reads a certificate as a promise.

---

Key Takeaways

• Know the book’s definitions in the book’s words. A security model is “a representation of what security should look like in an architecture.” Certification is “the comprehensive technical analysis of a solution to confirm it meets the desired needs”; accreditation is “management’s official sign-off of certification for a predetermined period of time,” performed by the asset owner or management, never by the security function. Those are the highest-yield sentences in 3.2.
• Bell–LaPadula: confidentiality only. Biba: integrity only. BLP — simple security property (no read up), *-property (no write down), strong star property (read and write at your own level only). Biba — simple integrity property (no read down), *-integrity property (no write up), invocation property. Confidentiality flows up, integrity flows down; the inversion is what candidates lose under pressure. Lipner is not a model; it is an implementation combining both, separating objects into data and programs and applying sensitivity levels and job categories to subjects.
• The *-property is named after a blackboard placeholder. David Bell, ACSAC 2005: he wrote “*-property” over a figure, said in the room that they should change it before it stuck, “Nothing came to us,” and it remained. Also: there is no security model called the “Star Model,” despite the ISC2 outline listing one — it is Bell–LaPadula’s write rule.
• Harrison–Ruzzo–Ullman proved the general safety question undecidable (CACM 19(8), August 1976): “It is undecidable whether a given configuration of a given protection system is safe for a given generic right.” This is why every real system uses restricted policy languages instead of a general access matrix, and it is the best single answer to “these models are academic.”
• The models are running in current products, by name. SELinux MLS in RHEL 9/10 implements Bell–LaPadula — with “write equality,” which is the strong star property. Windows has shipped a Biba-shaped integrity lattice since Vista, and Microsoft published that it “does not enforce a strict integrity policy described in the Biba model,” having dropped no-read-down because full enforcement would have required too many user confirmations. Meta’s Policy Zones (23 July 2025) runs information-flow control over an exabyte-scale warehouse, performing trillions of consent checks per hour.
• Zachman is 1987, not the ’70s (IBM Systems Journal 26(3):276–292; first drafted 1984). And the 1987 paper is not the six-by-six grid: it develops three columns — what, how, where — over five perspectives, with who/when/why sketched in Appendix A, formalised by Sowa & Zachman in 1992; the six perspective names come from the 2011 Version 3.0 graphic. The US Federal Enterprise Architecture Framework is built on its first three columns, which in 1987 were all of them. SABSA was devised 1995 and first published 1996, originally as SALSA — and no named enterprise deployment could be verified from an independent primary source (Sherwood’s own account names S.W.I.F.T., but he is the co-author), so none is claimed here; the closest independent use is the Canadian Centre for Cyber Security building ITSP.80.032’s vocabulary on the SABSA layer model. TOGAF derives from the US DoD’s TAFIM, handed to The Open Group in 1995; a current named adopter is the Centre for Railway Information Systems / Indian Railways (Open Group Y251, 17 June 2025).
• Do not repeat “roughly 99 percent of covert channels are storage.” The figure has no source: the string “percent” appears zero times in TCSEC, no percentage in NCSC-TG-030 makes a prevalence claim about storage versus timing, and Lampson’s 1973 paper contains no percentages at all (four of his six examples use storage, which is my arithmetic, not his). NCSC-TG-030 says the storage/timing distinction is retained “exclusively for consistency with the TCSEC” and that “theoretically no fundamental distinction exists between them.” The real asymmetry is regulatory — TCSEC class B2 required a search for covert storage channels; B3 widened it to covert channels generally.
• Use the Orange Book’s real numbers. Over 100 bits per second is “high” and disqualifying, because that was terminal speed in 1985; under 1 bit per second is acceptable in most environments; 1 bit in 10 seconds is worth auditing. Meltdown’s Flush+Reload covert channel dumped memory at “3.2 KB/s to 503 KB/s” depending on the machine — 26,214 to 4.12 million bits per second, or roughly 260 to 41,000 times the 1985 disqualifying rate. Quote the range, not the ceiling.
• The pizza index: the spikes are real, the conclusion is not. Contemporaneously reported (Christian Science Monitor, 17 January 1991: Pentagon post-10 p.m. orders “surged to 101” against an average of 3; Washington Post, 19 December 1998, page D1, Frank Meeks and the “Washington pizza index”). But no source supports the claim that any outlet used pizza deliveries to predict the Desert Storm strikes — that traces to a 2016 magazine line hedged as “supposedly” and sourced to “online anecdotes.” In the 1998 record CNN appears as a pizza customer.
• For covert channels, use cases with CVE numbers. Timing: CVE-2016-6210, OpenSSH before 7.3, where a non-existent username was hashed with BLOWFISH and a real one with SHA256/SHA512, making response time leak account existence — reported by Eddie Harari of Verint, 14 July 2016. Storage: Rowland’s TCP/IP header channels (First Monday, 5 May 1997), or Meltdown’s cache channel. Heartbleed is a buffer over-read, not a covert channel; leftover data in RAM is data remanence, not a covert channel.
• Clark–Wilson’s access triple is the whole model. “A user is not given authority to read or write certain data items, but to execute certain programs on certain data items. The distinction between these two mechanisms is fundamental.” And the write-in-ink line: bookkeepers wrote in ink and made correcting entries so the books “being write-only, became the log.” That is append-only audit logging, described in 1987 as a rule for clerks.
• Société Générale is a separation-of-duties failure in software, not a back-office-knowledge story. Kerviel used a booking capability “normally reserved for trader assistants (but with no technical block preventing traders from using it)” — a sanctioned tool for correcting modelling biases that no control confined to the role it was written for. SG’s own investigation found the prescribed controls “were carried out in accordance with procedure” and did not detect the fraud; it found indications of internal complicity by a middle-office assistant, and an extensive personal network inside the control functions. The popular “he learned it in the back office” line is not what SG’s investigators concluded.
• Brewer–Nash models an existing legal obligation, and says so: the UK Stock Exchange’s Chinese Wall requirements “have the authority of law,” providing “a legitimate defence against certain penal classes of offence.” Its distinguishing mechanic is that access depends on the subject’s history. The best real case is the SEC’s Global Research Analyst Settlement of 28 April 2003 — ten firms, ≈$1.4 billion, approved 31 October 2003 — whose remedies require that “the firms will physically separate their research and investment banking departments to prevent the flow of information between the two groups” and ban compensating analysts from banking revenue. Your compliance team calls this an information barrier; the term “Chinese Wall” has been criticised as ethnically loaded since Presiding Justice Harry W. Low’s 1988 California concurrence, which proposed “ethics wall” in its place.
• The C&A vocabulary was formally retired. RMF replaced DIACAP in DoDI 8510.01 (12 March 2014). NIST SP 800-37 Rev 1 (2010) “transforms the traditional Certification and Accreditation (C&A) process into the six-step Risk Management Framework”; in Rev 2 (2018) the word “accreditation” appears zero times in 183 pages. Certification → assessment; accreditation → authorization (ATO); accreditor → Authorizing Official, “the only organizational official who can accept the security and privacy risk.” Answer the exam in the book’s words; speak to auditors in NIST’s.
• There is no universal ATO period. The three-year example was deleted from SP 800-37 Rev 1 on 5 June 2014; Rev 2 says “the authorization frequency is specified in lieu of an authorization termination date” and describes ongoing authorization as “time-driven or event-driven.” Three years persists in DoDI 8510.01 — whose stated basis is an OMB A-130 appendix that ceased to exist when A-130 was revised in July 2016.
• A real accreditation can be revoked. CircleCI Cloud, FedRAMP FR1814240140: authorised 26 September 2018; on 2 October 2023 the log reads “SBA rescinds ATO which is why we drop to FedRAMP Ready” (the agency is identified nowhere but in that log line, and never expanded); re-entered authorisation 21 November 2024; re-certified 23 January 2025. Contrast the failures: NASA OIG IG-21-019 (35 systems with expired ATOs as of March 2021); GAO-19-164 (FEMA’s ATO granted 5 February 2018 on a 45-day condition that was missed and then waived); and OPM’s Assistant IG testifying on 16 June 2015 that 11 of 21 systems were operating without valid authorisation, that there were “no consequences,” and that “None of the systems in violation were shut down.”
• There is no TCSEC class D1. The Orange Book has Division D, one unnamed class, “reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class” — evaluated and failed, not untested. ITSEC’s E0 is the same shape: “E0 represents inadequate confidence.” Real ratings: SCOMP STOP 2.1 at A1, Multics MR11.0 at B2, Trusted XENIX at B2 (Trusted Information Systems, not IBM), Windows NT 3.5 + SP3 at C2 in a stand-alone configuration — the “only if you unplug the network” caveat is true for NT 3.5 and false for NT 4.0, which was evaluated networked in 1999. Evaluations ended around 2000; the standard was cancelled 24 October 2002.
• ITSEC has three axes, not two. The security target (a functionality class is optional — the criteria call the ten predefined classes “example” classes, in “draft form only”), the assurance level E0–E6, and strength of mechanism: basic, medium, high. A full rating reads “E3, high.” ITSEC v1.2 is dated 28 June 1991, the harmonised criteria of France, Germany, the Netherlands and the UK.
• “ITSEC was replaced by Common Criteria in 2005” is false. SOGIS-MRA v3.0 (8 January 2010) still recognises ITSEC E1–E3; EU tachograph law hard-coded “ITSEC level E3 high”; and BSI issued certificate BSI-DSZ-ITSEC-0959-2015 for the Stoneridge SE5000 tachograph at E3/high on 18 August 2015. A standard dies when the last law naming it is amended, not when the technical community moves on.
• The structural change ITSEC made was who pays. Under TCSEC the relying party (government) commissioned the evaluation; ITSEC introduced vendor-commissioned evaluation, which Common Criteria inherited. Every criticism of CC flows from that.
• The CCRA cap is the most important fact about Common Criteria and the book omits it. Since the 2 July 2014 Arrangement, mutual recognition covers only “Evaluation Assurance Levels 1 through 2 and ALC_FLR,” or conformance with a collaborative Protection Profile. Even the cPP branch is capped at EAL2 by default under Annex K.1, with EAL4 an exception requiring a demonstrated rationale that the activities “can be reproduced between schemes.” Certificates above the cap must print “CCRA recognition for components up to EAL 2 and ALC_FLR only.” The Arrangement gives no reason for the cap; what it gives is the test — cross-scheme reproducibility — which by default nothing above EAL2 clears. The sharpest criticism of Common Criteria is a clause inside it.
• Modern certificates often carry no EAL. Red Hat Enterprise Linux 9.4, CCEVS-VR-VID11526-2025, 25 February 2025: Protection Profile for General Purpose Operating Systems v4.3, conformance “CC Part 2 extended, CC Part 3 extended,” no EAL claimed, hardware explicitly outside the TOE. The book’s “operating systems are typically EAL3, firewalls EAL4” describes the pre-2014 world. Current CC version is CC:2022 (November 2022, ISO/IEC 15408-1..5:2022); new 3.1 evaluations could not start after 30 June 2024.
• Fix the EAL7 reasoning, keep the conclusion. A higher EAL means more assurance work on the same product, not a more complex product. The real risk in buying high-EAL products is procurement economics: slow, expensive evaluation means obsolete products, small markets and high prices.
• Read the scope, always. NIAP on RHEL 9.4: “Other functionality included in the product was not assessed as part of this evaluation,” and the evaluation “did not specifically search for, nor attempt to exploit, vulnerabilities that were not ‘obvious’,” assuming users are not hostile, administrators are not careless, and the platform is out of scope. Certification did not prevent ROCA (the broken Infineon RSA library is named in the title of EAL6+ certificate BSI-DSZ-CC-0782-V2-2015) or the factoring of 184 Taiwanese national identity keys, where “the CC certification stated ‘The TOE software for random number postprocessing shall be implemented by the embedded software developer'” and “neither certification caught the underlying RNG failures.”
• And the sentence to remember from the certifiers themselves: “Certification is not a guarantee of freedom from security vulnerabilities… The issue of a Certification Report is not an endorsement of a product.”

Sources & References

All URLs were retrieved on 8 September 2026. Where two credible sources disagree on a date, both are shown above and neither is chosen.

The CISSP material

• CISSP, Certification, Domain 3, section 3.2, “Understand the fundamental concepts of security models,” subsections 3.2.1–3.2.7. Every quoted definition, core concept, table entry and example attributed to “the book” is from this section.
• ISC2, CISSP Certification Exam Outline, effective 15 April 2024. Objective 3.2 quoted in full; Domain 3 average weight 13%.

The origin papers

• D. Elliott Bell, “Looking Back at the Bell-La Padula Model”, Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC), Tucson AZ, 5–9 December 2005, pp. 337–351. Source of the *-property naming passage and of the “moribund,” “second through the gate” and “multilevel secure components are unavoidable” quotations.
• D.E. Bell and L.J. LaPadula, Secure Computer Systems, MITRE MTR-2547 / ESD-TR-73-278, Vols. I–III, 1973–74; Unified Exposition and Multics Interpretation, MTR-2997, 1975, revised 1976. Bibliographic details from the UC Davis Early Computer Security Papers collection and Bell’s own 2005 reference list. The two disagree on the date of all three volumes, and on the year of Volume III: Bell gives 1 March 1973, 31 May 1973 and December 1973; UC Davis gives Nov. 1973, Nov. 1973 and Apr. 1974. That disagreement is what licenses the “1973–74” span in the table above. Volume II, 31 May 1973 on Bell’s list, is the volume introducing the *-property and the source of the date and place in this article’s opening.
• K.J. Biba, Integrity Considerations for Secure Computer Systems, MITRE MTR-3153, June 1975; reissued as ESD-TR-76-372, April 1977.
• M.A. Harrison, W.L. Ruzzo and J.D. Ullman, “Protection in Operating Systems”, Communications of the ACM 19(8), August 1976, pp. 461–471. Abstract and Theorem 2 quoted.
• D.E. Denning, “A Lattice Model of Secure Information Flow,” Communications of the ACM 19(5), May 1976, pp. 236–243, DOI 10.1145/360051.360056.
• G.S. Graham and P.J. Denning, “Protection — Principles and Practice,” AFIPS Conference Proceedings, 1972 Spring Joint Computer Conference, Vol. 40, pp. 417–429.
• B.W. Lampson, “A Note on the Confinement Problem”, Communications of the ACM 16(10), October 1973, pp. 613–615. His channel list is numbered 0 through 6 — seven items — though he refers to it as “the six examples above”; the paper contains no percentages.
• Backes et al., “Semantic-based Automated Reasoning for AWS Access Policies using SMT,” Formal Methods in Computer-Aided Design (FMCAD), 2018 — the Zelkova encoding of IAM policies into SMT over strings, regular expressions, bit-vectors and integer comparison, and the PSPACE-completeness result. Source for the AWS half of the “restricted logic instead of the general question” claim in 3.2.1.
• Kubernetes documentation, “Using RBAC Authorization” — the escalate and bind verbs, which are the named opt-outs from default escalation prevention.
• S.B. Lipner, “Non-Discretionary Controls for Commercial Applications”, Proceedings of the 1982 IEEE Symposium on Security and Privacy, Oakland CA, 26–28 April 1982, pp. 2–10. This is a scanned original; the quotations above are OCR-derived and are therefore kept short. The lattice construction (System-Low / Audit-Manager; Production-Data, Production-Code, Development, System-Development, Tools; the System Control downgrade privilege) is from the paper’s own figures — note that Figure 4 prints only four categories, omitting Production-Code, which appears in Figures 5, 6 and 7; the model has five. The comparison to modern environment separation and promotion gates is this article’s, not Lipner’s.
• D.D. Clark and D.R. Wilson, “A Comparison of Commercial and Military Computer Security Policies”, Proceedings of the 1987 IEEE Symposium on Security and Privacy, pp. 184–194. Author affiliations as printed: Clark, MIT Laboratory for Computer Science; Wilson, “Director, Information Security Services,” Ernst & Whinney.
• D.F.C. Brewer and M.J. Nash, “The Chinese Wall Security Policy”, Proceedings of the 1989 IEEE Symposium on Security and Privacy, pp. 206–214. Gamma Secure Systems Limited, Camberley, Surrey. The “authority of law,” “legitimate defence” and insider dealing passages are from p.206 and the conclusion; the sanitized-data exception is the paper’s own. The word “permanently,” used above for the durability of a subject’s history, is this article’s — the paper supplies a matrix N that only ever flips to true. The paper’s cited authorities are the Securities and Investment Board Rules Ch. III Pt 5:08 and the Financial Services Act 1986 s.48(2)(h). The paper does not mention the 1986 “Big Bang.”
• G. Klein et al., “seL4: Formal Verification of an OS Kernel,” Proceedings of the 22nd ACM SIGOPS Symposium on Operating Systems Principles (SOSP ’09), Big Sky MT, October 2009. Cited here through the seL4 Foundation whitepaper; page numbers not verified and therefore not given. The “8,700 lines of C code and 600 lines of assembler” figures and the 2009 assumption set (compiler, assembler, hardware) are from this paper and describe the 2009 ARMv6 kernel, not from the current whitepaper, which lists three different assumptions.

Standards and criteria

• Department of Defense, Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, 26 December 1985 (superseding CSC-STD-001-83 of 15 August 1983). Source of the Division D text, the B2/B3/A1 covert channel requirements, the storage and timing channel definitions, and the 100 bits per second / 1 bit per second / 1 bit in 10 seconds bandwidth guidance.
• NCSC-TG-030, A Guide to Understanding Covert Channel Analysis of Trusted Systems (the Light Pink Book), November 1993. Section 2.2.1 quoted on the storage/timing distinction. Counts taken over the full text: 62 “timing channel,” 49 “storage channel.” The guide does contain five percentage figures; none is a prevalence claim about storage versus timing.
• Information Technology Security Evaluation Criteria (ITSEC), Version 1.2, 28 June 1991, Department of Trade and Industry, London. Sections 1.15 (three strength levels, quoted with its full “ascending levels of confidence” clause), 1.16 (E0), 2.62 (“the use of predefined classes is not obligatory”), 5.2 (a rating references the security target, the evaluation level and the confirmed minimum strength of mechanisms), and 1.39 (the TCSEC mapping). The criteria describe the ten classes as “example predefined classes” that “are in draft form only.”
• Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security, 2 July 2014. Article 2 (scope), Annex K.1 (the EAL2 default cap on cPPs and the “can be reproduced between schemes” condition), and Annex J.2 specifying the amended recognition logo wording. The 8 September 2014 ratification date appears nowhere in the arrangement’s own text; it comes from the Common Criteria Portal’s filing of the document. The arrangement states no reason for the cap.
• Common Criteria CC:2022 Part 1, Release 1, November 2022, CCMB-2022-11-001; CC v2.1 Part 1, August 1999, CCIMB-99-031; CC/CEM Transition Policy CCMC-2023-04-001, 20 April 2023. The ISO/IEC 15408:2022 five-part numbering is taken from the CC’s own foreword; iso.org blocks automated retrieval. CC:2022 carries mandatory errata, currently v1.2. The “version 1.0 was issued in 1994” statement is on the portal’s live ICCC history page (commoncriteriaportal.org/iccc/ICCC_arc/history.htm), not an archived copy.
• SOGIS Mutual Recognition Agreement v3.0, 8 January 2010, Article 2. SOG-IS’s site banner reads “As of 27th February 2026 SOG-IS cease to emit certificates” — a date from which, not a date of announcement.
• NIST SP 800-37 Rev 1, February 2010 (updated 5 June 2014) and SP 800-37 Rev 2, December 2018. The zero occurrences of “accreditation” in Rev 2 is a word count of the published PDF.
• OMB Circular A-130, revised 28 July 2016 — no Appendix III, no “every three years,” and the “time- or event-driven basis” reauthorization language (numbered list item 4). The circular’s PDF carries no printed revision date; the date is from the Federal Register notice, 81 FR 49689, 28 July 2016.
• DoDI 8510.01 (Change 3, 29 December 2020), Navy DON CIO copy; DoDI 5200.40 (DITSCAP), 30 December 1997; DoD Directive 8500.1 / 8500.01E, 24 October 2002, whose reference list cancels DoD 5200.28-STD. The 2014 DoDI 8510.01’s full title ends “(IT)”. DoDI 8510.01 was reissued 19 July 2022 as “Risk Management Framework for DoD Systems”; esd.whs.mil blocks retrieval, so that date is corroborated only by secondary listings and the text is not quoted.

Certificates and evaluation records

• NIAP, Validation Report CCEVS-VR-VID11526-2025, Red Hat Enterprise Linux 9.4, 25 February 2025. TOE definition, conformance result, Protection Profile, §3.3 platforms (Intel Xeon Silver Cascade Lake, IBM z16 PR/SM, Power10 PowerVM), §5 assumptions and §6 Clarification of Scope quoted. grep -i "EAL" over the whole 25-page report returns zero hits.
• UK IT Security Evaluation and Certification Scheme, Certification Report No. P170, Sun Microsystems Trusted Solaris 8 4/01, Issue 3.0, March 2004. Certification at EAL4 was completed in June 2002 per the report’s own text; March 2004 is the date of Issue 3.0, which adds the ALC_FLR.3 augmentation. Source of the joint LSPP/CAPP-to-B1/C2 equivalence statement and of the two closing caveats quoted at the end of this article. The report does not use the phrase “Orange Book”; that gloss is this article’s.
• BSI, certificate BSI-DSZ-CC-0782-V2-2015, Infineon Security Controller M7892 B11, Bonn, 3 November 2015, EAL6 augmented by ALC_FLR.1, with the printed CCRA recognition limitation and the printed “not an endorsement” disclaimer; certificate history.
• BSI, German IT Security Certificates, document 7148, March 2020 edition, p.6 — the Stoneridge Electronics AB SE5000 v7.6 ITSEC certificate BSI-DSZ-ITSEC-0959-2015 of 18 August 2015, whose level BSI prints as “E3/hoch.” Second ITSEC example: T-Systems-DSZ-ITSEC-04016-2003, Setec SetEID v1.0, 18 July 2003.
• NCSC Evaluated Products List, historical listing via the Internet Archive, and the individual entries for SCOMP (CSC-EPL-85/001), Windows NT 3.5 (CSC-EPL-95/003) and Windows NT 4.0 (TTAP-CSC-EPL/99-001). Microsoft’s archived position on the NT 4.0 networked evaluation: TechNet archive.
• FedRAMP Marketplace — 528 FedRAMP Certified Services as of 8 September 2026, of which 30 are FedRAMP 20x (a subset, not an addition; of 77 records carrying the 20x certification type, exactly 30 hold status “FedRAMP Certified”). CircleCI Cloud, FR1814240140 (the status event log containing “SBA rescinds ATO” — the string “SBA” appears once on that page, inside the log line, and is never expanded; the package’s structured fields record partnering_agency: null and name the General Services Administration for the agency authorisation, so the Small Business Administration reading is inference, not source); AWS GovCloud, F1603047866; Appian Government Cloud – High, FR2318051429. These counts and statuses change; re-check before relying on them.

Products and vendor documentation

• Microsoft, What is the Windows Integrity Mechanism?, ms.date 5 July 2007. All Biba comparison and departure quotations. Current reference: Mandatory Integrity Control.
• Red Hat, Using Multi-Level Security (MLS), RHEL 9. The Bell–LaPadula naming, the sixteen sensitivity levels, “Bell-La Padula with write equality,” the note that “security administrators can adjust this behavior by modifying the system’s SELinux policy,” and the “does not map well to general use-case scenarios” caveat — that caveat is quoted from the RHEL 8/9 wording; the RHEL 10 page exists at a different URL and reads “does not map well to typical use cases.”
• seL4 Foundation, Gernot Heiser, The seL4 Microkernel — An Introduction, revision 1.4.1, 17 July 2026. The proof description, the current three-assumption set, the “our assumptions on C semantics drop out of the assumptions made by the proofs” statement, the covert-timing-channel limitation, and the Boeing Unmanned Little Bird / DARPA HACMS red-team account. Line counts and the 2009 assumption set come from Klein et al. 2009, not from this document.
• Meta Engineering, Lucas Waye, Wenlong Dong, Boris Shulman, Yizhou Yan and Yuxuan Zhang, “Policy Zones: How Meta enforces purpose limitation at scale in batch processing systems”, 23 July 2025. Meta names Information Flow Control principles and states the propagation rule; it does not cite Denning or Bell–LaPadula, and the identification of that rule as a lattice ordering is this article’s reading.
• OpenSSH 7.3 release notes — the CVE-2016-6210 mitigation, quoted with its full conditional (“and particular password hashing algorithms are in use on the server”), and the credit to Eddie Harari.

Attacks and vulnerabilities

• M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom and M. Hamburg, “Meltdown: Reading Kernel Memory from User Space”, 27th USENIX Security Symposium, 2018; preprint arXiv:1801.01207, 3 January 2018. CVE-2017-5754, published 4 January 2018. The “3.2 KB/s to 503 KB/s” range is from §1 of the paper; the Conclusion separately gives “with up to 503 KB/s,” and the two must not be spliced. The comparison to the Orange Book’s 100 bits per second is this article’s arithmetic on the paper’s published figures. Note the arXiv author list omits Fogh and Horn; the USENIX list is used.
• “Spectre Attacks: Exploiting Speculative Execution,” 40th IEEE Symposium on Security and Privacy, 2019; preprint arXiv:1801.01203. CVE-2017-5753 and CVE-2017-5715, published 4 January 2018. The two covert-channel spans quoted above appear in the preprint; the 2019 published paper words both differently, so they are cited to arXiv:1801.01203. No report-to-Intel date is stated in either paper and none is given here.
• Y. Yarom and K. Falkner, “FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack”, 23rd USENIX Security Symposium, San Diego, 20–22 August 2014; presented in the Side Channels session on Friday 22 August. (USENIX’s own presentation page carries a stale “1 August” field — also a Friday at 10:30, which is how the wrong date propagates.) Page numbers not verified and not given.
• D.J. Bernstein, “Cache-timing attacks on AES”, 14 April 2005 — a self-published technical report, not a peer-reviewed paper. D.A. Osvik, A. Shamir and E. Tromer, “Cache Attacks and Countermeasures: The Case of AES,” CT-RSA 2006, LNCS pp. 1–20, DOI 10.1007/11605805_1; ePrint 2005/271.
• MITRE, CVE-2016-6210; original disclosure by Eddie Harari (Verint), Full Disclosure list, 14 July 2016.
• C.H. Rowland, “Covert channels in the TCP/IP protocol suite”, First Monday 2(5), 5 May 1997, DOI 10.5210/fm.v2i5.528. “Project Loki: ICMP Tunneling”, Phrack 49, 8 November 1996 — the file header reads “whitepaper by daemon9 AKA route / sourcecode by daemon9 && alhambra”; the issue’s contents page lists it “by daemon9/alhambra.” The 8 November 1996 date is Phrack 49’s masthead; the article’s own internal date line says August 1996.
• M. Nemec, M. Sýs, P. Švenda, D. Klinec and V. Matyáš, “The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli”, ACM CCS’17, Dallas, 30 October – 3 November 2017. Note the abstract says “CC EAL 5+ certified devices,” a general statement about the affected population, which is a different claim from the EAL6-augmented certificate named in the body. NCSC, ROCA guidance — the page stamp reads “Created: 20 Oct 2017 / Updated: 20 Oct 2017,” with a later banner noting an update at 12:30 on 24 October. The dollar figures are attributed there to “the researchers,” not asserted by NCSC, and NCSC does not comment on Common Criteria in that guidance. Infineon’s statement, headed “Information on software update of RSA key generation function” and linked from the NCSC guidance, is the source of the “in close co-operation with the research team, customers and the German certification body” quotation; the URL now redirects away, so it is quoted as a statement that existed and has been taken down. BSI has published on ROCA, including a 2020 technical overview of Microsoft’s interim measures against CVE-2017-15361.
• D.J. Bernstein, Y.-A. Chang, C.-M. Cheng, L.-P. Chou, N. Heninger, T. Lange and N. van Someren, “Factoring RSA keys from certified smart cards: Coppersmith in the wild”, ASIACRYPT 2013. Sections 1.2 and 7 quoted.

Government, regulation and enforcement

• NASA Office of Inspector General, NASA’s Cybersecurity Readiness, IG-21-019, 18 May 2021.
• GAO, FEMA Grants Modernization: Improvements Needed to Strengthen Program Management and Cybersecurity, GAO-19-164, April 2019; and Information Security: Agencies Need to Implement Consistent Processes in Authorizing Systems for Operation, GAO-04-376, transmittal letter dated 28 June 2004. The 53% is GAO’s own printed figure in its Table 3.
• Michael R. Esser, Assistant Inspector General for Audits, OPM, statement before the House Committee on Oversight and Government Reform, “OPM: Data Breach”, 16 June 2015.
• SEC, Press Release 2003-54, 28 April 2003, and Litigation Release No. 18111 — the ten firms, the four settlement components and the structural remedies. Final approval by Judge William H. Pauley III on 31 October 2003 per the SEC News Digest of 17 November 2003.
• SEC, “SEC Charges KPMG With Violating Auditor Independence Rules”, 24 January 2014 — the “mere appearance that they may be conflicted in exercising independent judgment” quotation is John T. Dugan, associate director for enforcement, SEC Boston Regional Office. SOX §201 as codified at 15 U.S.C. § 78j-1 — nine prohibited non-audit services, audit committee pre-approval, and the 5% de minimis exception. The SEC’s implementing rule (Reg. S-X 2-01(c)(4)) expands the statutory list and was not consulted.
• ABA House of Delegates Report 109 (Revised), amending Model Rule 1.10 — the substantive amendment is February 2009, followed by a housekeeping amendment in August 2009, so “as amended in 2009” is the safe form. Quoted from a law-firm mirror; americanbar.org blocks automated retrieval. Rule 1.10(a)(2)(i)–(iii) and Comment [7], quoted in full including “apportioned no part of the fee therefrom,” “which shall include a description of the screening procedures employed,” and “motions to disqualify a lawyer from pending litigation.”
• Peat Marwick Mitchell & Co. v. Superior Court, 200 Cal.App.3d 272 (1988), Low, P. J., concurring — the “ethnic focus” objection and the “ethics wall” proposal, read from the opinion text via the Caselaw Access Project. “P. J.” is the title Presiding Justice; the judge is Harry W. Low, Presiding Justice of Division Five, First Appellate District, and the first Chinese American judge in the Bay Area. No pinpoint page is given because sources differ.
• European Banking Authority, Guidelines on internal governance, EBA/GL/2021/05, 2 July 2021, paragraph 107. The phrase “four-eyes principle” does not appear in these guidelines; the binding requirement is Directive 2013/36/EU Article 13(1).
• European Commission, COM(2011) 454 final — “ITSEC level E3 high” in tachograph legislation.
• Société Générale, Mission Green General Inspection synthesis report, 20 May 2008 (French), and the Special Committee of the Board progress report, 20 February 2008 (official English translation). Losses, timeline, the provisions-booking control gap (quoted with its “pour corriger des biais de modélisation” purpose clause), the internal complicity findings and the bonus figures are from these two documents. The €30bn / 31 October 2007 leg appears only in the May French report, not in the February English translation. The two dates in the findings are not in conflict: 18 January 2008 is when the alert reached the support function, 20 January when the position was identified. The Commission Bancaire fine is not cited because its amount and date could not be verified.
• NCSC, Common Criteria — “On 1 October 2019 we ceased to be a certificate producer under the Common Criteria Recognition Agreement (CCRA),” together with the two stated reasons and the continuing-recognition sentence. Note NCSC writes “Agreement” where the instrument says “Arrangement.” This page is a JavaScript application: the sentence came back from a rendering fetch rather than from greppable page source, and the Internet Archive holds only the JS shell — so it is verified at lower confidence than the rest of this list, and worth an eyeball before reuse.

Frameworks

• J.A. Zachman, “A framework for information systems architecture”, IBM Systems Journal 26(3), 1987, pp. 276–292 (scanned original; the author biography on p.292 is the source of the “since 1970” career line). J.F. Sowa and J.A. Zachman, “Extending and formalizing the framework for information systems architecture”, IBM Systems Journal 31(3), 1992, pp. 590–616. The three-column limitation quoted above is from p.279 of the 1987 paper. Version history from Zachman Framework evolution, which says of the 1984 draft: “Notice it has only 3 Columns.” The six perspective names in general circulation (executive, business management, architect, engineer, technician, enterprise) are from the Version 3.0 graphic of 2011 and are not in the 1987 paper.
• Chief Information Officer Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0, February 2001 — the FEAF/Zachman relationship and “the first three columns.”
• J. Sherwood, “SALSA: A method for developing the enterprise security architecture and strategy,” Computers & Security 15(6), 1996, pp. 501–506, DOI 10.1016/S0167-4048(97)83124-0 (verified via Crossref; ScienceDirect blocks retrieval). David Lynas Consulting on SABSA’s origin; The SABSA Institute’s submission to NIST (“The first SABSA paper was published 1996”). No licence text stating open-source terms could be found on sabsa.org, so the book’s “open source” description is treated as unconfirmed. Sherwood’s own account on that site names S.W.I.F.T. as a deployment, but he is the framework’s co-author; no named enterprise deployment from an independent primary source could be confirmed, and SABSA’s own site says “we do not have a definitive list of user organisations.”
• Canadian Centre for Cyber Security, Calculating robustness for boundary controls (ITSP.80.032), March 2019, footnote 1.
• The Open Group, TOGAF and the US DoD Architecture Framework (DoDAF), Doc. No. W061, November 2006 — the TAFIM lineage and the DISA contribution. The TOGAF Standard, 10th Edition, launched 25 April 2022. Indian Railways Freight Business Architecture, Document Y251, 17 June 2025.

Critique and secondary

• Ross Anderson, Security Engineering, 3rd edition — chapter 9, “Multilevel Security” (Windows integrity levels, the NoReadDown quotation, label explosion and TCB bloat, the RAF LITS case, the MAC-on-Android/iOS/Windows conclusion, safety integrity levels, SCOMP) and chapter 28, “Assurance and Sustainability” (the ITSEC “who pays” change, the liability shield, the moat, cPPs as a marketing mechanism, the 85-of-1472 count, the GCHQ withdrawal). 2nd edition, chapter 26 (the protection profile warning, the “cherry pickers’ charter,” the IBM 4758).
• “Pizza Orders Rise with War Tension”, The Christian Science Monitor, 17 January 1991, compiled from wire services.
• Sarah Schafer, “With Capital in Panic, Pizza Deliveries Soar”, The Washington Post, Saturday 19 December 1998, page D1 (recovered via the Internet Archive).
• “The Pizza Meter Was a Staple of 1990s Pop Pseudoscience”, Slate, 2016 — the only traceable origin of the Wolf Blitzer line, which it hedges as “supposedly” and attributes to “online anecdotes.” “1990s pop pseudoscience” is the page title (the on-page headline is “What Can Pizza Tell Us About Ourselves?”); “horrendously unscientific data collection” is in the prose. The same piece reports that the Chicago Tribune published a pizzeria owner’s claim to have predicted imminent action — an outlet reporting a vendor’s prediction, which is not an outlet predicting.
• The 2011 bin Laden raid pizza-decoy anecdote is not used; see the block below.