Subject: LAST CALL FOR COMMENTS ON CURRENT PROPOSALS

From: "David A. Curry" <[email-masked]>
Date: Fri, 09 Nov 2001 17:12:24 -0500

IF YOU HAVE ANY COMMENTS ON ANY OF THESE PROPOSALS, please submit them to
the list no later than 11:59pm Eastern Standard Time (GMT-0500) Wednesday,
November 14th, 2001.

-----

We believe that consensus (albeit without many participants in the process)
has been reached on the following:

1. (Section 5.2.6.1) The list of possible values for the "category" attribute
   of the "Node" element will be amended to include a new value:

       Rank    Keyword    Description
       ----    -------    -----------
        12     hosts      Local hosts file

2. (Section 5.2.4.1) Two optional attributes will be added to the "Analyzer"
   type to permit better identification of host-based analyzers:

   ostype
       Operating system name.  On POSIX systems, this is the value that is
       returned in utsname.sysname by the uname() system call, or the output
       of the "uname -s" command.

   osversion
       Operating system version.  On POSIX systems, this is the value that is
       returned in utsname.release by the uname() system call, or the output
       of the "uname -r" command.

3. (Section 5.2.4.4) A new "FileList" element will be added to the "Target"
   element to allow host-based intrusion detection systems to provide
   information about files:

       <!ELEMENT Target (
           Node?, User?, Process?, Service?, FileList?
         )>

4. The "FileList" element contains one or more "File" elements, each of which
   describes a file:

       <!ELEMENT FileList (
           File+
	 )>

5. The "File" element contains information about a file.  The element is
   defined as follows:

       <!ELEMENT File (
           name, path, create-time?, modify-time?, access-time?, data-size?
	   disk-size?, FileAccess*, Linkage?, Inode?
	 )>

   name
       Exactly one.  STRING.  The name of the file to which the alert applies,
       not including the path to the file.
   path
       Exactly one.  STRING.  The full path to the file, including the name.
       The path name should be represented in as "universal" a manner as
       possible, to facilitate processing of the alert.

       For Windows systems, the path should be specified using the Universal
       Naming Convention (UNC) for remote files, and using a drive letter for
       local files (e.g., "C:\boot.ini").  For UNIX systems, paths on network
       file systems should use the name of the mounted resource instead of the
       local mount point (e.g., "fileserver:/usr/local/bin/foo").  The mount
       point can be provided using the "Linkage" element.
   create-time
       Zero or one.  DATETIME.  Time the file was created.  Note that this is
       *not* the UNIX "st_ctime" file attribute (which is not file creation
       time).  The UNIX "st_ctime" attribute is contained in the "Inode"
       class.
   modify-time
       Zero or one.  DATETIME.  Time the file was last modified.
   access-time
       Zero or one.  DATETIME.  Time the file was last accessed.
   data-size
       Zero or one.  INTEGER.  The size of the data, in bytes.  Typically what
       is meant when referring to file size.  On UNIX UFS file systems, this
       value corresponds to stat.st_size.  On Windows NTFS, this value corres-
       ponds to VDL.
   disk-size
       Zero or one.  INTEGER.  The physical space on disk consumed by the
       file, in bytes.  On UNIX UFS file systems, this value corresponds to
       512 * stat.st_blocks.  On Windows NTFS, this value corresponds to EOF.
   FileAccess
       Zero or more.  Access permissions on the file.
   Linkage
       Zero or more.  File system objects to which this file is linked (other
       references for the file).
   Inode
       Zero or one.  Inode information for this file (relevant to UNIX).

   The "File" element has three attributes:

   ident
       Optional.  A unique identifier for this file, see Section 4.4.9.	
   category
       Required.  The context for the information being provided.

       Rank    Keyword    Description
       ----    -------    -----------
         0     original   The file information is from before the reported
	 		  change
         1     current    The file information is from after the reported
	 		  change

   fstype
       Required.  The type of file system the file resides on.  The name
       should be specified using a standard abbreviation, e.g., "ufs", "nfs",
       "afs", "ntfs", "fat16", "fat32", "pcfs", "joliet", "cdfs", etc.  This
       attribute governs how path names and other attributes are interpreted.

