The Crowdstrike Automation console — Falcon detections and hosts, one-click containment and detection triage, launching the seeded governed workflows, and detection→response rules gated by CROWDSTRIKE_AUTOMATION_ENABLED, with sample data until a Falcon tenant is connected.
An operational console over your CrowdStrike Falcon tenant: see detections and managed hosts, contain or triage with one click, launch the seeded governed workflows against a specific host or detection, and author detection → response rules that fire automatically.
It lives under the Client End-point Security workspace — Crowdstrike → Automation (/crowdstrike/automation, administrator access). The sibling Connection entry is the Falcon credential itself; setting that up, the workflow steps, and the SDK are covered in CrowdStrike Integration.
Ships switched off. Response rules can be authored at any time, but nothing fires against Falcon until
CROWDSTRIKE_AUTOMATION_ENABLEDis set and the evaluator command is scheduled. Everything else on the console — viewing, one-click actions, launching workflows — works regardless of the flag.
The header offers a source selector whenever Falcon connections exist (default: the first enabled one, by name). Five summary cards follow: Managed hosts, Contained, Open detections (status new or in_progress), Critical / High, and Active rules (enabled / total, with "automation on" or "automation off" underneath). A banner appears whenever the data is not live — see Sample data.
Three tabs sit below.
Detections sorted by severity, then newest first, each with severity and confidence, technique and tactic (plus filename), host, status, and age. Per row:
detection_id:'<id>' and the host name.in_progress.false_positive.Every managed host with platform and OS, local and external IP, containment state (Contained or Normal), and last-seen age. Per row:
Launching any workflow creates a run and takes you straight to it under Workflows → Runs.
Rules are the automation layer. Each rule has a name, an enabled toggle, an optional source (blank = first enabled), match criteria — minimum severity (Informational → Critical, default High), an optional tactic, and optional extra FQL — a response action, and an autonomy label (Require approval or Fully automated). Actions are:
| Action | What happens |
|---|---|
| Launch a workflow | Starts the chosen seeded workflow (default cs-host-containment) |
| Contain host | Network-isolates the detection's host |
| Update detection status | Sets the detection to the status you specify, e.g. in_progress |
Each rule shows when it last evaluated, how many detections it matched, and its lifetime action count.
The evaluator (evaluate_response_rules) runs once per invocation and, for each enabled rule:
new or in_progress, whose severity is at or above the minimum, and — if a tactic is set — whose tactic contains that text.cs_source, target_hostname, containment_reason (rule name, technique, severity, host) and detection_filter (detection_id:'…'), attributed to cs-rule:<rule name>, and starts it. Contain host calls Falcon's contain device-action on the host's AID. Update detection status patches the detection.The Autonomy setting is enforced by the evaluator. A rule set to Require approval never touches Falcon directly: its response is proposed through a governed workflow — the seeded Host Containment workflow for Contain host (its approval gate sits before isolation), the Detection Investigation workflow for Update detection status, or the rule's own workflow — and a human must pass that gate before anything is contained or changed. The detection's ID, agent ID and the requested action are passed in the run context. Only a Fully automated rule acts the moment it matches. A --dry-run computes matches without acting.
Three governed workflows ship under the security category and are the ones the console launches: Host Containment (cs-host-containment), Detection Investigation (cs-detection-investigation), and Vulnerability Scan (cs-vulnerability-scan). Their step-by-step wiring and run inputs are in CrowdStrike Integration. If a workflow is missing, the console reports "Could not launch workflow (is it seeded?)" and a rule targeting it logs a warning and skips.
The console has three modes, shown in the banner:
Sample data is five hosts (a contained Finance workstation, a domain controller, a DMZ web server, an HR laptop, a Jenkins build node) and five detections from Critical ransomware down to Low reconnaissance, with timestamps freshened to "minutes ago". In sample or unconfigured mode, one-click actions return simulated: true and a warning-coloured message rather than failing, so demo flows complete. The rule evaluator, by contrast, only ever acts through a live client — an unreachable Falcon simply yields no matches.
CROWDSTRIKE_AUTOMATION_ENABLED=true in the backend environment. The Active-rules card switches to "automation on".python manage.py run_crowdstrike_automation # honours the flag
python manage.py run_crowdstrike_automation --dry-run # match only, no actions
python manage.py run_crowdstrike_automation --force # evaluate even with the flag off
| Item | Detail |
|---|---|
| Location | Client End-point Security → Crowdstrike → Automation (/crowdstrike/automation), admin only |
| Tabs | Detections · Hosts · Rules |
| One-click actions | contain, lift, update detection status (simulated when Falcon is unreachable) |
| Rule match | status new/in_progress · severity ≥ minimum · tactic substring · extra FQL |
| Rule actions | Launch a workflow · Contain host · Update detection status |
| Gate | CROWDSTRIKE_AUTOMATION_ENABLED + scheduled run_crowdstrike_automation |
| Workflows launched | cs-host-containment · cs-detection-investigation · cs-vulnerability-scan |
| API | /api/integrations/crowdstrike-automation/overview/, …/action/, /api/integrations/crowdstrike-response-rules/ |
Related: CrowdStrike Integration · Client Endpoint Security · Workflow Builder · Endpoint Security API