XSIAM & Third-Party EDR
Telemetry Economics

SentinelOne Deep Visibility Depends entirely on the filter

SentinelOne streams endpoint events out through Cloud Funnel to an S3 bucket, which XSIAM then reads. There is no single “SentinelOne number” to quote. The Cloud Funnel export filter is the whole ballgame, and it moves the volume by about two orders of magnitude. Quote the wrong end of that range and you are off by 100x in either direction.

Linux changes the arithmetic completely and is modeled separately in the estimator: roughly 1 GB per Linux workstation and up to 8 GB per Linux server per day at baseline, from about 500,000 and 4,000,000 events per agent per day respectively. A few hundred Linux servers can outweigh every workstation in the estate, so an unverified server count is the fastest way to be wrong by a multiple in either direction. Per-OS and per-version figures come from the captured sizing research and are directional planning numbers, not vendor commitments.

• Ask for the filter, not the endpoint count. The Cloud Funnel query and field selection determine the volume far more than how many endpoints the customer has. Without it you are guessing across a 100x range.
• Ask for the agent version spread and the server count. These are the two inputs a customer can pull from their own console, and both move the total materially: an older Windows agent costs roughly 55% more per day than a current one for identical coverage, and servers run an order of magnitude above workstations.
• Establish compressed or uncompressed. XSIAM accepts these logs gzipped or uncompressed, and JSON compresses roughly tenfold. A number quoted without that qualifier is not usable.
• Every raw gigabyte that does arrive is charged. In an NG-SIEM deployment where the customer keeps SentinelOne, all ingested EDR logs count against the XSIAM base subscription daily GB/day allowance.
• Filtering trades cost for detection, and heavy filtering is not a supported plan. The file events that dominate volume are also what ransomware and staging behavior look like. The Cortex setup procedure instructs that all fields be included, and Palo Alto warns that external EDR filters can restrict the data analytics require — so any material reduction needs a per-detection dependency review before it is committed, which is scoped assessment work rather than a console setting. That is the honest version of the coexistence conversation, and it is also the services conversation.
• Replacing the agent removes the line item entirely. Move those endpoints to native Cortex XDR agents and the telemetry stops costing anything against the daily allowance, with no filtering tradeoff to negotiate. Note the tier dependency: the per-endpoint agent entitlement starts at XSIAM Enterprise, and is an add-on under NG-SIEM.

• SentinelOne Log Reduction & Alert Tuning Guide — the documented collection paths and their volume controls, XQL to baseline real ingest and troubleshoot the feed, issue exclusions and BIOC exceptions, parsing-rule practice, a nine-step run order, and an honest verdict on whether Cribl helps.
• Captured 10,000-endpoint sizing research — the per-OS and per-agent-version figures that now drive the estimator, preserved verbatim with an editorial note on how each one is used here.

Optimizing SentinelOne volume: the documented tier model Do this before filtering

Before anyone talks about dropping events, there is a supported answer to high-volume third-party EDR: decide where each dataset lands. Palo Alto documents three destinations with different costs and very different capabilities, and the choice is a configuration decision rather than a data-loss decision. The estimator above now models all three — use control 4, Where the endpoint data lands.

Tier assignment is done exclusively through Parsing Rules: Settings → Configurations → Data Management → Parsing Rules, open the Both tab, right-click the [INGEST] rule for the dataset and choose Change Tier to Data Lake. XSIAM disables the default rule, writes a user-defined rule with tier=lake, and appends a _lake_raw suffix to the dataset name. You can switch tiers at any time, but the change applies only to data ingested afterwards — existing data is never moved between tiers.

• 1. Decide what you actually forward. The largest and fastest reduction is not a filter, it is the collection path: the SentinelOne event collector and v2 integration pull activities, threats and alerts without the Cloud Funnel raw telemetry feed at all. Defensible when the SOC does not hunt in raw EDR; a real capability loss if they do.
• 2. Tier what you do keep. Raw telemetry that exists for compliance, investigation or occasional hunting is exactly the documented profile for the Cortex Data Lake tier — high volume, low real-time security value.
• 3. Federate what is purely an archive. If the customer wants sovereignty or a long retention horizon, leave it in their own bucket and reach it with Federated Search.
• 4. Only then discuss filtering, and only with a per-detection dependency review behind it. Dropping events is the one lever on this list that loses data permanently.
• 5. Reprice the remainder. Displacing the third-party agent removes the endpoint line item entirely rather than relocating it, because native Cortex XDR agent telemetry is covered by the per-endpoint agent license and does not count against the daily allowance as of today.

