Respond to Identity Compromise and Cloud Control Incidents
Contain compromised authority and scope cloud control-plane change while retaining the evidence needed for safe recovery.
In this lesson, you will learn to:
- Select containment and evidence-preservation actions for identity and cloud-control incidents based on the form of authority involved.
Respond to Identity Compromise and Cloud Control Incidents
Distinguish compromised identities from cloud control-plane changes and coordinate containment without destroying the evidence needed to understand scope.
Contain the authority that was actually misused
An identity incident is not always a stolen password. The affected authority may be an active session, an authenticator, a password-reset channel, a service principal, an OAuth consent grant, an API key, a privileged role assignment, or a delegated mailbox rule. Each permits different actions and needs a different containment decision. Resetting a password may leave an active session or application grant intact; disabling an account without planning may interrupt a critical service and encourage an unsafe workaround.
Start by identifying the principal, the authority type, the observed actions, the highest-risk reachable resources, and the evidence sources that record its use. Preserve relevant sign-in, administrative, application, and endpoint records before retention windows or automated cleanup remove them. Coordinate with the service and identity owners to revoke or restrict the suspected authority, increase scrutiny on related activity, and protect emergency access from casual use.
Make the trade-off explicit. A quick broad disable can be justified when active harm is likely, but the incident lead should record who authorized it, what service impact is expected, and what review will determine safe restoration. A common mistake is performing many simultaneous resets without tracking which sessions, grants, or recovery factors remained effective. A containment log enables the team to confirm what changed rather than assuming the risk disappeared.
Scope cloud control-plane changes before rebuilding services
Cloud incidents can alter the management plane as well as the workload itself. A new role assignment, changed network rule, logging change, access key, snapshot, automation job, or resource policy may widen access across multiple services. Begin by separating evidence about control-plane actions from evidence about data-plane behavior. Ask which account, project, subscription, tenant, or organization boundary is affected; which identities executed the changes; what resources became reachable; and whether the relevant audit records are complete and protected.
Coordinate containment in an order that preserves options. Stabilize evidence destinations, restrict clearly unsafe access paths, protect break-glass administration, and place guardrails around high-impact changes. Avoid immediately deleting unfamiliar resources when they may show how persistence or exfiltration occurred. Record timestamps, resource identifiers, actor identity, before-and-after settings, and the person who approved each action. This helps both technical responders and leaders understand what was confirmed rather than inferred.
Recovery is not simply reverting every change. Validate dependencies and intended business effects in a controlled sequence, then monitor for re-created roles, recurring automation, unusual sign-ins, or anomalous data access. The most important leadership contribution is to maintain a shared decision picture: current impact, confidence in scope, actions taken, operational trade-offs, and the next condition that would change the response plan.
Resources
- MITRE ATT&CK Cloud Matrix — Use the cloud matrix to investigate and communicate relevant adversary techniques without assuming every listed technique occurred.