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

[Martin Holste <mcholste () gmail com>]

> 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