-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion. #114
Comments
Hi! Thank you for the feedback! Here some answers:
You can combine multiple rules in one file with rule collections. In collection you can also define common rule parts with the action attribute set to global, which are automatically incorporated into following rules. We already used this in various rules, e.g. this one. This also solves the following problem:
Factually, the original intention of collection was this problem.
I don't know exactly what you mean here. The rule should work fine.
The problem with the proposed NOT syntax in the value definitions is the missing separation of condition and values, which has some advantages:
The example you named could be solved by:
Even if the filters would be separated in multiple definitions, the condition could be written in the following way: |
Hi! Thank you for help.
But I don't want my filters to be applied to ALL selections of the rule. If I have, say, 10 selections and 10 filters, which are independent from each other, I should place:
So, in a nutshell, all that it does is moving 'condition' on top of the rule. How is that helpful? And the strings about logsources are still duplicated, why wouldn't we use just one simple line in lieu of 3? The logsource filed is to be parsed and inserted into SIEM search all the same..
I agree here, but I just said that it is preferable for viewers to attach "NOT' right to the filed_name than condition (which can be in every part of the rule, as you showed me, so one should locate it first and scroll back every time one look the rule futher through) |
and also, if I use Filter section I have to describe the logsource fields again. Every time. It costs me 3 lines. If I'd have 10 selections and 10 filters I'd waste 60(!) lines for copy-pasting. If we switch to my way - there will be just 10 selections with filters in them and there will be only 10 lines about logsource. |
Ah, I understand! Yes, that is really some work to type in, but on the other side it precisely describes the logic and we keep the separation between values and the logic expression. I think about a possible shortcut for such constructs inside of the condition. Some kind of loop could be a solution. On the other side we try to keep Sigma as simple as possible (also for developers of tools) and especially don't add solutions for issues that appear only for a minority of rules.
Not only, the log source definition is inherited by the rules following the global definition.
The matching of the Logsource field in the rule is not intended and necessary. For this purpose, log source definitions should be used. With log source definitions you can define indices and conditions in a separate environment-specific configuration file. This is necessary to be able to write Sigma rules independent from SIEM-specific circumstances. Indeed, different rules from different log sources have to be written in separate Sigma rules inside a collection. But this is only minor additional type work with usage of global definitions.
In the public rule repository the definition name prefix filter is used to indicate filtering (example). This is quite obvious, at least after the reader has seen the condition and works with existing constructs without adding further complexity to the language. |
From my point of view that adds some difficulties aswell - the parsing tool has to be taught the logic about handling such global directives - how fields should be inherited, when it might be overwritten etc. It has to know about all theese global features and be able to adapt to appended ones, cause the more we use sigma the more features we might be in need with later.
What if my condition, unlike the one you mentioned, isn't described as a "looped function", what if it has complex logic with no repeat. So the reader would be forced to look at that condition again and again, because it is tricky to remember by heart. |
Definitely! This was an extension vs redundancy decision. Without this mechanism many rules would have to be duplicated. So we added it, despite of the increased complexity.
So, we have currently 198 rule files in this repository, only two of them have such lenghty search/filter condition. This is a minority. Furthermore, I have talked with few Sigma users in the recent time and no one mentioned such issues. I think I will ask explicitely for this in the next time. If this is a systematical problem an extension would make sense. By the way, we recently removed some kind of similar feature (not null values) for exactly the same reasons. Allowing not operators in values would add some further issues that have to be considered:
|
During the usage of sigma-language I got stuck describing cases when there is "NOT" and ("TRUE" and "TRUE") logic. I thought of suggested way of handling them as more like a workaround so I tried to add more readability to it. Also, the rules which are "united" by the common attack technique, but devided by different logsources of events, are tricky to combine into one rule. So, the main downsides of current realisation, as I see it, are:
Here's the example which describes abusing bitstransfer technique:
Presumably, the engineer who'd be analysing it shouldn't experience inconvenience - the rule is brief and readable. I don't see why we should devide it into pieces given the fact that each part is telling the same thing. Regarding the discomfort with current "not" in the condition filed:
Here's when the problem pops up - I don't know how to describe the last line in the selection1 yet. Of course, we already can solve it in directive "condition", but what if we have a dozen selections, then my "condition" would be bulky.
Can we consider some of my thoughts? The appearance of sigma-rules would be more simplistic, I believe.
The text was updated successfully, but these errors were encountered: