📊 Your Learning Progress 0%
01

The AAA Framework

The Security Brain — Foundation of all identity systems

🧠 Understanding the Security Brain

Every time you log into any system—whether it's your company email, a cloud application, or a secure server—the AAA Framework is working behind the scenes. Think of it as the "Security Brain" that answers three critical questions: Who are you? What are you allowed to do? What did you do?

🆔

Identification

Definition: The process of claiming an identity within a system. This is simply stating "I am [username]" — no proof required yet.

Real-World Examples
  • Username: [email protected]
  • Employee ID: EMP-12345
  • Badge number: 4056
  • Smart card serial number
  • SSH key fingerprint
Why This Matters

When you enter your username, the system doesn't know if you're actually that person. You're just claiming an identity. Attackers exploit this by discovering valid usernames through enumeration attacks.

🛡️ Mitigation Controls
  • Implement generic error messages ("Invalid credentials" vs "User not found")
  • Use rate limiting on login attempts to prevent username enumeration
  • Consider email-based identifiers over predictable usernames
  • Log all identification attempts for forensic analysis
  • Implement CAPTCHA after failed attempts
🔑

Authentication

Definition: The process of proving the claimed identity is valid. This answers "Can you prove you are who you say you are?"

Authentication Factors
  • Something you KNOW (password, PIN, security question)
  • Something you HAVE (phone, hardware token, smart card)
  • Something you ARE (fingerprint, face, iris)
  • Somewhere you ARE (geolocation, IP address)
  • Something you DO (typing pattern, behavior)
Enterprise Context

Modern enterprises require Multi-Factor Authentication (MFA) combining 2+ factors from different categories. A password + security question is NOT true MFA because both are "something you know."

🛡️ Mitigation Controls
  • Enforce MFA for all privileged accounts (no exceptions)
  • Implement phishing-resistant MFA (FIDO2, hardware keys)
  • Use adaptive/risk-based authentication
  • Set password complexity and rotation policies
  • Implement account lockout after X failed attempts
  • Deploy passwordless authentication where possible
✅

Authorization

Definition: Determining what actions a verified identity is permitted to perform. This answers "Now that I know who you are, what can you do?"

Authorization Examples
  • Read access to production database
  • Write access to shared folders
  • Execute permissions on scripts
  • Approval authority for expenses up to $10,000
  • Admin rights to specific applications
The Critical Distinction

Authentication confirms IDENTITY. Authorization defines PERMISSIONS. Many breaches occur because systems authenticate users correctly but grant excessive permissions (authorization failures).

🛡️ Mitigation Controls
  • Implement Role-Based Access Control (RBAC)
  • Conduct quarterly access reviews
  • Apply Least Privilege principle religiously
  • Use Attribute-Based Access Control (ABAC) for complex scenarios
  • Implement Just-In-Time (JIT) access for privileged operations
  • Document all authorization decisions
📋

Accounting (Auditing)

Definition: Recording all identity-related activities for compliance, forensics, and security monitoring. This answers "What did they do and when?"

What Gets Logged
  • Login success/failure events with timestamps
  • Resource access attempts (granted and denied)
  • Privilege escalation events
  • Configuration changes
  • Session duration and termination
Compliance Requirement

Regulations like SOX, HIPAA, PCI-DSS, and GDPR mandate specific audit logging requirements. Without proper accounting, you cannot prove compliance or investigate security incidents.

🛡️ Mitigation Controls
  • Centralize logs in SIEM (Splunk, ELK, QRadar)
  • Implement tamper-evident logging
  • Set log retention policies per compliance requirements
  • Create alerts for anomalous behavior patterns
  • Ensure logs include WHO, WHAT, WHEN, WHERE, HOW
  • Protect log integrity with write-once storage

📊 AAA Framework Flow Diagram

▼
AAA Flow
┌─────────────────────────────────────────────────────────────────────────┐ │ AAA FRAMEWORK FLOW │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ USER │───────▶│ IDENTIFICATION│───────▶│AUTHENTICATION│ │ │ │ Requests │ │ "Who are you?"│ │ "Prove it!" │ │ │ │ Access │ │ │ │ │ │ │ └──────────┘ │ Username │ │ Password │ │ │ │ Employee ID │ │ MFA Token │ │ │ │ Badge Number │ │ Biometric │ │ │ └──────────────┘ └──────┬───────┘ │ │ │ │ │ ┌────────────┴────────────┐ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐│ │ │ SUCCESS │ │ FAILURE ││ │ │ │ │ ││ │ └────┬─────┘ │ ● Lock ││ │ │ │ ● Log ││ │ ▼ │ ● Alert ││ │ ┌──────────────────┐ └──────────┘│ │ │ AUTHORIZATION │ │ │ │ "What can you do?"│ │ │ │ │ │ │ │ ● Check roles │ │ │ │ ● Verify perms │ │ │ │ ● Apply policies │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌───────────────┴───────────────┐ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ │ │ │ GRANTED │ │ DENIED │ │ │ │ │ │ │ │ │ │ Access │ │ ● Log │ │ │ │ Resource │ │ ● Alert │ │ │ └────┬─────┘ │ ● Review │ │ │ │ └──────────┘ │ │ ▼ │ │ ┌─────────────────┐ │ │ │ ACCOUNTING │ │ │ │ "Record it all" │ │ │ │ │ │ │ │ ● WHO accessed │ │ │ │ ● WHAT resource │ │ │ │ ● WHEN (time) │ │ │ │ ● WHERE (IP) │ │ │ │ ● HOW (method) │ │ │ └─────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────────────┘

