tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4765

 
 
 

The Intrusion Detection Message Exchange Format (IDMEF)

Part 2 of 6, p. 18 to 46
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
4.  The IDMEF Data Model and DTD

   In this section, the individual components of the IDMEF data model
   are explained in detail.  Unified Modeling Language (UML) diagrams of
   the model are provided to show how the components are related to each
   other, and relevant sections of the IDMEF DTD are presented to show
   how the model is translated into XML.

4.1.  Data Model Overview

   The relationship between the principal components of the data model
   is shown in Figure 1 (occurrence indicators and attributes are
   omitted).

   The top-level class for all IDMEF messages is IDMEF-Message; each
   type of message is a subclass of this top-level class.  There are
   presently two types of messages defined: Alerts and Heartbeats.
   Within each message, subclasses of the message class are used to
   provide the detailed information carried in the message.

   It is important to note that the data model does not specify how an
   alert should be classified or identified.  For example, a port scan
   may be identified by one analyzer as a single attack against multiple
   targets, while another analyzer might identify it as multiple attacks
   from a single source.  However, once an analyzer has determined the
   type of alert it plans to send, the data model dictates how that
   alert should be formatted.

Top      Up      ToC       Page 19 
                         IDMEF-Message
                              /_\
                               |
          +--------------------+-------------+
          |                                  |
      +-------+   +--------------+    +-----------+   +----------------+
      | Alert |<>-|   Analyzer   |    | Heartbeat |<>-|    Analyzer    |
      +-------+   +--------------+    +-----------+   +----------------+
      |       |   +--------------+    |           |   +----------------+
      |       |<>-|  CreateTime  |    |           |<>-|   CreateTime   |
      |       |   +--------------+    |           |   +----------------+
      |       |   +--------------+    |           |   +----------------+
      |       |<>-|  DetectTime  |    |           |<>-| AdditionalData |
      |       |   +--------------+    +-----------+   +----------------+
      |       |   +--------------+
      |       |<>-| AnalyzerTime |
      |       |   +--------------+
      |       |   +--------+   +----------+
      |       |<>-| Source |<>-|   Node   |
      |       |   +--------+   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-|   User   |
      |       |   |        |   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-| Process  |
      |       |   |        |   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-| Service  |
      |       |   +--------+   +----------+
      |       |   +--------+   +----------+
      |       |<>-| Target |<>-|   Node   |
      |       |   +--------+   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-|   User   |
      |       |   |        |   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-| Process  |
      |       |   |        |   +----------+
      |       |   |        |   +----------+
      |       |   |        |<>-| Service  |       +----------------+
      |       |   |        |   +----------+  +----| Classification |
      |       |   |        |   +----------+  |    +----------------+
      |       |   |        |<>-|   File   |  |    +----------------+
      |       |   +--------+   +----------+  | +--|   Assessment   |
      |       |<>----------------------------+ |  +----------------+
      |       |<>------------------------------+  +----------------+
      |       |<>---------------------------------| AdditionalData |
      +-------+                                   +----------------+

Top      Up      ToC       Page 20 
                       Figure 1: Data Model Overview

4.2.  The Message Classes

   The individual classes are described in the following sections.

4.2.1.  The IDMEF-Message Class

   All IDMEF messages are instances of the IDMEF-Message class; it is
   the top-level class of the IDMEF data model, as well as the IDMEF
   DTD.  There are currently two types (subclasses) of IDMEF-Message:
   Alert and Heartbeat.

   The IDMEF-Message class has a single attribute:

   version

      The version of the IDMEF-Message specification (this document)
      this message conforms to.  Applications specifying a value for
      this attribute MUST specify the value "1.0".

4.2.2.  The Alert Class

   Generally, every time an analyzer detects an event that it has been
   configured to look for, it sends an Alert message to its manager(s).
   Depending on the analyzer, an Alert message may correspond to a
   single detected event or multiple detected events.  Alerts occur
   asynchronously in response to outside events.

   An Alert message is composed of several aggregate classes, as shown
   in Figure 2.  The aggregate classes themselves are described in
   Section 4.2.4, Section 4.2.5, and Section 4.2.6.

