Difference between the available SentinelOne parsers

[emilh]

Hi,

looking through some of the new Native Dashboards and noticing that the EDR-related ones define the SENTINEL_EDR parser made me question if we are using the wrong parser for one SentinelOne EDR -> SecOps SIEM integration.

Looking through the documentation I see four different parsers/feeds for SentinelOne:

The way I understand it SENTINEL_DV is a legacy parser and SENTINELONE_ALERTS is a simple feed with alerts with incidents from within SentinelOne.

Then things become a bit more unclear.
What's the difference between SENTINEL_EDR and SENTINELONE_CF, provided we only use SentinelOne for EDR?

Currently we have SecOps ingestion setup with SENTINELONE_ALERTS and SENTINELONE_CF, but since some SecOps out of the box features such as those Native Dashboards and maybe also some Curated Detections specify the SENTINEL_EDR parser, is this the preferred parser?

This thread was inspired by a similar thread on CrowdStrike parsers.

[James_E]

Its my understanding you can use the log type SENTINELONE_CF to send XDR Telemetry outside of just the SENTINELONE_EDR events. If you look at the instructions here for collecting SENTINELONE_EDR, you still setup Cloud Funnel to ingest your logs into SecOps, but if you wanted to ingest your XDR Telemetry, then you can use these instructions to collect and ingest those events, which ultimately just has you do the same thing except you "Enable Telemetry Streaming" to get the XDR data into your bucket.

So  if you want to just ingest SENTINELONE_EDR, follow these instructions and set the log type to SENTINELONE_EDR. If you want XDR Telemetry, then follow these instructions and use the log type SENTINELONE_CF.

[emilh]

Yes, that makes sense.

However, what made me question this again is seeing that some built in features specifically filters on the SENTINEL_EDR parser, meaning that we won't get detections when ingesting with SENTINELONE_CF.

Here's an example query from the Google provided "EDR Alerts Overview" Native Dashboard:

$event.metadata.log_type = /LIMACHARLIE_EDR|CS_EDR|CS_DETECTS|ESET_EDR|CHECKPOINT_EDR|SOPHOS_EDR|OSQUERY_EDR|DIGITALGUARDIAN_EDR|SENTINEL_DV|MICROSOFT_DEFENDER_ENDPOINT|SENTINEL_EDR|UPTYCS_EDR|SYMANTEC_EDR|FORTINET_FORTIEDR|REDCANARY_EDR|CYBEREASON_EDR|MICROSOFT_DEFENDER_IDENTITY|DEEP_INSTINCT_EDR|CB_EDR|PAN_EDR|FIREEYE_HX|WATCHGUARD_EDR/ nocase

For the Native Dashboards I guess this is fine as I could duplicate and edit the dashboards myself so that they also look at events from SENTINELONE_CF. But then we have the question of Curated Detections where the queries are not visible to end customers.

In short this makes me wonder if SENTINEL_EDR is the "preferred" parser and if we should switch to that since we're only ingesting EDR events from SentinelOne.

[James_E]

I agree with you. If you're just ingesting SENTINEL_EDR logs then send those through the SENTINEL_EDR log type and only use SENTINELONE_CF for XDR Telemetry.  If I had to guess why SENTINEONE_CF isn't included in the "EDR Alerts Overview" dashboard, it's because SENTINELONE_CF events don't have the fields the dashboard would expect (this is a hunch as I don't have any SENTINELONE_CF logs to look at). And of course, if you have the Deep Visibility logs, those should be ingested through the SENTINEL_DV log type.

[emilh]

A brief update to this:

After a lengthy back and forth with SentinelOne it seems like the fields specified by the SENTINEL_EDR parser are deprecated and a part of the 1.0 spec of Cloud Funnel. This also explains why 99% of those fields are empty when looking at the date.

In short that leaves us with the wide set of data specified by the SENTINELONE_CF parser.

Once again this is also slightly worrying as a EDR-related Native Dashboards provided by Google are broken as they filter on the now deprecated SENTINEL_EDR parser and perhaps for some curated detections?