Closed joshnck closed 4 months ago
The logic in this sigma rule is flawed - but I hope my point comes across. Let me know if you'd like me to refactor this rule to make more sense if I am unclear.
The logic and use case are clear. There are some reasons I'm a bit hesitant on this. It could be implemented by additional field extractions configured in the SIEM. Defining fields in Sigma was already subject of discussions in the past and the outcome was to keep this out of Sigma, as it adds lots of complexity to it and while the topics are coupled together, Sigma main focus lies on detection than field extraction.
The syntax you've pointed out has the issue that there's a difference between regex matching and field extraction. E.g. in Splunk this are different commands, regex
and rex
. Until now we mostly got around the issue to "understand" the regular expression while the conversion. It's basically passed through to the query with some minor escaping. Adding this to Sigma would require to determine if the regular expression contains field extractions and to adapt the query accordingly. It also challenging for portability reasons.
I'm unsure if this is the right way to add this logic to the detection rules or if a separate rule type could be more appropriate. This would separate detection logic from log semantics and enable the conversion process to generate extraction configs or at least give the user a choice for where the extraction should be done.
There are times where you need to compare two substrings that you pull apart using Regex and in Splunk you can easily use named capture groups. Consider the following query:
If this were doable in Sigma, the rule should look like:
Unfortunately, named capture groups are not handled in PySigma to create a new field like they are in Splunk.