Authorization Mechanisms

The Model Selection Problem

Every organization faces the same question: who should be allowed to do what, and who gets to decide? The answer to that second part — who decides — is what separates one access control model from another. It is also what the CISSP exam tests more than anything else in Domain 5.

Authorization is not about technology. It is about decision authority. The model you choose determines who holds the power to grant or restrict access — and that choice carries consequences for security, scalability, and operational overhead.

This module covers CISSP objective 5.4: implement and manage authorization mechanisms. The exam expects you to match an access control model to an organizational scenario based on security requirements, regulatory constraints, and operational context — not to configure access control lists on a router.

Discretionary Access Control (DAC)

In DAC, the resource owner decides who can access their resources. The owner has full discretion to grant or revoke permissions.

• Decision authority — The individual resource owner or creator
• Typical implementation — File system permissions on Windows (NTFS ACLs) or Linux (chmod/chown)
• Strength — Flexible and easy for users to manage in small environments
• Weakness — Owners can make poor decisions. A single user sharing a file with the wrong group can create a data exposure that security never sees

DAC is the default model in most commercial operating systems. It works well when users understand classification requirements and the organization tolerates some risk from individual judgment. It fails in environments where data sensitivity demands centralized control — which is why military and government environments moved away from it decades ago.

Exam signal: When a scenario describes an environment where users share files freely and a data leak results from incorrect permissions, DAC is the model in play. The fix usually involves moving to a more restrictive model or adding compensating controls.

Mandatory Access Control (MAC)

In MAC, a central authority — not the resource owner — determines access based on security labels. Every subject (user) receives a clearance level. Every object (resource) receives a classification label. Access is granted only when the subject’s clearance dominates the object’s classification.

• Decision authority — System-enforced policy set by a central security administrator
• Labels and clearances — Subjects have clearances (e.g., Secret); objects have classifications (e.g., Confidential). The system compares them automatically
• Bell-LaPadula — The classic MAC model for confidentiality: “no read up, no write down.” A Secret-cleared user cannot read Top Secret data, and cannot write data to a lower classification level
• Biba — The integrity counterpart: “no read down, no write up.” Prevents contamination of high-integrity data from lower-integrity sources
• Strength — Highest level of access control enforcement. Users cannot override the system’s decisions
• Weakness — Rigid, expensive to administer, and impractical for most commercial environments

MAC is the right model when the cost of unauthorized disclosure is extremely high — national security, military operations, intelligence communities. It is almost never the right answer for a commercial organization unless the scenario specifically involves classified government data or mandated label-based controls.

Need-to-know adds a second dimension to MAC. Even if a user’s clearance dominates the object’s classification, access is denied without a demonstrated need-to-know for that specific information. Clearance is necessary but not sufficient.

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, then assigns users to roles. Users do not receive individual permissions — they inherit them from the roles they hold.

• Decision authority — Centralized role definitions managed by security or IT administration
• How it works — An “Accounts Payable Clerk” role includes permissions to access the payment system, view vendor records, and submit invoices. Anyone assigned that role gets exactly those permissions
• Strength — Scales well in organizations with well-defined job functions. Simplifies onboarding: assign the role, and all needed access follows
• Weakness — Role explosion. As organizations grow and job functions overlap, the number of roles multiplies. Maintaining hundreds of roles can become more complex than managing individual permissions

RBAC is the most common model in enterprise environments. It maps naturally to organizational structure and supports separation of duties by ensuring no single role combines conflicting permissions.

Separation of duties in RBAC: If the “Purchase Requisition” role and the “Purchase Approval” role are defined as mutually exclusive, no user can hold both. The system enforces the control automatically.

Exam signal: When the scenario involves a large organization with defined job functions and the question asks about scalable, manageable access control, RBAC is almost always the answer.

Attribute-Based Access Control (ABAC)

ABAC makes access decisions based on attributes of the subject, object, environment, and requested action. Instead of assigning roles, you define policies that evaluate combinations of attributes at the time of the access request.

