Triage a CrowdStrike Falcon alert. security-alert-response and edr-detection-runbook own the
investigation canon; you add Falcon's packaging and containment semantics. Containment,
status changes and RTR sessions are technician steps you direct and record.
1. Parse the alert: detection or incident (an incident groups detections — work the incident), severity, hostname and sensor ID, process tree or triggering hash, and the action-taken field (blocked/killed/quarantined versus
detection-only). Copy Falcon's exact verdict language; "blocked" is a claim about one
process — verify nothing executed before the block and scope-check the host before
closing. Route the client per security-alert-response using hostname and tenant (CID);
Falcon alerts often land on a shared intake mailbox, and low routing confidence means
flag for a human, not reassign.
2. Contain per the edr-detection-runbook matrix: Network Contain isolates the host but keeps
the Falcon cloud channel open, so the technician can investigate and lift it remotely.
Cheap to apply and undo — on detect-only alerts for credential theft, hands-on-keyboard
indicators or lateral-movement tooling, contain first, investigate second. Never lift
Network Contain without a documented verdict and a named decision-maker.
3. Investigate per edr-detection-runbook: process lineage, persistence, what executed before
blocking, other hosts with the same hash or indicator (prior tickets, ~90 days). Confirmed malicious with identity involvement branches to
compromised-account-containment; ransomware behavior to ransomware-response.
4. Check for a vendor-caused mass failure: on 19 July 2024 a faulty Falcon content update
caused mass Windows BSOD boot loops, not an attack. Many hosts failing or blue-screening across
unrelated clients, tightly clustered in time with no preceding detections, points
vendor-side — check CrowdStrike's status page BEFORE working it as a security incident. Then switch to outage response: a tracking ticket per
client, the vendor's remediation bulletin followed exactly rather than improvised fixes, and communication per defensive-writing-standard without speculating
until the vendor confirms. Rule out a content update before declaring a security
incident, and an attack before declaring it vendor-side.
5. Note the decision: severity and verdict, containment state and who applied or lifted it.
Classify per soc-classification-tree. Exclusions and IOC allowlisting
are security decisions, never silent: narrowest scope (hash over path, path over folder),
named approver, review date. Client-facing wording per defensive-writing-standard:
never "you were hacked".
Sensor deployment scope may be unknown without documentation — say so, don't assume full
coverage. When in doubt do nothing irreversible and escalate.
Magic Library