💡 Why All Four Components Matter

Remove any one component and your security crumbles:

  • No Identification: System can't distinguish between users
  • No Authentication: Anyone can claim to be anyone
  • No Authorization: Authenticated users can access everything
  • No Accounting: No visibility into who did what (compliance failures)

✅ Section 1 Learning Checklist

02

Core Security Principles

The 7 foundational principles that guide all IAM decisions

🎯 The Guiding Principles

These principles aren't just theoretical — they're used daily by IAM professionals to make access decisions, design policies, and justify security controls to stakeholders. Master these, and you'll speak the language of enterprise security.

🔒

Least Privilege

Definition: Users should have only the minimum permissions necessary to perform their job functions — nothing more, nothing less.

Application Examples
  • Developer has read access to prod, write to dev only
  • Service accounts have single-purpose permissions
  • Admin rights granted temporarily, not permanently
  • Applications run with minimal OS privileges
Real-World Impact

The 2020 SolarWinds breach spread because compromised accounts had excessive privileges. If those accounts had least privilege, lateral movement would have been significantly limited.

🛡️ Implementation Controls
  • Conduct annual privilege reviews with manager attestation
  • Implement Just-In-Time (JIT) access elevation
  • Remove admin rights from standard user accounts
  • Use Privileged Access Workstations (PAWs)
  • Implement break-glass procedures for emergencies
📁

Need to Know

Definition: Access to information should be restricted to those who require it to perform their specific duties, regardless of their security clearance level.

Application Examples
  • HR staff can access employee records, IT cannot
  • Finance team accesses payroll, marketing cannot
  • Project data segregated by project team
  • Customer data access limited to assigned accounts
Distinction from Least Privilege

Least Privilege = minimum PERMISSIONS. Need to Know = minimum DATA ACCESS. A DBA might have high privileges on the database system but shouldn't see HR data if they don't need it.

🛡️ Implementation Controls
  • Classify data by sensitivity level
  • Implement data loss prevention (DLP) controls
  • Use database row-level security
  • Apply SharePoint/file share permissions by project
  • Monitor data access patterns for anomalies
👥

Separation of Duties (SoD)

Definition: Critical tasks should require multiple people to complete, preventing any single individual from having enough access to commit fraud or cause significant damage.

Classic SoD Pairs
  • Requester ≠ Approver (expense claims)
  • Developer ≠ Deployer (code to production)
  • User Creator ≠ Permission Grantor
  • Payment Initiator ≠ Payment Approver
Fraud Prevention

SoD is your primary control against insider fraud. Without it, a single malicious (or compromised) employee could create fake vendors, approve their own invoices, and authorize payments.

🛡️ Implementation Controls
  • Map critical processes to identify SoD conflicts
  • Implement workflow approval systems
  • Use identity governance tools to detect violations
  • Create SoD policy matrices for sensitive roles
  • Conduct regular SoD violation reviews
🏰

Defense in Depth

Definition: Implement multiple layers of security controls so that if one layer fails, others still protect the asset. No single point of failure.

Layered Controls Example
  • Layer 1: Network firewall + VPN access
  • Layer 2: Application-level authentication
  • Layer 3: MFA requirement
  • Layer 4: Role-based authorization
  • Layer 5: Session monitoring + recording
The Castle Analogy

Medieval castles had moats, walls, towers, and inner keeps. Each layer slowed attackers and gave defenders time to respond. Modern security works the same way — multiple controls, each adding resistance.

🛡️ Implementation Controls
  • Map all controls protecting critical assets
  • Ensure no single control is the only protection
  • Combine preventive, detective, and corrective controls
  • Test what happens when individual controls fail
  • Document control dependencies and gaps
🚫

Zero Trust

Definition: "Never trust, always verify." Every access request must be authenticated, authorized, and encrypted regardless of where it originates — inside or outside the network.

