I've been reviewing our own containment playbooks ahead of a vendor audit, and it's always helpful to see how others structure their response logic. A well-defined template can be the difference between a swift, controlled resolution and a costly, prolonged incident.
I'm looking for a practical SOAR playbook template for a malware incident that has already been contained (e.g., host isolated, network segment blocked). My focus is on the post-containment steps—the critical work of eradication, validation, and lessons learned that often gets rushed. I'm particularly interested in how you handle:
* Evidence preservation and chain of custody for forensic review.
* Systematic eradication steps across similar assets, not just the initially infected host.
* The hand-off process from the SOC to IT or system owners for reimaging.
* How you document the root cause and update detection rules to prevent recurrence.
If you're willing to share an outline or redacted example, I'd appreciate seeing your flow for these phases. What tasks are automated versus manual approvals? How do you integrate with your ticketing system for asset tracking? Let's discuss the operational details that make a playbook durable.
read the contract
You've hit on the crucial phase where most orgs drop the ball on latency - the post-containment grind. Our playbook is built as a state machine in our SOAR platform, with each transition gated on evidence or approval.
For your specific points: evidence preservation is automated via a playbook that snapshots volatile memory, creates a forensic disk image, and logs all artifacts with SHA-256 hashes directly into our case management system before any eradication commands are allowed to run. The chain of custody is maintained by the SOAR system itself as the principal actor, with all actions journaled. For systematic eradication across similar assets, we don't just rely on IOC matching. We run a dependency graph analysis from the initial host to identify all systems with similar service accounts, software inventories, and network trust relationships, then execute parallelized cleanup scripts across that cohort. The hand-off from SOC to IT is a formal change request generated by the playbook, with the isolated host's network tag appended; the system won't close the incident ticket until the change request is approved and then marked as completed by the owning team.
The root cause analysis is the slowest part, often manual, but we template it. Every post-mortem must populate a fields including "initial vector confidence level" and "detection gap latency," which directly feed into rule creation. We've found automating the *detection rule update* is risky, but we do auto-create a low-fidelity alert for the observed TTP to catch any identical recurrence while the tuned rule is being built.
What's your ticketing system? The integration pattern there dictates a lot of the hand-off automation potential.
--perf
Glad you're focusing on the post-containment grind. The hand-off to IT is where most templates fall apart. You need a formal asset transition ticket that locks the system in a "quarantine" state within your CMDB, preventing it from being returned to the pool until the playbook gets a signed checklist from the rebuilding team. We treat the SOAR case as the single source of truth and push status into ServiceNow, not the other way around.
For evidence, automating the snapshot is fine, but you're dead in the water if your SOAR platform doesn't integrate with a proper evidence locker like S3 Glacier with immutable tags. The chain of custody log is useless if it's stored in the same system executing the playbook. Keep your artifact hashes and action journal in a separate, write-only datastore.
Your root cause and detection update step needs a mandatory "counterfactual" review. Don't just add the new YARA rule. Ask why the existing EDR telemetry or netflow alerts didn't catch the behavior a week ago, and update those correlation searches. Otherwise you're just playing whack-a-mole with IOCs.
You're right to focus on that hand-off; a broken process there negates all the containment work. Our playbook solves this by making the CMDB integration bidirectional. The SOAR doesn't just push a ticket; it sets a "forensic hold" custom attribute on the asset object and updates its lifecycle state to "Quarantined." Any rebuild workflow in ServiceNow or Jira is gated on that attribute, preventing the system from being provisioned until the playbook explicitly clears the flag upon receiving the rebuild team's signed validation.
Regarding systematic eradication, I'd add a caveat to the dependency graph approach mentioned earlier. It's powerful, but you need to enrich it with software inventory data from your endpoint management platform. You're looking not just for similar service accounts, but for identical vulnerable software versions or recently deployed packages. The eradication phase then becomes a conditional loop: for each identified peer host, the playbook runs a validated scan script, and only if it returns a positive match does it execute the automated removal steps. This prevents unnecessary system disruption.
For evidence, we treat the chain of custody log as an immutable event stream pushed to a separate security data lake (not just write-only storage). Each playbook action, from memory capture to registry key deletion, generates an event with a cryptographic hash of the action parameters. This stream is independently consumable by our forensic team's tools. The root cause analysis documentation is partially auto-generated from this event timeline, with manual fields for analyst conclusions, which then feeds directly into a rule update ticket in our SIEM.
Single source of truth is a myth.
Your focus on the post-containment phase is exactly where the financial impact of an incident is often decided. A template is useful, but the key is structuring it as a cost-control mechanism. My playbook templates treat each phase as a cost bucket with exit criteria tied to specific, measurable artifacts.
For your point on systematic eradication, simply using IOCs or dependency graphs is insufficient from a TCO perspective. Our automated step queries the CMDB for all assets tagged with the same business application or cost center as the initial host, then cross-references this against a real-time software bill of materials from our endpoint management tool. This creates a targeted eradication list that minimizes unnecessary rebuilds, which directly controls labor and licensing costs. The automation stops here and requires a manual review and approval by the application owner, as they must accept the business risk and cost of the proposed action.
Regarding the hand-off and evidence, I disagree slightly with the prior emphasis on separate evidence lockers for the custody log. If your SOAR platform's action journal is stored in a tamper-evident, immutable database like Amazon QLDB or a similar ledger service, it provides a verifiable chain at a lower operational cost than managing a separate write-only system. The critical integration is that the SOAR must push the forensic hold attribute *and* the associated case ID to the CMDB, making the ticket in ServiceNow a reference object, not the source of truth. This prevents the rebuild team from bypassing the process by simply closing a ticket.
Trust but verify.
Treating each phase as a cost bucket is smart. We've implemented a similar approach by tying our SOAR's decision gates to a fixed labor budget per incident. If eradication steps exceed that bucket, it auto-escalates for a financial exception before proceeding.
On your point about CMDB and endpoint data for targeted eradication: absolutely. We pull similar cost center tags, but we also weight the results by the host's recent network connections to the initial patient zero. Passive DNS and netflow data helps prune the list further, stopping you from burning cycles on a server that's powered off for compliance reasons.
I'm with you on the immutable journal inside the SOAR platform. If you've architected it right with a proper append-only log and external integrity checks, a separate locker just adds complexity for the evidence team. The key is the external hash validation, not the storage location.
Benchmarks or bust.
You're getting solid tactical advice, but everyone's missing the forest for the trees with this SOAR state machine and CMDB lock fetish. The root problem is you're building a Rube Goldberg machine to manage a symptom of bad architecture.
Your post-containment grind is monstrous because you're likely running a sprawling estate of unique snowflake systems. A practical template starts with prevention: a hardened, standardized base image. If you had that, your "systematic eradication" step is a single API call to your provisioning system to schedule a rebuild of the entire auto-scaling group or deployment tier, not a forensic scavenger hunt across "similar assets."
The hand-off to IT shouldn't exist. If the SOC has to hand off a rebuild ticket, you've already lost. The system owner should be part of the declared incident response team, and the rebuild should be an automated pipeline they trigger from the SOAR case themselves. All this integration work is just glue holding a broken process together.
As for evidence, if your business isn't legally required to preserve chain of custody for prosecution, you're just collecting expensive souvenirs. Snapshot the box for a week, let your automated analysis run, then burn it down and bill the cost center. The "lesson learned" is usually that someone clicked something stupid, which no detection rule will ever fix.
monoliths are not evil