Platform Integrations

CrowdStrike Automation

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_ENABLED is set and the evaluator command is scheduled. Everything else on the console — viewing, one-click actions, launching workflows — works regardless of the flag.


What the console shows

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

Detections sorted by severity, then newest first, each with severity and confidence, technique and tactic (plus filename), host, status, and age. Per row:

  • Investigate — launches the Detection Investigation workflow with the filter detection_id:'<id>' and the host name.
  • Contain (shield icon) — network-contains the detection's host after a confirmation.
  • Ack — sets the detection to in_progress.
  • FP — sets it to false_positive.

Hosts

Every managed host with platform and OS, local and external IP, containment state (Contained or Normal), and last-seen age. Per row:

  • CVEs — launches the Vulnerability Scan workflow for the host.
  • Contain — isolates the host immediately (a direct Falcon action, with confirmation).
  • Workflow — prompts for a containment reason and launches the governed Host Containment workflow, which opens an emergency change and holds for approval before isolating.
  • Lift — removes containment on a contained host.

Launching any workflow creates a run and takes you straight to it under Workflows → Runs.

Response Rules

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:

ActionWhat happens
Launch a workflowStarts the chosen seeded workflow (default cs-host-containment)
Contain hostNetwork-isolates the detection's host
Update detection statusSets 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.


How a rule fires

The evaluator (evaluate_response_rules) runs once per invocation and, for each enabled rule:

  1. Resolves the rule's Falcon source (bound, or the first enabled) and pulls up to 100 detections through the Falcon client, passing the rule's extra FQL to Falcon.
  2. Keeps detections whose status is new or in_progress, whose severity is at or above the minimum, and — if a tactic is set — whose tactic contains that text.
  3. Applies the action to each match. Launch a workflow creates a run with context 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.
  4. Updates the rule's last-evaluated time, match count, and total actions.

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.


The seeded workflows

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.


Sample data and simulated actions

The console has three modes, shown in the banner:

  • Live — hosts and detections pulled from the selected Falcon source.
  • Sample — a source exists but Falcon could not be reached; the banner shows the error and the console falls back to representative data.
  • Unconfigured — no CrowdStrike source at all.

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.


Enabling it

  1. Add and test a Falcon connection under Integrations → CrowdStrike (how).
  2. Confirm the three seeded workflows exist under Workflows.
  3. Set CROWDSTRIKE_AUTOMATION_ENABLED=true in the backend environment. The Active-rules card switches to "automation on".
  4. Schedule the evaluator — it is not started by the web process:
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
  1. Create rules on the Rules tab, starting with Launch a workflow so every automated response passes an approval gate.

Quick Reference

ItemDetail
LocationClient End-point Security → Crowdstrike → Automation (/crowdstrike/automation), admin only
TabsDetections · Hosts · Rules
One-click actionscontain, lift, update detection status (simulated when Falcon is unreachable)
Rule matchstatus new/in_progress · severity ≥ minimum · tactic substring · extra FQL
Rule actionsLaunch a workflow · Contain host · Update detection status
GateCROWDSTRIKE_AUTOMATION_ENABLED + scheduled run_crowdstrike_automation
Workflows launchedcs-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