Severity, in general [WAS: [IDMEF][Issue 10] Severity scale too narrow]
Greg Shipley <[email protected]> Sat, 10 Jan 2004 22:09:34 -0600 (CST)
| Newsgroups | gmane.ietf.idwg |
|---|---|
| Message-ID | <[email protected]> |
I'm not sure if it's appropriate for me to comment on the severity topic as I'm clearly not working on any of the drafts / part of the working group, but on the off chance the following insight might be useful, here goes: The severity topic is a can of worms, but I believe the adoption of "SIM" solutions (Security Information Management) in operational environments is a testament to the need for more flexible classification models. Many of today's commercial SIM solutions will take in data from a security device (firewall, NIDS, etc.) and attach a weight to it based on other data points (asset rankings, vulnerability informations, etc.). Security analysts can then use that weighting to help prioritize which events they choose to investigate. In a world where it's not uncommon for a security analyst to be presented with 10k+ events in any given day, the event weighting system *must* support a granular enough system to allow effective prioritization. (Obviously three choices won't help much with prioritizing 10k events/alerts) Now, again, I'm not entirely sure that the need for weighting is relevant to the discussion at hand, but I know the limitations of syslog have also been a problem in operational security units, and I'd hate to see those mistakes duplicated again here. Taking this from another angle, if you have an alert generated from a device such as a NIDS sensor, the sensor itself might not be completely capable of determining the alert level without further data points. For example, assume that device A is a NIDS sensor, and device B is a vulnerability scanner. While each device has its own view of the world, their combined view can be far more accurate. Extending the example, if Device A detects an "IIS UNICODE" BO-based attack against system with IP address y, and Device B knows that system y is vulnerable to such an attack, the severity rating of that event may be weighted as z by a third sensor/device/aggregator. (By the same token, if Device B knows that system y is NOT vulnerable to the attack it might provide information to downgrade the weighting) Bottom line: All this to say that I don't know what the ideal solution is for severity rankings, but I am quite sure that our world will be moving away from "high, medium, and low" rankings. If anything is to be done with severity rankings, it might be worth considering using an integer. That way, at least the decision of severity could be determined by endusers, implementors, data aggregation mechanisms, etc., and not be as limited. This is what I'm seeing done "in the field" today, anyway. Hope this helps, -Greg