Privileged Access Management (PAM): Privilegierte Konten schützen

Privileged accounts are the most valuable target in any IT environment. A compromised domain administrator account grants complete control over all Windows systems, all passwords, and all data. According to CyberArk, privileged credentials are involved in over 80 percent of all successful cyberattacks. Privileged Access Management (PAM) is the framework for protecting these critical accounts—through vaulting, session recording, just-in-time access, and continuous monitoring.

What is a privileged account?

Classification of privileged accounts:

Tier 0 - Most critical accounts:
  → Domain Administrator (Windows)
  → Enterprise Administrator
  → Schema Administrator
  → Azure/Entra ID Global Administrator
  → Root Account (Linux/Unix systems)
  → AWS Root Account
  → Cloud Platform Administrator
  → PKI/CA Administrator
  Compromise = complete control over everything!

Tier 1 - Server Administrators:
  → Local Administrators on Servers
  → Database Administrators (DBA, SA)
  → Backup Administrators
  → Network Administrators (Firewall, Switches)
  → CI/CD Pipeline Admins (manage production deployments)

Tier 2 - Workstation Administrators:
  → Local Administrators on Workstations
  → Helpdesk with admin rights
  → SCCM/Intune administrators

Service Accounts (Special Class):
  → Run 24/7, never interactively
  → Often with high privileges (backups, monitoring)
  → Frequently over-privileged ("easier" to configure that way back then)
  → PAM Vault: service accounts under control too!

Shared Accounts (to be eliminated!):
  → "root" is used by 10 administrators → no accountability
  → PAM solution: personal accounts + checkout system for shared passwords

Number of privileged accounts:
  → Average company: 3–4 times more privileged accounts than employees
  → Many unknown (former employees, forgotten service accounts)
  → Discovery: first PAM step!

Core PAM Concepts

What PAM Does:

Password Vaulting (Core Function):
  → All privileged passwords: stored in the vault (encrypted)
  → Users NEVER see passwords in plain text
  → Passwords are automatically rotated after every session
  → Vault: Hardware Security Modules (HSM) or strong encryption

  Rotation Strategies:
  → On-Demand: Rotate after every use
  → Scheduled: Daily/weekly
  → Event-based: Immediately after a security incident!

Privileged Session Management (PSM):
  → All admin sessions: Routed through PAM proxy
  → Session recording: Complete recording (Video + keystrokes)
  → Real-time monitoring: Supervisor can take over/end session
  → Audit trail: every action traceable
  → Credential injection: Admin sees NO password (injected directly!)

Just-in-Time Access (JIT):
  → Zero standing privilege: no permanent admin rights
  → Access is requested → approved → activated → automatically revoked
  → Time window: 1–8 hours (depending on the task)
  → Approval: dual-control principle or automatic for known workflows

Privileged Account Discovery:
  → Scans infrastructure for unknown privileged accounts
  → Detects: accounts in Domain Admins, Local Admins, Service Accounts
  → Integration: AD, Unix, cloud, databases, network devices
  → Onboarding: Add detected accounts to Vault

Privileged Threat Analytics (PTA):
  → Behavioral analysis of privileged users
  → Anomaly detection: Admin at 2 a.m.?
  → UEBA for privileged accounts
  → Integration with SIEM

Zero Standing Privilege (ZSP) - Target Architecture:
  Today:       Domain Admins with permanent privileges
  Transition:    PAM + JIT (temporary privileges)
  Target (ZSP):  No permanent privileged accounts
               → All admins: standard users + JIT escalation

Comparing PAM Products

Enterprise PAM Solutions:

CyberArk Privileged Access Manager (Market Leader):
  Strengths:
  → Market leader (Gartner Magic Quadrant Leader for over 10 years)
  → Vault architecture: Enterprise Password Vault (EVP)
  → PSM: complete RDP/SSH session recording
  → CyberArk Identity: IDAAS + MFA + SSO integrated
  → Threat Analytics: detects anomalous usage patterns
  → Kubernetes: Conjur (secrets management for containers)
  → OT/ICS support, enterprise support

  Weaknesses:
  → Complex to implement and operate
  → Very expensive (enterprise licensing, 6-figure annual cost)
  → Account onboarding: time-consuming

  Suitable for: Enterprise (1,000+ employees), KRITIS, Finance

