Subject: Re: IDMEF Last Call

From: "Glenn Mansfield Keeni" <[email-masked]>
Date: Mon, 3 Dec 2001 00:32:53 +0900

Dave,

I apologize for looking at this document at this late hour - (has the last
callI expired ?). In the following there are some issues that I feel need
to considered/checked. They are likely to come up some time somewhere.
Some of these have may have been discussed earlier.

0. Some of the references point to expired documents (e.g. ref 3).
1. Section 3.1 could do with some more pruning.
2. sec 4.4.7 NTP timestamps. the definitions is not very clear.
    textual representation of two 32-bit numbers separated by a '.'.
    That is what we want - right ?
3. I am alarmed to see that Alert-ID is optional. I feel this encourages
    sensors to break mamagers.
4. Sec 5.2.4 figure 5.7 -  The AdditionalData class appears twice
5. Sec 5.2.4.1 The Analyzer Class
    The text says:
             The Analyzer class identifies the analyzer from which the alert
or
        heartbeat message originates.  Only one analyzer may be encoded for
        each alert or heartbeat, and that MUST be the analyzer at which the
        alert or heartbeat originated. ....

    I do not think that we are very clear about the "origination" of the
alert.
    A clarification about this would probably avoid confusion.

6. Sec 5.2.4.1 The Analyzer Class
    This class seems to be mandatory. But all the constituent elements are
    optional !

7. Sec 5.2.4.2 The Classification class
     The text says
           The Classification class provides the "name" of an alert, or
other
           information allowing the manager to determine what it is (for
           example, to decide whether or not to display the alert on-screen,
           what color to display it in, etc.).
      The example does not seems very appropriate.

8.  Sec 5.2.4.2 The Classification class
      The text says:
          url
              Exactly one.  STRING.  A URL at which the manager (or the
human
             operator of the manager) can find additional information about
the
             alert.  The URL may include an in-depth description of the
attack,
             appropriate countermeasures, or other information deemed
relevant
             by the vendor.

     The "URL may include" may be confusing.
9. Sec 5.2.4.4 The Target Class
     The text says:
         Node
              Zero or one.  Information about the host or device that is
              receiving the events (network address, network name, etc.).
      Sensors (network sensors) will probably never know if the target IS
      "receiving".
       Same probably applies to "Source". class.
10. Sec 5.2.4.6 The AdditionalData Class
      The Type attribute seems to be irrelevant. Or, have I missed
something?
11. Sec 5.2.6 The Assessment Classes
      Is it OK to have "textual descriptions of  impact" ? This raises the
      basic issue -
                 is the IDMEF meant to facilitate mechanical interpretation
of alerts ?
                 is the IDMEF meant to facilitate mechanical parsing of
alerts
                                  (e.g. for display purposes)
                 is the IDMEF meant for none of above ? Or, some of both of
above
     This relates to similar format descriptions for Action class too
12. Sec. 5.2.7.1 The Node class
      I do not understand the purpose of the category. What will be criteria
      for filling this item? A name may belong to multiple domains
       in hosts file, dns and nis. A clarification may be helpful.
13. Sec 5.2.7.1.1. The Address Class
      I do not understand all the ranks in the category. Are all these
required.
      e.g. rank 7, 8 , 9 , 10?
      Do we require the domain name representation of an address ? That is
      not present ?
14. Sec. 5.2.7.4.2 The SNMPService Class
      The significance and purpose of this class is not clear. This is
better
      dropped.

Finally thanks for the good work. Keep it up.

Cheers

Glenn

----- Original Message -----
From: "Mike Erlinger" <[email-masked]>
To: "intrusion detection wg" <[email-masked]>
Cc: "Mike Erlinger" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "stuart staniford"
<[email-masked]>
Sent: Saturday, November 17, 2001 2:35 AM
Subject: IDMEF Last Call

> This message is to notify the IDWG that we are starting a Working
> Group Last Call for IDMEF.  The latest IDMEF ID is attached and has
> been forwarded to the Internet Drafts repository.  The current draft
> incorporates the changes agreed to at various IDWG meetings and
> presented and discussed on the IDWG mailing list.  The IDMEF Last
> Call will end 2 December 2001.
>
> Thanks for everyone's effort, especially Dave and Cindy.
>
> mike & stuart
>
>
> --
> 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-621-8465
>

---

From: "David A. Curry" <[email-masked]>
Date: Mon, 03 Dec 2001 09:24:14 -0500