Zero Trust Pillars
  • Verify explicitly (authenticate every request)
  • Use least privilege access
  • Assume breach (design as if already compromised)
  • Micro-segmentation of networks
The End of Perimeter Security

Traditional security assumed "inside the network = trusted." With remote work, cloud services, and sophisticated attacks, the perimeter is gone. Zero Trust treats every access as potentially hostile.

🛡️ Implementation Controls
  • Implement identity-based access (not network-based)
  • Deploy continuous authentication/authorization
  • Encrypt all traffic (even internal)
  • Implement micro-segmentation
  • Monitor all access continuously
🚨

Fail Secure (Fail Closed)

Definition: When a system fails or encounters an error, it should default to a secure state (denying access) rather than an open state (allowing access).

Fail Secure Examples
  • Authentication server down → deny all logins
  • Firewall crashes → block all traffic
  • Invalid session token → require re-authentication
  • Database error → deny data access
The Tradeoff

Fail secure protects security but impacts availability. Some systems (like emergency exits) must "fail open" for safety. The decision depends on which risk is greater — security breach vs. access denial.

🛡️ Implementation Controls
  • Document fail-state behavior for all systems
  • Test failure scenarios regularly
  • Implement redundancy for critical auth systems
  • Create break-glass procedures for emergencies
  • Balance security with business continuity needs
📝

Accountability

Definition: Every action in a system must be traceable to a specific individual. Shared accounts and anonymous access are eliminated.

Anti-Patterns to Eliminate
  • Shared "admin" accounts
  • Generic service accounts used by multiple people
  • Root/Administrator accounts for daily use
  • "Guest" accounts with no audit trail
🛡️ Implementation Controls
  • Eliminate all shared accounts
  • Implement unique IDs for all users
  • Use PAM vaulting for privileged credentials
  • Log individual actions even in shared sessions
  • Require justification for all access requests

✅ Section 2 Learning Checklist

03

Access Control Models

The four primary models for managing permissions at scale

🎛️ Choosing the Right Model

Most enterprises use a combination of these models. Understanding each helps you design the right access architecture for different systems and compliance requirements.

🎭 Role-Based Access Control (RBAC)

▼

Definition: Permissions are assigned to ROLES, and users are assigned to roles. Users inherit all permissions from their assigned roles.

RBAC Structure
ROLES HIERARCHY EXAMPLE: ──────────────────────────────────────────────────────── │ ROLE │ INHERITS FROM │ PERMISSIONS │ ──────────────────────────────────────────────────────── │ Basic User │ - │ Read Email │ │ Developer │ Basic User │ + Git Push │ │ Senior Developer │ Developer │ + Code Review│ │ DevOps Engineer │ Senior Developer │ + CI/CD Admin│ │ Platform Admin │ DevOps Engineer │ + Prod Access│ ──────────────────────────────────────────────────────── USER ASSIGNMENT: ──────────────────────────────────────────────────────── │ USER │ ROLE │ EFFECTIVE PERMS │ ──────────────────────────────────────────────────────── │ john.smith │ Developer │ Email, Git Push │ │ jane.doe │ DevOps Engineer │ Email, Git, CI/CD │ │ admin.user │ Platform Admin │ ALL PERMISSIONS │ ────────────────────────────────────────────────────────

✅ When to Use RBAC

  • Clear organizational hierarchy exists
  • Job functions are well-defined
  • Compliance requires role-based audits
  • Managing 100+ users

⚠️ RBAC Pitfalls

  • Role explosion (too many granular roles)
  • Role creep (roles accumulate permissions)
  • Doesn't handle dynamic conditions well
  • Cross-department access is challenging
🛡️ RBAC Best Practices
  • Limit total roles to a manageable number (aim for <50 core roles)
  • Conduct quarterly role reviews and cleanup
  • Use role mining to discover natural role patterns
  • Implement role request and approval workflows
  • Document each role's purpose and owner

📊 Attribute-Based Access Control (ABAC)

▼

Definition: Access decisions are based on attributes (properties) of the user, resource, action, and environment. Policies evaluate these attributes dynamically.

ABAC Policy Example
POLICY: "Customer Data Access" ──────────────────────────────────────────────────────────────── ALLOW ACCESS WHEN: Subject Attributes (User): ├─ department = "Customer Success" ├─ clearance_level >= 2 └─ mfa_verified = true Resource Attributes (Data): ├─ classification = "customer_pii" └─ region = subject.assigned_region Action Attributes: └─ action ∈ ["read", "update"] Environment Attributes: ├─ request_time BETWEEN 08:00 AND 18:00 ├─ source_ip IN corporate_network └─ device_compliant = true DENY OTHERWISE ──────────────────────────────────────────────────────────────── EVALUATION EXAMPLE: ──────────────────────────────────────────────────────────────── User: Sarah (dept="Customer Success", clearance=3, mfa=true) Resource: Customer record (classification="customer_pii", region="EMEA") Action: read Time: 14:30, Corporate VPN, Compliant laptop Result: ✅ ACCESS GRANTED (all conditions met) ────────────────────────────────────────────────────────────────

