Subject: Re: Comment's on Cynthia McLain's proposals

From: Cynthia McLain <[email-masked]>
Date: Thu, 01 Nov 2001 12:23:40 -0500

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

Since we are trying to define a generic file description,
I agree with your assessment that create_time should really
be the file creation time. However, disallowing the use of
create_time to present file information from Unix systems
will result in the loss of some, potentially valuable,
information.

What do you think of the idea of including a create_time
element in the Inode element to supply that information?
Despite the fact that the create_time is really the inode
modification time, the use of "create_time" instead of
"modify_time" would be more consistent with Unix terminology
in that context.

--Cindy

---

From: "David A. Curry" <[email-masked]>
Date: Thu, 01 Nov 2001 13:23:12 -0500

>>>>> On Thu, 1 Nov 2001, Cynthia McLain, identified as "Cynthia" below, wrote:

  Cynthia> Since we are trying to define a generic file description, I agree
  Cynthia> with your assessment that create_time should really be the file
  Cynthia> creation time. However, disallowing the use of create_time to
  Cynthia> present file information from Unix systems will result in the loss
  Cynthia> of some, potentially valuable, information.

If you're going to call it "create time," then yes, it should be the file
creation time.  And Unix has no notion of the file creation time, so that
field is not relevant on Unix.

  Cynthia> What do you think of the idea of including a create_time element in
  Cynthia> the Inode element to supply that information?  Despite the fact that
  Cynthia> the create_time is really the inode modification time, the use of
  Cynthia> "create_time" instead of "modify_time" would be more consistent with
  Cynthia> Unix terminology in that context.

  Cynthia> --Cindy

I have no problem with including another time element in Inode to keep track
of this third time value.  But you cannot call it the "create time," because
that is *not* what it is.

The third time is the "inode change time" or "file status change time" -- it
is plainly documented as such in the Unix manuals.  Calling it "create time"
is not consistent with Unix terminology, it's just plain wrong.  It's also
misleading to anyone unfamiliar with Unix who might be trying to interpret
events from Unix systems (such as a manager console operator).

--Dave

---

From: Lansing Sloan <[email-masked]>
Date: Thu, 01 Nov 2001 10:34:51 -0800

>--Cindy

    Would it not be better to include a "change_time" element
(or perhaps call it "inode_modify_time" or call it something more
generic yet fairly accurate) rather than a "create_time" element,
at least for reporting events in UNIX systems?

    If other operating systems have a genuine creation time and