6. The "FileAccess" element represents the access permissions on the file.
   The representation is intended to be useful across operating systems.

       <!ELEMENT FileAccess (
           UserId, permission+
	 )>

   UserId
       Exactly one.  The user (or group) to which these permissions apply.
       The value of the "type" attribute must be "user-privs", "group-privs",
       or "other-privs" as appropriate.  Other values for "type" MUST NOT be
       used in this context.
   permission
       One or more.  STRING.  Level of access allowed.  Recommended values are
       "noAccess", "read", "write", "execute", "delete", "executeAs",
       "changePermissions", and "takeOwnership".  The "changePermissions" and
       "takeOwnership" strings represent those concepts in Windows.  On UNIX,
       the owner of the file always has "changePermissions" access, even if no
       other access is allowed for that user.  "Full Control" in Windows is
       represented by enumerating the permissions it contains.  The
       "executeAs" string representes the set-user-id and set-group-id
       features in UNIX.

7. (Section 5.2.6.2.1) The definitions of the "user-privs" and "group-privs"
   types on "UserId" will be modified, and the "other-privs" type added:

   user-privs
       Another user id the user or process has the ability to use, or a user
       id associated with a file permission.  On Unix systems, this would be
       the effective user id in a user or process context, and the owner
       permissions in a file context.  Multiple UserId elements may be used to
       specify a list of privileges.
   group-privs
       Another group is the group or process has the ability to use, or a
       group id associated with a file permission.  On Unix systems, this
       would be the effective group id in a group or process context, and the
       group permissions in a file context.  On BSD-derived UNIX systems,
       multiple UserId elements would be used to include all the group ids on
       the "group list."
   other-privs
       Not used in a user, group, or process context, only used in the file
       context.  The file permissions assigned to users who do not match
       either the user or group permissions on the file.  On UNIX systems,
       this would be the "world" permissions.

8. The "Linkage" element represents file system connections between the file
   described in the "File" element and other objects in the file system.  For
   example, if the "File" is a symbolic link or shortcut, then the "Linkage"
   element should contain the name of the object the link points to.  Further
   information can be provided about the object in the "Linkage" element can
   be provided with another "File" element, if appropriate.

       <!ELEMENT Linkage (
           (name, path) | File
	 )>

   The "Linkage" element has one attribute:

   category
	Required.

	Rank	Keyword		Description
	----	-------		-----------
	  0	hard-link	The "name" class represents another name for
				this file.  This information may be more
				easily obtained on NTFS than on other file
				sytems.
	  1	symbolic-link	The "name" class represents the file to which
				this file points.
	  2	mount-point	Alias for the directory specified as part of
				the "path" and "name" combination.
	  3	reparse-point	Applies only to Windows; excludes symbolic links
				and mount points, which are specific types of
				reparse points.
	  4	shortcut	File represented by the Windows "shortcut."  A
				shortcut is distinguished from a symbolic link
				because of the difference in their contents,
				which may be important to the manager.
	  5	stream		Alternate Data Stream (ADS) in Windows, fork
				on MacOS.  Separate file system entity that
				is considered an extension of the main "File".

9. The "Inode" element represents the UNIX inode information.

	<!ELEMENT Inode (
            change-time?, (number, major-device, minor-device)?,
	    (c-major-device, c-minor-device)?
	  )>

   change-time
       Zero or one.  DATETIME.  The time of the last inode change, given by
       the st_ctime element of "struct stat".
   number
       Zero or one.  INTEGER.  The inode number.
   major-device
       Zero or one.  INTEGER.  The major device number of the device the file
       resides on.
   minor-device
       Zero or one.  INTEGER.  The minor device number of the device the file
       resides on.
   c-major-device
       Zero or one.  INTEGER.  The major device of the file itself, if it is a
       character special device.
   c-minor-device
       Zero or one.  INTEGER.  The minor device of the file itself, if it is a
       character special device.

10. (Section 5.2.2) A new "Assessment" element will be added to the "Alert"
    element to allow analyzers to express information about impact, action,
    and confidence:

       <!ELEMENT Alert (
           Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source*,
	   Target*, Classification+, Assessment?, (ToolAlert |
	   OverflowAlert | CorrelationAlert)?, AdditionalData*
	 )>

11. (Section 5.2.2) The "impact" attribute will be removed from the "Alert"
    element and replaced by the "Impact" element under "Assessment" (see
    below).

12. The "Assessment" element contains elements for describing event impact,
    analyzer action, and analyzer confidence:

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

