# Security model

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/security-model

## Quick definition

A security model is a set of rules that controls who can access what in a computer system. It helps prevent unauthorized access and protects data. Different models focus on different goals, like keeping secrets secret or making sure data isn't changed improperly.

## Simple meaning

Think of a security model like the rulebook for a very exclusive clubhouse. In this clubhouse, there are different rooms (objects) like the treasure room, the planning room, and the lounge. Each room has its own rules about who can enter. The clubhouse also has members (subjects) like Bob, Alice, and Charlie, and each member has a membership card that says which rooms they are allowed to enter.

The security model is not the lock on the door itself, but the entire system of rules that decides which card opens which door. For example, a simple rule might be: 'Only members with a 'Treasurer' badge can enter the treasure room.' A different rule might say: 'Anyone can enter the lounge, but only after they show their ID.' Some rules are very strict, like 'No member can enter the treasure room if a member with a higher rank is already inside because they might see something they shouldn't.'

In the computer world, the 'clubhouse' is your computer, network, or cloud account. The 'members' are users, programs (like your web browser), or even other computers. The 'rooms' are things like files, folders, databases, or entire servers. The security model is the set of mathematical and logical rules that the operating system or application follows to decide if a request like 'Can John's word processor read the file named 'Budget.xlsx'? should be allowed or denied.

Different clubhouses might have different rulebooks. One clubhouse might be obsessed with preventing secrets from leaking out (confidentiality), so it has very strict rules about who can read documents. Another clubhouse might be most worried about someone sneaking in and changing the guest list (integrity), so it has strict rules about who can write or modify things. A third clubhouse might be focused on making sure everyone can get into the main hall during an emergency (availability), so it has rules that prevent any single person from blocking the door.

Understanding the security model is crucial because it tells you what the system guarantees. If you know the rules, you can predict what will happen in different situations. You can also spot potential weaknesses. For example, if the rules say 'anyone can read the temperature log' but the temperature log is stored in the same folder as 'password backup.txt', the security model might not be strong enough for the data it is supposed to protect. Choosing the right security model for a particular job is a fundamental part of designing a secure system.

## Technical definition

A security model is a formal, often mathematically based, specification of a security policy. It defines the rules and relationships that govern how subjects (active entities, such as users or processes) can access objects (passive entities, such as files or memory segments) within a computer system. These models provide a theoretical foundation for verifying that a system's implementation enforces a given security policy. They are essential for trusted system design and evaluation, often referenced in standards like the Trusted Computer System Evaluation Criteria (TCSEC) and the Common Criteria.

Key components of a security model include subjects, objects, access modes (read, write, execute, append, delete), and a set of rules that define allowable states and state transitions. State transitions occur when a subject performs an access operation on an object. A secure system is one that starts in a secure state and never transitions to an insecure state through any sequence of allowed operations. This is the fundamental concept of a 'secure state machine' model.

Several classic security models have been developed, each addressing different primary goals:

The Bell-LaPadula Model (BLP) is the most famous model for confidentiality. It enforces two core rules: the Simple Security Property (No Read Up) and the *-Property (No Write Down). Subjects and objects are assigned security levels (e.g., Unclassified, Secret, Top Secret). A subject can read an object only if its clearance is equal to or greater than the object's classification (No Read Up). A subject can write to an object only if its clearance is equal to or less than the object's classification (No Write Down). This prevents a high-clearance subject from accidentally or maliciously writing classified information to a lower-classification object. BLP is widely used in military and government systems.

The Biba Model is the classic model for integrity. It is essentially the dual of Bell-LaPadula. Biba enforces: the Simple Integrity Property (No Read Down) and the *-Integrity Property (No Write Up). Subjects and objects are assigned integrity levels (e.g., High, Medium, Low). A subject can read an object only if its integrity level is less than or equal to the object's level (No Read Down). This prevents a low-integrity subject from reading high-integrity data and potentially corrupting it. A subject can write to an object only if its integrity level is greater than or equal to the object's level (No Write Up). This prevents a low-integrity subject from writing to a high-integrity object. Biba is critical for ensuring data accuracy and preventing unauthorized modification.

The Clark-Wilson Model addresses commercial integrity requirements, such as in banking and accounting. It focuses on preventing unauthorized modifications by authorized users. It introduces concepts like Constrained Data Items (CDIs), Transformation Procedures (TPs), and Integrity Verification Procedures (IVPs). Transactions are only allowed through well-formed TPs, and separation of duties ensures that a single person cannot complete a fraudulent transaction alone. This model is more practical for business environments than Biba.

The Brewer-Nash Model (also known as the Chinese Wall Model) is designed to prevent conflicts of interest, particularly in financial services or consulting firms. It dynamically changes access rights based on the data a user has already accessed. For example, an analyst who has accessed data for Company A cannot then access data for a competitor, Company B, if the two companies are in the same conflict-of-interest class. This model prevents insider trading and information leakage.

Modern implementations often use a combination of these models. For instance, SELinux uses a Flask security architecture that can enforce Type Enforcement (a form of mandatory access control) and optionally use models like Bell-LaPadula or Biba. Cloud providers like AWS implement Identity and Access Management (IAM) policies that are conceptually similar to these models, defining who (subject) can perform which action (access mode) on which resource (object). Understanding these underlying models helps architects design robust, verifiable security policies.

