6.2.2. ABAC and Risk-Based Access Control

💡 First Principle: Authentication answers "who are you?"; authorization answers "what are you allowed to do?" These are distinct operations. A user can be successfully authenticated (identity confirmed) and still be denied access (not authorized for the requested resource). Access control models define the rule system used to make authorization decisions — and the right model depends on the organization's structure, the sensitivity of resources, and how dynamically access needs change.

The four main access control models:

DAC (Discretionary Access Control):

• Resource owners control access to their own resources
• Flexible: owner can grant/revoke access to anyone they choose
• Weakness: user error can inadvertently share sensitive resources; malware running as the user inherits the user's access rights
• Example: Windows NTFS permissions, Unix file permissions (chmod)

MAC (Mandatory Access Control):

• Access decisions made by the system based on labels (classifications), not by resource owners
• Subjects have clearance levels; objects have classification labels; access granted only when clearance ≥ classification
• Based on Bell-LaPadula model (confidentiality) or Biba model (integrity)
• Example: SELinux, military classified systems
• Strength: prevents user error from leaking classified data; enforces classification policy

RBAC (Role-Based Access Control):

• Access granted based on job role, not individual identity
• Users are assigned to roles; roles are assigned to permissions; permissions to resources
• Reduces administration: change role definition once, all role members get updated permissions
• Example: "Payroll Processor" role has access to payroll system; all users in that role inherit access
• Supports separation of duties (no single role has conflicting permissions)

ABAC (Attribute-Based Access Control):

• Access decisions based on multiple attributes: user attributes (department, clearance, location), resource attributes (classification, owner, type), environment attributes (time of day, network location, device posture)
• Most flexible: "Grant access if user.department = Finance AND resource.type = BudgetReport AND environment.device = managed AND environment.time = BusinessHours"
• More complex to implement and audit; requires accurate attribute maintenance
• Example: Zero Trust access policies, cloud IAM (AWS IAM with conditions)

Rule-Based Access Control:

• Access governed by administrator-defined rules, not user/object attributes
• Example: "All traffic from subnet 10.1.0.0/24 to port 443 is allowed" (firewall rules)
• Less flexible than ABAC; rules applied uniformly regardless of user attributes

Comparison:

Privileged Access Management (PAM): PAM is the discipline of controlling, monitoring, and auditing privileged (administrative) access — the highest-risk identity category because privileged accounts can bypass normal controls.

PAM components:

• Just-in-time (JIT) access: Privileged access granted for a specific session, then automatically revoked. No persistent admin rights.
• Session recording: All privileged sessions recorded for audit; session playback for forensic investigation.
• Credential vaulting: Administrative passwords stored in secure vault, checked out for use, rotated automatically after each use.
• Privileged identity management (PIM): Manage privileged roles in Azure AD/Active Directory — time-bound, approval-required role activation.

Why PAM matters beyond passwords: The majority of major breaches involve privilege escalation — attackers compromise a standard account, then move to a privileged account to achieve their objective. PAM closes the window between initial compromise and privilege escalation by eliminating persistent privileged credentials. If privileged credentials don't exist until they're needed, they can't be stolen in advance.

Zero Trust Architecture and IAM:

Zero Trust rejects the implicit trust model of perimeter-based security — the assumption that users inside the network are trustworthy. Instead, every access request is evaluated on its own merits regardless of network location.

The IAM implications of Zero Trust are substantial:

The five Zero Trust IAM controls:

1. Verify explicitly — Authenticate and authorize on every request using all available context: identity, location, device health, service or workload, data classification, and anomaly signals.
2. Use least privilege access — Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive policies, and data protection.
3. Assume breach — Minimize blast radius by segmenting access at the resource level. Assume the attacker is already inside — make lateral movement as hard as possible.
4. Continuous validation — Revalidate trust throughout a session, not just at login. Device posture change, location anomaly, or unusual access pattern should trigger step-up authentication or session termination.
5. Comprehensive logging — All access attempts (successful and denied) logged for detection and forensics.

⚠️ Exam Trap: Zero Trust is an architecture principle, not a product. Vendors market products as "Zero Trust" but implementing Zero Trust requires organizational change across IAM, networking, endpoint, and data security. A single product purchase does not constitute a Zero Trust architecture.

⚠️ Exam Trap: RBAC reduces administration overhead, but role explosion — the proliferation of overly specific roles that essentially map one-to-one with users — eliminates this benefit. If an organization has 200 employees and 180 unique roles, they don't have role-based access; they have individual access with extra steps. Proper RBAC requires periodic role mining and consolidation.

Reflection Question: A hospital has implemented RBAC with 847 distinct roles for 2,200 employees. A new CISO argues this is not real RBAC. What is the CISO identifying as the problem, what metric would you use to diagnose role explosion severity, and what process would you use to consolidate roles without disrupting clinical operations?