Re: [IDMEF][Issue 8] Classification and ident

Krzysztof Zaraska <[email protected]> Thu, 8 Jan 2004 15:06:49 +0100 (CET)
Newsgroups gmane.ietf.idwg
Message-ID <[email protected]>
On Thu, 8 Jan 2004, Herve Debar wrote:

>  From Krzysztof Zaraska:
> Also, we would propose introducing the "id" field here, containing a
> unique identifier for the vulnerability in given database, as we can 
> see that "name" field is being rather used as a description, and, as 
> such, doesn't have to be unique. Having the "id" field, the 
> construction of the relevant URL is trivial (some combination of 
> database's base URL and the identifier).
> 
> Hervé:
> If I'm correct in what you suggest, the name field could still be your 
> ID, particularly if it is made unique like issue 1 suggests. or are 
> you thinking of an "ident" pointer like there is for analyzer ?

The "ident" pointer. 

A relevant comment from Yoann Vandoorselaere on issue #1:

| 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.

As you can see, only by looking up "SNMP public access udp" we cannot
determine whether we're dealing with CAN-1999-0517 or CAN-2002-0013. 

Inclusion of unique ids/idents solves this problem. 

If the names were made unique, this could work, but would require doing
extra lookups to determine (e.g.) CVE identifier from the name. Unless
it's said that the name field should contain the identifier; but then it
would stop being human readable (after all, "SNMP public access udp" is
more informative at the first sight than CAN-2002-0013: when I see "SNMP"
in the description field, I know I can simply ignore the alert if the
device in question has no SNMP agent). 

> BTW, your argument can be reversed: it is as easy to do ID->URL as 
> URL->ID. The URL is just bigger.

Not really. 

ID->URL convertion is a matter of simple string concatenation, while
URL->ID requires parsing (and possibly decoding escaped sequences, which 
can be specific to a particular HTTP implementation). 

Plus, the URLs which only point to the main page of the vulnerability
database site are permitted, what defeats the idea of performing URL->ID
convertion.

// Krzysztof Zaraska * kzaraska (at) student.uci.agh.edu.pl
// http://mops.uci.agh.edu.pl/~kzaraska/ * http://www.prelude-ids.org/
// A dream will always triumph over reality, once it is given the chance.
//		-- Stanislaw Lem