## Real-life example

Imagine a large, secure apartment building. This building is not just a place to live; it contains a mix of residential apartments, a corporate office on the third floor, and a medical clinic in the basement. Each area has different security needs. The building manager, who is like the system administrator, must create a set of rules (the security model) to govern who can go where and what they can do there.

First, think about the residential tenants. They are subjects. Their apartments are objects. The model for a tenant's own apartment is fairly simple: they have full access (read, write, create, delete) to their own apartment. They can bring in furniture, paint walls, and throw out trash. This is like a Discretionary Access Control (DAC) model where the owner has full control. However, the model says a tenant cannot enter another tenant's apartment without an explicit invitation, which is like an Access Control List (ACL).

Now, consider the corporate office on the third floor. It follows a very different rule set, similar to the Bell-LaPadula model. Employees are given security clearances. A 'Public Relations' employee (low clearance) can read press releases in the 'Public' folder, but cannot read the 'Financial Forecast' document (Top Secret). This is 'No Read Up.' A 'Chief Financial Officer' (high clearance) can read the 'Financial Forecast,' but if they try to save a copy of it to the 'Public' folder (a lower classification), the system model should block that action. This is 'No Write Down.' The building's security model for the third floor is designed to prevent the leakage of confidential financial information.

Finally, the medical clinic in the basement operates under a different model, focused on integrity and confidentiality, similar to a combination of Clark-Wilson and Biba. The medical records database (object) has a high integrity level. A doctor (subject with high integrity) can read a patient record and update the diagnosis using a specific, well-formed software application (a Transformation Procedure). However, the model prevents a doctor from directly writing raw data to the database using a generic text editor, because that would bypass the validation checks. This enforces integrity. The clinic's model also enforces Bell-LaPadula for patient privacy: a doctor can read patient records, but a billing clerk (lower clearance) can only read billing codes, not the full medical history (No Read Up for the clerk). The clinic model also has a Chinese Wall element: if a doctor has treated Patient A, the system will block them from viewing any records of a legal case where Patient A is suing the clinic, to prevent a conflict of interest.

This whole building uses a single building-wide access control system at the main door, but the security model for each floor is different. The building manager didn't just buy a lock; they designed a comprehensive rulebook that dictates exactly how the locks, keys, and access cards must work to meet the different security goals of each tenant. This is exactly how a security model works in IT: it is the blueprint that defines the rules, not the specific tools that enforce them.

## Why it matters

Understanding security models is not just an academic exercise; it is a fundamental practical skill for any IT professional responsible for protecting data and systems. A security model provides the 'why' behind access control decisions. When you configure a firewall rule, set a file permission, or write an IAM policy, you are implementing a security model, whether you realize it or not. If you don't understand the underlying model, you risk creating rules that are contradictory, incomplete, or even harmful.

For example, a common mistake is to implement a policy that is strict about who can read a sensitive file (confidentiality) but neglects to consider who can modify it (integrity). This is like having a lock on the door of the treasure room but allowing anyone to change the room's floor plan from the outside. An understanding of the Biba model would highlight this vulnerability immediately. A professional who knows the Clark-Wilson model will design a system for processing financial transactions with built-in separation of duties and well-formed transactions from the start, rather than trying to patch security holes later.

Security models also dictate how a system behaves during unexpected events or edge cases. For example, what happens when a user with high clearance tries to send a confidential document to an external partner via email? A system built on Bell-LaPadula should block that 'write down' operation. If it doesn't, the system is not correctly enforcing its security model, and the organization has a data leak risk. Professionals need to choose the right model for the task. Using a Bell-LaPadula model for a system where data integrity is the primary concern (like a payroll system) would be a poor architectural choice.

security models are the basis for compliance with many regulations like GDPR, HIPAA, and PCI-DSS. These regulations often mandate specific protections for data, such as preventing unauthorized access (confidentiality) and ensuring data is not altered without authorization (integrity). A security model provides the structured, verifiable framework to demonstrate that these requirements are being met. In short, a deep knowledge of security models enables an IT professional to move from simply 'following checklists' to 'designing secure systems'.

## Why it matters in exams

Security models are a core concept for several major IT certification exams, carrying significant weight and appearing in various question formats. For the ISC2 CISSP exam, this is a primary domain topic (Domain 3: Security Architecture and Engineering). You must understand the Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash, and state machine models in depth. Expect questions that describe a scenario and ask you to identify which model is best suited, or to identify which property (e.g., *-Property) is being violated. You will need to distinguish between models that provide confidentiality (BLP) versus integrity (Biba, Clark-Wilson).

For the CompTIA Security+ (SY0-601/701) exam, security models are a fundamental concept covered under 'Security Architecture' and 'Access Control'. While the depth is less than CISSP, you are expected to know the three primary models (BLP, Biba, Clark-Wilson) and their core principles, especially the 'No Read Up, No Write Down' concept. Questions often present a simple scenario and ask which model would prevent a specific type of unauthorized access or modification.

The AWS Certified Solutions Architect - Associate (SAA-C03) exam also touches on this concept. While you don't need to memorize the academic names of the models, you must understand how AWS IAM policies implement a security model. Questions will test your ability to apply concepts like principle of least privilege (a concept related to security models) and to design resource-based policies that enforce specific rules. Understanding the underlying concept of a security model helps you reason about complex policy evaluations.

