Sigma Rule Repository Enhancements— New Folder Structure & Rule Types
In the past few months we’ve been busy doing a major overhaul of the Sigma project, which includes rules re-writes, metadata enhancements (titles, descriptions, false positives notes) and much more.
Last month we introduced the logsource-guides a new addition that aims to ease the process of mapping the different log sources used in Sigma rules and their OS counterparts
More details were published in a dedicated blog that you can read here
Today we’re also introducing a set of new changes that will ease the use of Sigma rules and enable more contributions from the community. For this, let’s talk about the goal we want to achieve with these new changes.
Rule Types
The Sigma project always contained a single folder named “rules” that had all the “detection-rules”. Ranging from very broad rules to specific APT rules in a single place.
While this was fine when starting out, as the set kept growing, this didn’t scale well as by nature there are many different type of rules with different goals and different false positive appetites. From a usability perspective, it’s also not clear which rules are more important and which have timely usability (such as IOC based rules).
Hence why we’re introducing a new folder structure that reflects this idea.
New Folder Structure
In this update, in addition to the traditional “rules” folder, we’re introducing four additional folders
- rules-emerging-threats
- rules-threat-hunting
- rules-dfir (TBD)
- rules-compliance (TBD)
This blog post will cover only the “emerging threat” and “hunting” rules folders.
Emerging Threat Rules
One of the strong suits of Sigma is that it’s product agnostic. Meaning once you write a rule in Sigma it can be converted to any back-end as long as that back-end is implemented in pySigma (or the soon to be deprecated sigmac).
This feature allows anyone to share rules and they are immediately usable by virtually “everyone”.
This is key when sharing rules for “emerging threats” such as zero day exploits, malware or threat actor activity. Hence why we’re adding this new folder/rule type.
The “emerging-threat” folder will contain rules that are related to Malware, Threat Actors or specific Exploits. I.e more specific rules that might not be as relevant as time goes on but are necessary for having extra coverage when needed.
An example of such rules would be the recent reporting around the Snake malware or the COLDSTEEL RAT.
You’ll notice that all related rules for a threat are grouped together with extra details and links. This is to ease the process of sharing the rules and providing more context about a threat when needed.
Threat Hunting Rules
While engineering detections or hunting for maliciousness a common step is to formulate a hypothesis about a certain behavior based on some logic. This is sometimes called “Threat Hunting”. The aim is to find something whether be it known or sometimes unknown.
During said activity the false positive appetite of the “hunter” is above the average “triaging analyst”, hence why separating rules of such type is important from a detection pipeline and Sigma user perspective to set the right expectations.
This new folder aims to contain such rules.
Note that the migration of the older rules that fit this new definition to the new rules-threat-hunting folder is still a work in progress. Please expect a dedicated blog on these hunting rules and their new features in the coming weeks.
Conclusion
With these new folders and rule types, our hope is to expand the utility of the main Sigma rule repository and attract new types of contributions.
As we continue the work on this major step in the coming weeks. We’re also introducing in the coming weeks the long awaited rule releases in the form of “rule packages” in the release section of GitHub.
The aim with these releases is to reduce hassle that users have to go through when navigating the rule base and selecting their specific rules from the different folders and sub-folders.
The rule packages will honor this new folder structure as well as the “level” and “status” fields. By providing different packages grouping “stable”, “test” and “experimental” with the different “informational”, “low”, “medium”, “high” and “critical”.
Please stay tuned for more in the coming weeks!
If you’re interested in regular updates on the Sigma project, please be sure to subscribe to this publication and follow @sigma_hq on Twitter.
