elastic / elastic/integrations
Crowdstrike: Add cases data stream
- 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
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