SentinelOne Log Reduction
& Alert Tuning Guide

1. Filter noisy, low-value event types at the source

Where this is enforced. For the DeepVisibility path, the documented filter point is the SentinelOne Cloud Funnel configuration, not a generic connector setting: in SentinelOne go to Singularity Data Lake → Cloud Funnel, set the AWS S3 target, enable Telemetry Streaming, and build a Query Filters expression selecting only the agents that should stream, confirming it with Validate (Cortex documentation).

2. Exclude non-production, dev, and test endpoints

Tag those endpoints in the SentinelOne console and scope streaming by group, expressed as an agent-selection Query Filter on the Cloud Funnel configuration. unverified that a group-based policy can suppress telemetry forwarding independently of Cloud Funnel; confirm in the customer's console version before promising it.

3. SentinelOne-side visibility filters

unverified A console path named Deep Visibility → Ingestion Policy with trusted-parent-process allowlisting and known-good software suppression is not documented in the Palo Alto ingestion guide and should not be stated as fact. What is documented is the Cloud Funnel query filter plus field selection. SentinelOne separately markets data-pipeline filtering ahead of the lake; treat exact UI names as customer-specific until verified.

4. XSIAM-side reduction with Parsing Rules

XSIAM's documented drop-and-trim control plane is Parsing Rules, which requires View/Edit RBAC on Configurations → Data Management and lets you remove data not required for analytics, hunting, or regulation, pre-process incoming data, and tag events during ingestion. Rules are bound to a vendor and product, apply XQL transformations to raw log input, and may return zero, one, or more rows, so a rule can emit nothing and effectively drop a log. Rule groups carry a no-match policy that either drops the log or keeps a default format, and rules can be tested against real logs before implementation (Parsing Rules).

Good uses: duplicate coverage when two EDRs forward the same behavior, and verbose informational events with no detection or compliance use case. Suppressing an issue is not the same as dropping a log — an issue exclusion explicitly does not delete the logs that triggered it.

4b. Put the data in the right tier before you drop any of it

There is a supported alternative to filtering that most sizing conversations skip: choosing the destination. Palo Alto documents three, with different costs and capabilities (Optimize data management in Cortex XSIAM).

How to assign a tier. Configuration is exclusively through Parsing Rules: Settings → Configurations → Data Management → Parsing Rules, the Both tab, right-click the [INGEST] rule for the dataset and select Change Tier to Data Lake. XSIAM disables the default rule, adds a user-defined rule carrying tier=lake, and appends _lake_raw to the dataset name. Tier changes apply only to data ingested afterwards, and existing data is never moved between tiers (Configure Cortex Data Lake tier).

• No XDM normalization in the Data Lake tier, so SentinelOne data routed there does not land in xdr_data — BIOCs and analytics detectors lose it, and XQL plus correlation rules against the raw dataset are what remain.
• Compute Units apply. Queries, scheduled queries, dashboards, playbooks and public API calls consume CU, and any mixed-tier query touching one Data Lake dataset incurs a full CU charge. Retention and event forwarding are priced on the standard Analytics model.
• Temporary behavior is not a design input. A few sources currently receive analytics-like treatment in the Data Lake tier; the documentation states this is temporary and planned for removal.
• Federated Search is search only, slower because it depends on the external cloud, and consumes CU when queried. It is a compliance and sovereignty answer, not a detection one.

5. Scope the forwarding configuration itself

For the S3 and Cloud Funnel path, scope by site or account group in the SentinelOne query filter and keep file hygiene inside the documented constraints: one log per line, no multi-line format, gzip or uncompressed, and up to roughly 50 MB compressed per file for best performance. For the alert and activity path, the SentinelOne content pack and the SentinelOne Activity and Alerts integration pull activities, threats, and issues, a far narrower and cheaper feed than raw telemetry. unverified A severity-floor forwarding control in SentinelOne Activity Filters is not documented by Palo Alto — but a severity floor is documented on the integration path, covered in Part 3.

The Standard Collector handles raw DeepVisibility telemetry via Cloud Funnel to S3, the content pack / integration path applies to tenants onboarded before July 26, 2026, and the connector named SentinelOne applies after that date (SentinelOne DeepVisibility). Confirm the onboarding date before quoting a configuration path.