The CompTIA CySA+ focuses on applying security concepts in a blue-team context. You might see questions about misconfigurations that violate a security model, such as a low-integrity script being able to modify a high-integrity system file. The SC-900 (Microsoft Security, Compliance, and Identity Fundamentals) introduces the concept of identity and access management as a foundational security model. The Azure administration exams (AZ-104, MD-102, MS-102) require an understanding of Azure RBAC, which is the implementation of a role-based security model. Knowing the theoretical model helps you design better role assignments.

Exam questions can be theoretical ('Which model prevents a top-secret user from writing to a secret file?'), scenario-based ('A bank wants to prevent a single employee from both approving and processing a loan. Which model applies?'), or troubleshooting ('An administrator cannot access a file even though they have the correct NTFS permissions. What should they check? - This could involve understanding how conflicting security model rules from a model like Biba might be blocking the access.'). Mastering security models is not just about memorizing acronyms; it is about understanding the logical framework that all access control systems rely on.

## How it appears in exam questions

Questions about security models on certification exams fall into several distinct patterns. The most common is the theoretical definition question. For example, 'Which security model prevents subjects from reading objects at a higher classification level?' The answer is the Bell-LaPadula model, specifically its Simple Security Property. A variant might ask, 'Which property of the Biba model ensures that a low-integrity subject cannot write to a high-integrity object?' The answer is the *-Integrity Property (No Write Up).

Another frequent pattern is the scenario-based question. The exam will describe an organization's security requirements and ask you to select the most appropriate model. Example: 'A hospital needs a system where a doctor (high integrity) can update patient records, but a data entry clerk (low integrity) cannot directly modify the same records. The system must also prevent the doctor from accidentally overwriting critical audit logs. Which model should the security architect choose?' The correct answer would be the Biba model, as it enforces integrity levels and prevents modifications from lower to higher integrity subjects and objects. A different scenario: 'A government agency wants to ensure that a user with a Top Secret clearance cannot send classified data to an unclassified network printer.' This directly points to the Bell-LaPadula *-Property.

Troubleshooting questions are also common, particularly on the CISSP and CySA+ exams. For instance: 'A system administrator reports that users with high clearance can read sensitive files, but when they try to copy them to a shared drive meant for lower-clearance users, the operation fails. The administrator is confused because there is no explicit deny rule on the shared drive. What is the most likely explanation?' The answer would involve the system's underlying security model (Bell-LaPadula) preventing the 'write down' operation, which is implicit, not a configured deny.

Configuration and design questions appear on cloud exams like AWS SAA. Example: 'A company's S3 bucket contains both public marketing documents and internal financial reports. An IAM policy grants an analyst full access to the bucket. A security audit finds that the analyst can delete the marketing documents but cannot read the financial reports. Which security model principle is being enforced?' The answer would be 'No Read Up' from Bell-LaPadula or general least privilege. Another pattern on Azure exams might ask: 'An Azure subscription has several custom roles. A user reports that even though they are a member of the Contributor role for a resource group, they cannot restart a virtual machine. Which component of the security model (RBAC) is likely misconfigured?' This tests understanding of role definitions, assignments, and scope.

Finally, there are comparison questions that ask for differences. 'What is the primary difference between the Bell-LaPadula and the Clark-Wilson security models?' The correct answer focuses on confidentiality versus integrity. Knowing these patterns and practicing with official practice tests is key to mastering this topic for the exam.

## Example scenario

You are the IT security administrator for a small company called 'DataFirst'. The company has a central file server that stores all project files. The Marketing Department has a folder called 'Campaigns'. Inside 'Campaigns', there are subfolders: 'Public Ads' and 'Secret Launches'. The 'Secret Launches' folder contains information about upcoming, unannounced products.

The company's security policy states:
1. All Marketing employees can read and write to the 'Campaigns' folder.
2. Employees from other departments (e.g., Sales, HR, IT) cannot access the 'Campaigns' folder at all.
3. Only the Marketing Director, Jane, can create and delete files in the 'Secret Launches' folder. Other Marketing employees can only read files in 'Secret Launches'.
4. The 'Public Ads' folder is readable by any employee in the company.

You, as the administrator, must configure the file server's access controls to enforce this policy. This policy is your company's security model for the 'Campaigns' folder. You need to implement it using NTFS permissions on Windows Server or POSIX permissions on Linux.

To do this, you will create security groups (subjects): 'Marketing_Full', 'Marketing_ReadOnly', 'All_Employees', and 'Jane_Admin'. You will then assign permissions to the folders (objects). For the 'Secret Launches' folder, you give Jane 'Full Control', give 'Marketing_ReadOnly' (which includes all Marketing staff except Jane) 'Read' permission, and explicitly deny 'All_Employees' any access. For 'Public Ads', you give everyone 'Read' permission and give 'Marketing_Full' 'Write' permission.

A month later, a new sales intern, Tom, tries to open a file in the 'Secret Launches' folder. Because Tom is not in the 'Marketing_ReadOnly' group and the folder has an explicit deny for 'All_Employees', his access is blocked. This is the security model at work. Later, Jane is on vacation. A junior marketing employee, Alex, tries to delete an old document from 'Secret Launches' to make space. Even though Alex is in 'Marketing_Full', the model you implemented gives him only 'Read' access to 'Secret Launches', so the deletion is denied. This scenario shows how a carefully defined security model can be translated into concrete, enforceable rules.

