[Snort-sigs] FW: Signature Database

Brian Jameson brian at ...1160...
Wed Apr 28 07:06:01 EDT 2004


snort-sigs-admin at lists.sourceforge.net wrote:
> On Tue, Apr 27, 2004 at 10:00:20AM -0400, James Ashton wrote:
>> While I certainly DON'T want to detract from the sig base on
>> snort.org I must say that for me, it is always a LITTLE behind where
>> I would like it. I am hoping that by having a Sig Database that we
>> all keep current with the sigs that we write then everyone can have
>> a little more chance of catching something that they might have
>> otherwise missed. 
> 
> Quality is more important than quantity.
> 
> Simple string matches to catch a specific exploit may be useful for
> the few days after the exploit is written, but after that, people
> start writing new exploits with different shellcode.  The majority of
> the signatures contributed lately (on snort-sigs and other places)
> meet a specific need for the short term need but are lacking in the
> quality needed for long term use.
> 
> Before rules go into snort's "official" rules repository the rules
> need to be of a certain level of quality.  Short term use rules
> (simple shellcode based string match) generally do not fall into that
> category.
> 
> If you write rules for the vulnerability, not the exploit, the quality
> of the rules will go up.
> 
> Brian
> 

I would also like to throw snort management into the mix. The more the
rules are centralised the less resource is needed by the us lot out in
sticks to manage the thing. If you try to monitor several collections
of rules it becomes complicated, time consuming and error prone. What
do you do in the instance where three lists all have variations on the
same exploit? Are they all equally effective, has one collection not
allowed for a discovered false positive? Are the collections not after
all re-inventing the wheel? 'Quality not Quantity' to quote Brian
I think centralising at snort.org is the most effective way forward, 
but might call for bolting on an experimental category or some similar 
mechanism where maturing rules with their documentation go through 
multiple releases while they evolve. Once stable they can be migrated 
into their proper category in core rules.

regards
another Brian




More information about the Snort-sigs mailing list