[Snort-sigs] [Emerging-Sigs] [Snort-devel] New Proposed Classification.config file setup
mcholste at ...2420...
Mon Dec 27 11:41:03 EST 2010
On Mon, Dec 27, 2010 at 9:48 AM, Martin Roesch <roesch at ...435...> 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...
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.
More information about the Snort-sigs