Runbook 03 — Enterprise Container Investigation
Runbook Information
Section titled “Runbook Information”| Property | Value |
|---|---|
| Runbook Name | Enterprise Container Investigation |
| Module | Module 06 — Container Security |
| Runbook Number | Runbook 03 |
| Assessment Type | Enterprise Container Security Investigation |
| Estimated Duration | 1–3 Days |
| Audience | Cloud Penetration Testers, Container Security Engineers, DevSecOps Engineers, Incident Responders, Cloud Security Consultants |
| Framework | GoHackersCloud Enterprise Container Security Assessment Framework |
Purpose
Section titled “Purpose”This runbook provides a structured methodology for performing a complete enterprise container security investigation following a suspected security incident or as part of a proactive security assessment.
Unlike a standard configuration review, this investigation focuses on identifying indicators of compromise, validating runtime security controls, analyzing attacker activity, assessing business impact, and producing executive-ready investigation reports.
Investigation Scope
Section titled “Investigation Scope”Review the following components:
- Docker Engine
- Kubernetes Clusters
- Amazon EKS
- Azure AKS
- Google GKE
- Container Images
- Container Registries
- Runtime Security
- Linux Security Controls
- Kubernetes Audit Logs
- CI/CD Pipeline
- Software Supply Chain
- IAM & RBAC
- Network Activity
- Incident Response Readiness
Investigation Methodology
Section titled “Investigation Methodology”Incident Intake
↓
Scope Definition
↓
Evidence Collection
↓
Environment Enumeration
↓
Container Investigation
↓
Runtime Analysis
↓
Identity Investigation
↓
Network Investigation
↓
Timeline Reconstruction
↓
Business Impact Assessment
↓
Root Cause Analysis
↓
Executive ReportingPhase 1 — Incident Intake
Section titled “Phase 1 — Incident Intake”Objectives
Section titled “Objectives”- Understand the reported security event.
- Identify affected business services.
- Confirm investigation scope.
- Assign investigation priorities.
- Establish communication channels.
Collect
Section titled “Collect”- Incident ticket
- Initial alerts
- SOC notifications
- Customer reports
- Threat intelligence
- Previous investigations
Phase 2 — Scope Definition
Section titled “Phase 2 — Scope Definition”Identify:
- Affected cloud provider
- Kubernetes clusters
- Docker hosts
- Container registries
- CI/CD pipelines
- Business applications
- Production workloads
- Critical assets
Validate
Section titled “Validate”- Business ownership
- Environment classification
- Regulatory requirements
- Data sensitivity
Phase 3 — Evidence Collection
Section titled “Phase 3 — Evidence Collection”Collect evidence before making any changes.
Acquire:
- Docker configuration
- Running container list
- Kubernetes manifests
- Runtime logs
- Kubernetes Audit Logs
- Cloud audit logs
- Authentication logs
- Registry logs
- CI/CD logs
- SIEM alerts
- Network captures
- System timestamps
Maintain evidence integrity throughout the investigation.
Phase 4 — Environment Enumeration
Section titled “Phase 4 — Environment Enumeration”Document the enterprise environment.
Review:
- Docker versions
- Kubernetes versions
- Worker nodes
- Control plane components
- Running containers
- Images
- Registries
- Cloud integrations
Validate
Section titled “Validate”- Inventory accuracy
- Workload ownership
- Administrative access
- Cluster health
Phase 5 — Container Investigation
Section titled “Phase 5 — Container Investigation”Review:
- Running containers
- Stopped containers
- Privileged containers
- Root containers
- Mounted volumes
- HostPath mounts
- Resource limits
- Container metadata
Identify
Section titled “Identify”- Suspicious workloads
- Unknown containers
- Unauthorized deployments
- Configuration drift
Phase 6 — Runtime Security Investigation
Section titled “Phase 6 — Runtime Security Investigation”Analyze runtime behavior.
Review:
- Process execution
- Shell access
- Privilege escalation
- File modifications
- Runtime alerts
- Falco events
- Container lifecycle
- Resource anomalies
Validate
Section titled “Validate”- Runtime policies
- Security monitoring
- Threat detection
- Workload isolation
Phase 7 — Identity & Access Investigation
Section titled “Phase 7 — Identity & Access Investigation”Review:
- IAM Roles
- Kubernetes RBAC
- Service Accounts
- Cloud identities
- Authentication logs
- Administrative activity
- Privileged sessions
- Temporary credentials
Identify
Section titled “Identify”- Privilege escalation
- Unauthorized access
- Excessive permissions
- Credential misuse
Phase 8 — Network Investigation
Section titled “Phase 8 — Network Investigation”Review:
- Network Policies
- East-West traffic
- North-South traffic
- DNS activity
- External connections
- Ingress traffic
- Egress traffic
- Service Mesh communications
Validate
Section titled “Validate”- Network segmentation
- Unauthorized communication
- Lateral movement
- Data exfiltration attempts
Phase 9 — Supply Chain Investigation
Section titled “Phase 9 — Supply Chain Investigation”Review:
- Source code repository
- CI/CD pipelines
- Build history
- Image provenance
- Image signatures
- Software Bill of Materials (SBOM)
- Registry activity
- Artifact integrity
Identify
Section titled “Identify”- Compromised images
- Malicious dependencies
- Unauthorized builds
- Supply chain manipulation
Phase 10 — Timeline Reconstruction
Section titled “Phase 10 — Timeline Reconstruction”Build a complete timeline.
Include:
- Initial compromise
- Authentication events
- Container deployment
- Runtime activity
- Configuration changes
- Privilege escalation
- Network communication
- Detection events
- Incident response actions
Document all timestamps using UTC where possible.
Phase 11 — Business Impact Assessment
Section titled “Phase 11 — Business Impact Assessment”Evaluate:
- Business services affected
- Sensitive data exposure
- Customer impact
- Financial impact
- Regulatory implications
- Operational disruption
- Recovery requirements
- Reputation risk
Prioritize findings according to business impact rather than technical severity alone.
Phase 12 — Root Cause Analysis
Section titled “Phase 12 — Root Cause Analysis”Determine:
- Initial attack vector
- Failed security controls
- Misconfigurations
- Identity weaknesses
- Process failures
- Governance gaps
- Monitoring deficiencies
Identify both technical and organizational contributing factors.
Risk Classification
Section titled “Risk Classification”Classify findings using enterprise risk ratings.
| Severity | Description |
|---|---|
| Critical | Immediate enterprise-wide security risk |
| High | Significant compromise requiring urgent remediation |
| Medium | Moderate security weakness |
| Low | Minor security issue |
| Informational | Observation or improvement recommendation |
Evidence Checklist
Section titled “Evidence Checklist”Collect and preserve:
- Docker configurations
- Kubernetes manifests
- Runtime logs
- Kubernetes Audit Logs
- Cloud audit logs
- Registry activity logs
- IAM activity
- RBAC configuration
- Network captures
- SIEM alerts
- Screenshots
- CLI outputs
- Timeline documentation
Ensure evidence is securely stored, timestamped, and handled according to organizational forensic procedures.
Investigation Deliverables
Section titled “Investigation Deliverables”Prepare:
- Executive Summary
- Investigation Scope
- Timeline of Events
- Technical Findings
- Root Cause Analysis
- Business Impact Assessment
- Risk Register
- Security Scorecard
- Evidence Inventory
- Remediation Roadmap
- Executive Presentation
Common Enterprise Findings
Section titled “Common Enterprise Findings”Enterprise investigations frequently reveal:
- Containers running with excessive privileges
- Compromised service accounts
- Weak Kubernetes RBAC
- Missing runtime monitoring
- Unauthorized container deployments
- Insecure CI/CD pipelines
- Unsigned container images
- Excessive IAM permissions
- Weak network segmentation
- Inadequate incident response procedures
Enterprise Best Practices
Section titled “Enterprise Best Practices”- Preserve evidence before making changes.
- Follow documented incident response procedures.
- Correlate runtime, Kubernetes, cloud, and SIEM logs.
- Validate workload integrity before restoration.
- Apply least privilege across Docker and Kubernetes.
- Continuously monitor runtime activity.
- Secure the software supply chain with signed images and SBOM validation.
- Conduct post-incident reviews and update security controls.
- Document all investigation activities and decisions.
- Continuously improve governance based on lessons learned.
Success Criteria
Section titled “Success Criteria”The investigation is complete when:
- The root cause has been identified.
- Affected assets have been documented.
- Evidence has been preserved.
- Business impact has been assessed.
- Risks have been prioritized.
- Executive and technical reports have been completed.
- Remediation recommendations have been approved and documented.
Runbook Summary
Section titled “Runbook Summary”This runbook provides a comprehensive methodology for conducting enterprise container security investigations using the GoHackersCloud Enterprise Container Security Assessment Framework.
By following this structured approach, Cloud Penetration Testers and Cloud Security Consultants can investigate container-related security incidents, analyze runtime behavior, identify root causes, evaluate business impact, and produce executive-ready reports that support informed decision-making and long-term security improvements.
Next Module
Section titled “Next Module”➡️ Module 07 — Serverless Security
In the next module, you will learn how to assess and secure serverless platforms including AWS Lambda, Azure Functions, and Google Cloud Functions. You will evaluate function security, IAM permissions, event-driven architectures, API integrations, secrets management, monitoring, and enterprise serverless security using the GoHackersCloud Enterprise Cloud Penetration Testing Framework.