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