CrowdStrike Falcon β Alert Ingestion Guide
this guide covers two approaches for ingesting crowdstrike falcon alerts into swimlane turbine, normalized to turbine schema format connector β use the crowdstrike falcon v2 connector actions directly in a playbook for full control over your workflow component β use the crowdstrike falcon alert ingestion component for a turnkey webhook based pipeline with automatic checkpointing and retry both approaches deliver alerts in swimlane's turbine schema format one downstream playbook handles alerts from any source key capabilities unified alert format β every crowdstrike alert is normalized to turbine schema, enabling cross vendor playbooks and dashboards rich alert context β full host details (hostname, ip, os, agent version), mitre att\&ck tactic and technique mappings, file hashes and observables, and pre built falcon query language (fql) strings for threat hunting ready to use response actions β alerts include available response actions (contain host, release from containment, run rtr script) that can be wired directly into automated response playbooks incremental polling β checkpoint based polling ensures no duplicate alerts using the connector the crowdstrike falcon v2 connector provides dedicated alert ingestion actions query alerts , get alert details , and get queries alerts use this approach when you want full control over your playbook logic and custom processing how it works query alert ids β use the query alerts action to retrieve alert ids from the falcon alerts api, applying optional fql filters and sort order fetch full entities β use the get alert details action to fetch complete alert entities for each batch of ids, including host information, observables, file details, and mitre att\&ck mappings normalize β use playbook logic or a transform block to map alert fields to turbine schema format process β create records, trigger response actions, or route alerts based on your playbook design connector setup prerequisites crowdstrike falcon api client id and client secret with alerts read and hosts read scopes the crowdstrike falcon v2 connector installed from the turbine marketplace steps create an asset β in turbine, create a new crowdstrike falcon v2 asset with your oauth 2 0 client id, client secret, and the appropriate cloud region url create a playbook β create a new playbook with a scheduled trigger (e g , every 5 minutes) add the query alerts action β add the crowdstrike falcon v2 connector's query alerts action to retrieve alert ids add the get alert details action β add the get alert details action to fetch full alert entities for the retrieved ids configure filters β use fql filters to scope alert retrieval (e g , severity, status, time range) build processing logic β add playbook steps to normalize alerts to turbine schema, create records, and handle checkpointing authentication the connector requires crowdstrike falcon api oauth 2 0 credentials client id β your falcon api client identifier client secret β the secret key associated with your client id cloud region β supports us 1, us 2, eu 1, and custom cloud regions required api scopes alerts read hosts read (for host entity details) using the component the crowdstrike falcon alert ingestion component ( crowdstrike falcon alert ingestion vic ) provides a turnkey pipeline that handles the entire ingestion workflow querying alert ids, fetching full alert entities with host details and observables, normalizing to turbine schema, and posting to a swimlane webhook use this approach when you want out of the box ingestion with automatic retry and checkpointing what the component adds end to end pipeline β handles alert retrieval, entity enrichment, turbine schema normalization, and webhook delivery in a single component automatic checkpointing β maintains a checkpoint file to track the last processed alert timestamp, enabling incremental polling with no duplicate alerts webhook based ingestion β sends each normalized turbine schema payload to a configured swimlane webhook url supports individual posting or batched posting retries automatically on transient failures fql filtering β scope alert retrieval with custom falcon query language filters (e g , severity, status, detection source) how it works query alert ids β calls the falcon alerts api to retrieve alert ids, applying optional fql filters and sort order handles pagination across multiple pages (configurable up to 200 pages of 500 alerts each) fetch full entities β for each batch of alert ids (configurable batch size, default 25), fetches the complete alert entity including host information, observables, file details, and mitre att\&ck mappings normalize to turbine schema β each alert is transformed into turbine schema format with standardized fields for severity, timestamps, impacted hosts, observables, rules, and available response actions post to webhook β sends each normalized turbine schema payload to the configured swimlane webhook url supports individual posting (one request per alert) or batched posting checkpoint β updates the checkpoint file with the last processed alert timestamp for the next polling run component setup prerequisites crowdstrike falcon api client id and client secret with alerts read and hosts read scopes a swimlane turbine webhook url configured to receive alert payloads the crowdstrike falcon v2 connector installed from the turbine marketplace the crowdstrike falcon alert ingestion component imported from the marketplace steps create an asset β in turbine, create a new crowdstrike falcon v2 asset with your oauth 2 0 client id, client secret, and the appropriate cloud region url install the component β import the crowdstrike falcon alert ingestion component from the marketplace configure the webhook β set swimlane webhook url to your turbine webhook endpoint set organization β configure alert organization with your organization name configure first run β set lookback minutes on first run (default 60 minutes) the component will look back this many minutes on the first run to capture recent alerts optional add fql filters β use fql extra to scope alert retrieval for example, to only ingest high severity alerts severity >3 schedule the playbook β set up a scheduled trigger (e g , every 5 minutes) the component handles checkpointing automatically component configuration variables variable default description swimlane webhook url β required swimlane webhook endpoint url for receiving alerts alert organization swimlane ses organization name attached to ingested alerts checkpoint path cs alerts checkpoint json path to the checkpoint file for incremental polling lookback minutes on first run 60 minutes to look back on the first run (when no checkpoint exists) page limit 500 maximum alerts per api page max pages 200 maximum number of pages to fetch per run sort updated timestamp asc sort order for alert retrieval fql extra "" additional falcon query language filter (optional) entity batch size 25 number of alert ids to fetch per entity api call post batch false post alerts in batches ( true ) or individually ( false ) batch size 50 number of alerts per webhook batch (when post batch is true ) recommended configuration scenario page limit max pages lookback minutes post batch initial deployment 500 200 60 false production polling (every 5 min) 500 10 60 false high volume environments 500 200 60 true testing 100 1 30 false error handling scenario behavior alert retrieval fails error logged, processing stops entity fetch fails for a batch error logged, may continue or stop depending on configuration webhook post fails retried automatically on transient failures partial success returns success count and failed count with error details turbine schema output both the connector and vic produce alerts in this standardized format field type description alert uid string unique crowdstrike alert identifier alert title string alert display name alert description string what was detected alert severity string critical , high , medium , low , informational , unknown alert provider string "crowdstrike falcon" alert organization string organization name from alert organization alert categories array alert category classifications alert created timestamp string rfc 3339 creation time alert start timestamp string when the detection began alert end timestamp string when the detection ended alert ingested timestamp string when the alert was ingested by turbine alert risk score number 0β100 risk assessment alert permalink string direct link to the alert in the falcon console alert impacted hostnames array affected endpoint hostnames alert impacted ip addresses array affected endpoint ips alert impacted usernames array affected user accounts alert rules array objects with rule id , rule name , rule description , rule type alert mitre attack tactic technique array tactics and techniques with uids and names observables array objects with observable type , observable value , threathunt fql alert originating files array file name, hashes (sha256), mime type host info array hostname, device id, local/external ip, os, agent version, mac address threathunt fql array pre built fql queries for threat hunting (e g , sha256hash ' ' ) available responses array available response actions (contain host, rtr script, etc ) raw alert object complete original crowdstrike alert object sample output { "alert uid" "composite id", "alert title" "alert name", "alert severity" "high", "alert provider" "crowdstrike falcon", "alert organization" "swimlane ses", "alert categories" \["malware"], "alert created timestamp" "2025 08 01t17 38 58 000z", "alert impacted hostnames" \["workstation 01"], "alert impacted ip addresses" \["10 0 1 50"], "alert impacted usernames" \["jsmith"], "alert risk score" 85, "alert permalink" "https //falcon crowdstrike com/ ", "alert rules" \[ {"rule id" " ", "rule name" "ml detection", "rule type" "machine learning"} ], "alert mitre attack tactic technique" \[ { "tactics" \[{"uid" "ta0002", "name" "execution"}], "technique" {"uid" "t1059 001", "name" "powershell"} } ], "observables" \[ { "observable type" "sha256", "observable value" "abc123 ", "observable primary provider" "crowdstrike falcon", "threathunt fql" "sha256hash 'abc123 '" } ], "alert originating files" \[ {"file name" "payload exe", "file hashes" \[{"hash algorithm" "sha256", "hash value" "abc123 "}]} ], "host info" \[ { "host hostname" "workstation 01", "host device id" " ", "host local ip" "10 0 1 50", "host external ip" "203 0 113 10", "host platform" "windows", "host os version" "windows 10" } ], "threathunt fql" \["sha256hash 'abc123 '", "domainname 'malicious com'"], "available responses" \[ "contain host", "release host from containment", "run rtr script (real time response)" ] } connector reference for the full list of actions, input/output schemas, and authentication setup, see the https //docs swimlane com/connectors/crowdstrike falcon v2