ArcanaIncident-response documentationBrowse the feedTemplates
Back to feed
Runbook · Contain
RB-CONTAIN-015

Cloud Workload Isolation

1. Prerequisites

  • Identifier of the impacted cloud workload (instance ID, container/pod ID, function name, service ID)
  • Authorisation to isolate the workload (workload owner notified or break-glass authority)
  • Write access to the cloud account / subscription / project / tenancy
  • Pre-defined "quarantine" security group / NSG / firewall rule (deny all ingress and egress except investigator access)
  • Snapshot destination (account / region / project where snapshots will be stored)
  • Cloud provider console or CLI for the impacted account
  • SIEM / cloud control plane log access for verification
  • Snapshots already taken before isolation begins (see RB-EVIDENCE-005: Cloud Workload Snapshot Acquisition)

2. Step-by-Step Instructions

Common Failure Modes

  • Detaching the network interface (which can also destroy in-flight state) before isolating with a quarantine security group
  • Leaving the instance role attached — attacker can continue making API calls using the role credentials even after network isolation
  • Terminating the workload during isolation — keep it running for forensic analysis

  1. Confirm Workload Identity and Authorisation

    • Verify the workload identifier matches the incident scope
    • Confirm authorisation from the workload owner or Incident Commander
    • Notify dependent services / on-call owners before isolation if the workload is in production

  2. Capture Pre-Isolation State

    • Record the workload's current security group / NSG, instance role / managed identity, public IP, attached volumes, and running state
    • Record any load balancer / target group memberships
    • Record any auto-scaling group membership (so the group does not silently replace the workload)

  3. Suspend Auto-Replacement

    • If the workload is in an auto-scaling group, detach it or suspend the group's launch/terminate processes
    • If it's a Kubernetes pod, cordon the node and patch the controller (Deployment / StatefulSet) to prevent re-scheduling
    • If it's a serverless function, throttle concurrency to zero or disable the function

  4. Revoke Instance / Workload Credentials

    • Detach or replace the instance role / managed identity / workload identity from the workload
    • Revoke any active sessions issued to the role (e.g. AWS aws iam delete-access-key for any access keys, then a deny-all session policy attached to the role to invalidate live sessions)
    • Rotate any credentials the workload had access to (secrets manager entries, environment variables, hardcoded credentials)

  5. Network-Isolate the Workload

    • Replace the workload's security group / NSG with the pre-defined quarantine ruleset
    • Confirm new rules are active by reviewing the live security group / NSG attachment
    • For Kubernetes, apply a NetworkPolicy that denies all ingress/egress except investigator namespaces

  6. Verify Isolation

    • From the cloud control plane log, confirm no new API calls are being made by the instance role
    • From the workload (if reachable via investigator path), confirm outbound network is blocked
    • From SIEM, confirm no further alerts are being generated by the workload

  7. Hand Off to Replacement

    • For workloads in production, trigger replacement from known-good IaC / image (see RB-RECOVERY-002: Clean System Rebuild) so service continuity is restored
    • Keep the isolated workload running for forensic analysis until investigation is complete; do not terminate prematurely

3. Post-Action

  • Record all isolation actions and timestamps in the incident record
  • Notify the Incident Commander and Cloud Security / Platform Team that isolation is complete

Contributor

Firstname Lastname GitHub: https://github.com/account

Contributed to the Arcana Incident Response Documentation Framework.