Security models describe rules a system can use to protect information or enforce a security property. Design principles guide how a trustworthy system should be structured and operated.
Do not memorize a model name without its purpose. First ask whether the scenario is mainly protecting confidentiality, integrity, conflicts of interest, controlled transactions, or a broader system property.
Start with the security goal
| Main concern | Likely model or principle |
|---|---|
| Prevent information from moving to a lower classification | Bell-LaPadula |
| Prevent untrusted information from corrupting higher-integrity data | Biba |
| Protect business records through approved transactions and separated roles | Clark-Wilson |
| Prevent a consultant from accessing competing clients' confidential information | Brewer-Nash |
| Require every access request to be checked by a small trusted mechanism | Reference monitor and complete mediation |
| Remove implicit trust based on location | Zero trust |
Confidentiality models
Bell-LaPadula
The Bell-LaPadula model protects confidentiality by controlling how information moves among classification levels.
- No read up: A subject cannot read information above the subject's clearance.
- No write down: A subject cannot write information to a lower classification.
The model is concerned with preventing unauthorized disclosure. It does not primarily protect the correctness of data.
Memory clue: Bell-LaPadula protects secrets. Information should not flow down to a less trusted level.
Lattice-based access control
A lattice model uses ordered security labels and rules for comparing them. Access can depend on classification, compartments, categories, or other attributes represented in the labels.
Bell-LaPadula can be implemented with a lattice, but lattice-based access control is the broader method of ordering and comparing labels.
Integrity models
Biba
The Biba model protects integrity by limiting how information from lower-integrity sources can influence higher-integrity subjects and data.
In the strict form:
- No read down: A higher-integrity subject does not read lower-integrity information.
- No write up: A lower-integrity subject does not write to higher-integrity data.
Memory clue: Biba protects correctness. Untrusted information should not flow up into trusted data.
Clark-Wilson
The Clark-Wilson model protects business-data integrity through approved transactions, separated duties, and verification.
Important ideas include:
- Constrained data items: Protected data that must be changed only through approved methods
- Transformation procedures: Approved programs or transactions that change protected data
- Integrity verification procedures: Checks that confirm protected data remains valid
- Separation of Duties: Different people or roles perform and approve sensitive steps
- Well-formed transactions: Data changes occur through controlled and valid operations
Clark-Wilson fits accounting, payment, inventory, and other business systems where correctness depends on authorized procedures and accountability.
Other security models
Brewer-Nash
The Brewer-Nash model, also called the Chinese Wall model, changes access according to a user's prior activity. It prevents conflicts of interest by blocking access to confidential information from competing organizations after the user has entered one side of the conflict.
The access rule is dynamic. What a person may access later depends on what the person accessed earlier.
State-machine model
A state-machine model describes a system as a set of states and allowed transitions. The system is secure when it begins in a secure state and every permitted transition leads to another secure state.
This model is useful for reasoning about whether a design can enter an unsafe condition through a sequence of allowed actions.
Information-flow model
An information-flow model controls where information may move. It can address confidentiality, integrity, or both by restricting flows among subjects, objects, labels, processes, or domains.
Noninterference model
A noninterference model aims to prevent activity in one security domain from revealing or changing information in another domain in an unauthorized way. A lower-level observer should not be able to learn about higher-level actions through visible system behavior.
Secure design principles
| Principle | Plain meaning | Example |
|---|---|---|
| Least privilege | Give only the access needed for the task and only for as long as needed. | Temporary administrative access for one approved change. |
| Separation of Duties | Divide sensitive work so one person cannot complete the entire high-impact process alone. | One person requests a payment and another approves it. |
| Defense in depth | Use several safeguards so one failure does not expose the asset by itself. | Identity controls, segmentation, endpoint protection, logging, and backups. |
| Fail securely | When a component fails, the default result should deny unsafe access or preserve protection. | An authorization service failure does not silently grant access. |
| Complete mediation | Check every access request instead of assuming earlier approval remains valid. | Reevaluate authorization when a session requests a protected action. |
| Economy of mechanism | Keep trusted security mechanisms as small and simple as practical. | A narrow authorization component is easier to review than many scattered checks. |
| Open design | Security should depend on protected keys and credentials, not on hiding how the design works. | A published cryptographic design remains secure because the key is protected. |
| Least common mechanism | Reduce shared components and resources that create unintended paths between users or domains. | Separate tenant data and administrative paths. |
| Psychological acceptability | Make secure behavior understandable and practical enough that people can follow it correctly. | Clear authentication prompts and recovery steps that do not encourage workarounds. |
Reference monitor and trusted components
A reference monitor is the concept of a mechanism that checks access between subjects and objects. It should be:
- Always invoked: Every relevant access request is checked.
- Tamper resistant: Untrusted users and processes cannot change or bypass it.
- Small enough to evaluate: Its design and implementation can be analyzed and tested.
The security kernel is the part of a system that implements the reference-monitor concept. The Trusted Computing Base (TCB) is the collection of hardware, software, firmware, and controls that must work correctly for the system's security policy to hold.
A smaller TCB is usually easier to understand, protect, test, and maintain.
Zero trust is an architecture principle, not one product
Zero trust means the system does not grant implicit trust because a user or device is inside a network, owned by the organization, or previously authenticated.
A zero-trust design commonly emphasizes:
- Explicit identity and device checks
- Least-privilege access
- Resource-specific policy
- Repeated evaluation of context and session conditions
- Segmentation and reduced trust zones
- Monitoring, logging, and rapid revocation
Zero trust does not mean trusting nobody in every business sense. It means access decisions should be based on verified identity, device, policy, and context rather than location alone.
Scenario comparisons
A classified document must not be copied to a lower classification
Bell-LaPadula fits because the problem is unauthorized disclosure through downward information flow.
A low-integrity data feed must not update trusted financial records directly
Biba fits the integrity concern. Clark-Wilson may also fit when updates must occur through approved transactions and separated roles.
A consulting employee accesses one bank's confidential records
Brewer-Nash can block later access to a competing bank's confidential information because the conflict depends on prior access.
A system checks authorization only when the user first signs in
Complete mediation is missing. Sensitive actions should be checked when the access occurs, not assumed safe forever because of an earlier login.
A control failure causes the system to grant access
The design does not fail securely. A failure should preserve protection or deny the unsafe operation.
Common exam traps
- Choosing Bell-LaPadula for an integrity problem.
- Reversing Biba's strict read and write rules.
- Treating Clark-Wilson as a classification model instead of a transaction and integrity model.
- Treating Brewer-Nash as static role-based access.
- Assuming defense in depth means duplicating the same control without considering different failure modes.
- Calling a hidden design secure because attackers do not know how it works.
- Treating zero trust as a single firewall, VPN, or identity product.
- Forgetting that the reference monitor is a concept and the security kernel is an implementation mechanism.
Rapid review grid
| Need | Best match |
|---|---|
| Protect confidentiality across classification levels | Bell-LaPadula |
| Protect integrity across trust levels | Biba |
| Protect business records through approved transactions | Clark-Wilson |
| Prevent conflicts of interest based on prior access | Brewer-Nash |
| Keep every transition inside secure states | State-machine model |
| Check every access through a protected mechanism | Reference monitor and complete mediation |
| Remove implicit trust based on network location | Zero trust |