Four thousand alerts, a two-person SOC, and a miner that waited 26 hours
A two-analyst SOC feeds about 4,200 Prisma Cloud alerts per month into Cortex XSIAM. Seventy-eight percent come from three policies: image vulnerability critical, public S3 bucket, and runtime unexpected process. Mean time to acknowledge is 19 hours and mean time to resolve is 6 days. Last month a production container ran a mining binary; the runtime alert was created correctly but queued behind vulnerability alerts and was acted on after 26 hours, by which time the pod had egressed about 4 GB. The review found no asset-criticality enrichment, every cloud alert mapped to medium severity, and 61 percent of closures written as benign known batch job with the same copy-pasted comment. The CISO wants mean time to acknowledge under one hour for runtime threats and a defensible process.
1. Redesign the detection-to-response pipeline. Be specific about severity mapping, deduplication, routing and SLA, and about which alerts should never become incidents.
Read the worked answer
The pipeline fails because everything is medium and everything shares one queue. Rebuild in four layers.
Severity mapping. Replace flat medium with a mapping table: runtime threat behavior (miner, reverse shell, credential access, container escape, malware) maps to high or critical; identity plus internet exposure plus sensitive data maps to high; posture findings on non-production assets map to low and are not paged. Derive severity from behavior and asset context, not from the source product's label.
Correlation and dedupe. Group by resource and policy over a time window so 40 pods running the same vulnerable image digest become one incident, not 40. Enrich every alert with asset criticality from tags, owning team, internet exposure, and identity privilege level before it reaches a queue.
Routing. Runtime threats page the container platform on-call through the same tooling as other production incidents. Posture findings create tickets in the owning team's backlog. Vulnerability findings aggregate to the image and go to the AppSec backlog; a per-pod vulnerability alert should never become an incident. That alone removes most of the 78 percent.
SLA by class. Runtime: 15 minutes to acknowledge, one hour to contain. Identity or exposure: one hour. Posture: five business days.
Sanity check capacity: two analysts cannot work 4,200 alerts. After tuning, target a few hundred actionable items per month and verify the number before declaring the design done.
2. Sixty-one percent of closures are the same copy-pasted benign batch job comment. What is the correct fix, and what risk does the fix introduce?
Read the worked answer
Both halves are broken: the alert is genuinely expected, and the closure process is unauditable. Fix the source first.
Tune at the detection layer, not in the SOC queue. Scope the runtime policy to the batch namespace and image digests, or establish a learned baseline for that workload, so the expected process no longer generates an alert. Keep detection active for new digests so a rebuilt image is reviewed again. Analysts closing the same alert 500 times is a signal that the policy owner is not doing their job.
Then make closures structured. A benign close must carry a reason code from a fixed list, a link to evidence, and an expiry that triggers re-review in 90 days. Audit a small sample monthly, and report repeat-benign rates by policy as tuning debt.
The risk the fix introduces is real: tuning narrows coverage, and a genuine event inside a familiar pattern gets missed. That is exactly the failure mode in the miner incident, where a real alert sat behind a wall of known noise. Mitigate rather than pretend: keep a lower-severity version of the tuned detection so it still records, review a sample of tuned-scope events each quarter, and require security engineering sign-off on any tuning that removes a behavior from detection entirely.
3. The miner incident had a 26-hour dwell time. What do you change in the response process, and which metrics prove the change worked?
Read the worked answer
The detection worked; the routing and ownership failed. Lead with that, because it directs the fix at queue design rather than at sensor tuning.
Runbook for container runtime threats:
- Acknowledge within 15 minutes; identify the process tree, image digest and pod owner before touching the pod.
- Enrich from the alert: is the workload in production, what can its role reach, has there been outbound traffic to unknown destinations.
- Contain within one hour: deny egress for the namespace, cordon the node, snapshot and scale the workload down.
- Eradicate the entry vector: rebuild from a clean base, patch the exposed service, rotate the pod credentials.
- Scope: other pods on the node and other deployments on the same digest.
- Post-incident review within five business days.
Gaps to close beyond the runbook: alert on anomalous egress volume and mining-pool DNS, since 4 GB left the network without a second signal; assign runtime alerts to a named owning team rather than a shared queue; and add a quarterly purple-team exercise that runs a harmless miner-like binary in a canary namespace to prove detection, routing and containment end to end.
Metrics that prove it: MTTD, MTTA, time to contain (target one hour), MTTR, plus percentage of runtime alerts routed to a named owner and percentage of runbook steps executed without escalation. Track MTTA per alert class, not as a single average, or the posture backlog will keep hiding runtime performance.