Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4765

The Intrusion Detection Message Exchange Format (IDMEF)

Pages: 157
Experimental
Part 1 of 6 – Pages 1 to 18
None   None   Next

Top   ToC   RFC4765 - Page 1
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.
Top   ToC   RFC4765 - Page 2

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
Top   ToC   RFC4765 - Page 3
      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
Top   ToC   RFC4765 - Page 4

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.
Top   ToC   RFC4765 - Page 5

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.
Top   ToC   RFC4765 - Page 6
   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
Top   ToC   RFC4765 - Page 7
   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
Top   ToC   RFC4765 - Page 8
   (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:
Top   ToC   RFC4765 - Page 9
   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.
Top   ToC   RFC4765 - Page 10

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"/>
Top   ToC   RFC4765 - Page 11
   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.
Top   ToC   RFC4765 - Page 12

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.
Top   ToC   RFC4765 - Page 13

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 | +-----------+------------------+ | & | &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 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 &#38; or &#x0026; and the less-than sign (<) is encoded as &#60; or &#x003C;.
Top   ToC   RFC4765 - Page 14
   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.
Top   ToC   RFC4765 - Page 15
       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
Top   ToC   RFC4765 - Page 16
             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".
Top   ToC   RFC4765 - Page 17

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.
Top   ToC   RFC4765 - Page 18
       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)

Next Section