# Brewer-Nash

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/brewer-nash

## Quick definition

The Brewer-Nash model is a security rule that stops people from seeing information that could cause a conflict of interest. For example, a consultant working for two competing companies is not allowed to see both companies' secret files at the same time. The model automatically blocks access to the second company's data if the consultant already accessed the first company's data. It helps protect sensitive business information in environments like consulting firms and law offices.

## Simple meaning

Imagine you work at a consulting firm that advises two rival coffee shops, Brew A and Brew B. Each coffee shop shares its secret recipes and business plans with your firm but expects that information to stay confidential. Now, if you are assigned to help Brew A, you are trusted with their secret information. But if you later try to look at Brew B’s files while still working on Brew A’s project, that would create a conflict of interest because you could accidentally use one client’s secrets to help the other.

The Brewer-Nash model is a set of rules programmed into a computer system that automatically prevents this situation from happening. The system keeps track of which clients you have already accessed. Once you have accessed data from one client in a competitive set, the system blocks you from accessing data from any other client in the same set. This is often called the “Chinese Wall” model because, like a wall inside a company, it separates information that should not mix.

In a real computer system, this works through access labels. Each file or piece of data is tagged with the name of the client it belongs to and the category it falls into, such as “coffee company.” When a user tries to open a file, the system checks whether that user has already accessed a file from a different client in the same category. If the answer is yes, access is denied. This prevents the user from seeing both sides of a competitive relationship, even if the user has permission from each client separately. The model is very useful in industries where trust and confidentiality are paramount, such as law, finance, and consulting.

## Technical definition

The Brewer-Nash model, also known as the Chinese Wall security policy, is a formal access control model designed to prevent conflicts of interest in commercial environments. It was first proposed by David Brewer and Michael Nash in 1989. The model operates on three key data objects: objects (data items), company datasets (sets of objects belonging to the same company), and conflict-of-interest classes (sets of company datasets that are in direct competition). Users are not allowed to read objects from two different company datasets that belong to the same conflict-of-interest class after having accessed one of them.

The model enforces a dynamic access control policy. Initially, a user has no access history. Once the user reads an object from a company dataset, that company dataset becomes part of the user’s “sanitized” or “unsanitized” access set. The key rule is that a user can only read an object from a company dataset if the user has not previously read any object from a different company dataset within the same conflict-of-interest class. This is a “write” rule as well: a user can write to an object only if the user can read that object and if the object belongs to the same company dataset that the user already has access to. This prevents information leakage from one competing company to another through the user.

In practice, the model is implemented in security labels and access control lists within operating systems or database management systems. The system maintains a history of each user’s access events. When a user requests access to a new object, the system checks the object’s company dataset and conflict-of-interest class against the user’s access history. If the user has not accessed any object from a competing company dataset, access is granted. Otherwise, access is denied unless the object is “sanitized” data that has been approved for public release. This model is particularly effective in environments such as financial advisory firms, law firms, and consultancies where client confidentiality is legally mandated. It is also referenced in the CISSP Common Body of Knowledge as a key example of a commercial security model, contrasting with military models like Bell-LaPadula.

## Real-life example

Think about a hospital that treats two competing sports teams, the Eagles and the Falcons. Each team has its own doctors, medical records, and treatment plans. A doctor who works with both teams is trusted to see each team’s information separately but must never mix them. If the doctor reads the Eagles’ medical reports on Monday, then tries to look at the Falcons’ records on Tuesday, that could be a problem. The doctor might unintentionally share strategy about how the Eagles treat injuries, giving the Falcons an advantage.

To prevent this, the hospital uses the Brewer-Nash model on its computer system. Every patient record is labeled with the team it belongs to and with a conflict-of-interest class, such as “professional sports team.” When the doctor logs in and accesses the Eagles’ records for the first time, the system records that choice. Later, when the doctor tries to open the Falcons’ records, the system checks the conflict-of-interest class. Since the Eagles and the Falcons belong to the same class, the system blocks access. The doctor would have to formally request a change in assignment or get special permission to see both sets of records, ensuring that no conflict of interest arises accidentally.

