RFC 4765
The Intrusion Detection Message Exchange Format (IDMEF)
Pages: 157
Experimental
Experimental
Part 1 of 6 – Pages 1 to 18
Network Working Group H. Debar Request for Comments: 4765 France Telecom Category: Experimental D. Curry Guardian B. Feinstein SecureWorks, Inc. March 2007 The Intrusion Detection Message Exchange Format (IDMEF) Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). IESG Note The content of this RFC was at one time considered by the IETF, but the working group concluded before this work was approved as a standards-track protocol. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The IESG has chosen to publish this document in order to document the work as it was when the working group concluded and to encourage experimentation and development of the technology. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment.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 that may need to interact with them. This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided.
Table of Contents
1. Introduction ....................................................4 1.1. About the IDMEF Data Model .................................4 1.1.1. Problems Addressed by the Data Model ................5 1.1.2. Data Model Design Goals .............................6 1.2. About the IDMEF XML Implementation .........................7 1.2.1. The Extensible Markup Language ......................7 1.2.2. Rationale for Implementing IDMEF in XML .............8 2. Notices and Conventions Used in This Document ..................10 3. Notational Conventions and Formatting Issues ...................10 3.1. IDMEF XML Documents .......................................10 3.1.1. The Document Prolog ................................10 3.1.2. Character Data Processing in IDMEF .................11 3.1.3. Languages in IDMEF .................................12 3.2. IDMEF Data Types ..........................................12 3.2.1. Integers ...........................................12 3.2.2. Real Numbers .......................................12 3.2.3. Characters and Strings .............................13 3.2.4. Bytes ..............................................14 3.2.5. Enumerated Types ...................................14 3.2.6. Date-Time Strings ..................................14 3.2.7. NTP Timestamps .....................................16 3.2.8. Port Lists .........................................16 3.2.9. Unique Identifiers .................................17 4. The IDMEF Data Model and DTD ...................................18 4.1. Data Model Overview .......................................18 4.2. The Message Classes .......................................20 4.2.1. The IDMEF-Message Class ............................20 4.2.2. The Alert Class ....................................20 4.2.3. The Heartbeat Class ................................27 4.2.4. The Core Classes ...................................29 4.2.5. The Time Classes ...................................41 4.2.6. The Assessment Classes .............................42 4.2.7. The Support Classes ................................47 5. Extending the IDMEF ............................................79 5.1. Extending the Data Model ..................................79 5.2. Extending the IDMEF DTD ...................................80 6. Special Considerations .........................................81 6.1. XML Validity and Well-Formedness ..........................81 6.2. Unrecognized XML Tags .....................................82 6.3. Analyzer-Manager Time Synchronization .....................82 6.4. NTP Timestamp Wrap-Around .................................84 6.5. Digital Signatures ........................................85 7. Examples .......................................................85 7.1. Denial-of-Service Attacks .................................86 7.1.1. The "teardrop" Attack ..............................86 7.1.2. The "ping of death" Attack .........................87
7.2. Port Scanning Attacks .....................................88
7.2.1. Connection to a Disallowed Service .................88
7.2.2. Simple Port Scanning ...............................89
7.3. Local Attacks .............................................90
7.3.1. The "loadmodule" Attack ............................90
7.3.2. The "phf" Attack ...................................93
7.3.3. File Modification ..................................94
7.4. System Policy Violation ...................................96
7.5. Correlated Alerts .........................................98
7.6. Analyzer Assessments ......................................99
7.7. Heartbeat ................................................100
7.8. XML Extension ............................................101
8. The IDMEF Document Type Definition (Normative) ................104
9. Security Considerations .......................................117
10. IANA Considerations ..........................................118
10.1. Adding Values to Existing Attributes ....................118
10.1.1. Attribute Registrations ..........................119
10.1.2. Registration Template ............................130
10.2. Adding New Attributes and Classes .......................131
11. References ...................................................131
11.1. Normative References ....................................131
11.2. Informative References ..................................132
Appendix A. Acknowledgements ....................................134
Appendix B. The IDMEF Schema Definition (Non-normative) .........135
1. 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.1.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.
1.1.1. Problems Addressed by the Data Model
The data model addresses several problems associated with 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 Intrusion 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 notions 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 Document Type Definition (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
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.
1.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.
1.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.
1.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.1.1.2.3. Relationship between Alerts
Intrusion detection alerts can be transmitted at several levels. This document applies to the entire range, from very simple 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.1.2. About the IDMEF XML Implementation
Two implementations of the IDMEF were originally proposed to the Intrusion Detection Working Group (IDWG): one using the Structure of Management Information (SMI) to describe a Simple Network Management Protocol (SNMP) MIB, and the other using a 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.1.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.
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 Uniform 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.
1.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).
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.
2. 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".3. Notational Conventions and Formatting Issues
This document uses three notations: Unified Modeling Language to describe the data model [14], XML to describe the markup used in IDMEF documents, and IDMEF markup to represent the documents themselves.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.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 a document type definition. 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 definition 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 Section 3.2.3.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 [10].3.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 that 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 uppercase 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.3.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 | +-----------+------------------+ | & | & | | | | | < | < | | | | | > | > | | | | | " | " | | | | | ' | ' | +-----------+------------------+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 is 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 & or & and the less-than sign (<) is encoded as < or <.
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.3.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 [6]. 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). (Section 5.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
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".)
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 they must have unique values as follows: 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 (Sections 4.2.2, 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' (Sections 4.2.4.2, 4.2.4.3, 4.2.4.4, 4.2.7.2, 4.2.7.3, 4.2.7.4, 4.2.7.5, 4.2.7.6, 4.2.7.2.1, and 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.
(page 18 continued on part 2)