14.2 Identity & Access Management (IAM), PAM & RBAC
Key Takeaways
- The IAAA model (Identification, Authentication, Authorization, Accounting) forms the sequential governance backbone for all access control systems, requiring unique identity attribution at every stage.
- Multi-Factor Authentication (MFA) requires two or more distinct authentication factors from different categories (Knowledge, Possession, Inherence), whereas contextual attributes (location, time, behavior) provide risk-adaptive step-up authentication.
- Privileged Access Management (PAM) mitigates high-impact insider and lateral movement risks through credential vaulting, automated rotation, Just-in-Time (JIT) ephemeral privilege elevation, and session recording.
- Access control models serve distinct governance needs: DAC relies on data owner discretion, MAC enforces non-discretionary mandatory classification labels, RBAC assigns permissions to organizational job roles, and ABAC evaluates dynamic subject/resource/environmental attributes.
- Zero Trust Architecture (NIST SP 800-207) eliminates implicit trust by enforcing 'Never Trust, Always Verify', requiring continuous session verification, micro-segmentation, and dynamic policy evaluation across all control and data planes.
14.2 Identity & Access Management (IAM), PAM & RBAC
In modern decentralized, cloud-native, and hybrid enterprise environments, the traditional network perimeter has dissolved. Mobile workforces, third-party software-as-a-service (SaaS) platforms, microservice architectures, and multi-cloud deployments mean that network location no longer implies trustworthiness. Consequently, Identity has become the new enterprise security perimeter.
According to ISACA's CRISC Body of Knowledge and COBIT 2019, Identity and Access Management (IAM) is one of the most critical operational risk domains. Flaws in identity governance, excessive user permissions, unmonitored privileged accounts, and weak authentication mechanisms are the primary root causes exploited in over 80% of enterprise data breaches. Implementing robust IAM frameworks, Privileged Access Management (PAM), modern access control models, and Zero Trust Architecture (ZTA) is essential to enforce the fundamental security principles of Least Privilege and Separation of Duties (SoD).
+-----------------------------------------------------------------------------+
| THE IAM GOVERNANCE & ACCESS CONTROL ECOSYSTEM |
| |
| +---------------------------------------------------------------------+ |
| | THE IAAA SEQUENTIAL PIPELINE | |
| | [IDENTIFICATION] --> [AUTHENTICATION] --> [AUTHORIZATION] | |
| | "I am Alice" "Prove it (MFA)" "Can Alice read X?" | |
| | | |
| | v |
| | [ACCOUNTING / AUDIT] |
| | "Log: Alice read X" |
| +---------------------------------------------------------------------+ |
| | |
| v ENFORCEMENT MODELS |
| +---------------------------------------------------------------------+ |
| | ACCESS CONTROL MODELS: | |
| | - DAC (Owner Discretion) - MAC (Security Labels / Lattice) | |
| - RBAC (Role-Based Assignment) - ABAC (Dynamic Attributes / XACML)| |
| +---------------------------------------------------------------------+ |
| | |
| v ELEVATED & ZERO TRUST CONTROLS |
| +---------------------------------------------------------------------+ |
| | - Privileged Access Management (PAM): Vaulting, JIT, Break-Glass | |
| | - Zero Trust Architecture (ZTA): Continuous Verify, Micro-Segment | |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
1. The IAAA Framework: Foundational Access Control Mechanics
Access control operates through a strict sequential pipeline known as IAAA (Identification, Authentication, Authorization, and Accounting). A failure in any upstream phase compromises all downstream governance controls.
+-----------------------------------------------------------------------------+
| THE IAAA SEQUENTIAL WORKFLOW |
| |
| 1. IDENTIFICATION Subject claims an identity (e.g., username, employee |
| ID, smartcard serial, API client ID). |
| |
| 2. AUTHENTICATION Subject proves identity using verified credentials |
| (e.g., password, FIDO2 key, biometric scan). |
| |
| 3. AUTHORIZATION System grants or denies specific access rights to |
| requested resources based on policy (ACL, RBAC, ABAC)|
| |
| 4. ACCOUNTING System logs all actions, modifications, and requests |
| to immutable audit trails for non-repudiation. |
+-----------------------------------------------------------------------------+
Critical Governance Rules for IAAA:
- Individual Attribution: Every human user must possess a unique identifier. Generic shared accounts (e.g.,
admin,root,service) violate basic accountability because audit trails cannot trace an unauthorized command to a specific individual. - Separation of Authentication and Authorization: Proving who you are (Authentication) does not determine what you can do (Authorization). A validly authenticated employee must still be denied access to payroll data unless authorized by explicit business policy.
- Immutable Logging: Accounting records must be protected from tampering, including by administrators, using Write-Once-Read-Many (WORM) storage or real-time forwarding to an isolated Security Information and Event Management (SIEM) repository.
2. Multi-Factor Authentication (MFA): Factors vs. Attributes
A critical distinction on the CRISC examination is differentiating between Canonical Authentication Factors and Contextual Attributes.
+-----------------------------------------------------------------------------+
| AUTHENTICATION FACTORS VS. ATTRIBUTES |
| |
| CANONICAL FACTORS (Must combine 2+ different categories for true MFA): |
| ----------------------------------------------------------------------- |
| [1. KNOWLEDGE] Something You Know: Passwords, PINs, Passphrases. |
| [2. POSSESSION] Something You Have: Hardware tokens (YubiKey), |
| TOTP authenticator app, smartcards, SMS OTP. |
| [3. INHERENCE] Something You Are: Biometrics (Fingerprint, Iris, |
| Facial recognition, Voiceprint). |
| |
| CONTEXTUAL ATTRIBUTES (Environmental signals; NOT standalone factors): |
| ----------------------------------------------------------------------- |
| - Somewhere You Are: Geolocation, IP subnet, GPS coordinates. |
| - Something You Do: Behavioral biometrics (keystroke dynamics, gait). |
| - Temporal Context: Time of day, login velocity (impossible travel). |
+-----------------------------------------------------------------------------+
The MFA Composition Rule:
To qualify as true Multi-Factor Authentication, a system must require two or more credentials from DIFFERENT categories:
- Valid MFA: Password (Knowledge) + Hardware FIDO2 Security Key (Possession).
- Valid MFA: Smartcard (Possession) + Fingerprint Scan (Inherence).
- INVALID MFA (Single-Factor Dual-Instance): Password (Knowledge) + PIN (Knowledge) $\rightarrow$ Both belong to the Knowledge factor. If an attacker keylogs or social engineers the user, both are compromised simultaneously.
MFA Vulnerabilities & Phishing-Resistant Modern Controls:
+-----------------------------------------------------------------------------+
| MFA ATTACK VECTORS & REMEDIATIONS |
| |
| Legacy MFA Weakness Modern Attack Vector Phishing-Resistant|
| ------------------------------ -------------------- ------------------|
| SMS / Voice OTP SIM Swapping, SS7 tap Hardware Token |
| Push Notification Prompts MFA Fatigue / Bombing Number Matching |
| Reverse Proxy Phishing (Evilginx)Session Token Theft FIDO2 / WebAuthn |
+-----------------------------------------------------------------------------+
[!IMPORTANT] NIST SP 800-63-3 Alignment: NIST Digital Identity Guidelines establish three levels of Authenticator Assurance (AAL1 to AAL3). AAL3 mandates cryptographically bound, phishing-resistant hardware authenticators (such as FIDO2/WebAuthn hardware keys). SMS OTP and basic mobile push notifications are classified as vulnerable to adversary-in-the-middle (AiTM) proxy attacks.
3. Access Control Models: DAC, MAC, RBAC, and ABAC
Organizations enforce authorization policies using distinct architectural access control models. The risk practitioner must select the model that aligns with data classification and operational velocity.
+-----------------------------------------------------------------------------+
| ACCESS CONTROL MODELS COMPARISON |
| |
| Model Decision Authority Policy Basis Use Case |
| --------- -------------------- ------------------- --------------- |
| DAC Data / Resource Owner Discretionary ACLs Standard OS file |
| (User level) per object shares, NTFS |
| |
| MAC Central System / OS Security labels vs Military, high- |
| (Non-discretionary) clearance lattice integrity gov. |
| |
| RBAC Enterprise Security Job roles & business Enterprise apps, |
| Administration functions ERP, Salesforce |
| |
| ABAC Dynamic Policy Engine Attributes: Subject, Multi-cloud, |
| (Context-aware) Resource, Action, Env microservices |
+-----------------------------------------------------------------------------+
Detailed Model Exploration:
A. Discretionary Access Control (DAC)
- Mechanics: The creator or owner of an object (e.g., a file or folder) has complete discretion to grant or revoke read, write, and execute permissions to any other user via Access Control Lists (ACLs).
- Risk Profile: High operational risk. DAC leads to privilege creep, unmonitored data exposure, and unauthorized sharing because data owners frequently set loose permissions without security oversight.
B. Mandatory Access Control (MAC)
- Mechanics: Access decisions are enforced strictly by the operating system kernel based on hierarchical classification labels (e.g., Unclassified, Confidential, Secret, Top Secret) assigned to objects, and security clearances assigned to subjects. Users cannot alter or transfer permissions.
- Formal Mathematical Security Models:
- Bell-LaPadula Model (Confidentiality): Enforces "No Read Up (Simple Security Property)" and "No Write Down ( $\star$ -Property)" to prevent unauthorized data leakage.
- Biba Integrity Model (Integrity): Enforces "No Read Down (Simple Integrity Property)" and "No Write Up ( $\star$ -Integrity Property)" to prevent low-integrity data from contaminating high-integrity systems.
C. Role-Based Access Control (RBAC)
- Mechanics: Permissions are associated with specific organizational job roles (e.g.,
Financial_Analyst,DevOps_Engineer,Clinical_Nurse), and users are assigned to roles based on their job duties. When an employee changes departments, removing them from the role instantly revokes all associated permissions. - Governance Challenges:
- Role Explosion: Organizations creating thousands of hyper-granular roles, resulting in unmanageable complexity.
- Privilege Creep: Adding new roles as employees take on projects without revoking prior roles.
D. Attribute-Based Access Control (ABAC)
- Mechanics: Dynamic, context-aware authorization model that evaluates rules combining four attribute categories in real time using the XACML (eXtensible Access Control Markup Language) standard:
- Subject Attributes: Job title, department, security clearance, contractor status.
- Resource Attributes: Data classification (PII, PCI), file owner, creation date.
- Action Attributes: Read, Write, Delete, Approve, Export.
- Environmental Attributes: Time of day, geolocation IP, device compliance status, threat alert level.
- Policy Example: "Allow Doctors (Subject) to Read (Action) Medical Records (Resource) ONLY IF the Doctor is currently on-call at the local hospital facility AND using a compliant managed laptop (Environment)."
4. Privileged Access Management (PAM)
Privileged accounts—such as domain administrators, database root users, cloud IAM admins, and service accounts—represent the highest risk exposure in enterprise IT. Compromise of a single privileged credential enables complete infrastructure takeover, security log deletion, and widespread data destruction.
+-----------------------------------------------------------------------------+
| PRIVILEGED ACCESS MANAGEMENT (PAM) ARCHITECTURE |
| |
| +-------------------+ |
| | PRIVILEGED USER | |
| | (Admin / Engineer)| |
| +---------+---------+ |
| | 1. Requests Access (MFA + Ticket ID) |
| v |
| +---------------------------------------------------------------------+ |
| | PAM SECURE ENTERPRISE VAULT | |
| | | |
| | - Credential Vaulting (Passwords hashed & stored in HSM) | |
| | - Automated Password Rotation (Rotates immediately post-session) | |
| | - Just-in-Time (JIT) Elevation (Time-bounded ephemeral access) | |
| | - Dual-Custody Approval (Four-Eyes Principle for high-tier ops) | |
| +----------------------------------+----------------------------------+ |
| | |
| | 2. Proxies & Records Session |
| v |
| +---------------------------------------------------------------------+ |
| | TARGET PRODUCTION INFRASTRUCTURE | |
| | (Domain Controllers, Production DBs, Cloud IAM, Kubernetes) | |
| +---------------------------------------------------------------------+ |
| | |
| | 3. Full Video / Keystroke Logs |
| v |
| +---------------------------------------------------------------------+ |
| | IMMUTABLE SIEM / AUDIT LOGGING REPOSITORY | |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
Core PAM Capabilities:
- Credential Vaulting & Rotation: Administrators never see or know the raw passwords for root/admin accounts. The PAM vault injects credentials dynamically into proxied sessions and automatically rotates the password upon session termination.
- Just-in-Time (JIT) Elevation: Eliminates dangerous "standing privileges." Administrators hold standard unprivileged accounts day-to-day. When elevated rights are required, the user submits a justification ticket, undergoes approval, and receives ephemeral access granted for a strict time window (e.g., 2 hours), after which permissions automatically expire.
- Session Recording & Real-Time Termination: All administrative terminal sessions (SSH, RDP, Cloud Console) are recorded with full keystroke telemetry. Automated behavioral engines can terminate sessions immediately if suspicious commands (e.g.,
rm -rf /,DROP DATABASE, bulk export) are detected. - Emergency "Break-Glass" Procedures: Pre-configured emergency administrative accounts used only when primary identity providers (e.g., Okta, Azure AD) or network connections fail. Break-glass credentials are split between two senior executives (Dual Custody / M-of-N split knowledge), and their checkout triggers immediate high-priority PagerDuty alerts to executive leadership.
5. Zero Trust Architecture (ZTA) Principles
Codified in NIST SP 800-207, Zero Trust Architecture (ZTA) is an enterprise cybersecurity philosophy predicated on a fundamental operational assumption: The network is hostile, and breaches are inevitable. Zero Trust removes implicit trust based solely on physical or network location.
+-----------------------------------------------------------------------------+
| ZERO TRUST ARCHITECTURE LOGICAL MODEL (NIST SP 800-207) |
| |
| +---------------------------------------------------------------------+ |
| | CONTROL PLANE | |
| | |
| | +--------------------------+ +--------------------------+ |
| | | POLICY ENGINE | <---> | POLICY ADMINISTRATOR | |
| | | (Makes trust decision | | (Issues dynamic access | |
| | | using threat context) | | tokens / credentials) | |
| | +--------------------------+ +--------------------------+ |
| +----------------------------------+----------------------------------+ |
| | |
| ===================================|==================================== |
| v |
| +---------------------------------------------------------------------+ |
| | DATA PLANE | |
| | |
| | [SUBJECT / DEVICE] --> [POLICY ENFORCEMENT POINT] --> [RESOURCE] |
| | (User, laptop, API) (PEP / Identity-Proxy) (App, DB) |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
The Core Pillars of Zero Trust (NIST SP 800-207):
- Never Trust, Always Verify: Every access request—regardless of whether it originates from inside the corporate LAN or an external public network—must be explicitly authenticated, authorized, and encrypted.
- Assume Breach: Architecture is designed with the operational assumption that adversaries already possess an active foothold within internal systems. Lateral movement is blocked through granular Micro-segmentation and strict trust perimeter isolation.
- Verify Explicitly & Continuously: Trust is evaluated dynamically for every single session based on real-time telemetry (user identity, device posture, location, data classification, and behavioral risk score), rather than granting permanent session-long access.
- Apply Least Privilege: Access is strictly limited to the minimal resources necessary using JIT elevation and adaptive ABAC policies.
6. CRISC Exam Traps & Real-World Scenarios
Exam Trap 1: Assuming Role-Based Access Control (RBAC) Prevents Privilege Creep
- The Trap: Candidates assume that deploying RBAC eliminates privilege accumulation across an employee's career.
- The Reality: RBAC only prevents privilege creep if periodic user access recertification reviews are actively conducted. Without mandatory quarterly reviews, users accumulate secondary roles as they transfer across departments.
Exam Trap 2: Believing SMS OTP Qualifies as Phishing-Resistant MFA
- The Trap: An exam scenario asks for the most effective control to defeat adversary-in-the-middle (AiTM) reverse proxy phishing attacks. The candidate selects SMS or mobile push notifications.
- The Reality: SMS and standard push notifications are easily bypassed by reverse proxy frameworks (e.g., Evilginx). FIDO2/WebAuthn hardware tokens cryptographically bind the authentication handshake to the verified domain name, making them truly phishing-resistant.
Exam Trap 3: Confusing DAC with MAC in Regulatory Environments
- The Trap: Choosing DAC for an environment handling national defense secrets or highly regulated medical trials.
- The Reality: DAC allows data owners to grant permissions at will, creating severe data leak risks. Highly regulated environments mandate Mandatory Access Control (MAC) to enforce strict, centrally managed classification lattices that users cannot override.
An enterprise security architect is designing an authentication standard for remote employees accessing sensitive cloud-hosted financial ledgers. To satisfy corporate security policy mandating true Multi-Factor Authentication (MFA), which of the following credential combinations must be deployed?
A global healthcare provider requires an authorization model for its electronic health record (EHR) system that dynamically enforces access rules based on user role, patient consent status, the sensitivity label of the medical data, the geographic location of the clinician, and whether the access occurs during an active emergency shift. Which access control model is specifically designed to evaluate these dynamic multi-variable criteria?
An internal IT risk audit reveals that multiple database administrators possess permanent, unmonitored root administrative credentials to core production databases, creating severe operational and insider fraud risk. Which Privileged Access Management (PAM) architectural control should the risk practitioner recommend to eliminate unmanaged standing privileges?
An enterprise is transitioning its legacy castle-and-moat network security architecture to a Zero Trust Architecture (ZTA) aligned with NIST SP 800-207. Which core operational principle must guide the engineering and risk governance of this new architecture?