Disposition, Containment, and Detection Handoff
Decide what the chain represents, preserve the evidence needed for response, and turn durable behavior into a testable detection improvement.
In this lesson, you will learn to:
- Select a process-chain disposition based on observed behavior and impact.
- Produce a handoff that supports containment, recovery, and detection improvement.
Disposition, Containment, and Detection Handoff
Closes with disposition criteria, containment authority, evidence preservation, fleet scoping, case writing, false-positive control, and detection feedback.
Choose action from behavior, impact, and authority
Use a defined disposition such as malicious, suspicious, benign expected, benign policy violation, or insufficient evidence. State the behavior that supports it. Separate confidence from impact and urgency. A high-confidence blocked test tool may have little impact; an uncertain system-context chain on a critical server may require immediate validation. Check the response plan before terminating processes, isolating hosts, deleting files, disabling accounts, or blocking system binaries. These actions can disrupt operations and remove volatile evidence.
Preserve raw events, command lines, hashes, payloads under approved handling, relevant files, network destinations, persistence entries, user and logon context, and sensor health. If the host remains active, coordinate volatile collection and containment order. Scope the fleet using behavior-specific combinations: parent plus arguments, payload hash, writable path plus signer transition, persistence mechanism, or destination. A broad search for a common filename creates noise and can drive unsafe blocking. Define the earliest and latest observed activity and what data was searched.
Write a reproducible case and a testable detection change
A concise case note includes anchor alert, host and user, lineage, interpreted command, confirmed effects, alternative explanation tested, baseline comparison, scope, confidence, impact, containment, and open questions. Quote the raw command through an artifact link if it contains secrets rather than copying sensitive values into every ticket. Map ATT&CK after the behavior is supported, and avoid using the technique name as the explanation.
For detection handoff, describe the scenario, required log sources and fields, analytic logic, expected benign causes, severity conditions, test cases, and owner. Prefer relationships and outcomes over one filename. Test with known normal management tasks and confirmed malicious examples, then monitor alert volume and missing fields. Tuning should retain the risky child, argument, payload, destination, or effect rather than exclude an entire trusted parent. Feed collection gaps to engineering and record an expiry for temporary suppressions. The investigation is complete when action and learning are both traceable to evidence.
Resources
- Microsoft Sysmon documentation and download — Use the official Sysmon reference for event semantics, configuration behavior, Process GUID correlation, hashes, and collection limitations.