What Changed

CrowdStrike API Data Connector v3.3.1 implements a complete overhaul of the alerts and detections ingestion mechanism, switching from a broken single-endpoint approach to a two-step nested collection process.

Security Impact (Visibility & Fidelity)

Critical data fidelity gap resolved: The previous connector configuration (v3.3.0 and earlier) was only retrieving alert IDs from /alerts/combined/alerts/v1 endpoint, not the actual alert content. Deployments running the affected versions had incomplete CrowdStrike visibility — only alert references were ingested, with no alert metadata, severity, or contextual data populated in the CrowdStrikeAlerts and CrowdStrikeDetections tables.

The connector now implements proper nested data collection:

  • Step 1: Query /alerts/queries/alerts/v2 (GET) to retrieve alert ID lists
  • Step 2: Call /alerts/entities/alerts/v2 (POST) with those IDs to fetch full alert details

This two-phase approach ensures complete alert and detection data ingestion, restoring visibility into CrowdStrike endpoint protection events that was missing in previous versions.

Configuration Changes

  • HTTP method changed from POST to GET for initial alert queries
  • Implemented nested step collection with stepInfo.stepType: Nested
  • Added dedicated alert_details and detection_details step collectors
  • Changed paging mechanism from PersistentToken to Offset-based pagination
  • Reduced timeout from 120s to 90s per request

The fix affects both CrowdStrikeAlerts and CrowdStrikeDetections data types with identical architectural improvements.

Affected Files

Solutions/CrowdStrike Falcon Endpoint Protection/Data Connectors/CrowdStrikeAPI_ccp/CrowdStrikeAPI_Definition.json
Solutions/CrowdStrike Falcon Endpoint Protection/Data Connectors/CrowdStrikeAPI_ccp/CrowdStrikeAPI_PollingConfig.json
(packaging artefacts: 3.3.1.zip, ReleaseNotes.md, Solution_CrowdStrike.json, mainTemplate.json)