Top      Up      ToC       Page 21 
              +-------------------+
              |    Alert          |
              +-------------------+            +------------------+
              | STRING messageid  |<>----------|     Analyzer     |
              |                   |            +------------------+
              |                   |            +------------------+
              |                   |<>----------|    CreateTime    |
              |                   |            +------------------+
              |                   |            +------------------+
              |                   |<>----------|  Classification  |
              |                   |            +------------------+
              |                   |       0..1 +------------------+
              |                   |<>----------|    DetectTime    |
              |                   |            +------------------+
              |                   |       0..1 +------------------+
              |                   |<>----------|   AnalyzerTime   |
              |                   |            +------------------+
              |                   |       0..* +------------------+
              |                   |<>----------|      Source      |
              |                   |            +------------------+
              |                   |       0..* +------------------+
              |                   |<>----------|      Target      |
              |                   |            +------------------+
              |                   |       0..1 +------------------+
              |                   |<>----------|    Assessment    |
              |                   |            +------------------+
              |                   |       0..* +------------------+
              |                   |<>----------|  AdditionalData  |
              |                   |            +------------------+
              +-------------------+
                     /_\
                      |
                      +----+------------+-------------+
                           |            |             |
                +-------------------+   |   +-------------------+
                |     ToolAlert     |   |   |  CorrelationAlert |
                +-------------------+   |   +-------------------+
                                        |
                              +-------------------+
                              |   OverflowAlert   |
                              +-------------------+

                         Figure 2: The Alert Class

Top      Up      ToC       Page 22 
   The aggregate classes that make up Alert are:

   Analyzer

      Exactly one.  Identification information for the analyzer that
      originated the alert.

   CreateTime

      Exactly one.  The time the alert was created.  Of the three times
      that may be provided with an Alert, this is the only one that is
      required.

   Classification

      Exactly one.  The "name" of the alert, or other information
      allowing the manager to determine what it is.

   DetectTime

      Zero or one.  The time the event(s) leading up to the alert was
      detected.  In the case of more than one event, the time the first
      event was detected.  In some circumstances, this may not be the
      same value as CreateTime.

   AnalyzerTime

      Zero or one.  The current time on the analyzer (see Section 6.3).

   Source

      Zero or more.  The source(s) of the event(s) leading up to the
      alert.

   Target

      Zero or more.  The target(s) of the event(s) leading up to the
      alert.

   Assessment

      Zero or one.  Information about the impact of the event, actions
      taken by the analyzer in response to it, and the analyzer's
      confidence in its evaluation.

Top      Up      ToC       Page 23 
   AdditionalData

      Zero or more.  Information included by the analyzer that does not
      fit into the data model.  This may be an atomic piece of data, or
      a large amount of data provided through an extension to the IDMEF
      (see Section 5).

   Alert is represented in the IDMEF DTD as follows:

   <!ELEMENT Alert                         (
       Analyzer, CreateTime, DetectTime?, AnalyzerTime?,
       Source*, Target*, Classification, Assessment?, (ToolAlert |
       OverflowAlert | CorrelationAlert)?, AdditionalData*
     )>
   <!ATTLIST Alert
       messageid           CDATA                   '0'
       %attlist.global;
     >

   The Alert class has one attribute:

   messageid

      Optional.  A unique identifier for the alert; see Section 3.2.9.

4.2.2.1.  The ToolAlert Class

   The ToolAlert class carries additional information related to the use
   of attack tools or malevolent programs such as Trojan horses and can
   be used by the analyzer when it is able to identify these tools.  It
   is intended to group one or more previously-sent alerts together, to
   say "these alerts were all the result of someone using this tool".

   The ToolAlert class is composed of three aggregate classes, as shown
   in Figure 3.

Top      Up      ToC       Page 24 
             +------------------+
             |      Alert       |
             +------------------+
                     /_\
                      |
             +------------------+
             |    ToolAlert     |
             +------------------+            +-------------------+
             |                  |<>----------|        name       |
             |                  |            +-------------------+
             |                  |       0..1 +-------------------+
             |                  |<>----------|      command      |
             |                  |            +-------------------+
             |                  |       1..* +-------------------+
             |                  |<>----------|    alertident     |
             |                  |            +-------------------+
             |                  |            | STRING analyzerid |
             |                  |            +-------------------+
             +------------------+

                       Figure 3: The ToolAlert Class

   The aggregate classes that make up ToolAlert are:

   name

      Exactly one.  STRING.  The reason for grouping the alerts
      together, for example, the name of a particular tool.

   command

      Zero or one.  STRING.  The command or operation that the tool was
      asked to perform, for example, a BackOrifice ping.

   alertident

      One or more.  STRING.  The list of alert identifiers that are
      related to this alert.  Because alert identifiers are only unique
      across the alerts sent by a single analyzer, the optional
      "analyzerid" attribute of "alertident" should be used to identify
      the analyzer that a particular alert came from.  If the
      "analyzerid" is not provided, the alert is assumed to have come
      from the same analyzer that is sending the ToolAlert.

Top      Up      ToC       Page 25 
   This is represented in the IDMEF DTD as follows:

   <!ELEMENT ToolAlert                     (
       name, command?, alertident+
     )>
   <!ATTLIST ToolAlert
       %attlist.global;
     >