✅ When to Use ABAC

  • Complex, multi-dimensional access rules
  • Dynamic conditions (time, location, risk)
  • Cross-organizational access
  • Fine-grained data-level controls

⚠️ ABAC Challenges

  • More complex to implement and debug
  • Requires quality attribute data
  • Policy conflicts harder to detect
  • Performance overhead for complex policies
🛡️ ABAC Best Practices
  • Start with core attributes, add complexity gradually
  • Implement policy testing and simulation tools
  • Create clear attribute taxonomy and ownership
  • Use XACML or similar standard policy languages
  • Monitor policy evaluation performance

🔐 Mandatory Access Control (MAC)

▼

Definition: Access is controlled by the SYSTEM based on security labels assigned to users (clearances) and resources (classifications). Users cannot change these controls.

MAC Classification Example
CLASSIFICATION LEVELS (Bell-LaPadula Model): ──────────────────────────────────────────────────────────────── LEVEL 4: TOP SECRET │ Nuclear codes, spy identities LEVEL 3: SECRET │ Military operations, source code LEVEL 2: CONFIDENTIAL │ Internal strategies, financials LEVEL 1: UNCLASSIFIED │ Public marketing, job postings ──────────────────────────────────────────────────────────────── RULES: ──────────────────────────────────────────────────────────────── "NO READ UP" │ Users cannot read data above their clearance "NO WRITE DOWN"│ Users cannot write data below their clearance │ (prevents leaking secrets to lower levels) ──────────────────────────────────────────────────────────────── EXAMPLE: ──────────────────────────────────────────────────────────────── User: Agent Smith (Clearance: SECRET) Can READ: Can WRITE: ✅ SECRET ✅ SECRET ✅ CONFIDENTIAL ✅ TOP SECRET (write up allowed) ✅ UNCLASSIFIED ❌ CONFIDENTIAL ❌ UNCLASSIFIED ────────────────────────────────────────────────────────────────

🏛️ Where MAC is Used

MAC is primarily used in military, government, and highly regulated industries where information classification is legally mandated. Examples include:

  • Defense/Intelligence agencies (classified networks)
  • Healthcare systems (patient data protection)
  • Financial services (regulatory compliance)
  • SELinux/AppArmor (operating system security)

👤 Discretionary Access Control (DAC)

▼

Definition: The OWNER of a resource decides who can access it. Users have discretion to share access with others.

DAC Example - File System
WINDOWS NTFS PERMISSIONS: ──────────────────────────────────────────────────────────────── File: Q4_Financial_Report.xlsx Owner: finance.director Access Control List (ACL): ──────────────────────────────────────────────────────────────── │ User/Group │ Permission │ Granted By │ ──────────────────────────────────────────────────────────────── │ finance.director │ Full Control │ (Owner) │ │ Finance Team │ Read + Write │ Owner │ │ CEO │ Read Only │ Owner │ │ External Auditor │ Read Only │ Owner │ │ Everyone Else │ NO ACCESS │ (default) │ ──────────────────────────────────────────────────────────────── The owner can SHARE access at their discretion. This is flexible but creates security risks. ────────────────────────────────────────────────────────────────
⚠️ DAC Security Risks
  • Users can accidentally over-share sensitive data
  • No central control or oversight
  • Permission creep is difficult to detect
  • Malware running as user inherits all permissions
  • Former employees may retain shared access
🛡️ DAC Risk Mitigations
  • Implement DLP to detect over-sharing
  • Conduct periodic access reviews
  • Train users on data classification
  • Overlay DAC with MAC for sensitive data
  • Monitor sharing activity and audit regularly

📊 Access Control Model Comparison

Aspect RBAC ABAC MAC DAC
Control Type Role-based Attribute-based Label-based Owner-based
Flexibility Medium Very High Low High
Complexity Medium High High Low
Central Control Yes Yes Yes (System) No (Owner)
Best For Enterprise apps Cloud/Dynamic Government File shares
Enterprise Tools Azure AD, Okta AWS IAM, OPA SELinux NTFS, SharePoint

✅ Section 3 Learning Checklist

04

Privileged Access Management (PAM)

Protecting the "Keys to the Kingdom"

⚠️ Why PAM is Critical

Privileged accounts are the #1 target for attackers. According to industry research, 80% of security breaches involve compromised privileged credentials. PAM is not optional — it's essential.

🔑 Types of Privileged Accounts

👑

Domain/Enterprise Admins