This is exactly how the model works in IT. The system acts like a gatekeeper that remembers your history and enforces separation. It does not rely on the user’s judgment alone. Instead, it hard-codes the rule that you cannot see competitive information after you have seen one side. This protects the organization from legal liability and maintains client trust.

## Why it matters

In the real world of IT, especially in consulting, law, and finance, companies handle sensitive data for multiple clients who are often direct competitors. Without a model like Brewer-Nash, an employee could inadvertently access and combine confidential information from two rivals, leading to legal action, loss of contracts, and severe reputation damage. The model provides an automated, enforceable way to prevent this conflict of interest at the system level, reducing the burden on human judgment and policy.

For IT professionals, understanding Brewer-Nash is crucial because many enterprise systems, such as those used by accounting firms or legal practices, implement this model as part of their access control framework. If you are responsible for designing or auditing security systems, you need to know how to configure labels and conflict sets correctly. A misconfiguration could allow data leakage, while a correctly implemented model ensures compliance with industry regulations and ethical standards.

the Brewer-Nash model is often discussed in security certifications to illustrate that access control is not just about classifying data by secrecy (like military models) but also about managing commercial ethics. It shows that security policies must adapt to business needs. Learning this model helps you think beyond simple permissions and consider the dynamic nature of trust and interest. It also prepares you to answer exam questions about which model is best suited for a given business scenario, especially when the scenario involves multiple competing clients.

## Why it matters in exams

The Brewer-Nash model appears primarily in the CISSP (Certified Information Systems Security Professional) exam, specifically in the Security Architecture and Engineering domain. It is one of the foundational commercial security models that candidates are expected to recognize and compare against other models like Bell-LaPadula, Biba, and Clark-Wilson. The exam objective typically asks you to identify the model that prevents conflicts of interest, uses a “Chinese Wall” analogy, or is best suited for consulting and law firms.

In the CISSP exam, you might see questions that present a scenario: “A consulting firm needs an access control model to ensure that consultants working for competing clients cannot access each other’s data. Which model should be implemented?” The correct answer is Brewer-Nash. You may also be asked about its key rules, such as the prohibition on reading objects from two competing company datasets within the same conflict-of-interest class.

Beyond CISSP, Brewer-Nash may also appear in other security certifications like CompTIA Security+ or SANS GIAC, but typically as a lighter supporting concept. In those exams, you might only need to know the basic idea: it is a commercial model for avoiding conflicts of interest. However, in the CISSP, you should be prepared for more detailed questions about how the model works, what its components are (objects, company datasets, conflict-of-interest classes), and how it differs from Bell-LaPadula and Biba.

Exam questions can be tricky. For instance, they might mislead you by describing a scenario where a user needs to read data from two different companies within the same conflict-of-interest class, but one of those data objects is “sanitized” or public. In that case, the model allows access. Also, be aware that Brewer-Nash does not address data integrity like Biba does, nor does it enforce secrecy levels like Bell-LaPadula. Its sole focus is conflict of interest. Mastering these nuances will help you choose the correct answer in exam questions.

## How it appears in exam questions

In the CISSP exam, Brewer-Nash questions often present a business scenario and ask you to pick the right access control model. A common pattern is: “A law firm wants to prevent attorneys from accessing case files of two rival clients. Which security model should be applied?” The correct answer is Brewer-Nash. Another variation asks about the “Chinese Wall” model, which is the same concept.

You may also see questions that test your understanding of the model’s components. For example: “In the Brewer-Nash model, what is a ‘company dataset’?” The answer is a set of objects that belong to the same company. Another question might ask: “What happens when a user requests access to an object from a company dataset that is in the same conflict-of-interest class as a dataset already accessed?” The answer is that access is denied unless the object is sanitized.

