Security Models

"What actually enforces the policy?" is the trap the exam springs in this subtopic, and the answer is never the model itself: a model is only a rulebook, inert until a reference monitor mediates access against it and a security kernel inside the Trusted Computing Base implements that mediation. Get those four terms separated and you have the spine of the whole page (it assumes you already hold the CIA triad and the difference between a security policy, a goal, and a control, a mechanism). For each classic model the exam asks just two things, which pillar it protects and what component enforces it, so anchor every model to its pillar and its enforcer as you read.

A security model is a formal (frequently mathematical) statement of the rules a system must obey to satisfy a chosen policy goal, almost always one pillar of the CIA triad. It sits between the abstract policy ("a Secret user must not read Top Secret data") and the implementation (the code, kernel, and hardware). Its payoff is provability: instead of testing access decisions one case at a time, you can reason that the policy holds across every reachable system state. CISSP questions rarely ask you to prove anything; they ask you to map a named model to its pillar and recite its access rules in the correct direction.

The reference monitor: the enforcement core every model assumes

A model is inert unless something mediates every access attempt against it. That mediator is the reference monitor, which NIST defines as "a set of design requirements on a reference validation mechanism that ... enforces an access control policy over all subjects and objects" (NIST SP 800-53 Rev. 5 glossary^[1]). It must satisfy three properties at once: always invoked (complete mediation, no access bypasses it), tamperproof (protected from modification), and verifiable (small enough to be analyzed and tested for correctness).

The reference monitor is an abstraction; its concrete implementation is the security kernel, the "hardware, firmware, and software elements of a trusted computing base implementing the reference monitor concept" (NIST/CNSSI glossary^[2]). The security kernel and everything else trusted to enforce policy together form the Trusted Computing Base (TCB): the "totality of protection mechanisms within a computer system, including hardware, firmware, and software ... responsible for enforcing a security policy" (NIST/CNSSI glossary^[3]). The figure shows that nesting: the security kernel implements the reference monitor concept and sits inside the TCB boundary, while the model stays outside as the rulebook the kernel applies.

Keep these four straight, because the exam separates them deliberately: the model is the rulebook, the reference monitor is the design concept that mediates access, the security kernel is its implementation, and the TCB is the full trusted boundary you must evaluate for assurance. When a question asks "what enforces the policy?" the answer is the reference monitor / security kernel inside the TCB, never the model itself.

This section covers the two level-based (lattice) models. They behave by the same shared mechanic, so learn that mechanic once and then treat the two as opposites.

The shared mechanic: a lattice and two rules per model

Both Bell-LaPadula and Biba are multilevel security (MLS) models used to specify Mandatory Access Control (MAC), "an access control policy that is uniformly enforced across all subjects and objects" where the system, not the object owner, decides access (NIST SP 800-53 Rev. 5 glossary^[4]). Every subject and object carries a label drawn from an ordered set of levels (a lattice). Each model then states two rules: one constraining reads and one constraining writes. The trick to never confusing them is to anchor on the pillar each protects, then read the rules off the goal.

Bell-LaPadula (BLP): confidentiality

BLP's goal is to stop secrets from leaking down to a lower classification. NIST states its two rules plainly: a Secret process "should not be allowed to read a file with a label of Top Secret. This is known as the 'simple security rule,' or 'no read up.' Conversely, a [Secret] user ... should not be allowed to write to a file with a label of Confidential. This rule is called the '-property' (pronounced 'star property') or 'no write down'" (NIST IR 7316, Assessment of Access Control Systems, 2006^[5]). So: *Simple Security Property = no read up; Star () Property = no write down.* A common misread is that "no write down" is about protecting the writer. It is not; it stops a high-clearance subject from copying secrets into a low container where uncleared users could read them. BLP adds a tranquility property: a frequent exam form is the strong tranquility rule, that labels do not change during operation, versus weak tranquility, that labels may change only in ways that do not violate the policy. NIST also notes a stricter variant, the *strict -property, requiring that information be written at the subject's level only, not above it.

Biba: integrity, the exact inverse

Biba's goal is the mirror image: stop low-integrity (untrusted) data from flowing up and corrupting high-integrity data. So its rules invert BLP's. The Simple Integrity Axiom = no read down (a high-integrity subject must not read lower-integrity data, which might be corrupt) and the Star Integrity Axiom = no write up (a subject must not write to a higher-integrity object, which would let it inject untrusted content). NIST lists "the Bell-La Padula Confidentiality and Biba Integrity models" together as the canonical MLS pair (NIST IR 7316^[5]).

The single sentence that survives exam pressure: BLP keeps secrets from leaking down (no read up / no write down); Biba keeps garbage from flowing up (no read down / no write up). Because their write rules point in opposite directions, a system cannot enforce both simultaneously on the same labels, a detail distractors exploit.

This section covers the integrity and confidentiality models that do NOT use clearance levels. Read it after the lattice models, because its whole point is to handle cases BLP and Biba cannot. The figure first sets the whole map straight: each classic model is filed under the CIA pillar it protects, so a scenario question becomes "which pillar?" then "which model under it?".

Clark-Wilson: integrity through controlled transactions

