Cloud incident response
Investigate identities, APIs, and delegated access as well as workloads.
Respond to identities and infrastructure together
Cloud incident response investigates unauthorized activity across identities, management APIs, workloads, and managed services. A compromised virtual machine is only one possible starting point. An exposed access credential, malicious application grant, or altered storage policy can create serious impact without a traditional endpoint infection.
Begin by identifying the account or tenant, affected resource, suspected identity, and time window. Those boundaries are provisional: new evidence may show that a role had access across several accounts or that the first visible workload was created after the original compromise.
A suspicious workload appears
Consider a fictional team that receives an unexpected cloud spending alert. Several compute instances were created outside its normal deployment process. The responder checks who requested their creation, which role or credential was used, which images and network settings were selected, and whether the requests succeeded.
The team also examines how that identity obtained authority. A long-lived key might have leaked, or a legitimate role might have been assumed through an abused trust relationship. Deleting the instances addresses a visible symptom but leaves the underlying identity path available unless it is investigated and restricted.
Cloud audit logs help reconstruct management activity. Workload logs, identity-provider events, network records, and service-specific data events may answer different questions. Keep the distinction clear when explaining whether the team observed resource creation, code execution, or access to stored information.
Containment has dependencies
Disabling a credential or changing a role can interrupt production automation. Work with the service owner to identify dependent jobs and choose an authorized containment action. Immediate restriction may still be necessary when harm is ongoing, but the decision and its business effects should be recorded.
Preserve relevant configuration and records before deleting short-lived resources where practical. Avoid treating an exported virtual-machine disk as complete cloud evidence: identity settings, API actions, storage policies, and other control-plane records exist elsewhere.
Review whether the actor created additional accounts, access keys, application grants, scheduled workloads, or modified images. Password changes do not automatically invalidate every cloud credential or session; the service's credential and revocation behavior determines what is required.
Define recovery evidence
Recovery should establish that unauthorized access paths were addressed, required services function, and monitoring covers the relevant actions. Rotate affected secrets through a controlled process and verify dependent services rather than assuming successful replacement because a key was generated.
For practice, run a tabletop exercise using the spending alert. Ask who can restrict the role, preserve records, approve workload deletion, and communicate financial impact. Then introduce a second account reached through the same role. Incident response provides coordination, while Incident containment keeps urgent actions connected to a reasoned plan.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
NIST: Incident Response Recommendations, SP 800-61 Rev. 3