Skip to content
Help: SentinelOne d...
 
Notifications
Clear all

Help: SentinelOne data not parsing correctly in our Graylog setup.

2 Posts
2 Users
0 Reactions
16 Views
(@grafana_knight_shift)
Reputable Member
Joined: 6 months ago
Posts: 324
Topic starter   [#11251]

Alright, I've been banging my head against this for a few nights now. We're ingesting SentinelOne syslog data into Graylog (v5.1), and while the events are landing, the parsing is a mess. Fields aren't being extracted properly, which makes building dashboards and setting up alert rules a real pain.

Our current setup:
* SentinelOne is configured to send syslog (CEF format) to our Graylog node.
* We're using the built-in CEF parser in a pipeline rule, but it seems to be choking on the S1-specific extensions.

Here's a raw message snippet from the `full_message` field:

```
CEF:0|SentinelOne|MTP|22.4.2.5.1061|15|Network event|3|dvchost=host.example.com dvc=192.168.1.10 act=NetworkActivity cat=NetworkActivity src=10.0.1.15 dst=172.217.16.174 externalId=1234567890
```

The issue is that fields like `src`, `dst`, and `externalId` aren't landing as separate, searchable fields. They're all stuck in the `full_message`. I've tried tweaking the CEF parser extractor settings and even wrote a crude Grok pattern, but it feels fragile.

Has anyone else wired up S1 to Graylog successfully? Specifically:
* Did you use the raw CEF parser, or did you write a custom extractor?
* Are there any known quirks with S1's CEF implementation that need pre-processing?

My end goal is to get clean fields for at least `src`, `dst`, `act`, and the S1 event ID, so I can start correlating with our Prometheus host metrics and Loki logs. Right now, it's just a blob.

- away



   
Quote
(@ide_tinkerer)
Reputable Member
Joined: 6 months ago
Posts: 338
 

Yeah, the built-in CEF parser can be a bit finicky with vendor extensions. I've had similar headaches. For SentinelOne data specifically, I found that the CEF parser's field mapping sometimes misses custom key-value pairs if they aren't part of the base CEF spec.

What worked for me was using a pipeline rule with a regex extractor instead of relying solely on the CEF parser. The CEF format after the header is basically just key=value pairs, so you can capture the extra S1 fields with something like:

```
rule "extend_s1_cef"
when
has_field("cef_version")
then
let matches = regex("src=([^\s]+)", to_string($message.full_message));
set_field("src_ip", matches["$1"]);
// repeat for dst, externalId, etc.
end
```

It's a bit more manual, but you can build it out incrementally as you see new fields come in. Have you checked if the `cef_extensions` field is being populated at all by the built-in parser? That might give you a clue about where it's failing.


editor is my home


   
ReplyQuote