it is relevant for intrusion detection, then including a "create_time"
element seems sensible also.  (Sorry, I don't know enough about other
operating systems to say it is or isn't sensible.)  But "create_time"
just does not seem right for information from a UNIX inode.

-- Lansing Sloan

P.S. I am delighted to see the proposal and progress on
reporting file-system changes.

---

From: Cynthia McLain <[email-masked]>
Date: Thu, 01 Nov 2001 17:24:44 -0500

David> The third time is the "inode change time" or "file status change
time" -- it
David> is plainly documented as such in the Unix manuals.  Calling it
"create time"
David> is not consistent with Unix terminology, it's just plain wrong. 
It's also
David> misleading to anyone unfamiliar with Unix who might be trying to
interpret
David> events from Unix systems (such as a manager console operator).

Lansing>    Would it not be better to include a "change_time" element
Lansing> (or perhaps call it "inode_modify_time" or call it something
more
Lansing> generic yet fairly accurate) rather than a "create_time"
element,
Lansing> at least for reporting events in UNIX systems?

Since the change_time element is specific to the Unix
inode, I think that it makes more sense to put it in
the Inode element. Doing so adds some small tag overhead
for Unix but it makes it very clear what the time
represents. For example,

<File fstype="ufs">
   <name>foo</name>
   <path>/usr/bin/foo</path>
   <modify_time>0x12345678.0x87654321</modify_time>
   <access_time>0x12345678.0x87654321</access_time>
   <Inode><change_time>0x12345678.0x87654321</change_time></Inode>
</File>

create_time is a generic concept, which is supported in
Windows and is, unfortunately, not supported by Unix.

Note that "change_time" is being used, not "create_time"
or "modify_time". Note that this change motivates changing
the attributes in the Inode element to sub-elements so
they can be omitted:

<!ELEMENT Inode   (
    change_time |
    (number, major_device, minor_device, c_major_device?,
c_minor_device?) |
    (change_time,
     (number, major_device, minor_device, c_major_device?,
c_minor_device?))
 )>

Does this seem reasonable to everyone?

Thanks,
--Cindy     

-- 
------------------------------------------------------------
Cynthia D. McLain                 M.I.T. Lincoln Laboratory
Information Systems Technology    244 Wood Street
phone:  781-981-3943              Lexington, MA 02420-9108
e-mail: [email-masked]       Fax: 781-981-0186
------------------------------------------------------------

---

From: Andy Walther <[email-masked]>
Date: Thu, 1 Nov 2001 14:34:19 -0800 (PST)

That works for me. We're keeping create_time in File still, right?

Andy

---

From: Cynthia McLain <[email-masked]>
Date: Thu, 01 Nov 2001 17:39:08 -0500

> That works for me. We're keeping create_time in File still, right?

That's the plan, as I understand it. It
just wouldn't be used for Unix files (i.e.,
it isn't the ctime file attribute)

--Cindy

---

From: "David A. Curry" <[email-masked]>
Date: Fri, 02 Nov 2001 08:50:34 -0500

>>>>> On Thu, 1 Nov 2001,
>>>>> Cynthia McLain, identified as "Cynthia" below, wrote:

Putting change_time into Inode, and leaving create_time in File, makes
perfect sense (and was what I was suggesting too, if it wasn't clear).

  Cynthia> <!ELEMENT Inode   (
  Cynthia>     change_time |
  Cynthia>     (number, major_device, minor_device, c_major_device?,
  Cynthia> c_minor_device?) |
  Cynthia>     (change_time,
  Cynthia>      (number, major_device, minor_device, c_major_device?,
  Cynthia> c_minor_device?))
  Cynthia> )>

I guess the only thing I don't understand is why all the complexity here?
Why not just:

<!ELEMENT Inode (
    change_time?, (number, major_device, minor_device)?,
    (c_major_device, c_minor_device)?
  )>

[The grouping of c_major/c_minor together is not strictly necessary, but
 it makes things simpler, and since they both come from struct stat, it's
 no harder to supply both than it is to supply either.]

--Dave

---

From: Cynthia McLain <[email-masked]>
Date: Fri, 02 Nov 2001 09:06:44 -0500

David> I guess the only thing I don't understand is why all the
complexity here?
David> Why not just:

David> <!ELEMENT Inode (
David>     change_time?, (number, major_device, minor_device)?,
David>     (c_major_device, c_minor_device)?
David>   )>

The reason for the complexity was to ensure that
Inode always has some content (either a change_time,
or inode numbers, or both). Since there are no required
elements in the definition above, an empty Inode
element would be valid XML.

David> [The grouping of c_major/c_minor together is not strictly
necessary, but
David> it makes things simpler, and since they both come from struct
stat, it's
David> no harder to supply both than it is to supply either.]

I agree, they should be grouped together. But,
shouldn't they should be grouped with the other device
numbers? Does it make sense to have character device
numbers without an inode number or the primary device
numbers?

--Cindy

---

From: "David A. Curry" <[email-masked]>
Date: Fri, 02 Nov 2001 09:18:53 -0500

>>>>> On Fri, 2 Nov 2001, Cynthia McLain, identified as "Cynthia" below, wrote:

  Cynthia> The reason for the complexity was to ensure that Inode always
  Cynthia> has some content (either a change_time, or inode numbers, or
  Cynthia> both). Since there are no required elements in the definition above,
  Cynthia> an empty Inode element would be valid XML.

There are a few places in the DTD where this is possible, so I don't
think it's a big concern.  The managers should be able to deal with
it, and hey, if you wanna waste the bandwidth... :-)

  David> [The grouping of c_major/c_minor together is not strictly necessary...

  Cynthia> I agree, they should be grouped together. But, shouldn't they should
  Cynthia> be grouped with the other device numbers? Does it make sense to have
  Cynthia> character device numbers without an inode number or the primary
  Cynthia> device numbers?

I don't think so.

They should not be grouped with the other device numbers, because they are
not related.  The character major/minor identify a device to the operating
system (i.e., a device driver and an instance).  The other major/minor are
simply the block major/minor of the device on which the file (inode) is
residing (i.e., they identify the physical disk where the file lives).
The "important" part of the device is the character major/minor; where
the entry in the file system resides is not particularly meaningful (as
you can have multiple entries for the same device).

Likewise, the particular inode number of the entry in the file system for
a character special file is not particularly meaningful.

--Dave

---

From: "David A. Curry" <[email-masked]>
Date: Sun, 04 Nov 2001 08:17:35 -0500

I think Cindy's Action/Impact/Confidence proposal looks great.  My personal
preference is for "Option 2" of the Impact element (the one that breaks it
down into three attributes).

--Dave

---

From: Cynthia McLain <[email-masked]>
Date: Sun, 4 Nov 2001 08:22:42 -0500 (EST)

[My apologies if you receive this twice but I wasn't
 sure that it got out to the mailing list.]

Of the proposed changes to IDMEF, the representation of
impact and confidence values remain open.

Regarding the impact values, in the September 18, 2001
draft of IDMEF, the enumerated impact types were changed
to free-form text. Although there is agreement that alert
processing by managers is facilitated by standardized
values, there has been disagreement about what those values
should be. Two more options for representing the impact
information are proposed below; both options change impact
from an attribute to an element. Option 2 is derived from
a previous proposal by Paul Sangree.

Regarding the confidence values, the previously proposed
confidence attribute is changed to an element which uses
attributes to inform the contents. Wording for guidance
on use of the confidence element is proposed.

Finally, rather than clutter up Alert with a bunch of new
elements, an Assessment element is proposed to contain Impact,
Action, and Confidence. Alert would contain zero or one
Assessment element.

While all of the proposals below benefit from the ideas
and inputs of others, any problems with the proposals
are of my own doing. 

Your feedback is requested and encouraged.

   ++++++++++++++++++++
   ++++ Assessment ++++
   ++++++++++++++++++++

   <!ELEMENT Assessment   (
         Impact?, Action?, Confidence?
   )>

   ++++++++++++++++++++++++++++
   ++++ Impact  (Option 1) ++++
   ++++++++++++++++++++++++++++

   This option changes the current "impact" attribute into an element
   that has a modified set of the enumerated types for its optional
   attribute. Impact supports arbitrary text strings for its content.
   
   <!ENTITY  % attvals.impact    "
         ( attempted-admin | successful-admin |
           attempted-dos | successful-dos |
           attempted-recon | successful-recon |
           attempted-user | successful-user |
           file-change | other )
   ">
   <!ELEMENT Impact  (#PCDATA | EMPTY)>
   <!ATTLIST Impact
        category      %attvals.impact;        'other'

   The "category" attribute is optional and defaults to "other".
   For attempted-recon and successful-recon the recommended
   element content is "limited" or "largescale".  For file-change
   the recommended element content is "created", "read", "modified",
   or "deleted". The element is permitted to have no content.

   ++++++++++++++++++++++++++++
   ++++ Impact  (Option 2) ++++
   ++++++++++++++++++++++++++++

   This option also changes the current "impact" attribute into
   an element. In this case the single enumerated attribute is
   divided into three optional attributes. The attribute names
   are as previously proposed by Paul Sangree, the enumerations
   are derived from his proposal. As with the previous option,
   Impact supports arbitrary text strings for its content.

   <!ENTITY  % attvals.severity    "
       ( low | medium | high )
   ">
   <!ENTITY  % attvals.completion  "
       ( failed | succeeded )
   ">
   <!ENTITY  % attvals.impacttype   "
       ( admin | user | dos | recon | file | other )
   ">
   <!ELEMENT Impact  (#PCDATA | EMPTY)>
   <!ATTLIST Impact
        severity      %attvals.severity;      #IMPLIED
        completion    %attvals.completion;    #IMPLIED
        type          %attvals.impacttype     'other'

   All three attributes are optional. The "type" attribute defaults
   to "other".

                                               New values
   Previous and proposed values   severity  completion   type    content
   ----------------------------   --------  ----------   -----   -------
   unknown                        varies    varies       other
   bad-unknown                    high      succeeded    other
   not-suspicious                 low       varies       varies
   attempted-admin                varies    failed       admin
   successful-admin               varies    succeeded    admin
   attempted-dos                  varies    failed       dos
   successful-dos                 varies    succeeded    dos
   attempted-recon                varies    failed       recon
   successful-recon-limited       varies    succeeded    recon   limited
   successful-recon-largescale    varies    succeeded    recon
largescale
   attempted-user                 varies    failed       user
   successful-user                varies    succeeded    user

   file-modified                  varies    succeeded    file    modified
   file-created                   varies    succeeded    file    created
   file-deleted                   varies    succeeded    file    deleted
   file-read                      varies    succeeded    file    read

   * varies denotes any of several values, including omission of
     the attribute

   ++++++++++++++++
   ++++ Action ++++
   ++++++++++++++++

   <!ENTITY % attvals.actcat  "
       ( block-installed | notification-sent | taken-offline | other )
   ">
   <!ELEMENT Action (#PCDATA | EMPTY)>
   <!ATTLIST Action
        category   %attvals.actcat;           'other'

   Omission of element content is permitted.

   ++++++++++++++++++++
   ++++ Confidence ++++
   ++++++++++++++++++++

   <!ENTITY % attvals.rating  "
       ( low | medium | high | numeric )
   "> 
   <!ELEMENT Confidence (#PCDATA | EMPTY)>
   <!ATTLIST Confidence
         rating       %attvals.rating;         'numeric'
  
   Confidence represents the analyzer's best estimate of the
   validity of its analysis. This element is optional and should
   be used only when the analyzer can produce meaningful information.
   Systems that can output only a rough heuristic should use "low",
   "medium", or "high" as the rating value. In this case, the
   element content should be omitted.

   Systems capable of producing reasonable probability estimates
   should use "numeric" as the rating value and include a numeric
   confidence value in the element content. This numeric value
   should reflect a posterior probability (the probability that
   an attack has occurred given the data seen by the detection
   system and the model used by the system). It is a floating point
   number between 0.0 and 1.0, inclusive. The number of digits
   should be limited to those representable by a single precision
   floating point value. 

--Cindy