elastic / elastic/integrations

Crowdstrike: Add cases data stream

Open
#20,516 1 comment 0 reactions 0 assignees View on GitHub
Integration:crowdstrike needs:triage Team:Security-Service Integrations
Dominant language
Handlebars
Stars
333
Forks
647
Avg merge
2d 17h
Merged PRs (30d)
225

Description

### Integration Name

CrowdStrike [packages/crowdstrike]

### Dataset Name

_No response_

### Integration Version

4.5.0

### Agent Version

NA

### OS Version and Architecture

NA

### User Goal

Add a new cases data stream to the crowdstrike integration that pulls from the Case Management API, so Falcon Cases can be ingested into Elasticsearch alongside existing CrowdStrike telemetry.

### Existing Features

NA

### What did you see?

NA

### Anything else?

Summary

CrowdStrike Falcon replaced its legacy Incidents module with a dedicated Case Management feature under Falcon Next-Gen SIEM. The /incidents/ API was decommissioned on March 9, 2026, and replaced by the Case Management API (/cases/ + /casemgmt/). The current crowdstrike integration package does not have a data stream for this — it only covers falcon (SIEM Connector / Event Streams), alert, host, vulnerability (REST API), and Identity Protection datasets (identity_protection_assessment, identity_protection_timeline).

Request

Add a new cases data stream to the crowdstrike integration that pulls from the Case Management API, so Falcon Cases can be ingested into Elasticsearch alongside existing CrowdStrike telemetry.

Why this matters

Falcon Cases groups related detections/alerts into an investigation object with tasks, templates, SLAs, and tags — this context is currently invisible to Elastic once a case is opened in Falcon.
Teams running Elastic Security in parallel with Falcon Next-Gen SIEM have no native way to correlate Falcon Cases with Elastic Cases/alerts without building custom polling or webhook pipelines.
This would let Falcon Case status/lifecycle changes drive Elastic-side automation (e.g., rule actions, ServiceNow escalation) directly from ingested data instead of a bespoke integration.

Relevant API reference

Case Management API: /cases/ (core case CRUD, evidence, tags — scope: Cases: Read/Write) and /casemgmt/ (templates, SLAs, notification groups — scope: Case Templates: Read/Write)
FalconPy SDK support: CaseManagement class (case_management.py, SDK v1.6.0+)
Cases support 40+ FQL filter fields (hostnames, IPs, SHA256s, MITRE ATT&CK tactics/techniques, cloud providers)
Alert evidence linked via composite_id (same IDs returned by Alerts v2 API)
Event evidence linked via LogScale identifiers

Suggested shape

A cases dataset polling /cases/ (and optionally /casemgmt/ for templates/SLAs) via REST API polling, similar to the existing alert, host, and vulnerability datasets, mapped to ECS-compliant fields where applicable (case ID, status, severity, assignee, linked alert/event evidence, tags, timestamps).

Contributor guide

Open the contributing guide

Research direction

Start in packages/crowdstrike and compare the existing alert, host, and vulnerability data streams to the FalconPy CaseManagement reference, especially case_management.py. Review the /cases/ API and determine the ECS fields and polling behavior needed for case IDs, status, severity, assignees, evidence, tags, and timestamps; done means the new cases dataset is tested and ingests those records alongside existing telemetry.

Written by the indexing model from the issue text.

Assessment

Domain
api, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.