Identity, Access Management, and Monitoring
Identity, Access Management and Monitoring
This domain tests least privilege, unique identity, MFA into the CDE, and the logging that proves these controls operate.
Requirement 7 requires an access control model with least privilege and need-to-know (7.2.1) and role-based assignment (7.2.2). Requirement 8 requires unique IDs before access (8.2.1), MFA for all access into the CDE (8.4.2) and for remote network access (8.4.3), plus complexity and change rules where passwords are used (8.3.6, 8.3.9). Requirement 10 requires logs of all individual access to CHD (10.2.1), administrative actions, access to audit logs, invalid attempts and authentication changes, with user, event type, timestamp, success or failure and affected resource (10.3), synchronised time (10.3.3), retention of at least 12 months with the most recent three months immediately available (10.5.1), and at least daily review (10.4.1).
Cloud practice: federate identities to an IdP, forbid long-lived access keys, scope roles to specific resources, use permission boundaries and organisation policies, and keep break-glass accounts few, monitored and tested.
Worked example. An engineer's static access key is found in a repository and carries full administrator rights. Remediation is not just rotating the key. Replace it with federation: human access through SSO with MFA into a time-bound role; workloads using workload identity with narrowly scoped policies; secrets scanning in CI; a guardrail policy rejecting new long-lived keys. The old shared key never identified a person, so it also breached 8.2.1 and 10.2.1 - a separate finding from the exposure. Reasoning: one weakness often breaks several requirements; list each.
Traps. MFA on the console but not on CLI or API access into the CDE; shared service accounts used interactively; retention shorter than 12 months; logs the workload itself can delete; reviewing logs only when something looks wrong.