## The Core Security Model Principles: Confidentiality, Integrity, and Availability

The security model of any system is fundamentally built upon three core principles: confidentiality, integrity, and availability, often referred to as the CIA triad. These principles serve as the foundation for all security architectures, including those tested in AWS SAA, CISSP, CySA+, and Microsoft exams. Confidentiality ensures that sensitive data is accessible only to authorized individuals or systems. This is enforced through encryption, access control lists, and authentication mechanisms. For example, in an AWS environment, confidentiality is maintained using services like AWS Key Management Service (KMS) to encrypt data at rest and AWS Certificate Manager for TLS encryption in transit. In Microsoft Azure, Azure Information Protection and Azure Key Vault serve similar roles. Integrity guarantees that data is not altered or tampered with by unauthorized parties. This is achieved through hashing algorithms, digital signatures, and audit logs. For instance, using AWS CloudTrail or Azure Monitor to log all changes to resources helps detect unauthorized modifications. Availability ensures that systems and data remain accessible to authorized users when needed. This involves redundancy, failover mechanisms, and disaster recovery planning. In a cloud environment, this might be implemented using AWS Auto Scaling and Elastic Load Balancing or Azure Availability Sets and Azure Site Recovery. These three principles are not isolated; they interact and sometimes conflict. For example, increasing confidentiality through strict access controls might reduce availability if users are locked out. Security models like the Bell-LaPadula model focus on confidentiality, while the Biba model focuses on integrity. In the context of the CISSP exam, understanding these trade-offs is crucial. Real-world security models often combine these principles with additional elements such as non-repudiation and authentication, forming the Parkerian hexad, which adds possession, utility, and authenticity. However, for exams like AWS SAA or SC-900, the CIA triad remains the central framework. Security professionals must design architectures that balance these principles based on organizational risk tolerance. For example, a financial application might prioritize integrity and availability over extreme confidentiality, while a healthcare system may prioritize confidentiality due to HIPAA regulations. The security model is not a one-size-fits-all template but a strategic framework that adapts to specific threats, regulatory requirements, and business needs. Understanding how to implement and test these principles is essential for passing security certification exams and for real-world system design.

## Access Control Models in Security Architecture: DAC, MAC, RBAC, and ABAC

Access control models are a critical component of any security model, defining how subjects (users, processes) can interact with objects (files, databases, network resources). The four primary models tested in security exams like CISSP, Security+, and Azure certifications are Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). Discretionary Access Control (DAC) allows the owner of an object to decide who can access it and with what permissions. This is common in file systems like Linux where each file has an owner who can assign read, write, or execute permissions to other users. While flexible, DAC is vulnerable to privilege escalation if users share access inadvertently. In cloud environments, AWS S3 bucket policies can be considered a form of DAC, where the bucket owner defines permissions for users and roles. However, exams emphasize that DAC is not suitable for high-security environments due to lack of centralized control. Mandatory Access Control (MAC) imposes system-wide policies that cannot be overridden by users. The operating system or security kernel enforces labels (e.g., Top Secret, Secret, Confidential) to control access. This model is used in military and government systems and is a key topic in the CISSP exam. In practice, SELinux on Linux implements MAC policies, and Microsoft Windows uses integrity levels as a form of MAC. MAC is highly secure but complex to manage, often requiring strict configuration. Role-Based Access Control (RBAC) assigns permissions to roles, and users are assigned roles based on their job functions. This is the most widely used model in enterprise environments and cloud platforms. For example, in Azure RBAC, built-in roles like Reader, Contributor, and Owner provide granular control. AWS IAM roles also operate on RBAC principles. Exams like AZ-104 and MS-102 test your ability to configure RBAC to follow the principle of least privilege. RBAC simplifies administration because changes to permissions only require updating a role definition. Attribute-Based Access Control (ABAC) is a more dynamic model that uses attributes (user, resource, environment, action) to determine access. For instance, access can be granted only if a user's department attribute matches the resource's department and the request comes from a trusted IP range. AWS IAM policies with conditions and Azure Policy with custom roles implement ABAC. Exams like SC-900 and Security+ highlight that ABAC provides fine-grained control but increases complexity. Understanding the trade-offs between these models is essential for building secure architectures. For example, a hybrid approach often combines RBAC for broad permissions and ABAC for sensitive transactions. Security professionals must choose the appropriate model based on threat landscape, regulatory requirements, and operational efficiency. The CISSP exam, in particular, expects deep knowledge of how MAC and DAC differ, including the concept of lattice-based access control in MAC. In practice, modern systems often layer multiple models; for example, a database might use DAC for tables while the underlying OS enforces MAC. Mastering these models helps in answering scenario-based questions in exams like CySA+ and MD-102, where you must select the best control for a given situation.

## Threat Modeling as a Security Model Component: STRIDE, PASTA, and Attack Trees

