Access Control Models (RBAC, DAC, MAC)

Why Access Control Models Matter
Access control is the mechanism that decides who can do what to which resource. For the CSSLP, it sits inside the Secure Software Implementation domain because developers must correctly enforce authorization in code, not just rely on perimeter defenses. Broken access control is consistently the number one category in the OWASP Top 10, and most real-world breaches involve a subject accessing something they should not. Choosing and implementing the right model (RBAC, DAC, MAC, or a hybrid such as ABAC) determines whether an application can enforce least privilege, separation of duties, and defense in depth. Exam questions frequently test whether you can match a business scenario to the correct model and recognize the security trade-offs of each.

Core Terminology
Subject – the active entity requesting access (user, process, service).
Object – the passive resource being accessed (file, database row, API endpoint).
Access right / permission – the operation allowed (read, write, execute, delete).
Reference monitor – the conceptual component that mediates every access; it must be tamper-proof, always invoked, and small enough to verify.
Least privilege – grant only the access needed to perform a task.
Separation of duties – no single subject should be able to complete a sensitive transaction alone.

Discretionary Access Control (DAC)
What it is: The owner of an object decides who may access it. Access is "at the discretion" of the owner.
How it works: Typically implemented with Access Control Lists (ACLs) attached to each object, or capability lists attached to subjects. The access control matrix is the theoretical foundation: rows are subjects, columns are objects, cells hold permissions. Unix/Linux file permissions (owner/group/other with rwx) and Windows NTFS ACLs are classic DAC examples.
Strengths: Flexible, easy to understand, low administrative overhead for small systems, supports collaboration.
Weaknesses: Owners can grant access carelessly; permissions proliferate; vulnerable to Trojan horse attacks because a malicious program running with a user's rights can copy data and grant others access; difficult to audit at scale; no central policy enforcement.
Keywords on the exam: owner decides, ACL, identity-based, flexible, Trojan horse risk, Windows/Unix file permissions.

Mandatory Access Control (MAC)
What it is: A central authority (the system/security administrator) defines policy, and users cannot override it. Access is based on security labels assigned to both subjects (clearances) and objects (classifications).
How it works: Each object carries a sensitivity label (e.g., Top Secret, Secret, Confidential, Unclassified) and often categories or compartments. Each subject has a clearance. The reference monitor compares labels using formal rules. Models you must know:
• Bell-LaPadula (confidentiality): Simple Security Property = no read up; *-Property (star) = no write down. Remembered as "no read up, no write down." Protects secrecy.
• Biba (integrity): Simple Integrity = no read down; * Integrity = no write up. Remembered as "no read down, no write up." Protects data from corruption by lower-integrity sources.
• Clark-Wilson (integrity, commercial): uses well-formed transactions, constrained data items, and separation of duties; subjects access data only through trusted programs (access triple: subject–program–object).
• Brewer-Nash / Chinese Wall: dynamic rules preventing conflicts of interest; once you access one competitor's data you are blocked from the other's.
Implementations include SELinux, AppArmor, Windows Mandatory Integrity Control, and Trusted Solaris.
Strengths: Highest assurance, resists Trojan horses and user error, enforces organization-wide policy, strong auditability.
Weaknesses: Rigid, expensive to administer, poor usability, labeling every object is labor-intensive, not suited to dynamic collaborative environments.
Keywords on the exam: labels, clearance, classification, military/government, system-enforced, cannot be overridden by users, Bell-LaPadula, Biba, SELinux.

Role-Based Access Control (RBAC)
What it is: Permissions are assigned to roles, and users are assigned to roles. Access is determined by the subject's role(s), not individual identity.
How it works: Defined by the NIST RBAC standard (ANSI INCITS 359). Levels include Core RBAC (users, roles, permissions, sessions), Hierarchical RBAC (senior roles inherit junior roles' permissions), and Constrained RBAC (static and dynamic separation of duties). A user activates a subset of roles in a session. In applications, RBAC is implemented through role claims in tokens, role tables in a database, annotations such as @RolesAllowed, or policy middleware.
Strengths: Scales well, simplifies administration (change the role, not every user), naturally supports least privilege and separation of duties, maps cleanly to organizational structure, eases onboarding/offboarding and audit.
Weaknesses: "Role explosion" when too many fine-grained roles are created; does not natively account for context such as time, location, or data attributes; roles must be carefully engineered.
Keywords on the exam: job function, roles, enterprise/commercial, scalable administration, separation of duties, role hierarchy, NIST model.

Related Models You May See
Attribute-Based Access Control (ABAC): decisions based on attributes of subject, object, action, and environment evaluated against policies, often expressed in XACML. Most fine-grained and context-aware; solves role explosion but is complex to design. Components: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP), Policy Administration Point (PAP).
Rule-Based Access Control: global rules apply to all subjects (e.g., firewall rules, time-of-day restrictions). Sometimes confused with RBAC—watch the wording; "rule-based" is often classified as a form of MAC because users cannot change the rules.
Non-discretionary access control: an umbrella term for any model where a central authority, not the owner, controls access (MAC, RBAC, rule-based).

