Re: [Emerging-Sigs] New Proposed Classification.config file setup

[Martin Roesch <roesch () sourcefire com>]

Yeah, I guess I didn't say it but I was recommending new keywords so
that we wouldn't break backwards compatibility.  I do favor mapping of
assigned enumeration values to strings though, I don't just want
random metadata because that can lead to a Tower of Babel situation
where people start baking up nonstandard things that break external
event processors.

Doing the metadata tag thing is fine in the near term as a "let's do
something now" solution for people who need it sooner rather than
later but I don't think adding new keywords should be all that tough
in this particular case.  Does info in the metadata fields even make
it into unified 2 output?  I'm not in a place where I can look it up
at the moment and I don't remember...

Marty


On Fri, Dec 24, 2010 at 1:28 PM, Martin Holste <mcholste () gmail com> wrote:
> This is so simple to me it is exasperating:  Continue with the new
> classification system as proposed, add on metadata: tags=<csv of tags>
> as an interim tagging solution that supports full backward
> compatibility.  Mandate that only hyphens and commas are used in tags.
>  Don't worry about what the tags are for now, just start tossing
> something reasonable in there.  That's the whole point--they are
> extremely flexible and don't affect performance or parsing for
> existing tools.  Merry Snortmas!
>
> On Thu, Dec 23, 2010 at 11:52 PM, Joel Esler <jesler () sourcefire com> wrote:
> > I don't disagree. The thought was brought up to expand the classifications into something much more granular, and 
> > technically it was possible to replace the classifications we have with this more granular classification system 
> > with very little work.
> >
> > My biggest concern would be getting not only the internal Snort parsers fixed to accept it (which I am not saying 
> > isn't possible, just not currently slated on the build documents) but then getting all the output modules and gui's 
> > to recode to the new format. I'm all for backwards comparability where it makes sense.
> >
> > However, if there is a better idea the community has in order to make areas of Snort better, I'm all for it. I've 
> > heard Marty's idea, and I've heard s couple other ideas that have made it to me off list (if those people want to 
> > share their opinions on list, that would fuel the discussion as well)
> >
> > I'm definitely not the "decider" here, and I'd like to hear the community speak. I would love to see a fully dynamic 
> > classification system based upon contextual data, but i don't know if that's possible with the current code base.
> >
> > Maybe a simple replacement of the system we have now is a solution, maybe even just a short term one. Maybe we 
> > should redesign it totally as Marty (and others) have said. I think this is an important topic to bring up, and am 
> > glad ET and group did. It brings attention to an area of Snort that has really never changed since the beginning.
> >
> > Sent from my iPad
> >
> > On Dec 24, 2010, at 12:17 AM, <Joshua.Kinard () us-cert gov> wrote:
> >
> > > Having a class & subclass mechanism would be really useful, IMHO.  It's
> > > cleaner-reading than constantly linking the two together via a hyphen
> > > and essentially repeating the class over and over again.  I can think of
> > > some saner categorization ways w/ a setup like this.
> > >
> > > --J
> > >
> > > -----Original Message-----
> > > From: Martin Roesch [mailto:roesch () sourcefire com]
> > > Sent: Thursday, December 23, 2010 10:54 PM
> > > To: Joel Esler
> > > Cc: snort-sigs () lists sourceforge net; Emerging Sigs;
> > > snort-users () lists sourceforge net; snort-devel () lists sourceforge net
> > > Subject: Re: [Snort-devel] New Proposed Classification.config file setup
> > >
> > > On Thu, Dec 23, 2010 at 5:27 PM, Joel Esler <jesler () sourcefire com>
> > > wrote:
> > > > As mentioned earlier, here's the proposed Classification.config file
> > > > setup posted and available for download here:
> > > > http://blog.snort.org/2010/12/new-proposed-classificationconfig-file.h
> > > > tml Please take a look, leave comments preferably on the blog, but
> > > > also here would be fine.
> > >
> > >
> > > It appears that there's two levels of information here, why not have a
> > > class and subclass?  For example:
> > >
> > > classification: exploit-shellcode
> > > classification: exploit-sql-injection
> > > classification: exploit-browser
> > >
> > > should maybe be
> > >
> > > category: exploit; class: shellcode;
> > > category: exploit; class: sql-injection;
> > > category: exploit; class: browser;
> > >
> > > Having the different levels of granularity could be useful for things
> > > list real-time response mechanisms that act on just the category or
> > > whatever.  Just thinking out loud here.
> > >
> > > Furthermore, maybe we should be thinking about really fixing the
> > > classification system with static value assignments for categories and
> > > classes and mappings between values and human readable strings.  I
> > > imagine this could make machine processing easier if we had output
> > > options that could generate either (more easily) machine readable or
> > > human readable data.  This would also make the runtime loading more
> > > sane, no more classification.config line order-dependent
> > > classifications.
> > >
> > > I mean, if we're going to fix it why not fix it right?
> > >
> > > Any log management/SIEM people paying attention on-list?  This is a
> > > chance to make your lives easier if you've got any input!
> > >
> > >
> > > Marty
> > >
> > >
> > > --
> > > Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
> > > Sourcefire - Security for the Real World - http://www.sourcefire.com
> > > Snort: Open Source IDP - http://www.snort.org
> > >
> > > ------------------------------------------------------------------------
> > > ------
> > > Learn how Oracle Real Application Clusters (RAC) One Node allows
> > > customers to consolidate database storage, standardize their database
> > > environment, and, should the need arise, upgrade to a full multi-node
> > > Oracle RAC database without downtime or disruption
> > > http://p.sf.net/sfu/oracle-sfdevnl
> > > _______________________________________________
> > > Snort-devel mailing list
> > > Snort-devel () lists sourceforge net
> > > https://lists.sourceforge.net/lists/listinfo/snort-devel
> > _______________________________________________
> > Emerging-sigs mailing list
> > Emerging-sigs () emergingthreats net
> > http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> >
> > Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> > The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!



-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel