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

Martin Holste mcholste at ...2499...
Thu Jan 6 16:20:16 EST 2011


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 at ...2499...> 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 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
>>
>
> ------------------------------------------------------------------------------
> 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