What is the Bell-LaPadula model?

A confidentiality-focused access control model from 1973, built for US military systems. Its two rules are 'no read up' (a subject cannot read data classified above their own clearance) and 'no write down' (a subject cannot write data to a lower classification level). It stops information flowing from high classification to low, but says nothing about data integrity.

What is the Biba model?

An integrity-focused model published in 1977, essentially Bell-LaPadula inverted. Its rules are 'no write up' (a subject cannot write to data at a higher integrity level) and 'no read down' (a subject cannot read data from a lower integrity level). It stops low-integrity, unverified data from contaminating high-integrity data.

What is the Clark-Wilson model?

A 1987 commercial integrity model built for business systems rather than military ones. Instead of classification levels, it requires that data (constrained data items) can only be changed through approved programs (transformation procedures), and that duties are split across roles so no single person can both create and approve a change. It formalises the idea of a well-formed transaction and separation of duties.

What is the Brewer-Nash model?

Also called the Chinese Wall model, published in 1989 for environments like consultancies, law firms, and investment banks. Access is not fixed by classification but changes dynamically based on what a person has already accessed: once someone has worked on Client A, the model blocks them from accessing a competing Client B's data, to prevent conflicts of interest.

Are these models actually implemented in real systems today?

Rarely in their original, literal form. Bell-LaPadula survives in government multi-level secure systems. The other three exist mainly as design principles rather than named implementations: role-based access control borrows from Clark-Wilson's separation of duties, data loss prevention tools borrow from Biba's integrity logic, and ethical walls in legal and financial case management software are direct descendants of Brewer-Nash.

How do these models relate to ISO 27001?

ISO 27001 does not name any of these models directly, but Annex A controls A.5.15 (access control), A.5.18 (access rights), A.8.2 (privileged access rights), and A.5.3 (segregation of duties) all encode the same underlying logic: restrict access by need, prevent unauthorised information flow, and separate conflicting duties. Understanding the models makes it easier to design controls that satisfy the standard's intent rather than just its wording.

Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash: the access control models behind your ISO 27001 controls

Most access control policies are written from first principles, or copied from the last audit that passed. Few people writing them know that the logic goes back to four formal models built between 1973 and 1989, each solving a different failure mode: leaking secrets, corrupting data, letting one person both make and approve a fraudulent change, or handing a consultant a conflict of interest they can’t see. Bell-LaPadula, Biba, Clark-Wilson, and Brewer-Nash. None of them are named in ISO 27001, but the logic behind half of Annex A’s access control clauses comes straight from them.

This piece sets out what each model actually says, why it was built, where it breaks down, and where its fingerprints show up in the access control you already run.

Key takeaways

Bell-LaPadula (1973) protects confidentiality: no reading above your clearance, no writing below it. It says nothing about integrity, and a system built purely on it can still be fed corrupted data from the top down.
Biba (1977) is Bell-LaPadula’s mirror image, protecting integrity instead of confidentiality: no writing up, no reading down. Run both models on the same system and they pull access rights in opposite directions.
Clark-Wilson (1987) drops classification levels altogether and protects integrity through process: changes only happen via approved procedures, and no one person can both create and authorise a change. This is the model closest to what most commercial organisations actually need.
Brewer-Nash (1989), the Chinese Wall model, is the only one of the four built for the exact situation a consultancy, law firm, or bank faces daily: preventing conflicts of interest between clients, with access rules that change based on what a person has already seen.
None of the four is deployed literally in most modern systems. Their value now is as a vocabulary for describing what an access control decision is actually trying to achieve, which is useful when you’re writing or auditing an ISO 27001 access control policy.

Bell-LaPadula: keeping secrets from flowing down

Bell-LaPadula came out of work for the US Department of Defense in the early 1970s, built to answer a specific question: can a computer be trusted to enforce military classification levels (unclassified, confidential, secret, top secret) the way a paper filing system does. Its answer is two rules.

The simple security property (“no read up”) stops a subject from reading data classified above their clearance. The *-property, usually read as the “star property” (“no write down”), stops a subject from writing data to a level below their own. A general with top secret clearance can read a confidential file, but cannot copy its contents into a document available to someone with lower clearance, even by accident.

The model is a genuine achievement: it made it possible to prove, mathematically, that a system enforcing these two rules cannot leak classified information to an unauthorised level. Multi-level secure systems built on it are still in government and defence use.

Its limitation is equally well known. Bell-LaPadula controls confidentiality and has nothing to say about integrity. A high-clearance user can write garbage or falsified data into a low-clearance file (writing down is fine, since it only risks disclosure, not corruption of the higher level) and, more troublingly, a system enforcing only Bell-LaPadula has no mechanism to stop bad data flowing from a high level down into decisions made at a lower one. Confidentiality and integrity turned out to need separate models, which is exactly what Biba supplied four years later.

Biba: keeping corruption from flowing up

Biba takes Bell-LaPadula’s structure and flips it for integrity instead of confidentiality. Instead of classification levels, subjects and objects sit at integrity levels, and the rules invert: the simple integrity axiom (“no write up”) stops a subject from writing to data at a higher integrity level than their own, and the *-integrity axiom (“no read down”) stops a subject from reading data at a lower integrity level.

