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