Subject: Re: Status

From: Krzysztof Zaraska <[email-masked]>
Date: Tue, 6 Jan 2004 13:55:18 +0100 (CET)

On Mon, 5 Jan 2004, Herve Debar wrote:

> Hi Mike and all

Hi,

> First of all, all the best for 2004.

The same to all of you,
 
> I'm still around and interested as well.

And I'd like to express the interest on behalf of the Prelude IDS
developers. Deployed Prelude installations use IDMEF in production
environment. 

> ---------------------------------------------------------------
> Issue 1: add encoding information to additional data.
> 
> The current tag for introducing additionaldata is the following:
> <additionaldata type=[fixed list] meaning=[free text]>
> 
> I propose to specify a non-mandatory list for meaning, as a 
> best-current-practice, to help convergence on the description of 
> additional data. I would include "packet-dump" in the list.
> I would also add an encoding=[free-text] tag, describing the actual 
> encoding of the information. I would also propose a BCP list of 
> values, including "hex", "base64", "UTF-8", "unicode".

Agreed. This is absolutely necessary. 

> <Protocol ip_version=[number] iana_number=[number] iana_name=[free 
> text] >some text</Protocol>
> 
> That way we would have any IP protocol represented.

The problem is that we are usually dealing with a protocol stack.
Therefore, what about the layer 2 information for example? Ethernet
addresses can go into into Source/Target, but what about, say, VPI/VCI
fields in ATM, or any other connection identifier? [This is not an
academic problem, as some people are trying to combine Prelude with
logging all traffic at the session level for later inspection and would
appreciate some form of connection identifier within the alert.]

> ---------------------------------------------------------------
> Issue 4: classification
> 
> The cve, bugtraq and vendor-specific for "origin" is a bit too 
> reductive. 

We second that. Free-form string?

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

Having said that, I am not sure what is the use of "url" field anyhow, as
it's unclear whether it's the main database URL or a
vulnerability-specific URL, and vulnerability-specific URLs could be
generated trivially from the "id" field.

> ---------------------------------------------------------------
> Issue 5: alert routing
> 
> I'm getting questions (actually I'm into a flamewar :-) related to 
> alert routing, 

Hm? If this was the flamewar we participated in, then I remember it has
ended long time ago without reaching agreement. :-)