Configuration and troubleshooting questions are less common but possible. For instance: “A user in a consulting firm can see data from Client A but cannot access data from Client B, even though both are in different conflict-of-interest classes. What could be wrong?” The answer might be that the conflict-of-interest classes were incorrectly defined, or that the user’s access history was not reset after a change in assignment.

the exam may ask you to compare Brewer-Nash with other models. For example: “Which model is best for preventing information leakage in a commercial environment with competing clients?” The answer is Brewer-Nash. Or: “Which model focuses on conflict of interest rather than data classification?” Again, Brewer-Nash. You should also be ready for questions that mix concepts, such as: “A military system needs to prevent users from reading higher classified data. Which model is used?” That would be Bell-LaPadula, and the contrast helps the exam evaluate your ability to differentiate models.

## Example scenario

You work as an IT security analyst for a large financial advisory firm that manages investments for two competing oil companies, PetroMax and OilWell. Each company has a set of financial reports, strategies, and merger plans stored in the firm’s secure database. The firm has a strict policy that no employee should have access to both companies’ sensitive data at the same time.

One day, an employee named Sarah logs into the system to review PetroMax’s quarterly earnings. The system records this access in her history. Later, Sarah receives a request from her manager to also look at OilWell’s upcoming investment plans for comparison. She attempts to open the OilWell folder, but the system immediately denies her access. The system displays a message: “Access denied – conflict of interest detected.” Sarah is confused because she has legitimate business reasons for both accesses.

The system is using the Brewer-Nash model. It has labeled PetroMax’s files under company dataset “PetroMax” and OilWell’s files under company dataset “OilWell.” Both datasets belong to the same conflict-of-interest class called “oil_companies.” Because Sarah already accessed PetroMax, the model considers that she has taken a “side” in that conflict class. Allowing her to access OilWell would create a conflict of interest. The model blocks the request automatically, protecting the firm from potential legal liability.

To resolve the situation, Sarah must submit a formal request to the security officer to change her assignment so that she no longer works on PetroMax. Once her access history is reset or her role is changed, she can then access OilWell. This illustrates how the model enforces ethical boundaries through automated access control, not just through policy.

## Common mistakes

- **Mistake:** Thinking Brewer-Nash and Bell-LaPadula are the same model.
  - Why it is wrong: Bell-LaPadula is a military model focused on preventing information flow from high to low security levels, while Brewer-Nash is a commercial model focused on preventing conflicts of interest.
  - Fix: Remember: Bell-LaPadula is about secrecy levels (no read up, no write down). Brewer-Nash is about competing companies (Chinese Wall).
- **Mistake:** Assuming Brewer-Nash only uses static labels like “secret” or “top secret.”
  - Why it is wrong: Brewer-Nash uses company datasets and conflict-of-interest classes, not hierarchical security labels. It is dynamic because it depends on a user’s access history.
  - Fix: Understand that Brewer-Nash labels are based on ownership and competition, not classification levels.
- **Mistake:** Believing that a user who accessed one company can never access another company’s data again.
  - Why it is wrong: The restriction only applies to companies within the same conflict-of-interest class. A user can freely access companies from different classes. Also, sanitized data is exempt from the rule.
  - Fix: Remember the model only blocks access within the same conflict-of-interest class, not across all companies.
- **Mistake:** Confusing the write rule with the Biba model’s integrity rule.
  - Why it is wrong: In Brewer-Nash, the write rule prevents writing to objects outside the user’s current company dataset to avoid leaking information. Biba’s write rule is about preventing contamination of high-integrity data with low-integrity data.
  - Fix: Focus on the purpose: Brewer-Nash write rule is about conflict-of-interest, not data integrity.
- **Mistake:** Thinking that Brewer-Nash is only relevant for government systems.
  - Why it is wrong: Brewer-Nash was specifically designed for commercial environments like consulting firms, law offices, and financial institutions. It is less relevant for government classified systems.
  - Fix: Associate Brewer-Nash with businesses handling multiple competing clients.

## Exam trap