Threat modeling is a systematic approach to identifying, evaluating, and mitigating security threats within a system. It is a fundamental part of the security model because it helps architects and engineers design systems that resist attacks. Exams such as CISSP, Security+, and CySA+ emphasize understanding threat modeling frameworks like STRIDE, PASTA, and Attack Trees. STRIDE, developed by Microsoft, categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each threat maps to a specific security control. For example, spoofing is countered by authentication, tampering by integrity checks, and denial of service by availability controls. In practice, using STRIDE during design helps teams ensure that every threat type is addressed. For cloud environments, AWS Well-Architected Framework and Azure Security Benchmarks incorporate STRIDE concepts. STRIDE is also tested in the SC-900 exam for building secure Microsoft solutions. PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric framework that involves seven stages: define objectives, define technical scope, decompose application, analyze threats, identify vulnerabilities, enumerate attacks, and analyze residual risk. PASTA is more comprehensive than STRIDE and is often used in enterprise security assessments. It aligns with business impact analysis, making it popular for CISSP exam questions that require understanding of risk management. Attack Trees, introduced by Bruce Schneier, provide a graphical representation of how an attacker might achieve a goal. The root node is the attack goal, and branches represent different methods. This model helps security teams visualize attack vectors and prioritize defenses. In exams like CySA+, attack trees are used to analyze complex attack scenarios. Threat modeling must be integrated into the development lifecycle, often in the design phase. For example, in Azure DevOps, you can use threat modeling tools that generate STRIDE-based reports. Similarly, AWS Security Hub provides automated threat detection but requires manual threat modeling during architecture design. A common exam scenario involves a business application that needs to be compliant with regulations like PCI-DSS or HIPAA. The security model must incorporate threat modeling to identify where sensitive data flows and how it can be compromised. Another important aspect is understanding that threat modeling is not a one-time activity; it must be repeated as the system evolves. For instance, when adding a new API endpoint, you must re-evaluate threats like information disclosure or elevation of privilege. Security professionals are also expected to know how to use data flow diagrams (DFDs) to represent trust boundaries, processes, and data stores. In the CISSP exam, you might be asked to identify the appropriate countermeasure based on a DFD. Overall, threat modeling strengthens the security model by proactively addressing vulnerabilities before deployment, reducing the cost of fixing issues later. Mastering these frameworks is key to answering scenario-based questions in certification exams and ensuring robust security architecture.

## Defense in Depth: Layered Security Model for Cloud and On-Premises Environments

Defense in depth is a security model strategy that employs multiple layers of defensive controls to protect information and systems. The principle is that if one layer fails, subsequent layers continue to provide protection. This concept is universally tested across exams like AWS SAA, CISSP, Security+, and Azure certifications. The layers typically include physical security, network security, endpoint security, data security, identity and access management, and application security. Physical security involves controlling access to data centers and hardware, such as biometric locks, security guards, and surveillance cameras. In cloud environments, this is managed by the provider, but the customer is responsible for logical controls. Network security includes firewalls, intrusion detection systems (IDS), virtual private networks (VPNs), and network segmentation. For example, in AWS, security groups and network ACLs act as virtual firewalls at the instance and subnet levels. In Azure, network security groups (NSGs) and Azure Firewall provide similar controls. Exams test your ability to configure these to block unauthorized traffic while allowing legitimate communication. Endpoint security includes antivirus, endpoint detection and response (EDR), and patch management. In Microsoft environments, Microsoft Defender for Endpoint and Intune provide endpoint protection. Security+ exams emphasize the importance of baseline configurations and regular scanning. Data security focuses on encryption at rest, in transit, and during processing. This involves technologies like AWS KMS, Azure Key Vault, and TLS/SSL. Identity and access management (IAM) is arguably the most critical layer, implementing least privilege, multi-factor authentication (MFA), and role-based access control. For example, Azure AD Conditional Access policies enforce MFA based on user location, device compliance, and risk level. The MS-102 exam tests deep understanding of these policies. Application security includes secure coding practices, web application firewalls (WAFs), and input validation. AWS WAF and Azure Application Gateway WAF help protect against common attacks like SQL injection and cross-site scripting. Defense in depth also includes administrative controls like security policies, user training, and incident response plans. A real-world example is protecting a database server. The first layer is physical security of the data center, then network segmentation isolating the database subnet, then a firewall allowing only specific application servers, then database authentication and authorization, and finally encryption of the data at rest. Even if an attacker breaches the application server, they would still need valid database credentials and an encrypted connection to exfiltrate data. In cloud architect exams like AWS SAA, you must design a multi-tier architecture that follows defense in depth. For instance, using an Application Load Balancer (ALB) in public subnets, web servers in private subnets with security groups, and RDS in dedicated subnets with encryption enabled. You might enable AWS Shield for DDoS protection and AWS CloudTrail for logging. In the context of the CISSP exam, defense in depth is often associated with the concept of layered security and the principle of least privilege. Another important aspect is that defense in depth does not mean adding controls blindly; each layer should be justified based on risk assessment. Overlapping controls can introduce complexity and management overhead. For example, having too many firewall rules can lead to misconfigurations. Therefore, security professionals must balance security with usability. Exams like CySA+ and SC-900 test your ability to evaluate whether a given set of controls sufficiently covers the attack surface. Defense in depth is a holistic security model that ensures resilience against a wide range of threats, from advanced persistent threats to insider threats. It is the gold standard for building secure systems and a recurring theme in all major security certifications.

## Common mistakes

