Re: [IDMEF][Issue 10] Severity scale too narrow

 > On Sun, 11 Jan 2004, David A. Curry wrote:
 >
 >
 >>I am way skeptical of any scheme that purports to assign numerical
 >>values to this type of data and claim that they are "accurate" in any
 >>meaningful way.
 >>
 >>As I recall, the group was similarly skeptical when the idea was
 >>proposed in the past (and it was proposed more than once).

I think in similar terms. I'd like to propose an enumerated, textual 
list, and let people assign whatever internal numerical values they 
want. Maybe this "numerical" value could be provided for as an option, 
but the enumerated string would be mandatory.


Greg Shipley wrote:
 > If it's a done deal, it's a done deal, and please view my ramblings as
 > nothing more than comments from the peanut gallery.  (and please 
excuse me
 > and my monkey wrench!) I just know from EXPERIENCE that simple
 > classification metrics (e.g. 5 ratings) are not going to cut it in many
 > real world scenarios.  For example, when we were doing our SIM testing
 > last year in conjunction with Syracuse University we had days when we hit
 > 2600 events PER SECOND from our IDS/FW sensors.  Without some ability to
 > classify/rank those events more granularly you can forget about ever
 > really sifting through the data, much less acting on it.

First of all, it's an open discussion, so any input is valid.

In fact, I have a completely opposite feeling apout integer values. What 
I want in an alert is
1) do I have to do something about it
	and if 1)==TRUE
2) how much time do I have to comply with my business objectives.

Using integer values is akin to setting a threshold, and this depends on 
organizations. That's why I like the enumerated list, and people then 
set their own sensitivity to it.

Matthew F. Caldwell wrote:
> 	I agree using an integer to describe the level of severity is a
> necessity. Our SIM/SEM solution already reassign the priority into
> numeric form in the aggreagation phase. It could be made better for
> everyone if assignment was already in the logging format. For example:
> HIGH = 255 , MEDIUM = 128 LOW = 64. It is faster and more efficient to
> use an integer format in correlation primarily because string
> comparisons are costly CPU wise. When you compute/correlate/classify
> 3000/eps any CPU cycles you can spare increases the effectiveness of the
> SIM/SEM solution and or analysts running queries on databases.  

I remember the old CSIDS sensor doing that. We just never got around to 
using something else than the 1-5 scale. As much as I understand how 
this is important for the reasoning of your engine, I'm not sure that 
this is information that will be transported as is by IDMEF messages.

I'm still mulling this one around, and am not up for a definite proposal.

Hervé
-- 
Hervé Debar             <mailto:[email protected]>
Tel: +33 (0)2 31 75 92 61            GSM: +33 (0)6 74 09 09 66
France Télécom R&D                   Fax: +33 (0)2 31 75 93 13
42 rue des Coutures  (--)  BP 6243  (--)  F-14066 Caen Cedex 4