Possible Bug With Sigma Parser

[jstore-embers]

Version

2.4.110

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

20

RAM

64 GB

Storage for /

2 TB

Storage for /nsm

12 TB

Network Traffic Collection

tap

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Security Onion can not ingest these Sigma rules if the same field/modifier combination is used within a given select statement. I can't tell if this is an issue with the Sigma parser used by Security Onion, or if these rules are actually incorrect according to the Sigma schema.

I noticed this when troubleshooting an issue ingesting Sigma rules from a private repo as documented in this issue.

Here's the relevant logs with the repo file names redacted:

{
  "fields": {
    "detectionEngine": "elastalert",
    "sigmaParseError": {
      "/opt/sensoroni/sigma/repos/<REDACTED>": {
        "Errors": [
          "line 33: mapping key \"CommandLine|contains\" already defined at line 27"
        ]
      },
      "/opt/sensoroni/sigma/repos/<REDACTED>": {
        "Errors": [
          "line 23: mapping key \"CommandLine|contains\" already defined at line 21"
        ]
      },
      "/opt/sensoroni/sigma/repos/<REDACTED>": {
        "Errors": [
          "line 27: mapping key \"Details|contains\" already defined at line 26"
        ]
      },
      "/opt/sensoroni/sigma/repos/<REDACTED>": {
        "Errors": [
          "line 23: mapping key \"Details|contains\" already defined at line 22"
        ]
      }
    },
    "syncId": "8e320102-9130-4c1e-9694-d246bfbaf368"
  },
  "level": "error",
  "timestamp": "2024-12-03T20:04:15.362726435Z",
  "message": "something went wrong while parsing sigma rule files from repos"
}

Note that the parser uses the field and modifier combination to create a key, presumably for a key value pair for a hash table. Since each key must be unique, these rules are not ingested.

I have reported this to the private repo in hopes they will re-write the rules for better compatibility. I haven't been able to find anything that definitely says this is not allowed according to the sigma syntax/schema, so I'm reporting it in case the parser is something unique to security onion that could be modified to account for this. It's possible rules from other repositories are also written this way, and my interpretation is that they are using these with an implied "AND" between the two lists.

For example, attempting to detect ping OR netstat where the output is being processed by find OR redirected.

selection:
CommandLine|contains:
- ping
- netstat
CommandLine|contains:
- find
- >

I realize these should be multiple selection statements, but there is an implicit AND between all fields in a selection statement, so I don't see why this couldn't be implemented and hold true even if the field is included twice with the same modifier.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[defensivedepth]

Im looking into this.

[defensivedepth]

I believe this was fixed upstream. If not, go ahead and reopen.