D1 — Security Models Vocabulary: Bell-LaPadula, Biba, Clark-Wilson

Access control policies written in prose ("managers can see salary data, employees can't") are ambiguous and hard to verify mechanically. Formal security models exist to encode "who can read or write what" as a small set of provable rules a system's design can actually be checked against. This lesson gives you just enough of that vocabulary to reason about D1 and D5 policy questions; the deeper architectural treatment (state machines, trusted computing base, lattice-based models) comes later in this roadmap's Security Architecture batch.

Bell-LaPadula — protects confidentiality

Bell-LaPadula (BLP) was designed for military/government classification levels (Confidential, Secret, Top Secret) and enforces two rules:

• Simple Security Property ("no read up"): a subject cannot read data classified above their clearance. A Secret-cleared subject cannot read Top Secret data.
• *-property ("no write down"): a subject cannot write data down to a lower classification level. A Secret-cleared subject cannot copy Secret data into a Confidential-level file, because doing so would leak sensitive information into a less-protected level where subjects with lower clearance could then read it.

Both rules exist for the same goal: prevent unauthorized disclosure. Read-up would directly expose data above someone's clearance; write-down would indirectly do the same by relocating the data somewhere a less-cleared subject can read.

Biba — protects integrity, mirror image of BLP

Biba governs a different property with the opposite direction of restriction:

• Simple Integrity Property ("no read down"): a subject cannot read data from a lower integrity level — because that data is less trustworthy, and consuming it as if it were reliable would contaminate a higher-integrity process's judgment.
• *-integrity property ("no write up"): a subject cannot write to a higher integrity level — because doing so would let unverified, lower-integrity input corrupt data that downstream processes rely on as trustworthy.

The memory device worth internalizing: BLP blocks information from flowing down (protecting secrets from leaking to those who shouldn't see them), while Biba blocks information from flowing up (protecting trusted data from contamination by less-trusted input). They're mirror images specifically because they protect opposite properties — confidentiality cares about who can see something; integrity cares about what's allowed to influence something.

Clark-Wilson — integrity through process, not levels

Clark-Wilson also protects integrity, but takes a completely different approach: no classification levels at all. Two ideas do the work instead:

• Well-formed transactions: data can only be modified through a certified, constrained program — never directly by a user. This guarantees every change follows a defined, valid procedure rather than an arbitrary, unreviewed edit.
• Separation of duties: no single individual can both execute and certify/approve a critical transaction end-to-end. Splitting the transaction across roles means corrupting the data requires collusion, not just one person's mistake or malice.

This matters because access control alone doesn't guarantee integrity. A system can restrict who has write permission perfectly and still allow an authorized person to make an ill-formed, unreviewed, damaging change — which is exactly the scenario from Lesson 1's first task (the on-call engineer's direct database edit). Biba would prevent a lower-integrity subject from writing to a higher-integrity object; Clark-Wilson prevents any subject, regardless of level, from writing outside a certified transaction process.

The CISSP mindset: manager vs technician

A team asks how to better protect the integrity of a critical financial reporting dataset.

The technician answer: restrict write access to fewer people. Fewer people with write permission means fewer opportunities for a bad edit — technically true, and a reasonable first step.

The manager (CISSP) answer: recognize that restricting who can write is necessary but not sufficient. The real integrity guarantee comes from controlling how writes happen — enforcing that all modifications go through a well-formed, auditable transaction process, and that no single person can both make and approve a change to the dataset (separation of duties). A system with perfect access-control restrictions can still be corrupted by one authorized person's unreviewed mistake; a system with well-formed transactions and separation of duties is protected even if that person's account is compromised. This is the CISSP distinction between access control (who can act) and transaction integrity (how the action is structured) — and it's why D1 governance and this lesson's models both matter before D5's access control mechanics.