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

[Martin Holste <mcholste () gmail com>]

I agree that there's no reason to pass any other info than what is
essential to the event when logging.  Tags, priorities, etc., can all
be found using a lookup after the fact.  That's why in one of my
schema examples I have tags broken out as a separate table which can
be joined.

On Wed, Jan 5, 2011 at 2:10 PM, beenph <beenph () gmail com> wrote:
> This is a good timing to see discussion about this, on one side its
> great to see people wanting to categorise rules
> and future rules into families. This can be helpfull to humanly manage
> and organise things.
>
> But beside priority which can internally (snort wise) affect alerting
> capability or queueing of a rule, person X could decide to use
> nomanclature A and person Y nomanclature B, would there really be any
> differences.
>
> Those information in textual form should not be relayed in unified2
> format, (in my opinion) for  the main reason that
> they would obviously bloat the ole process of having compact
> information stored to represent alerts.
>
> I have allways seen the unicity of a event as the following.
>
> event_type identifier = gid + sid + rev
>
> Classification + Priority are overall display data.
>
> You could end up wanting to log only Priority 1 alerts for some
> reason, thus why would you load your IDS with all the other rules.
>
> Since the last email in the thread had some examples of a proposed db
> schema table, i would not see why (gid+sid+rev) wouldn't be enough
> sufficient information
> to reference a unique event identifier.
>
> This is why in my opinion that whatever is chosen as a model to
> identify textual information for UI and rule management interface
> should have no effect on unified2 and reader process.
>
> I have also seen reference to gid-msg.map and sid-msg.map.
>
> Those two file should never be considered as gold with unified2 reader
> unless their purpose is strictly "syslog" type reporting, And even
> there, you should be able to transport your information
> throught the ole process without having to add extra data to what
> should be already existing elsewhere.
>
> AKA Before deploying a new rule base, it should be done from a static
> location where  every change and update , modifies the revisions,
> where every new GID/SID/REV exist and
> where those values are not duplicated. If you choose to change [rule A
> cat 1 pri 2 rev 1] to [rule A cat 5 pri 1 rev 2]. And if you keep rule
> change history and revision history, you would be able
> to backmap category changes in time whatever the type of backend your using.
>
> So overall i think having more flexible categories are a good thing.
> Should those changes have an impact on the engine beside priority,
> i dont think so, should those info be logged to unifed2, why not,
> should the information  logged in unified2 format be in textual form,
> i dont think so.
>
>
> On a side note, Happy MMXI to snorters out there, i wish everyone good
> health and whatever comes with it.
>
> -elz
>
>
>
>
> On Tue, Dec 28, 2010 at 2:48 PM, Martin Holste <mcholste () gmail com> wrote:
> > > Unless the rule contains an existing "priority" keyword (which
> > > overrides), then the rule's priority is determined by the
> > > highest-priority label in the keyword's parameters.  Since 'ddos' is
> > > specified, the rule's overall priority is '1', overriding the lower
> > > values of the 'http' and 'botnet' priorities.
> >
> > Interesting.  I think everyone seems to be independently coming to the
> > conclusion that we need structure for the tags/labels and that they
> > can't be ad-hoc.
> >
> > Personally, I would vote to remove the priority attribute entirely.  I
> > so rarely find generic prioritization helpful that I'd just as soon
> > leave it out entirely.  Consequently, while I like the idea of more
> > tightly integrating tags/labels into the config, I don't think I'd get
> > any extra value out of having them calculate the priority.  The main
> > problem, aside from the vast differences between environments, is that
> > I really think the idea of being able to predetermine priority is
> > fundamentally flawed.  For instance, a sig that checks for generic exe
> > downloads may need a very high priority when the exe comes from
> > known-bad subnets, and the 200th zeus check-in probably should carry
> > less weight then the very first check-in, at least from an IR
> > standpoint.
> >
> > The point is that they are all situational, and I believe that it is
> > actually harmful to suggest that we can know the priority of a given
> > signature ahead of time because you risk novice analysts undervaluing
> > a given alert based on very generic guesswork, and equally bad,
> > overvaluing red herring alerts.  Furthermore, SIEM frameworks that
> > rely on these priorities are exasperating the situation through
> > "garbage in, garbage out" (props, Richard) in that their calculations
> > are based on fundamentally flawed ideas.
> >
> > It is for this very reason that I am so adamant that a tagging
> > solution be produced--and soon, because it provides concrete, factual
> > attributes that add to the analyst's immediate tactical understanding.
> >  Likewise, it provides future SIEM frameworks a solid foundation for
> > writing correlation routines.
> >
> > > Sidenote: I'd like to avoid extending "metadata" any -- internally,
> > > we've had problems with appending extraneous keywords to that parameter
> > > due to several parsing bugs in the SourceFire GUI (which are now fixed).
> > > I'd like to avoid any more of these getting created :)
> >
> > Noted, but as I've written above, I'm eager to get this moving, even
> > if it risks a few more bugs being found.  Instead of using metadata,
> > there is another way that could guarantee noninterference:  Simply
> > keep an external map file of sid-to-tags.  As in:
> >
> > 2011001 http,zeus,check-in
> > 2011002 http,exe,download
> > ...and so forth.
> >
> > Those who are able to immediately incorporate it into their tools may
> > do so, and there is no risk to upsetting any processes currently in
> > place.
> >
> > Matt, if you wanted to, you could simply keep a list of these for all
> > new sigs in sig-tags.map so that when a more finalized solution is in
> > place, it will be easy to tack on these tags.  Interested parties
> > could create another table in their snort schema:
> >
> > CREATE TABLE sig_tags (
> >  gid TINYINT UNSIGNED NOT NULL,
> >  sid INT UNSIGNED NOT NULL,
> >  tags VARCHAR(8000)
> >  PRIMARY KEY (gid, sid)
> > );
> >
> > Or, for proper 3rd normal form:
> > CREATE TABLE sig_tags (
> >  tag_id INT UNSIGNED NOT NULL PRIMARY KEY,
> >  tag VARCHAR(255)
> > ) ENGINE=InnoDB;
> > CREATE TABLE sig_tag_map (
> >  gid TINYINT UNSIGNED NOT NULL,
> >  sid INT UNSIGNED NOT NULL,
> >  tag_id INT UNSIGNED NOT NULL,
> >  PRIMARY KEY (gid, sid, tag_id),
> >  FOREIGN KEY (tag_id) REFERENCES sig_tags (tag_id) ON DELETE CASCADE
> > ON UPDATE CASCADE
> > ) ENGINE=InnoDB;
> >
> > You get the idea.  So how about it, Matt, can we start at least
> > writing down what tags we would want to assign to new signatures?
> > Once we do a few we should be able to come up with some
> > standardization.
> >
> > ------------------------------------------------------------------------------
> > 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
>
> ------------------------------------------------------------------------------
> 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

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