{"trap":"A question describes a scenario where a user has already accessed data from two companies in the same conflict-of-interest class, but the data was sanitized. The exam asks whether the model would allow the user to read a third company’s data from the same class.","why_learners_choose_it":"Many learners think that once a user has taken a “side” by accessing one company, they are permanently barred from all others in that class. They panic and think the model would block all future access, even to sanitized data.","how_to_avoid_it":"Remember that the Brewer-Nash model has an exception for sanitized data. Sanitized data has been reviewed and approved for public or broad release, so it no longer poses a conflict-of-interest risk. Access to sanitized data is allowed regardless of prior access history. Always look for the word “sanitized” in the question – it changes the answer."}

## Commonly confused with

- **Brewer-Nash vs Bell-LaPadula:** Bell-LaPadula is a military model focused on preventing unauthorized disclosure of classified information by controlling read and write operations based on security levels (no read up, no write down). Brewer-Nash is a commercial model that prevents conflicts of interest by restricting access to data from competing companies based on user access history. (Example: Bell-LaPadula would stop a secret-cleared user from reading top-secret files. Brewer-Nash would stop a consultant from reading files of two rival clients.)
- **Brewer-Nash vs Biba:** The Biba model protects data integrity by preventing unauthorized modification of data (no write up, no read down). Brewer-Nash is not concerned with integrity; it is concerned with conflicts of interest. Biba would block a low-integrity user from writing to a high-integrity file, while Brewer-Nash would block a user from reading data of two competing companies. (Example: Biba stops a junior analyst from accidentally corrupting a senior analyst’s report. Brewer-Nash stops a lawyer from seeing files of two opposing clients.)
- **Brewer-Nash vs Clark-Wilson:** Clark-Wilson is an integrity model that uses well-formed transactions and separation of duties to ensure data integrity and prevent fraud. Brewer-Nash is about conflict-of-interest through access control. Clark-Wilson focuses on how data can be changed, while Brewer-Nash focuses on who can see what. (Example: Clark-Wilson would require two people to approve a financial transaction. Brewer-Nash would stop an auditor from viewing two competing firms’ accounts.)
- **Brewer-Nash vs Chinese Wall:** Chinese Wall is just another name for the Brewer-Nash model. There is no difference – they are the same concept. Some sources use the term “Chinese Wall” to describe the policy, and “Brewer-Nash” to describe the formal model. (Example: Both refer to the same rule: you cannot access information from two competitors once you have seen one side.)

## Step-by-step breakdown

1. **Identify the objects and their ownership** — Each data object in the system is tagged with the company it belongs to, forming a company dataset. For example, a file called “report_Q1.pdf” is tagged as belonging to “Acme Corp.” This step is crucial because the model uses ownership to determine conflicts.
2. **Define conflict-of-interest classes** — Companies that compete with each other are grouped into the same conflict-of-interest class. For instance, “Acme Corp.” and “Beta Inc.” might both be in the “Pharmaceutical” class. This defines which datasets cannot be mixed.
3. **User makes an initial access request** — When a user first requests to read an object, the system checks the access history. If the user has no prior access to any company in the conflict-of-interest class, access is granted. The user’s history is then updated to include that company dataset.
4. **Subsequent access is checked against history** — When the user tries to access a second object, the system compares the object’s company dataset with the user’s history. If the new object belongs to a different company but the same conflict-of-interest class, access is denied. This is the core enforcement step.
5. **Write access is restricted** — If the user is allowed to read an object, they may also write to it, but only if the object belongs to the same company dataset they have already accessed. This prevents the user from accidentally or maliciously writing data from one company into another company’s files, which would cause information leakage.
6. **Handling sanitized data** — Some objects can be labeled as “sanitized,” meaning they have been reviewed and approved for wider access. The model allows users to read sanitized data even if it belongs to a conflict-of-interest class they have already accessed. This exception is important for public reports or aggregated summaries.

## Practical mini-lesson

