Intrusion Detection Exchange H. Debar
Format France Telecom
Internet-Draft D. Curry
Expires: September 17, 2006 Guardian
B. Feinstein
TNT
March 16, 2006
The Intrusion Detection Message Exchange Formatdraft-ietf-idwg-idmef-xml-16
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The purpose of the Intrusion Detection Message Exchange Format
(IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems,
and to the management systems which may need to interact with them.
Debar, et al. Expires September 17, 2006 [Page 1]

Internet-Draft The IDMEF March 20061. Notices and conventions Used in This Document
The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
An "IDMEF-compliant application" is a program or program component,
such as an analyzer or manager, that reads and/or writes messages in
the format specified by this memo.
An "IDMEF document" is a message that adheres to the requirements
specified by this memo, and that is exchanged by two or more IDMEF
applications. "IDMEF message" is another term for an "IDMEF
document."
Debar, et al. Expires September 17, 2006 [Page 4]

Internet-Draft The IDMEF March 20062. Introduction
The Intrusion Detection Message Exchange Format (IDMEF) [2] is
intended to be a standard data format that automated intrusion
detection systems can use to report alerts about events that they
deem suspicious. The development of this standard format will enable
interoperability among commercial, open source, and research systems,
allowing users to mix-and-match the deployment of these systems
according to their strong and weak points to obtain an optimal
implementation.
The most obvious place to implement the IDMEF is in the data channel
between an intrusion detection analyzer (or "sensor") and the manager
(or "console") to which it sends alarms. But there are other places
where the IDMEF can be useful:
o a single database system that could store the results from a
variety of intrusion detection products would make it possible for
data analysis and reporting activities to be performed on "the
whole picture" instead of just a part of it;
o an event correlation system that could accept alerts from a
variety of intrusion detection products would be capable of
performing more sophisticated cross-correlation and cross-
confirmation calculations than one that is limited to a single
product;
o a graphical user interface that could display alerts from a
variety of intrusion detection products would enable the user to
monitor all of the products from a single screen, and require him
or her to learn only one interface, instead of several; and
o a common data exchange format would make it easier for different
organizations (users, vendors, response teams, law enforcement) to
not only exchange data, but also communicate about it.
The diversity of uses for the IDMEF needs to be considered when
selecting its method of implementation.
2.1. About the IDMEF Data Model
The IDMEF data model is an object-oriented representation of the
alert data sent to intrusion detection managers by intrusion
detection analyzers.
2.1.1. Problems Addressed by the Data Model
The data model addresses several problems associated with
Debar, et al. Expires September 17, 2006 [Page 5]

Internet-Draft The IDMEF March 2006
representing intrusion detection alert data:
o Alert information is inherently heterogeneous. Some alerts are
defined with very little information, such as origin, destination,
name, and time of the event. Other alerts provide much more
information, such as ports or services, processes, user
information, and so on. The data model that represents this
information must be flexible to accommodate different needs.
An object-oriented model is naturally extensible via aggregation
and subclassing. If an implementation of the data model extends
it with new classes, either by aggregation or subclassing, an
implementation that does not understand these extensions will
still be able to understand the subset of information that is
defined by the data model. Subclassing and aggregation provide
extensibility while preserving the consistency of the model.
o Inrusion detection environments are different. Some analyzers
detect attacks by analyzing network traffic; others use operating
system logs or application audit trail information. Alerts for
the same attack, sent by analyzers with different information
sources, will not contain the same information.
The data model defines support classes that accommodate the
differences in data sources among analyzers. In particular, the
notion of source and target for the alert are represented by the
combination of Node, Process, Service, and User classes.
o Analyzer capabilities are different. Depending on the
environment, one may install a lightweight analyzer that provides
little information in its alerts, or a more complex analyzer that
will have a greater impact on the running system but provide more
detailed alert information. The data model must allow for
conversion to formats used by tools other than intrusion detection
analyzers, for the purpose of further processing the alert
information.
The data model defines extensions to the basic DTD that allow
carrying both simple and complex alerts. Extensions are
accomplished through subclassing or association of new classes.
o Operating environments are different. Depending on the kind of
network or operating system used, attacks will be observed and
reported with different characteristics. The data model should
accommodate these differences.
Significant flexibility in reporting is provided by the Node and
Service support classes. If additional information must be
Debar, et al. Expires September 17, 2006 [Page 6]

Internet-Draft The IDMEF March 2006
reported, subclasses may be defined that extend the data model
with additional attributes.
o Commercial vendor objectives are different. For various reasons,
vendors may wish to deliver more or less information about certain
types of attacks.
The object-oriented approach allows this flexibility while the
subclassing rules preserve the integrity of the model.
2.1.2. Data Model Design Goals
The data model was designed to provide a standard representation of
alerts in an unambiguous fashion, and to permit the relationship
between simple and complex alerts to be described.
2.1.2.1. Representing Events
The goal of the data model is to provide a standard representation of
the information that an intrusion detection analyzer reports when it
detects an occurrence of some unusual event(s). These alerts may be
simple or complex, depending on the capabilities of the analyzer that
creates them.
2.1.2.2. Content-Driven
The design of the data model is content-driven. This means that new
objects are introduced to accommodate additional content, not
semantic differences between alerts. This is an important goal, as
the task of classifying and naming computer vulnerabilities is both
extremely difficult and very subjective.
The data model must be unambiguous. This means that while we allow
analyzers to be more or less precise than one another (i.e., one
analyzer may report more information about an event than another), we
do not allow them to produce contradictory information in two alerts
describing the same event (i.e., the common subset of information
reported by both analyzers must be identical and inserted in the same
placeholders within the alert data structure). Of course, it is
always possible to insert all "interesting" information about an
event in extension fields of the alert instead of in the fields where
it belongs; however, such practice reduces interoperability and
should be avoided whenever possible.
2.1.2.3. Relationship Between Alerts
Intrusion detection alerts can be transmitted at several levels.
This Internet-Draft applies to the entire range, from very simple
Debar, et al. Expires September 17, 2006 [Page 7]

Internet-Draft The IDMEF March 2006
alerts (e.g., those alerts that are the result of a single action or
operation in the system, such as a failed login report) to very
complex ones (e.g., the aggregation of several events causing an
alert to be generated).
As such, the data model must provide a way for complex alerts that
aggregate several simple alerts to identify those simple alerts in
the complex alert's content.
2.2. About the IDMEF XML Implementation
Two implementations of the IDMEF were originally proposed to the
IDWG: one using the Structure of Management Information (SMI) to
describe an SNMP MIB, and the other using a Document Type Definition
(DTD) to describe XML documents.
These proposed implementations were reviewed by the IDWG at its
September 1999 and February 2000 meetings; it was decided at the
February meeting that the XML solution was best at fulfilling the
IDWG requirements.
2.2.1. The Extensible Markup Language
The Extensible Markup Language (XML) [3] is a simplified version of
the Standard Generalized Markup Language (SGML), a syntax for
specifying text markup defined by the ISO 8879 standard. XML is
gaining widespread attention as a language for representing and
exchanging documents and data on the Internet, and as the solution to
most of the problems inherent in HyperText Markup Language (HTML).
XML was published as a recommendation by the World Wide Web
Consortium (W3C) on February 10, 1998.
XML is a metalanguage -- a language for describing other languages --
that enables an application to define its own markup. XML allows the
definition of customized markup languages for different types of
documents and different applications. This differs from HTML, in
which there is a fixed set of identifiers with preset meanings that
must be "adapted" for specialized uses. Both XML and HTML use
elements (tags) (identifiers delimited by '<' and >') and attributes
(of the form "name='value'"). But where "<p>" always means
"paragraph" in HTML, it may mean "paragraph," "person," "price," or
"platypus" in XML, or it might have no meaning at all, depending on
the particular application.
Debar, et al. Expires September 17, 2006 [Page 8]

Internet-Draft The IDMEF March 2006
NOTE: XML provides both a syntax for declaring document markup and
structure (i.e., defining elements and attributes, specifying the
order in which they appear, and so on) and a syntax for using that
markup in documents. Because markup declarations look radically
different from markup, many people are confused as to which syntax
is called XML. The answer is that they both are, because they are
actually both part of the same language.
For clarity in this document, we will use the terms "XML" and "XML
documents" when speaking in the general case, and the term "IDMEF
markup" when speaking specifically of the elements (tags) and
attributes that describe IDMEF messages.
The publication of XML was followed by the publication of a second
recommendation [4] by the World Wide Web Consortium, defining the use
of namespaces in XML documents. An XML namespace is a collection of
names, identified by a Universal Resource Identifier (URI) [5]. When
using namespaces, each tag is identified with the namespace it comes
from, allowing tags from different namespaces with the same names to
occur in the same document. For example, a single document could
contain both "usa:football" and "europe:football" tags, each with
different meanings.
In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.
2.2.2. Rationale for Implementing IDMEF in XML
XML-based applications are being used or developed for a wide variety
of purposes, including electronic data interchange in a variety of
fields, financial data interchange, electronic business cards,
calendar and scheduling, enterprise software distribution, web "push"
technology, and markup languages for chemistry, mathematics, music,
molecular dynamics, astronomy, book and periodical publishing, web
publishing, weather observations, real estate transactions, and many
others.
XML's flexibility makes it a good choice for these applications; that
same flexibility makes it a good choice for implementing the IDMEF as
well. Other, more specific reasons for choosing XML to implement the
IDMEF are:
o XML allows a custom language to be developed specifically for the
purpose of describing intrusion detection alerts. It also defines
a standard way to extend this language, either for later revisions
of this document ("standard" extensions), or for vendor-specific
use ("non-standard" extensions).
Debar, et al. Expires September 17, 2006 [Page 9]

Internet-Draft The IDMEF March 2006
o Software tools for processing XML documents are widely available,
in both commercial and open source forms. Numerous tools and APIs
for parsing and/or validating XML are available in a variety of
languages, including Java, C, C++, Tcl, Perl, Python, and GNU
Emacs Lisp. Widespread access to tools will make adoption of the
IDMEF by product developers easier, and hopefully, faster.
o XML meets IDMEF Requirement 5.1 [2], that message formats support
full internationalization and localization. The XML standard
requires support for both the UTF-8 and UTF-16 encodings of ISO/
IEC 10646 (Universal Multiple-Octet Coded Character Set, "UCS")
and Unicode, making all XML applications (and therefore all IDMEF-
compliant applications) compatible with these common character
encodings.
XML also provides support for specifying, on a per-element basis,
the language in which the element's content is written, making
IDMEF easy to adapt to "Natural Language Support" versions of a
product.
o XML meets IDMEF Requirement 5.2 [2], that message formats must
support filtering and aggregation. XML's integration with XSL, a
style language, allows messages to be combined, discarded, and
rearranged.
o Ongoing XML development projects, in the W3C and elsewhere, will
provide object-oriented extensions, database support, and other
useful features. If implemented in XML, the IDMEF immediately
gains these features as well.
o XML is free, with no license, no license fees, and no royalties.
Debar, et al. Expires September 17, 2006 [Page 10]

Internet-Draft The IDMEF March 20063. Notational Conventions and Formatting Issues
This document uses three notations: Unified Modeling Language to
describe the data model, XML to describe the markup used in IDMEF
documents, and IDMEF markup to represent the documents themselves.
Appendix A describes these notations in sufficient detail that
readers unfamiliar with them can understand the document. Note,
however, that these descriptions are not comprehensive; they only
cover the components of the notations used by the data model and
document format.
Appendix A also explains several document formatting issues that
apply to XML documents, including formats for particular data types,
special character and whitespace processing, character sets, and
languages.
3.1. IDMEF XML Documents
This section describes IDMEF XML document formatting rules. Most of
these rules are "inherited" from the rules for formatting XML
documents; see Appendix A for more detail.
3.1.1. The Document Prolog
The format of an IDMEF XML document prolog is described in the
following sections.
3.1.1.1. XML Declaration
IDMEF documents being exchanged between IDMEF-compliant applications
MUST begin with an XML declaration, and MUST specify the XML version
in use. Specification of the encoding in use is RECOMMENDED.
An IDMEF message SHOULD therefore start with:
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
IDMEF-compliant applications MAY choose to omit the XML declaration
internally to conserve space, adding it only when the message is sent
to another destination (e.g., a web browser). This practice is NOT
RECOMMENDED unless it can be accomplished without loss of each
message's version and encoding information.
In order to be valid (see Section 6.1), an XML document must contain
Debar, et al. Expires September 17, 2006 [Page 11]

Internet-Draft The IDMEF March 2006
a document type declaration. However, this represents significant
overhead to an IDMEF-compliant application, both in the bandwidth it
consumes as well as the requirements it places on the XML processor
(not only to parse the declaration itself, but also to parse the DTD
it references).
Implementors MAY decide, therefore, to have analyzers and managers
agree out-of-band on the particular document type definition they
will be using to exchange messages (the standard one as defined here,
or one with extensions), and then omit the document type declaration
from IDMEF messages. The method for negotiating this agreement is
outside the scope of this document. Note that great care must be
taken in negotiating any such agreements, as the manager may have to
accept messages from many different analyzers, each using a DTD with
a different set of extensions.
3.1.2. Character Data Processing in IDMEF
For portability reasons, IDMEF-compliant applications SHOULD NOT use,
and IDMEF messages SHOULD NOT be encoded in, character encodings
other than UTF-8 and UTF-16. Consistent with the XML standard, if no
encoding is specified for an IDMEF message, UTF-8 is assumed.
NOTE: The ASCII character set is a subset of the UTF-8 encoding, and
therefore may be used to encode IDMEF messages.
Per the XML standard, IDMEF documents encoded in UTF-16 MUST begin
with the Byte Order Mark described by ISO/IEC 10646 Annex E and
Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character,
#xFEFF).
3.1.2.1. Character Entity References
It is RECOMMENDED that IDMEF-compliant applications use the entity
reference form (see A.3.2.1) of the characters '&', ,'<', '>', '"',
and ''' (single-quote) whenever writing these characters in data, to
avoid any possibility of misinterpretation.
3.1.2.2. White Space Processing
All IDMEF elements MUST support the "xml:space" attribute.
3.1.3. Languages in IDMEF
IDMEF-compliant applications MUST specify the language in which their
contents are encoded; in general this can be done by specifying the
"xml:lang" attribute for the top-level element and letting all other
elements "inherit" that definition.
Debar, et al. Expires September 17, 2006 [Page 12]

Internet-Draft The IDMEF March 20063.2. IDMEF Data Types
Within an XML IDMEF message, all data will be expressed as "text" (as
opposed to "binary"), since XML is a text formatting language. We
provide typing information for the attributes of the classes in the
data model however, to convey to the reader the type of data the
model expects for each attribute.
Each data type in the model has specific formatting requirements in
an XML IDMEF message; these requirements are set forth in this
section.
3.2.1. Integers
Integer attributes are represented by the INTEGER data type. Integer
data MUST be encoded in Base 10 or Base 16.
Base 10 integer encoding uses the digits '0' through '9' and an
optional sign ('+' or '-'). For example, "123", "-456".
Base 16 integer encoding uses the digits '0' through '9' and 'a'
through 'f' (or their upper case equivalents), and is preceded by the
characters "0x". For example, "0x1a2b".
3.2.2. Real Numbers
Real (floating-point) attributes are represented by the REAL data
type. Real data MUST be encoded in Base 10.
Real encoding is that of the POSIX 1003.1 "strtod" library function:
an optional sign ('+' or '-') followed by a non-empty string of
decimal digits, optionally containing a radix character, then an
optional exponent part. An exponent part consists of an 'e' or 'E',
followed by an optional sign, followed by one or more decimal digits.
For example, "123.45e02", "-567,89e-03".
IDMEF-compliant applications MUST support both the '.' and ',' radix
characters.
3.2.3. Characters and Strings
Single-character attributes are represented by the CHARACTER data
type. Multi-character attributes of known length are represented by
the STRING data type.
Character and string data have no special formatting requirements,
other than the need to occasionally use character references (see
Section 3.2.3.1 and Section 3.2.3.2) to represent special characters.
Debar, et al. Expires September 17, 2006 [Page 13]

Internet-Draft The IDMEF March 20063.2.3.1. Character Entity References
Within XML documents, certain characters have special meanings in
some contexts. To include the actual character itself in one of
these contexts, a special escape sequence, called an entity
reference, must be used.
The characters that sometimes need to be escaped, and their entity
references, are:
+-----------+------------------+
| Character | Entity Reference |
+-----------+------------------+
| & | &amp; |
| | |
| < | &lt; |
| | |
| > | &gt; |
| | |
| " | &quot; |
| | |
| ' | &apos; |
+-----------+------------------+
3.2.3.2. Character Code References
Any character defined by the ISO/IEC 10646 and Unicode standards may
be included in an XML document by the use of a character reference.
A character reference is started with the characters '&' and '#', and
ended with the character ';'. Between these characters, the
character code for the character inserted.
If the character code is preceded by an 'x' it is interpreted in
hexadecimal (base 16), otherwise, it is interpreted in decimal (base
10). For instance, the ampersand (&) is encoded as &#38; or &#x0026;
and the less-than sign (<) is encoded as &#60; or &#x003C;.
Any one-, two-, or four-byte character specified in the ISO/IEC 10646
and Unicode standards can be included in a document using this
technique.
3.2.4. Bytes
Binary data is represented by the BYTE (and BYTE[]) data type.
Binary data MUST be encoded in its entirety using base64.
Debar, et al. Expires September 17, 2006 [Page 14]

Internet-Draft The IDMEF March 20063.2.5. Enumerated Types
Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values.
3.2.6. Date-Time Strings
Date-time strings are represented by the DATETIME data type. Each
date-time string identifies a particular instant in time; ranges are
not supported.
Date-time strings are formatted according to a subset of ISO 8601:
2000 [6], as show below. Section references in parentheses refer to
sections of the ISO 8601:2000 standard.
1. Dates MUST be formatted as follows:
YYYY-MM-DD
where YYYY is the four- digit year, MM is the two-digit month
(01-12), and DD is the two- digit day (01-31). (Section 5.2.1.1,
"Complete representation -- Extended format.")
2. Times MUST be formatted as follows:
hh:mm:ss
where hh is the two-digit hour (00-24), mm is the two-digit
minute (00-59), and ss is the two-digit second (00-60). (Section5.3.1.1, "Complete representation -- Extended format.")
Note that midnight has two representations, 00:00:00 and
24:00:00. Both representations MUST be supported by IDMEF-
compliant applications, however, the 00:00:00 representation
SHOULD be used whenever possible.
Note also that this format accounts for leap seconds. Positive
leap seconds are inserted between 23:59:59Z and 24:00:00Z and are
represented as 23:59:60Z. Negative leap seconds are achieved by
the omission of 23:59:59Z. IDMEF-compliant applications MUST
support leap seconds.
3. Times MAY be formatted to include a decimal fraction of seconds,
as follows:
hh:mm:ss.ss or
hh:mm:ss,ss
Debar, et al. Expires September 17, 2006 [Page 15]

Internet-Draft The IDMEF March 2006
As many digits as necessary may follow the decimal sign (at least
one digit must follow the decimal sign). Decimal fractions of
hours and minutes are not supported. (Section 5.3.1.3,
"Representation of decimal fractions.")
IDMEF-compliant applications MUST support the use of both decimal
signs ('.' and ',').
Note that the number of digits in the fraction part does not
imply anything about accuracy -- i.e., "00.100000", "00,1000" and
"00.1" are all equivalent.
4. Times MUST be formatted to include (a) an indication that the
time is in Coordinated Universal Time (UTC), or (b) an indication
of the difference between the specified time and Coordinated
Universal Time.
* Times in UTC MUST be formatted by appending the letter 'Z' to
the time string as follows:
hh:mm:ssZ
hh:mm:ss.ssZ
hh:mm:ss,ssZ
(Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended
format.")
* If the time is ahead of or equal to UTC, a '+' sign is
appended to the time string; if the time is behind UTC, a '-'
sign is appended. Following the sign, the number of hours and
minutes representing the different from UTC is appended, as
follows:
hh:mm:ss+hh:mm
hh:mm:ss-hh:mm
hh:mm:ss.ss+hh:mm
hh:mm:ss.ss-hh:mm
hh:mm:ss,ss+hh:mm
hh:mm:ss,ss-hh:mm
The difference from UTC MUST be specified in both hours and
minutes, even if the minutes component is 0. A "difference"
of "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local
time and the difference with Coordinated Universal Time --
Extended Format.")
Debar, et al. Expires September 17, 2006 [Page 16]

Internet-Draft The IDMEF March 2006
5. Date-time strings are created by joining the date and time
strings with the letter 'T', as shown below:
YYYY-MM-DDThh:mm:ssZ
YYYY-MM-DDThh:mm:ss.ssZ
YYYY-MM-DDThh:mm:ss,ssZ
YYYY-MM-DDThh:mm:ss+hh:mm
YYYY-MM-DDThh:mm:ss-hh:mm
YYYY-MM-DDThh:mm:ss.ss+hh:mm
YYYY-MM-DDThh:mm:ss.ss-hh:mm
YYYY-MM-DDThh:mm:ss,ss+hh:mm
YYYY-MM-DDThh:mm:ss,ss-hh:mm
(Section 5.4.1, "Complete representation -- Extended format.")
In summary, IDMEF date-time strings MUST adhere to one of the nine
templates identified in Paragraph 5, above.
3.2.7. NTP Timestamps
NTP timestamps are represented by the NTPSTAMP data type, and are
described in detail in [7] and [8]. An NTP timestamp is a 64-bit
unsigned fixed-point number. The integer part is in the first 32
bits, and the fraction part is in the last 32 bits.
Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit
hexadecimal values, separated by a period ('.'). For example,
"0x12345678.0x87654321".
See also Section 6.4 for more information on NTP timestamps.
3.2.8. Port Lists
Port lists are represented by the PORTLIST data type, and consist of
a comma-separated list of numbers (individual integers) and ranges
(N-M means ports N through M, inclusive). Any combination of numbers
and ranges may be used in a single list. For example,
"5-25,37,42,43,53,69-119,123-514".
3.2.9. Unique Identifiers
There are two types of unique identifiers used in this specification.
Both types are represented by STRING data types.
These identifiers are implemented as attributes on the relevant XML
elements, and must have unique values as follows:
Debar, et al. Expires September 17, 2006 [Page 17]

Internet-Draft The IDMEF March 2006
1. The Analyzer class' (Section 4.2.4.1) "analyzerid" attribute, if
specified, MUST have a value that is unique across all analyzers
in the intrusion detection environment.
The "analyzerid" attribute is not required to be globally unique,
only unique within the intrusion detection environment of which
the analyzer is a member. It is permissible for two analyzers,
in different intrusion detection environments, to have the same
value for "analyzerid".
The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.
2. The Alert and Heartbeat messages (Section 4.2.2, Section 4.2.3)
must be uniquely identified by the couple (analyzerid,messageid),
if the analyzer supports the generation of message identifiers.
3. The Classification, Source, Target, Node, User, Process, Service,
File, Address, and UserId classes' (Section 4.2.4.2Section 4.2.4.3, Section 4.2.4.4, Section 4.2.7.2,
Section 4.2.7.3, Section 4.2.7.4, Section 4.2.7.5,
Section 4.2.7.6, Section 4.2.7.2.1, and Section 4.2.7.3.1)
"ident" attribute, if specified, MUST have a value that is unique
across all messages sent by the individual analyzer.
The "ident" attribute value MUST be unique for each particular
combination of data identifying an object, not for each object.
Objects may have more than one "ident" value associated with
them. For example, an identification of a host by name would
have one value, while an identification of that host by address
would have another value, and an identification of that host by
both name and address would have still another value.
Furthermore, different analyzers may produce different values for
the same information.
The "ident" attribute by itself provides a unique identifier only
among all the "ident" values sent by a particular analyzer. But
when combined with the "analyzerid" value for the analyzer, a
value that is unique across the intrusion detection environment
is created. Again, there is no requirement for global
uniqueness.
The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.
The specification of methods for creating the unique values contained
in these attributes is outside the scope of this document.
Debar, et al. Expires September 17, 2006 [Page 18]

Internet-Draft The IDMEF March 20064. The IDMEF Data Model and DTD
In this section, the individual components of the IDMEF data model
are explained in detail. 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 2 (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 |
| | +--------------+
| | +--------+ +----------+
Debar, et al. Expires September 17, 2006 [Page 19]

Internet-Draft The IDMEF March 2006
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 3. The aggregate classes themselves are described in
Section 4.2.4, Section 4.2.5, and Section 4.2.6.
Debar, et al. Expires September 17, 2006 [Page 21]

Internet-Draft The IDMEF March 2006
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
Debar, et al. Expires September 17, 2006 [Page 23]

Internet-Draft The IDMEF March 2006
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 5.
Debar, et al. Expires September 17, 2006 [Page 24]

Internet-Draft The IDMEF March 2006
+------------------+
| Alert |
+------------------+
/_\
|
+------------------+
| ToolAlert |
+------------------+ +-------------------+
| |<>----------| name |
| | +-------------------+
| | 0..1 +-------------------+
| |<>----------| command |
| | +-------------------+
| | 1..* +-------------------+
| |<>----------| alertident |
| | +-------------------+
| | | STRING analyzerid |
| | +-------------------+
+------------------+
Figure 5: 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.
Debar, et al. Expires September 17, 2006 [Page 25]

Internet-Draft The IDMEF March 2006
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 9.
+------------------+
| Alert |
+------------------+
/_\
|
+------------------+
| OverflowAlert |
+------------------+ +---------+
| |<>----------| program |
| | +---------+
| | 0..1 +---------+
| |<>----------| size |
| | +---------+
| | 0..1 +---------+
| |<>----------| buffer |
| | +---------+
+------------------+
Figure 9: The OverflowAlert Class
Debar, et al. Expires September 17, 2006 [Page 27]

Internet-Draft The IDMEF March 2006
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 11. The aggregate classes themselves are described
in Section 4.2.4 and Section 4.2.5.
Debar, et al. Expires September 17, 2006 [Page 28]

Internet-Draft The IDMEF March 20064.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 14.
+---------------------+
| 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 14: 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 want to forward it to
another manalyzer, it needs to substitute the original analyzer
Debar, et al. Expires September 17, 2006 [Page 31]

Internet-Draft The IDMEF March 2006
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 that the analyzerid.
manufacturer
Optional. The manufacturer of the analyzer software and/or
hardware.
Debar, et al. Expires September 17, 2006 [Page 32]

Internet-Draft The IDMEF March 2006
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 16.
+----------------+
| Classification |
+----------------+ 0..* +-----------+
| STRING ident |<>----------| Reference |
| STRING text | +-----------+
+----------------+
Debar, et al. Expires September 17, 2006 [Page 33]

Internet-Draft The IDMEF March 2006
Figure 16: The Classification Class
The aggregate class that make 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 18.
Debar, et al. Expires September 17, 2006 [Page 34]

Internet-Draft The IDMEF March 2006
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
Debar, et al. Expires September 17, 2006 [Page 36]

Internet-Draft The IDMEF March 2006
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.
Debar, et al. Expires September 17, 2006 [Page 38]

Internet-Draft The IDMEF March 2006
The Assessment class is composed of three aggregate classes, as shown
in Figure 22.
+------------------+
| Assessment |
+------------------+ 0..1 +------------+
| |<>----------| Impact |
| | +------------+
| | 0..* +------------+
| |<>----------| Action |
| | +------------+
| | 0..1 +------------+
| |<>----------| Confidence |
| | +------------+
+------------------+
Figure 22: 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
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
Debar, et al. Expires September 17, 2006 [Page 39]

Internet-Draft The IDMEF March 2006
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 analyzer
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.
Debar, et al. Expires September 17, 2006 [Page 41]

Internet-Draft The IDMEF March 2006
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 the
event(s) producing an alert was detected by the analyzer. In the
case of more than one event, the time 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
Debar, et al. Expires September 17, 2006 [Page 42]

Internet-Draft The IDMEF March 2006
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.)
Debar, et al. Expires September 17, 2006 [Page 43]

Internet-Draft The IDMEF March 2006
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.
4.2.7. The Support Classes
The support classes make up the major parts of the core classes, and
are shared between them.
4.2.7.1. The Reference Class
The Reference class provides the "name" of an alert, or other
information allowing the manager to determine what it is.
The Reference class is composed of two aggregate classes, as shown in
Figure 29.
+----------------+
| Reference |
+----------------+ +------+
| STRING origin |<>----------| name |
| STRING meaning | +------+
| | +------+
| |<>----------| url |
| | +------+
+----------------+
Debar, et al. Expires September 17, 2006 [Page 47]

Internet-Draft The IDMEF March 2006
Figure 29: The Reference Class
The aggregate classes that make up Reference are:
name
Exactly one. STRING. The name of the alert, from one of the
origins listed below.
url
Exactly one. STRING. A URL at which the manager (or the human
operator of the manager) can find additional information about the
alert. The document pointed to by the URL may include an in-depth
description of the attack, appropriate countermeasures, or other
information deemed relevant by the vendor.
This is represented in the IDMEF DTD as follows:
<!ENTITY % attvals.origin "
( unknown | vendor-specific | user-specific | bugtraqid | cve |
osvdb )
">
<!ELEMENT Reference (
name, url
)>
<!ATTLIST Reference
origin %attvals.origin; 'unknown'
meaning CDATA #IMPLIED
>
The Reference class has two attributes:
origin
Required. The source from which the name of the alert originates.
The permitted values for this attribute are shown below. The
default value is "unknown". (See also Section 10.)
Debar, et al. Expires September 17, 2006 [Page 48]

Internet-Draft The IDMEF March 2006
| 5 | group-privs | Another group id the group or process has |
| | | the ability to use, or a group id |
| | | associated with a file permission. On |
| | | Unix systems, this would be the "effect- |
| | | ive" group id in a group or process |
| | | context, and the group permissions in a |
| | | file context. On BSD-derived Unix |
| | | systems, multiple UserId elements of this |
| | | type would be used to include all the |
| | | group ids on the "group list." |
| | | |
| 6 | other-privs | Not used in a user, group, or process |
| | | context, only used in the file context. |
| | | The file permissions assigned to users who |
| | | do not match either the user or group |
| | | permissions on the file. On Unix systems, |
| | | this would be the "world" permissions. |
+------+---------------+--------------------------------------------+
tty
Optional. STRING. The tty the user is using.
4.2.7.4. The Process Class
The Process class is used to describe processes being executed on
sources, targets, and analyzers.
The Process class is composed of five aggregate classes, as shown in
Figure 39.
Debar, et al. Expires September 17, 2006 [Page 58]

Internet-Draft The IDMEF March 2006
env
Zero or more. STRING. An environment string associated with the
process; generally of the format "VARIABLE=value". Multiple
environment strings may be specified with multiple uses of env.
This is represented in the IDMEF DTD as follows:
<!ELEMENT Process (
name, pid?, path?, arg*, env*
)>
<!ATTLIST Process
ident CDATA '0'
%attlist.global;
>
The Process class has one attribute:
ident
Optional. A unique identifier for the process, see Section 3.2.9.
4.2.7.5. The Service Class
The Service class describes network services on sources and targets.
It can identify services by name, port, and protocol. When Service
occurs as an aggregate class of Source, it is understood that the
service is one from which activity of interest is originating; and
that the service is "attached" to the Node, Process, and User
information also contained in Source. Likewise, when Service occurs
as an aggregate class of Target, it is understood that the service is
one to which activity of interest is being directed; and that the
service is "attached" to the Node, Process, and User information also
contained in Target. If Service occurs in both Source and Target,
then information in both locations should be the same. If
information is the same in both locations and implementers wish to
carry it in only one location, they should specify it as an aggregate
of the Target class.
The Service class is composed of four aggregate classes, as shown in
Figure 41.
Debar, et al. Expires September 17, 2006 [Page 60]

Internet-Draft The IDMEF March 2006
Zero or one. STRING. Additional information about the protocol
being used. The intent of the protocol field is to carry
additional information related to the protocol being used when the
<Service> attributes iana_protocol_number or/and
iana_protocol_name are filed.
A Service MUST be specified as either (a) a name or a port, or (b) a
portlist. The protocol is optional in all cases, but no other
combinations are permitted.
Service is represented in the IDMEF DTD as follows:
<!ELEMENT Service (
(((name, port?) | (port, name?)) | portlist), protocol?,
SNMPService?, WebService?
)>
<!ATTLIST Service
ident CDATA '0'
ip_version CDATA #IMPLIED
iana_protocol_number CDATA #IMPLIED
iana_protocol_name CDATA #IMPLIED
%attlist.global;
>
The Service class has four attributes:
ident
Optional. A unique identifier for the service, see Section 3.2.9.
ip_version
Optional. INTEGER. The IP version number.
iana_protocol_number
Optional. INTEGER. The IANA protocol number.
iana_protocol_name
Optional. STRING. The IANA protocol name.
4.2.7.5.1. The WebService Class
The WebService class carries additional information related to web
traffic.
The WebService class is composed of four aggregate classes, as shown
Debar, et al. Expires September 17, 2006 [Page 62]

Internet-Draft The IDMEF March 2006
securityModel
Zero or one. INTEGER. The identification of the security model
in use, typically 0 for any, 1 for SNMPv1, 2 for SNMPv2c, 3 for
USM, see RFC 3411 [14] section 5 for appropriate values.
securityName
Zero or one. STRING. The object's security name, see RFC 3411
[14] section 3.2.2.
securityLevel
Zero or one. INTEGER. The security level of the SNMP request,
see RFC 3411 [14] section 3.4.3.
contextName
Zero or one. STRING. The object's context name, see RFC 3411
[14] section 3.3.3.
contextEngineID
Zero or one. STRING. The object's context engine identifier, see
RFC 3411 [14] section 3.3.2.
command
Zero or one. STRING. The command sent to the SNMP server (GET,
SET. etc.).
If other fields of an SNMP message are available and should be
incorporated in the IDMEF alert, they must be located in the
additionaldata structure with the meaning being an object definition
defined in RFC 3411 [14] section 5 and the value located within the
additionaldata payload.
This is represented in the IDMEF DTD as follows:
<!ELEMENT SNMPService (
oid?, messageProcessingModel?, securityModel?, securityName?,
securityLevel?, contextName?, contextEngineID?, command?
)>
<!ATTLIST SNMPService
%attlist.global;
>
Debar, et al. Expires September 17, 2006 [Page 66]

Internet-Draft The IDMEF March 2006
Figure 47: The File Class
The aggregate classes that make up File are:
name
Exactly one. STRING. The name of the file to which the alert
applies, not including the path to the file.
path
Exactly one. STRING. The full path to the file, including the
name. The path name should be represented in as "universal" a
manner as possible, to facilitate processing of the alert.
For Windows systems, the path should be specified using the
Universal Naming Convention (UNC) for remote files, and using a
drive letter for local files (e.g., "C:\boot.ini"). For Unix
systems, paths on network file systems should use the name of the
mounted resource instead of the local mount point (e.g.,
"fileserver:/usr/local/bin/foo"). The mount point can be provided
using the <Linkage> element.
create-time
Zero or one. DATETIME. Time the file was created. Note that
this is *not* the Unix "st_ctime" file attribute (which is not
file creation time). The Unix "st_ctime" attribute is contained
in the "Inode" class.
modify-time
Zero or one. DATETIME. Time the file was last modified.
access-time
Zero or one. DATETIME. Time the file was last accessed.
data-size
Zero or one. INTEGER. The size of the data, in bytes. Typically
what is meant when referring to file size. On Unix UFS file
systems, this value corresponds to stat.st_size. On Windows NTFS,
this value corres- ponds to VDL.
Debar, et al. Expires September 17, 2006 [Page 68]

Internet-Draft The IDMEF March 2006
ident
Optional. A unique identifier for this file, see Section 3.2.9.
category
Required. The context for the information being provided. The
permitted values are shown below. There is no default value.
(See also Section 10.)
+------+----------+-------------------------------------------------+
| Rank | Keyword | Description |
+------+----------+-------------------------------------------------+
| 0 | current | The file information is from after the reported |
| | | change |
| | | |
| 1 | original | The file information is from before the |
| | | reported change |
+------+----------+-------------------------------------------------+
fstype
Optional. The type of file system the file resides on. This
attribute governs how path names and other attributes are
interpreted.
file-type
Optional. The type of file, as a mime-type.
4.2.7.6.1. The FileAccess Class
The FileAccess class represents the access permissions on a file.
The representation is intended to be usefule across operating
systems.
The FileAccess class is composed of two aggregate classes, as shown
in Figure 49.
Debar, et al. Expires September 17, 2006 [Page 70]

Internet-Draft The IDMEF March 2006
| 6 | executeAs | This user has the ability to execute |
| | | this file as another user |
| | | |
| 7 | changePermissions | This user has the ability to change |
| | | the access permissions on this file |
| | | |
| 8 | takeOwnership | This user has the ability to take |
| | | ownership of this file |
+------+-------------------+----------------------------------------+
The "changePermissions" and "takeOwnership" strings represent those
concepts in Windows. On Unix, the owner of the file always has
"changePermissions" access, even if no other access is allowed for
that user. "Full Control" in Windows is represented by enumerating
the permissions it contains. The "executeAs" string represents the
set-user-id and set-group-id features in Unix.
This is represented in the IDMEF DTD as follows:
<!ELEMENT Permission EMPTY >
<!ATTLIST Permission
perms %attvals.fileperm; #REQUIRED
%attlist.global;
>
<!ENTITY % attvals.fileperm "( noAccess | read | write | execute |
search | delete | executeAs | changePermissions |
takeOwnership)" >
4.2.7.6.2. The Linkage Class
The Linkage class represents file system connections between the file
described in the <File> element and other objects in the file system.
For example, if the <File> element is a symbolic link or shortcut,
then the <Linkage> element should contain the name of the object the
link points to. Further information can be provided about the object
in the <Linkage> element with another <File> element, if appropriate.
The Linkage class is composed of three aggregate classes, as shown in
Figure 51.
Debar, et al. Expires September 17, 2006 [Page 72]

Internet-Draft The IDMEF March 2006
+--------------+
| Linkage |
+--------------+ +------+
| |<>----------| name |
| | +------+
| | +------+
| |<>----------| path |
| | +------+
| | +------+
| |<>----------| File |
| | +------+
+--------------+
Figure 51: The Linkage Class
The aggregate classes that make up Linkage are:
name
Exactly one. STRING. The name of the file system object. not
including the path.
path
Exactly one. STRING. The full path to the file system object,
including the name. The path name should be represented in as
"universal" a manner as possible, to facilitate processing of the
alert.
File
Exactly one. A <File> element may be used in place of the <name>
and <path> elements if additional information about the file is to
be included.
Debar, et al. Expires September 17, 2006 [Page 73]

Internet-Draft The IDMEF March 2006
Zero or one. INTEGER. The inode number.
major-device
Zero or one. INTEGER. The major device number of the device the
file resides on.
minor-device
Zero or one. INTEGER. The minor device number of the device the
file resides on.
c-major-device
Zero or one. INTEGER. The major device of the file itself, if it
is a character special device.
c-minor-device
Zero or one. INTEGER. The minor device of the file itself, if it
is a character special device.
Note that <number>, <major-device>, and <minor-device> must be given
together, and the <c-major-device> and <c-minor-device> must be given
together.
This is represented in the IDMEF DTD as follows:
<!ELEMENT Inode (
change-time?, (number, major-device, minor-device)?,
(c-major-device, c-minor-device)?
)>
<!ATTLIST Inode
%attlist.global;
>
4.2.7.6.4. The Checksum class
The Checksum class represents checksum information associated with
the file. This checksum information can be provided by file
integrity checkers, among others.
The checksum class is composed of two aggregate classes, as shown in
Figure 55.
Debar, et al. Expires September 17, 2006 [Page 76]

Internet-Draft The IDMEF March 20065. Extending the IDMEF
As intrusion detection systems evolve, the IDMEF data model and DTD
will have to evolve along with them. To allow new features to be
added as they are developed, both the data model and the DTD can be
extended as described in this section. As these extensions mature,
they can then be incorporated into future versions of the
specification.
5.1. Extending the Data Model
There are two mechanisms for extending the IDMEF data model,
inheritance and aggregation:
o Inheritance denotes a superclass/subclass type of relationship
where the subclass inherits all the attributes, operations, and
relationships of the superclass. This type of relationship is
also called a "is-a" or "kind-of" relationship. Subclasses may
have additional attributes or operations that apply only to the
subclass, and not to the superclass.
o Aggregation is a form of association in which the whole is related
to its parts. This type of relationship is also referred to as a
"part-of" relationship. In this case, the aggregate class
contains all of its own attributes and as many of the attributes
associated with its parts as required and specified by occurrence
indicators.
Of the two mechanisms, inheritance is preferred, because it preserves
the existing data model structure and also preserves the operations
(methods) executed on the classes of the structure.
Note that the rules for extending the IDMEF DTD (see below) set
limits on the places where extensions to the data model may be made.
5.2. Extending the IDMEF DTD
There are two ways to extend the IDMEF DTD:
1. The AdditionalData class (see Section 4.2.4.6) allows
implementors to include arbitrary "atomic" data items (integers,
strings, etc.) in an Alert or Heartbeat message. This approach
SHOULD be used whenever possible. See Section 7.4 and
Section 7.5.
2. The AdditionalData class allows implementors to extend the IDMEF
DTD with additional DTD "modules" that describe arbitrarily
complex data types and relationships. The remainder of this
Debar, et al. Expires September 17, 2006 [Page 79]

Internet-Draft The IDMEF March 2006
section describes this extension method.
To extend the IDMEF DTD with a new DTD "module," the following steps
MUST be followed:
1. The document declaration MUST define a DTD Location that define
the namespace and contains the location of the extension DTD, and
then reference that namespace.
2. Multiple extensions may be included by defining multiple
namespaces and DTD locations, and referencing them.
3. Extension DTDs MUST declare all of their elements and attributes
in a separate XML namespace. Extension DTDs MUST NOT declare any
elements or attributes in the "idmef" or default namespaces.
4. Extensions MUST only be included in IDMEF alert and heartbeat
messages under an <AdditionalData> element whose "type" attribute
contains the value "xml". For example:
In this example, the "vendorco" namespace is defined and then
referenced, causing the DTD for the extension to be read by the XML
parser.
<idmef:IDMEF-Message version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:idmef="http://iana.org/idmef"
xmlns:vendorco="http://vendor.com/idmef"
xsi:schemaLocation="http://vendor.com/idmef http://v.com/vidmef.xsd">
<idmef:Alert messageid="...">
...
<idmef:AdditionalData type="xml" meaning="VendorExtension">
<idmef:xml>
<vendorco:TestVendor a="attribute of example"
xmlns:vendorco="http://vendor.com/idmef"
xsi:schemaLocation="http://vendor.com/idmef http://v.com/vidmef.xsd">
<vendorco:content>content element of example</vendorco:content>
</vendorco:TestVendor>
</idmef:xml>
</idmef:AdditionalData>
</idmef:Alert>
</idmef:IDMEF-Message>
See Section 7.8 for another example of extending the IDMEF DTD.
Debar, et al. Expires September 17, 2006 [Page 80]

Internet-Draft The IDMEF March 20066. Special Considerations
This section discusses some of the special considerations that must
be taken into account by implementors of the IDMEF.
6.1. XML Validity and Well-Formedness
It is expected that IDMEF-compliant applications will not normally
include the IDMEF DTD itself in their communications. Instead, the
DTD will be referenced in the document type declaration in the IDMEF
message. Such IDMEF documents will be well-formed and valid as
defined in [3].
Other IDMEF documents will be specified that do not include the
document prolog (e.g., entries in an IDMEF-format database). Such
IDMEF documents will be well-formed but not valid.
Generally, well-formedness implies that a document has a single
element that contains everything else (e.g., "<Book>"), and that all
the other elements nest nicely within each other without any
overlapping (e.g., a "chapter" does not start in the middle of
another "chapter").
Validity further implies that not only is the document well-formed,
but it also follows specific rules (contained in the Document Type
Definition) about which elements are "legal" in the document, how
those elements nest within other elements, and so on (e.g., a
"chapter" does not begin in the middle of a "title"). A document
cannot be valid unless it references a DTD.
XML processors are required to be able to parse any well-formed
document, valid or not. The purpose of validation is to make the
processing of that document (what's done with the data after it's
parsed) easier. Without validation, a document may contain elements
in nonsense order, elements "invented" by the author that the
processing application doesn't understand, and so forth.
IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid
whenever both possible and practical.
6.2. Unrecognized XML Tags
On occasion, an IDMEF-compliant application may receive a well-
formed, or even well-formed and valid, IDMEF message containing tags
that it does not understand. The tags may be either:
Debar, et al. Expires September 17, 2006 [Page 81]

Internet-Draft The IDMEF March 2006
o Recognized as "legitimate" (a valid document), but the application
does not know the semantic meaning of the element's content; or
o Not recognized at all.
IDMEF-compliant applications MUST continue to process IDMEF messages
that contain unknown tags, provided that such messages meet the well-
formedness requirement of Section 6.1. It is up to the individual
application to decide how to process (or ignore) any content from the
unknown elements(s).
6.3. Analyzer-Manager Time Synchronization
Synchronization of time-of-day clocks between analyzers and managers
is outside the scope of this document. However, the following
comments and suggestions are offered:
1. Whenever possible, all analyzers and managers should have their
time-of-day clocks synchronized to an external source such as NTP
or SNTP [13, 14], GPS/GOES/WWV clocks, or some other reliable
time standard.
2. When external time synchronization is not possible, the IDMEF
provides the <AnalyzerTime> element, which may be used to perform
rudimentary time synchronization (see below).
3. IDMEF-compliant applications SHOULD permit the user to enable/
disable the <AnalyzerTime> method of time synchronization as a
configuration option.
A number of caveats apply to the use of <AnalyzerTime> for time
synchronization:
1. <AnalyzerTime> works best in a "flat" environment where analyzers
report up to a single level of managers. When a tree topology of
high-level managers, intermediate relays, and analyzers is used,
the problem becomes more complex.
2. When intermediate message relays (managers or otherwise) are
involved, two scenarios are possible:
* The intermediaries may forward entire IDMEF messages, or may
perform aggregation or correlation, but MUST NOT inject delay.
In this case, time synchronization is end-to-end between the
analyzer and the highest-level manager.
* The intermediaries may inject delay, due to storage or
additional processing. In this case, time synchronization
Debar, et al. Expires September 17, 2006 [Page 82]

Internet-Draft The IDMEF March 2006
MUST be performed at each hop. This means each intermediary
must decompose the IDMEF message, adjust all time values, and
then reconstruct the message before sending it on.
3. When the environment is mixed, with some analyzers and managers
using external time synchronization and some not, all managers
and intermediaries must perform <AnalyzerTime> synchronization.
This is because determining whether or not compensation is
actually needed between two parties rapidly becomes very complex,
and requires knowledge of other parts of the topology.
4. If an alert can take alternate paths, or be stored in multiple
locations, the recorded times may be different depending on the
path taken.
The above being said, <AnalyzerTime> synchronization is probably
still better than nothing in many environments. To implement this
type of synchronization, the following procedure is suggested:
1. When an analyzer or manager sends an IDMEF message, it should
place the current value of its time-of-day clock in an
<AnalyzerTime> element. This should occur as late as possible in
the message transmission process, ideally right before the
message is "put on the wire."
2. When a manager receives an IDMEF message, it should compute the
difference between its own time-of-day clock and the time in the
<AnalyzerTime> element of the message. This difference should
then be used to adjust the times in the <CreateTime> and
<DetectTime> elements (NTP timestamps should also be adjusted).
3. If the manager is an intermediary and sends the IDMEF message on
to a higher-level manager, and hop-by-hop synchronization is in
effect, it should regenerate the <AnalyzerTime> value to contain
the value of its own time-of-day clock.
6.4. NTP Timestamp Wrap-Around
From [8]:
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that
the 64-bit field will overflow some time in 2036 (second
4,294,967,296). Should NTP or SNTP be in use in 2036, some
external means will be necessary to qualify time relative to 1900
and time relative to 2036 (and other multiples of 136 years).
There will exist a 200-picosecond interval, henceforth ignored,
every 136 years when the 64-bit field will be 0, which by
Debar, et al. Expires September 17, 2006 [Page 83]

Internet-Draft The IDMEF March 2006
convention is interpreted as an invalid or unavailable timestamp.
IDMEF-compliant applications MUST NOT send a zero-valued NTP
timestamp unless they mean to indicate that it is invalid or
unavailable. If an IDMEF-compliant application must send an IDMEF
message at the time of rollover, the application should wait for 200
picoseconds until the timestamp will have a non-zero value.
Also from [8]:
As the NTP timestamp format has been in use for the last 17 years,
it remains a possibility that it will be in use 40 years from now
when the seconds field overflows. As it is probably inappropriate
to archive NTP timestamps before bit 0 was set in 1968, a
convenient way to extend the useful life of NTP timestamps is the
following convention:
If bit 0 is set, the UTC time is in the range 1968-2036 and UTC
time is reckoned from 0h 0m 0s UTC on 1 January 1900.
If bit 0 is not set, the time is in the range 2036-2104 and UTC
time is reckoned from 6h 28m 16s UTC on 7 February 2036.
Note that when calculating the correspondence, 2000 is not a leap
year. Note also that leap seconds are not counted in the
reckoning.
IDMEF-compliant applications in use after 2036-02-07T06:28:16Z MUST
adhere to the above convention.
6.5. Digital Signatures
Standard XML digital signature processing rules and syntax are
specified in [11]. XML Signatures provide integrity, message
authentication, and/or signer authentication services for data of any
type, whether located within the XML that includes the signature or
elsewhere.
The IDMEF requirements document [2] assigns responsibility for
message integrity and authentication to the communications protocol,
not the message format. However, in situations where IDMEF messages
are exchanged over other, less secure protocols, or in cases where
the digital signatures must be archived for later use, the inclusion
of digital signatures within an IDMEF message itself may be
desirable.
Debar, et al. Expires September 17, 2006 [Page 84]

Internet-Draft The IDMEF March 2006
Specifications for the use of digital signatures within IDMEF
messages are outside the scope of this document. However, if such
functionality is needed, use of the XML Signature standard is
RECOMMENDED.
Debar, et al. Expires September 17, 2006 [Page 85]

Internet-Draft The IDMEF March 20067. Examples
The examples shown in this section demonstrate how the IDMEF is used
to encode alert data. These examples are for illustrative purposes
only, and do not necessarily represent the only (or even the "best"
way to encode these particular alerts). These examples should not be
taken as guidelines on how alerts should be classified.
7.1. Denial of Service Attacks
The following examples show how some common denial of service attacks
could be represented in the IDMEF.
7.1.1. The "teardrop" Attack
Network-based detection of the "teardrop" attack. This shows the
basic format of an alert.
Debar, et al. Expires September 17, 2006 [Page 86]

Internet-Draft The IDMEF March 20069. Security Considerations
This Internet-Draft describes a data representation for exchanging
security-related information between intrusion detection system
implementations. Although there are no security concerns directly
applicable to the format of this data, the data itself may contain
security-sensitive information whose confidentiality, integrity,
and/or availability may need to be protected.
This suggests that the systems used to collect, transmit, process,
and store this data should be protected against unauthorized use, and
that the data itself should be protected against unauthorized access.
The means for achieving this protection are outside the scope of this
document.
Section 5 of [2] describes the required and recommended security
characteristics of the transmission protocol that will be used to
deliver IDMEF data from analyzers to managers. These requirements
include message confidentiality, message integrity, non-repudiation,
and avoidance of duplicate messages. Both standard and proposed
protocols exist that provide these features.
Where a protocol that does not meet the requirements of Section 5 of
[2] is used to exchange IDMEF messages, it may be desirable to use
digital signatures to certify the integrity of these messages; this
is discussed in Section 6.5 of this document.
Debar, et al. Expires September 17, 2006 [Page 120]

Internet-Draft The IDMEF March 200610. IANA ConsiderationsSection 5 describes how to use the AdditionalData class to include
arbitrary "atomic" data items in an IDMEF message, as well as how
AdditionalData may be used to extended the DTD itself by adding new
classes and attributes.
From time to time, it may be desirable to move an extension from its
private or local use status (as all extensions made via the above
mechanism are) to "standard" status that should be supported by all
implementations.
This may be accomplished as described in this section.
10.1. Adding Values to Existing Attributes
Several of the attributes specified in this document have lists of
permissible values that they may contain. To allow the addition of
new values to these lists, the IANA will create a repository for
attribute values called "IDMEF Attribute Values."
Following the policies outlined in [9], this repository is
"Specification Required" by RFC. Section 10.1.1 describes the
initial values for this repository.
To create a new attribute, you MUST publish an RFC to document the
type. In the RFC, include a copy of the registration template found
in Section 10.1.2 of this document. Put the template in your IANA
Considerations section, filling in the appropriate fields. You MUST
describe any interoperability and security issues in your document.
When adding a new attribute value to the repository, the IANA shall
assign the next rank number in numerical sequence for the value.
10.1.1. Attribute Registrations
IDMEF Class Name: Reference
IDMEF Attribute Name: origin
Registered Values:
Debar, et al. Expires September 17, 2006 [Page 121]

Internet-Draft The IDMEF March 2006
Contact Person and E-Mail Address:
<your name and e-mail address>
10.2. Adding New Attributes and Classes
To the extent possible, the IDMEF classes and attributes specified in
this document have been designed to accomodate all current and near-
future needs. Although it is recognized that the addition of new
classes, as well as the addition of new attributes to existing
classes, will be necessary in the future, these actions should not be
taken lightly.
Any addition of new attributes or classes should only be undertaken
when the current classes and attributes simply cannot be used to
represent the information in a "clean" way -- and such additions
should only be made to represent generally-useful types of data.
Vendor-specific information, obscure information provided by only a
particular type of analyzer or used only by a particular type of
manager, "pet" attributes, and the like are not good reasons to make
class and attribute additions.
At the time this RFC was written, the first anticipated case for
which new classes and attributes will need to be added is to handle
host-based intrusion detection systems. However, such additions
should not be made until some level of consensus has been reached
about the set of data that will be provided by these systems.
Following the policies outlined in [9], the addition of new classes
and attributes to the IDMEF requires "IETF Consensus."
To add new attributes or classes, you MUST publish an RFC to document
them, and get that RFC approved by the IESG. Typically, the IESG
will seek input on prospective additions from appropriate persons
(e.g., a relevant Working Group if one exists). You MUST describe
any interoperability and security issues in your document.
Debar, et al. Expires September 17, 2006 [Page 135]

Internet-Draft The IDMEF March 2006Appendix A. History of Significant Changes
The RFC Editor should remove this section and its corresponding TOC
references prior to publication.
A.1. Things to do before publication
Remove this section.
A.2. Response to IESG commentsA.2.1. Comment on Section 3.1.3A.2.1.1. Comment
I'm not sure that this is a good thing to say: "If no language is
specified for an IDMEF message, English SHALL be assumed." (RFC1766
--and 3066?-- has some words about i-default)
A.2.1.2. Response
Changed "IDMEF-compliant applications SHOULD" to "IDMEF-compliant
applications MUST" and drop the 2 other paragraphs in the section.
A.2.2. Comment on Section A.3.4A.2.2.1. Comment
"As a note of interest, XML Schemas, currently being developed by the
W3C, will provide support for inheritance, as well as stronger data
typing and other useful features. Future versions of the IDMEF will
probably use XML Schemas instead of DTDs; this is not currently
possible because the XML Schema Recommendation has not been
finalized."
How *old* is this document? XML schema was approved as a W3C >
Recommendation (approximately their equivalent to IETF full standard)
> over 18 months ago -- http://www.w3.org/XML/SchemaA.2.2.2. Response
The paragraph has been dropped and the document includes an XML
schema equivalent to the DTD. The normative reference is now the
schema.
A.2.3. Comment on Section 3.2Debar, et al. Expires September 17, 2006 [Page 138]

Internet-Draft The IDMEF March 2006A.2.3.1. Comment
Data typing should make reference to XML schema datatypes [2]. Even
> among those who promote alternatives to XML schema, most folks use
the XML schema datatypes as defined. [2]
http://www.w3.org/TR/xmlschema-2/A.2.3.2. Response
This has been realized with the creation of the schema.
A.2.3.3. Comment
Also, the number notations are muddling encoding issues with
presentation issues (cf. use of '.' and ',' in numbers).
A.2.3.4. Response
I do not think this is the case. We're trying to solve the EU/US
input problem, not pretty-print.
A.2.4. Comment on section 3.2.4A.2.4.1. Comment
My earlier comment was this: "Using XML character references to
encode binary data seems seriously broken to me. Character
references in XML denote Unicode code points, *not* byte values. I
suggest looking to the XML encryption work for ways to encode binary
data in XML." Now I haven't a clue what this document is
specifiying. There is a reference to a BYTE datatype, but no
description I can see of how it is encoded in XML.
A.2.4.2. Response
The comment is right. This has been changed to base64 encoding,
reflecting current practice.
A.2.5. Comment on 3.2.5 Enumerated TypesA.2.5.1. Comment
"Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values. Each value has a rank
(number) and a representing keyword. Within IDMEF XML messages, the
enumerated type keywords are used as attribute values, and the ranks
are ignored. However, those IDMEF-compliant applications that choose
to represent these values internally in a numeric format MUST use the
Debar, et al. Expires September 17, 2006 [Page 139]

Internet-Draft The IDMEF March 2006
rank values identified in this memo." What right has a spec of this
type to tell an application to do internally?
A.2.5.2. Response
Paragraph dropped, replaced by:
Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values.
A.2.6. Comment on Section 4.*A.2.6.1. Comment
I think the UML-based data modelling could usefully be separated from
XML DTD definitions; I'd go far as to suggest the UML data model
should be a separate document in its own right. This would serve to
separate the essential data design from its representation in XML.
A.2.6.2. Response
There is a WG concensus for having one draft. There were two before,
and it was decided to merge them to ensure that there would not be
any divergence between the model and the normative spec (DTD or
schema).
A.2.6.3. Comment
This part contains a number of enumerated string values. It seems to
me that these could more usefully be assigned URIs (maybe, URNs).
Using XML namespaces, these could then become element names, with all
but the last part of the URI being the namespace URI. I think this
would better support the claimed requirement (section 2.1.1) for easy
extensibility.
A.2.6.4. Response
The schema does this.
A.2.7. Comment on Section 5Section 5 is now section 6 because of the addition of the schema.
A.2.7.1. Comment
I'm uneasy about the approach to extensibility, particularly DTD
extensions. For an Internet standard it feels rather fragile,
depending on things like XML parameter-entity references within a
Debar, et al. Expires September 17, 2006 [Page 140]

Internet-Draft The IDMEF March 2006
DTD-declaration. This is a gut feel, which I cannot substantiate.
A.2.7.2. Response
As far as I can tell, this only impacts 6.2. Including XML in the
additionaldata structure is correct, at least in the schema.
A.2.7.3. Comment
I could not find a definition of the namespace URI.
A.2.7.4. Response
It is now on both the schema and the DTD. The schema is clearly
better in defining this.
A.2.7.5. CommentSection 2.2.1 claims that IDMEF elements will be in an XML namespace,
but the examples given have no namespace declaration, so the elements
used there are not namespace qualified. I think the use of a
namespace is correct. A simple fix is to use a default namespace
declaration in the examples.
A.2.7.6. Response
The namespace has been added to the examples.
A.2.8. Comment on Section 7.8A.2.8.1. Comment
The example contains what I think is an incorrect attempt to use XML
namespace prefix 'VendorCo:'. Specifically, there is no xmlns:
VendorCo declaration in the XML data. I don't think the attempt to
define the namespace in the DTD is valid ... or if it is, I don't
think it's advisable, because it means the namespace cannot be
identified without access to the DTD. (I'm not certain about this,
and think it should be run by an XML expert.)
A.2.8.2. Response
After verification with an XML expert, and according to the XML
documents on w3c.org, this is - at least for the schema - the correct
procedure for including XML in an IDMEF message.
Debar, et al. Expires September 17, 2006 [Page 141]

Internet-Draft The IDMEF March 2006A.3. Significant Changes Since idmef-10
[BF] Converted memo to RFC2629-compliant XML.
[BF] Added Appendix A.
[HD] Changed examples to have diverse urls.
[HD] Changed Dave Curry contact info.
[HD] Altered language setting.
[HD] Simplified enumerated types.
[HD] Added name attribute to analyzer.
[HD] Changed ident in Alert and Heartbeat to messageid and added
description in "Unique Identifiers" section, because we really mean
something different than the ident in the other classes.
[HD] Made fstype an optional attribute rather than a required one,
because it's difficult to get to in some situations, and it's not
provided by many systems.
[HD] Added checksum class.
[HD] Cleaned & errors in document.
[HD] Important change to transform the classification class as
Classification-Reference (carrying the former classification
information).
[HD] Added recursive path to the analyzer.
[HD] Completed recursive path to the analyzer.
[HD] Specified better definition for additionaldata.meaning - this
may be temporary pending the definition of a list of meaning
keywords. The encoding keyword has not been added.
[HD] Added IANA number/name for service class.
[HD] Added info to low/medium/high severity.
[HD] Reference new XML digital sigs standard.
[HD] Changed IANA STRING -> INTEGER
Debar, et al. Expires September 17, 2006 [Page 142]

Internet-Draft The IDMEF March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Debar, et al. Expires September 17, 2006 [Page 167]