4.2.2.2.  The CorrelationAlert Class

   The CorrelationAlert class carries additional information related to
   the correlation of alert information.  It is intended to group one or
   more previously-sent alerts together, to say "these alerts are all
   related".

   The CorrelationAlert class is composed of two aggregate classes, as
   shown in Figure 4.

             +------------------+
             |      Alert       |
             +------------------+
                     /_\
                      |
             +------------------+
             | CorrelationAlert |
             +------------------+            +-------------------+
             |                  |<>----------|        name       |
             |                  |            +-------------------+
             |                  |       1..* +-------------------+
             |                  |<>----------|    alertident     |
             |                  |            +-------------------+
             |                  |            | STRING analyzerid |
             |                  |            +-------------------+
             +------------------+

                   Figure 4: The CorrelationAlert Class

   The aggregate classes that make up CorrelationAlert are:

   name

      Exactly one.  STRING.  The reason for grouping the alerts
      together, for example, a particular correlation method.

Top      Up      ToC       Page 26 
   alertident

      One or more.  STRING.  The list of alert identifiers that are
      related to this alert.  Because alert identifiers are only unique
      across the alerts sent by a single analyzer, the optional
      "analyzerid" attribute of "alertident" should be used to identify
      the analyzer that a particular alert came from.  If the
      "analyzerid" is not provided, the alert is assumed to have come
      from the same analyzer that is sending the CorrelationAlert.

   This is represented in the IDMEF DTD as follows.

   <!ELEMENT CorrelationAlert              (
       name, alertident+
     )>
   <!ATTLIST CorrelationAlert
       %attlist.global;
     >

4.2.2.3.  The OverflowAlert Class

   The OverflowAlert carries additional information related to buffer
   overflow attacks.  It is intended to enable an analyzer to provide
   the details of the overflow attack itself.

   The OverflowAlert class is composed of three aggregate classes, as
   shown in Figure 5.

                  +------------------+
                  |      Alert       |
                  +------------------+
                          /_\
                           |
                  +------------------+
                  |  OverflowAlert   |
                  +------------------+            +---------+
                  |                  |<>----------| program |
                  |                  |            +---------+
                  |                  |       0..1 +---------+
                  |                  |<>----------| size    |
                  |                  |            +---------+
                  |                  |       0..1 +---------+
                  |                  |<>----------| buffer  |
                  |                  |            +---------+
                  +------------------+

                     Figure 5: The OverflowAlert Class

Top      Up      ToC       Page 27 
   The aggregate classes that make up OverflowAlert are:

   program

      Exactly one.  STRING.  The program that the overflow attack
      attempted to run (NOTE: this is not the program that was
      attacked).

   size

      Zero or one.  INTEGER.  The size, in bytes, of the overflow (i.e.,
      the number of bytes the attacker sent).

   buffer

      Zero or one.  BYTE[].  Some or all of the overflow data itself
      (dependent on how much the analyzer can capture).

   This is represented in the IDMEF DTD as follows:

   <!ELEMENT OverflowAlert                 (
       program, size?, buffer?
     )>
   <!ATTLIST OverflowAlert
       %attlist.global;
     >

4.2.3.  The Heartbeat Class

   Analyzers use Heartbeat messages to indicate their current status to
   managers.  Heartbeats are intended to be sent in a regular period,
   say, every ten minutes or every hour.  The receipt of a Heartbeat
   message from an analyzer indicates to the manager that the analyzer
   is up and running; lack of a Heartbeat message (or more likely, lack
   of some number of consecutive Heartbeat messages) indicates that the
   analyzer or its network connection has failed.

   All managers MUST support the receipt of Heartbeat messages; however,
   the use of these messages by analyzers is OPTIONAL.  Developers of
   manager software SHOULD permit the software to be configured on a
   per-analyzer basis to use/not use Heartbeat messages.

   A Heartbeat message is composed of several aggregate classes, as
   shown in Figure 6.  The aggregate classes themselves are described in
   Sections 4.2.4 and 4.2.5.

