📖 Report📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 97 · Tricks

Access Controls — Exam Tricks

Four high-yield patterns: the MAC keyword triggers (government, labels, cannot change), the RBAC keyword (implicit group rights), the ABAC keyword (multiple simultaneous attributes), and the Rule-based vs. RBAC distinction the exam exploits repeatedly.

Trick 1 MAC — Three Keywords That Instantly Identify It

The exam will describe MAC in a scenario without naming it. Three keywords trigger MAC as the answer:

  • Government / military / classified — MAC is the access control model for government/military environments. Any scenario involving classified data, security clearances, or government classification labels = MAC.
  • Classification labels (Confidential, Secret, Top Secret) — the presence of these specific terms in a scenario = MAC. No other model uses these labels.
  • “Users cannot change permissions/labels” — the defining operational characteristic of MAC is that the OS enforces all decisions and users have zero discretion. If the scenario says users are prevented from modifying access controls, the model is MAC.

Common distractors to reject:

  • “The administrator assigns users to groups” — this sounds like MAC but is actually RBAC. MAC uses classification label comparison, not group membership.
  • “A Top Secret user can read a Secret file” — this IS MAC behavior (clearance level ≥ classification level = access granted).
Rule: Government + labels + cannot change = MAC. The OS enforces. Users have zero discretion. No other model uses Top Secret/Secret/Confidential classification levels.
Trick 2 RBAC vs. Rule-Based — WHO vs. CONDITIONS

This is the most commonly exploited confusion on the exam. Both RBAC and rule-based access control are "role" and "rule" based — candidates confuse them constantly. The distinction is simple:

  • RBAC (Role-Based) — access determined by who you are (your role/group membership). A Finance employee gets Finance access. A physician gets patient record access. The decision is membership-based.
  • Rule-Based — access determined by conditions being met (time, IP address, day of week, device type). The system evaluates rules in an ACL. Access requires the condition to be true, not a particular role.

Exam trigger phrases:

  • “Group membership grants access” or “Active Directory security group” → RBAC
  • “Access only from IP range X” or “only between hours Y” or “only on weekdays” → Rule-based
  • “Firewall ACL” → Rule-based (ACLs are a rule-based mechanism)

They can coexist: A user must be in the Finance RBAC group AND connect from the corporate IP range (rule-based) to access the finance system. Real systems often combine both.

Rule: RBAC = group membership (WHO). Rule-based = ACL conditions (WHEN/WHERE/HOW). If the scenario mentions groups/roles = RBAC. If it mentions time/IP/conditions = Rule-based.
Trick 3 ABAC — Look for Multiple Simultaneous Attribute Categories

The exam signals ABAC by describing multiple different categories of attributes all being evaluated at the same time. Look for sentences that combine:

  • Something about the USER (role, department, clearance) = subject attribute
  • Something about the RESOURCE (type, classification, sensitivity) = object attribute
  • Something about the CONTEXT (time, network, location, device) = environment attribute
  • Something about the OPERATION (read, write, delete, share) = action attribute

Signal phrases:

  • “Access changes depending on whether the user is on VPN or home Wi-Fi” → environment attribute = ABAC
  • “The system evaluates role, time of day, network, and the specific operation being performed” → multi-category = ABAC
  • “Zero-trust architecture” → always ABAC (zero-trust requires context-aware, multi-attribute access decisions)
  • “Context-aware” or “next-generation access control” → ABAC

ABAC vs. Rule-based distinction: Rule-based typically evaluates one or two conditions (IP range, time). ABAC evaluates a full policy combining attributes from multiple categories simultaneously. If more than two attribute types are mentioned, lean toward ABAC.

Rule: Multiple attribute categories (subject + object + environment + action) evaluated simultaneously = ABAC. Zero-trust = ABAC. One or two conditions = rule-based.
Trick 4 DAC Weakness — Always “User Makes Bad Decisions”

Every DAC weakness question has the same answer structure: security failed because the owner made a poor access decision. Identify DAC weakness scenarios by these patterns:

  • “An employee shared the folder with a colleague they trusted” → DAC — the owner chose to share
  • “The user granted another department access to their files without IT approval” → DAC — no oversight of owner decisions
  • “The file creator set permissions to allow everyone to read” → DAC — owner set overly permissive ACL
  • “The employee mistakenly granted access to the wrong person” → DAC — owner error with no safety net

The fix the exam expects: switching from DAC to MAC removes owner discretion entirely. Under MAC, the employee cannot share the file even if they want to — only the admin can change access controls.

Remember: DAC is “discretionary” precisely because access is at the owner's discretion. The entire weakness is that the model depends on discretion being used correctly.

