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

From: Herve Debar <[email-masked]>
Date: Fri, 09 Jan 2004 10:16:43 +0100

Krzysztof Zaraska wrote:

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

Proposal:

move from
       1..n
Alert------Classification

to
       1..n            0..n
Alert-------Message--------Classification

Message has 2 fields
- ident (reference)
- meaning (whatever one wants to put there)

And classification is reserved for documentation.

Rationale:
This is closer to the current state of the art, where people associate 
a unique message with their alerts and add classification as 
documentation, either their own or publicly available others. This is 
also symetric with analyzer.

Comments ?

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

---

From: Krzysztof Zaraska <[email-masked]>
Date: Thu, 8 Jan 2004 15:06:49 +0100 (CET)

The "ident" pointer. 

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

---

From: Herve Debar <[email-masked]>
Date: Thu, 08 Jan 2004 21:35:21 +0100

From Krzysztof Zaraska:

Hervé:

Hervé

---

From: Krzysztof Zaraska <[email-masked]>
Date: Sun, 11 Jan 2004 00:28:47 +0100 (CET)

> And classification is reserved for documentation.

I mostly agree, however:

1. Isn't "message" confusing with the root object?

2. What's the rationale for using > 1 Classification/documentation fields
per vulnerbility id?

---

From: Herve Debar <[email-masked]>
Date: Sun, 11 Jan 2004 14:11:19 +0100

> 1. Isn't "message" confusing with the root object?
Possibly. I didn't want to use signature, though.
> 2. What's the rationale for using > 1 Classification/documentation fields
Multiple CVE, BID, ... ?

Hervé

---

From: "David A. Curry" <[email-masked]>
Date: Sun, 11 Jan 2004 20:52:27 -0500

>>>>> On Thu, 8 Jan 2004, Herve Debar, identified as "Herve" below, wrote:

  Herve> From Krzysztof Zaraska:  Also, we would propose introducing the "id"
  Herve> field here, containing a unique identifier for the vulnerability in
  Herve> given database, as we can see that "name" field is being rather used
  Herve> as a description, and, as such, doesn't have to be unique. Having the
  Herve> "id" field, the construction of the relevant URL is trivial (some
  Herve> combination of database's base URL and the identifier).

I would prefer not to make the assumption that a URL could be generated from
an ID.  By doing so, you're assuming that vulnerability databases and their
URLs are built in a certain way, which is not an assumption that should be
built into IDMEF.  Because as soon as you do it, someone's gonna break it.

If the goal is that the analyzer, in the end, should have a URL to go to, then
a URL is what should be sent.  If the goal is to have an ID at the end (which
may or may not be convertible to a URL), then an ID should be sent.  But let's
not have IDMEF dictating how one can be built from the other.

--Dave

---

From: Krzysztof Zaraska <[email-masked]>
Date: Mon, 12 Jan 2004 16:34:20 +0100 (CET)

> built into IDMEF.  Because as soon as you do it, someone's gonna break it.

Agreed. 

To clarify, the core of my argument is: neither classification.name nor
classification.url can be relied on to specify the vulnerability
accurately, hence the proposal of the "id" field.

---

From: Herve Debar <[email-masked]>
Date: Tue, 13 Jan 2004 01:21:31 +0100

Here is my proposal for advancing the discussion on classification. 
This is not a formal text change in the draft, but sort of a midway 
point for general agreement.

Model:

+-------+ 1..n  +--------------+ 0..n  +----------------+ 0..1+----+
| Alert |<>-----|Classification|<>-----| Reference      |<>---|URL |
+-------+       +--------------+       +----------------+     +----+
                 | STRING ident |       | STRING origin  |
		| STRING name  |       | STRING meaning |
		|              |       | STRING name    |
                 +--------------+       +----------------+

Description
- Classification is the only mandatory piece of information, 
indicating what the alert is about. It provides an identification 
(pointer to previously transmitted information) and a name. The name 
must be filled in and non-blank if identification is not filled.
- Reference is there for documentation purposes, to provide additional 
information and naming about the Classification.
- Providing an URL for the reference is mandatory.

Rationale:
This structure is closer to the state of the art. It allows passing 
classification information by reference, like source and destination, 
which is useful for avoiding overload.

Problems:
- What to do if there are different "reference" sets for the same 
Classification.name ?
- do we provide a namespace for origin, that allows us to get rid of 
meaning ?

Comments ?

Hervé