Hi everyone,
Recently, I have developed a tool that can check Suricata rules for common issues. Most specifically, it asserts whether many of the suggestions proposed in this Suricata Style Guide are followed.
During the development of the tool and while testing it during the engineering and evaluation of some Suricata rules, I realized some issues were present in rules that the tool previously did not detect because the Style Guide did not remark on these issues.
- For postprocessing of Suricata alerts, it is beneficial to be able to automatically detect the target of an attack, which is possible using the
target keyword, which in my opinion should always be set. Of course some heuristics based on the rule header and flow keyword can be derived, but these quickly get complicated and may not always be reliable.
- During the analysis of security events, we find that metadata describing the age of a rule is an important relevance indicator. Therefore, we believe the
created_at and updated_at metadata fields should always be set.
- Classtype is hugely beneficial to the interpretation of alerts in a similar way and whilst it is discussed in the Style Guide, the guide does not prescribe it should be set unlike some other metadata fields.
- Moreover, we found that the usage of
xbits: set (but also ) and threshold results in unexpected behavior. Although it is documented in the Suricata documentation, we find this easy to overlook. Therefore, we believe these options should never be used in conjunction.
If you want to learn more about the Suricata rule issues I described above, please take a look at how we assert their presence here.
Hi everyone,
Recently, I have developed a tool that can check Suricata rules for common issues. Most specifically, it asserts whether many of the suggestions proposed in this Suricata Style Guide are followed.
During the development of the tool and while testing it during the engineering and evaluation of some Suricata rules, I realized some issues were present in rules that the tool previously did not detect because the Style Guide did not remark on these issues.
targetkeyword, which in my opinion should always be set. Of course some heuristics based on the rule header andflowkeyword can be derived, but these quickly get complicated and may not always be reliable.created_atandupdated_atmetadata fields should always be set.xbits: set(but also ) andthresholdresults in unexpected behavior. Although it is documented in the Suricata documentation, we find this easy to overlook. Therefore, we believe these options should never be used in conjunction.If you want to learn more about the Suricata rule issues I described above, please take a look at how we assert their presence here.