Highest level Windows AD accounts with full control over the entire domain.

Risk Level: CRITICAL
  • Can create/delete any user
  • Can modify any group policy
  • Can access any system in domain
  • Can grant any permission
🖥️

Local Administrators

Admin accounts on individual servers or workstations.

Risk Level: HIGH
  • Full control of single system
  • Can install software/malware
  • Can disable security controls
  • Often same password across systems!
🤖

Service Accounts

Non-human accounts used by applications to access resources.

Risk Level: HIGH
  • Run 24/7 without human oversight
  • Often have excessive permissions
  • Passwords rarely rotated
  • No MFA protection possible
🔧

Application/Database Accounts

Accounts with elevated access to specific applications or databases.

Risk Level: HIGH
  • DBA accounts (sa, root, sysdba)
  • Application admin consoles
  • Cloud admin accounts (AWS root)
  • API keys with admin permissions

🛡️ Core PAM Capabilities

🔒 Credential Vaulting

▼

What: Store privileged credentials in an encrypted vault, eliminating credential exposure.

Vault Architecture
┌────────────────────────────────────────────────────────────┐ │ PAM VAULT ARCHITECTURE │ ├────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ ┌─────────────────────────┐ │ │ │ ADMIN REQUESTS │ │ CREDENTIAL VAULT │ │ │ │ "I need SA │───────▶│ ┌─────────────────────┐ │ │ │ │ password" │ │ │ Domain Admin │ │ │ │ └─────────────────┘ │ │ ████████████████ │ │ │ │ │ │ ├─────────────────────┤ │ │ │ ▼ │ │ SQL SA Account │ │ │ │ ┌─────────────────┐ │ │ ████████████████ │ │ │ │ │ APPROVAL │ │ ├─────────────────────┤ │ │ │ │ WORKFLOW │ │ │ AWS Root │ │ │ │ │ ● Justify │ │ │ ████████████████ │ │ │ │ │ ● Time-limited │ │ └─────────────────────┘ │ │ │ │ ● Manager OK │ │ │ │ │ └────────┬────────┘ │ 🔐 AES-256 Encrypted │ │ │ │ │ 🔄 Auto-Rotation │ │ │ ▼ │ 📋 Full Audit Log │ │ │ ┌─────────────────┐ └─────────────────────────┘ │ │ │ TEMPORARY │ │ │ │ CREDENTIAL │◀────── Checked out for 4 hours │ │ │ CHECKOUT │ Auto-checked in after │ │ └─────────────────┘ │ │ │ └────────────────────────────────────────────────────────────┘
🛡️ Vaulting Controls
  • Use HSM-backed encryption for vault master keys
  • Implement dual-control for vault access
  • Enable automatic credential rotation
  • Set maximum checkout durations
  • Require justification for all checkouts

📹 Session Recording & Monitoring

▼

What: Record and monitor all privileged sessions for audit, compliance, and incident investigation.

Recording Capabilities
  • Full video capture of RDP/SSH sessions
  • Keystroke logging (with masking for passwords)
  • Command auditing for terminal sessions
  • Clipboard monitoring
  • File transfer tracking
Real-Time Monitoring
  • Live session viewing by security team
  • Automatic alerts on risky commands
  • Session termination capability
  • Behavioral anomaly detection
🛡️ Session Controls
  • Record ALL privileged sessions (no exceptions)
  • Retain recordings per compliance requirements (typically 1-7 years)
  • Implement command blacklisting for dangerous operations
  • Enable dual-control for break-glass scenarios
  • Use AI/ML to detect anomalous session behavior

⏰ Just-In-Time (JIT) Access

▼

What: Eliminate standing privileges by granting access only when needed, for limited time, with approval.

JIT Access Flow
TRADITIONAL (STANDING PRIVILEGES): ──────────────────────────────────────────────────────────── │ User: DBA_Admin │ │ Status: ALWAYS has production database access │ │ Risk: If compromised, attacker has immediate access │ ──────────────────────────────────────────────────────────── JIT ACCESS MODEL: ──────────────────────────────────────────────────────────── STEP 1: USER REQUESTS ACCESS └─ "I need prod DB access for incident INC0012345" └─ Duration: 2 hours STEP 2: APPROVAL WORKFLOW └─ Manager notified └─ Risk assessment performed └─ Approval granted (or denied) STEP 3: TEMPORARY PRIVILEGE ELEVATION └─ User added to DBA group └─ Timer starts: 2 hours └─ Session recording begins STEP 4: AUTO-REVOCATION └─ Timer expires (or manual check-in) └─ User removed from DBA group └─ Session recording ends └─ Audit trail complete ──────────────────────────────────────────────────────────── RESULT: Zero standing privileges, full accountability ────────────────────────────────────────────────────────────

