How to version detection rules?
Why your detection rules should be versioned and how to properly implement best software engineering practices for effective Detection Engineering management.
Why is detection rules versioning important?
Detection rules versioning plays a crucial role in optimizing Security Operations Centers (SOC). By implementing versioning, organizations can ensure the accuracy, reliability, and agility of their detection rules.
Imagine a detection rule in a Splunk environment to identify a specific malware, let's call it ErawlamLive[1]. The initial query may look like this:
index=main url=*foo*
Over time, new variants of ErawlamLive may emerge, making the existing detection rule less effective. To address this, it is crucial to adjust the detection rule so that all variants can be monitored. The adjusted query may look like this:
index=main url=*foo* OR *bar*.
Let's consider the situation of not having rule versioning in place:
- First, we don't really know when the rule changed, so we don't really know since when we are monitoring this new variant.
- We also probably don't know either who in the team made the change (was it bob or alice?).
- If for any reason we need to revert back to the previous version of the rule, because of performance issues for example, then, what was the previous version of the rule? Only the person who made the modifications knows it, and at the condition of the rule being simple, but what about a 100+ lines Splunk query?
- The search query is one thing, but did the parameters of the search changed too? What is under the same name? Was it running at the same intervals? And so on. We understand here that a detection rule is more than a search, it has a name and parameters.
- How to know how many and which rules changed last month?
Now, let's consider a mature SOC where detection rules are versioned. All the above questions can be easily answered, because of versioning.
Regularly updating and tracking versions allows for seamless maintenance, easy troubleshooting, and efficient collaboration among the security team.
By versioning detection rules, we can easily track and manage changes with precision and confidence. For instance, we can maintain a dedicated repository or version control system where each iteration of the detection rule is stored, allowing us to revert back to previous versions if needed.
INFO
The French regulation ANSSI PDIS 🇫🇷 goes further by making detection rules versioning mandatory for nation-critical organizations, and greatly advised for any other SOC.
Software Engineering versioning
Instead of reinventing the wheel, let's look at how software is versioned with the 3 principal existing schemes. After all, the cybersecurity industry is more and more talking about Detection-as-Code, so we can probably borrow a few things there.
CalVer
CalVer, short for Calendar Versioning, is a software versioning approach that derives version numbers based on calendar dates rather than using arbitrary numbers or labels. The CalVer scheme follows a predictable format of assigning version numbers, typically in the format of <year>.<month> or <year>.<month>.<day>.
Popular software such as Ubuntu have switched to this versioning scheme and the key idea behind CalVer is to provide meaningful and human-readable version numbers that convey information about when a particular version of software was released or updated.
While it allows to easily understand the relative age and order of different versions, and it is a no-brainer for developers compared to SemVer for most software, it doesn't appear to us at LogCraft as an ideal candidate to version our detection rules as only the notion of time is conveyed, while we would need a little more to be fully satisfied.
ZeroVer
It's impossible to talk about software versioning without mentioning the leading and de facto industry standard ZeroVer, but we'll let you discover it by yourself (hint: it's a satire).
SemVer
SemVer, short for Semantic Versioning, is a versioning scheme used in software engineering to provide a clear and consistent way of assigning version numbers to software releases. It helps developers and users understand the significance of changes in different versions and manage software dependencies effectively.
SemVer follows a three-part versioning scheme: MAJOR.MINOR.PATCH, such as 1.3.5. Each part conveys specific information about the changes in the software:
- MAJOR version: This number is incremented when there are incompatible changes or significant new features that may cause existing functionality to break. It indicates that the new version introduces changes that may require modifications in the code using the software.
- MINOR version: This number is incremented when new features are added in a backward-compatible manner. It signifies that the new version includes additional functionality but does not break existing functionality.
- PATCH version: This number is incremented when backward-compatible bug fixes or patches are applied. It represents that the new version includes fixes for issues without introducing new features or breaking existing functionality.
By adhering to SemVer, developers can communicate the nature of changes in their software effectively, making it easier for users and other developers to understand the impact of a version update.
SemVer's essential aspect lies in its focus on evaluating software changes from the perspective of the user. It prioritizes understanding how changes will impact those who utilize the application or the library.
How to version detection rules?
At LogCraft, we adopted SemVer.
INFO
SemVer is debated in the software community because it is impossible for a developper to fully understand how a change is going to impact its users, but this problem doesn't exist for Detection Engineering.
As we eluded in the introduction example, a detection, even if it's called a "detection rule" or a "correlation rule", is more than "a rule" as it is the combination of a search query, parameters and a name.
Let's shift our focus from a Security Analyst point of view.
First, if we change the search query, we are changing the heart of the detection. This could radically change what is detected, how it is detected, and if bugs are introduced, prevent Security Operations from detecting the supposed threat. This kind of change is a major change from a Security Analyst point of view because we may change the nature of the detection itself.
Second, if we change the parameters of a detection rule, for example changing cron_schedule to run more frequently, then we are not changing what is detected, but more when it is detected. This change may have consequences such as more or less alerts and thus is still "concerning" from a Security Analyst point of view, but that's clearly less important than changing the search query itself. Hence, that's a minor change.
Finally, if we change the name of a detection rule, well, it has a new name, but it is not going to change what is detected and how it is detected. That's a cosmetic change, or, a patch change.
With such a scheme in place, it is possible to understand what changed between 2 versions of the same detection without even knowing its content. For example, the difference between v1.2.0 and v2.0.0 is a change in the search query. Similarly, the difference between v3.3.0 and v3.3.1, it's just a renaming of the detection rule. Pretty efficient isn't it?
LogCraft
LogCraft complements your Splunk servers to act as a smart detection repository with automated versioning and changelog management. This unlocks advanced capabilities such as code review & diff, greater traceability, precision and confidence. Contact us for a demo!
This is an imaginary malware name at the moment of writing this article. History will tell us how long this stays imaginary! You may also read it in reverse to discover its true nature 😎 ↩︎