RFC 4765
The Intrusion Detection Message Exchange Format (IDMEF)
Pages: 157
Experimental
Experimental
Part 2 of 6 – Pages 18 to 46
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.
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 |
+-------+ +----------------+
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.
+-------------------+ | 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
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.
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.
+------------------+ | 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.
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.
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
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.
+------------------+ | 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).
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
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
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.
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.
+----------------+ | 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.
+------------------+ | 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).
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).
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).
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.
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; >
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) | +------+-------------+----------------------------------------------+
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.
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).
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; >
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 |
+------+-----------+--------------------------------+
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;
>
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;
>
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)