💡 JIT Benefits

  • Reduced Attack Surface: Privileges exist only when needed
  • Full Accountability: Every access tied to request/approval
  • Compliance Ready: Complete audit trail for regulators
  • Least Privilege: Automatically enforced through time limits
🚨

Real Incident: Target Data Breach (2013)

What Happened

Attackers stole credentials from an HVAC vendor contractor. Those credentials had network access to Target's systems. The attackers moved laterally to point-of-sale systems and exfiltrated 40 million credit card numbers and 70 million customer records.

PAM Failures

The HVAC vendor account had excessive network access (violated Least Privilege). There was no network segmentation between vendor access and payment systems. No session monitoring detected the lateral movement. Standing credentials allowed persistent access.

PAM Controls That Would Have Helped

JIT access requiring approval for vendor connections. Session recording that would have detected unusual navigation. Network micro-segmentation limiting vendor access to HVAC systems only. Automated credential rotation after each use.

Business Impact

$162 million in breach-related costs. CEO and CIO resigned. Stock price dropped 46% in the following months. Lasting reputation damage.

✅ Section 4 Learning Checklist

05

Identity Attack Vectors

Know the enemy — common attacks targeting identity systems

⚠️ Identity is the New Perimeter

With cloud adoption and remote work, attackers focus on identity compromise rather than network intrusion. Understanding these attacks is essential for building effective defenses.

🔐 Credential Stuffing & Password Spraying

▼
Credential Stuffing

Attackers use username/password pairs stolen from other breaches, betting on password reuse.

Attack Pattern
# Attacker has 10M credentials from LinkedIn breach for cred in stolen_credentials: try_login("targetbank.com", cred.email, cred.password) # Success rate: typically 0.1-2% (still thousands of accounts)
Password Spraying

Try a few common passwords against many accounts, staying below lockout thresholds.

Attack Pattern
# Try common passwords against all discovered users passwords = ["Summer2024!", "Welcome1", "Password123"] for user in discovered_users: for pwd in passwords: try_login(user, pwd) wait(30_minutes) # Avoid lockout detection
🛡️ Defense Controls
  • Enforce MFA (blocks 99.9% of these attacks)
  • Check passwords against breach databases (HaveIBeenPwned)
  • Implement intelligent lockout (IP-based, not just user-based)
  • Deploy CAPTCHA after failed attempts
  • Monitor for distributed login attempts across accounts
  • Use passwordless authentication where possible

🎣 Phishing & Adversary-in-the-Middle (AitM)

▼

Modern phishing doesn't just steal passwords — it steals entire authenticated sessions, bypassing traditional MFA.

AitM Attack Flow
TRADITIONAL PHISHING: ──────────────────────────────────────────────────────────── User → Fake Login Page → Attacker gets password Result: Blocked by MFA ✅ ADVERSARY-IN-THE-MIDDLE (AitM): ──────────────────────────────────────────────────────────── ┌─────────────────┐ User ────────────▶│ ATTACKER PROXY │────────────▶ Real Office365 │ (EvilGinx,etc.) │ └────────┬────────┘ │ Attacker captures: ├─ Username/Password ├─ MFA token/code └─ Session cookie ← THIS IS THE PRIZE │ ▼ Attacker uses session cookie to login as user MFA already satisfied! ❌ BYPASSED ────────────────────────────────────────────────────────────
⚠️ Why Traditional MFA Fails
  • SMS/Email codes can be captured in real-time
  • TOTP codes are valid for 30+ seconds (enough for proxy)
  • Push notifications are approved by deceived users
  • Session cookies work from any device
🛡️ Defense Controls
  • Deploy phishing-resistant MFA (FIDO2/WebAuthn, hardware keys)
  • Implement Conditional Access blocking untrusted devices
  • Use token binding to lock sessions to devices
  • Enable continuous access evaluation (real-time session revocation)
  • Train users to recognize URL spoofing
  • Deploy anti-phishing email filters

🎫 Kerberoasting & Pass-the-Hash

▼

Active Directory attacks that exploit how Windows authentication works.

Kerberoasting

Request service tickets for accounts with SPNs, then crack them offline to get service account passwords.

PowerShell
# Any domain user can request service tickets Get-ADUser -Filter {ServicePrincipalName -ne "$null"} # Request ticket (legitimate Kerberos operation) # Then crack offline - no lockout, no alerts!
Pass-the-Hash

Use stolen NTLM password hashes to authenticate without knowing the actual password.

Attack
# Extract hashes from memory (e.g., Mimikatz) # Hash: aad3b435b51404eeaad3b435b51404ee # Use hash directly to authenticate # No password cracking needed!
🛡️ Defense Controls
  • Use Group Managed Service Accounts (gMSA) — no human-known passwords
  • Enforce 25+ character passwords for service accounts
  • Implement Credential Guard on Windows 10/11
  • Deploy privileged access workstations (PAWs)
  • Monitor for Kerberos TGS requests (Event ID 4769)
  • Enable Protected Users group for sensitive accounts