13. The "Impact" element is used to describe the analyzer's assessment of the
    impact of the event:

       <!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 element itself may be empty, or
    may contain a text description of the impact, if the analyzer is able
    to provide additional details.

    Impact types are:

    admin
        Administrative privileges were attempted or obtained.
    user
        User privileges were attempted or attained.
    dos
        A denial of service was attempted or completed.
    recon
        A reconnaissance probe was attempted or completed.
    file
        An action on a file was attempted or completed.
    other
        Some other action was attempted or completed (details should be
	included as text).

14. The "Action" element is used to describe any actions taken by the analyzer
    in response to the event:

       <!ENTITY % attvals.actcat  "
           ( block-installed | notification-sent | taken-offline | other )
         ">

       <!ELEMENT Action (#PCDATA | EMPTY)>
       <!ATTLIST Action
           category   %attvals.actcat;           'other'

    The element itself may be empty, or may contain a text description of the
    action, if the analyzer is able to provide additional details.

    Action categories are:

    block-installed
       A block of some sort was installed to prevent an attack from reaching
       its destination. The block could be a port block, address block, etc.
       or disabling a user account.
    notification-sent
       A notification message of some sort was sent out-of-band (via pager,
       e-mail, etc.).  Does not include the transmission of this alert.
    taken-offline
       A system, computer, or user was taken offline, as when the computer is
       shut down or a user is logged off.
    other
       Some other type of action was taken (details should be included as
       text).

15. The "Confidence" element represents the analyzer's best estimate of the
    validity of its analysis:

       <!ENTITY % attvals.rating  "
           ( low | medium | high | numeric )
         "> 

       <!ELEMENT Confidence (#PCDATA | EMPTY)>
       <!ATTLIST Confidence
           rating       %attvals.rating;         'numeric'

    This element 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, and may be represented as described in Section 4.4.2.

    Caution:  It should be noted that different types of analyzers may compute
      confidence values in different ways and that in many cases, confidence
      values from different analyzers should not be compared (for example, if
      the analyzers use different methods of computing or representing
      confidence, or are of different types or configurations).  Care should
      be taken when implementing systems that process confidence values (such
      as event correlators) not to make comparisons or assumptions that cannot
      be supported by the system's knowledge of the environment in which it is
      working.

-----

IF YOU HAVE ANY COMMENTS ON ANY OF THESE PROPOSALS, please submit them to
the list no later than 11:59pm Eastern Standard Time (GMT-0500) Wednesday,
November 14th, 2001.

---

From: Yuri Demchenko <[email-masked]>
Date: Tue, 13 Nov 2001 22:59:40 +0100

Hi, 

This is a response from the IODEF design group.

After having a detailed discussion, we agreed that all proposed changed
can be incorporated into the IODEF. 

It's essential to mention that mandatory IODEF requirement (RFC3067) is
a compatibility with the IDMEF.

The remaining issue that we would like to ask is the possibility to
rename "method" in WebService to the "httpmethod". This issue was
presented and discussed at the IDWG meeting at IETF50 in Minneapolis.

Requested change is not crucial but will sufficiently increase
"transparency" of applications (Incident Handling tools) using IDS for
generating initial Incident alerts/information.

I am looking forward to your response.

Regards,

Yuri

P.S. For more information about IODEF:
http://www.terena.nl/task-forces/tf-csirt/iodef/
IODEF Pre-draft Version 0.02
> http://www.terena.nl/task-forces/tf-csirt/iodef/docs/draft-terena-itdwg-iodef-xml-002.txt

-- 
-----------------------------------------------------------------------
Yuri Demchenko, TERENA, Singel 468D, 1017 AW Amsterdam, The Netherlands 
Tel: +31 20 530 4488  Fax: +31 20 530 4499  E-mail: [email-masked]
-----------------------------------------------------------------------

---

From: "David A. Curry" <[email-masked]>
Date: Wed, 14 Nov 2001 13:55:48 -0500

>>>>> On Tue, 13 Nov 2001, Yuri Demchenko, identified as "Yuri" below, wrote:

  Yuri> The remaining issue that we would like to ask is the possibility to
  Yuri> rename "method" in WebService to the "httpmethod".

Unless someone has a good reason *not* to do this, I will add this to the
list of changes.  (I think it was supposed to be done before, and I missed
it on my list of things to do.)

--Dave