--- title: CrowdStrike Falcon — Alert Ingestion Guide slug: authentication-guides/crowdstrike-falcon-alert-ingestion-guide docTags: createdAt: 2026-04-23T13:59:08.787Z --- 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 1. **Query Alert IDs** — Use the `Query Alerts` action to retrieve alert IDs from the Falcon Alerts API, applying optional FQL filters and sort order. 2. **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. 3. **Normalize** — Use playbook logic or a transform block to map alert fields to Turbine Schema format. 4. **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 1. **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. 2. **Create a Playbook** — Create a new playbook with a scheduled trigger (e.g., every 5 minutes). 3. **Add the Query Alerts Action** — Add the CrowdStrike Falcon V2 connector's `Query Alerts` action to retrieve alert IDs. 4. **Add the Get Alert Details Action** — Add the `Get Alert Details` action to fetch full alert entities for the retrieved IDs. 5. **Configure Filters** — Use FQL filters to scope alert retrieval (e.g., severity, status, time range). 6. **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 1. **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). 2. **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. 3. **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. 4. **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. 5. **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 1. **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. 2. **Install the Component** — Import the CrowdStrike Falcon Alert Ingestion component from the marketplace. 3. **Configure the Webhook** — Set `SWIMLANE_WEBHOOK_URL` to your Turbine webhook endpoint. 4. **Set Organization** — Configure `ALERT_ORGANIZATION` with your organization name. 5. **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. 6. **Optional: Add FQL Filters** — Use `FQL_EXTRA` to scope alert retrieval. For example, to only ingest high-severity alerts: `severity:>3`. 7. **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 ```json { "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 [CrowdStrike Falcon V2 connector documentation](https://docs.swimlane.com/connectors/crowdstrike-falcon-v2).