ACCESS MANAGEMENT RUNBOOK

JML · Access Requests · Recertification · PAM · Break-Glass · Service Accounts · Secrets · Vendor Access · MFA

Table of Contents

1. Purpose and Scope
2. The Two Operating Models, CERG-Owned vs. Cyber-Contributing
3. Joiner / Mover / Leaver
4. Access Request and Approval
5. Access Review and Recertification
6. Privileged Access Management (PAM)
7. Break-Glass Access
8. Service Accounts and Machine Identities
9. Secrets, API Keys, and Tokens
10. Vendor Access
11. MFA Enrollment and Exception
12. Roles and Responsibilities
13. Regulatory and Framework Alignment Summary
14. Document Control

1. Purpose and Scope

The Access Management Standard explicitly says implementation details, IdP baselines, MFA enrollment, PAM workflows, recertification runbooks, are maintained separately. This runbook is that “separately.” It defines the executable workflows behind every identity decision CERG-STD-AC-001 requires.

The runbook covers every identity in the environment: human (employee, contractor), machine (system, service, agent), and vendor / third-party.

One Runbook, Two Owners

Many organizations run IAM under IT (not Cyber). The runbook is written so it is complete under either operating model: where IAM reports into CERG, this is the operational manual; where IAM reports outside CERG, this is the cyber-required content the IAM team must implement or formally diverge from with documented compensating controls.

2. The Two Operating Models: CERG-Owned vs. Cyber-Contributing

Where IAM is outside CERG, every requirement below is either implemented by the IAM team, or a formal documented divergence is recorded in the risk register per CERG-PRC-RM-001.

3. Joiner / Mover / Leaver

3.1 Joiner

3.2 Mover

3.3 Leaver

3.4 Involuntary or High-Sensitivity Leavers

Same as 3.3 with all SLAs collapsed to “immediately” and the SOC alerted to monitor for credential reuse and data exfiltration.

4. Access Request and Approval

4.1 Request Patterns

4.2 Approval Chain

4.3 Approval Discipline

• Approvers are accountable parties; rubber-stamping is detected via approval-velocity metrics.
• Requests that violate SoD rules are blocked at submission; override requires named additional approver.
• Time-bound roles auto-expire; no implicit renewal.

5. Access Review and Recertification

5.1 Cadence

5.2 Recertification Workflow

1. Campaign launched via IGA with named reviewers.
2. Reviewers presented with: identity, current entitlements, last-used dates, role rationale.
3. Decision per entitlement: Certify · Modify · Remove. “Bulk Certify” is permitted only where reviewer has reviewed actual access patterns.
4. Auto-removal of Removed entitlements within 5 business days.
5. Audit log captured per IGA for the cycle.
6. Exceptions flagged to Engineering, Identity for follow-up.

5.3 Anti-Rubber-Stamp Controls

• Reviewers who certify > X% of items in < Y minutes are flagged for sampling-audit.
• Certifications of dormant accounts (> 60 days unused) require explicit justification.
• Reviewers who never modify or remove are sampled.

5.4 Privileged Access Review Evidence Checklist

Every quarterly privileged access review evidence package must be complete enough for an auditor, the Evidence Librarian, or a future reviewer to reperform the review without asking the reviewer what they meant. Store the package as an Access Review Record / Evidence Index Entry per CERG-GOV-CAT-002 and evidence quality rules in CERG-PRC-AUD-001.

A privileged access review is incomplete if the population is missing, the reviewer lacks authority, decisions are not recorded at entitlement level, removals are not validated after implementation, or exceptions are retained only in email/chat rather than the exception or risk process.

6. Privileged Access Management (PAM)

6.1 Coverage

Every privileged action across the in-scope estate is mediated by PAM. Specifically:

• Domain admin / cloud root / SaaS tenant admin.
• Network device, firewall, hypervisor, storage admin.
• Database privileged accounts.
• OT engineering interfaces and jump-server access.
• CUI workspace admin.

6.2 PAM Workflow

6.3 PAM Operating Disciplines

• No direct admin password use; PAM-only.
• Standing privileged access avoided where JIT is supported.
• Quarterly audit of dormant privileged accounts.
• Session recordings sampled by Risk on a quarterly cadence; high-risk roles sampled monthly.

7. Break-Glass Access

7.1 Definition

Break-glass accounts are the credentials of last resort, used only when normal identity systems are unavailable or compromised. Misuse is a P1 detection per CERG-STD-LM-001 Section 11.

7.2 Operating Rules

8. Service Accounts and Machine Identities

8.1 Preference Order

1. Workload identity (cloud-native): managed identities, IRSA, workload identity federation. Preferred.
2. Short-lived issued credentials via STS / IdP-integrated token service.
3. Long-lived static credentials in secrets manager, only when 1–2 are infeasible.

8.2 Lifecycle

8.3 Service Account Disciplines

• No human use of service accounts.
• No interactive logon for service accounts; flagged and alerted if observed.
• No service accounts in default admin groups (Domain Admins, etc.).
• Service accounts in OT scope follow tighter restrictions and engineering review.

9. Secrets, API Keys, and Tokens

This section operationalizes CERG-STD-CR-001 Section 7. See that standard for storage and rotation requirements.

10. Vendor Access

10.1 Onboarding

10.2 Monitoring

• Vendor sessions recorded per PAM policy.
• Geographic anomalies trigger alerts.
• Quarterly review of all active vendor access.
• Off-boarding triggered by project closeout, vendor termination, or country reclassification.

11. MFA Enrollment and Exception

11.1 Enrollment

11.2 Exceptions

MFA exceptions are time-bounded and tracked.

Phishing-resistant MFA coverage is reported as ID-001 in CERG-GOV-MTR-001.

12. Roles and Responsibilities

13. Regulatory and Framework Alignment Summary

14. Document Control

Source: procedures/CERG-PRC-AC-002_Access_Management_Runbook.md · Download .md · View on GitHub