I have the Sigma extension turned on but I find that, because Windows EventIDs are not unique and Sigma rules lack Channel specificity, I am spending a lot of time writing FP rules for detections where the same EventID occurred in a different Channel. My gut feeling is that there is more good in using the Sigma Rules than in not using them. Just sanity checking with others to make sure I’m not missing some magical FP repo where someone has contributed their Sigma anti-rules.
I found the free Sigma rules were just too noisy. In the end, I used the paid Soteria rules and also cherry-picked my own Sigma rules which I’ve converted over to LC detections.
2 Likes
I appreciate the insight. I’m curious: What criteria did you use to cherry pick? Was it needs based or did you look for Sigma rules with “higher severity”?
It’s basically to fill a few specific gaps in the paid Soteria rules, or for some very specific detection edge cases. Don’t get me wrong the paid Soteria rules are great.
I was using the LC Sigma API convert to basically save time in having to write a rule from scratch when there was an existing open source Sigma rule that matches what I needed.
It’s also helpful if there is some new type of attack that’s the new hotness and you want to make sure you have coverage, or you want to do a retro hunt in the past.
1 Like
We do the same thing.
1 Like
I am curious to know how you understand the Soteria rule coverage. When I look at their D&R rules they are hidden. Is it by the rule name that you are assessing the gaps in the Soteria rules?
There’s the rule names, the MITRE tags with them, and they also expose the MITRE report: https://mitre-attack.github.io/attack-navigator/#layerURL=https%3A%2F%2Fstorage.googleapis.com%2Fsoteria-detector-mapping%2F%2Fall.json
1 Like