🎭 Token & Session Hijacking

▼

Attackers steal OAuth tokens, JWTs, or session cookies to impersonate authenticated users.

🚨

Real Attack: Microsoft/SolarWinds (2020-2021)

What Happened

Attackers (NOBELIUM) used stolen SAML signing certificates to forge authentication tokens, granting themselves access to any federated application — including Microsoft 365 environments of thousands of organizations.

Attack Technique: Golden SAML

By compromising the AD FS server's token-signing certificate, attackers could create tokens for any user, with any permissions, without knowing passwords or triggering MFA.

🛡️ Defense Controls
  • Protect token-signing certificates with HSMs
  • Implement short token lifetimes (hours, not days)
  • Enable Continuous Access Evaluation (CAE)
  • Monitor for anomalous token usage patterns
  • Use certificate-bound tokens where possible
  • Regularly rotate signing keys

✅ Section 5 Learning Checklist

06

Identity Lifecycle Management

Joiner → Mover → Leaver — Managing identities from hire to retire

🔄 The Identity Lifecycle

Every identity in your organization goes through predictable phases. Automating these transitions eliminates orphaned accounts, reduces security risks, and ensures compliance.

Identity Lifecycle Phases
┌─────────────────────────────────────────────────────────────────────────┐ │ IDENTITY LIFECYCLE MANAGEMENT │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ JOINER │───▶│ MOVER │───▶│ LEAVER │ │ │ │ │ │ │ │ │ │ │ │ New Employee │ │ Role Change │ │ Termination │ │ │ │ Contractor │ │ Department │ │ Retirement │ │ │ │ Vendor │ │ Promotion │ │ Contract End │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ PROVISION │ │ MODIFY │ │ DEPROVISION │ │ │ │ │ │ │ │ │ │ │ │ ● Create AD │ │ ● Remove old │ │ ● Disable │ │ │ │ ● Create M365│ │ access │ │ account │ │ │ │ ● Assign role│ │ ● Add new │ │ ● Revoke all │ │ │ │ ● Issue badge│ │ permissions│ │ access │ │ │ │ ● Add to │ │ ● Update │ │ ● Archive │ │ │ │ groups │ │ groups │ │ mailbox │ │ │ │ ● Enable MFA │ │ ● Notify │ │ ● Recover │ │ │ │ │ │ manager │ │ license │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ⏱️ SLA: 24 hours ⏱️ SLA: 4 hours ⏱️ SLA: IMMEDIATE │ │ │ └─────────────────────────────────────────────────────────────────────────┘

🆕 Joiner Process (Onboarding)

▼

Trigger: HR creates new employee record in HRIS (Workday, SAP, etc.)

Automated Provisioning Steps
Step System Action SLA
1 Active Directory Create user account with standard attributes Immediate
2 Email System Create mailbox, assign license 15 min
3 Group Management Add to department/location groups Immediate
4 Application Access Provision based on job code/role 1 hour
5 MFA Enrollment Send enrollment link/instructions With welcome email
🛡️ Joiner Controls
  • Automate provisioning from authoritative HR source
  • Enforce MFA enrollment before Day 1 access
  • Apply role-based access based on job code
  • Send credentials through secure channel (not email)
  • Require manager attestation of access grants

🔄 Mover Process (Internal Transfers)

▼

Trigger: HR updates department, job code, or manager in HRIS

⚠️ The Access Accumulation Problem
  • Users collect permissions over time as they move roles
  • Old access rarely removed ("might need it someday")
  • After 3-5 transfers, users have excessive privileges
  • Creates Separation of Duties violations
Correct Mover Process
Mover Workflow
1. DETECT CHANGE └─ HR updates job code: "Developer" → "Project Manager" 2. REVOKE OLD ACCESS └─ Remove from Developer groups └─ Revoke Git repository access └─ Remove from developer mailing lists 3. GRANT NEW ACCESS └─ Add to Project Manager groups └─ Grant project management tool access └─ Add to PM mailing lists 4. NOTIFY & DOCUMENT └─ Email old manager: "Access revoked" └─ Email new manager: "Access granted" └─ Log all changes for audit
🛡️ Mover Controls
  • Implement "birthright access" model (role determines baseline access)
  • Auto-revoke old role access when job code changes
  • Require manager review of inherited vs. new access
  • Run SoD checks before granting new role
  • Set grace period for old access (7-14 days max)

🚪 Leaver Process (Offboarding)

▼

Trigger: HR sets termination date in HRIS (or immediate for involuntary terminations)