The logic: if you let low-integrity, unverified input flow into a high-integrity process, you’ve contaminated it, so both directions need blocking. A process trusted to configure production infrastructure shouldn’t take unvalidated input from a low-trust source (no reading down), and a low-trust process shouldn’t be able to modify a high-trust one (no writing up).

Run Bell-LaPadula and Biba on the same system and the access rules point in opposite directions: one blocks reading up and writing down, the other blocks writing up and reading down. That’s not a flaw in either model, it’s the reason real systems need to decide which risk (disclosure or corruption) matters more for a given piece of data, rather than assuming one model covers both. Biba’s principle survives today mostly in code-signing, patch validation, and data loss prevention logic: don’t let unverified input touch a trusted process without a check in between.

Clark-Wilson: integrity through process, not classification

Clark-Wilson, published in 1987, was built for commercial systems, banks, insurers, ordinary businesses, that had no use for military classification levels but cared enormously about integrity: an accounting ledger, an inventory count, a set of financial records.

Instead of levels, it works through two ideas. Constrained data items are the data that must stay accurate (account balances, stock records), and they can only be changed by transformation procedures, approved programs that enforce validation rules rather than letting anyone edit the data directly. Integrity verification procedures periodically check that constrained data items are still in a valid state.

The second idea is the one that shows up everywhere in real audits: separation of duties. Clark-Wilson requires that the person who executes a transaction cannot also be the person who approves it. One person raises a purchase order, a different person authorises the payment. This is what stops an employee from both creating a fraudulent invoice and approving it for payment, and it’s the direct ancestor of the segregation of duties control you’ll find in almost every financial controls framework and in ISO 27001’s Annex A.5.3.

Of the four models, Clark-Wilson maps most directly onto what commercial organisations actually build: role-based access, approval workflows, and audit trails that record who did what, all in service of trustworthy data rather than secrecy.

Brewer-Nash: walls that move with you

Brewer-Nash, published in 1989 and better known as the Chinese Wall model, is the one built for a situation Axlio and firms like it live in daily. It was designed for financial and professional services organisations advising multiple clients who may be direct competitors, where a consultant who has seen one client’s confidential strategy cannot be allowed anywhere near a competitor’s.

What makes Brewer-Nash different from the other three is that access isn’t fixed in advance. It’s dynamic, based on your own access history. Before you’ve touched anything in a conflict-of-interest class (say, retail banking clients), you can access any file in it. The moment you access one client’s data in that class, the wall goes up: you’re now blocked from every competing client in the same class, for as long as the engagement runs. Someone else on your team, who hasn’t touched that class yet, can still be assigned to the competitor.

This is the model behind “ethical walls” in legal case management systems, “deal walls” in investment banking, and conflict-check tooling in consultancies. It’s also the model most directly relevant to a firm’s own operational risk, since a Chinese Wall breach isn’t a technical vulnerability, it’s a business-ending conflict of interest if it reaches a client or a regulator.

The same logic shows up in auditor independence requirements: an advisor who has worked on a system cannot then audit it, for exactly the reason Brewer-Nash exists, prior access creates a conflict a later access decision has to account for. We’ve covered how that plays out for internal audit under clause 9.2.

Where these show up in ISO 27001

None of the four models is named in ISO 27001. What the standard does is require the outcomes they were built to produce, through Annex A controls that read like plain-English versions of the same logic.

A.5.15 (access control) and A.5.18 (access rights) require access to be granted by business need and reviewed regularly, which is Bell-LaPadula’s clearance logic without the military framing. A.8.2 (privileged access rights) requires tighter control over accounts that can change high-value systems, which is Biba’s integrity logic applied to admin access. A.5.3 (segregation of duties) is Clark-Wilson, almost unchanged: no one person should be able to both execute and approve a critical transaction. And any consultancy, law firm, or advisory business managing competing clients under A.5.19 (supplier relationships) or its own confidentiality obligations is running a Brewer-Nash problem, whether or not anyone on the team has heard the name.

None of this means an auditor will ask you to name the model behind a control. It means that when a control seems arbitrary, “why can’t the same person raise and approve a payment,” “why is this data read-only for that role,” the answer usually traces back to one of these four ideas, and knowing which one is often the fastest way to design a control that actually holds up rather than one that just satisfies the checklist.

Practical questions to ask

Does any single role in your organisation both create and approve high-value transactions, payments, user access grants, code deployments, without a second person in the loop?
Do privileged accounts that can modify production systems or financial records take input from lower-trust sources without validation in between?
If your organisation advises multiple clients in the same sector, is there a documented process for identifying and walling off conflicts of interest, or does it rely on individual judgement?
When your access control policy grants or restricts a permission, could you explain in one sentence which risk it’s managing: disclosure, corruption, fraud, or conflict of interest?

Closing

These four models are decades old and none of them are implemented literally in most systems built today. What they left behind is more useful than the models themselves: a vocabulary for naming exactly what an access control decision is protecting against, so that “least privilege” stops being a slogan and becomes a specific, defensible answer to a specific risk.

If you’d like help reviewing your access control policy, segregation of duties, or conflict-of-interest procedures against ISO 27001 Annex A, get in touch. Our ISO 27001 and Risk & Governance services both cover this ground.