• “The Data Lake tier is just cheaper storage” — not quite. It is significantly cheaper to ingest, but queries, dashboards, playbooks and public API calls consume Compute Units, any mixed-tier query touching a single Data Lake dataset incurs a full CU charge, and retention and event-forwarding costs follow the standard Analytics tier model. Cheaper is not free, and the CU model has to be in the conversation.
• “You keep everything, you just pay less” — no. The Data Lake tier has no XDM normalization, which for SentinelOne means the data does not land in xdr_data. BIOCs and analytics detectors depend on that normalized dataset, so they lose it. What survives is XQL and correlation rules written against the raw dataset. Note also that a few sources currently receive analytics-like treatment in the Data Lake tier as a temporary configuration that is documented as planned for removal — do not design around it.
• “80 to 95 percent reduction” — unverified. No vendor publishes that figure for this feed. The defensible numbers are the ones the customer measures: baseline with the ingestion-metrics queries first, then quote a reduction against their own starting point.
• “Native telemetry is subsidized” — say it precisely. The documented position is that native Cortex XDR agent endpoint and analytics telemetry does not count against the daily GB/day allowance because it is covered by the per-endpoint agent license, and that the per-endpoint agent entitlement starts at XSIAM Enterprise. “Subsidized” invites a pricing question nobody on the call can answer.

Full detail, including the XQL to baseline current volume before choosing a tier, is in the SentinelOne Log Reduction & Alert Tuning Guide. Source: Optimize data management in Cortex XSIAM and Configure Cortex Data Lake tier.

CrowdStrike Falcon Data Replicator Low volume, low fidelity

CrowdStrike's numbers look dramatically smaller, and that is the story rather than a footnote. FDR delivers compressed batches, and CrowdStrike simply provides far less raw event data than other vendors. Cheap to ingest, and correspondingly thinner to detect and investigate on.

These are absolute minimums, published as averages of compressed data, and they are what the estimator uses for the published-minimum band — 2.5 MB per Windows or macOS host and 10 MB per Linux host, reproducing ~25 GB and ~100 GB per day at 10,000 hosts. Some sources give the Linux figure as an 8–10 MB range. Real environments run higher, driven by host activity, the customer's Falcon module subscriptions, and which filtering policies are applied; field reports of 10–40 MB per endpoint per day are common, which is the estimator's activity-adjusted band. CrowdStrike publishes no upper figure and no per-agent-version split, so every band above the floor is derived.

• The data arrives partial. Raw FDR events lack much of the context other vendors provide natively, so XSIAM has to spend extra backend work stitching FDR records to other event sources to make them usable for analytics and investigation.
• Analytics coverage is a subset. With no on-endpoint causality chains, only a portion of XSIAM's analytics detectors light up, primarily network, file, process, and registry. The most advanced behavioral detectors are not fully operational on this telemetry.
• Still charged. Exactly as with SentinelOne, if the customer keeps CrowdStrike and streams via FDR, that volume counts against the XSIAM base subscription daily allowance.
• Compression cuts both ways. Compressed-at-rest figures are not the same as parsed and indexed volume. Confirm which measurement a customer is quoting you.

Deeper background: the captured CrowdStrike sizing research preserves the original FDR minimums and sizing considerations verbatim.

Microsoft Defender for Endpoint Two very different numbers

Microsoft publishes no flat expected megabytes per day. They estimate individual log entries at roughly 500 bytes, with certain events spiking to 2.5 MB each. That leaves you sizing between two numbers that differ by twentyfold, and picking the wrong one is how proposals fall apart.

The 5 MB per endpoint per day included with a Microsoft Sentinel E5 entitlement is where most Microsoft-led sizing conversations start, and it is what the estimator uses for the E5-included band — about 50 GB per day at 10,000 endpoints. Customers who have tried to run real investigations on it consistently report needing at least 100 MB per endpoint per day, which is the effective-IR band and lands at roughly 1 TB per day for the same estate. Microsoft publishes no flat expected megabytes per day and no per-OS split, so anything above that is derived.

• Server data is often simply absent. E5 and MDE telemetry frequently isolates or excludes server data unless Defender for Servers is licensed separately. When the customer says 10,000 endpoints, verify whether servers are in that number, because their event volume is far higher than workstations.
• Streaming path matters. Raw MDE events reach XSIAM through the dedicated Defender for Endpoint collector via Azure Event Hubs. The generic Event Hub collector is not suitable for EDR data because it does not support stitching.
• Analytics coverage is partial. XSIAM covers key network, file, process, and registry detections from MDE, but Microsoft cannot supply the patented on-endpoint causality chains a native Cortex agent produces, so the most advanced AI behavioral detectors are not fully operational on this data.
• The whole volume is charged. Keep Defender and stream raw logs into XSIAM through Graph API or Event Hubs, and that entire roughly 1 TB per day counts against the base subscription daily GB/day allowance.

Deeper background: the captured Microsoft Defender sizing research preserves the E5 baseline versus effective-volume framing and the cost-saving strategy verbatim.