[Oisf-devel] Rule usage issues

[David Wharton]

At SuriCon this year there was a talk [1] that covered "Better Enhanced 
Teleological and Taxonomic Embedded Rules Schema" (BETTER) [2], a schema 
and standard for embedding metadata in Suricata Rules.  It includes a 
"priority" key with finite values "high", "medium", "low", "info", and 
"research" [3].

I know Secureworks [4] has an "enhanced" BETTER Suricata ruleset where 
the BETTER standard has been applied comprehensively and consistently on 
all rules, including having the "priority" metadata key set on every 
rule.  I am not aware of other ruleset vendors who have adopted the 
BETTER standard yet.

Taking a quick look with Aristotle [5] at the latest Emerging Threats 
ruleset, I see less than 27% of the rules with the "signature_severity" 
metadata keyword:



If Emerging Threats is your ruleset provider, I would encourage you to 
encourage them to adopt the BETTER standard for their rules and apply it 
consistently and comprehensively to their ruleset.

-David Wharton

   1. https://youtu.be/6zhwohKQZos 
https://suricon.net/wp-content/uploads/2019/11/SURICON2019_Suricata-Rule-Taxonomy_-A-Modest-Teleological-Approach.pdf
   2. https://better-schema.readthedocs.io/
   3. 
https://better-schema.readthedocs.io/en/latest/appendices.html#appendixb
   4. I am a Secureworks employee; my personal views are mine alone and 
do not reflect Secureworks’ views or represent an official company position.
   5. https://github.com/secureworks/aristotle/

On 1/30/20 2:14 PM, Francis Trudeau wrote:
> The 'signature_severity' stuff is part of the metadata, which is free
> form, but most of the time it's a key value pair:
>
> https://suricata.readthedocs.io/en/latest/rules/meta.html#metadata
>
> So signature_severity isn't an official keyword but rather extra
> information that Emerging Threats (who made the rules you are looking
> at) added to help classify the rule.  The reason other rules might not
> have that is because they were made before the metadata was added by
> default by them.
>
> On Wed, Jan 29, 2020 at 11:17 PM Star <huzhenming36 at gmail.com> wrote:
>> Happy new year, thanks for reply
>> I have another question
>> How many severity levels does this rule define?
>> Some rules have severity and some do not. Is this not a uniform standard?
>>
>>                                                                                                       Thank You
>>
>> Andreas Herz <aherz at oisf.net> 于2020年1月21日周二 上午3:50写道：
>>> On 19/01/20 at 17:36, Star wrote:
>>>>        What does the signature_severity Major in the suricata default rule
>>>> mean?
>>> That is just a classification of the severity by the rule writer.
>>> This is on a lot of rules so depends mainly on the context.
>>>
>>> --
>>> Andreas Herz
>>> _______________________________________________
>>> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
>>> Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
>>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>>> Redmine: https://redmine.openinfosecfoundation.org/
>>>
>> _______________________________________________
>> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>> Redmine: https://redmine.openinfosecfoundation.org/
>>
> _______________________________________________
> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
> Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> Redmine: https://redmine.openinfosecfoundation.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20200130/85428ad6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olfdkhfdnodjdaod.png
Type: image/png
Size: 123651 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20200130/85428ad6/attachment-0001.png>