6.2 Mandatory, Discretionary, and Role-Based Access Control

Why models matter on an operations exam

Knowledge area 2.4 — Understand and administer access controls — asks you to recognize how authorization is decided, not only that a decision exists. The same file server can be locked down by labels the administrator cannot override (mandatory), by an owner-edited ACL (discretionary), or by job roles (role-based). If you pick the wrong model, you will "fix" a classified-lab leak by making the researcher the owner of the dataset — which is exactly what Mandatory Access Control (MAC) exists to prevent.

This section covers mandatory, discretionary, and role-based access control, including subject-based and object-based RBAC and Privileged Access Management (PAM) as a specialized control for high-power roles. Rule-based and attribute-based models, and the PAM checkout mechanics, continue in 6.3.

Subjects, objects, and operations

Every model has a subject (user, process, service account, AI agent) that requests, an object (file, table, API, virtual LAN, vault secret) that is requested, and an operation (read, write, execute, delete, approve). The model is the rule that says yes or no. Lifecycle (6.1) decides when the subject exists. The model decides each request while it exists.

Mandatory access control

Mandatory Access Control (MAC) is system-enforced. Labels on subjects (clearance, category) and objects (classification, compartment) determine access. The data owner and the local administrator cannot grant an exception that violates the label policy. Need to know is typically a second MAC dimension: even with Secret clearance you do not see every Secret file, only those in compartments you are briefed into.

Operations examples:

• A classified research lab runs Security-Enhanced Linux (SELinux) or a similar mandatory policy in enforcing mode. A scientist who owns a file still cannot chmod it world-readable.
• Military and intelligence networks tag data Confidential / Secret / Top Secret and users with matching clearances and compartments.
• Some commercial systems approximate MAC with data-classification labels in Data Loss Prevention (DLP) or information-rights management that users cannot turn off.

If the stem says the security kernel rejected the owner, you are in MAC. If the stem says the file owner added a coworker, you are not.

Bell-LaPadula versus Biba at conceptual operations level

Two classic MAC models show up as conceptual questions. The SSCP outline does not publish how many items, if any, name these models, and you should not invent a scoring claim. Treat them as operational mnemonics for confidentiality versus integrity lattices.

Bell-LaPadula protects confidentiality:

• Simple security property: no read up. A Secret subject cannot read Top Secret.
• Star property (*-property): no write down. A Top Secret subject cannot write into a Secret or Unclassified file — that would leak.
• Informal ops read: keep secrets from flowing to less-cleared people. A cleared analyst must not paste a Top Secret paragraph into an Unclassified ticket.

Biba protects integrity:

• Simple integrity: no read down. Do not read less-trusted data into a high-integrity process (garbage in).
• Star integrity: no write up. Do not write from a low-integrity subject into a high-integrity object.
• Informal ops read: keep dirty data and untrusted code from contaminating authoritative records. A kiosk process must not write into the payment-switch database.

They pull in opposite directions. Bell-LaPadula stops a high-clearance user from exporting down. Biba stops a low-integrity source from updating a trusted ledger. Real systems that need both confidentiality and integrity use additional controls or hybrid policy; one lattice does not do everything. Clark-Wilson (well-formed transactions and separation of duty on commercial integrity) may appear as contrast in study materials. You administer it as constrained programs and segregation of duties, not as classification labels.

Scenario: need-to-know MAC in a classified lab

You administer workstations in a government contractor lab. Data is labeled Secret//NOFORN. Researchers have Secret clearance but are briefed into different compartments (project A versus project B). A project-A principal investigator asks you to make them the owner of a project-B dataset so they can "share it with the team this afternoon." Under MAC, you cannot. Ownership does not confer the right to relabel or to grant across compartments. The correct path is a formal authorization to brief the investigator into project B, or a sanitization and export review that produces a lower or differently compartmented copy. Granting NTFS Full Control because the investigator is "the customer" is a DAC instinct that fails MAC. It also fails the duty to protect infrastructure and public trust when the data is classified for a reason.

Discretionary access control

Discretionary Access Control (DAC) lets the owner of an object decide who else may access it, usually through an ACL. Windows NTFS permissions, Linux user/group/other bits plus ACLs, and many collaboration-drive "anyone with the link" settings are DAC.

The power and the failure mode are the same: owners are convenient and owners are sloppy.