• Subject attributes — Department, job title, clearance level, training completion status
• Object attributes — Classification, project code, data type, creation date
• Environment attributes — Time of day, location, device type, network zone, threat level
• Action attributes — Read, write, delete, export

A typical ABAC policy might read: “Allow access when the subject’s department matches the object’s project team AND the request originates from a managed device AND the current time is within business hours.”

• Strength — Extremely granular. Can express policies that RBAC cannot without creating thousands of roles. Handles dynamic conditions like time and location natively
• Weakness — Complex to design, implement, and audit. Policy interactions can create unexpected results. Harder to answer the question “what can user X access?” because the answer depends on context at the moment of request

ABAC is the right model when the access decision depends on context that changes — the user’s location, the sensitivity of the specific record, the current risk posture. It is increasingly common in cloud and zero-trust architectures where static role assignments are insufficient.

Rule-Based Access Control

Rule-based access control applies a set of predefined rules — typically managed by the system administrator — that are evaluated against each access request. The rules are not tied to individual identities or roles but apply uniformly to all subjects.

• Common example — Firewall rules: “Allow traffic from subnet 10.1.0.0/16 to port 443” applies regardless of who the user is
• How it differs from RBAC — Rule-based controls evaluate conditions about the request itself (source, destination, time, protocol). RBAC evaluates the user’s role assignment

Rule-based access control often works alongside other models. A user might be authorized through RBAC to access a system, but a rule-based firewall determines whether the network path is allowed.

Risk-Based and Adaptive Access Control

Risk-based access control (sometimes called adaptive access control) evaluates the risk level of each access request in real time and adjusts the authorization decision accordingly.

• Low-risk request — User logs in from their usual device, at their usual time, from their usual location. Access is granted normally
• Elevated-risk request — Same user logs in from a new country at 3 AM. The system requires step-up authentication or restricts access to read-only
• High-risk request — Multiple anomalous factors detected. Access is denied pending manual verification

This model is a natural extension of ABAC — it uses environmental and behavioral attributes to calculate a risk score, then applies different authorization policies based on that score. It is the foundation of most zero-trust implementations and is increasingly tested on the CISSP exam.

The Access Control Matrix

The access control matrix is a theoretical model that maps every subject to every object with their specific permissions. It is a table where rows represent subjects, columns represent objects, and each cell contains the set of allowed operations.

The matrix itself is a conceptual tool. In practice, it is implemented in two ways:

• Capability tables — Each row of the matrix. A capability table lists all objects a specific subject can access and the permissions they hold. Think of it as the user’s access badge: “User A can read File 1, write File 2, execute Program 3”
• Access Control Lists (ACLs) — Each column of the matrix. An ACL lists all subjects who can access a specific object and their permissions. Think of it as the resource’s guest list: “File 1 can be read by User A, read/written by User B, read by Group C”

The exam tests whether you understand this distinction. Capability tables are subject-focused (what can this user do?). ACLs are object-focused (who can access this resource?).

Policy Enforcement Points

Authorization decisions involve multiple components working together:

• Policy Decision Point (PDP) — The component that evaluates the access request against the policy and returns an allow/deny decision. This is where the logic lives
• Policy Enforcement Point (PEP) — The component that intercepts the access request and enforces the PDP’s decision. A firewall, an API gateway, or a file system permission check all act as PEPs
• Policy Administration Point (PAP) — Where administrators create and manage policies
• Policy Information Point (PIP) — Provides the attribute data (user directory, classification database, threat intelligence feed) that the PDP needs to make its decision

In ABAC and zero-trust architectures, separating these components is essential. The PEP sits at the resource boundary, the PDP evaluates the policy, and the PIP feeds in current attribute data. If any component fails or is bypassed, the authorization model breaks down.

Choosing the Right Model

The exam presents scenarios and expects you to select the appropriate model. Here is the decision logic:

• Small team, user-managed resources, low sensitivity → DAC
• Classified data, government/military, label-based controls mandated → MAC
• Enterprise with defined job functions, need for scalable administration → RBAC
• Context-dependent decisions, cloud/zero-trust, dynamic conditions → ABAC
• Network-level traffic filtering, uniform rules regardless of identity → Rule-based
• Variable risk levels, step-up authentication needed, behavioral analytics → Risk-based/adaptive

Pattern Recognition

Authorization mechanism questions on the CISSP follow these patterns:

• “Which model prevents users from overriding access decisions?” — MAC. The defining feature of mandatory access control is that users cannot change what the system enforces
• “Which model scales best for a large enterprise?” — RBAC. Role-based assignment maps to organizational structure and simplifies user management
• “Which model supports context-dependent decisions?” — ABAC or risk-based. When the scenario includes time, location, or device as factors, look for these models
• “Who decides?” — If the owner decides, it is DAC. If the system enforces policy, it is MAC. If the organization defines roles, it is RBAC. If attributes and policies decide, it is ABAC

Trap Patterns

Watch for these wrong-answer traps:

• “RBAC and ABAC are mutually exclusive” — They are not. Many organizations use RBAC as a baseline and layer ABAC policies on top for finer-grained decisions. The exam may present hybrid scenarios
• “MAC is always more secure than RBAC” — MAC provides stronger enforcement but is not always appropriate. Choosing MAC for a commercial environment where RBAC fits better introduces unnecessary complexity without proportional risk reduction
• “DAC is inherently insecure” — DAC is less restrictive, but it is not insecure by definition. It is the wrong model for high-sensitivity environments, but it is a valid choice in low-risk contexts
• “Rule-based is the same as RBAC” — The names sound similar but the mechanisms are different. RBAC is role-based (identity-centric). Rule-based is condition-centric (evaluate the request attributes against a rule set)

Scenario Practice

Question 1

A defense contractor is building an information system that will process data at multiple classification levels: Unclassified, Confidential, and Secret. Users will have different clearance levels. The system must prevent users from accessing data above their clearance and prevent any mechanism for higher-classified data to flow to lower classification levels.

Which access control model is MOST appropriate?

A. Role-Based Access Control with separation of duties
B. Mandatory Access Control with Bell-LaPadula enforcement
C. Attribute-Based Access Control with classification attributes
D. Discretionary Access Control with strict ACL management

Question 2

A healthcare organization with 5,000 employees needs to control access to its electronic health record (EHR) system. Access requirements vary by clinical role: physicians need full read/write access to patient records, nurses need read access to records for their assigned patients, and billing staff need access to financial fields only. The organization experiences frequent staff turnover and lateral transfers between departments.

Which access control model provides the BEST balance of security and administrative efficiency?

A. Discretionary Access Control managed by department heads
B. Mandatory Access Control with patient data classifications
C. Role-Based Access Control aligned to clinical job functions
D. Rule-based access control using department network segments

Question 3

A financial services firm is deploying a zero-trust architecture. The security team wants access decisions to factor in the user’s device posture, geographic location, time of request, the sensitivity of the data being accessed, and a real-time risk score calculated from behavioral analytics. Static role assignments alone are not sufficient.

Which approach BEST meets these requirements?

A. RBAC with additional firewall rules
B. MAC with security labels on all financial data
C. ABAC combined with risk-based adaptive controls
D. DAC with enhanced logging and monitoring

Key Takeaway

Authorization models are not about memorizing definitions — the exam tests your ability to match the model to the scenario. Ask three questions: Who needs to control access decisions? How dynamic are the access requirements? What is the sensitivity of the data? DAC gives control to owners. MAC gives control to the system. RBAC gives control to organizational role definitions. ABAC gives control to policy evaluated against real-time context. Every exam question about authorization mechanisms is really asking you to identify which of those four answers fits the situation described.