Top      Up      ToC       Page 28 
               +------------------+
               |    Heartbeat     |
               +------------------+            +------------------+
               | STRING messageid |<>----------|     Analyzer     |
               |                  |            +------------------+
               |                  |            +------------------+
               |                  |<>----------|    CreateTime    |
               |                  |            +------------------+
               |                  |       0..1 +------------------+
               |                  |<>----------| HeartbeatInterval|
               |                  |            +------------------+
               |                  |       0..1 +------------------+
               |                  |<>----------|   AnalyzerTime   |
               |                  |            +------------------+
               |                  |       0..* +------------------+
               |                  |<>----------|  AdditionalData  |
               |                  |            +------------------+
               +------------------+

                       Figure 6: The Heartbeat Class

   The aggregate classes that make up Heartbeat are:

   Analyzer

      Exactly one.  Identification information for the analyzer that
      originated the heartbeat.

   CreateTime

      Exactly one.  The time the heartbeat was created.

   HeartbeatInterval

      Zero or one.  The interval in seconds at which heartbeats are
      generated.

   AnalyzerTime

      Zero or one.  The current time on the analyzer (see Section 6.3).

   AdditionalData

      Zero or more.  Information included by the analyzer that does not
      fit into the data model.  This may be an atomic piece of data or a
      large amount of data provided through an extension to the IDMEF
      (see Section 5).

Top      Up      ToC       Page 29 
   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Heartbeat                     (
       Analyzer, CreateTime, HeartbeatInterval?, AnalyzerTime?,
       AdditionalData*
     )>
   <!ATTLIST Heartbeat
       messageid           CDATA                   '0'
       %attlist.global;
     >

   The Heartbeat class has one attribute:

   messageid

      Optional.  A unique identifier for the heartbeat; see
      Section 3.2.9.

4.2.4.  The Core Classes

   The core classes -- Analyzer, Source, Target, Classification, and
   AdditionalData -- are the main parts of Alerts and Heartbeats, as
   shown in Figure 7.

                +-----------+                +----------------+
                | Heartbeat |        +-------|    Analyzer    |
                +-----------+        |       +----------------+
                |           |<>---+--+
                +-----------+     |  |  0..* +----------------+
                                  |  +-------| AdditionalData |
                                  |          +----------------+
                +-----------+     |
                |   Alert   |     |     0..* +----------------+
                +-----------+     |  +-------|     Source     |
                |           |<>---+  |       +----------------+
                |           |        |  0..* +----------------+
                |           |        +-------|     Target     |
                |           |        |       +----------------+
                |           |<>------+
                +-----------+        |       +----------------+
                                     +-------| Classification |
                                             +----------------+

                        Figure 7: The Core Classes

Top      Up      ToC       Page 30 
4.2.4.1.  The Analyzer Class

   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.  Although the IDMEF data model does
   not prevent the use of hierarchical intrusion detection systems
   (where alerts get relayed up the tree), it does not provide any way
   to record the identity of the "relay" analyzers along the path from
   the originating analyzer to the manager that ultimately receives the
   alert.

   The Analyzer class is composed of three aggregate classes, as shown
   in Figure 8.

                +---------------------+
                |      Analyzer       |
                +---------------------+       0..1 +----------+
                | STRING analyzerid   |<>----------|  Node    |
                | STRING name         |            +----------+
                | STRING manufacturer |
                | STRING model        |       0..1 +----------+
                | STRING version      |<>----------| Process  |
                | STRING class        |            +----------+
                | STRING ostype       |       0..1 +----------+
                | STRING osversion    |<>----------| Analyzer |
                +---------------------+            +----------+

                       Figure 8: The Analyzer Class

   The aggregate classes that make up Analyzer are:

   Node

      Zero or one.  Information about the host or device on which the
      analyzer resides (network address, network name, etc.).

   Process

      Zero or one.  Information about the process in which the analyzer
      is executing.

   Analyzer

      Zero or one.  Information about the analyzer from which the
      message may have gone through.  The idea behind this mechanism is
      that when a manager receives an alert and wants to forward it to
      another analyzer, it needs to substitute the original analyzer

Top      Up      ToC       Page 31 
      information with its own.  To preserve the original analyzer
      information, it may be included in the new analyzer definition.
      This will allow analyzer path tracking.

   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Analyzer                      (
       Node?, Process?, Analyzer?
     )>
   <!ATTLIST Analyzer
       analyzerid          CDATA                   '0'
       name                CDATA                   #IMPLIED
       manufacturer        CDATA                   #IMPLIED
       model               CDATA                   #IMPLIED
       version             CDATA                   #IMPLIED
       class               CDATA                   #IMPLIED
       ostype              CDATA                   #IMPLIED
       osversion           CDATA                   #IMPLIED
       %attlist.global;
     >

   The Analyzer class has eight attributes:

   analyzerid

      Optional (but see below).  A unique identifier for the analyzer;
      see Section 3.2.9.

      This attribute is only "partially" optional.  If the analyzer
      makes use of the "ident" attributes on other classes to provide
      unique identifiers for those objects, then it MUST also provide a
      valid "analyzerid" attribute.  This requirement is dictated by the
      uniqueness requirements of the "ident" attribute (they are unique
      only within the context of a particular "analyzerid").  If the
      analyzer does not make use of the "ident" attributes, however, it
      may also omit the "analyzerid" attribute.

   name

      Optional.  An explicit name for the analyzer that may be easier to
      understand than the analyzerid.

   manufacturer

      Optional.  The manufacturer of the analyzer software and/or
      hardware.

