Definition of "logsource" values like product or category.

[Maspital]

Hey,

I am currently using chainsaw + SIGMA to evaluate log datasets and stumbled upon the following issue:
Certain SIGMA rules produce an abnormally high number of false positives, to the point where I suspect that it just triggers on most events. The rule in question is

title: Sysmon Blocked Executable
id: 23b71bc5-953e-4971-be4c-c896cda73fc2
description: Triggers on any Sysmon file block executable event. Which should indicates a violation of the block policy set
status: experimental
author: Nasreddine Bencherchali
date: 2022/08/16
references:
    - https://medium.com/@olafhartong/sysmon-14-0-fileblockexecutable-13d7ba3dff3e
tags:
    - attack.defense_evasion
logsource:
    product: windows
    category: file_block
detection:
    selection:
        Image: '*'
    condition: selection
falsepositives:
    - Unlikely
level: high

I think the problem is that the category in question (file_block) is not mapped to anything - where and how can I define this?
In this example, the category should be file_block iff "provider_name": "Microsoft-Windows-Sysmon" and event_id: 27, which would clearly identify the category.

I have a similar problem for several other rules. Am I perhaps misunderstanding how certain things work?

Any help on this would be much appreciated :)

[FranticTyping]

Hey @Maspital

I'm guessing you're running chainsaw with the sigma-event-logs-all.yml mapping file. This mapping file does not filter based on provider name or category which means that some Sigma rules (like the file block one you mentioned above) cause a huge number of false positives.

You could either extend the sigma rule to also require a specific event ID (which should cut down the number of FPs), or you could use the sigma-event-logs-legacy.yml mapping file instead which supports "Provider" mappings.

I don't think either of these two options will completely solve your issue, but it should reduce the number of FPs that you face.

[alexkornitzer]

There is also potential to add category support to the mapping to apply 'x' filter when category 'y' is set. But this would require code enhancements.

[Maspital]

Yes, I'm using a modified version of sigma_event_logs.all (because winlogbeat likes to name stuff differently). Changing SIGMA rules themselves even slightly is something I would like to avoid because I want to be able to say "this dataset was created with SIGMA vXX" so it can be reproduced easily (though this is probably the easiest solution). In this case the change would be simple, but I wouldn't say I'm competent enough to confidently say that whatever change I intend to do does not change the intended result/logic of a given SIGMA rule :D

Using the legacy mapping file seems like it both has a lot of duplicate entries and prevents any novel alerts from being shown because they are blocked by the manually set filters(?).

Having category support like you mentioned @alexkornitzer would be a really nice and useful feature imo, but I dont know how much effort this would require on your part.

[alexkornitzer]

So adding this code wise is pretty easy the challenge comes from how to extend the mapping schema in a clear way, my current thinking is something like this:

---
name: Chainsaw's groupless Sigma mappings for Event Logs
kind: evtx
rules: sigma
...

extensions:
  preconditions:
    - for:
        category: file_block
      filter:
        int(EventID): 27
        Provider: Microsoft-Windows-Sysmon
...
groups:
...

Where the for block can consist of different identifiable fields of a Sigma rule.

[Maspital]

That looks great! Assuming knowledge of Sigma rules in general, this is nice and understandable in my opinion.

So this would work for whatever field may be defined within the logsource of a rule?

[alexkornitzer]

Ah good spot nah I would wanna support things like name too, so it should be this:

---
name: Chainsaw's groupless Sigma mappings for Event Logs
kind: evtx
rules: sigma
...

extensions:
  preconditions:
    - for:
        logsource.category: file_block
      filter:
        int(EventID): 27
        Provider: Microsoft-Windows-Sysmon
...
groups:
...

But awesome, okay i'll see if I can do this when I get time otherwise i'll lob it at someone else :)

[Maspital]

Any news regarding this? :) @alexkornitzer

[alexkornitzer]

@Maspital can you give the feature/extensions branch a try?

[Maspital]

Seems to work nicely, at least for the things I tested 👍 I will try it out in more detail tomorrow