> and I'm wondering if the draft shouldn't be more 
> explicit on hte hierarchy between manager and analyzer (actually, this 
> may also impact the requirements document, but the question I had was 
> on IDMEF.
> 
> Situation 1 (serial/transfer)
> -----------
> 
> Imagine 3 boxes, A=analyzer, B=manager/analyzer, C=manager, connected 
> thus:
> 
> Analyzer-A -> (Manager-B / Analyzer-B) -> Manager-C
> 
> You should ([even must ?] not have alerts on C whose analyzerid is 
> Analyzer-A.

I'd like to know a rationale for this. In Prelude it's a typical situation
that C sees alerts generated by A. And it's therefore very useful to know
where the alert actually originated. 

We were also proposing is a "path record" inside the alert, specifying the
managers the alert has travelled through. 

> There are probably others, this is what I have on my plate for the 
> moment. I haven't made any changes to the draft yet.

Not earlier than yesterday we've had these issues on prelude-devel
mailing list, raised by someone trying to express events originating from 
a honeypot in IDMEF:

- severity scale (3 grades only) is too narrow; for example, there is an
idea floating around of expressing the danger associated with the attack
as exp(severity*vulnerabity_level), but you can't go far this way with 3
level severity scale only

- there is a need for INFORMATIONAL messages. For example, a honeypot
traffic is by definition anomalous, however it should be treated
differently whether it's malicious or not. Maybe these could be
implemented as alert messages with severity = 0?

Another problem is that alerts are too verbose, i.e. every message sent
from sensor to the manager carries the same "Analyzer" object. In fact, it
should be enough to send such data once at the beginning of the session.
Fortunately, as we don't use XML on sensor->manager link, so we can do
that at the implementation level without breaking the draft, but the idea
could be worth considering.

I think there are also other thinks, I can look through our mailing list
archives and send you summary if you are interested. 

Best regards,
Krzysztof

// 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: "David A. Curry" <[email-masked]>
Date: Mon, 05 Jan 2004 14:58:11 -0500

I am here as well, and still interested, although pretty starved for time.

  Herve> ---------------------------------------------------------------
  Herve> Issue 1: add encoding information to additional data.

  Herve> The current tag for introducing additionaldata is the following:
  Herve> <additionaldata type=[fixed list] meaning=[free text]>

  Herve> I propose to specify a non-mandatory list for meaning, as a
  Herve> best-current-practice, to help convergence on the description of
  Herve> additional data. I would include "packet-dump" in the list.

I thought this had come up before and was rejected by the group, although I
may be misremembering things.  I don't have any strong feelings one way or
the other.

  Herve> I would also add an encoding=[free-text] tag, describing the actual
  Herve> encoding of the information. I would also propose a BCP list of
  Herve> values, including "hex", "base64", "UTF-8", "unicode".

The only concern I have with this is that it MIGHT conflict with the encoding
stuff associated with the whole IDMEF format (in which you specify an encoding
in the XML statement).  I am not up enough on encodings to know whether that
is the case or not.

  Herve> ---------------------------------------------------------------
  Herve> Issue 3: classification

  Herve> URL: in the examples, the urls are incomplete, in the sense that they
  Herve> point to the vendor web site and not to the specific vuln. Snort IDMEF
  Herve> messages include the full URL. I believe both are correct, and we
  Herve> should have instances of both in the examples.

That's fine by me... and as far as I know what has always been intended (it's
at least what *I* always intended).  The only reason specific links are not
in the examples now is laziness on my part...

  Herve> ---------------------------------------------------------------
  Herve> Issue 4: classification

  Herve> The cve, bugtraq and vendor-specific for "origin" is a bit too
  Herve> reductive. I'd like to either add more identifiers, or add a meaning
  Herve> field to allow people to put free text in there (field that would only
  Herve> be valid if origin=unknown). For example, I have a need to carry the
  Herve> following identifiers:

I'm pretty sure the list was decided on at a meeting, and people were loathe
to specify every Source Of The Day because it would always be out of date.
I would not object to some kind of free-text or alternate-source type of
functionality in...

  Herve> ---------------------------------------------------------------
  Herve> Issue 5: alert routing

  Herve> I'm getting questions (actually I'm into a flamewar :-) related to
  Herve> alert routing, and I'm wondering if the draft shouldn't be more
  Herve> explicit on hte hierarchy between manager and analyzer (actually, this
  Herve> may also impact the requirements document, but the question I had was
  Herve> on IDMEF.

  Herve> [manager/analyzer diagrams...]

  Herve> I believe that with these two constructs we cover any arrangement that
  Herve> anybody may want to make.

I think you're right.

--Dave

---

From: Herve Debar <[email-masked]>
Date: Mon, 05 Jan 2004 13:43:31 +0100

Hi Mike and all

Mike Erlinger wrote:
> Needs:
>    Author/Editor for IDMEF

I'd like to restart that again, now that my situation is more stable.

>    An active list to deal with IDMEF questions/issues.

Here is my current list of issues. As usual, they are more geared 
towards the data model.

---------------------------------------------------------------
Issue 2: duplicate information related to protocol information.

The current draft allow specification of tcp or udp as protocol only. 
This is a problem for other protocols. Moreover, the information can 
be inserted in two places, in source and destination, and there is no 
constraint ensuring that they should be the same.

I somehow think that the protocol should be something like:

I haven't yet made my mind where to attach this protocol information.
---------------------------------------------------------------

Issue 3: classification

Before we release the draft, I have had a question on the 
Classification class, that may confuse some implementers, and we may 
need to precise things either the examples or the wording of the class.

URL: in the examples, the urls are incomplete, in the sense that they 
point to the vendor web site and not to the specific vuln. Snort IDMEF 
messages include the full URL. I believe both are correct, and we 
should have instances of both in the examples.

NAME: Snort reuses the same name for all references. e.g:

<Classification origin="cve">
<name>SNMP public access udp</name>
<url>http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013</url>
</Classification>
<Classification origin="cve">
<name>SNMP public access udp</name>
<url>http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012</url>
</Classification>
<Classification origin="cve">
<name>SNMP public access udp</name>
<url>http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0517</url>
</Classification>
<Classification origin="vendor-specific">
<name>SNMP public access udp</name>
<url>http://www.snort.org/snort-db/sid.html?sid=1411</url>
</Classification>

I tend to think we should discourage that, at least for the 2 first 
lines, because the origin+name should be a primary key for the data.
---------------------------------------------------------------

The cve, bugtraq and vendor-specific for "origin" is a bit too 
reductive. I'd like to either add more identifiers, or add a meaning 
field to allow people to put free text in there (field that would only 
be valid if origin=unknown). For example, I have a need to carry the 
following identifiers:

snort id (sid)
nessus plugin id
arachnids
open-source vuln database
icat

I'm getting questions (actually I'm into a flamewar :-) related to 
alert routing, and I'm wondering if the draft shouldn't be more 
explicit on hte hierarchy between manager and analyzer (actually, this 
may also impact the requirements document, but the question I had was 
on IDMEF.

Situation 2 (parallelism/duplication)
-----------

Imagine 3 boxes, A=analyzer, B=manager, C=manager, connected thus:

              /---> Manager-B
Analyzer-A -<
              \---> Manager-C

The same alert on Manager-B and Manager C should [must ?] have the 
same analyzerid+alertid.

I believe that with these two constructs we cover any arrangement that 
anybody may want to make.

I'm not sure this has to go in the document, but it would probably 
clear some misunderstanding.

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: Mike Erlinger <[email-masked]>
Date: Sun, 4 Jan 2004 16:51:14 -0800

Hi All

In case you have not noticed IDWG has been silent for awhile.  Lots of reasons,
but still, it would be nice to finish things.  So, i am going to try to revive
the mail list and working group.  So here goes on how I see things.

Document status:
   Req doc is in the RFC editor queue
   IDXP doc is in the RFC editor queue
   Tunnel is RFC 3620
   IDMEF - the problem child.  Needs some work based on IESG comments.
   The IETF editor wants to publish the remaining 3 documents at the same time...

Mailing list:
   I moved it from Europe to a list that I have control of here at mudd.
   Hopefully, this will mean that I can avoid some of the email issues.
   The Working Group page at the IETF lists the way to get on and off the
    list.

Chair Status:
   I have not contacted Stuart recently.  His company was undergoing some issues.
   I will try to contact him this coming week and see if he is interested in
    continuing as co-chair.

   I am still around and interested.  Just got burned by too many things to do.
   I would really like to finish IDWG.
   I will be gone for 2+ weeks starting Jan 8th, but I hope to get the list going
    before I leave.

Needs:
   Author/Editor for IDMEF

IDMEF:
   The IESG had some issues with the IDMEF document.  One of them being a need
   to convert from DTD to Schema.  Some of this work was undertaken last summer
   and a reasonable document does exist, but was never posted nor finished.

   My plan is to get the latest version of IDMEF posted as an ID
   Get an author/editor
   Get the list of IESG questions/issues onto the mailing list
   Get discussion going on each of the questions/issues, reach a consensus
       on a solution via the mail list.
   Get the document out of the Working Group and back to the IESG.

comments/questions ?

mike

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    Computer Science Dept., Harvey Mudd College,
          301 E. 12th Street, Claremont, CA, 91711 
          909-621-8912,   FAX: 909-607-8364