• The severity floor exists on the integration path, not the telemetry path. The v2 integration exposes an alert-severity parameter and a minimum risk score; the event collector exposes event-type selection and fetch limits.
• Use Site IDs on the v2 integration to keep multi-tenant or lab sites out of the tenant entirely.
• Set First fetch time conservatively. A long first-fetch window is a one-time but real ingestion spike.
• Detection handoff without the telemetry bill. If a customer needs alerts and response actions rather than raw hunting data, the event collector plus the v2 integration covers threats, alerts, agent actions, and remediation with no Cloud Funnel volume at all.
• Event-class vocabulary. DeepVisibility event types visible through the v2 integration are events, file, ip, url, dns, process, registry, scheduled_task, and logins across windows, linux, macos, and windows_legac agents.
• Collector parameters to capture during onboarding: Access Key or Assumed Role, Name, SQS URL, plus AWS Client ID and AWS Client Secret, or Role ARN and External Id.

The trap in most ingestion queries is a hardcoded vendor filter. Tenants label sources differently depending on the collection path, the connector version, and whatever the person who onboarded it typed, and the documentation does not publish the _vendor and _product values. So do not filter by vendor at all. Group by it instead, and the tenant tells you its own naming.

Set the time range in the query builder’s time picker, or keep the config timeframe stage shown here. Validate field names against the tenant schema on first run.

B1. What is arriving, and how much — the one query to run first

config timeframe = 7D
| preset = metrics_view
| comp sum(total_size_bytes) as bytes, sum(total_event_count) as events by _vendor, _product
| alter GB_7d = divide(bytes, pow(2,30))
| alter GB_per_day = divide(GB_7d, 7)
| fields _vendor, _product, GB_per_day, GB_7d, events
| sort desc GB_7d

What you get. Every source in the tenant, ranked by volume, with the customer’s own vendor and product strings printed in the first two columns. This answers the only question that matters at the start: what is actually driving the bill, and is the EDR feed the top line or a footnote. Read the vendor string for the EDR feed off this output and copy it literally if you later want to drill into one source. A seven-day window smooths weekday and weekend patterns; widen it to 30D if the estate is seasonal, and divide by 30 instead of 7.

B2. Is it growing, and did something change

config timeframe = 30D
| preset = metrics_view
| alter day = format_timestamp("%Y-%m-%d", _time)
| comp sum(total_size_bytes) as bytes, sum(total_event_count) as events by day, _vendor, _product
| alter GB = divide(bytes, pow(2,30))
| fields day, _vendor, _product, GB, events
| sort asc day

What you get. A daily series per source, still with no vendor filter. You are looking for three things: a trend line that is climbing, a step change on a specific date that usually maps to a policy or agent version rollout, and flat zero days that mean the feed broke and nobody noticed. A single day’s number is not a baseline, and this is the query that proves whether the number from B1 is representative or a bad day.

B3. Where is the volume concentrated

config timeframe = 7D
| preset = metrics_view
| comp sum(total_size_bytes) as bytes, sum(total_event_count) as events by _vendor, _product, _collector_name, _collector_type, _final_reporting_device_name
| alter GB = divide(bytes, pow(2,30))
| fields _vendor, _product, _collector_name, _collector_type, _final_reporting_device_name, GB, events
| sort desc GB
| limit 50

What you get. The collectors and reporting devices producing the most data. Volume is almost never spread evenly, and this is where the actionable finding usually lives: one broker, one collector, or a handful of servers accounting for a disproportionate share. These grouping fields are the ones Palo Alto uses in its own ingestion-health correlation examples.

• A number you can defend — measured GB per day by source, from the customer’s tenant, replacing every planning range on the estimator page.
• The tenant’s own vocabulary — the literal vendor and product strings, so any follow-up query or correlation rule can be pinned to an exact match instead of a guessed one.
• A direction for the conversation — whether the answer is tiering, export tuning, agent displacement, or nothing at all because the EDR feed is not the problem.

That is enough to size a plan. Go deeper only when these three raise a question: the full XQL library covers health, event-class mix, and noisiest-endpoint analysis, and the nine-step run order is for when a feed is broken rather than merely expensive.

Sections in a Parsing Rules file

