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

beenph beenph at ...2499...
Wed Jan 5 15:10:15 EST 2011


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 at ...2499...> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>




More information about the Snort-devel mailing list