---
{
  "title": "Chinese Wall model",
  "summary": "Restrict access dynamically to manage conflicts of interest.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    },
    {
      "title": "Brewer and Nash: The Chinese Wall Security Policy (historical paper)",
      "url": "https://people.csail.mit.edu/alinush/6.858-fall-2014/papers/chinese-wall-sec-pol.pdf"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

The Chinese Wall, or Brewer–Nash, model prevents a subject from accessing information that creates a conflict after they have already accessed a competing dataset. Access depends on previous choices as well as current permissions. It is useful for reasoning about professional services handling multiple competing clients. Organizations still need a precise definition of conflict classes, trusted sanitization, and how access history is recorded.

## In practice

An analyst working with confidential information from one bank may be blocked from equivalent confidential information belonging to another bank in the same conflict class.

## A common misunderstanding

A static department role does not necessarily capture conflicts that arise from prior work.

## Check your understanding

What makes this access model dynamic?

**Think it through:** A decision may change after the subject accesses a dataset, because that access creates a conflict with another dataset.

## Previous access changes the next decision

A fictional consultancy serves two competing shipping companies and a separate museum. An analyst who accesses one shipping client's confidential dataset creates a conflict with the competing client's dataset under the policy. Access to the museum's unrelated dataset may remain permitted. The important state is the analyst's prior access within defined conflict classes.

This differs from a simple permanent role assignment. Two analysts with the same job title may have different permitted next accesses because their histories differ. The enforcement system therefore needs reliable identity and access-history information, not only a current department field.

The model also considers information flow through writes and the treatment of sanitized information. A practical design must define what can safely be shared and how that determination is trusted. Merely renaming a confidential report 'public summary' does not remove the conflict. Introductory read examples should not be mistaken for the complete formal policy.

## Build a history-sensitive access table

For a classroom exercise, create two shipping datasets and one museum dataset using fictional records. Give two analysts different first accesses and list which later reads each should be allowed. Explain why identical job roles do not produce identical decisions after those histories diverge.

Then discuss how service accounts, exports, and shared folders could bypass a history-aware policy if they are left outside enforcement. Keep the exercise conceptual rather than applying it to real client data. The useful lesson is that some access decisions depend on accumulated context and conflicts, not only static permissions. Implementing that lesson requires precise conflict definitions and coverage across the actual paths through which information moves.

## Keep exploring

- [[access-control]]
- [[rbac-and-abac]]
- [[separation-of-duties]]