Formal Security Models: Bell-LaPadula and Biba
Before "zero trust" and "least privilege" were slogans, they were theorems. In the 1970s, researchers tried to state access control with mathematical precision so that a system's security properties could be proven, not merely asserted. Two models from that era — Bell-LaPadula and Biba — still underpin how we reason about confidentiality and integrity, and they remain fixtures of the CISSP body of knowledge for good reason: they teach you to think in properties.
Bell-LaPadula: protecting confidentiality
Developed for the U.S. military, Bell-LaPadula (BLP) answers one question: how do you stop secret information from flowing to those not cleared to see it? It assigns security levels (Unclassified, Confidential, Secret, Top Secret) to both subjects (users) and objects (data), and enforces two famous rules:
- Simple Security Property — "no read up." A subject may not read an object at a higher level. A Confidential user cannot read Top Secret data. Obvious.
- Star (*) Property — "no write down." A subject may not write to an object at a lower level. This is the subtle, brilliant one: it stops a Top Secret user from copying secrets into a Confidential file where a lower-cleared user could read them — closing the leak that "no read up" alone misses.
Read down, write up. BLP is about confidentiality only — it says nothing about whether data is correct.
Biba: protecting integrity
Biba is BLP turned upside down. Where BLP guards secrets, Biba guards trustworthiness — it keeps low-integrity (untrusted) data from corrupting high-integrity systems. Its rules invert BLP's:
- Simple Integrity Property — "no read down." A high-integrity subject may not read low-integrity data, lest bad input taint good process.
- Star Integrity Property — "no write up." A low-integrity subject may not write to a high-integrity object — untrusted sources can't modify trusted data.
Read up, write down. You already live inside a Biba-like model: your operating system won't let an unprivileged app overwrite system binaries — low integrity cannot write up to high.
Why they conflict, and what that teaches
| Bell-LaPadula | Biba | |
|---|---|---|
| Protects | Confidentiality | Integrity |
| Read | No read up | No read down |
| Write | No write down | No write up |
They pull in opposite directions — you cannot naively enforce both with one lattice, which is precisely the lesson: confidentiality and integrity are distinct goals requiring distinct controls. Real systems apply each where it belongs, or reach for richer models.
Known limitations
BLP is famously static — it doesn't address how classifications change, and the "tranquility principle" was bolted on to handle relabeling. Neither model addresses availability (the third leg of the CIA triad), covert channels, or the messy realities of modern dynamic systems. Later models answered specific gaps: Clark-Wilson for commercial integrity through well-formed transactions and separation of duties; Brewer-Nash (the Chinese Wall) for conflict-of-interest access that changes based on what you've already seen.
Why bother in 2026
You will not configure a Bell-LaPadula lattice this quarter. But you will design access control, and these models give you the vocabulary and the discipline: separate confidentiality from integrity, think in provable properties rather than ad-hoc rules, and notice that "no write down" and "no write up" are the ancestors of the mandatory access controls (SELinux, AppArmor) and multi-level security running quietly in the systems you use today.
Bell-LaPadula keeps secrets from leaking down; Biba keeps corruption from creeping up. They contradict each other on purpose — teaching the enduring lesson that confidentiality and integrity are different problems.