Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody?

[Nigel Houghton <nhoughton () sourcefire com>]

On Mon, 21 Mar 2011 12:26:58 -0400, Joel Esler wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Nigel Houghton 
> <nhoughton () sourcefire com> wrote:
> > On Mon, 21 Mar 2011 12:10:17 -0400, Joel Esler wrote:
> > > That makes sense.  That's basically Marty's #2 point.  I'd say the
> > > porn.rules files can be re-sid'ed (referencing Jason's problem) as
> > > VRT has dropped those completely, as well as other improved rules can
> > > be re-sid.
> >
> > Like I said earlier, there is no need to re-SID these rules. We won't
> > be re-using any of the SIDs from those rules. Any changes to them can
> > be better tracked by incrementing the rev number on them and leaving
> > the SIDs themselves well alone.
>
> Okay, but that's the porn rules, what about the rest? 

Changes to other GPL rules should be handled in a similar manner. Keep 
the SID bump the rev. We will always modify a rule if there is a change 
needed. Reasons for the change could be:

 1. Improvement in detection functionality provided by new 
functionality in Snort. In this instance, the rule will be modified for 
that new version of Snort. Rules for older versions remain untouched 
and just like it is right now, the rules are shipped on a per-Snort 
version basis (so the rules still work for a particular version of 
Snort). This means that rules for older versions do not get a revision 
bump.

 2. False positive/negative content match change or addition of content 
match to improve detection. In this instance the rule gets modified for 
all currently supported versions of Snort and the rev for each rule is 
bumped. For folks who are running non-supported versions, this 
modification should be done by whoever wants to maintain the rules for 
those older sets and the rev bumped accordingly. Since rules for 
specific versions of Snort should be shipped in separate packages, this 
should not impose a problem.

 3. A reference change or addition. Much like #2, the rev gets bumped 
for all versions of the rule for all versions of Snort.

Any reported instances of false positive/negative cases should be 
reported to the VRT in the usual manner. Suggestions for improvement 
are certainly welcomed and will be handled appropriately. i.e. consider 
it a case that fits into #2.

If a user makes changes to a rule for their particular environment, the 
rule should be converted to a local rule and given a local SID. Then 
the user can disable the original rule and make changes as appropriate 
should the original rule be changed for some reason. This does of 
course mean that the user should implement a tracking mechanism for 
their local rules and the original rules they are based off.

I do not see a case for copying rules and re-numbering for distribution 
to the general populace. This just makes the job of managing rules 
needlessly more complex for the end user. FWIW, we are more than 
capable of incorporating changes to rules and re-distributing them in a 
very short space of time if the need arises (as in, we can do this in a 
matter of minutes if no QA, other than running the rule over test pcaps 
for that vulnerability is required or full regression testing is not 
needed). However, we are not inclined to issue rule changes at the drop 
of a hat and then have to re-issue the rules shortly thereafter because 
the change either did not work or introduced a false positive/negative 
case. If anyone has suggested rule changes, our advice is to test your 
change thoroughly in your environment first (i.e. go the local SID 
route) to see if anything untoward or unexpected occurs.

--
Nigel Houghton
Head Mentalist
SF VRT Department of Intelligence Excellence
http://vrt-blog.snort.org/ && http://labs.snort.org/

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users