CrowdStrike Falcon Next-Gen SIEM Guide: Ingestion, CQL, Correlation Rules and Governance

Falcon Next-Gen SIEM puts third-party logs next to Falcon telemetry, but the value a SOC gets depends on customer-side choices: how data is ingested and parsed, how correlation rules are written and governed, and who can change them. The platform is built on the Falcon LogScale engine, uses the CrowdStrike Query Language (CQL) for search and detection, and normalises third-party data with the CrowdStrike Parsing Standard (CPS). This guide covers the parts a detection engineer or SOC lead configures: data connectors and HEC ingestion, parsers and CPS fields, correlation rule design and limits, Fusion SOAR automation, access control and audit, and how to measure that the deployment is working. It assumes you already understand SIEM fundamentals; for those, see the SIEM Guide.

This is an independent guide from NHI Mgmt Group, based on CrowdStrike's public documentation as of November 2026. It is not sponsored or reviewed by CrowdStrike. Product features change, so confirm settings against CrowdStrike's current documentation.

Key takeaways

• Parsing decides detection quality. Third-party data only correlates well when its parser maps fields to CPS, which builds on Elastic Common Schema (ECS) and requires tags such as #Vendor, #event.module and #event.kind.
• Treat HEC API keys as secrets. Each HEC/HTTP Event Data Connector produces an API key that is shown only once; store it in a secrets manager and plan its rotation.
• Design rules around the published limits. 750 active scheduled searches and rules, 30 running concurrently, a 60 minute runtime and 50 detections per execution shape how you write and schedule correlation rules.
• Use the version workflow. Correlation rules move through Draft, Unpublished and Published versions, which gives you a built-in review step before a rule reaches analysts.
• Audit the people who can change detections. NG SIEM roles, the Connector Manager permission and LogScale audit records are as important to govern as the rules themselves.

How the platform fits together

CrowdStrike describes Falcon Next-Gen SIEM as unifying security data into a single searchable platform where custom parsers make third-party data searchable alongside native Falcon telemetry. Its product page states that data from licensed Falcon modules carries no additional ingestion charge. The main building blocks a customer works with are:

The developer documentation lists the Falcon Next-Gen SIEM and Falcon Next-Gen SIEM 10GB subscriptions as the requirement for data connectors and correlation rules, and lists the US-1, US-2, EU-1 and US-GOV-1 clouds for the HEC connector. Confirm your own subscription terms with CrowdStrike.

Ingestion: data connectors and HEC

For most third-party sources the documented path is a data connector with an assigned parser. The setup for the HEC connector is short, which is exactly why its governance needs attention.

1. Create the connector: in the Falcon console go to Next-Gen SIEM > Data ingestion > Data connectors, select Add data connector, choose the HEC/HTTP Event Data Connector, give it a connector name and description, and select an existing parser or create a custom one. The documentation lists Administrator or Connector Manager as the required permission.
2. Capture the API key once: the connector detail page shows the API key and URL, and CrowdStrike warns that the key is displayed only once. Write it straight into your secrets manager, not a ticket or chat thread. See the API Key Management Guide.
3. Configure the shipper: any shipper that supports the HEC API works; CrowdStrike recommends the Falcon LogScale Collector, whose sink configuration uses type hec with the token and URL. Inject the token from a secret store rather than hard coding it in collector configuration files.
4. Verify: confirm the connector Status shows Active, use Show events to open the data in Advanced Event Search, or filter on the #connector tag.
5. Automate if you run many sources: CrowdStrike publishes Terraform resources (ngsiem_data_connection, ngsiem_data_connection_token, ngsiem_data_connector_config) and Ansible modules (ngsiem_data_connection, ngsiem_parser, ngsiem_search) so connectors and parsers can be managed as code. FalconPy also provides an HEC helper class with a send_event() method for programmatic ingestion.

LogScale itself documents further ingest methods, including ingest listeners for raw TCP or UDP (for example rsyslog and GELF), ingest feeds that pull from an Amazon S3 bucket or Azure Event Hubs, ingest tokens that route data to the right repository with the right parser, and ingestion of Falcon Data Replicator data. Check which of these your Next-Gen SIEM tenant exposes before designing around them. For a source by source approach, use the SIEM Log Source Onboarding Checklist.