- **Mistake:** Thinking all security models are the same and only control who can access a file.
  - Why it is wrong: Different models have different focuses. Bell-LaPadula focuses on confidentiality, Biba and Clark-Wilson focus on integrity, and Brewer-Nash focuses on conflict of interest. Using a confidentiality model for a system that needs integrity (like a payroll system) will not protect it from data corruption.
  - Fix: Always identify the primary security goal (confidentiality, integrity, availability, or non-repudiation) before choosing a model. Match the model to the primary goal.
- **Mistake:** Confusing the 'No Write Down' rule in Bell-LaPadula (confidentiality) with 'No Write Up' in Biba (integrity).
  - Why it is wrong: This is a classic mix-up. Getting them reversed means you would design a system that actively harms its own security goals.
  - Fix: Remember: BLP prevents leaks (high to low is bad for writes). Biba prevents corruption (low to high is bad for writes). A mnemonic: 'BLP: Leaks Down (bad). Biba: Dirt Up (bad).'
- **Mistake:** Believing that a security model is the same as a security policy.
  - Why it is wrong: A security policy is a high-level statement of goals (e.g., 'Customer data must be kept confidential'). A security model is the formal, mathematical framework that provides the rules to enforce the policy (e.g., 'Enforce No Read Up and No Write Down'). The policy is the 'what'; the model is the 'how'.
  - Fix: Think of the policy as 'We need to keep secrets.' The model is the specific recipe (like 'Do not let anyone with a lower badge read a higher-badge document') that the engineers use to build the system.
- **Mistake:** Assuming that implementing a security model is just about setting file permissions.
  - Why it is wrong: Implementing a model often requires deep changes in the operating system, application logic, and database design. For example, Bell-LaPadula requires the system to track security labels on all objects and subjects, which is not possible with standard Windows NTFS permissions alone. You might need a specialized trusted OS like SELinux or a secure database.
  - Fix: Recognize that security models are implemented at the kernel or architecture level, not just at the application layer. When designing a high-security system, plan to use an operating system that supports the model you need (e.g., a trusted OS with MLS).
- **Mistake:** Ignoring the state machine principle of starting in a secure state and staying there.
  - Why it is wrong: Many people focus only on access rules but forget that the initial system configuration must be secure. If a system boots up with default insecure permissions, it has already failed the state machine principle.
  - Fix: When auditing a system, always check the baseline configuration. A secure model must start from a known-good, secure state. This is why secure image hardening is so important.

## Exam trap

{"trap":"The exam might present a scenario where a highly trusted user (like a system administrator) is unable to perform an action on a file that they have explicit 'Full Control' over in the file system. The trap is to assume a permission problem at the file level.","why_learners_choose_it":"Learners often default to the most familiar cause of access denied: the file or folder permissions (NTFS, POSIX). They do not consider that a mandatory security model (like BLP or Biba) running in the kernel might be overriding those permissions.","how_to_avoid_it":"Always consider mandatory access controls (MAC) as a possible reason for denied access, especially when the user is a high-privilege account. In a MAC environment, even an administrator cannot bypass the security model's rules. In a system running SELinux (which can enforce a Biba-like model), an admin might not be able to write a file labeled with a higher integrity level, even if they are root. The correct answer in such a question would be 'The system's mandatory security model is enforcing a rule that prevents the action.'"}

## Commonly confused with

