Snort mailing list archives
Re: [Emerging-Sigs] New Proposed Classification.config file setup
From: beenph <beenph () gmail com>
Date: Wed, 5 Jan 2011 15:10:15 -0500
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
Current thread:
- Re: [Emerging-Sigs] New Proposed Classification.config file setup beenph (Jan 05)
- Re: [Snort-devel] [Emerging-Sigs] New Proposed Classification.config file setup Martin Holste (Jan 06)