7.1 Master Policy Framework & Enterprise Compliance Rules

7.1 Master Policy Framework & Enterprise Compliance Rules

Quick Answer: The Master Policy is CyberArk's enterprise-wide compliance engine, establishing a unified baseline of privileged account security rules across all managed targets. Configured in the Password Vault Web Access (PVWA) under Policies -> Master Policy, it enforces core controls including periodic password changes, verification, One-Time Password (OTP) changes upon release, dual control access approval, reason-for-access ticketing, exclusive check-in/check-out, and Privileged Session Manager (PSM) session recording. Baseline rules are immutable and cannot be deleted. When specific systems require different parameters—such as emergency break-glass accounts or high-tier domain controllers—administrators configure Master Policy Exceptions, which are applied strictly at the Platform level.

---

The Master Policy as the Enterprise Compliance Engine

In enterprise Privileged Access Management (PAM), maintaining consistent security posture across thousands of disparate servers, databases, network appliances, and cloud assets presents a formidable governance challenge. Prior to centralized policy engines, security administrators had to configure rotation cycles and access workflows on individual vaults, safes, or individual accounts. This fragmented approach introduced configuration drift, audit blind spots, and administrative overhead.

CyberArk solves this through the Master Policy. Located centrally within the PVWA interface, the Master Policy serves as the single source of truth and the overarching compliance engine for the entire CyberArk PAM deployment. Instead of defining access control rules repeatedly across hundreds of Safes, the Master Policy dictates high-level enterprise requirements. It sets the baseline standards that organizations present to external auditors, regulatory bodies, and internal risk committees to prove compliance with frameworks such as NIST SP 800-53, PCI-DSS, SOX, and ISO/IEC 27001.

Every account onboarded into the Digital Vault automatically inherits the compliance mandates defined in the Master Policy. The Central Policy Manager (CPM) reads these baseline rules to determine when and how to rotate passwords, verify target credentials, or reconcile lost secrets. Simultaneously, the PVWA evaluates these rules to control end-user workflows, determining whether an engineer must provide a ticketing change number, wait for dual control managerial authorization, or connect through an isolated PSM jump host.

---

Built-In Baseline Policy Rules: Three Critical Functional Domains

The Master Policy organizes enterprise security baselines into three primary operational domains: Privileged Password Management, Privileged Access Workflows, and Privileged Session Management.

1. Privileged Password Management Rules

These rules direct the automated lifecycle activities performed by the Central Policy Manager:

• Require password change every X days: Mandates the periodic rotation frequency for privileged credentials. When active, the CPM automatically calculates password expiration based on the last change timestamp and initiates automated rotation on the target system when the interval (such as 90, 60, or 30 days) elapses.
• Require periodic password verification every X days: Instructs the CPM to connect to the target endpoint using the stored credential without changing it, verifying that the password in the Vault matches the password on the target. This detects out-of-band changes made outside CyberArk.
• Perform password change on release: Enforces the One-Time Password (OTP) model. Whenever an exclusive account is checked in by a user or an active session expires, the CPM immediately initiates a password rotation on the target system. This ensures that any human exposure to a credential rendered it single-use.

2. Privileged Access Workflow Rules

These rules govern human interaction with privileged credentials in the PVWA:

• Require dual control password access approval: Enforces multi-person authorization. When enabled, a user cannot view, copy, or initiate a PSM connection to an account until one or more authorized Safe approvers (such as security leads or team managers) review and approve a time-bounded access request.
• Require users to specify reason for access: Mandates that requestors provide a business justification before accessing an account. This rule can be configured to require free-form text or strict integration with enterprise ticketing systems (such as ServiceNow or Jira), validating that an active change request or incident ticket exists.
• Enforce check-in/check-out exclusive access: Locks an account to a single user at any given time. When User A checks out an account, User B cannot retrieve the credentials or launch a session using that same account until User A checks it in or the validity window expires. This establishes absolute non-repudiation in audit trails.

3. Privileged Session Management Rules

These rules govern session isolation, real-time monitoring, and recording through the Privileged Session Manager (PSM):

• Record and store user sessions: Instructs the PSM to record full graphical video recordings and capture detailed text logs (including typed keystrokes, executed commands, and opened Windows GUI titles) for every session launched through the Vault. These recordings are encrypted and stored in designated recording Safes (PSMRecordings) for non-repudiation.
• Require privileged session monitoring and isolation: Mandates that end users connect to target hosts exclusively via the PSM proxy server rather than connecting directly from their client workstations. This prevents plaintext credentials from touching endpoint memory and isolates the target network from workstation-borne malware.

---

Baseline Rule Permanence and Immutability

A foundational architecture principle tested heavily on the CyberArk Defender exam is the permanence and immutability of Master Policy baseline rules.

Administrators cannot delete baseline rules from the Master Policy. CyberArk deliberately prevents rule deletion to guarantee that the core compliance framework remains intact across all versions and enterprise environments. The built-in rules represent standard audit controls mandated across global security frameworks.

While baseline rules cannot be deleted, administrators have precise administrative authority over them:

1. Enable or Disable Rules: Administrators can toggle a rule's operational status. For example, an organization not utilizing dual control can set Require dual control password access approval to disabled globally.
2. Modify Global Baseline Values: Administrators can adjust numerical values, such as changing the global default for Require password change every X days from 90 days to 60 days.
3. Configure Advanced Sub-Rules: Many rules feature subordinate options, such as specifying whether dual control allows self-approval or requiring ticketing systems to validate ticket state before access is granted.

---

Master Policy Exceptions: Architecture and Management

While global standardization is essential, real-world enterprise infrastructure contains heterogeneous systems with divergent operational requirements. A global mandate requiring 30-day password rotation may work well for Windows workstations but cause outages on database clusters or break-glass accounts. CyberArk addresses this through Master Policy Exceptions.

The Platform-Only Exception Rule

A critical exam fact: Master Policy exceptions can only be applied at the Platform level.

Exceptions cannot be applied directly to a Safe, an individual account, or an Active Directory user group. If an organization needs fifty specific database accounts to rotate every 7 days while all other accounts rotate every 90 days, administrators do not alter the Safe or the accounts. Instead, they create an exception on the specific target Platform to which those database accounts are bound.

Step-by-Step Configuration of Exceptions

1. Log in to the PVWA as a member of the Vault Admin or Auditors group with policy management permissions.
2. Navigate to Policies -> Master Policy.
3. Select the specific baseline rule requiring an exception (e.g., Enforce check-in/check-out exclusive access).
4. In the rule details pane, click Add Exception.
5. Select the target platform from the platform repository (e.g., UnixSSH-Emergency-BreakGlass).
6. Configure the platform-specific override value (e.g., setting the rule to Inactive or altering the parameter value).
7. Save the exception. The PVWA immediately displays an exception indicator badge next to the baseline rule, showing the number of active platform overrides.

Operational Use Cases for Exceptions

• Emergency Break-Glass Accounts: Global policy may mandate dual control and ticketing validation. However, during a catastrophic datacenter or network failure, ticketing systems and approvers may be offline. An exception applied to the BreakGlass-DomainAdmin platform disables dual control and reason-for-access, ensuring unhindered emergency recovery.
• High-Risk Tier-0 Identities: Standard infrastructure may rotate passwords every 90 days. An exception on the Domain-Controllers-Tier0 platform can enforce rotation every 24 hours.
• Service Accounts with Multiple Dependencies: Service accounts running background daemons cannot tolerate automatic password changes on release (OTP). An exception disables Perform password change on release for service account platforms while leaving it enforced for interactive administrator platforms.

---

Master Policy Compliance Architecture Table