Helpful first: Identity, authentication, authorization, and recovery · Least privilege, defense in depth, and Zero Trust boundaries
Key points
- Contrast DAC (owner discretion/ACLs), MAC (system-enforced clearances + labels), RBAC (job roles), ABAC (multi-attribute policy engine), and Rule-Based access control
- Explain why MAC requires both hierarchical clearance AND compartmentalized Need-to-Know categories
- Classify controls across two axes: Implementation Type (Administrative, Technical/Logical, Physical) and Functional Timing (Preventive, Detective, Corrective, Deterrent, Recovery, Compensating)
Comparing DAC, MAC, RBAC, ABAC, and Rule-Based access control
Every access control system mediates requests from a Subject (an active entity: user, process, or workload token) to perform an operation on an Object (a passive resource: file, database row, API endpoint, or hardware port). The five canonical models differ in who holds the authority to define permissions and how decisions are evaluated.
In Discretionary Access Control (DAC), every object has an owner (typically its creator) who can at their own discretion grant or revoke access to other users via Access Control Lists (ACLs) or Capability Tickets. Standard Windows NTFS and Unix/Linux chmod permissions are DAC. While DAC is easy for collaboration, it has a fundamental architectural weakness: any program or Trojan horse executed by a user inherits that user’s full DAC identity and can silently re-permission or exfiltrate the user’s files.
In Mandatory Access Control (MAC), users have zero discretion to share files or modify labels. The operating system kernel (such as SELinux or a military multilevel system) assigns a security clearance to every Subject and a classification label to every Object. Access is permitted only when the kernel verifies both Hierarchical Dominance (the subject’s clearance is greater than or equal to the object’s sensitivity) AND Compartmentalized Need-to-Know (the subject’s profile includes every formal compartment tag, such as ORBITAL-CRYPTO, attached to the object).
| Model | Who sets policy & how it evaluates | Best use case and primary limitation |
|---|---|---|
| DAC (Discretionary) | Resource owner grants rights to subjects via ACLs. | Peer file sharing; weak against Trojan horse malware and hard to audit at enterprise scale. |
| MAC (Mandatory / Lattice) | System/Administrator assigns immutable Clearance + Compartment labels. | Classified defense and SELinux containment; rigid and high administrative overhead. |
| RBAC (Role-Based) | Permissions bind to job Roles; users bind to Roles (supports role hierarchy). | Enterprise workforce IAM; can suffer "role explosion" if context rules are baked into role names. |
| ABAC (Attribute-Based) | Policy engine evaluates Subject, Object, Action, and Environment attributes. | Zero-trust cloud APIs and dynamic context gates; requires clean attribute telemetry. |
| Rule-Based (RuBAC) | Administrator defines global IF/THEN rules applied to all traffic. | Network firewall ACLs and router filters (often combined with RBAC/ABAC). |
From RBAC role explosion to ABAC policy architecture (PEP, PDP, PIP, PAP)
Role-Based Access Control (RBAC, Non-Discretionary) groups permissions into named business roles (such as SOC_Tier1, Flight_Director, Billing_Auditor). Instead of granting 40 individual permissions to a new hire, administrators assign the user to one role. However, when access depends on dynamic context ("Allow propulsion engineers to approve thruster burns only from corporate-managed laptops during an active launch window from a U.S. ground station"), pure RBAC suffers from Role Explosion - forcing administrators to create hundreds of combinatorial roles.
Attribute-Based Access Control (ABAC, standardized in NIST SP 800-162 and OASIS XACML) solves role explosion by evaluating policies across four sets of attributes at runtime: Subject attributes (job title, clearance, department), Object/Resource attributes (classification tag, project owner, data type), Action attributes (read, approve, delete), and Environment/Context attributes (time of day, device health posture, network location, threat level).
Under the XACML / Zero Trust policy architecture (NIST SP 800-207), four components cooperate on every request: the Policy Administration Point (PAP, where architects author policy), the Policy Information Point (PIP, which fetches external attributes like EDR health or HR status), the Policy Decision Point (PDP, the brain that evaluates attributes against policy and outputs Permit or Deny), and the Policy Enforcement Point (PEP, the API gateway or proxy on the data path that enforces the PDP’s decision).
The two-axis control matrix: Type vs Functional Timing
Across all CISSP domains, safeguards are classified along two orthogonal axes: Implementation Type (Administrative/Managerial, Technical/Logical, and Physical) and Functional Timing relative to an incident.
Before an event occurs, Deterrent controls discourage a potential attacker (warning banners, visible cameras, prosecution notices) and Preventive controls actively stop the unauthorized action (firewalls, MFA, mantraps, IPS, encryption). During or immediately after an event, Detective controls discover and alert on activity (IDS, SIEM correlation, audit log review, motion sensors, mandatory vacations).
After an event is detected, Corrective controls contain damage and fix the immediate vulnerability (EDR host isolation, patching, killing a rogue process, restoring a configuration), while Recovery controls restore full business operations to normal (failing over to a warm site, restoring databases from backups). Finally, a Compensating control is an alternative safeguard deployed when a primary control is temporarily infeasible.
CHECK YOUR JUDGMENT