Top      Up      ToC       Page 32 
   model

      Optional.  The model name/number of the analyzer software and/or
      hardware.

   version

      Optional.  The version number of the analyzer software and/or
      hardware.

   class

      Optional.  The class of analyzer software and/or hardware.

   ostype

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

   osversion

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

   The "manufacturer", "model", "version", and "class" attributes'
   contents are vendor-specific, but may be used together to identify
   different types of analyzers (and perhaps make determinations about
   the contents to expect in other vendor-specific fields of IDMEF
   messages).

4.2.4.2.  The Classification Class

   The Classification class provides the "name" of an alert, or other
   information allowing the manager to determine what it is.  This name
   is chosen by the alert provider.

   The Classification class is composed of one aggregate class, as shown
   in Figure 9.

Top      Up      ToC       Page 33 
                    +----------------+
                    | Classification |
                    +----------------+       0..* +-----------+
                    | STRING ident   |<>----------| Reference |
                    | STRING text    |            +-----------+
                    +----------------+

                    Figure 9: The Classification Class

   The aggregate class that makes up Classification is:

   Reference

      Zero or more.  Information about the message, pointing to external
      documentation sites, that will provide background information
      about the alert.

   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Classification                (
       Reference*
     )>
   <!ATTLIST Classification
       ident               CDATA                   '0'
       text                CDATA                   #REQUIRED
     >

   The Classification class has two attributes:

   ident

      Optional.  A unique identifier for this classification; see
      Section 3.2.9.

   text

      Required.  A vendor-provided string identifying the Alert message.

4.2.4.3.  The Source Class

   The Source class contains information about the possible source(s) of
   the event(s) that generated an alert.  An event may have more than
   one source (e.g., in a distributed denial-of-service attack).

   The Source class is composed of four aggregate classes, as shown in
   Figure 10.

Top      Up      ToC       Page 34 
                  +------------------+
                  |      Source      |
                  +------------------+       0..1 +---------+
                  | STRING ident     |<>----------|  Node   |
                  | ENUM spoofed     |            +---------+
                  | STRING interface |       0..1 +---------+
                  |                  |<>----------|  User   |
                  |                  |            +---------+
                  |                  |       0..1 +---------+
                  |                  |<>----------| Process |
                  |                  |            +---------+
                  |                  |       0..1 +---------+
                  |                  |<>----------| Service |
                  |                  |            +---------+
                  +------------------+

                        Figure 10: The Source Class

   The aggregate classes that make up Source are:

   Node

      Zero or one.  Information about the host or device that appears to
      be causing the events (network address, network name, etc.).

   User

      Zero or one.  Information about the user that appears to be
      causing the event(s).

   Process

      Zero or one.  Information about the process that appears to be
      causing the event(s).

   Service

      Zero or one.  Information about the network service involved in
      the event(s).

Top      Up      ToC       Page 35 
   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Source                        (
       Node?, User?, Process?, Service?
     )>
   <!ATTLIST Source
       ident               CDATA                   '0'
       spoofed             %attvals.yesno;         'unknown'
       interface           CDATA                   #IMPLIED
       %attlist.global;
     >

   The Source class has three attributes:

   ident

      Optional.  A unique identifier for this source; see Section 3.2.9.

   spoofed

      Optional.  An indication of whether the source is, as far as the
      analyzer can determine, a spoofed address used for hiding the real
      origin of the attack.  The permitted values for this attribute are
      shown below.  The default value is "unknown".  (See also
      Section 10.)

        +------+---------+----------------------------------------+
        | Rank | Keyword | Description                            |
        +------+---------+----------------------------------------+
        |    0 | unknown | Accuracy of source information unknown |
        |      |         |                                        |
        |    1 | yes     | Source is believed to be a decoy       |
        |      |         |                                        |
        |    2 | no      | Source is believed to be "real"        |
        +------+---------+----------------------------------------+

   interface

      Optional.  May be used by a network-based analyzer with multiple
      interfaces to indicate which interface this source was seen on.

4.2.4.4.  The Target Class

   The Target class contains information about the possible target(s) of
   the event(s) that generated an alert.  An event may have more than
   one target (e.g., in the case of a port sweep).