Ingestion and data structure limits

Parsers and the CrowdStrike Parsing Standard

CPS 1.2 is CrowdStrike's normalisation standard for parsers. It builds on ECS, with one notable difference: parsers keep every log field available, even where ECS has no matching field. Getting CPS right is what lets one correlation rule work across, for example, two firewall vendors.

Parser practice: CrowdStrike's parser guidelines ask for test cases that exercise all parser logic, synthetic test data instead of real personal data (example.com domains, RFC 1918 or TEST-NET addresses, placeholder names), comments that describe the logic, use of the parser template, and the assumption that a parser receives one event at a time. Store parsers and their test cases in version control and review changes like code. The Detection as Code Guide covers the pipeline pattern.

Writing CQL for detection

CQL chains expressions in a pipeline, each passing its result to the next. The language reference documents free-text filters, field filters and regular expressions; := for assigning new fields (also eval() and an as parameter on some functions); case and match statements instead of if/else; // and /* */ comments; and functions such as groupBy(), count(), table(), sort(), join() and defineTable().

• Filter first, aggregate last: narrow by tags such as #Vendor or #event.module and by CPS fields before calling groupBy(). CrowdStrike documents a default of 20,000 rows for groupBy() (200,000 maximum) and 20,000 events for tail(), head() and sort().
• Query CPS fields, not vendor fields: a rule written against event.outcome and source.ip survives a vendor change; one written against a Vendor. field does not.
• Comment every rule: state the behaviour detected, the data sources it needs and the expected false positives in a /* */ header.
• Respect search limits: live queries have 1 GB of memory, Search API jobs time out at 90 seconds, and results cap at 1,000,000 rows (lower with some functions).
• Use lookups for context: asset criticality, known service accounts and approved admin hosts in lookup files turn noisy matches into useful ones.

Correlation rules: design, limits and lifecycle

CrowdStrike documents three rule types: correlation rules that run a search on a recurring schedule, behavioural rules built on the LogScale correlate() function (which cannot be combined with other aggregation functions in the same query), and built-in sensor rules that cannot be created, edited or deleted. Templates from CrowdStrike and third parties can be applied from the Templates tab once Next-Gen SIEM is enabled on the CID.

Published limits: 750 active scheduled searches plus correlation rules, 30 running concurrently, a 60 minute maximum runtime, and 50 detections per execution. The limits page states that exceeding 50 detections auto-disables the rule, so a noisy rule silently stops protecting you. In Terraform, the correlation_rule resource requires a schedule interval of at least 5m, allows a lookback of up to 168h, and takes a status of active or inactive; it uses the Correlation Rules READ and WRITE API scopes.

Lifecycle: versions move through Draft, Unpublished (for review and testing) and Published, and a published version cannot be deleted until another version is published. Rules are Active or Inactive; the documentation says an inactive rule is kept for 365 days and then permanently deleted, so export anything you might want back. NG SIEM role users see only their own rules by default; seeing others needs the "View scheduled reports (all types)" permission, which detection leads should hold. The Detection coverage dashboard rates ATT&CK technique coverage as High, Low or None. For the wider method, see the Detection Engineering Guide.

Automation with Fusion SOAR

Fusion SOAR workflows can be triggered on demand, on a schedule (minimum granularity one hour) or by platform events such as detections and incidents. Documented actions include calling CrowdStrike APIs, running Foundry functions, running event queries, sending notifications, writing to LogScale and HTTP actions to external REST APIs, with conditions written as CEL expressions and loops of up to 100,000 iterations.

• Start with enrichment: automate lookups and notifications first; add containment actions only after the triggering rule has a measured false positive rate.
• Know the integration limits: 10,000 rows per search result in the Next-Gen SIEM integration and a 10 MB action result size.
• Keep execution evidence: Fusion execution logs are retained for 90 days, so export records you need for incident files or audit beyond that.
• Govern HTTP actions: each external call uses a credential; inventory them with the other non-human identities in the SOC.

Access, audit and the identities behind the SIEM

The SIEM holds detection logic and some of your most sensitive logs, so its own access model matters. See Securing the SIEM itself for the general case.

