Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4765

The Intrusion Detection Message Exchange Format (IDMEF)

Pages: 157
Experimental
Part 2 of 6 – Pages 18 to 46
First   Prev   Next

Top   ToC   RFC4765 - Page 18   prevText

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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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   ToC   RFC4765 - 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 page on part 3)

Next Section