Top      Up      ToC       Page 36 
   The Target class is composed of four aggregate classes, as shown in
   Figure 11.

                  +------------------+
                  |      Target      |
                  +------------------+       0..1 +----------+
                  | STRING ident     |<>----------|   Node   |
                  | ENUM decoy       |            +----------+
                  | STRING interface |       0..1 +----------+
                  |                  |<>----------|   User   |
                  |                  |            +----------+
                  |                  |       0..1 +----------+
                  |                  |<>----------| Process  |
                  |                  |            +----------+
                  |                  |       0..1 +----------+
                  |                  |<>----------| Service  |
                  |                  |            +----------+
                  |                  |       0..n +----------+
                  |                  |<>----------|   File   |
                  |                  |            +----------+
                  +------------------+

                        Figure 11: The Target Class

   The aggregate classes that make up Target are:

   Node

      Zero or one.  Information about the host or device at which the
      event(s) (network address, network name, etc.) is being directed.

   User

      Zero or one.  Information about the user at which the event(s) is
      being directed.

   Process

      Zero or one.  Information about the process at which the event(s)
      is being directed.

   Service

      Zero or one.  Information about the network service involved in
      the event(s).

Top      Up      ToC       Page 37 
   File

      Optional.  Information about file(s) involved in the event(s).

   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Target                        (
       Node?, User?, Process?, Service?, File*
     )>
   <!ATTLIST Target
       ident               CDATA                   '0'
       decoy               %attvals.yesno;         'unknown'
       interface           CDATA                   #IMPLIED
       %attlist.global;
     >

   The Target class has three attributes:

   ident

      Optional.  A unique identifier for this target, see Section 3.2.9.

   decoy

      Optional.  An indication of whether the target is, as far as the
      analyzer can determine, a decoy.  The permitted values for this
      attribute are shown below.  The default value is "unknown".  (See
      also Section 10.)

        +------+---------+----------------------------------------+
        | Rank | Keyword | Description                            |
        +------+---------+----------------------------------------+
        |    0 | unknown | Accuracy of target information unknown |
        |      |         |                                        |
        |    1 | yes     | Target is believed to be a decoy       |
        |      |         |                                        |
        |    2 | no      | Target is believed to be "real"        |
        +------+---------+----------------------------------------+

   interface

      Optional.  May be used by a network-based analyzer with multiple
      interfaces to indicate which interface this target was seen on.

Top      Up      ToC       Page 38 
4.2.4.5.  The Assessment Class

   The Assessment class is used to provide the analyzer's assessment of
   an event -- its impact, actions taken in response, and confidence.

   The Assessment class is composed of three aggregate classes, as shown
   in Figure 12.

                  +------------------+
                  |   Assessment     |
                  +------------------+       0..1 +------------+
                  |                  |<>----------|   Impact   |
                  |                  |            +------------+
                  |                  |       0..* +------------+
                  |                  |<>----------|   Action   |
                  |                  |            +------------+
                  |                  |       0..1 +------------+
                  |                  |<>----------| Confidence |
                  |                  |            +------------+
                  +------------------+

                      Figure 12: The Assessment Class

   The aggregate classes that make up Assessment are:

   Impact

      Zero or one.  The analyzer's assessment of the impact of the event
      on the target(s).

   Action

      Zero or more.  The action(s) taken by the analyzer in response to
      the event.

   Confidence

      Zero or one.  A measurement of the confidence the analyzer has in
      its evaluation of the event.

   This is represented in the IDMEF DTD as follows:

   <!ELEMENT Assessment                    (
       Impact?, Action*, Confidence?
     )>
   <!ATTLIST Assessment
       %attlist.global;
     >

Top      Up      ToC       Page 39 
4.2.4.6.  The AdditionalData Class

   The AdditionalData class is used to provide information that cannot
   be represented by the data model.  AdditionalData can be used to
   provide atomic data (integers, strings, etc.) in cases where only
   small amounts of additional information need to be sent; it can also
   be used to extend the data model and the DTD to support the
   transmission of complex data (such as packet headers).  Detailed
   instructions for extending the data model and the DTD are provided in
   Section 5.

   +------+-------------+----------------------------------------------+
   | Rank | Keyword     | Description                                  |
   +------+-------------+----------------------------------------------+
   |    0 | boolean     | The element contains a boolean value, i.e.,  |
   |      |             | the strings "true" or "false"                |
   |      |             |                                              |
   |    1 | byte        | The element content is a single 8-bit byte   |
   |      |             | (see Section 3.2.4)                          |
   |      |             |                                              |
   |    2 | character   | The element content is a single character    |
   |      |             | (see Section 3.2.3)                          |
   |      |             |                                              |
   |    3 | date-time   | The element content is a date-time string    |
   |      |             | (see Section 3.2.6)                          |
   |      |             |                                              |
   |    4 | integer     | The element content is an integer (see       |
   |      |             | Section 3.2.1)                               |
   |      |             |                                              |
   |    5 | ntpstamp    | The element content is an NTP timestamp (see |
   |      |             | Section 3.2.7)                               |
   |      |             |                                              |
   |    6 | portlist    | The element content is a list of ports (see  |
   |      |             | Section 3.2.8)                               |
   |      |             |                                              |
   |    7 | real        | The element content is a real number (see    |
   |      |             | Section 3.2.2)                               |
   |      |             |                                              |
   |    8 | string      | The element content is a string (see         |
   |      |             | Section 3.2.3)                               |
   |      |             |                                              |
   |    9 | byte-string | The element is a byte[] (see Section 3.2.4)  |
   |      |             |                                              |
   |   10 | xmltext     | The element content is XML-tagged data (see  |
   |      |             | Section 5.2)                                 |
   +------+-------------+----------------------------------------------+

