Shared Cloud Environment Complicates Isolation

The compromised workload runs in a multi-tenant cloud environment (shared subscription, Kubernetes cluster, or PaaS) where isolation actions may impact other tenants or business-critical services sharing the same infrastructure.

Signals

  • •The compromised resource shares a VPC/VNet, subnet, or Kubernetes namespace with production workloads owned by other teams
  • •Network security groups or firewall rules are broadly scoped, making surgical isolation difficult
  • •Container orchestration shows the compromised pod running on a shared node with other tenant workloads

Pivot Actions

  1. 1.Apply granular network policies (Kubernetes NetworkPolicy, NSG rules) to isolate the compromised workload without blocking shared-service traffic
  2. 2.Snapshot the compromised VM or container image for offline analysis, then redeploy a clean instance
  3. 3.Coordinate with the cloud platform team to identify all resources sharing the same trust boundary and assess lateral-movement risk
  4. 4.Use cloud-native security tools (Azure Defender, AWS GuardDuty, GCP SCC) to scope activity across the shared environment
  5. 5.Implement identity-level isolation (revoke the compromised service principal or IAM role) rather than network-level isolation

Alternate Evidence Sources

  • •Cloud provider activity and management-plane logs (CloudTrail, Azure Activity Log, GCP Admin Activity)
  • •Kubernetes audit logs and container runtime logs (containerd, CRI-O)
  • •Cloud-native threat-detection findings (GuardDuty, Defender for Cloud, SCC)