Re: Severity, in general [WAS: [IDMEF][Issue 10] Severity scale too narrow]

Dan White <[email protected]> Sun, 11 Jan 2004 10:02:37 -0500 (EST)
Newsgroups gmane.ietf.idwg
Message-ID <[email protected]>
I agree with Greg,

SIM or Security Event Management products have many rules based
approaches that assign criticality. The real measure of severity
is the susceptibility to the enterprise of the attack. I.e. 
Does the vulnerabity that would allow an attack ssignature to be succssfull
exist?

Severity that is on a 1-10 scale with user configuration to change seems to be a reasonable suggestion?

---- Greg Shipley <[email protected]> wrote:
> 
> 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
> 
>