Last verified · 1 day ago
Falcon detection, incident and audit data streams into Splunk reliably through an add-on CrowdStrike writes and supports itself. Sending an instruction back the other way is not part of it, and the ingest side has a throughput ceiling and an appId rule that will cost you data if you ignore them.
CrowdStrike Falcon → Splunk Verified · Splunk → CrowdStrike Falcon Partial
A week
From purchase to a feed you actually trust.
Installing the add-on is an afternoon. The week goes into deciding what not to send, and getting the appId scheme right before it silently drops data.
Erick Ingleby, not a vendor figure
This is one of the better-documented integrations in security, largely because CrowdStrike wrote the add-on rather than leaving it to the community, and publishes a detailed configuration guide for it. Read that guide before you deploy, not after: the two things most likely to break your feed, the appId uniqueness rule and the roughly 1700 events per minute per input ceiling, are both in it and neither is obvious from the Splunk UI.
In my own words
Send Falcon detections to Splunk. Do not send the raw endpoint telemetry.
Falcon knows an enormous amount about what every endpoint is doing and it will happily send you all of it. Do that and your Splunk bill doubles, triples or quadruples. Then it gets worse, because Splunk itself crumbles under that kind of ingest, and God forbid you try to search those Falcon logs at that volume. For a large organization the indexes collapse and the data becomes unsearchable, which is the worst outcome available: you are paying for it and you cannot use it. A small shop, fine, that is probably not true for you. Any large one, it is.
I am not going to prove the cost claim, and I do not have to. Do the simple math yourself. Gigs per day ingested against how many log lines Falcon produces from a single endpoint with a real person using it all day. It is mathematically impossible to avoid. If you want proof, hook it up and watch your next monthly bill.
Most customers end up sending alerts only. There is a reason for that.
Erick Ingleby
The add-on holds an open connection to the Falcon Event Streams API and indexes detection, event, incident and audit data as it arrives. It is not a poll. The Interval field on the input is not used and is always set to 0, which surprises people who try to tune it.
GET /sensors/entities/datafeed/v2 Every event in a feed carries a numeric offset. If the connection drops, the add-on uses the last offset it processed as the resume marker, keyed as input name to data feed URL to offset. From version 3.x that state lives only in the Splunk KV store, so KV store health is now part of your data pipeline whether you planned it that way or not.
Several independent inputs can run at once, each pointed at a different Falcon instance with its own credential and its own index. This is a genuine multi-tenant path, not a workaround.
An input can be restricted to chosen event type categories. This matters more than it sounds, because it is the documented remedy for the throughput ceiling: you split high volume event types onto their own input so they stop delaying the events you actually care about.
On first connection you choose whether to collect as far back as possible or only forward from now. This is an initial collection setting only, so decide before you enable the input rather than after.
The add-on needs one OAuth2 API client with Read on Event streams and nothing else. CrowdStrike recommends a dedicated credential so that regenerating the secret does not take down other integrations. The secret is shown exactly once when you create the client.
Falcon genuinely supports network containment as an API call, so the loop can be closed. It just is not this add-on, which is ingest only, and it is not Splunk's built-in webhook alert action either, which posts an unauthenticated JSON body and has no documented way to carry a bearer token. Closing the loop means an add-on that implements a custom alert action, or one you write.
POST /devices/entities/devices-actions/v2 The Event Streams gateway tracks each connection by an appId that must be unique within the Falcon instance. If a client connects using an appId that is already established, the connection is refused. CrowdStrike lists this twice in its own troubleshooting section, which tells you how often it happens. The failure looks like an input that is enabled, shows no errors you would notice, and produces no data. A forgotten lab collector or a cloned input is the usual culprit.
Because events are processed one at a time to keep the offset accurate, the add-on ingests on average about 1700 events per minute per input. Above that, processing falls behind. CrowdStrike's worked example is a cloud posture event type averaging 1500 events per minute and delaying detection events behind it. If your detections are arriving late, this is the first thing to check, and the fix is to split event types across inputs rather than to tune anything.
A busy Falcon instance splits its data across several feed URLs, each with its own offset, and the add-on has to establish and hold all of them. The documentation is explicit that all connections must be maintained to collect all the data. There is no obvious signal in Splunk when one of four feeds is quietly dead.
The add-on validates that the index exists only when the input is first configured. If the index is later disabled, Splunk drops what the add-on hands it and the add-on carries on happily. CrowdStrike documents this as a troubleshooting case, which is a polite way of saying it happens.
Falcon has separate regional gateways for US commercial, US-2, GovCloud and EU, and the add-on does not support redirection. A credential and a cloud selection that disagree produce an authentication failure, not a helpful hop to the right region.
Version 2.0.9 introduced a saved search and alert action that could detect a stalled input, by checking for at least two OAuth2 token refresh events in a sixty minute window, and restart it. Splunk 9.x changed how SSL is used and CrowdStrike removed support for that alert action in v3.5. The detection logic is still useful as a monitoring search. The automatic restart is not something you should be relying on.
CrowdStrike names network devices that block persistent connections after a prolonged period, and a data connection inside the API closing while the gateway connection stays up, as recognized causes of a stalled feed. In that second case the add-on looks connected and is not collecting. Proxies must be HTTPS-capable and must not interfere with a long-lived connection.
CrowdStrike's own guide and the source for almost everything on this page: the appId collision rule, the 1700 events per minute figure and its remedy, multiple feed URLs and offsets, KV store state from v3.x, the unused Interval field, the four regional base URLs and no redirection, the disabled index behavior, and the withdrawal of the restart alert action in v3.5.
VENDOR DOC · Checked
Independent confirmation of the endpoint, the Event streams READ scope and the appId parameter. Worth noting the reference gives appId a 32 character limit while the add-on guide gives the input field a 15 character maximum, so build to 15.
VENDOR DOC · Checked
Basis for saying the return path is possible at all: contain and lift_containment are documented actions on the device actions endpoint under the Hosts WRITE scope.
VENDOR DOC · Checked
Basis for saying Splunk's built-in webhook cannot drive the Falcon API. The documented payload is a URL and a fixed JSON body with no authentication field.
VENDOR DOC · Checked