Delinea Secret Server (formerly Thycotic):
  Strengths:
  → Simpler setup than CyberArk
  → Good value for money
  → SaaS option (Secret Server Cloud) + on-premises
  → Launchers: automatic RDP/SSH startup without password visibility
  → Reporting: out-of-the-box compliance reports
  → Privilege Manager: least privilege on endpoints (Application Control)

  Weaknesses:
  → Less powerful than CyberArk in complex environments
  → Threat analytics less mature

  Suitable for: Mid-sized businesses (100–1,000 employees)

BeyondTrust Password Safe:
  Strengths:
  → Combines remote access and PAM
  → Privileged remote access: for external service providers
  → Asset discovery: automatic detection of privileged accounts
  → Good for managed service providers
  → Endpoint Privilege Management (EPM): removes local admin rights

  Weaknesses:
  → Expensive for PAM-only use

HashiCorp Vault (Open Source / Enterprise):
  Strengths:
  → Open Source (Community Edition free!)
  → Focus: Secrets management for applications (API keys, DB credentials)
  → Dynamic Secrets: temporary credentials on demand
  → Kubernetes integration: Vault Agent Injector
  → Multi-cloud: AWS/Azure/GCP Secrets Engine

  # Dynamic Secrets example:
  vault read database/creds/my-role
  # Key                Value
  # username           v-root-abcd1234
  # password           A1a-XxYyZz...
  # lease_duration     1h   ← expires automatically!

  Suitable for: DevOps, cloud-native, development environments

Microsoft Privileged Identity Management (PIM):
  Strengths:
  → Integrated into Azure AD / Entra ID (not a separate product)
  → JIT activation for Azure RBAC + Azure AD roles
  → Access Reviews: regular reviews
  → PIM included in Entra ID P2 (approx. 8 EUR/user/month)

  Configure PIM:
  Azure Portal → Entra ID → Privileged Identity Management → Roles
  → Global Administrator: Eligible instead of Permanent!
    → Max Duration: 4h
    → Require Justification: On
    → Require Approval: On → Approver: CISO

  Weaknesses:
  → Only for Azure/M365 (no on-premises without Azure Arc)
  → No PSM / session recording

Wallix Bastion (EU provider):
  → GDPR-compliant, developed in Europe
  → PAM + Session Management + Access Control
  → Good for: Companies prioritizing EU data protection

Step-by-Step PAM Implementation

PAM Rollout - Sequence:

Phase 1: Discovery (Weeks 1-2)
  → Identify all privileged accounts:
    - Windows: Domain Admins, Local Admins, Service Accounts
    - Linux: root, sudo groups
    - Databases: DBA accounts, SA users
    - Network: Enable passwords, management accounts
    - Cloud: Root account, IAM admins, service principals
  → Tool: CyberArk Discovery Manager, or PowerShell:

  # Find all local admins in the AD domain:
  Get-ADGroupMember "Domain Admins" -Recursive | Select Name
  # Service accounts:
  Get-ADServiceAccount -Filter *

Phase 2: Vault Setup (Weeks 2–4)
  → Deploy PAM vault (HA for production!)
  → Configure Vault encryption (HSM or strong keys)
  → Define break-glass accounts (see below)
  → Admin onboarding: Set up IT admins in PAM

Phase 3: Account onboarding (Weeks 4–8)
  → Domain admins first (highest risk!)
  → Then: Server admins
  → Then: Service accounts (password rotation!)
  → Then: Database admins
  → Then: Network devices
  → Then: Cloud accounts

  Important for service accounts:
  → Store service account password in Vault
  → Enable automatic rotation
  → Check: Which services use this account?
  → Rotation plan: update all services first, then rotate!

  # For Windows service accounts: Group Managed Service Accounts (gMSA)
  # Password is automatically rotated by AD (no PAM required!)
  New-ADServiceAccount -Name "svc-webapp" -ManagedPasswordIntervalInDays 30
  Install-ADServiceAccount svc-webapp

