Bell-LaPadula, Biba, and Clark-Wilson: The CISSP Security Models, Made Concrete

Nobody has ever run Bell-LaPadula in production, and that is not the point. The formal models in CISSP Domain 3 are how the profession learned to state a security policy precisely enough to prove something about it, and the exam uses them as a test of whether you can tell confidentiality from integrity when the scenario refuses to use either word. Get the models straight once and a whole class of questions stops being guesswork.

What a security model actually is

A security policy says what should be true: analysts must not disclose classified material to people without clearance. A security model restates that policy formally enough that you can reason about it: define the subjects, the objects, the states the system may occupy, and the rules for moving between them. If every permitted transition preserves the property you care about, the system is secure with respect to that property.

That framing explains two things candidates often find arbitrary. First, each model protects one property. Bell-LaPadula has nothing to say about whether your data is correct; Biba has nothing to say about who is allowed to see it. Second, the models are described as state machines: a secure state is one that satisfies the property, and the model's job is to ensure no legal operation takes you out of one.

Underneath most of them sits a lattice. Subjects and objects carry labels (Top Secret, Secret, Confidential) ordered so that any two have a defined relationship. A subject's clearance dominates an object's classification when it is equal or higher. Access decisions are then comparisons on that lattice, which is exactly what makes mandatory access control enforceable by the system rather than negotiable by a user.

Bell-LaPadula: confidentiality, and only confidentiality

Bell-LaPadula (1973, built for US Department of Defense multilevel systems) answers one question: how do you stop classified information leaking downward? Its two famous properties are best read as directions of information flow, not as rules of etiquette.

• Simple security property: no read up. A subject cleared at Secret cannot read a Top Secret document. Reading upward would pull classified information down to the reader's level.
• Star property: no write down. That same Secret subject cannot write into a Confidential file. Writing downward would push classified content into a container cleared to hold less.

The star property is the one that surprises people, because it forbids something that feels harmless: a cleared, trusted person writing a memo to a lower level. Bell-LaPadula does not model people, it models processes, and a process that has read Top Secret data may be carrying it, deliberately or through a Trojan. The rule closes the channel rather than trusting the carrier.

Two refinements the exam names. The strong star property requires a subject to read and write at exactly its own level: no reading down either. And a trusted subject is a process explicitly exempted from the star property, because real systems need sanitized declassification to happen somewhere; the model handles this by naming the exception rather than pretending it does not exist.

Bell-LaPadula's limitations are fair exam material too: it does not address integrity at all, it assumes a static classification lattice, and it says nothing about covert channels, a subject cannot write down, but it can still signal downward by modulating something observable, such as filling a disk or timing its own execution.

Biba: the mirror image, for integrity

Biba (1977) asks the opposite question: how do you stop bad data flowing upward into trusted places? Its rules are Bell-LaPadula's, reversed.

• Simple integrity axiom: no read down. A high-integrity process must not consume low-integrity input; that is how a trustworthy component gets fed garbage.
• Star integrity axiom: no write up. A low-integrity subject must not modify a high-integrity object.

The everyday version is unremarkable: your build pipeline should not pull dependencies from an unsigned mirror, and an unprivileged process should not be able to edit a system binary. Biba adds an invocation property as well (a subject may not invoke a service at a higher integrity level) which is the model's account of privilege escalation.

Because the two protect different properties, a system can enforce both at once, which is exactly what the Lipner model does, combining Bell-LaPadula labels for confidentiality with Biba labels for integrity in a commercial setting. Applying both simply narrows a subject's permitted reads and writes to where the two lattices agree.

Clark-Wilson: integrity the way businesses actually enforce it

Clark-Wilson (1987) was written as a rebuttal. Military models protect data from unauthorized users, but commercial fraud is usually committed by authorized ones. Its answer is to stop granting access to data at all, and grant access to programs instead.

Its vocabulary is worth learning precisely, because the exam uses the acronyms as answer options:

• CDI: constrained data item. Data whose integrity the system protects, such as the ledger.
• UDI: unconstrained data item. Data outside the protection boundary, such as a customer's uploaded file.
• TP: transformation procedure. A well-formed transaction; the only thing permitted to modify a CDI.
• IVP: integrity verification procedure. A check confirming that CDIs are in a valid state.

Two enforcement rules complete it. Well-formed transactions mean every change is made by a certified TP that leaves the data consistent and writes a log entry: the idea a database calls a transaction, applied as a security control. Separation of duties means the TPs are divided among people, so whoever raises a payment cannot also approve it. If a scenario mentions certified procedures, an audit trail, and duties split between staff, it is describing Clark-Wilson whether or not it names it.

Brewer-Nash, and the rest of the named models

Brewer-Nash, the Chinese Wall model, is the one built for conflict of interest rather than secrecy or correctness. Its distinguishing feature is that permissions are dynamic: a consultant may access any client's dataset at first, but the moment they open one bank's records, everything else in that conflict-of-interest class becomes unavailable to them. Access history changes access rights: no other model on the exam does that.

The remaining names appear as distractors more often than as answers, so recognition is enough:

How the exam turns this into scenarios

CISSP questions rarely say "which model." They describe a failure and ask what to apply. The translation is mechanical once you sort by harm:

Two habits make these fast. Ask what harm the scenario is complaining about before reading the options. That alone eliminates half of them. Then ask which direction the unwanted flow runs; the properties are named for directions, so the answer usually falls out.

Where models meet real evaluation

Models describe policy; assurance is the evidence that a product implements one. The exam pairs them, so know the lineage: TCSEC (the Orange Book, US, confidentiality-focused, graded D through A1) and ITSEC (European, and the first to separate functionality from assurance) were both superseded by the Common Criteria (ISO/IEC 15408), which is what you would cite today.

Common Criteria vocabulary is easy marks. The TOE is the target of evaluation: the thing being assessed. A protection profile (PP) is a customer-side statement of what a class of product must do; a security target (ST) is the vendor's claim about their specific product. The EAL, 1 through 7, states how rigorously that claim was verified, and the trap is always the same: a higher EAL means a more thorough evaluation, not a more secure product. An EAL4 product with a well-chosen security target can be far more appropriate than an EAL6 product evaluated against a target that does not match your use.

Sitting alongside all of this are the mechanisms that make a model enforceable: the reference monitor, the abstract component that mediates every access and must be tamper-proof, always invoked, and small enough to verify; its implementation, the security kernel; and the trusted computing base (TCB), the totality of protection mechanisms you are relying on. When a question asks what enforces a model, the reference monitor concept is what it is fishing for.

Security models sit in CISSP Domain 3, alongside secure design principles, cryptography, site and facility design, and the information system lifecycle objective added in the 2024 outline. They connect directly to identity and access management, where these abstractions become real authorization decisions, and to zero trust, which is in one sense the lattice idea rebuilt for networks that never had a perimeter. Work all 45 topics with our CISSP Domain 3 study guide.

#CISSP #ISC2 #SecurityModels #BellLaPadula #Biba #ClarkWilson #SecurityArchitecture #CommonCriteria #InfoSec #CyberSecurity