Top      Up      ToC       Page 40 
   The AdditionalData element is declared in the IDMEF DTD as follows:

   <!ENTITY % attvals.adtype               "
       ( boolean | byte | character | date-time | integer | ntpstamp |
         portlist | real | string | byte-string | xmltext )
     ">

   <!ELEMENT AdditionalData           (
     (boolean | byte        | character | date-time |
      integer | ntpstamp    | portlist  | real      |
      string  | byte-string | xmltext  )
    )>

   <!ATTLIST AdditionalData
       type                %attvals.adtype;        'string'
       meaning             CDATA                   #IMPLIED
       %attlist.global;
     >

   The AdditionalData class has one attribute:

   meaning

      Optional.  A string describing the meaning of the element content.
      These values will be vendor/implementation dependent; the method
      for ensuring that managers understand the strings sent by
      analyzers is outside the scope of this specification.  A list of
      acceptable meaning keywords is not within the scope of the
      document, although later versions may undertake to establish such
      a list.

Top      Up      ToC       Page 41 
4.2.5.  The Time Classes

   The data model provides three classes for representing time.  These
   classes are elements of the Alert and Heartbeat classes.

   The time classes are represented in the IDMEF DTD as follows:

   <!ELEMENT ntpstamp          (#PCDATA)         >
   <!ATTLIST ntpstamp          %attlist.global;  >

   <!ELEMENT CreateTime          (#PCDATA) >
   <!ATTLIST CreateTime
       ntpstamp            CDATA                   #REQUIRED
       %attlist.global;
     >

   <!ELEMENT DetectTime          (#PCDATA) >
   <!ATTLIST DetectTime
       ntpstamp            CDATA                   #REQUIRED
       %attlist.global;
     >

   <!ELEMENT AnalyzerTime        (#PCDATA) >
   <!ATTLIST AnalyzerTime
       ntpstamp            CDATA                   #REQUIRED
       %attlist.global;
     >

   The DATETIME format of the <CreateTime> element content is described
   in Section 3.2.6.

   If the date and time represented by the element content and the NTP
   timestamp differ (should "never" happen), the value in the NTP
   timestamp MUST be used.

4.2.5.1.  The CreateTime Class

   The CreateTime class is used to indicate the date and time the alert
   or heartbeat was created by the analyzer.

4.2.5.2.  The DetectTime Class

   The DetectTime class is used to indicate the date and time that the
   event(s) producing an alert was detected by the analyzer.  In the
   case of more than one event, it is the time that the first event was
   detected.  (This may or may not be the same time as CreateTime;
   analyzers are not required to send alerts immediately upon
   detection).

Top      Up      ToC       Page 42 
4.2.5.3.  The AnalyzerTime Class

   The AnalyzerTime class is used to indicate the current date and time
   on the analyzer.  Its values should be filled in as late as possible
   in the message transmission process, ideally immediately before
   placing the message "on the wire".

   The use of <AnalyzerTime> to perform rudimentary time synchronization
   between analyzers and managers is discussed in Section 6.3.

4.2.6.  The Assessment Classes

   The data model provides three types of "assessments" that an analyzer
   can make about an event.  These classes are aggregates of the
   Assessment class.

4.2.6.1.  The Impact Class

   The Impact class is used to provide the analyzer's assessment of the
   impact of the event on the target(s).  It is represented in the IDMEF
   DTD as follows:

   <!ENTITY % attvals.severity             "
       ( info | low | medium | high )
     ">
   <!ENTITY % attvals.completion           "
       ( failed | succeeded )
     ">
   <!ENTITY % attvals.impacttype           "
       ( admin | dos | file | recon | user | other )
     ">

   <!ELEMENT Impact              (#PCDATA) >
   <!ATTLIST Impact
       severity            %attvals.severity;      #IMPLIED
       completion          %attvals.completion;    #IMPLIED
       type                %attvals.impacttype;    'other'
       %attlist.global;
     >

Top      Up      ToC       Page 43 
   The Impact class has three attributes:

   severity

      An estimate of the relative severity of the event.  The permitted
      values are shown below.  There is no default value.  (See also
      Section 10.)

       +------+---------+-----------------------------------------+
       | Rank | Keyword | Description                             |
       +------+---------+-----------------------------------------+
       |    0 | info    | Alert represents informational activity |
       |      |         |                                         |
       |    1 | low     | Low severity                            |
       |      |         |                                         |
       |    2 | medium  | Medium severity                         |
       |      |         |                                         |
       |    3 | high    | High severity                           |
       +------+---------+-----------------------------------------+

   completion

      An indication of whether the analyzer believes the attempt that
      the event describes was successful or not.  The permitted values
      are shown below.  There is no default value.  (See also
      Section 10.)

           +------+-----------+--------------------------------+
           | Rank | Keyword   | Description                    |
           +------+-----------+--------------------------------+
           |    0 | failed    | The attempt was not successful |
           |      |           |                                |
           |    1 | succeeded | The attempt succeeded          |
           +------+-----------+--------------------------------+

Top      Up      ToC       Page 44 
   type

      The type of attempt represented by this event, in relatively broad
      categories.  The permitted values are shown below.  The default
      value is "other".  (See also Section 10.)

   +------+---------+--------------------------------------------------+
   | Rank | Keyword | Description                                      |
   +------+---------+--------------------------------------------------+
   |    0 | admin   | Administrative privileges were attempted or      |
   |      |         | obtained                                         |
   |      |         |                                                  |
   |    1 | dos     | A denial of service was attempted or completed   |
   |      |         |                                                  |
   |    2 | file    | An action on a file was attempted or completed   |
   |      |         |                                                  |
   |    3 | recon   | A reconnaissance probe was attempted or          |
   |      |         | completed                                        |
   |      |         |                                                  |
   |    4 | user    | User privileges were attempted or obtained       |
   |      |         |                                                  |
   |    5 | other   | Anything not in one of the above categories      |
   +------+---------+--------------------------------------------------+

   All three attributes are optional.  The element itself may be empty,
   or may contain a textual description of the impact, if the analyzer
   is able to provide additional details.

4.2.6.2.  The Action Class

   The Action class is used to describe any actions taken by the
   analyzer in response to the event.  Is is represented in the IDMEF
   DTD as follows:

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

   <!ELEMENT Action              (#PCDATA) >
   <!ATTLIST Action
       category            %attvals.actioncat;     'other'
       %attlist.global;
     >

Top      Up      ToC       Page 45 
   Action has one attribute:

   category

      The type of action taken.  The permitted values are shown below.
      The default value is "other".  (See also Section 10.)

   +------+-------------------+----------------------------------------+
   | Rank | Keyword           | Description                            |
   +------+-------------------+----------------------------------------+
   |    0 | 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.              |
   |      |                   |                                        |
   |    1 | 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.            |
   |      |                   |                                        |
   |    2 | taken-offline     | A system, computer, or user was taken  |
   |      |                   | offline, as when the computer is shut  |
   |      |                   | down or a user is logged off.          |
   |      |                   |                                        |
   |    3 | other             | Anything not in one of the above       |
   |      |                   | categories.                            |
   +------+-------------------+----------------------------------------+

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

4.2.6.3.  The Confidence Class

   The Confidence class is used to represent the analyzer's best
   estimate of the validity of its analysis.  It is represented in the
   IDMEF DTD as follows:

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

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

Top      Up      ToC       Page 46 
   The Confidence class has one attribute:

   rating

      The analyzer's rating of its analytical validity.  The permitted
      values are shown below.  The default value is "numeric".  (See
      also Section 10.)

   +------+---------+--------------------------------------------------+
   | Rank | Keyword | Description                                      |
   +------+---------+--------------------------------------------------+
   |    0 | low     | The analyzer has little confidence in its        |
   |      |         | validity                                         |
   |      |         |                                                  |
   |    1 | medium  | The analyzer has average confidence in its       |
   |      |         | validity                                         |
   |      |         |                                                  |
   |    2 | high    | The analyzer has high confidence in its validity |
   |      |         |                                                  |
   |    3 | numeric | The analyzer has provided a posterior            |
   |      |         | probability value indicating its confidence in   |
   |      |         | its validity                                     |
   +------+---------+--------------------------------------------------+

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

   NOTE:  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.


Next RFC Part