Subject: Comment's on Cynthia McLain's proposals

From: "David A. Curry" <[email-masked]>
Date: Fri, 26 Oct 2001 10:53:14 -0400

My comments on Cynthia McLain's recent proposals.

=============================================
Comments on "Host-Based IDS" (Message 2 of 4)
=============================================

  Cynthia> A. Alert impact types:
  Cynthia> --------------------------------------------------------------------
  Cynthia> If it is not feasible to return to the use of enumerated types, due
  Cynthia> to concerns about extensibility, the potential variability in this
  Cynthia> attribute could be mitigated by recommending specific strings in the
  Cynthia> document.

Comment: The reason we changed the "impact" attribute from a list of values
  to a free-format string was that nobody was happy with the list of values
  that we had, and nobody had any brilliant ideas for how to solve this.  I
  don't think anyone is really happy with a free-format string either, but
  it seemed better to allow the flexibility than to restrict implementors
  to a lousy set of choices.

  Cynthia> B. Additional Node category type:
  Cynthia> --------------------------------------------------------------------
  Cynthia> Keyword Description
  Cynthia> ------- -----------
  Cynthia> hosts Local hosts file (Unix file system)

Comment: I would remove the "(Unix file system)" restriction here, and just
  make it a generic local hosts file (Windows does have one, although it is
  not used very often).

  Cynthia> C. Additional Analyzer categories
  Cynthia> ---------------------------------
  Cynthia> The two additional attributes are:
  Cynthia> ostype
  Cynthia>    Optional. Operating system name (e.g., Linux).
  Cynthia> osversion
  Cynthia>    Optional. Version of the operating system.

Comment: This seems fine, but I wonder if there's a way we can be more clear
  about what exactly we want.  For example, is it "Solaris 8" or "SunOS 5.8"?
  And is it "Linux" or "RedHat Linux" or "RedHat" or ...  Maybe this is just
  something we have to live with (it's easily enough addressed with aliases
  or whatever in the manager).

  Cynthia> D. Additional sub-element to Target
  Cynthia> -----------------------------------
  Cynthia> In XML the "File" element would be added to "Target" as follows:
  Cynthia>
  Cynthia> <!ELEMENT Target (
  Cynthia>     Node?, User?, Process?, File*, Service?
  Cynthia> )>

Comment: I believe this should be File? and not File* (i.e., zero or one, not
  zero or more).  The thinking for the other subclasses is that if you have
  more than one, then you have multiple targets, and repeat at the <Target>
  level, not below.   

Question: Is there a reason you chose File* instead of File? ?

  Cynthia> The "File" element consists of several sub-classes:
  Cynthia>
  Cynthia> path
  Cynthia>   [...]
  Cynthia>   If the path field is eliminated, the name information should
  Cynthia>   include the path in order to avoid ambiguity.

Comment: I disagree with this.  If you know the path, put it in <path>.  If
  you don't know it, leave <path> out.  The <name> element should never have
  the path in it.

  Cynthia> create_time
  Cynthia>    Zero or one. DATETIME as described in Section 4.4.6 of
  Cynthia>    draft-ietf-idwg-idmef-xml-04.txt. Create time of this file.

Question: Do we need to include a clarification about Unix "ctime" in this?
  (The issue being that Unix "ctime" is commonly misinterpreted as creation
  time, when really it is last inode change time.  Unix does not keep track
  of file creation times.)  I know that's not an IDMEF issue, but I keep
  having this vision of lots of misinformed developers filling that field
  in on their Unix-based IDSes...

  Cynthia> ++++ GroupId element ++++
  Cynthia> name
  Cynthia>    Zero or one. STRING. A user or group name. To represent the Unix
  Cynthia>    permissions for "other", the name "unix_other" should be used.

Question: Why do we need to rename "other" as "unix_other"?  This seems like
  an arbitrary special case that's just going to get us into trouble later
  (as people start adding other special cases).

Overall, I think this proposal is excellent, and once my issues and any raised
by others on the list are resolved, we should adopt it into the IDMEF before
we go to last call.

=====================================
Comments on "Action" (Message 3 of 4)
=====================================

  Cynthia> To provide a more structured representation of response information,
  Cynthia> it is proposed that an "Action" element be defined and added as a
  Cynthia> sub-element of "Alert" in lieu of the "action" attribute. Zero or
  Cynthia> more "Action" elements would be allowed. The description of the
  Cynthia> action could be represented as a string or as XML.

Comment: I'm okay with this, up to the last sentence.  It's not clear to me if
  XML is really needed here.  Yes, I suppose I could contrive a use for it, in
  the future, but I think strings are plenty for the moment.

Other than that, what's proposed here sounds reasonable.  Cynthia's points that
it offers more flexibility, and gives the opportunity to add attributes in the
future as experience is gained, are both well taken.  Again, I think we should
adopt this into the IDMEF before we go to last call, once any other issues have
been resolved.

=========================================
Comments on "Confidence" (Message 4 of 4)
=========================================

  Cynthia> The confidence attribute was removed from the Alert data model due
  Cynthia> to concerns within the IDWG over the ability to assign a meaningful
  Cynthia> value to this field.

Comment: I think the problem was a little more complex than that.  The issue
  was no so much whether or not a meaningful value could be assigned to this
  attribute by a single IDS.  Rather, the issue was what happens when you get
  these values from different IDSes back at the manager -- are they comparable
  in any meaningful way?

  For example, if IDS-A says 0.7 and IDS-B says 0.8, does that mean B is more
  certain than A?  Not necessarily, depending on how the number was calculated.
  This becomes a real problem if both IDSes are reporting on the same event.
  Say, for example, that a network-based IDS reports an event with confidence
  0.8, and a host-based IDS reports the same event with a 0.2.  Does that mean
  the network-based IDS is pretty sure it happened, and the host-based IDS is
  pretty sure it didn't?  Not necessarily, since the confidences are not
  directly comparable.  So which IDS does the manager believe?

  That's the problem we couldn't solve.  I think.

I'm not an expert on confidence calculations, and will defer to those who are
for whether or not this attribute can be kept in a useful form.  I'm inclined
not to include it in the IDMEF unless and until that can be shown.

--Dave