• Human roles: the default roles listed for correlation rules are Falcon Administrator, NG SIEM Administrator, NG SIEM Analyst and NG SIEM Analyst - Read Only. Give most analysts the read only or analyst role, and limit administrator and Connector Manager to a small named group.
• API clients: scope each API client to the minimum, for example Correlation Rules READ only for reporting jobs, and keep WRITE for the detection pipeline's own client.
• HEC keys and collector tokens: one key per connector, owned by a named team, stored in a vault and rotated on staff change or suspected exposure. The API Key Leak Response Playbook covers the response.
• Audit records: LogScale's humio-audit repository records user actions, with fields such as actor, type and a sensitive flag for events that change roles or access, change retention or delete data. Users see only their own actions unless they are members of that repository. Review sensitive events weekly.

Rollout plan

1. Weeks 1 to 2, baseline: confirm the native Falcon data in search, define roles, create the API client and secrets layout, and agree a parser and rule repository.
2. Weeks 2 to 6, priority sources: onboard identity provider, cloud control plane, firewall and email logs through data connectors with CPS-compliant parsers; validate tags and fields against a test set before production.
3. Weeks 4 to 8, detections in shadow: deploy templates and custom rules as Unpublished versions or with notifications to a test channel only; measure volume against the 50 detection ceiling and tune.
4. Weeks 8 to 12, go live: publish rules, enable case creation for high and critical severity, then add Fusion enrichment workflows.
5. Rollback: set a rule to Inactive or republish the previous version; disable a workflow rather than deleting it; revert parser changes from version control.

Small versus large teams: a small SOC should rely on CrowdStrike templates and CPS-compliant parsers and spend effort on tuning. A large team with many custom sources benefits from managing connectors, parsers and rules through Terraform or Ansible with peer review.

Detection and measurement

• Source health: percentage of connectors with Active status and data in the last hour, per source.
• Parse quality: share of events per source with all required CPS tags populated.
• Rule health: number of rules auto-disabled or hitting the 50 detection limit per week (target zero).
• Coverage: ATT&CK techniques rated High on the Detection coverage dashboard, tracked monthly.
• Precision: true positive rate per rule from case outcomes.
• Change control: sensitive humio-audit events reviewed within seven days.

Framework mapping

Common failure patterns

• Losing the HEC key: the key is shown once; teams that paste it into a ticket create a long-lived secret nobody rotates.
• Vendor-field rules: rules written against raw vendor fields break when a source changes; write against CPS fields.
• Silent auto-disable: a rule that exceeds 50 detections per run is disabled; without a rule health check nobody notices.
• Window shorter than frequency: events fall between runs; keep the search window at least as long as the frequency, and use ingest time for late sources.
• Forgotten inactive rules: inactive rules are deleted after 365 days; export logic before parking a rule.
• Broad administrator rights: too many people able to change parsers and rules makes detection logic easy to weaken by mistake.

Practitioner checklist

• Store every HEC API key in a secrets manager at creation, with an owner and rotation date.
• Use CPS-compliant parsers; test custom parsers against synthetic data with all required tags.
• Write rules against CPS fields and comment their intent and data dependencies.
• Keep each rule's search window at least as long as its frequency.
• Monitor for rules approaching or exceeding 50 detections per execution.
• Map every rule to ATT&CK tactics and techniques and review the coverage dashboard monthly.
• Limit NG SIEM Administrator and Connector Manager rights; scope API clients to READ or WRITE as needed.
• Review sensitive events in humio-audit weekly.
• Export Fusion execution evidence needed beyond 90 days.

Standards and references

• CrowdStrike: Next-Gen SIEM Correlation Rules
• CrowdStrike: Next-Gen SIEM Data Ingestion (HEC)
• CrowdStrike: Next-Gen SIEM Limits and Standards
• CrowdStrike: CrowdStrike Parsing Standard 1.2
• CrowdStrike: CrowdStrike Query Language Syntax
• CrowdStrike: Fusion SOAR
• CrowdStrike: The humio-audit Repository
• CrowdStrike: Terraform correlation_rule Resource

Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · EDR Platform Configuration Guide · Securing the SIEM itself