Phase 4: Enable PSM + JIT (Weeks 8–12)
  → Configure PSM proxy for RDP/SSH
  → Enable session recording + define storage location
  → Define JIT workflows (who approves what?)
  → Training: Admins must use PAM (Change Management!)

Tiered Administration Model

Microsoft Tiered Administration Model:

Why it’s necessary:
  → Attacker uses lateral movement: compromises workstation → Helpdesk admin
    uses same credentials on server → Server compromised →
    DA credentials stored on server → Domain admin compromised
  → Solution: Strict separation of tier credentials

Tier 0 (Forest and Domain):
  → Systems: Domain Controller, PKI, ADFS, Azure AD Connect
  → Accounts: Domain Admins, PKI Admins
  → Admin workstation: Tier-0-PAW (Privileged Access Workstation)
    → Separate, hardened laptop EXCLUSIVELY for Tier 0 tasks
    → No internet, no email, no Office on this machine!
  → Logon restriction: Tier 0 accounts are NOT allowed on Tier 1/2 systems!
    GPO: Computer Configuration → Security Settings → User Rights:
    "Deny log on locally" for all Tier 1/2 systems for DA accounts

Tier 1 (Servers):
  → Systems: Member servers, VMs, databases
  → Accounts: Server administrators (NO Domain Admins!)
  → Admin workstation: Tier-1 PAW or Jump Server
  → Logon Restriction: Tier-1 accounts not allowed on workstations

Tier 2 (Workstations):
  → Systems: User workstations, laptops
  → Accounts: Helpdesk, standard admins
  → Admin workstation: Dedicated helpdesk workstation
  → Logon Restriction: Not allowed on servers/DCs

Implementation with LAPS (Local Admin Password Solution):
  → For Tier 1/2: unique local admin account per system
  → Password managed automatically (no manual rotation!)
  → Windows LAPS: integrated into Windows 11 22H2 and Server 2022
  → PAM integration: LAPS passwords accessible via PAM Vault

  Enable LAPS (Intune):
  Endpoint Security → Account Protection → LAPS:
    Backup Directory: Azure AD
    Password Complexity: Uppercase Letters + Lowercase Letters + Numbers + Special Characters
    Password Length: 32
    Password Age: 7 days
    Administrator Account Name: (blank = default account)

Authentication Policy Silos (Windows 2012R2+):
  → Tier-0 accounts: may ONLY authenticate on Tier-0 computers
  → If Tier-0 account is logged in on a normal PC: DENIED!

Just-in-Time Access in Practice

JIT Implementation – Three Approaches:

Approach 1: Ephemeral Accounts (temporary accounts):
  → Admin account is created on-demand
  → Automatically deleted after expiration
  → CyberArk: Just-in-Time Access + Dynamic Provisioning

  Workflow:
  1. Admin requests JIT access (Reason: "Deploy patch KB5017308")
  2. PAM creates temporary account: john.doe.jit.20260304@firma.de
  3. Account is added to the Server Admin group
  4. Admin connects via PSM (Session is recorded)
  5. After 2 hours: Account automatically deactivated and removed from group

Approach 2: Privilege Elevation (existing account, temporary elevation):
  → Normal account → temporarily added to privileged group
  → Microsoft PIM for Azure permissions
  → PAM Vault for on-premises

  PIM Workflow:
  1. Admin activates "Server Administrator" in PIM
  2. Justification: "Monthly Patch Deployment Server-01"
  3. Notification to CISO/Manager
  4. After approval: Account added to group (2h)
  5. Session Monitor in PIM: when active?
  6. After 2h: automatically removed from group

  # Activation via PowerShell:
  Open-AzureADMSPrivilegedRoleAssignmentRequest `
    -ProviderId "aadRoles" `
    -ResourceId &quot;<tenantid>&quot; `
    -RoleDefinitionId &quot;<globaladminroleid>&quot; `
    -SubjectId &quot;<userid>&quot; `
    -Type &quot;UserAdd&quot; `
    -AssignmentState &quot;Active&quot; `
    -Schedule @{StartDateTime=(Get-Date); EndDateTime=(Get-Date).AddHours(4)} `
    -Reason &quot;Configuration change for ticket #12345&quot;

