Skip to main content

​
Overview

The CrowdStrike Falcon integration (INT-008) ingests Falcon detections into CaseBender and can push case dispositions back to Falcon when a case is closed.

Inbound Ingestion

Falcon detections are ingested — either pulled automatically on a schedule (recommended) or pushed via a webhook — then normalized, enriched with observables and MITRE ATT&CK techniques, and turned into alerts.

Outbound Disposition Sync

When a linked CaseBender case is closed, the Falcon detection status is updated with an audit comment.
Recommended: enable Automatic polling. CaseBender can pull new detections on a schedule using the same Falcon API client — no webhook or SIEM connector is required. See Automatic polling.
This integration uses the Falcon Alerts API v2 and authenticates with an OAuth2 API client (client ID + secret) using the client-credentials flow.

​
Capabilities

​
Prerequisites

1

Falcon API client

In the Falcon console, go to Support and resources → API clients and keys and create an API client. Grant the Alerts: Read scope (and Alerts: Write if you want outbound close-back). Copy the Client ID and Secret.
2

Cloud region base URL

Note your Falcon cloud base URL (e.g. https://api.crowdstrike.com, https://api.us-2.crowdstrike.com, or https://api.eu-1.crowdstrike.com).
3

Network egress

The CaseBender poller service must be able to reach your Falcon API base URL.

​
Configure the integration in CaseBender

1

Open the integration catalog

Go to Settings → Integrations → Create, then choose CrowdStrike Falcon from the EDR/XDR category.
2

Enter Falcon API credentials

3

Enable automatic polling (recommended)

In the Automatic polling card, turn on Enable automatic polling and set:
4

Configure auto-case creation

​
Inbound (automatic polling, recommended)

With Automatic polling enabled, the CaseBender poller periodically queries the Falcon Alerts API and ingests new detections on its own.
1

Scheduled pull

On each interval, CaseBender queries the Alerts API v2 for composite IDs updated since the last cursor, then fetches the full detection entities. On the first run there is no cursor, so detections updated within pollingInitialLookbackHours are imported.
2

Cursor + deduplication

CaseBender advances a per-integration cursor to the newest updated_timestamp it has seen. Detections are deduplicated by detection ID, so overlapping polling windows never create duplicate alerts.
3

Normalization

Each detection is normalized into a CaseBender alert — mapping severity, building the title/description, extracting observables, and generating MITRE TTPs.
Polling runs in CaseBender’s background poller service. Ensure that service can reach your Falcon API base URL (directly or via your configured proxy).

​
Inbound (webhook / push)

As an alternative to polling, Falcon (or an intermediary) can push detection payloads to the CaseBender ingestion endpoint:
Requests are authenticated with an integration API key in the x-api-key header. Falcon webhook API keys are prefixed with cbr_crowdstrike_.

​
Outbound: syncing case dispositions to Falcon

When a case is closed, the case_closed event is dispatched to the CrowdStrike handler. If the case is linked to a Falcon detection (the detection ID is stamped onto the ingested alert), the handler updates the detection status and adds an audit comment. Outbound close-back requires the Alerts: Write scope on the API client.

​
Security considerations

  • Least privilege — grant Alerts: Read for inbound only; add Alerts: Write only if you enable outbound close-back.
  • Secret handling — the client secret is stored in the integration settings; rotate on your organization’s schedule.
  • Token caching — access tokens are cached in memory and refreshed before expiry.
  • Network — restrict egress to your Falcon API base URL.

​
Troubleshooting

Verify the client ID, secret, and API base URL (region). Confirm the API client is enabled and has the Alerts scope.
Confirm Enable automatic polling is on and the API client has the Alerts: Read scope. Check the poller can reach your Falcon base URL. On first run only detections within pollingInitialLookbackHours are imported.Make sure all CaseBender services are running. Detections are fetched by the background processor and turned into alerts (and optionally cases) by the background worker. With Docker, run docker compose ps and confirm the worker and misp-processor services are Up.
Ensure the API client has the Alerts: Write scope and the case is linked to a Falcon detection. Check the case timeline for the sync result.

​
Related documentation