• Statements never start with a dataset or preset; the raw source is handled by the system.
• Permitted stages: alter, fields, filter, join, plus call to invoke another rule. An inner join is allowed in CONST, INGEST, and RULE but not in COLLECT, and must start with dataset=<lookup> | ....
• Permitted functions: parse_timestamp, parse_epoch, regexcapture. regexcapture works only in Parsing Rules.
• No output stages; a RULE object holds a single statement; every statement ends with a semicolon.
• IN accepts only a literal sequence list, for example device_name in ("device1", "device2").
• Access requires Cortex Account Administrator or Instance Administrator, and the editor requires View/Edit on Configurations → Data Management.
• Rules cannot be created for NGFW datasets matching panw_ngfw_<text>_raw or for panw_observability_raw.

There is no drop stage. Reduction is expressed two ways: a filter that yields no rows for a log, since a rule can return zero, one, or more rows, and a rule-group no-match policy that either drops the log or keeps it in a default format (file structure and syntax, Parsing Rules).

• Reduce with filter, not with hope. Write INGEST filters for the specific classes the customer agreed to drop, then verify with the Part 4 queries rather than assuming the rule fired.
• Trim fields after mapping, not before. Use fields to keep what XDM mapping, BIOCs, and correlation rules consume. Anything a BIOC references on xdr_data is off limits.
• Prefer EXTEND over editing vendor rules so Marketplace updates do not overwrite your work.
• Centralize thresholds in CONST. Host lists, path allowlists, and trusted signer names belong in constants referenced as $MY_CONST, so a tuning change is one edit with one review.
• COLLECT will not help Cloud Funnel data. It reduces at the Broker VM, and DeepVisibility arrives through a cloud S3 and SQS collector. Use it only for syslog-delivered SentinelOne data, if that path exists.
• Test before promoting. The editor tests rules against actual logs, validates output before implementation, and surfaces parsing errors.
• Tag during ingestion. Tag SentinelOne events by estate — production, lab, kiosk — so later reduction and exclusion decisions reference a tag instead of a growing hostname list.
• Keep the S3 side healthy. Retain at least 7 days on the bucket lifecycle rule so a collector outage does not become permanent data loss, and honor one log per line, gzip or uncompressed, up to roughly 50 MB compressed per file.

Queries are reproduced as written for the tenant. Verify field names on first use, since collection_auditing, insert_timestamp, and event_type availability vary by tenant and license.

config timeframe = 24h
| dataset = xdr_data
| filter _vendor = "SentinelOne"
| sort desc _time
| limit 20

config timeframe = 7d
| dataset = xdr_data
| filter _vendor = "SentinelOne"
| fields _time, _vendor
| bin _time span = 1d
| comp count() as event_count by _time
| sort asc _time
| view graph type = line xaxis = _time yaxis = event_count

config timeframe = 7d
| dataset = xdr_data
| filter _vendor = "SentinelOne"
| comp count() as event_count by _product, event_type
| sort desc event_count
| view graph type = column subtype = grouped xaxis = event_type yaxis = event_count series = _product

config timeframe = 7d
| dataset = collection_auditing
| filter lowercase(collector_type) contains "sentinelone"
    or lowercase(description) contains "sentinelone"
| fields _time as time,
         collector_host_name as collector_name,
         collector_type,
         classification as issue_name,
         description as issue_description

config timeframe = 7d
| dataset = xdr_data
| filter _vendor = "SentinelOne"
| alter delay_sec = timestamp_diff(insert_timestamp, _time, "SECOND")
| bin _time span = 1d
| comp avg(delay_sec) as avg_delay_seconds by _product, _time
| sort desc avg_delay_seconds
| view graph type = line xaxis = _time yaxis = avg_delay_seconds series = _product

config timeframe = 7d
| dataset = xdr_data
| filter _vendor = "SentinelOne"
    and (event_type = null or actor_effective_username = null)
| fields _product, event_type, actor_effective_username
| comp count() as gap_count by _product
| view graph type = column subtype = grouped xaxis = _product yaxis = gap_count

config timeframe = 7d
| dataset = collection_auditing
| comp count() as occurrence_count by collector_type, classification
| sort desc occurrence_count
| view graph type = column subtype = stacked xaxis = collector_type yaxis = occurrence_count series = classification

// Rule: SentinelOne Deep Visibility - Network Events
// Version: 1.2 | Last Updated: 2026-09-11
// Owner: SOC Engineering
// Purpose: Normalize netconn events; drops internal-only flows