To implement the Brewer-Nash model in a real IT environment, you need to begin by identifying the business entities that create conflicts of interest. This is typically done in consultation with legal or compliance teams. You then label every data object with its owning entity and its conflict-of-interest class. For example, in a document management system, you might create metadata fields such as “OwnedBy” and “ConflictClass.” Access control rules are then written to enforce the model. These rules are often implemented as part of a Role-Based Access Control (RBAC) system or a custom access control list, but with dynamic state tracking.

A common approach is to use an attribute-based access control (ABAC) system where the policy engine checks the user’s access history at runtime. The system must maintain an audit trail of which company datasets each user has accessed. This history may be stored in a database and cleared only when the user’s assignment changes via an authorized workflow. For example, if a consultant moves to a new project that does not conflict, an administrator would reset that user’s access history for the relevant conflict class.

What can go wrong? Mislabeling is a frequent problem. If a file is accidentally assigned to the wrong company dataset, or if two companies that actually compete are not placed in the same conflict-of-interest class, the model will fail to block inappropriate access. For example, if a law firm fails to label a client’s case files correctly, an attorney might be able to access opposing counsel’s data without restriction. Another issue is performance: tracking every user’s access history for every object can slow down the system if not designed properly. Caching and efficient database queries are necessary.

Finally, professionals need to understand that the model does not replace other security measures. It should be used alongside authentication, encryption, and audit logging. The Brewer-Nash model handles a specific business requirement: conflict-of-interest. It does not address malware, unauthorized changes, or denial of service. Therefore, a comprehensive security architecture will include Brewer-Nash as one layer among many.

## Memory tip

Remember “Brewer-Nash = Chinese Wall = Conflict of Interest.” Think of a wall that separates two competing clients in a consulting firm. The model stops you from being on both sides of the wall at the same time.

## FAQ

**Is Brewer-Nash the same as the Chinese Wall model?**

Yes, they are the same. The Chinese Wall is the common name for the security policy, and Brewer-Nash is the formal model that defines it.

**Can Brewer-Nash be used in government systems?**

It is primarily designed for commercial systems, but it can be used in any environment where conflict-of-interest is a concern, including government agencies that process competing contractors’ information.

**Does Brewer-Nash allow reading sanitized data from a competing company?**

Yes. Sanitized data has been reviewed and approved for broader release, so it does not pose a conflict-of-interest risk and can be read even if the user has accessed another company in the same conflict class.

**What is the difference between a company dataset and a conflict-of-interest class?**

A company dataset is a collection of data objects owned by a single company. A conflict-of-interest class is a set of company datasets that are in competition. A single class can contain multiple datasets.

**How does Brewer-Nash handle write operations?**

A user can write to an object only if they can read it and if the object belongs to the same company dataset they have already accessed. This prevents leaking information from one company’s dataset into another’s.

**What happens if a user needs to access two competing companies’ data for a legitimate reason?**

The Brewer-Nash model does not allow it unless the user’s assignment changes or special authorization is given. Typically, the user would need to be reassigned or the data must be sanitized first.

## Summary

The Brewer-Nash model, also known as the Chinese Wall model, is a commercial security model that prevents conflicts of interest by dynamically controlling access based on a user’s past access history. It groups data into company datasets and conflict-of-interest classes, and it ensures that once a user accesses data from one company, they cannot access data from a competing company in the same class. The model also restricts write operations to prevent information leakage. This model is essential in industries like consulting, law, and finance where client confidentiality and ethical separation are critical.

For IT professionals and certification candidates, understanding Brewer-Nash is not just about memorizing a definition. It is about knowing when to apply it and how it differs from other models like Bell-LaPadula and Biba. In the CISSP exam, you will encounter scenario-based questions that require you to identify the correct model for a given business situation. You must also understand the nuances, such as the exception for sanitized data and the dynamic nature of the access decision.

The key takeaway for exams is to associate Brewer-Nash with conflict-of-interest and the Chinese Wall analogy. Avoid confusing it with secrecy or integrity models. Remember that it is dynamic, based on user history, and that it operates within defined conflict-of-interest classes. Mastering these points will help you answer questions correctly and apply the model in real-world security architecture.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/brewer-nash