Incident scoping starts with what was observed, where it ran, and what remains unknown. Process activity, workload identity, and event outcomes can give responders a concrete starting point. This guide describes an investigation workflow; it does not present a measured response time or a real incident case study.
01
Confirm the Finding and Its Outcome
Start with the triggering rule, event time, process ancestry, and reported outcome. A shell launch, a credential read, and an outbound connection attempt are separate observations; distinguish a completed operation from a failed attempt before drawing conclusions.
Check capture gaps and node coverage. An alert stream can show activity worth investigating without proving every step of an attack. The runtime threat detection workflow illustrates how process evidence and event outcomes can be reviewed together.
02
Map the Evidence to Workloads
Associate the finding with its namespace, pod, container, image digest, and owning team where available. Include linked request context only when instrumentation captured it. Preserve timestamps and identifiers so responders can check the same evidence in their other systems.
Keep observed process relationships separate from inferred attack paths. A service dependency or topology edge is not proof of lateral movement. Expand the investigation using corroborating events, control-plane audit records, and other available evidence.
03
Integrating with Existing Playbooks
Hand off the event sequence, affected workload identifiers, owner, evidence sources, and known capture limitations. Record which scope statements are supported by observations and which still need investigation.
Make containment decisions through your incident playbook, with the team responsible for the workload. Record the requested action and its confirmed outcome separately. After the incident, review missing evidence and update the collection or handoff process where it would help the next investigation.
Methodology notes
- Review event outcomes, coverage, and capture gaps before interpreting a finding.
- Associate observations with workload identifiers and timestamps; include request context only where captured.
- Keep observations, hypotheses, requested actions, and confirmed outcomes distinct in the incident handoff.
Sources and references
- NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide
NIST
- Kubernetes Auditing
Kubernetes Documentation
- MITRE ATT&CK Framework
MITRE
Weekly email
Runtime Evidence
One email a week: a runtime finding worth understanding, how it was investigated, and what to check in your own clusters. No product pitches in disguise; unsubscribe in one click.
