Subject: [Fwd: Re: [prelude-devel] [IDMEF][Issue 1] Duplicate name in classifications (fwd)]

From: Yoann Vandoorselaere <[email-masked]>
Date: Sat, 17 Jan 2004 01:00:01 +0000

-- 
Yoann Vandoorselaere, http://www.prelude-ids.org

"Programming is a race between programmers, who try and make more and 
 more idiot-proof software, and universe, which produces more and more 
 remarkable idiots. Until now, universe leads the race"  -- R. Cook

Subject: Re: [prelude-devel] [IDMEF][Issue 1] Duplicate name in classifications (fwd)
From: Yoann Vandoorselaere <[email-masked]>
To: Krzysztof Zaraska <[email-masked]>
Cc: [email-masked], Herve Debar <[email-masked]>, intrusion detection wg <[email-masked]>
Date: Fri, 09 Jan 2004 19:22:55 +0000

On Thu, 2004-01-08 at 22:55, Yoann Vandoorselaere wrote:
> 
> Today most IDS aggregate several possible type alert behind a single
> description, as you can see Snort's doing here... 
> 
> CVE references CAN-1999-0517 and CAN-2002-0013 are quite different, but
> aggregated under the same "SNMP public access udp" name.
> 
> Now you might argues that this should be splited up into 2 differents
> Snort rules, but it might not always be possible.

BTW, url and origin attribute are required. 

Now, what's the expected policy when a sensor, say a honeypot, generate
an alert triggered by some unexpected traffic but can't categorize it ?

IMO, in this case, the honeypot should only have to fill the
classification name field...

-- 
Yoann Vandoorselaere <[email-masked]>

---

From: Herve Debar <[email-masked]>
Date: Tue, 27 Jan 2004 14:43:14 +0100

> classification name field...

Would the proposed solution (see issue 8 discussion) satisfy you. I 
think it is closer to this.

Hervé
-- 
Hervé Debar             <mailto:[email-masked]>
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