• Ingest raw EDR events from SentinelOne DeepVisibility — Cortex documentationCloud Funnel configuration parameters, the instruction to include all fields, collector authentication parameters, S3 and SQS setup, file format constraints, 7-day bucket retention recommendation, datasets, and third-party analytics limitations.
• SentinelOne DeepVisibility — Cortex documentationStandard Collector, content pack before July 26 2026, and connector after that date; content pack contents and integration list.
• SentinelOne Activity and Alerts — Cortex XSOAR/XSIAM integration referenceEvent types activities, threats, alerts; First fetch time default of 3 days; per-event-type fetch limit of 1 to 1000; sentinelone-get-events.
• SentinelOne v2 (Partner Contribution) — integration referenceAlert severity selection, minimum risk score for API 2.0, Site IDs scoping, fetch limits and interval, Deep Visibility event types and agent OS values.
• Issue exclusions — Cortex documentationSuppression scope, backward scan, schedule start and expire, and the fact that logs are not deleted.
• Add an IOC or BIOC rule exception — Cortex documentationSingle-attribute limitation and the pointer to exclusion rules for advanced criteria.
• Create a correlation rule — Cortex documentationSupported and unsupported XQL, target datasets and added fields, Medium-and-above auto-opens a case, Low is not grouped.
• Create a BIOC rule — Cortex documentationxdr_data and cloud_audit_log only, mandatory event_type filter, supported event types, Pro per GB requirement for cloud audit logs.
• Ingest external alerts — Cortex documentationRequired and optional field mappings and the Filter and Map flow.
• Visibility of logs and alerts from external sources — Cortex documentationCorrelation issues on non-normalized and normalized logs; Analytics, IOC, and BIOC only on normalized logs.
• Set up case scoring — Cortex documentationSmartScore enablement, scoring rules, first-issue-only option, 48-hour initial calculation.
• Overview of data ingestion metrics — Cortex documentation5-minute aggregation, metric field names, metrics_source and metrics_view, health issues and the Cortex - Analytics prerequisite.
• Creating correlation rules to monitor data ingestion health — Cortex documentationThe silent-source example query, its grouping fields, and the full rule configuration.
• Parsing Rules — Cortex documentationRBAC requirement, data-removal and pre-processing capabilities, vendor and product binding, zero-or-more row output, no-match policy, tagging, and rule testing.
• Parsing Rules file structure and syntax — Cortex documentationINGEST, COLLECT, CONST, RULE, and EXTEND sections; permitted XQLp stages and functions; IN literal-list restriction; comment syntax; semicolon requirement; administrator permission; excluded datasets.
• Optimize data management in Cortex XSIAM — Cortex documentationAnalytics tier, Cortex Data Lake tier and Federated Search: goals, analytics and correlation support, data location, usage model and restrictions.
• Configure Cortex Data Lake tier — Cortex documentationTier minimums, the capability matrix, Compute Unit charging including full CU on mixed-tier queries, the Parsing Rules assignment path with tier=lake and _lake_raw, and the non-retroactive rule.
• XQL query best practices — Cortex documentationDefault and maximum result limits, time-frame and field-selection guidance.
• Cortex XSIAM Destination — Cribl documentationEndpoint format, authentication options, batching, event and batch size limits, rate limits, and concurrency defaults.
• Cribl–Cortex XSIAM data source onboarding guideRequired header fields and their XSIAM mappings, UUID guidance, the recommendation not to route Palo Alto first-party data through Cribl, and the XDM mapping caveat.
• Cribl and Palo Alto Networks launch partnership with Cortex XSIAM integrationStream 4.11.0 destination, the XSIAM Cribl integration and single-instance limit, token shown once, and the warning not to modify or drop events sent to XSIAM.
• Cribl pack for SentinelOne Cloud FunnelPack capabilities, Cloud Funnel v1 versus v2 formats and naming differences, per-category pipelines, well_known lookups, and object-storage routing with Replay.
• Cribl Packs DispensaryPack versions and publication dates, including the 2023 Cloud Funnel pack and the March 2026 Palo Alto XSIAM pack, and the absence of published reduction percentages.
• XQL query for calculating XDR log ingestion — Palo Alto Networks LIVEcommunityCommunity-validated metrics_source volume query and the per-agent log-count pattern. Community source, not documentation.

Continue

• XSIAM & EDR Telemetry Economics — sizing ranges, the daily ingest estimator, fidelity matrix, and discovery questions.
• Third-Party EDR Sizing Deep Dive — the captured 10,000-endpoint research for SentinelOne, CrowdStrike, and Defender.
• Cortex XDR Deep Dive — what the native agent produces and why causality changes detection coverage.