- **Security model vs Security policy:** A security policy is a high-level document that states what an organization wants to protect and why (e.g., 'All customer data must be encrypted at rest'). A security model is the formal, technical blueprint that defines exactly how those rules will be enforced (e.g., 'Use Bell-LaPadula model to prevent unauthorized data reads'). The policy is the goal, the model is the method. (Example: Policy: 'No unauthorized access to patient records.' Model: 'Implement Bell-LaPadula to ensure a nurse cannot read a patient record classified as 'Physician-Only' (No Read Up).')
- **Security model vs Access control list (ACL):** An ACL is a specific data structure or list associated with an object (like a file) that explicitly states which subjects can access it and in what ways. A security model is the overarching rule system that determines how ACLs are created, interpreted, and overridden. ACLs are a tool used to implement a model, but the model is the bigger framework. (Example: A file's ACL says 'User Alice can Read this file.' The security model (e.g., Bell-LaPadula) might still block Alice from reading it if her clearance is lower than the file's classification, overriding the ACL.)
- **Security model vs Security architecture:** Security architecture is the overall design and structure of an organization's security controls, including policies, models, hardware, and software. The security model is a component within that architecture. The architecture is the entire house; the security model is the rulebook for the doors and windows. (Example: The security architecture of a cloud platform includes firewalls, encryption, IAM, and a PKI. The security model for the IAM component might be a Role-Based Access Control model.)
- **Security model vs Trusted computing base (TCB):** The TCB is the set of all hardware, firmware, and software components that are critical to the security of a system, and whose failure could cause a breach of the security policy. The security model defines what the TCB should enforce. The TCB is the physical and logical implementation of the model. (Example: The security model says 'No Write Down.' The TCB includes the kernel, the security reference monitor, and the hardware that ensures the kernel cannot be bypassed.)
- **Security model vs Encryption:** Encryption is a cryptographic mechanism that transforms data to make it unreadable without a key. It protects data confidentiality at rest or in transit. A security model may mandate encryption as one of its rules, but the model itself is about the logic of access control, not just about scrambling data. (Example: A security model might have a rule 'All sensitive data must be encrypted before being written to a lower-classification system.' The encryption is the tool that fulfills the model's 'No Write Down' rule.)

## Step-by-step breakdown

1. **Identify Subjects and Objects** — The first step in applying a security model is to clearly identify all subjects (users, processes, applications) and objects (files, directories, databases, printers, network sockets) in the system. In a cloud environment, a subject could be an IAM role, and an object could be an S3 bucket. Without this clear identification, no rules can be correctly assigned.
2. **Define Security Classes or Levels** — Next, assign a classification or integrity level to every subject and object. For Bell-LaPadula, this might be 'Unclassified, Confidential, Secret, Top Secret'. For Biba, it might be 'Low, Medium, High'. This step creates the hierarchical structure the model needs to enforce its rules. In practice, this is done via security labels or tags.
3. **Define Allowed Access Operations** — Specify all the possible actions a subject can perform on an object. Common operations are read, write, execute, append, and delete. The security model will define exactly which combinations of these operations are permitted based on the security classes. For example, Bell-LaPadula allows read if subject level >= object level, and write if subject level <= object level.
4. **Define the Security Rules (Properties)** — This is the core of the model. Define the formal rules, such as the Simple Security Property, the *-Property, the Simple Integrity Property, etc. These rules must be mathematically precise so they can be implemented in code. For example, a rule might be: 'A subject may read an object if and only if the subject's security level dominates the object's security level.'
5. **Enforce a Secure Initial State** — The system must be booted or initialized into a state that is proven to be secure according to the model's rules. This means that at startup, all subjects have valid security labels, all objects have correct classifications, and no access rights are granted that violate the rules. A compromised initial state means the model cannot guarantee security.
6. **Implement a Reference Monitor** — The rules must be enforced by a trusted, tamper-proof component called the security reference monitor. This piece of software or firmware mediates every access attempt by a subject to an object. It checks the request against the security model's rules and either grants or denies access. It must be invoked on every access (complete mediation) and be small enough to verify (verifiability).
7. **Define State Transitions** — The model must define all allowed state transitions. A state transition occurs when a subject successfully performs an operation on an object (e.g., creating a new file, changing a file's classification). The model must ensure that no transition can lead to an insecure state. For example, creating a new file should automatically assign it a classification based on the subject's clearance and the context.
8. **Audit and Verify Compliance** — The final step is continuous auditing. The system must log all access attempts (both allowed and denied) so that administrators can verify that the security model is being correctly enforced. Formal verification techniques can be used to mathematically prove that the system's state transitions never violate the model's rules. In practice, this translates to reviewing security logs and using tools like SELinux audit logs.

## Practical mini-lesson

To understand how a security model works in practice, let us look at SELinux (Security-Enhanced Linux). SELinux is a mandatory access control (MAC) system built into the Linux kernel. It is one of the most practical implementations of formal security models in mainstream computing.

SELinux does not rely on traditional discretionary access controls (DAC) like user-owner-group permissions alone. Instead, it implements a security model based on Type Enforcement (TE). Every subject (process) is assigned a 'domain' and every object (file, socket, etc.) is assigned a 'type'. The SELinux policy is a set of rules that defines which domains can access which types and in what ways. This is essentially a custom security model.

For example, the Apache web server runs in the domain 'httpd_t'. The content it serves is stored in files of type 'httpd_sys_content_t'. A standard SELinux policy includes a rule that allows 'httpd_t' to read 'httpd_sys_content_t'. This is normal. However, what if a vulnerability allows an attacker to take control of the Apache process and try to write to a system configuration file of type 'shadow_t' (which contains passwords)? The rule in the SELinux policy does NOT allow 'httpd_t' to write to 'shadow_t'. Even if the Apache process has root privileges under the DAC model, SELinux will block the write. This is the security model (MAC) overriding the traditional permissions.

What can go wrong? A common real-world issue is that SELinux can block legitimate operations if the policy is too strict. For instance, if you move a website from a standard directory to a custom directory (e.g., /opt/myapp), the files might get the wrong SELinux type (like 'default_t'). When Apache tries to read them, SELinux denies the request. The system log (in /var/log/audit/audit.log) will show an AVC denial. The fix is not to disable SELinux, but to restore the correct file context using the 'restorecon' command or to update the SELinux policy with a custom rule.

Professional Linux administrators must understand this. Configuring a service involves not just setting traditional permissions but also ensuring that the SELinux context (the part of the security model) is correct. Tools like 'semanage', 'chcon', and 'sealert' are used to diagnose and fix SELinux policy violations. This practical lesson shows how an abstract security model becomes a day-to-day operational reality. The model (SELinux Type Enforcement) is not just theory; it is a running software component that actively mediates every system call, and ignoring it will lead to security breaches or application failures.

## Commands

```
aws iam create-role --role-name SecurityAuditor --assume-role-policy-document file://trust-policy.json
```
Creates an IAM role for a security auditor that can assume the role across accounts. Used in AWS security models to enforce least privilege by granting temporary credentials.

*Exam note: Tests your understanding of IAM roles vs. users, and how to set up cross-account access. Common in AWS SAA and Security+ exams.*

```
Set-AzurePolicy -Name 'Require MFA' -PolicyDefinition 'Microsoft.GuestConfiguration/AzureWindowsBaseline' -Scope '/subscriptions/123/resourceGroups/prod'
```
Assigns an Azure Policy that enforces MFA for all users accessing resources in a specific resource group. Part of identity security model.

*Exam note: Azure policy assignments are tested in AZ-104 and SC-900 to enforce compliance and security controls at scale.*

```
gcloud projects add-iam-policy-binding my-project --member='serviceAccount:sa@project.iam.gserviceaccount.com' --role='roles/bigquery.admin'
```
Binds a service account to the BigQuery admin role, giving it full access to BigQuery datasets. Used in GCP security models for service account management.

*Exam note: Though not directly in your listed exams, similar concepts appear in AWS and Azure exams. Tests understanding of IAM bindings and service accounts.*

```
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
```
Adds a rule to the firewall that allows SSH access only from the 192.168.1.0/24 subnet. Used in network security models for segmentation.

*Exam note: Tests network access control concepts in Security+ and CySA+. Understand how to restrict management ports to trusted networks.*

```
net user jdoe /domain /active:no
```
Disables a user account in Active Directory. Used in identity management within Windows security models to revoke access immediately.

*Exam note: Common in MD-102 and MS-102 exams for user account lifecycle management and incident response.*

```
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
```
Configures PowerShell execution policy to allow only signed scripts from remote sources. Part of host security model to prevent unauthorized script execution.

*Exam note: Tests secure configuration and attack surface reduction. Appears in Security+ and MS-102 for endpoint hardening.*

```
az network nsg rule create --resource-group MyGroup --nsg-name MyNSG --name AllowHTTP --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 80
```
Creates a network security group rule to allow inbound HTTP traffic on port 80. Used in Azure network security models.

*Exam note: Essential for AZ-104. Tests understanding of NSGs, priority order, and how to control inbound and outbound traffic.*

## Troubleshooting clues

- **Insufficient permissions to access S3 bucket** — symptom: User receives AccessDenied error when trying to list or download objects from an S3 bucket, even though they are within the same AWS account.. The IAM user or role does not have the necessary s3:ListBucket or s3:GetObject permissions. Alternatively, a bucket policy could be denying access even if IAM allows it. (Exam clue: Exams test the difference between identity-based policies and resource-based policies. You must check both layers.)
- **MFA loopback failure in Azure AD Conditional Access** — symptom: Users are prompted for MFA repeatedly in a browser session, even after successfully authenticating. This causes login failures and frustration.. The Conditional Access policy may be configured with session controls that enforce re-authentication too frequently, or the browser is not storing the MFA claim cookie correctly due to privacy settings. (Exam clue: This scenario tests understanding of Conditional Access session controls and token lifetime policies in MS-102 and SC-900.)
- **Network security group rule not taking effect** — symptom: A newly created NSG rule allowing traffic on port 443 does not permit HTTPS connections to the virtual machine. Connections are still refused.. The NSG rule may have a lower priority than an existing deny rule. Also, Azure NSGs are stateful, so outbound traffic rules might not be correctly configured for the return traffic. (Exam clue: Common in AZ-104. Tests understanding of NSG priority, rule evaluation order, and stateful firewall behavior.)
- **Security group in AWS allowing traffic from unexpected IP** — symptom: An EC2 instance receives traffic from an IP address that is not in the security group's allowed list. The security group appears to be working for other IPs.. The security group might have a default rule allowing traffic, or there could be a network ACL that permits the traffic. Also, if the security group is attached to multiple instances, a rule might be too permissive. (Exam clue: Tests understanding of security group vs. network ACL in AWS SAA. Security groups are stateful and evaluate all rules before allowing traffic.)
- **User cannot access SharePoint site after RBAC role change** — symptom: A user who was previously able to access a SharePoint Online site loses access after being assigned a new Azure AD role. Other users with the same role can access.. The new role may have higher permissions that override or conflict with the existing SharePoint permissions. Alternatively, the user's group membership changed, affecting access via group-based sharing. (Exam clue: Tests RBAC inheritance and group-based access in MS-102 and SC-900. Understand that role assignments in Azure AD do not automatically grant SharePoint permissions.)
- **Windows Defender Firewall blocking legitimate application** — symptom: An in-house application fails to connect to a network resource after a Windows Update. The application works when the firewall is disabled.. The update may have changed firewall rules or added a new default block rule for the application's port. The Windows Firewall is stateful and may also block outbound connections based on profile settings (Domain, Private, Public). (Exam clue: Tests troubleshooting Windows Defender Firewall in MD-102 and Security+. Know how to use Windows Security and PowerShell to identify blocked ports.)
- **IAM role trust policy misconfiguration causing federation failure** — symptom: Users from an external IdP (e.g., Okta) cannot assume an IAM role in AWS to access resources. The error indicates 'Access Denied' at the role assumption step.. The trust policy of the IAM role does not include the correct external ID, or the IdP's ARN is not properly specified. The role must trust the identity provider's ARN and have conditions like sts:ExternalId. (Exam clue: Tests federation and cross-account access in AWS SAA. Understand trust policies vs. permission policies.)

## Memory tip

Remember BLP for Confidentiality (Leaks Down), Biba for Integrity (Dirt Up). Bell-LaPadula stops the leak, Biba stops the dirt.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/security-model