• A share owner adds Everyone: Modify so a vendor can drop a file.
• A developer runs chmod 777 on a log directory to "fix permissions."
• A physician emails a spreadsheet and the recipient forwards it; each hop is a new discretionary grant the security team never saw.

DAC is appropriate when the organization accepts owner judgment: a personal drive, a team workspace with DLP watching exfiltration, a lab that is not classified. It is a poor fit for regulated need-to-know data unless you wrap it with monitoring, encryption, and policy that owners cannot disable.

Owner grants are the exam keyword. If the stem says the file owner added a coworker, answer DAC. Inherited access-control entries on child folders are still DAC; they are just DAC that nobody remembered.

Role-based access control

Role-Based Access Control (RBAC) grants permissions to roles, and subjects are assigned to roles. Users do not accumulate random object ACLs; they inherit the job's bundle. A new nurse is assigned RN-MedSurg, not two hundred individual chart permissions.

The outline's examples:

• Subject-based RBAC: the role is defined around the actor. "Hospital nurse," "night SOC analyst," "accounts-payable clerk." Subjects (people or services) are assigned those roles. This is the common enterprise directory pattern: role-nurse gets charting; role-coder gets billing codes.
• Object-based RBAC: the role is defined around the resource. "Payroll-share-readers," "firewall-object-admins," "vault-prod-secret-users." You still assign subjects to those roles, but the catalog is resource-centric. Large environments often mix both: a subject role (nurse) plus object roles (ehr-unit-4-west).

RBAC is how hospitals, banks, and most enterprises scale authorization. It is also how they fail, through role explosion.

Role explosion

Role explosion is the failure mode. Every exception becomes a new role: RN-MedSurg-except-nights, RN-MedSurg-plus-pharmacy-for-Jane. After two years you have more roles than people, recertification is impossible, and everyone sits in a custom role that is actually DAC with extra steps.

SSCP operations responses:

• Prefer a small set of standard roles plus time-boxed exceptions in PAM or a ticket, not a new role per person.
• Use attribute-based rules (6.3) for environment conditions such as location and time instead of cloning roles.
• Recertify role definitions as well as membership. A role that still contains "temporary ERP cutover 2021" is a land mine.
• Do not copy an existing user's access as a provisioning shortcut. That clones explosion and is the joiner failure from 6.1 wearing an RBAC badge.

Scenario: RBAC in a hospital EHR versus MAC in the lab

An electronic health record (EHR) is almost never a Bell-LaPadula lattice. Clinicians have jobs (nurse, attending, coder, billing) and locations (unit, clinic). RBAC assigns RN-4West the ability to chart on 4 West patients, with a break-glass path for a code-blue in another unit. That is subject-based RBAC plus a documented emergency exception. Need-to-know still exists as policy — a nurse from another floor should not browse celebrity charts — but enforcement is role membership, audit, and sanction, not a security kernel that prevents the owner from granting.

Contrast the classified lab: a project owner cannot "add a colleague for the afternoon." The hospital can let a manager request RN-4West for a float nurse, because the model is RBAC. Confusing the two is a common exam trap. "Need to know" is a requirement in both worlds; MAC is the model that mechanically prevents owner grants.

The Health Insurance Portability and Accountability Act (HIPAA) minimum-necessary rule is a policy you implement with RBAC and logging, not a reason to claim the EHR is a MAC system. If a stem mentions labels and a kernel the user cannot override, answer MAC. If it mentions job titles and role assignment, answer RBAC.

Privileged Access Management as an RBAC specialist

Privileged Access Management (PAM) is how you handle roles whose blast radius is the environment: Domain Admin, root, cloud Owner, firewall admin, EHR break-glass, and AI agents that can disable accounts. Those are still roles, but standing membership is too dangerous.

At the 6.2 level, remember:

• Privileged roles are RBAC roles with extra controls: vaulted credentials, just-in-time assignment, session recording, dual control.
• Help-desk password-reset roles are privileged relative to a standard user even if they are not Domain Admin.
• PAM does not replace MAC, DAC, or RBAC. It wraps the high-power roles those models create.

Section 6.3 covers vaulting, just-in-time access, recording, and break-glass in operational detail.

Choosing a model — and mixing them

Production networks mix them. The directory is RBAC. The file server may still be DAC underneath. SELinux on the same host is MAC. The jump-host password sits in a PAM vault. The SSCP's job is to know which decision engine answered "yes" when something goes wrong, and not to "fix" a MAC compartment with a DAC owner grant or to "fix" hospital scale with a unique role per nurse.