[Snort-users] One for the Wishlist

Joe McAlerney joey at ...155...
Fri Aug 25 16:16:31 EDT 2000


"A.L.Lambert" wrote:
> 

> > > I know this has been mentioned before, but I would like to see the ability
> > > to assign a severity level to a rule.  For example a PING-ICMP_TIME_EXCEEDED
> > > my be a severity=1 while an FTP-badlogin may be a 3 and a DDoS-shaft handler
> > > to agent may be a 5.
> >
> > Not only would a severity level be useful, but also a confidence
> > level.
> >
> > There are many rules which are known to false trigger often, so it
> > would be useful to assign those a low confidence level. Rules which
> > almost never falsely trip should be given a high confidence level.
> >
> > -Dan
> 
>         How about we collectively start just adding a simple, consistent
> text string to messages which are known to generate false positives?
> Something like 'msg: "$CURENTMSG Confidence:3"'.  That would make life
> easy on parsers, and not cause any additional work for snort itself.
> Anyone else like the idea?  Hate it?  Comments welcome.
> 
> -- A.L.Lambert
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/snort-users

Those would be very useful, but how do you classify severity and assign
it a confidence level?  Well, first you need a scale for each.  There
are a number of ones out there, but one that has been mentioned on this
list in the past for impact has been developed by the IDWG.  It is as
follows:

Value  Definition
----------------------------------------------------------------
0      The impact of the event is not known to the analyzer.
----------------------------------------------------------------
1      Event is not known to be suspicious in any way.
----------------------------------------------------------------
2      Event is believed unpleasant in an unknown way.
----------------------------------------------------------------
3      Event is believed to be an attempted reconnaissance
       probe.
----------------------------------------------------------------
4      Event is believed to be a reconnaissance probe which
       provided useful information, but of limited scope (e.g.
       a single machine was scanned for a small number of ports
       (< 10)).
----------------------------------------------------------------
5      Event is believed to be a large scale reconnaissance
       probe which provided useful information (e.g. a DNS
       sweep over a complete subnetwork).
----------------------------------------------------------------
6      event appears intended to lead to denial of service.
----------------------------------------------------------------
7      event is believed to have successfully denied service
----------------------------------------------------------------
8      event is believed to be an attempt to gain user level
       access.
----------------------------------------------------------------
9      event appears to be a successful compromise of user
       level access.
----------------------------------------------------------------
10     event is believed to be an attempt to gain administrator
       level access.
----------------------------------------------------------------
11     event appears to be a successful compromise of
       administrator level access.
----------------------------------------------------------------

Once some scale is agreed on, we need to agree on the values for each
alert.  This is probably not feasible, so it will most likely be left to
the author of the rule to decide.  

I don't see how you can statically assign a confidence value to an
alert.  That seems like something that everyone would need to do for
their own network, given each has unique properties.

-Joe M.



More information about the Snort-users mailing list