Replies: 1 comment 2 replies
-
The v2 specification defines clear ways for case-(in)sensitivity:
Both modifiers are full supported by pySigma and case-insensitivity syntaxes mentioned above can easily be implemented by backends:
|
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The Sigma specification mentions that :
and
However, those are the only two mentions of case-sensitiveness in the whole Sigma specification.
This leads to the following problem: There is no standard way to express a case-insensitive regex in a Sigma rule.
From my understanding, this is undefined behavior, which Sigma should try to avoid. Individual backends must decide without guidance how to handle those, which undermines the vendor-agnosticness that we love of Sigma .
For example, in QRadar and splunk, the way to define a case-insensitive regex is by prepending it with
(?i)
. With Crowdstrike Falcon Logscale, however, it's/myregex/i
. In sqlite, you need tolower()
the field you're searching on. Completely different ways to express the same outcome. I think Sigma should standardize regex case-sensitiveness, and maybe other regex flags as well.Beta Was this translation helpful? Give feedback.
All reactions