Clark-Wilson enforces integrity in commercial systems where the concern is fraud and error, not military secrecy. Instead of labels, it requires that users never touch data directly: they act only through certified programs. Its core construct is the access triple (subject -> program -> object): a subject may operate on a constrained data item only through an authorized transformation procedure. Data is split into constrained data items (CDIs), which must stay consistent, and unconstrained data items (UDIs); transformation procedures (TPs) are the only operations allowed to change CDIs, and integrity verification procedures (IVPs) check that CDIs are in a valid state. Critically, Clark-Wilson builds in separation of duties so the person who creates a transaction is not the person who approves it. NIST classifies Clark-Wilson as the canonical example of Historical Separation of Duty (NIST IR 7316^[5]), and defines separation of duty as the principle that "no user should be given enough privileges" to misuse the system alone, enforced statically or dynamically (the two-person rule being a dynamic example).

Brewer-Nash (Chinese Wall): dynamic conflict of interest

Brewer-Nash, the Chinese Wall policy, addresses a problem neither level-based nor transaction-based models touch: commercial conflict of interest. NIST records that "Brewer and Nash identified the Chinese Wall policy ... to address conflict-of-interest issues" and that it is history-based: a subject's past accesses determine which objects they may access next (NIST IR 7316^[5]). The canonical example is a consultant who, having read data for one company in a conflict-of-interest class (e.g., one bank), is thereafter walled off from competitors in that same class. The wall is dynamic: at the start a subject can access anything, but each access narrows future choices. NIST notes the Chinese Wall is "a commercially inspired confidentiality policy" whose objective is "to prevent illicit flows of information" across the wall, so although it is often discussed alongside integrity models, its pillar is confidentiality.

Graham-Denning and Harrison-Ruzzo-Ullman (HRU)

Two more formal models govern the protection state itself rather than reads and writes of data. Graham-Denning defines a set of primitive rights and rules for securely creating and deleting subjects and objects and for transferring rights. Harrison-Ruzzo-Ullman (HRU) extends this and is famous for proving that, in the general case, the safety problem (deciding whether a given right can ever leak to a subject) is undecidable. The exam-level takeaway is simply that these answer "how are access rights themselves administered and is leakage provable?", which the data-flow models do not.

This section names three reasoning frameworks. They describe HOW a model proves security, not which pillar it protects, so a single named model can be more than one of them at once. The figure makes that overlap visible: Bell-LaPadula sits under two lenses because it qualifies as both a state-machine model and an information-flow model.

A state-machine model treats the system as a set of states and transitions and proves the system is secure in every reachable state and across every transition; a system that starts secure and only ever transitions to secure states is a secure state machine. Both Bell-LaPadula and Biba are state-machine models.

An information-flow model tracks how data moves between objects and security levels and blocks any flow that violates the policy. NIST's modern term is information flow control: "controls to ensure that information transfers within a system or organization are not made in violation of the security policy" (NIST SP 800-53 Rev. 5 glossary^[6]). Bell-LaPadula is the textbook information-flow model: its "no write down" rule is exactly a forbidden downward flow.

A noninterference model is stricter still: the actions of a higher-level subject must produce no observable effect on a lower-level subject. Its purpose is to defeat covert channels and inference, where a low-level user deduces high-level information indirectly. This is not hypothetical even under MAC: NIST warns that "information can pass through a covert channel in MAC, where information of a higher security class is deduced by inference such as assembling and intelligently combining information of a lower security class" (NIST IR 7316^[5]). Noninterference is the property that closes that gap.

Because these are lenses rather than rulebooks, an exam answer can correctly attach several to one model (BLP is a state-machine and an information-flow model), and a single "which type of model" question may hinge on which lens the stem emphasizes.

This section maps question shapes to the right answer. Read the others first; this is the pattern layer.

Pattern 1: "Which model protects [pillar]?" Confidentiality and a level/clearance scenario -> Bell-LaPadula. Integrity and levels -> Biba. Integrity in a commercial/financial transaction setting with separation of duties -> Clark-Wilson. Conflict of interest / competing clients -> Brewer-Nash (Chinese Wall). The trap answer is usually the other CIA pillar's model (offering Biba when the stem is about secrecy).

Pattern 2: direction of a rule. A stem cites "no write down" or the "*-property" -> Bell-LaPadula confidentiality. "No write up" or "Simple Integrity Axiom" -> Biba. The reliable method is to name the pillar first, then derive the direction: confidentiality stops secrets flowing down, so reads can't go up and writes can't go down; integrity is the inverse. Distractors swap one of the two rules (e.g., pairing "no read up" with "no write up"), which is internally inconsistent for either model.

Pattern 3: "What enforces the model / what must be evaluated for assurance?" The answer is the reference monitor (the design concept), implemented by the security kernel, within the Trusted Computing Base. The trap is to offer the model name itself, or to swap these three terms; recall that the reference monitor must be tamperproof, always-invoked, and verifiable (NIST SP 800-53 Rev. 5 glossary^[1]).

Pattern 4: Clark-Wilson specifics. Stems mentioning "well-formed transactions," "the access triple," or "a user may not both create and approve" point to Clark-Wilson; the underlying principle being tested is separation of duties, which NIST defines as no single user holding enough privilege to act alone (NIST IR 7316^[5]).

Pattern 5: covert channels / inference. A stem describing a low-level user deducing high-level data indirectly is testing the limits of level-based MAC and points to a noninterference model as the mitigation, not BLP or Biba (NIST IR 7316^[5]). Finally, beware the framing trap that the classic models govern availability: none of Bell-LaPadula, Biba, Clark-Wilson, or Brewer-Nash addresses the availability pillar.