>>>>> On Mon, 3 Dec 2001, Glenn Mansfield Keeni, identified as "Glenn"
>>>>> below, wrote:

  Glenn> 0. Some of the references point to expired documents (e.g. ref 3).

The references are to the most recent versions of the documents, although yes,
those have expired.  There's not much that can be done about that other than
to keep resubmitting them every six months.

I believe there was a plan to move the requirements document (and maybe the
SMI/XML document, I forget) to "informational" RFC status when we submit all
this stuff.  I don't recall the details or know the status of this, however.

  Glenn> 1. Section 3.1 could do with some more pruning.

This section has not changed in quite some time.  Is there something specific
you want to cut?

  Glenn> 2. sec 4.4.7 NTP timestamps. the definitions is not very clear.
  Glenn> textual representation of two 32-bit numbers separated by a '.'.
  Glenn> That is what we want - right ?

No, two hexadecimal representations (not "textual," that's too vague).  I
think the sentence that's there is pretty clear on this.

But if you have alternate wording to propose...?

  Glenn> 3. I am alarmed to see that Alert-ID is optional. I feel this encourages
  Glenn> sensors to break mamagers.

Alert-ID is not optional.  It will always appear in an alert; it may have the
value of zero (the default).  We have always permitted the value of zero for
analyzers that cannot generate unique ids.

The rules on whether or not Alert-ID must be provided have not changed.  The
only rules that have changed are the uniqueness rules; the current rules as
reflected in the document were decided upon at the March, 2000 IDWG meeting.

  Glenn> 4. Sec 5.2.4 figure 5.7 -  The AdditionalData class appears twice

Fixed.

  Glenn> 5. Sec 5.2.4.1 The Analyzer Class
  Glenn> The text says: The Analyzer class identifies the analyzer from which
  Glenn> the alert or heartbeat message originates.  Only one analyzer may be
  Glenn> encoded for each alert or heartbeat, and that MUST be the analyzer at
  Glenn> which the alert or heartbeat originated. ....

  Glenn> I do not think that we are very clear about the "origination" of the
  Glenn> alert. A clarification about this would probably avoid confusion.

I think the sentence that follows the two you quoted above clarifies what we
mean pretty well (i.e., we don't let you record "relay" analyzers along the
way).

But if you have a clarification you like better than you want to propose...?

  Glenn> 6. Sec 5.2.4.1 The Analyzer Class
  Glenn> This class seems to be mandatory. But all the constituent elements are
  Glenn> optional !

No, the analyzerid attribute is not optional.

  Glenn> 7. Sec 5.2.4.2 The Classification class
  Glenn> The text says The Classification class provides the "name" of an alert,
  Glenn> or other information allowing the manager to determine what it is (for
  Glenn> example, to decide whether or not to display the alert on-screen,
  Glenn> what color to display it in, etc.).

  Glenn> The example does not seems very appropriate.

If you have a better example to propose...

  Glenn> 8.  Sec 5.2.4.2 The Classification class
  Glenn> The text says: url  Exactly one.  STRING.  A URL at which the manager
  Glenn> (or the human operator of the manager) can find additional information
  Glenn> about the alert.  The URL may include an in-depth description of the
  Glenn> attack, appropriate countermeasures, or other information deemed
  Glenn> relevant by the vendor.

  Glenn> The "URL may include" may be confusing.

Changed "URL" to "the document pointed to by the URL"

  Glenn> 9. Sec 5.2.4.4 The Target Class
  Glenn> The text says: Node  Zero or one.  Information about the host or device
  Glenn> that is receiving the events (network address, network name, etc.).
  Glenn> Sensors (network sensors) will probably never know if the target IS
  Glenn> "receiving".

Changed to "...at which the event(s) is being directed."

  Glenn> Same probably applies to "Source". class.

I don't believe it does.  Source says "...is causing the event(s)."

  Glenn> 10. Sec 5.2.4.6 The AdditionalData Class
  Glenn> The Type attribute seems to be irrelevant. Or, have I missed
  Glenn> something?

Why do you believe it to be irrelevant?  It specifies the type of data that
the element contains; without knowing that, a manager (especially one that
may not know what the data is, but wants to show it to the user or some
such behavior) cannot do anything meaningful with the data.

  Glenn> 11. Sec 5.2.6 The Assessment Classes
  Glenn> Is it OK to have "textual descriptions of  impact" ? This raises the
  Glenn> basic issue -

Unless you have an all-encompassing pleases-everybody set of attributes that
we can use instead...

This has been a topic at more than one IDWG meeting; I don't believe it was
ever resolved.  The current approach is to have some broad categories, but
to leave the details to free-form text.  This way, at least the information
gets up to the manager, even if we can't solve the standard format problem
now.

  Glenn> is the IDMEF meant to facilitate mechanical interpretation
  Glenn> of alerts ?
  Glenn> is the IDMEF meant to facilitate mechanical parsing of
  Glenn> alerts
  Glenn> (e.g. for display purposes)
  Glenn> is the IDMEF meant for none of above ? Or, some of both of
  Glenn> above
  Glenn> This relates to similar format descriptions for Action class too

According to the requirements document:

  IDMEF is planned to be a standard format which automated Intrusion Detection
  Systems (IDS) can use for reporting what they have deemed to be suspicious
  or of interest.

So the answers to your questions would be No, No, and None of the above.

  Glenn> 12. Sec. 5.2.7.1 The Node class
  Glenn> I do not understand the purpose of the category. What will be criteria
  Glenn> for filling this item? A name may belong to multiple domains
  Glenn> in hosts file, dns and nis. A clarification may be helpful.

The category specifies where the analyzer got the name from; it doesn't matter
if it could have gotten it from more than one place.  I changed the first part
of the description to read "the 'domain' from which the name information was
obtained".

  Glenn> 13. Sec 5.2.7.1.1. The Address Class
  Glenn> I do not understand all the ranks in the category. Are all these
  Glenn> required. e.g. rank 7, 8 , 9 , 10?

Addresses are used to represent hosts and users, that's why there's the kind
of odd mix.  And it was decided some time ago (two or three IDWG meetings ago)
that networks needed to be represented too.

Why would you remove all four of the IPv4 notations?  IPv6 has not taken over
the world yet.

  Glenn> Do we require the domain name representation of an address ? That is
  Glenn> not present ?

Do you mean PTR records?  Or something else?

  Glenn> 14. Sec. 5.2.7.4.2 The SNMPService Class
  Glenn> The significance and purpose of this class is not clear. This is
  Glenn> better dropped.

I have no objection, but I think the group needs to decide this, as it has
been in the draft since "Day 1."

--Dave

---

From: Andy Walther <[email-masked]>
Date: Mon, 3 Dec 2001 08:36:28 -0800 (PST)

> But if you have a clarification you like better than you want to propose...?

I agree. I think the text as written is clear.

>   Glenn> The example does not seems very appropriate.

I'd tend to agree with Glen here a bit. The purpose of the sentence in
question is to get the point across that the class tells the Manager how
to logically interpret and categorize the alert message and thus assumes
that such ability is desired, but then the parenthesized "for example"
speculates on the reasons a manager might wish to categorize. I see
Glenn's point that the example doesn't completely match the point. Do we
ened an example? Can we take it out? If not, maybe change it to something
like "for example, to relay specific alert information and references from
the analyzer to the manager"

> So the answers to your questions would be No, No, and None of the above.

Yeah. Glenn, maybe check out the conversations on the list from about 3
weeks ago. This result is one that everyone finally decided we could live
with, especially in regards to the comments Dave metnioned about the
requirements doc. I for one can't think of another representation I could
agree with. But if you have a specific suggestion...

> been in the draft since "Day 1."

Who's out there that wants this? If we drop SNMPService, does that
indicate anything about dropping the WebService tag (or whatever its now
called)?

Andy

---

From: Cynthia McLain <[email-masked]>
Date: Mon, 03 Dec 2001 14:23:22 -0500

Hi Glenn,

In general I agree with David and Andy. Just wanted
to make a couple more points...

>      This relates to similar format descriptions for Action class too

	As Dave and Andy indicated, there has been substantial
	discussion of this topic on the list and there has been
	difficulty getting consensus on a fixed list of values
	to be used. Part of the problem is that it is not possible
	to determine all of the possible alerts/actions that may be
	generated in the future. In the absence of a perfect and
	complete list of values, general categories with the specific
	details left to free-form text seemed like a reasonable
	alternative. The general categories, given by attributes,
	can be used for automated processing; the free-form text
	can be used for providing the necessary flexibility. While
	there may still be some adjustments that are desirable, for
	example to attribute values, the current scheme provides a
	combination of structure and flexibility that should be
	amenable to both analyzers and managers.

>       The significance and purpose of this class is not clear. This is
	Is there a reason that there are extensions to Service for
	WebService and SNMPService but not other types of services?
	Having argued for the re-instatement of action and confidence,
	I'm tending towards the cautious when it comes to dropping
	elements.

Thanks,
--Cindy