RB-CONTAIN-015: Cloud Workload Isolation

Document Control

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.