Approach 3: Just-Enough-Administration (JEA):
  → PowerShell remoting with restricted commands
  → No longer &quot;full admin&quot; – only necessary cmdlets!
  → Configuration: JEA Session Configuration Files

  JEA Configuration (PowerShell):
  # SessionConfiguration.pssc
  SchemaVersion = &#x27;2.0.0.0&#x27;
  Author = &#x27;IT-Security&#x27;
  Description = &#x27;Limited Admin for Patch Management&#x27;
  SessionType = &#x27;RestrictedRemoteServer&#x27;
  ModulesToImport = @(&#x27;PSWindowsUpdate&#x27;)
  VisibleCmdlets = @(
    &#x27;Get-WindowsUpdate&#x27;,
    &#x27;Install-WindowsUpdate&#x27;,
    &#x27;Get-Service&#x27;,
    &#x27;Restart-Service&#x27;
  )
  RunAsVirtualAccount = $true  # Runs with local admin privileges, but isolated!

  Register JEA:
  Register-PSSessionConfiguration -Path .\SessionConfiguration.pssc
    -Name &#x27;PatchManagement&#x27; -Force
  # Usage: Enter-PSSession -ComputerName server -ConfigurationName PatchManagement

JIT on Linux (sudo with time-limited sessions):
  # With tlog (session recording) + sudo:
  # /etc/sudoers.d/jit:
  %jit-admins ALL=(ALL) NOPASSWD: /usr/bin/tlog-rec-session
  # Only specific commands allowed, all sessions recorded

CyberArk PAM - Enterprise Architecture

CyberArk Architecture and Configuration:

Core Components:
  Digital Vault:                    Central encrypted credential store
  Central Policy Manager (CPM):     Automatic password rotation
  Privileged Session Manager (PSM): Session proxy
  Password Vault Web Access (PVWA): Web UI for administrators

Safe Concept (Organizational Structure):
  Safes = Folders/Containers for Credentials
  → Safe "DomainAdmins": all DA credentials
  → Safe "DatabaseAccounts": all DB credentials
  → Access Rights: granular at the safe level

  # CyberArk REST API - Create Account:
  POST /api/Accounts
  {
    "safeName": "DomainAdmins",
    "platformId": "WinDomain",
    "name": "da-maxmustermann-prod",
    "address": "corp.example.com",
    "userName": "da-maxmustermann",
    "secretType": "password",
    "secret": "initialpassword",
    "platformAccountProperties": {
      "LogonDomain": "CORP"
    }
  }

CPM Rotation (automatic password rotation):
  → CPM connects to the system, changes the password, and stores it in the Vault
  → Interval: daily, weekly
  → Automatic rotation after checkout (immediate rotation after use!)
  → Dual Control: two people must approve the password

PSM Session (Log Types):
  → RDP (Windows): Video recording of Windows admin sessions
  → SSH (Linux): Keystroke + terminal recording
  → SQL Plus / SQL Server Management Studio: DB admin sessions
  → Web applications: via browser extensions

Using session recording for forensic analysis:
  → CyberArk Vault: all recordings searchable
  → Transcript search: "Which admin executed DROP TABLE?"
  → Timeline: when was which system accessed?
  → Compliance report: all accesses to PCI-DSS systems in the last quarter

Session Recording and Forensics

Audit trail: Analyzing session recordings:

What is recorded:
  → Keystroke logging: every key, every command
  → Terminal output: all output
  → File transfers (via SCP/SFTP)
  → RDP: Video stream + clipboard activity
  → Timestamp for each event

Forensics scenario:
  Incident: Database data was deleted
  Investigation via PAM session recordings:
  1. PAM logs: Who had DB access during this time window?
  2. Session recording: Open the DBA’s session from 3:15 a.m.
  3. Video: DBA connects and executes: “DELETE FROM customers;”
  4. Keystroke log: Exact SQL command documented
  5. Result: Insider threat identified, evidence secured

Session Recording Compliance:
  → PCI-DSS: Record all access to CDE (Cardholder Data Environment)
  → SOX: Document all financial system admin access
  → HIPAA: Log all PHI system access
  → ISO 27001: A.9.4 - Logging of system administrator activities

Break-Glass Accounts

Emergency access when PAM is unavailable:

The problem:
  → PAM system fails → no access to admin passwords
  → Emergency: Server compromised, PAM system too?
  → Power outage / network partition

Break-Glass Account Concept:
  → 1–2 accounts with highest privileges OUTSIDE of PAM
  → Password: in a physically secured envelope (safe!)
  → NO digital access to the break-glass password (except in an emergency)

  Implementation:
  Account:     bga01@company.com (Break-Glass Account 1)
  Password:  60+ characters, complex, generated offline
  Storage:  Physical safe (Room A, Lock No. X)
             PLUS: encrypted on USB drive (different location)
  Access:   Only by CISO + IT Director together (four-eyes principle!)
  Monitoring: Every use → immediate alert to all IT executives

  Monitoring:
  → Azure Sentinel Alert: bga01 logged in → IMMEDIATE P1 Incident!
  → Regular test login (annually): check if account works
  → Password rotation: after every actual use

  Break-glass account best practices:
  ✓ MFA method documented (authenticator backup codes!)
  ✓ Do not let the account expire (exception to password policy)
  ✓ No regular email reception (not for normal work!)
  ✓ Audit trail: every use justified and documented

GDPR-compliant session recording

Legal limits on session monitoring:

What is permitted:
  ✓ Session recording on company systems
  ✓ Monitoring of privileged accounts (IT admins!)
  ✓ Logging for security and compliance

What is relevant to the works council:
  → §87 BetrVG: The works council has the right of co-determination!
  → A works agreement MUST be concluded
  → Content of the works agreement: what is recorded, how long it is stored, who has access

GDPR compliance:
  → Legal basis: Art. 6(1)(f) GDPR (legitimate interest)
  → or: Works agreement (= consent under collective bargaining law)
  → Purpose limitation: only for security, not for performance monitoring
  → Retention periods: Delete session recordings after 90 days (recommended)
  → Exception: Incident-related recordings → retain longer

Transparency:
  → Admins are informed: "Sessions are being recorded"
  → System banner upon login: "Authorized use only, sessions monitored"
  → No covert monitoring of employees (§201a StGB!)

PAM and SIEM/SOAR Integration

PAM Events in SIEM:

Important PAM events for SIEM correlation:
  □ Unexpected check-out: Admin retrieves credentials outside business hours
  □ Failed check-out: Account no longer exists (orphaned credential!)
  □ Session Duration: Admin session longer than 4 hours (unusual!)
  □ Sensitive Commands: rm -rf, DROP TABLE, net user /domain in session log
  □ JIT expiration ignored: Admin extends JIT access multiple times (bypass?)
  □ Concurrent Sessions: Simultaneous use of the same private account

SIEM Alert: Credential checkout outside business hours:
  # Splunk:
  index=pam eventtype=credential_checkout
  | eval hour=strftime(_time, "%H")
  | where (hour < 6 OR hour >= 20)
  | table _time, user, target_account, target_system, reason
  | eval alert_title = "PAM Checkout outside business hours"

SOAR Playbook: Suspicious Checkout:
  Trigger: PAM alert "Credential Checkout at 3:00 AM"
  Automated:
    1. Slack/Teams message to CISO: "Privileged checkout at 3:00 AM"
    2. View current session (is the admin currently connected?)
    3. If no known change window: Terminate session immediately!
    4. Create ticket: "Unexpected Privileged Access"
  Manual:
    → L2 Analyst evaluates: Was it planned? (e.g., change window forgotten?)
    → If unknown: Initiate Incident Response

KQL in Microsoft Sentinel (Admin login not from PAW):
  SecurityEvent
  | where EventID == 4624
  | where Account contains "admin" or Account contains "svc"
  | where Computer !in (known_paw_hostnames)
  | where LogonType in (3, 10)  // Network + RemoteInteractive
  | project TimeGenerated, Account, Computer, IpAddress
```</userid></globaladminroleid></tenantid>