mailing list archives
Re: [Emerging-Sigs] New Proposed Classification.config file setup
From: "Gregory W. MacPherson" <greg () netpublishing com>
Date: Mon, 27 Dec 2010 10:28:08 -0800
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
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
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.
Emerging-sigs mailing list
Emerging-sigs () emergingthreats net
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
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
Snort-devel mailing list
Snort-devel () lists sourceforge net
Re: [Emerging-Sigs] New Proposed Classification.config file setup Frank Knobbe (Dec 27)