⚠️ Critical: Timing Matters

Voluntary resignation: Disable account on last day. Involuntary termination: Disable account BEFORE employee is notified. Delayed deprovisioning is the #1 cause of insider theft and sabotage.

Leaver Checklist
Priority Action Timing
P1 - CRITICAL Disable AD/Azure AD account Immediate
P1 - CRITICAL Revoke VPN/Remote access Immediate
P1 - CRITICAL Revoke OAuth tokens/sessions Immediate
P2 - HIGH Disable badge/physical access < 1 hour
P2 - HIGH Remove from all groups < 4 hours
P3 - MEDIUM Forward email to manager < 24 hours
P3 - MEDIUM Archive mailbox < 24 hours
P4 - LOW Recover licenses < 7 days
P4 - LOW Delete account (after retention) 30-90 days
🛡️ Leaver Controls
  • Automate immediate access revocation on termination date
  • Include all cloud SaaS applications in offboarding
  • Rotate shared credentials the user knew
  • Conduct exit DLP scan for data exfiltration
  • Maintain audit trail for legal/compliance hold
  • Sync with HR/Legal for involuntary terminations

✅ Section 6 Learning Checklist

07

Your IAM Career Path

From foundation knowledge to senior roles

🎯 Career Trajectory

IAM professionals are in high demand. Understanding these foundations positions you for roles ranging from IAM Analyst to Security Architect. Here's your roadmap.

IAM Career Ladder
┌─────────────────────────────────────────────────────────────────────────┐ │ IAM CAREER PROGRESSION │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ YEARS 0-2: FOUNDATION │ │ ├─ IAM Analyst / IAM Support │ │ ├─ Skills: User provisioning, access requests, basic troubleshooting │ │ ├─ Certs: Security+, Azure AZ-900, Okta Certified Professional │ │ └─ Salary Range: $55,000 - $75,000 │ │ │ │ YEARS 2-4: SPECIALIST │ │ ├─ IAM Engineer / PAM Administrator │ │ ├─ Skills: RBAC design, PAM implementation, scripting (PowerShell) │ │ ├─ Certs: CyberArk Defender, SailPoint Certified, Azure SC-300 │ │ └─ Salary Range: $75,000 - $110,000 │ │ │ │ YEARS 4-7: SENIOR │ │ ├─ Senior IAM Engineer / IAM Team Lead │ │ ├─ Skills: Architecture design, automation, governance frameworks │ │ ├─ Certs: CISSP, CISM, CyberArk Sentry │ │ └─ Salary Range: $110,000 - $150,000 │ │ │ │ YEARS 7+: LEADERSHIP │ │ ├─ IAM Architect / IAM Manager / CIAM Director │ │ ├─ Skills: Strategy, vendor evaluation, compliance programs │ │ ├─ Certs: TOGAF, SABSA, ISSAP │ │ └─ Salary Range: $150,000 - $250,000+ │ │ │ └─────────────────────────────────────────────────────────────────────────┘

🛠️ Skills to Develop

💻

Technical Skills

Must-Have
  • Active Directory & Azure AD
  • PowerShell scripting
  • LDAP, SAML, OAuth, OIDC
  • PAM tools (CyberArk, BeyondTrust)
  • IGA tools (SailPoint, Saviynt)
📊

Process Skills

Essential
  • Access review/certification
  • Joiner/Mover/Leaver automation
  • Role mining & engineering
  • Segregation of Duties analysis
  • Incident response
📜

Compliance Knowledge

Key Frameworks
  • SOX (finance controls)
  • HIPAA (healthcare)
  • PCI-DSS (payment cards)
  • GDPR (data privacy)
  • ISO 27001 / NIST
🤝

Soft Skills

Critical for Growth
  • Stakeholder communication
  • Business case development
  • Vendor management
  • Project management
  • Risk communication

📜 Certification Roadmap

Level Certification Focus Area Prep Time
Entry CompTIA Security+ Security fundamentals 1-2 months
Entry Okta Certified Professional Cloud identity basics 2-4 weeks
Intermediate Microsoft SC-300 Azure AD/Entra ID 1-2 months
Intermediate CyberArk Defender PAM implementation 1-2 months
Advanced CISSP Security leadership 3-6 months
Advanced CyberArk Sentry PAM architecture 2-3 months

🚀 Your Next Steps

  • Complete this guide: Check all boxes above to solidify foundation
  • Build a lab: Set up AD, Azure AD, or Authentik to practice
  • Join communities: Reddit r/IAM, LinkedIn IAM groups, Discord servers
  • Start certifying: Security+ or Okta Professional as first milestone
  • Apply learning: Volunteer for IAM projects at your current job

✅ Section 7 Learning Checklist