Rule: DAC weakness = owner had discretion and used it badly (or was manipulated into using it). The solution = MAC (remove discretion from users). Never RBAC or ABAC as the answer to a DAC weakness question.
Practice Scenarios
Scenario A: A government contractor operates three separate computing environments: (1) an internal collaboration system where employees create and manage their own shared project folders, granting access to colleagues as needed; (2) a classified system for processing government contracts where data is marked Confidential or Secret and administrators assign clearance levels to personnel; (3) a corporate network system where employees are added to departmental groups (Engineering, Finance, Legal) and receive the access rights of those groups automatically. Identify the access control model for each environment and explain the key characteristic that determines the identification.
Answer: Environment 1 — collaboration system with employee-managed folders: Discretionary Access Control (DAC). The key characteristic is that the creator/owner controls who can access their resources. Employees grant access to colleagues without administrator involvement. Security depends entirely on each employee's access decisions. The risk is that employees may share sensitive project data with unauthorized colleagues without realizing the sensitivity. Environment 2 — classified government system: Mandatory Access Control (MAC). The key characteristics are: (1) data has classification labels (Confidential, Secret) assigned by administrators; (2) users have clearance levels assigned by administrators; (3) the OS enforces access based on label vs. clearance comparison; (4) users cannot modify classification labels even on data they created. This is the model used for all government classified information systems. A Secret-cleared employee can access Confidential data but not data classified above their clearance. Environment 3 — departmental group membership system: Role-Based Access Control (RBAC). The key characteristic is group membership granting implicit access rights. Being added to the Engineering group automatically grants all Engineering resource access without individual permission grants for each resource. Being added to Finance grants Finance access. The administrator manages group membership and group permissions; users do not manage their own access.
Scenario B: A hospital CISO wants to implement access to electronic health records (EHR) using the most sophisticated and appropriate model. Requirements: physicians should only access records for their own patients; access should only be permitted from hospital-issued devices on the hospital network or VPN; read access should be granted during business hours, but emergency read access should be available 24/7 for on-call physicians; write access should only be allowed during business hours; and administrative staff should only access the billing fields, not clinical notes. Can RBAC meet all these requirements alone? Which model is needed, and how would a policy statement look?
Answer: RBAC alone cannot meet all these requirements. RBAC can distinguish between physician and administrative staff roles, but it cannot natively evaluate which specific patients are assigned to a physician (object attribute), what time it is (environment attribute), whether the device is hospital-issued (environment attribute), whether the user is on VPN (environment attribute), or whether the operation is read vs. write (action attribute). RBAC would either grant all physicians access to all patient records (too broad) or require individually configured permissions per physician per patient (operationally impossible). The model needed is ABAC (Attribute-Based Access Control). ABAC evaluates all required attribute categories simultaneously. Sample ABAC policy statements: Physician read access: GRANT if subject.role = physician AND subject.assigned_patients includes object.patient_id AND environment.device = hospital_issued AND (environment.network = hospital OR environment.network = VPN) AND action = read. Physician write access: GRANT if subject.role = physician AND subject.assigned_patients includes object.patient_id AND environment.device = hospital_issued AND (environment.network = hospital OR environment.network = VPN) AND action = write AND environment.time between 07:00-20:00. On-call emergency read: GRANT if subject.role = physician AND subject.oncall_status = true AND environment.device = hospital_issued AND action = read (overrides time restriction). Administrative staff: GRANT if subject.role = admin_staff AND object.field_type = billing AND action = read AND environment.network = hospital. These policies express exactly the business requirements the CISO described, with fine-grained context-aware decisions that no other model can implement with the same precision.
Scenario C: A security analyst reviews an incident report. An employee in the Accounts Payable department was socially engineered via email to share their workstation's shared folder with an attacker. The attacker accessed financial data. Another employee in the same department noticed the intruder in their shared folder and attempted to revoke the access, but the attacker had already shared the folder further with an external account. What access control weakness does this illustrate, and what model change would prevent it?
Answer: This illustrates two classic DAC weaknesses: The first weakness is that DAC allows the resource owner to grant access to anyone, including being socially engineered into granting access to an attacker. Under DAC, the employee's permission to share their folder is the vulnerability. The attacker exploited the owner's discretion. The second weakness is that once access is granted in DAC, the new grantee may themselves be able to share the resource further (depending on whether share permissions were included). The attacker gaining the ability to re-share demonstrates how DAC access can propagate in ways the original owner did not intend. Model change to prevent this: Switch financial data to MAC. Under MAC, the Accounts Payable employee cannot share the financial data folder even if they want to — classification labels on the financial data can only be changed by administrators, and only users with the appropriate clearance can access classified financial resources. Even if the employee is socially engineered and attempts to share the resource, the OS will reject the action because the employee does not have administrative authority over the classification label. Additionally, supplementing with ABAC could add network-based restrictions (financial data accessible only from the corporate network, not via remote sharing), time restrictions (only during business hours), and action restrictions (prevent external sharing entirely as an allowed action). The combination of MAC for classification enforcement and ABAC for contextual access control provides the strongest defense against this attack pattern.