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

["Gregory W. MacPherson" <greg () netpublishing com>]

Yes, this suggestion makes sense. When I used to be employed by a large
multinational telecommunications company that does their SEIM
development in Belgium, the team that worked on the SEIM was
overwhelmed primarily by the lack of forethought in defining
classifications in such a manner as this. Parsing and logging solutions
for new devices were all handled as custom one-offs because no working
standard was available. 

Because everyone already has their implementations, what breakdown works 
best - not for adoption, but for ease of conversion? This suggestion - 
an atomic breakdown - makes more sense programatically - join() costs 
fewer cycles than split(index()). While metadata is nice, I prefer to
make my decisions with logic in my code. KISS - my .02

G

On or about 2010.12.27 10:41:03 +0000, Martin Holste (mcholste () gmail com) said:

> On Mon, Dec 27, 2010 at 9:48 AM, Martin Roesch <roesch () sourcefire com> wrote:
> > 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.
>
> Yes, as a logging/SIEM guy (I'm active on the Syslog-NG list as well),
> I am very much in favor of using integers wherever possible.  There's
> certainly no reason long-term not to implement a sid-msg.map-like
> lookup for tag intval-to-string.  That, of course, also mandates some
> standardization for the tags being used, which obviously a good thing.
>
> > 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
>
> I'm really pushing for tagging because there will be such an immediate
> benefit to getting something simple going.  Being able to just
> reliably grep something like "zeus" and "check-in" from the alerts
> will make such an impact for communicating to NOC staff which events
> are important enough to alert the SIRT in the middle of the night.  I
> value my sleep, gentlemen!
>
> The tag values won't need to be included in unified2 output in the
> same way that sig names are not included.  It's up to the app to do
> the lookup to resolve ints to strings.
> _______________________________________________
> 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!

-- 
Gregory W. MacPherson
Global Network Exploitation Specialist, CISSP, Security+, ITIL
http://www.netpublishing.com/greg/

Government is like fire - a handy servant, but a dangerous master.
                                                     - George Washington

------------------------------------------------------------------------------
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