Secure Implementation Guidance for Developers
• Enforce authorization on the server side for every request; never trust client-side checks or hidden UI elements.
• Deny by default; fail closed when a decision cannot be made.
• Centralize access control logic in a single reusable component rather than scattering checks through code.
• Validate object-level authorization to prevent Insecure Direct Object Reference (IDOR)—confirm the subject may access this specific record, not just this type of record.
• Use complete mediation: check access on every call, not only at login.
• Log authorization decisions, especially denials, for monitoring and forensics.
• Review roles and permissions periodically (recertification) to prevent privilege creep.
• Do not hard-code roles or permissions in code; externalize policy so it can change without redeployment.

Quick Comparison
Who decides? DAC: owner. MAC: system/central authority via labels. RBAC: administrator via roles.
Basis of decision: DAC: identity and ACL. MAC: clearance vs. classification. RBAC: job function.
Typical environment: DAC: personal/small systems, general OS files. MAC: military, intelligence, high-security. RBAC: enterprises, business applications.
Flexibility vs. security: DAC most flexible/least secure; MAC least flexible/most secure; RBAC balanced.

Exam Tips: Answering Questions on Access Control Models (RBAC, DAC, MAC)
1. Hunt for the deciding keyword. "Owner" or "ACL" points to DAC. "Label," "clearance," "classification," or "cannot be changed by the user" points to MAC. "Job function," "department," or "role" points to RBAC. "Context," "attributes," "time of day," or "fine-grained policy" points to ABAC.
2. Memorize the mnemonics. Bell-LaPadula is confidentiality: "no read up, no write down." Biba is integrity: "no read down, no write up" (the exact opposite). If a question asks which model prevents a lower-clearance user from reading higher-classified data, the answer is Bell-LaPadula's simple security property.
3. Match the environment. Government, military, or "highest level of assurance" scenarios want MAC. Large commercial organizations with many employees changing positions want RBAC. Small teams or personal file sharing want DAC.
4. Know the weaknesses. If a question describes a Trojan horse leaking data or users over-sharing, the model in play is DAC. If it describes administrative burden and rigidity, it is MAC. If it describes too many roles to manage, it is RBAC role explosion, and the fix is typically ABAC or role hierarchy.
5. Distinguish rule-based from role-based. Read carefully; "rule" and "role" differ by one letter. Rule-based uses global conditions (firewalls, time restrictions); role-based uses job function.
6. Favor least privilege and separation of duties. When asked for the best way to reduce fraud or insider risk in an application, look for the answer that enforces separation of duties, which RBAC supports directly through constrained roles.
7. Remember "non-discretionary" is a category, not a model. Both MAC and RBAC are non-discretionary because the owner does not decide.
8. For implementation questions, choose server-side, centralized, deny-by-default. Answers that rely on hiding buttons, client-side validation, or security through obscurity are wrong. The correct choice always enforces authorization on every request at the server through a reference-monitor-style component.
9. Eliminate extremes. When two answers seem plausible, the CSSLP generally prefers the option that is scalable, auditable, and policy-driven over the one that is merely convenient.
10. Read the question stem for "most" or "best." Several models may technically work; select the one that most precisely fits the scenario's defining characteristic rather than one that merely could be used.

Sample Question Walkthrough
A hospital application must ensure nurses can view patient charts only in their own ward and only during their shift. Which model best fits? Roles alone (nurse) are insufficient because the decision also depends on ward and time—environmental and object attributes. The best answer is ABAC. If ABAC is not offered, RBAC with constraints is the next best choice. DAC is wrong because patients or clinicians should not individually decide sharing; MAC is wrong because labels do not naturally express shift timing.

Summary
DAC gives control to owners and is flexible but weak. MAC gives control to the system via labels and is strong but rigid, with Bell-LaPadula protecting confidentiality and Biba protecting integrity. RBAC assigns permissions to roles for scalable enterprise administration and supports least privilege and separation of duties. ABAC extends these with contextual attributes. In code, always enforce access decisions server-side, centrally, on every request, and deny by default. Master the keywords and mnemonics and you will answer the vast majority of CSSLP access control questions with confidence.