Implementing Zero Standing Privilege with CyberArk

Overview

Zero Standing Privileges (ZSP) is a security model where no user or identity retains persistent privileged access. Instead, elevated access is provisioned dynamically on a just-in-time (JIT) basis and automatically revoked after use. CyberArk implements ZSP through its Secure Cloud Access (SCA) module, which creates ephemeral, scoped roles in cloud environments (AWS, Azure, GCP) that exist only for the duration of a session. The TEA framework -- Time, Entitlements, and Approvals -- governs every privileged access session.

Prerequisites

CyberArk Identity Security Platform (Privilege Cloud or self-hosted)
CyberArk Secure Cloud Access (SCA) license
Cloud provider accounts (AWS, Azure, GCP) with admin access for integration
ITSM integration (ServiceNow, Jira) for approval workflows
CyberArk Vault configured with safe management

Core Concepts

TEA Framework (Time, Entitlements, Approvals)

Component	Description	Configuration
Time	Duration of the privileged session	Min 15 minutes, max 8 hours, default 1 hour
Entitlements	Permissions granted during the session	Dynamically scoped IAM roles/policies
Approvals	Authorization workflow before access	Auto-approve, manager approval, or multi-level

ZSP Architecture

User requests access via CyberArk
        │
        ├── CyberArk evaluates request against policies:
        │   ├── Is user eligible for this access?
        │   ├── Does the request comply with TEA policies?
        │   └── Is approval required?
        │
        ├── [If approval needed] → Route to approver (ITSM/ChatOps)
        │
        ├── Upon approval:
        │   ├── CyberArk creates ephemeral IAM role in target cloud
        │   ├── Scopes permissions to minimum required entitlements
        │   ├── Sets session TTL (time-bound)
        │   └── Provisions temporary credentials
        │
        ├── User accesses cloud resources via session
        │   ├── All actions logged and recorded
        │   └── Session monitored for policy violations
        │
        └── Session expires:
            ├── Ephemeral role deleted
            ├── Temporary credentials revoked
            └── Zero standing privileges remain

CyberArk Components

Component	Role
Identity Security Platform	Central management and policy engine
Privilege Cloud Vault	Stores privileged credentials and keys
Secure Cloud Access	Creates/destroys ephemeral cloud roles
Endpoint Privilege Manager	Controls local admin and app elevation
Privileged Session Manager	Records and monitors privileged sessions

Implementation Steps

Step 1: Integrate Cloud Providers

AWS Integration:

Create a CyberArk integration role in AWS IAM
Configure cross-account trust policy allowing CyberArk to assume roles
Create IAM policies that define maximum allowed entitlements
Register AWS accounts in CyberArk SCA

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::CYBERARK_ACCOUNT:role/CyberArkSCARole"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
                "sts:ExternalId": "cyberark-external-id"
            }
        }
    }]
}

Azure Integration:

Register CyberArk as an enterprise application in Microsoft Entra ID
Grant CyberArk application permissions: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory
Create custom Azure roles with scoped permissions
Register Azure subscriptions in CyberArk SCA

GCP Integration:

Create a service account for CyberArk in GCP
Grant IAM Admin and Service Account Admin roles
Configure workload identity federation for cross-cloud access
Register GCP projects in CyberArk SCA

Step 2: Define Access Policies

Create policies that map job functions to cloud entitlements:

# CyberArk SCA Policy Example
policy_name: "developer-aws-read-access"
description: "Read-only access to AWS production for developers"
target_cloud: "aws"
target_accounts: ["123456789012", "987654321098"]

time_policy:
  max_duration: "4h"
  default_duration: "1h"
  business_hours_only: true
  timezone: "America/New_York"

entitlement_policy:
  aws_managed_policies:
    - "arn:aws:iam::aws:policy/ReadOnlyAccess"
  deny_actions:
    - "iam:*"
    - "organizations:*"
    - "sts:*"
  resource_restrictions:
    - "arn:aws:s3:::production-*"

approval_policy:
  approval_required: true
  approvers:
    - type: "manager"
    - type: "group"
      group: "cloud-security-team"
  auto_approve_conditions:
    - previous_approved_same_policy: true
      within_days: 7
  escalation_timeout: "2h"
  escalation_approver: "cloud-security-lead"

Step 3: Configure Session Monitoring

Set up privileged session recording and real-time monitoring:

Enable session recording for all ZSP sessions
Configure keystroke logging for SSH/RDP sessions
Set up real-time alerts for suspicious activities:
- Attempts to escalate privileges during session
- Access to resources outside policy scope
- Session duration exceeding 2x the normal pattern
Forward session metadata to SIEM

Step 4: Implement Approval Workflows

Integrate with ITSM tools for access request and approval:

ServiceNow: CyberArk SCA connector creates ServiceNow tickets for approval
Slack/Teams: ChatOps bot for quick approvals within messaging platforms
Jira: Integration for development-related access requests
Auto-Approval: Configure rules for low-risk, previously approved requests

Step 5: Migrate from Standing Privileges

Phase 1: DISCOVERY (Weeks 1-2)
    ├── Inventory all standing privileged roles across cloud accounts
    ├── Map users to their standing role assignments
    ├── Analyze CloudTrail/activity logs for actual permission usage
    └── Identify roles that can be converted to JIT

Phase 2: POLICY CREATION (Weeks 3-4)
    ├── Create ZSP policies based on actual usage analysis
    ├── Define TEA parameters for each policy
    ├── Configure approval workflows
    └── Test policies with pilot users

Phase 3: MIGRATION (Weeks 5-8)
    ├── Assign ZSP policies to pilot group
    ├── Remove standing privileges from pilot users
    ├── Monitor for access issues and adjust policies
    ├── Expand to additional teams incrementally
    └── Remove all standing privileges organization-wide

Phase 4: GOVERNANCE (Ongoing)
    ├── Monthly review of ZSP policy effectiveness
    ├── Quarterly entitlement optimization
    ├── Monitor for policy drift or standing privilege re-creation
    └── Report ZSP metrics to security leadership

implementing-zero-standing-privilege-with-cyberark