CISSP - Security Models and Frameworks

Formal security models are the blueprints and engineering principles behind secure systems. As a security professional, you don't just implement controls; you reason about why they work. Understanding these abstract models transforms your approach from applying best-guess configurations to making defensible, architecture-level decisions that protect critical assets based on proven mathematical properties. This knowledge is fundamental for the CISSP exam and, more importantly, for designing systems that can withstand sophisticated threats and rigorous evaluation.

Foundational Models: Confidentiality and Integrity

Security models formalize security policies into mathematical rules that a system can enforce. Two of the most fundamental models address the core goals of confidentiality and integrity independently.

The Bell-LaPadula Model is the classic model for enforcing confidentiality. Developed for military systems, it formalizes multi-level security (MLS) using classification labels (e.g., Top Secret, Secret) and need-to-know categories. Its rules govern how subjects (users, processes) access objects (files, data). The model is defined by two core properties, often summarized as "no read up, no write down."

• The Simple Security Property (ss-property): A subject cannot read an object at a higher security level (No Read Up). This prevents a Secret-cleared user from accessing Top Secret data.
• The *-Property (Star Property): A subject cannot write to an object at a lower security level (No Write Down). This prevents a Top Secret user from accidentally or maliciously copying Top Secret data into a Secret file.

While powerful for confidentiality, Bell-LaPadula ignores integrity. This gap is addressed by the Biba Model, which is its integrity counterpart. Biba also uses integrity labels but inverts the Bell-LaPadula rules to protect data from being corrupted by less trustworthy sources.

• The Simple Integrity Axiom: A subject cannot read an object at a lower integrity level (No Read Down). You shouldn't trust data from a less trustworthy source.
• The Integrity *-Axiom: A subject cannot modify an object at a higher integrity level (No Write Up). An untrusted process cannot alter high-integrity data.

It's critical to remember that Biba and Bell-LaPadula are designed for different goals. You cannot have a system that strictly enforces both models simultaneously for the same data labels, as their read/write rules are opposites. Choosing between them, or implementing them in parallel on different data sets, is a key architectural decision.

Models for Commercial and Legal Environments

While Bell-LaPadula and Biba suit governmental contexts, commercial operations require models that enforce real-world business rules and ethical boundaries.

The Clark-Wilson Model enforces integrity in commercial environments through well-formed transactions and separation of duties. Instead of lattice-based labels, it focuses on ensuring data moves from one consistent state to another without unauthorized modification. The model defines two key sets of rules:

• Certification Rules (C Rules): These are security policies. For example, a bank must certify that a transaction procedure (like a funds transfer) is well-formed and logs all details.
• Enforcement Rules (E Rules): These are the system mechanisms that enforce the certification rules. The system must ensure only authorized users execute certified procedures on specific data items.

Clark-Wilson achieves this through a triad: Constrained Data Items (CDIs) are high-integrity data (e.g., a bank account balance), Integrity Verification Procedures (IVPs) check that CDIs are in a valid state, and Transformation Procedures (TPs) are the only allowed methods to change CDIs (e.g., a "debit account" function). This model directly informs the design of audit trails and non-repudiation mechanisms.

The Brewer-Nash Model, also known as the Chinese Wall Model, addresses conflict of interest, not confidentiality or integrity directly. It is designed for environments like consulting, auditing, or banking where a firm has multiple clients who may be competitors. The policy goal is to prevent a subject from accessing information from two competing companies.

The model dynamically changes a user's access rights based on their previous actions. Initially, you can access any company's data. However, once you access data from one company (e.g., "Bank A"), you are immediately walled off from accessing data of its competitor ("Bank B"). You remain free to access data from companies in a different conflict class (e.g., "Oil Company C"). This dynamic policy prevents the flow of sensitive competitive information within the firm.

From Models to Evaluation: The Common Criteria

Formal models provide the "what," but how do you assess if a system correctly implements them? This is where evaluation frameworks come in. The Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) is an international standard for certifying that a security product (Target of Evaluation, or TOE) meets specified requirements.

The Common Criteria process starts with a Protection Profile (PP), a vendor-independent document that defines security requirements for a category of devices (e.g., a firewall). A vendor then creates a Security Target (ST), which details how their specific product meets a PP or its own set of security objectives. The evaluation itself is conducted by an accredited lab, which assesses the TOE against its ST and assigns an Evaluation Assurance Level (EAL). EALs range from EAL1 (functionally tested) to EAL7 (formally verified design and tested), with higher levels requiring more rigorous analysis, documentation, and testing. For instance, a system designed on the Bell-LaPadula model might aim for a higher EAL to prove its mandatory access control mechanisms are mathematically sound.

Applying Models to Architecture and Access Control

Theoretical models directly inform practical security architecture and access control system design. Your choice of model dictates the underlying logic of your access control system.

• A system requiring strict data secrecy hierarchies (e.g., government contractor) would implement a Mandatory Access Control (MAC) scheme based on the Bell-LaPadula model, where labels are assigned by the system, not users.
• A financial application would be architected using Clark-Wilson principles, ensuring every change to financial records occurs through a certified TP (like a transaction API) with full audit logging, enforcing separation of duties between those who initiate and those who approve a transaction.
• A discretionary access control (DAC) system, where owners control permissions, lacks the rigorous formal guarantees of these models but may be suitable for less restrictive environments. The model informs you of the risks you accept by choosing DAC.

The decision-making process involves analyzing business requirements: What is the primary concern? Is it preventing leaks (confidentiality), ensuring data accuracy (integrity), or avoiding legal conflicts? The answer points you to the appropriate model, which in turn specifies the type of access control (MAC, role-based, attribute-based) and logging/auditing features you must design into the system.

Common Pitfalls

1. Confusing the Properties of Bell-LaPadula and Biba: A classic exam trap. Remember: Bell-LaPadula is "no read up, no write down" for confidentiality. Biba is "no read down, no write up" for integrity. Memorize them as opposing pairs.
2. Assuming One Model Fits All: The most common architectural mistake is trying to force a single model to address all security goals. Use Bell-LaPadula for confidentiality-centric systems, Biba or Clark-Wilson for integrity, and Brewer-Nash for conflict of interest. Often, zones of a system will use different models.
3. Overlooking the Purpose of Clark-Wilson: It's not just "another integrity model." Its power is in formalizing real-world business rules (TPs) and ensuring only those rules can change data. Failing to implement the separation between certification (policy) and enforcement (mechanism) misses the point.
4. Misapplying Brewer-Nash: This model is not about general confidentiality. It is a very specific, dynamic policy for preventing conflict of interest in multi-client organizations. Using it where simple MAC or DAC would suffice adds unnecessary complexity.

Summary

• Formal security models translate security policies into enforceable mathematical rules, providing a verifiable foundation for system design.
• Bell-LaPadula enforces confidentiality via "no read up, no write down" rules, while Biba enforces integrity via the inverse ("no read down, no write up"). They address complementary goals.
• Clark-Wilson is the premier model for commercial integrity, using well-formed transactions (Transformation Procedures), separation of duties, and audit to ensure data moves between consistent states.
• Brewer-Nash (Chinese Wall) dynamically controls access to prevent conflicts of interest by walling off access to competitor data after a user accesses one company's information.
• The Common Criteria provides a standardized framework for evaluating and certifying that a product meets its security specifications, culminating in an Evaluation Assurance Level (EAL).
• As a security architect, you select models based on primary business risks, and this choice directly dictates whether you implement Mandatory, Discretionary, or other forms of access control.