GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4765

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.

Debar, et al. Experimental [Page 1] RFC 4765 The IDMEF March 2007

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

Debar, et al. Experimental [Page 2] RFC 4765 The IDMEF March 2007

    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

Debar, et al. Experimental [Page 3] RFC 4765 The IDMEF March 2007

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.

Debar, et al. Experimental [Page 4] RFC 4765 The IDMEF March 2007

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.

Debar, et al. Experimental [Page 5] RFC 4765 The IDMEF March 2007

 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

Debar, et al. Experimental [Page 6] RFC 4765 The IDMEF March 2007

 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

Debar, et al. Experimental [Page 7] RFC 4765 The IDMEF March 2007

 (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:

Debar, et al. Experimental [Page 8] RFC 4765 The IDMEF March 2007

 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.

Debar, et al. Experimental [Page 9] RFC 4765 The IDMEF March 2007

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"/>

Debar, et al. Experimental [Page 10] RFC 4765 The IDMEF March 2007

 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.

Debar, et al. Experimental [Page 11] RFC 4765 The IDMEF March 2007

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.

Debar, et al. Experimental [Page 12] RFC 4765 The IDMEF March 2007

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;.

Debar, et al. Experimental [Page 13] RFC 4765 The IDMEF March 2007

 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.

Debar, et al. Experimental [Page 14] RFC 4765 The IDMEF March 2007

     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

Debar, et al. Experimental [Page 15] RFC 4765 The IDMEF March 2007

           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".

Debar, et al. Experimental [Page 16] RFC 4765 The IDMEF March 2007

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.

Debar, et al. Experimental [Page 17] RFC 4765 The IDMEF March 2007

     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.

4. The IDMEF Data Model and DTD

 In this section, the individual components of the IDMEF data model
 are explained in detail.  Unified Modeling Language (UML) diagrams of
 the model are provided to show how the components are related to each
 other, and relevant sections of the IDMEF DTD are presented to show
 how the model is translated into XML.

4.1. Data Model Overview

 The relationship between the principal components of the data model
 is shown in Figure 1 (occurrence indicators and attributes are
 omitted).
 The top-level class for all IDMEF messages is IDMEF-Message; each
 type of message is a subclass of this top-level class.  There are
 presently two types of messages defined: Alerts and Heartbeats.
 Within each message, subclasses of the message class are used to
 provide the detailed information carried in the message.
 It is important to note that the data model does not specify how an
 alert should be classified or identified.  For example, a port scan
 may be identified by one analyzer as a single attack against multiple
 targets, while another analyzer might identify it as multiple attacks
 from a single source.  However, once an analyzer has determined the
 type of alert it plans to send, the data model dictates how that
 alert should be formatted.

Debar, et al. Experimental [Page 18] RFC 4765 The IDMEF March 2007

                       IDMEF-Message
                            /_\
                             |
        +--------------------+-------------+
        |                                  |
    +-------+   +--------------+    +-----------+   +----------------+
    | Alert |<>-|   Analyzer   |    | Heartbeat |<>-|    Analyzer    |
    +-------+   +--------------+    +-----------+   +----------------+
    |       |   +--------------+    |           |   +----------------+
    |       |<>-|  CreateTime  |    |           |<>-|   CreateTime   |
    |       |   +--------------+    |           |   +----------------+
    |       |   +--------------+    |           |   +----------------+
    |       |<>-|  DetectTime  |    |           |<>-| AdditionalData |
    |       |   +--------------+    +-----------+   +----------------+
    |       |   +--------------+
    |       |<>-| AnalyzerTime |
    |       |   +--------------+
    |       |   +--------+   +----------+
    |       |<>-| Source |<>-|   Node   |
    |       |   +--------+   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-|   User   |
    |       |   |        |   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-| Process  |
    |       |   |        |   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-| Service  |
    |       |   +--------+   +----------+
    |       |   +--------+   +----------+
    |       |<>-| Target |<>-|   Node   |
    |       |   +--------+   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-|   User   |
    |       |   |        |   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-| Process  |
    |       |   |        |   +----------+
    |       |   |        |   +----------+
    |       |   |        |<>-| Service  |       +----------------+
    |       |   |        |   +----------+  +----| Classification |
    |       |   |        |   +----------+  |    +----------------+
    |       |   |        |<>-|   File   |  |    +----------------+
    |       |   +--------+   +----------+  | +--|   Assessment   |
    |       |<>----------------------------+ |  +----------------+
    |       |<>------------------------------+  +----------------+
    |       |<>---------------------------------| AdditionalData |
    +-------+                                   +----------------+

Debar, et al. Experimental [Page 19] RFC 4765 The IDMEF March 2007

                     Figure 1: Data Model Overview

4.2. The Message Classes

 The individual classes are described in the following sections.

4.2.1. The IDMEF-Message Class

 All IDMEF messages are instances of the IDMEF-Message class; it is
 the top-level class of the IDMEF data model, as well as the IDMEF
 DTD.  There are currently two types (subclasses) of IDMEF-Message:
 Alert and Heartbeat.
 The IDMEF-Message class has a single attribute:
 version
    The version of the IDMEF-Message specification (this document)
    this message conforms to.  Applications specifying a value for
    this attribute MUST specify the value "1.0".

4.2.2. The Alert Class

 Generally, every time an analyzer detects an event that it has been
 configured to look for, it sends an Alert message to its manager(s).
 Depending on the analyzer, an Alert message may correspond to a
 single detected event or multiple detected events.  Alerts occur
 asynchronously in response to outside events.
 An Alert message is composed of several aggregate classes, as shown
 in Figure 2.  The aggregate classes themselves are described in
 Section 4.2.4, Section 4.2.5, and Section 4.2.6.

Debar, et al. Experimental [Page 20] RFC 4765 The IDMEF March 2007

            +-------------------+
            |    Alert          |
            +-------------------+            +------------------+
            | STRING messageid  |<>----------|     Analyzer     |
            |                   |            +------------------+
            |                   |            +------------------+
            |                   |<>----------|    CreateTime    |
            |                   |            +------------------+
            |                   |            +------------------+
            |                   |<>----------|  Classification  |
            |                   |            +------------------+
            |                   |       0..1 +------------------+
            |                   |<>----------|    DetectTime    |
            |                   |            +------------------+
            |                   |       0..1 +------------------+
            |                   |<>----------|   AnalyzerTime   |
            |                   |            +------------------+
            |                   |       0..* +------------------+
            |                   |<>----------|      Source      |
            |                   |            +------------------+
            |                   |       0..* +------------------+
            |                   |<>----------|      Target      |
            |                   |            +------------------+
            |                   |       0..1 +------------------+
            |                   |<>----------|    Assessment    |
            |                   |            +------------------+
            |                   |       0..* +------------------+
            |                   |<>----------|  AdditionalData  |
            |                   |            +------------------+
            +-------------------+
                   /_\
                    |
                    +----+------------+-------------+
                         |            |             |
              +-------------------+   |   +-------------------+
              |     ToolAlert     |   |   |  CorrelationAlert |
              +-------------------+   |   +-------------------+
                                      |
                            +-------------------+
                            |   OverflowAlert   |
                            +-------------------+
                       Figure 2: The Alert Class

Debar, et al. Experimental [Page 21] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up Alert are:
 Analyzer
    Exactly one.  Identification information for the analyzer that
    originated the alert.
 CreateTime
    Exactly one.  The time the alert was created.  Of the three times
    that may be provided with an Alert, this is the only one that is
    required.
 Classification
    Exactly one.  The "name" of the alert, or other information
    allowing the manager to determine what it is.
 DetectTime
    Zero or one.  The time the event(s) leading up to the alert was
    detected.  In the case of more than one event, the time the first
    event was detected.  In some circumstances, this may not be the
    same value as CreateTime.
 AnalyzerTime
    Zero or one.  The current time on the analyzer (see Section 6.3).
 Source
    Zero or more.  The source(s) of the event(s) leading up to the
    alert.
 Target
    Zero or more.  The target(s) of the event(s) leading up to the
    alert.
 Assessment
    Zero or one.  Information about the impact of the event, actions
    taken by the analyzer in response to it, and the analyzer's
    confidence in its evaluation.

Debar, et al. Experimental [Page 22] RFC 4765 The IDMEF March 2007

 AdditionalData
    Zero or more.  Information included by the analyzer that does not
    fit into the data model.  This may be an atomic piece of data, or
    a large amount of data provided through an extension to the IDMEF
    (see Section 5).
 Alert is represented in the IDMEF DTD as follows:
 <!ELEMENT Alert                         (
     Analyzer, CreateTime, DetectTime?, AnalyzerTime?,
     Source*, Target*, Classification, Assessment?, (ToolAlert |
     OverflowAlert | CorrelationAlert)?, AdditionalData*
   )>
 <!ATTLIST Alert
     messageid           CDATA                   '0'
     %attlist.global;
   >
 The Alert class has one attribute:
 messageid
    Optional.  A unique identifier for the alert; see Section 3.2.9.

4.2.2.1. The ToolAlert Class

 The ToolAlert class carries additional information related to the use
 of attack tools or malevolent programs such as Trojan horses and can
 be used by the analyzer when it is able to identify these tools.  It
 is intended to group one or more previously-sent alerts together, to
 say "these alerts were all the result of someone using this tool".
 The ToolAlert class is composed of three aggregate classes, as shown
 in Figure 3.

Debar, et al. Experimental [Page 23] RFC 4765 The IDMEF March 2007

           +------------------+
           |      Alert       |
           +------------------+
                   /_\
                    |
           +------------------+
           |    ToolAlert     |
           +------------------+            +-------------------+
           |                  |<>----------|        name       |
           |                  |            +-------------------+
           |                  |       0..1 +-------------------+
           |                  |<>----------|      command      |
           |                  |            +-------------------+
           |                  |       1..* +-------------------+
           |                  |<>----------|    alertident     |
           |                  |            +-------------------+
           |                  |            | STRING analyzerid |
           |                  |            +-------------------+
           +------------------+
                     Figure 3: The ToolAlert Class
 The aggregate classes that make up ToolAlert are:
 name
    Exactly one.  STRING.  The reason for grouping the alerts
    together, for example, the name of a particular tool.
 command
    Zero or one.  STRING.  The command or operation that the tool was
    asked to perform, for example, a BackOrifice ping.
 alertident
    One or more.  STRING.  The list of alert identifiers that are
    related to this alert.  Because alert identifiers are only unique
    across the alerts sent by a single analyzer, the optional
    "analyzerid" attribute of "alertident" should be used to identify
    the analyzer that a particular alert came from.  If the
    "analyzerid" is not provided, the alert is assumed to have come
    from the same analyzer that is sending the ToolAlert.

Debar, et al. Experimental [Page 24] RFC 4765 The IDMEF March 2007

 This is represented in the IDMEF DTD as follows:
 <!ELEMENT ToolAlert                     (
     name, command?, alertident+
   )>
 <!ATTLIST ToolAlert
     %attlist.global;
   >

4.2.2.2. The CorrelationAlert Class

 The CorrelationAlert class carries additional information related to
 the correlation of alert information.  It is intended to group one or
 more previously-sent alerts together, to say "these alerts are all
 related".
 The CorrelationAlert class is composed of two aggregate classes, as
 shown in Figure 4.
           +------------------+
           |      Alert       |
           +------------------+
                   /_\
                    |
           +------------------+
           | CorrelationAlert |
           +------------------+            +-------------------+
           |                  |<>----------|        name       |
           |                  |            +-------------------+
           |                  |       1..* +-------------------+
           |                  |<>----------|    alertident     |
           |                  |            +-------------------+
           |                  |            | STRING analyzerid |
           |                  |            +-------------------+
           +------------------+
                 Figure 4: The CorrelationAlert Class
 The aggregate classes that make up CorrelationAlert are:
 name
    Exactly one.  STRING.  The reason for grouping the alerts
    together, for example, a particular correlation method.

Debar, et al. Experimental [Page 25] RFC 4765 The IDMEF March 2007

 alertident
    One or more.  STRING.  The list of alert identifiers that are
    related to this alert.  Because alert identifiers are only unique
    across the alerts sent by a single analyzer, the optional
    "analyzerid" attribute of "alertident" should be used to identify
    the analyzer that a particular alert came from.  If the
    "analyzerid" is not provided, the alert is assumed to have come
    from the same analyzer that is sending the CorrelationAlert.
 This is represented in the IDMEF DTD as follows.
 <!ELEMENT CorrelationAlert              (
     name, alertident+
   )>
 <!ATTLIST CorrelationAlert
     %attlist.global;
   >

4.2.2.3. The OverflowAlert Class

 The OverflowAlert carries additional information related to buffer
 overflow attacks.  It is intended to enable an analyzer to provide
 the details of the overflow attack itself.
 The OverflowAlert class is composed of three aggregate classes, as
 shown in Figure 5.
                +------------------+
                |      Alert       |
                +------------------+
                        /_\
                         |
                +------------------+
                |  OverflowAlert   |
                +------------------+            +---------+
                |                  |<>----------| program |
                |                  |            +---------+
                |                  |       0..1 +---------+
                |                  |<>----------| size    |
                |                  |            +---------+
                |                  |       0..1 +---------+
                |                  |<>----------| buffer  |
                |                  |            +---------+
                +------------------+
                   Figure 5: The OverflowAlert Class

Debar, et al. Experimental [Page 26] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up OverflowAlert are:
 program
    Exactly one.  STRING.  The program that the overflow attack
    attempted to run (NOTE: this is not the program that was
    attacked).
 size
    Zero or one.  INTEGER.  The size, in bytes, of the overflow (i.e.,
    the number of bytes the attacker sent).
 buffer
    Zero or one.  BYTE[].  Some or all of the overflow data itself
    (dependent on how much the analyzer can capture).
 This is represented in the IDMEF DTD as follows:
 <!ELEMENT OverflowAlert                 (
     program, size?, buffer?
   )>
 <!ATTLIST OverflowAlert
     %attlist.global;
   >

4.2.3. The Heartbeat Class

 Analyzers use Heartbeat messages to indicate their current status to
 managers.  Heartbeats are intended to be sent in a regular period,
 say, every ten minutes or every hour.  The receipt of a Heartbeat
 message from an analyzer indicates to the manager that the analyzer
 is up and running; lack of a Heartbeat message (or more likely, lack
 of some number of consecutive Heartbeat messages) indicates that the
 analyzer or its network connection has failed.
 All managers MUST support the receipt of Heartbeat messages; however,
 the use of these messages by analyzers is OPTIONAL.  Developers of
 manager software SHOULD permit the software to be configured on a
 per-analyzer basis to use/not use Heartbeat messages.
 A Heartbeat message is composed of several aggregate classes, as
 shown in Figure 6.  The aggregate classes themselves are described in
 Sections 4.2.4 and 4.2.5.

Debar, et al. Experimental [Page 27] RFC 4765 The IDMEF March 2007

             +------------------+
             |    Heartbeat     |
             +------------------+            +------------------+
             | STRING messageid |<>----------|     Analyzer     |
             |                  |            +------------------+
             |                  |            +------------------+
             |                  |<>----------|    CreateTime    |
             |                  |            +------------------+
             |                  |       0..1 +------------------+
             |                  |<>----------| HeartbeatInterval|
             |                  |            +------------------+
             |                  |       0..1 +------------------+
             |                  |<>----------|   AnalyzerTime   |
             |                  |            +------------------+
             |                  |       0..* +------------------+
             |                  |<>----------|  AdditionalData  |
             |                  |            +------------------+
             +------------------+
                     Figure 6: The Heartbeat Class
 The aggregate classes that make up Heartbeat are:
 Analyzer
    Exactly one.  Identification information for the analyzer that
    originated the heartbeat.
 CreateTime
    Exactly one.  The time the heartbeat was created.
 HeartbeatInterval
    Zero or one.  The interval in seconds at which heartbeats are
    generated.
 AnalyzerTime
    Zero or one.  The current time on the analyzer (see Section 6.3).
 AdditionalData
    Zero or more.  Information included by the analyzer that does not
    fit into the data model.  This may be an atomic piece of data or a
    large amount of data provided through an extension to the IDMEF
    (see Section 5).

Debar, et al. Experimental [Page 28] RFC 4765 The IDMEF March 2007

 This is represented in the IDMEF DTD as follows:
 <!ELEMENT Heartbeat                     (
     Analyzer, CreateTime, HeartbeatInterval?, AnalyzerTime?,
     AdditionalData*
   )>
 <!ATTLIST Heartbeat
     messageid           CDATA                   '0'
     %attlist.global;
   >
 The Heartbeat class has one attribute:
 messageid
    Optional.  A unique identifier for the heartbeat; see
    Section 3.2.9.

4.2.4. The Core Classes

 The core classes -- Analyzer, Source, Target, Classification, and
 AdditionalData -- are the main parts of Alerts and Heartbeats, as
 shown in Figure 7.
              +-----------+                +----------------+
              | Heartbeat |        +-------|    Analyzer    |
              +-----------+        |       +----------------+
              |           |<>---+--+
              +-----------+     |  |  0..* +----------------+
                                |  +-------| AdditionalData |
                                |          +----------------+
              +-----------+     |
              |   Alert   |     |     0..* +----------------+
              +-----------+     |  +-------|     Source     |
              |           |<>---+  |       +----------------+
              |           |        |  0..* +----------------+
              |           |        +-------|     Target     |
              |           |        |       +----------------+
              |           |<>------+
              +-----------+        |       +----------------+
                                   +-------| Classification |
                                           +----------------+
                      Figure 7: The Core Classes

Debar, et al. Experimental [Page 29] RFC 4765 The IDMEF March 2007

4.2.4.1. The Analyzer Class

 The Analyzer class identifies the analyzer from which the Alert or
 Heartbeat message originates.  Only one analyzer may be encoded for
 each alert or heartbeat, and that MUST be the analyzer at which the
 alert or heartbeat originated.  Although the IDMEF data model does
 not prevent the use of hierarchical intrusion detection systems
 (where alerts get relayed up the tree), it does not provide any way
 to record the identity of the "relay" analyzers along the path from
 the originating analyzer to the manager that ultimately receives the
 alert.
 The Analyzer class is composed of three aggregate classes, as shown
 in Figure 8.
              +---------------------+
              |      Analyzer       |
              +---------------------+       0..1 +----------+
              | STRING analyzerid   |<>----------|  Node    |
              | STRING name         |            +----------+
              | STRING manufacturer |
              | STRING model        |       0..1 +----------+
              | STRING version      |<>----------| Process  |
              | STRING class        |            +----------+
              | STRING ostype       |       0..1 +----------+
              | STRING osversion    |<>----------| Analyzer |
              +---------------------+            +----------+
                     Figure 8: The Analyzer Class
 The aggregate classes that make up Analyzer are:
 Node
    Zero or one.  Information about the host or device on which the
    analyzer resides (network address, network name, etc.).
 Process
    Zero or one.  Information about the process in which the analyzer
    is executing.
 Analyzer
    Zero or one.  Information about the analyzer from which the
    message may have gone through.  The idea behind this mechanism is
    that when a manager receives an alert and wants to forward it to
    another analyzer, it needs to substitute the original analyzer

Debar, et al. Experimental [Page 30] RFC 4765 The IDMEF March 2007

    information with its own.  To preserve the original analyzer
    information, it may be included in the new analyzer definition.
    This will allow analyzer path tracking.
 This is represented in the IDMEF DTD as follows:
 <!ELEMENT Analyzer                      (
     Node?, Process?, Analyzer?
   )>
 <!ATTLIST Analyzer
     analyzerid          CDATA                   '0'
     name                CDATA                   #IMPLIED
     manufacturer        CDATA                   #IMPLIED
     model               CDATA                   #IMPLIED
     version             CDATA                   #IMPLIED
     class               CDATA                   #IMPLIED
     ostype              CDATA                   #IMPLIED
     osversion           CDATA                   #IMPLIED
     %attlist.global;
   >
 The Analyzer class has eight attributes:
 analyzerid
    Optional (but see below).  A unique identifier for the analyzer;
    see Section 3.2.9.
    This attribute is only "partially" optional.  If the analyzer
    makes use of the "ident" attributes on other classes to provide
    unique identifiers for those objects, then it MUST also provide a
    valid "analyzerid" attribute.  This requirement is dictated by the
    uniqueness requirements of the "ident" attribute (they are unique
    only within the context of a particular "analyzerid").  If the
    analyzer does not make use of the "ident" attributes, however, it
    may also omit the "analyzerid" attribute.
 name
    Optional.  An explicit name for the analyzer that may be easier to
    understand than the analyzerid.
 manufacturer
    Optional.  The manufacturer of the analyzer software and/or
    hardware.

Debar, et al. Experimental [Page 31] RFC 4765 The IDMEF March 2007

 model
    Optional.  The model name/number of the analyzer software and/or
    hardware.
 version
    Optional.  The version number of the analyzer software and/or
    hardware.
 class
    Optional.  The class of analyzer software and/or hardware.
 ostype
    Optional.  Operating system name.  On POSIX 1003.1 compliant
    systems, this is the value returned in utsname.sysname by the
    uname() system call, or the output of the "uname -s" command.
 osversion
    Optional.  Operating system version.  On POSIX 1003.1 compliant
    systems, this is the value returned in utsname.release by the
    uname() system call, or the output of the "uname -r" command.
 The "manufacturer", "model", "version", and "class" attributes'
 contents are vendor-specific, but may be used together to identify
 different types of analyzers (and perhaps make determinations about
 the contents to expect in other vendor-specific fields of IDMEF
 messages).

4.2.4.2. The Classification Class

 The Classification class provides the "name" of an alert, or other
 information allowing the manager to determine what it is.  This name
 is chosen by the alert provider.
 The Classification class is composed of one aggregate class, as shown
 in Figure 9.

Debar, et al. Experimental [Page 32] RFC 4765 The IDMEF March 2007

                  +----------------+
                  | Classification |
                  +----------------+       0..* +-----------+
                  | STRING ident   |<>----------| Reference |
                  | STRING text    |            +-----------+
                  +----------------+
                  Figure 9: The Classification Class
 The aggregate class that makes up Classification is:
 Reference
    Zero or more.  Information about the message, pointing to external
    documentation sites, that will provide background information
    about the alert.
 This is represented in the IDMEF DTD as follows:
 <!ELEMENT Classification                (
     Reference*
   )>
 <!ATTLIST Classification
     ident               CDATA                   '0'
     text                CDATA                   #REQUIRED
   >
 The Classification class has two attributes:
 ident
    Optional.  A unique identifier for this classification; see
    Section 3.2.9.
 text
    Required.  A vendor-provided string identifying the Alert message.

4.2.4.3. The Source Class

 The Source class contains information about the possible source(s) of
 the event(s) that generated an alert.  An event may have more than
 one source (e.g., in a distributed denial-of-service attack).
 The Source class is composed of four aggregate classes, as shown in
 Figure 10.

Debar, et al. Experimental [Page 33] RFC 4765 The IDMEF March 2007

                +------------------+
                |      Source      |
                +------------------+       0..1 +---------+
                | STRING ident     |<>----------|  Node   |
                | ENUM spoofed     |            +---------+
                | STRING interface |       0..1 +---------+
                |                  |<>----------|  User   |
                |                  |            +---------+
                |                  |       0..1 +---------+
                |                  |<>----------| Process |
                |                  |            +---------+
                |                  |       0..1 +---------+
                |                  |<>----------| Service |
                |                  |            +---------+
                +------------------+
                      Figure 10: The Source Class
 The aggregate classes that make up Source are:
 Node
    Zero or one.  Information about the host or device that appears to
    be causing the events (network address, network name, etc.).
 User
    Zero or one.  Information about the user that appears to be
    causing the event(s).
 Process
    Zero or one.  Information about the process that appears to be
    causing the event(s).
 Service
    Zero or one.  Information about the network service involved in
    the event(s).

Debar, et al. Experimental [Page 34] RFC 4765 The IDMEF March 2007

 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).

Debar, et al. Experimental [Page 35] RFC 4765 The IDMEF March 2007

 The Target class is composed of four aggregate classes, as shown in
 Figure 11.
                +------------------+
                |      Target      |
                +------------------+       0..1 +----------+
                | STRING ident     |<>----------|   Node   |
                | ENUM decoy       |            +----------+
                | STRING interface |       0..1 +----------+
                |                  |<>----------|   User   |
                |                  |            +----------+
                |                  |       0..1 +----------+
                |                  |<>----------| Process  |
                |                  |            +----------+
                |                  |       0..1 +----------+
                |                  |<>----------| Service  |
                |                  |            +----------+
                |                  |       0..n +----------+
                |                  |<>----------|   File   |
                |                  |            +----------+
                +------------------+
                      Figure 11: The Target Class
 The aggregate classes that make up Target are:
 Node
    Zero or one.  Information about the host or device at which the
    event(s) (network address, network name, etc.) is being directed.
 User
    Zero or one.  Information about the user at which the event(s) is
    being directed.
 Process
    Zero or one.  Information about the process at which the event(s)
    is being directed.
 Service
    Zero or one.  Information about the network service involved in
    the event(s).

Debar, et al. Experimental [Page 36] RFC 4765 The IDMEF March 2007

 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.

Debar, et al. Experimental [Page 37] RFC 4765 The IDMEF March 2007

4.2.4.5. The Assessment Class

 The Assessment class is used to provide the analyzer's assessment of
 an event -- its impact, actions taken in response, and confidence.
 The Assessment class is composed of three aggregate classes, as shown
 in Figure 12.
                +------------------+
                |   Assessment     |
                +------------------+       0..1 +------------+
                |                  |<>----------|   Impact   |
                |                  |            +------------+
                |                  |       0..* +------------+
                |                  |<>----------|   Action   |
                |                  |            +------------+
                |                  |       0..1 +------------+
                |                  |<>----------| Confidence |
                |                  |            +------------+
                +------------------+
                    Figure 12: The Assessment Class
 The aggregate classes that make up Assessment are:
 Impact
    Zero or one.  The analyzer's assessment of the impact of the event
    on the target(s).
 Action
    Zero or more.  The action(s) taken by the analyzer in response to
    the event.
 Confidence
    Zero or one.  A measurement of the confidence the analyzer has in
    its evaluation of the event.
 This is represented in the IDMEF DTD as follows:
 <!ELEMENT Assessment                    (
     Impact?, Action*, Confidence?
   )>
 <!ATTLIST Assessment
     %attlist.global;
   >

Debar, et al. Experimental [Page 38] RFC 4765 The IDMEF March 2007

4.2.4.6. The AdditionalData Class

 The AdditionalData class is used to provide information that cannot
 be represented by the data model.  AdditionalData can be used to
 provide atomic data (integers, strings, etc.) in cases where only
 small amounts of additional information need to be sent; it can also
 be used to extend the data model and the DTD to support the
 transmission of complex data (such as packet headers).  Detailed
 instructions for extending the data model and the DTD are provided in
 Section 5.
 +------+-------------+----------------------------------------------+
 | Rank | Keyword     | Description                                  |
 +------+-------------+----------------------------------------------+
 |    0 | boolean     | The element contains a boolean value, i.e.,  |
 |      |             | the strings "true" or "false"                |
 |      |             |                                              |
 |    1 | byte        | The element content is a single 8-bit byte   |
 |      |             | (see Section 3.2.4)                          |
 |      |             |                                              |
 |    2 | character   | The element content is a single character    |
 |      |             | (see Section 3.2.3)                          |
 |      |             |                                              |
 |    3 | date-time   | The element content is a date-time string    |
 |      |             | (see Section 3.2.6)                          |
 |      |             |                                              |
 |    4 | integer     | The element content is an integer (see       |
 |      |             | Section 3.2.1)                               |
 |      |             |                                              |
 |    5 | ntpstamp    | The element content is an NTP timestamp (see |
 |      |             | Section 3.2.7)                               |
 |      |             |                                              |
 |    6 | portlist    | The element content is a list of ports (see  |
 |      |             | Section 3.2.8)                               |
 |      |             |                                              |
 |    7 | real        | The element content is a real number (see    |
 |      |             | Section 3.2.2)                               |
 |      |             |                                              |
 |    8 | string      | The element content is a string (see         |
 |      |             | Section 3.2.3)                               |
 |      |             |                                              |
 |    9 | byte-string | The element is a byte[] (see Section 3.2.4)  |
 |      |             |                                              |
 |   10 | xmltext     | The element content is XML-tagged data (see  |
 |      |             | Section 5.2)                                 |
 +------+-------------+----------------------------------------------+

Debar, et al. Experimental [Page 39] RFC 4765 The IDMEF March 2007

 The AdditionalData element is declared in the IDMEF DTD as follows:
 <!ENTITY % attvals.adtype               "
     ( boolean | byte | character | date-time | integer | ntpstamp |
       portlist | real | string | byte-string | xmltext )
   ">
 <!ELEMENT AdditionalData           (
   (boolean | byte        | character | date-time |
    integer | ntpstamp    | portlist  | real      |
    string  | byte-string | xmltext  )
  )>
 <!ATTLIST AdditionalData
     type                %attvals.adtype;        'string'
     meaning             CDATA                   #IMPLIED
     %attlist.global;
   >
 The AdditionalData class has one attribute:
 meaning
    Optional.  A string describing the meaning of the element content.
    These values will be vendor/implementation dependent; the method
    for ensuring that managers understand the strings sent by
    analyzers is outside the scope of this specification.  A list of
    acceptable meaning keywords is not within the scope of the
    document, although later versions may undertake to establish such
    a list.

Debar, et al. Experimental [Page 40] RFC 4765 The IDMEF March 2007

4.2.5. The Time Classes

 The data model provides three classes for representing time.  These
 classes are elements of the Alert and Heartbeat classes.
 The time classes are represented in the IDMEF DTD as follows:
 <!ELEMENT ntpstamp          (#PCDATA)         >
 <!ATTLIST ntpstamp          %attlist.global;  >
 <!ELEMENT CreateTime          (#PCDATA) >
 <!ATTLIST CreateTime
     ntpstamp            CDATA                   #REQUIRED
     %attlist.global;
   >
 <!ELEMENT DetectTime          (#PCDATA) >
 <!ATTLIST DetectTime
     ntpstamp            CDATA                   #REQUIRED
     %attlist.global;
   >
 <!ELEMENT AnalyzerTime        (#PCDATA) >
 <!ATTLIST AnalyzerTime
     ntpstamp            CDATA                   #REQUIRED
     %attlist.global;
   >
 The DATETIME format of the <CreateTime> element content is described
 in Section 3.2.6.
 If the date and time represented by the element content and the NTP
 timestamp differ (should "never" happen), the value in the NTP
 timestamp MUST be used.

4.2.5.1. The CreateTime Class

 The CreateTime class is used to indicate the date and time the alert
 or heartbeat was created by the analyzer.

4.2.5.2. The DetectTime Class

 The DetectTime class is used to indicate the date and time that the
 event(s) producing an alert was detected by the analyzer.  In the
 case of more than one event, it is the time that the first event was
 detected.  (This may or may not be the same time as CreateTime;
 analyzers are not required to send alerts immediately upon
 detection).

Debar, et al. Experimental [Page 41] RFC 4765 The IDMEF March 2007

4.2.5.3. The AnalyzerTime Class

 The AnalyzerTime class is used to indicate the current date and time
 on the analyzer.  Its values should be filled in as late as possible
 in the message transmission process, ideally immediately before
 placing the message "on the wire".
 The use of <AnalyzerTime> to perform rudimentary time synchronization
 between analyzers and managers is discussed in Section 6.3.

4.2.6. The Assessment Classes

 The data model provides three types of "assessments" that an analyzer
 can make about an event.  These classes are aggregates of the
 Assessment class.

4.2.6.1. The Impact Class

 The Impact class is used to provide the analyzer's assessment of the
 impact of the event on the target(s).  It is represented in the IDMEF
 DTD as follows:
 <!ENTITY % attvals.severity             "
     ( info | low | medium | high )
   ">
 <!ENTITY % attvals.completion           "
     ( failed | succeeded )
   ">
 <!ENTITY % attvals.impacttype           "
     ( admin | dos | file | recon | user | other )
   ">
 <!ELEMENT Impact              (#PCDATA) >
 <!ATTLIST Impact
     severity            %attvals.severity;      #IMPLIED
     completion          %attvals.completion;    #IMPLIED
     type                %attvals.impacttype;    'other'
     %attlist.global;
   >

Debar, et al. Experimental [Page 42] RFC 4765 The IDMEF March 2007

 The Impact class has three attributes:
 severity
    An estimate of the relative severity of the event.  The permitted
    values are shown below.  There is no default value.  (See also
    Section 10.)
     +------+---------+-----------------------------------------+
     | Rank | Keyword | Description                             |
     +------+---------+-----------------------------------------+
     |    0 | info    | Alert represents informational activity |
     |      |         |                                         |
     |    1 | low     | Low severity                            |
     |      |         |                                         |
     |    2 | medium  | Medium severity                         |
     |      |         |                                         |
     |    3 | high    | High severity                           |
     +------+---------+-----------------------------------------+
 completion
    An indication of whether the analyzer believes the attempt that
    the event describes was successful or not.  The permitted values
    are shown below.  There is no default value.  (See also
    Section 10.)
         +------+-----------+--------------------------------+
         | Rank | Keyword   | Description                    |
         +------+-----------+--------------------------------+
         |    0 | failed    | The attempt was not successful |
         |      |           |                                |
         |    1 | succeeded | The attempt succeeded          |
         +------+-----------+--------------------------------+

Debar, et al. Experimental [Page 43] RFC 4765 The IDMEF March 2007

 type
    The type of attempt represented by this event, in relatively broad
    categories.  The permitted values are shown below.  The default
    value is "other".  (See also Section 10.)
 +------+---------+--------------------------------------------------+
 | Rank | Keyword | Description                                      |
 +------+---------+--------------------------------------------------+
 |    0 | admin   | Administrative privileges were attempted or      |
 |      |         | obtained                                         |
 |      |         |                                                  |
 |    1 | dos     | A denial of service was attempted or completed   |
 |      |         |                                                  |
 |    2 | file    | An action on a file was attempted or completed   |
 |      |         |                                                  |
 |    3 | recon   | A reconnaissance probe was attempted or          |
 |      |         | completed                                        |
 |      |         |                                                  |
 |    4 | user    | User privileges were attempted or obtained       |
 |      |         |                                                  |
 |    5 | other   | Anything not in one of the above categories      |
 +------+---------+--------------------------------------------------+
 All three attributes are optional.  The element itself may be empty,
 or may contain a textual description of the impact, if the analyzer
 is able to provide additional details.

4.2.6.2. The Action Class

 The Action class is used to describe any actions taken by the
 analyzer in response to the event.  Is is represented in the IDMEF
 DTD as follows:
 <!ENTITY % attvals.actioncat            "
     ( block-installed | notification-sent | taken-offline | other )
   ">
 <!ELEMENT Action              (#PCDATA) >
 <!ATTLIST Action
     category            %attvals.actioncat;     'other'
     %attlist.global;
   >

Debar, et al. Experimental [Page 44] RFC 4765 The IDMEF March 2007

 Action has one attribute:
 category
    The type of action taken.  The permitted values are shown below.
    The default value is "other".  (See also Section 10.)
 +------+-------------------+----------------------------------------+
 | Rank | Keyword           | Description                            |
 +------+-------------------+----------------------------------------+
 |    0 | block-installed   | A block of some sort was installed to  |
 |      |                   | prevent an attack from reaching its    |
 |      |                   | destination.  The block could be a     |
 |      |                   | port block, address block, etc., or    |
 |      |                   | disabling a user account.              |
 |      |                   |                                        |
 |    1 | notification-sent | A notification message of some sort    |
 |      |                   | was sent out-of-band (via pager,       |
 |      |                   | e-mail, etc.).  Does not include the   |
 |      |                   | transmission of this alert.            |
 |      |                   |                                        |
 |    2 | taken-offline     | A system, computer, or user was taken  |
 |      |                   | offline, as when the computer is shut  |
 |      |                   | down or a user is logged off.          |
 |      |                   |                                        |
 |    3 | other             | Anything not in one of the above       |
 |      |                   | categories.                            |
 +------+-------------------+----------------------------------------+
    The element itself may be empty, or may contain a textual
    description of the action, if the analyzer is able to provide
    additional details.

4.2.6.3. The Confidence Class

 The Confidence class is used to represent the analyzer's best
 estimate of the validity of its analysis.  It is represented in the
 IDMEF DTD as follows:
 <!ENTITY % attvals.rating               "
     ( low | medium | high | numeric )
   ">
 <!ELEMENT Confidence          (#PCDATA) >
 <!ATTLIST Confidence
     rating              %attvals.rating;        'numeric'
     %attlist.global;
   >

Debar, et al. Experimental [Page 45] RFC 4765 The IDMEF March 2007

 The Confidence class has one attribute:
 rating
    The analyzer's rating of its analytical validity.  The permitted
    values are shown below.  The default value is "numeric".  (See
    also Section 10.)
 +------+---------+--------------------------------------------------+
 | Rank | Keyword | Description                                      |
 +------+---------+--------------------------------------------------+
 |    0 | low     | The analyzer has little confidence in its        |
 |      |         | validity                                         |
 |      |         |                                                  |
 |    1 | medium  | The analyzer has average confidence in its       |
 |      |         | validity                                         |
 |      |         |                                                  |
 |    2 | high    | The analyzer has high confidence in its validity |
 |      |         |                                                  |
 |    3 | numeric | The analyzer has provided a posterior            |
 |      |         | probability value indicating its confidence in   |
 |      |         | its validity                                     |
 +------+---------+--------------------------------------------------+
 This element should be used only when the analyzer can produce
 meaningful information.  Systems that can output only a rough
 heuristic should use "low", "medium", or "high" as the rating value.
 In this case, the element content should be omitted.
 Systems capable of producing reasonable probability estimates should
 use "numeric" as the rating value and include a numeric confidence
 value in the element content.  This numeric value should reflect a
 posterior probability (the probability that an attack has occurred
 given the data seen by the detection system and the model used by the
 system).  It is a floating point number between 0.0 and 1.0,
 inclusive.  The number of digits should be limited to those
 representable by a single precision floating point value, and may be
 represented as described in Section 3.2.2.
 NOTE:  It should be noted that different types of analyzers may
    compute confidence values in different ways and that in many
    cases, confidence values from different analyzers should not be
    compared (for example, if the analyzers use different methods of
    computing or representing confidence, or are of different types or
    configurations).  Care should be taken when implementing systems
    that process confidence values (such as event correlators) not to
    make comparisons or assumptions that cannot be supported by the
    system's knowledge of the environment in which it is working.

Debar, et al. Experimental [Page 46] RFC 4765 The IDMEF March 2007

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 13.
                  +----------------+
                  | Reference      |
                  +----------------+            +------+
                  | STRING origin  |<>----------| name |
                  | STRING meaning |            +------+
                  |                |            +------+
                  |                |<>----------| url  |
                  |                |            +------+
                  +----------------+
                    Figure 13: 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.

Debar, et al. Experimental [Page 47] RFC 4765 The IDMEF March 2007

 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.)
 +------+-----------------+------------------------------------------+
 | Rank | Keyword         | Description                              |
 +------+-----------------+------------------------------------------+
 |    0 | unknown         | Origin of the name is not known          |
 |      |                 |                                          |
 |    1 | vendor-specific | A vendor-specific name (and hence, URL); |
 |      |                 | this can be used to provide              |
 |      |                 | product-specific information             |
 |      |                 |                                          |
 |    2 | user-specific   | A user-specific name (and hence, URL);   |
 |      |                 | this can be used to provide              |
 |      |                 | installation-specific information        |
 |      |                 |                                          |
 |    3 | bugtraqid       | The SecurityFocus ("Bugtraq")            |
 |      |                 | vulnerability database identifier        |
 |      |                 | (http://www.securityfocus.com/bid)       |
 |      |                 |                                          |
 |    4 | cve             | The Common Vulnerabilities and Exposures |
 |      |                 | (CVE) name (http://www.cve.mitre.org/)   |
 |      |                 |                                          |
 |    5 | osvdb           | The Open Source Vulnerability Database   |
 |      |                 | (http://www.osvdb.org)                   |
 +------+-----------------+------------------------------------------+

Debar, et al. Experimental [Page 48] RFC 4765 The IDMEF March 2007

 meaning
    Optional.  The meaning of the reference, as understood by the
    alert provider.  This field is only valid if the value of the
    <origin> attribute is set to "vendor-specific" or "user-specific".

4.2.7.2. The Node Class

 The Node class is used to identify hosts and other network devices
 (routers, switches, etc.).
 The Node class is composed of three aggregate classes, as shown in
 Figure 14.
                 +---------------+
                 |     Node      |
                 +---------------+       0..1 +----------+
                 | STRING ident  |<>----------| location |
                 | ENUM category |            +----------+
                 |               |       0..1 +----------+
                 |               |<>----------|   name   |
                 |               |            +----------+
                 |               |       0..* +----------+
                 |               |<>----------|  Address |
                 |               |            +----------+
                 +---------------+
                       Figure 14: The Node Class
 The aggregate classes that make up Node are:
 location
    Zero or one.  STRING.  The location of the equipment.
 name
    Zero or one.  STRING.  The name of the equipment.  This
    information MUST be provided if no Address information is given.
 Address
    Zero or more.  The network or hardware address of the equipment.
    Unless a name (above) is provided, at least one address must be
    specified.

Debar, et al. Experimental [Page 49] RFC 4765 The IDMEF March 2007

 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.nodecat              "
     ( unknown | ads | afs | coda | dfs | dns | hosts | kerberos |
       nds | nis | nisplus | nt | wfw )
   ">
 <!ELEMENT Node                          (
     location?, (name | Address), Address*
   )>
 <!ATTLIST Node
     ident               CDATA                   '0'
     category            %attvals.nodecat;       'unknown'
     %attlist.global;
   >

Debar, et al. Experimental [Page 50] RFC 4765 The IDMEF March 2007

 The Node class has two attributes:
 ident
    Optional.  A unique identifier for the node; see Section 3.2.9.
 category
    Optional.  The "domain" from which the name information was
    obtained, if relevant.  The permitted values for this attribute
    are shown in the table below.  The default value is "unknown".
    (See also Section 10 for extensions to the table.)
    +------+----------+------------------------------------------+
    | Rank | Keyword  | Description                              |
    +------+----------+------------------------------------------+
    |    0 | unknown  | Domain unknown or not relevant           |
    |      |          |                                          |
    |    1 | ads      | Windows 2000 Advanced Directory Services |
    |      |          |                                          |
    |    2 | afs      | Andrew File System (Transarc)            |
    |      |          |                                          |
    |    3 | coda     | Coda Distributed File System             |
    |      |          |                                          |
    |    4 | dfs      | Distributed File System (IBM)            |
    |      |          |                                          |
    |    5 | dns      | Domain Name System                       |
    |      |          |                                          |
    |    6 | hosts    | Local hosts file                         |
    |      |          |                                          |
    |    7 | kerberos | Kerberos realm                           |
    |      |          |                                          |
    |    8 | nds      | Novell Directory Services                |
    |      |          |                                          |
    |    9 | nis      | Network Information Services (Sun)       |
    |      |          |                                          |
    |   10 | nisplus  | Network Information Services Plus (Sun)  |
    |      |          |                                          |
    |   11 | nt       | Windows NT domain                        |
    |      |          |                                          |
    |   12 | wfw      | Windows for Workgroups                   |
    +------+----------+------------------------------------------+

Debar, et al. Experimental [Page 51] RFC 4765 The IDMEF March 2007

4.2.7.2.1. The Address Class

 The Address class is used to represent network, hardware, and
 application addresses.
 The Address class is composed of two aggregate classes, as shown in
 Figure 15.
                +------------------+
                |     Address      |
                +------------------+            +---------+
                | STRING ident     |<>----------| address |
                | ENUM category    |            +---------+
                | STRING vlan-name |       0..1 +---------+
                | INTEGER vlan-num |<>----------| netmask |
                |                  |            +---------+
                +------------------+
                     Figure 15: The Address Class
 The aggregate classes that make up Address are:
 address
    Exactly one.  STRING.  The address information.  The format of
    this data is governed by the category attribute.
 netmask
    Zero or one.  STRING.  The network mask for the address, if
    appropriate.

Debar, et al. Experimental [Page 52] RFC 4765 The IDMEF March 2007

 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.addrcat              "
     ( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
       ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
       ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask )
   ">
 <!ELEMENT Address                       (
     address, netmask?
   )>
 <!ATTLIST Address
     ident               CDATA                   '0'
     category            %attvals.addrcat;       'unknown'
     vlan-name           CDATA                   #IMPLIED
     vlan-num            CDATA                   #IMPLIED
     %attlist.global;
   >
 The Address class has four attributes:
 ident
    Optional.  A unique identifier for the address; see Section 3.2.9.
 category
    Optional.  The type of address represented.  The permitted values
    for this attribute are shown below.  The default value is
    "unknown".  (See also Section 10.)

Debar, et al. Experimental [Page 53] RFC 4765 The IDMEF March 2007

 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | unknown       | Address type unknown                       |
 |      |               |                                            |
 |    1 | atm           | Asynchronous Transfer Mode network address |
 |      |               |                                            |
 |    2 | e-mail        | Electronic mail address (RFC 2822 [12])    |
 |      |               |                                            |
 |    3 | lotus-notes   | Lotus Notes e-mail address                 |
 |      |               |                                            |
 |    4 | mac           | Media Access Control (MAC) address         |
 |      |               |                                            |
 |    5 | sna           | IBM Shared Network Architecture (SNA)      |
 |      |               | address                                    |
 |      |               |                                            |
 |    6 | vm            | IBM VM ("PROFS") e-mail address            |
 |      |               |                                            |
 |    7 | ipv4-addr     | IPv4 host address in dotted-decimal        |
 |      |               | notation (a.b.c.d)                         |
 |      |               |                                            |
 |    8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation  |
 |      |               |                                            |
 |    9 | ipv4-net      | IPv4 network address in dotted-decimal     |
 |      |               | notation, slash, significant bits          |
 |      |               | (a.b.c.d/nn)                               |
 |      |               |                                            |
 |   10 | ipv4-net-mask | IPv4 network address in dotted-decimal     |
 |      |               | notation, slash, network mask in           |
 |      |               | dotted-decimal notation (a.b.c.d/w.x.y.z)  |
 |      |               |                                            |
 |   11 | ipv6-addr     | IPv6 host address                          |
 |      |               |                                            |
 |   12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation  |
 |      |               |                                            |
 |   13 | ipv6-net      | IPv6 network address, slash, significant   |
 |      |               | bits                                       |
 |      |               |                                            |
 |   14 | ipv6-net-mask | IPv6 network address, slash, network mask  |
 +------+---------------+--------------------------------------------+
 vlan-name
    Optional.  The name of the Virtual LAN to which the address
    belongs.

Debar, et al. Experimental [Page 54] RFC 4765 The IDMEF March 2007

 vlan-num
    Optional.  The number of the Virtual LAN to which the address
    belongs.

4.2.7.3. The User Class

 The User class is used to describe users.  It is primarily used as a
 "container" class for the UserId aggregate class, as shown in
 Figure 16.
             +---------------+
             |     User      |
             +---------------+       1..* +--------+
             | STRING ident  |<>----------| UserId |
             | ENUM category |            +--------+
             +---------------+
                       Figure 16: The User Class
 The aggregate class contained in User is:
 UserId
    One or more.  Identification of a user, as indicated by its type
    attribute (see Section 4.2.7.3.1).
 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.usercat              "
     ( unknown | application | os-device )
   ">
 <!ELEMENT User                          (
     UserId+
   )>
 <!ATTLIST User
     ident               CDATA                   '0'
     category            %attvals.usercat;       'unknown'
     %attlist.global;
   >

Debar, et al. Experimental [Page 55] RFC 4765 The IDMEF March 2007

 The User class has two attributes:
 ident
    Optional.  A unique identifier for the user; see Section 3.2.9.
 category
    Optional.  The type of user represented.  The permitted values for
    this attribute are shown below.  The default value is "unknown".
    (See also Section 10.)
      +------+-------------+------------------------------------+
      | Rank | Keyword     | Description                        |
      +------+-------------+------------------------------------+
      |    0 | unknown     | User type unknown                  |
      |      |             |                                    |
      |    1 | application | An application user                |
      |      |             |                                    |
      |    2 | os-device   | An operating system or device user |
      +------+-------------+------------------------------------+

4.2.7.3.1. The UserId Class

 The UserId class provides specific information about a user.  More
 than one UserId can be used within the User class to indicate
 attempts to transition from one user to another, or to provide
 complete information about a user's (or process') privileges.
 The UserId class is composed of two aggregate classes, as shown in
 Figure 17.
                    +--------------+
                    |    UserId    |
                    +--------------+       0..1 +--------+
                    | STRING ident |<>----------|  name  |
                    | ENUM type    |            +--------+
                    | STRING tty   |       0..1 +--------+
                    |              |<>----------| number |
                    |              |            +--------+
                    +--------------+
                      Figure 17: The UserId Class

Debar, et al. Experimental [Page 56] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up UserId are:
 name
    Zero or one.  STRING.  A user or group name.
 number
    Zero or one.  INTEGER.  A user or group number.
 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.idtype               "
     ( current-user | original-user | target-user | user-privs |
       current-group | group-privs | other-privs )
   ">
 <!ELEMENT UserId                        (
     (name, number?) | (number, name?)
   )>
 <!ATTLIST UserId
     ident               CDATA                   '0'
     type                %attvals.idtype;        'original-user'
     tty                 CDATA                   #IMPLIED
     %attlist.global;
   >
 The UserId class has three attributes:
 ident
    Optional.  A unique identifier for the user id, see Section 3.2.9.
 type
    Optional.  The type of user information represented.  The
    permitted values for this attribute are shown below.  The default
    value is "original-user".  (See also Section 10.)

Debar, et al. Experimental [Page 57] RFC 4765 The IDMEF March 2007

 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | current-user  | The current user id being used by the user |
 |      |               | or process.  On Unix systems, this would   |
 |      |               | be the "real" user id, in general.         |
 |      |               |                                            |
 |    1 | original-user | The actual identity of the user or process |
 |      |               | being reported on.  On those systems that  |
 |      |               | (a) do some type of auditing and (b)       |
 |      |               | support extracting a user id from the      |
 |      |               | "audit id" token, that value should be     |
 |      |               | used.  On those systems that do not        |
 |      |               | support this, and where the user has       |
 |      |               | logged into the system, the "login id"     |
 |      |               | should be used.                            |
 |      |               |                                            |
 |    2 | target-user   | The user id the user or process is         |
 |      |               | attempting to become.  This would apply,   |
 |      |               | on Unix systems for example, when the user |
 |      |               | attempts to use "su", "rlogin", "telnet",  |
 |      |               | etc.                                       |
 |      |               |                                            |
 |    3 | user-privs    | Another user id the user or process has    |
 |      |               | the ability to use, or a user id           |
 |      |               | associated with a file permission.  On     |
 |      |               | Unix systems, this would be the            |
 |      |               | "effective" user id in a user or process   |
 |      |               | context, and the owner permissions in a    |
 |      |               | file context.  Multiple UserId elements of |
 |      |               | this type may be used to specify a list of |
 |      |               | privileges.                                |
 |      |               |                                            |
 |    4 | current-group | The current group id (if applicable) being |
 |      |               | used by the user or process.  On Unix      |
 |      |               | systems, this would be the "real" group    |
 |      |               | id, in general.                            |
 |      |               |                                            |
 |    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            |
 |      |               | "effective" 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".             |

Debar, et al. Experimental [Page 58] RFC 4765 The IDMEF March 2007

 |    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 18.
                   +--------------+
                   |    Process   |
                   +--------------+            +------+
                   | STRING ident |<>----------| name |
                   |              |            +------+
                   |              |       0..1 +------+
                   |              |<>----------| pid  |
                   |              |            +------+
                   |              |       0..1 +------+
                   |              |<>----------| path |
                   |              |            +------+
                   |              |       0..* +------+
                   |              |<>----------| arg  |
                   |              |            +------+
                   |              |       0..* +------+
                   |              |<>----------| env  |
                   |              |            +------+
                   +--------------+
                     Figure 18: The Process Class

Debar, et al. Experimental [Page 59] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up Process are:
 name
    Exactly one.  STRING.  The name of the program being executed.
    This is a short name; path and argument information are provided
    elsewhere.
 pid
    Zero or one.  INTEGER.  The process identifier of the process.
 path
    Zero or one.  STRING.  The full path of the program being
    executed.
 arg
    Zero or more.  STRING.  A command-line argument to the program.
    Multiple arguments may be specified (they are assumed to have
    occurred in the same order they are provided) with multiple uses
    of arg.
 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.

Debar, et al. Experimental [Page 60] RFC 4765 The IDMEF March 2007

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 19.
          +-----------------------------+
          |   Service                   |
          +-----------------------------+       0..1 +----------+
          | STRING  ident               |<>----------|   name   |
          | INTEGER ip_version          |            +----------+
          | INTEGER iana_protocol_number|       0..1 +----------+
          | STRING  iana_protocol_name  |<>----------|   port   |
          |                             |            +----------+
          |                             |       0..1 +----------+
          |                             |<>----------| portlist |
          |                             |            +----------+
          |                             |       0..1 +----------+
          |                             |<>----------| protocol |
          |                             |            +----------+
          +-----------------------------+
                          /_\
                           |
                 +---------+--------+
                 |                  |
          +-------------+     +-------------+
          | SNMPService |     | WebService  |
          +-------------+     +-------------+
                     Figure 19: The Service Class

Debar, et al. Experimental [Page 61] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up Service are:
 name
    Zero or one.  STRING.  The name of the service.  Whenever
    possible, the name from the IANA list of well-known ports SHOULD
    be used.
 port
    Zero or one.  INTEGER.  The port number being used.
 portlist
    Zero or one.  PORTLIST.  A list of port numbers being used; see
    Section 3.2.8 for formatting rules.  If a portlist is given, the
    iana_protocol_number and iana_protocol_name MUST apply to all the
    elements of the list.
 protocol
    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;
   >

Debar, et al. Experimental [Page 62] RFC 4765 The IDMEF March 2007

 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
 in Figure 20.
                 +-------------+
                 |   Service   |
                 +-------------+
                       /_\
                        |
                 +-------------+
                 | WebService  |
                 +-------------+            +-------------+
                 |             |<>----------|     url     |
                 |             |            +-------------+
                 |             |       0..1 +-------------+
                 |             |<>----------|     cgi     |
                 |             |            +-------------+
                 |             |       0..1 +-------------+
                 |             |<>----------| http-method |
                 |             |            +-------------+
                 |             |       0..* +-------------+
                 |             |<>----------|     arg     |
                 |             |            +-------------+
                 +-------------+
                    Figure 20: The WebService Class

Debar, et al. Experimental [Page 63] RFC 4765 The IDMEF March 2007

 The aggregate classes that make up WebService are:
 url
    Exactly one.  STRING.  The URL in the request.
 cgi
    Zero or one.  STRING.  The CGI script in the request, without
    arguments.
 http-method
    Zero or one.  STRING.  The HTTP method (PUT, GET) used in the
    request.
 arg
    Zero or more.  STRING.  The arguments to the CGI script.
 This is represented in the IDMEF DTD as follows:
 <!ELEMENT WebService                    (
     url, cgi?, http-method?, arg*
   )>
 <!ATTLIST WebService
     %attlist.global;
   >

4.2.7.5.2. The SNMPService Class

 The SNMPService class carries additional information related to SNMP
 traffic.  The aggregate classes composing SNMPService must be
 interpreted as described in RFC 3411 [15] and RFC 3584 [16].
 The SNMPService class is composed of eight aggregate classes, as
 shown in Figure 21.

Debar, et al. Experimental [Page 64] RFC 4765 The IDMEF March 2007

              +-------------+
              |   Service   |
              +-------------+
                    /_\
                     |
              +-------------+
              | SNMPService |
              +-------------+       0..1 +----------------------+
              |             |<>----------|       oid            |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|messageProcessingModel|
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|    securityModel     |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|    securityName      |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|   securityLevel      |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|    contextName       |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|   contextEngineID    |
              |             |            +----------------------+
              |             |       0..1 +----------------------+
              |             |<>----------|     command          |
              |             |            +----------------------+
              +-------------+
                   Figure 21: The SNMPService Class
 The aggregate classes that make up SNMPService are:
 oid
    Zero or one.  STRING.  The object identifier in the request.
 messageProcessingModel
    Zero or one.  INTEGER.  The SNMP version, typically 0 for SNMPv1,
    1 for SNMPv2c, 2 for SNMPv2u and SNMPv2*, and 3 for SNMPv3; see
    RFC 3411 [15] Section 5 for appropriate values.

Debar, et al. Experimental [Page 65] RFC 4765 The IDMEF March 2007

 securityModel
    Zero or one.  INTEGER.  The identification of the security model
    in use, typically 0 for any, 1 for SNMPv1, 2 for SNMPv2c, and 3
    for USM; see RFC 3411 [15] Section 5 for appropriate values.
 securityName
    Zero or one.  STRING.  The object's security name; see RFC 3411
    [15] Section 3.2.2.
 securityLevel
    Zero or one.  INTEGER.  The security level of the SNMP request;
    see RFC 3411 [15] Section 3.4.3.
 contextName
    Zero or one.  STRING.  The object's context name; see RFC 3411
    [15] Section 3.3.3.
 contextEngineID
    Zero or one.  STRING.  The object's context engine identifier; see
    RFC 3411 [15] 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 [15] 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. Experimental [Page 66] RFC 4765 The IDMEF March 2007

4.2.7.6. The File Class

 The File class provides specific information about a file or other
 file-like object that has been created, deleted, or modified on the
 target.  The description can provide either the file settings prior
 to the event or the file settings at the time of the event, as
 specified using the "category" attribute.
 The File class is composed of eleven aggregate classes, as shown in
 Figure 22.
                +--------------+
                |     File     |
                +--------------+            +-------------+
                |              |<>----------|    name     |
                |              |            +-------------+
                |              |            +-------------+
                |              |<>----------|    path     |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------| create-time |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------| modify-time |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------| access-time |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------|  data-size  |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------|  disk-size  |
                |              |            +-------------+
                |              |       0..* +-------------+
                |              |<>----------| FileAccess  |
                |              |            +-------------+
                |              |       0..* +-------------+
                |              |<>----------|   Linkage   |
                |              |            +-------------+
                |              |       0..1 +-------------+
                |              |<>----------|    Inode    |
                |              |            +-------------+
                |              |       0..* +-------------+
                |              |<>----------|  Checksum   |
                |              |            +-------------+
                +--------------+
                       Figure 22: The File Class

Debar, et al. Experimental [Page 67] RFC 4765 The IDMEF March 2007

 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 corresponds to Valid Data Length (VDL).

Debar, et al. Experimental [Page 68] RFC 4765 The IDMEF March 2007

 disk-size
    Zero or one.  INTEGER.  The physical space on disk consumed by the
    file, in bytes.  On Unix UFS file systems, this value corresponds
    to 512 * stat.st_blocks.  On Windows NTFS, this value corresponds
    to End of File (EOF).
 FileAccess
    Zero or more.  Access permissions on the file.
 Linkage
    Zero or more.  File system objects to which this file is linked
    (other references for the file).
 Inode
    Zero or one.  Inode information for this file (relevant to Unix).
 Checksum
    Zero or more.  Checksum information for this file.
 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.filecat              "
     ( current | original )
   ">
 <!ELEMENT File                          (
     name, path, create-time?, modify-time?, access-time?,
     data-size?, disk-size?, FileAccess*, Linkage*, Inode?,
     Checksum*
   )>
 <!ATTLIST File
     ident               CDATA                   '0'
     category            %attvals.filecat;       #REQUIRED
     fstype              CDATA                   #IMPLIED
     file-type           CDATA                   #IMPLIED
     %attlist.global;
   >
 The File class has four attributes (one required and three optional):
 ident
    Optional.  A unique identifier for this file; see Section 3.2.9.

Debar, et al. Experimental [Page 69] RFC 4765 The IDMEF March 2007

 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.
              +------+---------+-------------------------------------+
              | Rank | Keyword | Description                         |
              +------+---------+-------------------------------------+
              |    0 | ufs     | Berkeley Unix Fast File System      |
              |    1 | efs     | Linux "efs" file system             |
              |    2 | nfs     | Network File System                 |
              |    3 | afs     | Andrew File System                  |
              |    4 | ntfs    | Windows NT File System              |
              |    5 | fat16   | 16-bit Windows FAT File System      |
              |    6 | fat32   | 32-bit Windows FAT File System      |
              |    7 | pcfs    | "PC" (MS-DOS) file system on CD-ROM |
              |    8 | joliet  | Joliet CD-ROM file system           |
              |    9 | iso9660 | ISO 9660 CD-ROM file system         |
              +------+---------+-------------------------------------+
 file-type
    Optional.  The type of file, as a mime-type.

Debar, et al. Experimental [Page 70] RFC 4765 The IDMEF March 2007

4.2.7.6.1. The FileAccess Class

 The FileAccess class represents the access permissions on a file.
 The representation is intended to be useful across operating systems.
 The FileAccess class is composed of two aggregate classes, as shown
 in Figure 23.
                +--------------+
                |  FileAccess  |
                +--------------+            +------------+
                |              |<>----------|   UserId   |
                |              |            +------------+
                |              |       1..* +------------+
                |              |<>----------| Permission |
                |              |            +------------+
                +--------------+
                    Figure 23: The FileAccess Class
 The aggregate classes that make up FileAccess are:
 UserId
    Exactly one.  The user (or group) to which these permissions
    apply.  The value of the "type" attribute must be "user-privs",
    "group-privs", or "other-privs" as appropriate.  Other values for
    "type" MUST NOT be used in this context.

Debar, et al. Experimental [Page 71] RFC 4765 The IDMEF March 2007

 Permission
    One or more.  ENUM.  Level of access allowed.  The permitted
    values are shown below.  There is no default value.  (See also
    Section 10.)
 +------+-------------------+----------------------------------------+
 | Rank | Keyword           | Description                            |
 +------+-------------------+----------------------------------------+
 |    0 | noAccess          | No access at all is allowed for this   |
 |      |                   | user                                   |
 |      |                   |                                        |
 |    1 | read              | This user has read access to the file  |
 |      |                   |                                        |
 |    2 | write             | This user has write access to the file |
 |      |                   |                                        |
 |    3 | execute           | This user has the ability to execute   |
 |      |                   | the file                               |
 |      |                   |                                        |
 |    4 | search            | This user has the ability to search    |
 |      |                   | this file (applies to "execute"        |
 |      |                   | permission on directories in Unix)     |
 |      |                   |                                        |
 |    5 | delete            | This user has the ability to delete    |
 |      |                   | this file                              |
 |      |                   |                                        |
 |    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.

Debar, et al. Experimental [Page 72] RFC 4765 The IDMEF March 2007

 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 24.
                +--------------+
                |   Linkage    |
                +--------------+            +------+
                |              |<>----------| name |
                |              |            +------+
                |              |            +------+
                |              |<>----------| path |
                |              |            +------+
                |              |            +------+
                |              |<>----------| File |
                |              |            +------+
                +--------------+
                     Figure 24: 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.

Debar, et al. Experimental [Page 73] RFC 4765 The IDMEF March 2007

 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.
 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.linkcat              "
     ( hard-link | mount-point | reparse-point | shortcut | stream |
       symbolic-link )
   ">
 <!ELEMENT Linkage                       (
     (name, path) | File
   )>
 <!ATTLIST Linkage
     category            %attvals.linkcat;       #REQUIRED
     %attlist.global;
   >

Debar, et al. Experimental [Page 74] RFC 4765 The IDMEF March 2007

 The Linkage class has one attribute:
 category
    The type of object that the link describes.  The permitted values
    are shown below.  There is no default value.  (See also
    Section 10.)
 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | hard-link     | The <name> element represents another name |
 |      |               | for this file.  This information may be    |
 |      |               | more easily obtainable on NTFS file        |
 |      |               | systems than others.                       |
 |      |               |                                            |
 |    1 | mount-point   | An alias for the directory specified by    |
 |      |               | the parent's <name> and <path> elements.   |
 |      |               |                                            |
 |    2 | reparse-point | Applies only to Windows; excludes symbolic |
 |      |               | links and mount points, which are specific |
 |      |               | types of reparse points.                   |
 |      |               |                                            |
 |    3 | shortcut      | The file represented by a Windows          |
 |      |               | "shortcut".  A shortcut is distinguished   |
 |      |               | from a symbolic link because of the        |
 |      |               | difference in their contents, which may be |
 |      |               | of importance to the manager.              |
 |      |               |                                            |
 |    4 | stream        | An Alternate Data Stream (ADS) in Windows; |
 |      |               | a fork on MacOS.  Separate file system     |
 |      |               | entity that is considered an extension of  |
 |      |               | the main <File>.                           |
 |    5 | symbolic-link | The <name> element represents the file to  |
 |      |               | which the link points.                     |
 +------+---------------+--------------------------------------------+

Debar, et al. Experimental [Page 75] RFC 4765 The IDMEF March 2007

4.2.7.6.3. The Inode Class

 The Inode class is used to represent the additional information
 contained in a Unix file system i-node.
 The Inode class is composed of six aggregate classes, as shown in
 Figure 25.
                +--------------+
                |    Inode     |
                +--------------+            +----------------+
                |              |<>----------|   change-time  |
                |              |            +----------------+
                |              |            +----------------+
                |              |<>----------|     number     |
                |              |            +----------------+
                |              |            +----------------+
                |              |<>----------|  major-device  |
                |              |            +----------------+
                |              |            +----------------+
                |              |<>----------|  minor-device  |
                |              |            +----------------+
                |              |            +----------------+
                |              |<>----------| c-major-device |
                |              |            +----------------+
                |              |            +----------------+
                |              |<>----------| c-minor-device |
                |              |            +----------------+
                +--------------+
                      Figure 25: The Inode Class
 The aggregate classes that make up Inode are:
 change-time
    Zero or one.  DATETIME.  The time of the last inode change, given
    by the st_ctime element of "struct stat".
 number
    Zero or one.  INTEGER.  The inode number.
 major-device
    Zero or one.  INTEGER.  The major device number of the device the
    file resides on.

Debar, et al. Experimental [Page 76] RFC 4765 The IDMEF March 2007

 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;
   >

Debar, et al. Experimental [Page 77] RFC 4765 The IDMEF March 2007

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 26.
                +--------------+
                |   Checksum   |
                +--------------+            +-------+
                | algorithm    |<>----------| value |
                |              |            +-------+
                |              |        0..1+-------+
                |              |<>----------|  key  |
                |              |            +-------+
                +--------------+
                     Figure 26: The Checksum Class
 The aggregate classes that make up Checksum are:
 value
    Exactly one.  STRING.  The value of the checksum.
 key
    Zero or one.  STRING.  The key to the checksum, if appropriate.
 This is represented in the IDMEF DTD as follows:
 <!ENTITY % attvals.checksumalgos        "
       ( MD4 | MD5 | SHA1 | SHA2-256 | SHA2-384 | SHA2-512 | CRC-32 |
         Haval | Tiger | Gost )
   ">
 <!ELEMENT Checksum                      (
     value, key?
   )>
 <!ATTLIST Checksum
     algorithm           %attvals.checksumalgos; #REQUIRED
     %attlist.global;
   >

Debar, et al. Experimental [Page 78] RFC 4765 The IDMEF March 2007

 The Checksum class has one attribute:
 algorithm
    The cryptographic algorithm used for the computation of the
    checksum.  The permitted values are shown below.  There is no
    default value.  (See also Section 10.)
    +------+----------+------------------------------------------+
    | Rank | Keyword  | Description                              |
    +------+----------+------------------------------------------+
    |    0 | MD4      | The MD4 algorithm.                       |
    |      |          |                                          |
    |    1 | MD5      | The MD5 algorithm.                       |
    |      |          |                                          |
    |    2 | SHA1     | The SHA1 algorithm.                      |
    |      |          |                                          |
    |    3 | SHA2-256 | The SHA2 algorithm with 256 bits length. |
    |      |          |                                          |
    |    4 | SHA2-384 | The SHA2 algorithm with 384 bits length. |
    |      |          |                                          |
    |    5 | SHA2-512 | The SHA2 algorithm with 512 bits length. |
    |      |          |                                          |
    |    6 | CRC-32   | The CRC algorithm with 32 bits length.   |
    |      |          |                                          |
    |    7 | Haval    | The Haval algorithm.                     |
    |      |          |                                          |
    |    8 | Tiger    | The Tiger algorithm.                     |
    |      |          |                                          |
    |    9 | Gost     | The Gost algorithm.                      |
    +------+----------+------------------------------------------+

5. 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

Debar, et al. Experimental [Page 79] RFC 4765 The IDMEF March 2007

    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
     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 defines
     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.

Debar, et al. Experimental [Page 80] RFC 4765 The IDMEF March 2007

 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.

6. 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 definition 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.

Debar, et al. Experimental [Page 81] RFC 4765 The IDMEF March 2007

 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:
 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:

Debar, et al. Experimental [Page 82] RFC 4765 The IDMEF March 2007

 1.  Whenever possible, all analyzers and managers should have their
     time-of-day clocks synchronized to an external source such as NTP
     [7] or SNTP [8] Global Positioning System (GPS), Geosynchronous
     Operational Environmental Satellite (GOES), NIST radio station
     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

        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.

Debar, et al. Experimental [Page 83] RFC 4765 The IDMEF March 2007

 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
    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

Debar, et al. Experimental [Page 84] RFC 4765 The IDMEF March 2007

    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 [13].  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.
 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.

7. 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.

Debar, et al. Experimental [Page 85] RFC 4765 The IDMEF March 2007

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.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message xmlns:idmef="http://iana.org/idmef"
                      version="1.0">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="hq-dmz-analyzer01">
       <idmef:Node category="dns">
         <idmef:location>Headquarters DMZ Network</idmef:location>
         <idmef:name>analyzer01.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc723b45.0xef449129">
       2000-03-09T10:01:25.93464-05:00
     </idmef:CreateTime>
     <idmef:Source ident="a1b2c3d4">
       <idmef:Node ident="a1b2c3d4-001" category="dns">
         <idmef:name>badguy.example.net</idmef:name>
         <idmef:Address ident="a1b2c3d4-002"
                        category="ipv4-net-mask">
           <idmef:address>192.0.2.50</idmef:address>
           <idmef:netmask>255.255.255.255</idmef:netmask>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target ident="d1c2b3a4">
       <idmef:Node ident="d1c2b3a4-001" category="dns">
         <idmef:Address category="ipv4-addr-hex">
           <idmef:address>0xde796f70</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Target>
     <idmef:Classification text="Teardrop detected">
       <idmef:Reference origin="bugtraqid">
         <idmef:name>124</idmef:name>
         <idmef:url>http://www.securityfocus.com/bid/124</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>

Debar, et al. Experimental [Page 86] RFC 4765 The IDMEF March 2007

 </idmef:IDMEF-Message>

7.1.2. The "ping of death" Attack

 Network-based detection of the "ping of death" attack.  Note the
 identification of multiple targets, and the identification of the
 source as a spoofed address.
 NOTE: The URL has been cut to fit the IETF formating requirements.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-sensor01">
       <idmef:Node category="dns">
         <idmef:name>sensor.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc71f4f5.0xef449129">
       2000-03-09T10:01:25.93464Z
     </idmef:CreateTime>
     <idmef:Source ident="a1a2" spoofed="yes">
       <idmef:Node ident="a1a2-1">
         <idmef:Address ident="a1a2-2" category="ipv4-addr">
           <idmef:address>192.0.2.200</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target ident="b3b4">
       <idmef:Node>
         <idmef:Address ident="b3b4-1" category="ipv4-addr">
           <idmef:address>192.0.2.50</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Target>
     <idmef:Target ident="c5c6">
       <idmef:Node ident="c5c6-1" category="nisplus">
         <idmef:name>lollipop</idmef:name>
       </idmef:Node>
     </idmef:Target>
     <idmef:Target ident="d7d8">
       <idmef:Node ident="d7d8-1">
         <idmef:location>Cabinet B10</idmef:location>
         <idmef:name>Cisco.router.b10</idmef:name>
       </idmef:Node>
     </idmef:Target>

Debar, et al. Experimental [Page 87] RFC 4765 The IDMEF March 2007

     <idmef:Classification text="Ping-of-death detected">
       <idmef:Reference origin="cve">
         <idmef:name>CVE-1999-128</idmef:name>
         <idmef:url>http://www.cve.mitre.org/cgi-bin/
         cvename.cgi?name=CVE-1999-128</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.2. Port Scanning Attacks

 The following examples show how some common port scanning attacks
 could be represented in the IDMEF.

7.2.1. Connection to a Disallowed Service

 Host-based detection of a policy violation (attempt to obtain
 information via "finger").  Note the identification of the target
 service, as well as the originating user (obtained, e.g., through RFC
 1413 [11]).
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-sensor01">
       <idmef:Node category="dns">
         <idmef:name>sensor.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc72541d.0x00000000">
       2000-03-09T18:47:25+02:00
     </idmef:CreateTime>
     <idmef:Source ident="a123">
       <idmef:Node ident="a123-01">
         <idmef:Address ident="a123-02" category="ipv4-addr">
           <idmef:address>192.0.2.200</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:User ident="q987-03" category="os-device">
         <idmef:UserId ident="q987-04" type="target-user">
           <idmef:name>badguy</idmef:name>
         </idmef:UserId>
       </idmef:User>
       <idmef:Service ident="a123-03">
         <idmef:port>31532</idmef:port>

Debar, et al. Experimental [Page 88] RFC 4765 The IDMEF March 2007

       </idmef:Service>
     </idmef:Source>
     <idmef:Target ident="z456">
       <idmef:Node ident="z456-01" category="nis">
         <idmef:name>myhost</idmef:name>
         <idmef:Address ident="z456-02" category="ipv4-addr">
           <idmef:address>192.0.2.50</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service ident="z456-03">
         <idmef:name>finger</idmef:name>
         <idmef:port>79</idmef:port>
       </idmef:Service>
     </idmef:Target>
     <idmef:Classification text="Portscan">
       <idmef:Reference origin="vendor-specific">
         <idmef:name>finger</idmef:name>
         <idmef:url>http://www.vendor.com/finger</idmef:url>
       </idmef:Reference>
       <idmef:Reference origin="vendor-specific"
                        meaning="general documentation">
         <idmef:name>Distributed attack</idmef:name>
         <idmef:url>http://www.vendor.com/distributed</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.2.2. Simple Port Scanning

 Network-based detection of a port scan.  This shows detection by a
 single analyzer; see Section 7.5 for the same attack as detected by a
 correlation engine.  Note the use of <portlist> to show the ports
 that were scanned.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="hq-dmz-analyzer62">
       <idmef:Node category="dns">
         <idmef:location>Headquarters Web Server</idmef:location>
         <idmef:name>analyzer62.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc72b2b4.0x00000000">
       2000-03-09T15:31:00-08:00

Debar, et al. Experimental [Page 89] RFC 4765 The IDMEF March 2007

     </idmef:CreateTime>
     <idmef:Source ident="abc01">
       <idmef:Node ident="abc01-01">
         <idmef:Address ident="abc01-02" category="ipv4-addr">
           <idmef:address>192.0.2.200</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target ident="def01">
       <idmef:Node ident="def01-01" category="dns">
         <idmef:name>www.example.com</idmef:name>
         <idmef:Address ident="def01-02" category="ipv4-addr">
           <idmef:address>192.0.2.50</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service ident="def01-03">
         <idmef:portlist>5-25,37,42,43,53,69-119,123-514
         </idmef:portlist>
       </idmef:Service>
     </idmef:Target>
     <idmef:Classification text="simple portscan">
       <idmef:Reference origin="vendor-specific">
         <idmef:name>portscan</idmef:name>
         <idmef:url>http://www.vendor.com/portscan</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.3. Local Attacks

 The following examples show how some common local host attacks could
 be represented in the IDMEF.

7.3.1. The "loadmodule" Attack

 Host-based detection of the "loadmodule" exploit.  This attack
 involves tricking the "loadmodule" program into running another
 program; since "loadmodule" is set-user-id "root", the executed
 program runs with super-user privileges.  Note the use of <User> and
 <Process> to identify the user attempting the exploit and how he's
 doing it.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">

Debar, et al. Experimental [Page 90] RFC 4765 The IDMEF March 2007

     <idmef:Analyzer analyzerid="bc-fs-sensor13">
       <idmef:Node category="dns">
         <idmef:name>fileserver.example.com</idmef:name>
       </idmef:Node>
       <idmef:Process>
         <idmef:name>monitor</idmef:name>
         <idmef:pid>8956</idmef:pid>
         <idmef:arg>monitor</idmef:arg>
         <idmef:arg>-d</idmef:arg>
         <idmef:arg>-m</idmef:arg>
         <idmef:arg>idmanager.example.com</idmef:arg>
         <idmef:arg>-l</idmef:arg>
         <idmef:arg>/var/logs/idlog</idmef:arg>
       </idmef:Process>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc7221c0.0x4ccccccc">
       2000-03-09T08:12:32.3-05:00
     </idmef:CreateTime>
     <idmef:Source ident="a1a2">
       <idmef:User ident="a1a2-01" category="os-device">
         <idmef:UserId ident="a1a2-02"
                       type="original-user">
           <idmef:name>joe</idmef:name>
           <idmef:number>13243</idmef:number>
         </idmef:UserId>
       </idmef:User>
       <idmef:Process ident="a1a2-03">
         <idmef:name>loadmodule</idmef:name>
         <idmef:path>/usr/openwin/bin</idmef:path>
       </idmef:Process>
     </idmef:Source>
     <idmef:Target ident="z3z4">
       <idmef:Node ident="z3z4-01" category="dns">
         <idmef:name>fileserver.example.com</idmef:name>
       </idmef:Node>
     </idmef:Target>
     <idmef:Classification text="Loadmodule attack"
                           ident="loadmodule">
       <idmef:Reference origin="bugtraqid">
         <idmef:name>33</idmef:name>
         <idmef:url>http://www.securityfocus.com</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

Debar, et al. Experimental [Page 91] RFC 4765 The IDMEF March 2007

 The Intrusion Detection System (IDS) could also indicate that the
 target user is the "root" user, and show the attempted command; the
 alert might then look like:
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-fs-sensor13">
       <idmef:Node category="dns">
         <idmef:name>fileserver.example.com</idmef:name>
       </idmef:Node>
       <idmef:Process>
         <idmef:name>monitor</idmef:name>
         <idmef:pid>8956</idmef:pid>
         <idmef:arg>monitor</idmef:arg>
         <idmef:arg>-d</idmef:arg>
         <idmef:arg>-m</idmef:arg>
         <idmef:arg>idmanager.example.com</idmef:arg>
         <idmef:arg>-l</idmef:arg>
         <idmef:arg>/var/logs/idlog</idmef:arg>
       </idmef:Process>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc7221c0.0x4ccccccc">
       2000-03-09T08:12:32.3-05:00
     </idmef:CreateTime>
     <idmef:Source ident="a1a2">
       <idmef:User ident="a1a2-01" category="os-device">
         <idmef:UserId ident="a1a2-02" type="original-user">
           <idmef:name>joe</idmef:name>
           <idmef:number>13243</idmef:number>
         </idmef:UserId>
       </idmef:User>
       <idmef:Process ident="a1a2-03">
         <idmef:name>loadmodule</idmef:name>
         <idmef:path>/usr/openwin/bin</idmef:path>
       </idmef:Process>
     </idmef:Source>
     <idmef:Target ident="z3z4">
       <idmef:Node ident="z3z4-01" category="dns">
         <idmef:name>fileserver.example.com</idmef:name>
       </idmef:Node>
       <idmef:User ident="z3z4-02" category="os-device">
         <idmef:UserId ident="z3z4-03" type="target-user">
           <idmef:name>root</idmef:name>
           <idmef:number>0</idmef:number>
         </idmef:UserId>

Debar, et al. Experimental [Page 92] RFC 4765 The IDMEF March 2007

       </idmef:User>
       <idmef:Process ident="z3z4-04">
         <idmef:name>sh</idmef:name>
         <idmef:pid>25134</idmef:pid>
         <idmef:path>/bin/sh</idmef:path>
       </idmef:Process>
     </idmef:Target>
     <idmef:Classification text="Loadmodule attack"
                           ident="loadmodule">
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>
 Note that the identification of the classification is used.

7.3.2. The "phf" Attack

 Network-based detection of the "phf" attack.  Note the use of the
 <WebService> element to provide more details about this particular
 attack.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-sensor01">
       <idmef:Node category="dns">
         <idmef:name>sensor.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
       2000-03-09T08:12:32-01:00
     </idmef:CreateTime>
     <idmef:Source ident="abc123">
       <idmef:Node ident="abc123-001">
         <idmef:Address ident="abc123-002"
                        category="ipv4-addr">
           <idmef:address>192.0.2.200</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service ident="abc123-003">
         <idmef:port>21534</idmef:port>
       </idmef:Service>
     </idmef:Source>
     <idmef:Target ident="xyz789">
       <idmef:Node ident="xyz789-001" category="dns">
         <idmef:name>www.example.com</idmef:name>

Debar, et al. Experimental [Page 93] RFC 4765 The IDMEF March 2007

         <idmef:Address ident="xyz789-002"
                        category="ipv4-addr">
           <idmef:address>192.0.2.100</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service>
         <idmef:port>8080</idmef:port>
         <idmef:WebService>
           <idmef:url>
           http://www.example.com/cgi-bin/phf?/etc/group
           </idmef:url>
           <idmef:cgi>/cgi-bin/phf</idmef:cgi>
           <idmef:http-method>GET</idmef:http-method>
         </idmef:WebService>
       </idmef:Service>
     </idmef:Target>
     <idmef:Classification text="phf attack">
       <idmef:Reference origin="bugtraqid">
         <idmef:name>629</idmef:name>
         <idmef:url>
         http://www.securityfocus.com/bid/629
         </idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.3.3. File Modification

 Host-based detection of a race condition attack.  Note the use of the
 <File> to provide information about the files that are used to
 perform the attack.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert>
     <idmef:Analyzer analyzerid="bids-192.0.2.1"
                     ostype="Linux"
                     osversion="2.2.16-3">
       <idmef:Node category="hosts">
         <idmef:name>etude</idmef:name>
         <idmef:Address category="ipv4-addr">
           <idmef:address>192.0.2.1</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Analyzer>

Debar, et al. Experimental [Page 94] RFC 4765 The IDMEF March 2007

     <idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
       2000-03-09T08:12:32-01:00
     </idmef:CreateTime>
     <idmef:Source spoofed="no">
       <idmef:Node>
         <idmef:location>console</idmef:location>
         <idmef:Address category="ipv4-addr">
           <idmef:address>192.0.2.1</idmef:address>
         </idmef:Address>
         </idmef:Node>
     </idmef:Source>
     <idmef:Target decoy="no">
       <idmef:Node>
         <idmef:location>local</idmef:location>
         <idmef:Address category="ipv4-addr">
           <idmef:address>192.0.2.1</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:User category="os-device">
         <idmef:UserId type="original-user">
           <idmef:number>456</idmef:number>
         </idmef:UserId>
         <idmef:UserId type="current-user">
           <idmef:name>fred</idmef:name>
           <idmef:number>456</idmef:number>
         </idmef:UserId>
         <idmef:UserId type="user-privs">
           <idmef:number>456</idmef:number>
         </idmef:UserId>
       </idmef:User>
       <idmef:File category="current" fstype="tmpfs">
         <idmef:name>xxx000238483</idmef:name>
         <idmef:path>/tmp/xxx000238483</idmef:path>
         <idmef:FileAccess>
           <idmef:UserId type="user-privs">
             <idmef:name>alice</idmef:name>
             <idmef:number>777</idmef:number>
           </idmef:UserId>
           <idmef:permission perms="read" />
           <idmef:permission perms="write" />
           <idmef:permission perms="delete" />
           <idmef:permission perms="changePermissions" />
         </idmef:FileAccess>
         <idmef:FileAccess>
           <idmef:UserId type="group-privs">
             <idmef:name>user</idmef:name>
             <idmef:number>42</idmef:number>
           </idmef:UserId>

Debar, et al. Experimental [Page 95] RFC 4765 The IDMEF March 2007

           <idmef:permission perms="read" />
           <idmef:permission perms="write" />
           <idmef:permission perms="delete" />
         </idmef:FileAccess>
         <idmef:FileAccess>
           <idmef:UserId type="other-privs">
             <idmef:name>world</idmef:name>
           </idmef:UserId>
           <idmef:permission perms="noAccess" />
         </idmef:FileAccess>
         <idmef:Linkage category="symbolic-link">
           <idmef:name>passwd</idmef:name>
           <idmef:path>/etc/passwd</idmef:path>
         </idmef:Linkage>
       </idmef:File>
     </idmef:Target>
     <idmef:Classification text="DOM race condition">
       <idmef:Reference origin="vendor-specific">
         <idmef:name>DOM race condition</idmef:name>
         <idmef:url>file://attack-info/race.html
         </idmef:url>
       </idmef:Reference>
     </idmef:Classification>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.4. System Policy Violation

 In this example, logins are restricted to daytime hours.  The alert
 reports a violation of this policy that occurs when a user logs in a
 little after 10:00 pm.  Note the use of <AdditionalData> to provide
 information about the policy being violated.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-ds-01">
       <idmef:Node category="dns">
         <idmef:name>dialserver.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc72e7ef.0x00000000">
       2000-03-09T22:18:07-05:00
     </idmef:CreateTime>
     <idmef:Source ident="s01">
       <idmef:Node ident="s01-1">

Debar, et al. Experimental [Page 96] RFC 4765 The IDMEF March 2007

         <idmef:Address category="ipv4-addr">
           <idmef:address>127.0.0.1</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service ident="s01-2">
         <idmef:port>4325</idmef:port>
       </idmef:Service>
     </idmef:Source>
     <idmef:Target ident="t01">
       <idmef:Node ident="t01-1" category="dns">
         <idmef:name>mainframe.example.com</idmef:name>
       </idmef:Node>
       <idmef:User ident="t01-2" category="os-device">
         <idmef:UserId ident="t01-3" type="current-user">
           <idmef:name>louis</idmef:name>
           <idmef:number>501</idmef:number>
         </idmef:UserId>
       </idmef:User>
       <idmef:Service ident="t01-4">
         <idmef:name>login</idmef:name>
         <idmef:port>23</idmef:port>
       </idmef:Service>
     </idmef:Target>
     <idmef:Classification text="Login policy violation">
       <idmef:Reference origin="user-specific">
         <idmef:name>out-of-hours activity</idmef:name>
         <idmef:url>http://my.company.com/policies
         </idmef:url>
       </idmef:Reference>
     </idmef:Classification>
     <idmef:AdditionalData type="date-time"
                           meaning="start-time">
       <idmef:date-time>2000-03-09T07:00:00-05:00</idmef:date-time>
     </idmef:AdditionalData>
     <idmef:AdditionalData type="date-time"
                           meaning="stop-time">
       <idmef:date-time>2000-03-09T19:30:00-05:00</idmef:date-time>
     </idmef:AdditionalData>
   </idmef:Alert>
 </idmef:IDMEF-Message>

Debar, et al. Experimental [Page 97] RFC 4765 The IDMEF March 2007

7.5. Correlated Alerts

 The following example shows how the port scan alert from
 Section 7.2.2 could be represented if it had been detected and sent
 from a correlation engine, instead of a single analyzer.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="bc-corr-01">
       <idmef:Node category="dns">
         <idmef:name>correlator01.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc72423b.0x00000000">
       2000-03-09T15:31:07Z
     </idmef:CreateTime>
     <idmef:Source ident="a1">
       <idmef:Node ident="a1-1">
         <idmef:Address ident="a1-2" category="ipv4-addr">
           <idmef:address>192.0.2.200</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target ident="a2">
       <idmef:Node ident="a2-1" category="dns">
         <idmef:name>www.example.com</idmef:name>
         <idmef:Address ident="a2-2" category="ipv4-addr">
           <idmef:address>192.0.2.50</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:Service ident="a2-3">
         <idmef:portlist>5-25,37,42,43,53,69-119,123-514
         </idmef:portlist>
       </idmef:Service>
     </idmef:Target>
     <idmef:Classification text="Portscan">
       <idmef:Reference origin="vendor-specific">
         <idmef:name>portscan</idmef:name>
         <idmef:url>http://www.vendor.com/portscan</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
     <idmef:CorrelationAlert>
       <idmef:name>multiple ports in short time</idmef:name>
       <idmef:alertident>123456781</idmef:alertident>
       <idmef:alertident>123456782</idmef:alertident>

Debar, et al. Experimental [Page 98] RFC 4765 The IDMEF March 2007

       <idmef:alertident>123456783</idmef:alertident>
       <idmef:alertident>123456784</idmef:alertident>
       <idmef:alertident>123456785</idmef:alertident>
       <idmef:alertident>123456786</idmef:alertident>
       <idmef:alertident analyzerid="a1b2c3d4">987654321
       </idmef:alertident>
       <idmef:alertident analyzerid="a1b2c3d4">987654322
       </idmef:alertident>
     </idmef:CorrelationAlert>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.6. Analyzer Assessments

 Host-based detection of a successful unauthorized acquisition of root
 access through the eject buffer overflow.  Note the use of
 <Assessment> to provide information about the analyzer's evaluation
 of and reaction to the attack.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                      xmlns:idmef="http://iana.org/idmef">
   <idmef:Alert>
     <idmef:Analyzer analyzerid="bids-192.0.2.1">
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
       2000-03-09T08:12:32-01:00
     </idmef:CreateTime>
     <idmef:Source spoofed="no">
       <idmef:Node>
         <idmef:location>console</idmef:location>
         <idmef:Address category="ipv4-addr">
           <idmef:address>192.0.2.1</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target decoy="no">
       <idmef:Node>
         <idmef:location>local</idmef:location>
         <idmef:Address category="ipv4-addr">
           <idmef:address>192.0.2.1</idmef:address>
         </idmef:Address>
       </idmef:Node>
       <idmef:User category="os-device">
         <idmef:UserId type="original-user">
           <idmef:number>456</idmef:number>
         </idmef:UserId>

Debar, et al. Experimental [Page 99] RFC 4765 The IDMEF March 2007

         <idmef:UserId type="current-user">
           <idmef:name>root</idmef:name>
           <idmef:number>0</idmef:number>
         </idmef:UserId>
         <idmef:UserId type="user-privs">
           <idmef:number>0</idmef:number>
         </idmef:UserId>
       </idmef:User>
       <idmef:Process>
         <idmef:name>eject</idmef:name>
         <idmef:pid>32451</idmef:pid>
         <idmef:path>/usr/bin/eject</idmef:path>
         <idmef:arg>\x90\x80\x3f\xff...\x08/bin/sh</idmef:arg>
       </idmef:Process>
     </idmef:Target>
     <idmef:Classification
         text="Unauthorized administrative access">
       <idmef:Reference origin="vendor-specific">
         <idmef:name>Unauthorized user to superuser</idmef:name>
         <idmef:url>file://attack-info/u2s.html</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
     <idmef:Assessment>
       <idmef:Impact severity="high" completion="succeeded"
               type="admin"/>
       <idmef:Action category="notification-sent">
         page
         </idmef:Action>
       <idmef:Action category="block-installed">
         disabled user (fred)
       </idmef:Action>
       <idmef:Action category="taken-offline">
         logout user (fred)
       </idmef:Action>
       <idmef:Confidence rating="high"/>
     </idmef:Assessment>
   </idmef:Alert>
 </idmef:IDMEF-Message>

7.7. Heartbeat

 This example shows a Heartbeat message that provides "I'm alive and
 working" information to the manager.  Note the use of
 <AdditionalData> elements, with "meaning" attributes, to provide some
 additional information.

Debar, et al. Experimental [Page 100] RFC 4765 The IDMEF March 2007

 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
                xmlns:idmef="http://iana.org/idmef">
   <idmef:Heartbeat messageid="abc123456789">
     <idmef:Analyzer analyzerid="hq-dmz-analyzer01">
       <idmef:Node category="dns">
         <idmef:location>Headquarters DMZ Network</idmef:location>
         <idmef:name>analyzer01.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc722ebe.0x00000000">
       2000-03-09T14:07:58Z
     </idmef:CreateTime>
     <idmef:AdditionalData type="real" meaning="%memused">
       <idmef:real>62.5</idmef:real>
     </idmef:AdditionalData>
     <idmef:AdditionalData type="real" meaning="%diskused">
       <idmef:real>87.1</idmef:real>
     </idmef:AdditionalData>
   </idmef:Heartbeat>
 </idmef:IDMEF-Message>

7.8. XML Extension

 The following example shows how to extend the IDMEF DTD.  In the
 example, the VendorCo company has decided it wants to add geographic
 information to the Node class.  To do this, VendorCo creates a
 Document Type Definition or DTD that defines how their class will be
 formatted:
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:vendorco="http://vendor.com/idmef"
             targetNamespace="http://vendor.com/idmef"
             elementFormDefault="qualified" >
   <xsd:annotation>
     <xsd:documentation>
       Intrusion Detection Message Exchange Format (IDMEF) Extension
       for geographic information
     </xsd:documentation>
   </xsd:annotation>
   <xsd:complexType name="NodeGeoType">
     <xsd:sequence>
     <xsd:element name="latitude"
                  type="xsd:string" />
     <xsd:element name="longitude"

Debar, et al. Experimental [Page 101] RFC 4765 The IDMEF March 2007

                  type="xsd:string" />
     <xsd:element name="elevation"
                  type="xsd:string"
                  minOccurs="0"
                  maxOccurs="1" />
         </xsd:sequence>
     <xsd:attribute name="node-ident"
                    type="xsd:integer"
                    use="required"/>
   </xsd:complexType>
   <xsd:element name="NodeGeography" type="vendorco:NodeGeoType" />
 </xsd:schema>
 The VendorCo:NodeGeography class will contain the geographic data in
 three aggregate classes, VendorCo:latitude, VendorCo:longitude, and
 VendorCo:elevation.  To associate the information in this class with
 a particular node, the "VendorCo:node-ident" attribute is provided;
 it must contain the same value as the "ident" attribute on the
 relevant Node element.
 To make use of this DTD now, VendorCo follows the rules in
 Section 5.2 and defines a parameter entity called "x-vendorco" within
 the Document Type Definition, and then references this entity.  In
 the alert, the VendorCo elements are included under the
 AdditionalData element, with a "type" attribute of "xml", as shown
 below.
 <?xml version="1.0" encoding="UTF-8"?>
 <idmef:IDMEF-Message version="1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:idmef="http://iana.org/idmef"
      xmlns:vendorco="http://v.com/idmef"
      xsi:schemaLocation="http://v.com/idmef http://v.com/geo.xsd">
   <idmef:Alert messageid="abc123456789">
     <idmef:Analyzer analyzerid="hq-dmz-analyzer01">
       <idmef:Node category="dns">
         <idmef:location>Headquarters DMZ Network</idmef:location>
         <idmef:name>analyzer01.example.com</idmef:name>
       </idmef:Node>
     </idmef:Analyzer>
     <idmef:CreateTime ntpstamp="0xbc723b45.0xef449129">
       2000-03-09T10:01:25.93464-05:00
     </idmef:CreateTime>

Debar, et al. Experimental [Page 102] RFC 4765 The IDMEF March 2007

     <idmef:Source ident="a1b2c3d4">
       <idmef:Node ident="a1b2c3d4-001" category="dns">
         <idmef:name>badguy.example.net</idmef:name>
         <idmef:Address ident="a1b2c3d4-002" category="ipv4-net-mask">
           <idmef:address>192.0.2.50</idmef:address>
           <idmef:netmask>255.255.255.255</idmef:netmask>
         </idmef:Address>
       </idmef:Node>
     </idmef:Source>
     <idmef:Target ident="d1c2b3a4">
       <idmef:Node ident="d1c2b3a4-001" category="dns">
         <idmef:Address category="ipv4-addr-hex">
           <idmef:address>0xde796f70</idmef:address>
         </idmef:Address>
       </idmef:Node>
     </idmef:Target>
     <idmef:Classification text="Teardrop">
       <idmef:Reference origin="bugtraqid">
         <idmef:name>124</idmef:name>
         <idmef:url>http://www.securityfocus.com/bid/124</idmef:url>
       </idmef:Reference>
     </idmef:Classification>
     <idmef:AdditionalData type="xml" meaning="node geo info">
       <idmef:xml>
         <vendorco:NodeGeography
           xmlns:vendorco="http://vendor.com/idmef"
    xsi:schemaLocation="http://v.com/idmef http://v.com/geo.xsd"
           vendorco:node-ident="a1b2c3d4-001">
         <vendorco:latitude>38.89</vendorco:latitude>
         <vendorco:longitude>-77.02</vendorco:longitude>
       </vendorco:NodeGeography>
       </idmef:xml>
     </idmef:AdditionalData>
   </idmef:Alert>
 </idmef:IDMEF-Message>

Debar, et al. Experimental [Page 103] RFC 4765 The IDMEF March 2007

8. The IDMEF Document Type Definition (Normative)

 <?xml version="1.0" encoding="UTF-8"?>
 <!-- ***************************************************************
  *******************************************************************
  *** Intrusion Detection Message Exchange Format (IDMEF) XML DTD ***
  ***                Version 1.0, 07 March 2006                   ***
  ***                                                             ***
  *** The use and extension of the IDMEF XML DTD are described in ***
  *** RFC 4765, "The Intrusion Detection Message Exchange         ***
  *** Format",  H. Debar, D. Curry, B. Feinstein.                 ***
  *******************************************************************
  *************************************************************** -->
 <!-- ===============================================================
  ===================================================================
  === SECTION 1.  Attribute list declarations.
  ===================================================================
  =============================================================== -->
 <!--
  | Attributes of the IDMEF element.  In general, the fixed values of
  | these attributes will change each time a new version of the DTD
  | is released.
  -->
 <!ENTITY % attlist.idmef                "
     version             CDATA                   #FIXED    '1.0'
   ">
 <!--
  | Attributes of all elements.  These are the "XML" attributes that
  | every element should have.  Space handling, language, and name
  | space.
  -->
 <!ENTITY % attlist.global               "
     xmlns:idmef         CDATA                   #FIXED
         'http://iana.org/idmef'
     xmlns               CDATA                   #FIXED
         'http://iana.org/idmef'
     xml:space           (default | preserve)    'default'
     xml:lang            NMTOKEN                 #IMPLIED
   ">

Debar, et al. Experimental [Page 104] RFC 4765 The IDMEF March 2007

 <!-- ===============================================================
  ===================================================================
  === SECTION 2.  Attribute value declarations.  Enumerated values for
  ===            many of the element-specific attribute lists.
  ===================================================================
  =============================================================== -->
 <!--
  | Values for the Action.category attribute.
  -->
 <!ENTITY % attvals.actioncat            "
     ( block-installed | notification-sent | taken-offline | other )
   ">
 <!--
  | Values for the Address.category attribute.
  -->
 <!ENTITY % attvals.addrcat              "
     ( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
       ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
       ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask )
   ">
 <!--
  | Values for the AdditionalData.type attribute.
  -->
 <!ENTITY % attvals.adtype               "
     ( boolean | byte | character | date-time | integer | ntpstamp |
       portlist | real | string | byte-string | xmltext )
   ">
 <!--
  | Values for the Impact.completion attribute.
  -->
 <!ENTITY % attvals.completion           "
     ( failed | succeeded )
   ">
 <!--
  | Values for the File.category attribute.
  -->
 <!ENTITY % attvals.filecat              "
     ( current | original )
   ">
 <!ENTITY % attvals.fileperm "( noAccess | read | write | execute |
   search | delete | executeAs | changePermissions |
   takeOwnership)" >

Debar, et al. Experimental [Page 105] RFC 4765 The IDMEF March 2007

 <!--
  | Values for the UserId.type attribute.
  -->
 <!ENTITY % attvals.idtype               "
     ( current-user | original-user | target-user | user-privs |
       current-group | group-privs | other-privs )
   ">
 <!--
  | Values for the Impact.type attribute.
  -->
 <!ENTITY % attvals.impacttype           "
     ( admin | dos | file | recon | user | other )
   ">
 <!--
  | Values for the Linkage.category attribute.
  -->
 <!ENTITY % attvals.linkcat              "
     ( hard-link | mount-point | reparse-point | shortcut | stream |
       symbolic-link )
   ">
 <!--
  | Values for the Checksum.algorithm attribute
  -->
 <!ENTITY % attvals.checksumalgos        "
       ( MD4 | MD5 | SHA1 | SHA2-256 | SHA2-384 | SHA2-512 | CRC-32 |
         Haval | Tiger | Gost )
   ">
 <!--
  | Values for the Node.category attribute.
  -->
 <!ENTITY % attvals.nodecat              "
     ( unknown | ads | afs | coda | dfs | dns | hosts | kerberos |
       nds | nis | nisplus | nt | wfw )
   ">
 <!--
  | Values for the Reference.origin attribute.
  -->
 <!ENTITY % attvals.origin               "
     ( unknown | vendor-specific | user-specific | bugtraqid | cve |
       osvdb )
   ">
 <!--

Debar, et al. Experimental [Page 106] RFC 4765 The IDMEF March 2007

  | Values for the Confidence.rating attribute.
  -->
 <!ENTITY % attvals.rating               "
     ( low | medium | high | numeric )
   ">
 <!--
  | Values for the Impact.severity attribute.
  -->
 <!ENTITY % attvals.severity             "
     ( info | low | medium | high )
   ">
 <!--
  | Values for the User.category attribute.
  -->
 <!ENTITY % attvals.usercat              "
     ( unknown | application | os-device )
   ">
 <!--
  | Values for yes/no attributes such as Source.spoofed and
  | Target.decoy.
  -->
 <!ENTITY % attvals.yesno                "
     ( unknown | yes | no )
   ">
 <!-- ===============================================================
  ===================================================================
  === SECTION 3.  Top-level element declarations.  The IDMEF-Message
  ===            element and the types of messages it can include.
  ===================================================================
  =============================================================== -->
 <!ELEMENT IDMEF-Message                 (
     (Alert | Heartbeat)*
   )>
 <!ATTLIST IDMEF-Message
     %attlist.global;
     %attlist.idmef;
   >
 <!ELEMENT Alert                         (
     Analyzer, CreateTime, DetectTime?, AnalyzerTime?,
     Source*, Target*, Classification, Assessment?, (ToolAlert |
     OverflowAlert | CorrelationAlert)?, AdditionalData*
   )>

Debar, et al. Experimental [Page 107] RFC 4765 The IDMEF March 2007

 <!ATTLIST Alert
     messageid           CDATA                   '0'
     %attlist.global;
   >
 <!ELEMENT Heartbeat                     (
     Analyzer, CreateTime, HeartbeatInterval?, AnalyzerTime?,
     AdditionalData*
   )>
 <!ATTLIST Heartbeat
     messageid           CDATA                   '0'
     %attlist.global;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 4.  Subclasses of the Alert element that provide more
  ===            data for specific types of alerts.
  ===================================================================
  =============================================================== -->
 <!ELEMENT CorrelationAlert              (
     name, alertident+
   )>
 <!ATTLIST CorrelationAlert
     %attlist.global;
   >
 <!ELEMENT OverflowAlert                 (
     program, size?, buffer?
   )>
 <!ATTLIST OverflowAlert
     %attlist.global;
   >
 <!ELEMENT ToolAlert                     (
     name, command?, alertident+
   )>
 <!ATTLIST ToolAlert
     %attlist.global;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 5.  The AdditionalData element.  This element allows an
  ===             alert to include additional information that cannot
  ===             be encoded elsewhere in the data model.
  ===================================================================

Debar, et al. Experimental [Page 108] RFC 4765 The IDMEF March 2007

  =============================================================== -->
 <!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;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 6.  Elements related to identifying entities - analyzers
  ===            (the senders of these messages), sources (of
  ===            attacks), and targets (of attacks).
  ===================================================================
  =============================================================== -->
 <!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;
   >
 <!ELEMENT Classification                (
     Reference*
   )>
 <!ATTLIST Classification
     ident               CDATA                   '0'
     text                CDATA                   #REQUIRED
   >
 <!ELEMENT Source                        (
     Node?, User?, Process?, Service?

Debar, et al. Experimental [Page 109] RFC 4765 The IDMEF March 2007

   )>
 <!ATTLIST Source
     ident               CDATA                   '0'
     spoofed             %attvals.yesno;         'unknown'
     interface           CDATA                   #IMPLIED
     %attlist.global;
   >
 <!ELEMENT Target                        (
     Node?, User?, Process?, Service?, File*
   )>
 <!ATTLIST Target
     ident               CDATA                   '0'
     decoy               %attvals.yesno;         'unknown'
     interface           CDATA                   #IMPLIED
     %attlist.global;
   >
 <!ELEMENT Assessment                    (
     Impact?, Action*, Confidence?
   )>
 <!ATTLIST Assessment
     %attlist.global;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 7.  Support elements used for providing detailed info
  ===            about entities - addresses, names, etc.
  ===================================================================
  =============================================================== -->
 <!ELEMENT Reference                (
     name, url
   )>
 <!ATTLIST Reference
     origin              %attvals.origin;        'unknown'
     meaning             CDATA                   #IMPLIED
   >
 <!ELEMENT Node                          (
     location?, (name | Address), Address*
   )>
 <!ATTLIST Node
     ident               CDATA                   '0'
     category            %attvals.nodecat;       'unknown'
     %attlist.global;
   >

Debar, et al. Experimental [Page 110] RFC 4765 The IDMEF March 2007

 <!ELEMENT Address                       (
     address, netmask?
   )>
 <!ATTLIST Address
     ident               CDATA                   '0'
     category            %attvals.addrcat;       'unknown'
     vlan-name           CDATA                   #IMPLIED
     vlan-num            CDATA                   #IMPLIED
     %attlist.global;
   >
 <!ELEMENT File                          (
     name, path, create-time?, modify-time?, access-time?,
     data-size?, disk-size?, FileAccess*, Linkage*, Inode?,
     Checksum*
   )>
 <!ATTLIST File
     ident               CDATA                   '0'
     category            %attvals.filecat;       #REQUIRED
     fstype              CDATA                   #IMPLIED
     file-type           CDATA                   #IMPLIED
     %attlist.global;
   >
 <!ELEMENT Permission EMPTY >
 <!ATTLIST Permission
     perms               %attvals.fileperm;      #REQUIRED
     %attlist.global;
 >
 <!ELEMENT FileAccess                    (
     UserId, Permission+
   )>
 <!ATTLIST FileAccess
     %attlist.global;
   >
 <!ELEMENT Inode                         (
     change-time?, (number, major-device, minor-device)?,
     (c-major-device, c-minor-device)?
   )>
 <!ATTLIST Inode
     %attlist.global;
   >
 <!ELEMENT Linkage                       (
     (name, path) | File
   )>

Debar, et al. Experimental [Page 111] RFC 4765 The IDMEF March 2007

 <!ATTLIST Linkage
     category            %attvals.linkcat;       #REQUIRED
     %attlist.global;
   >
 <!ELEMENT Checksum                      (
     value, key?
   )>
 <!ATTLIST Checksum
     algorithm           %attvals.checksumalgos; #REQUIRED
     %attlist.global;
   >
 <!ELEMENT Process                       (
     name, pid?, path?, arg*, env*
   )>
 <!ATTLIST Process
     ident               CDATA                   '0'
     %attlist.global;
   >
 <!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;
   >
 <!ELEMENT SNMPService                   (
     oid?, messageProcessingModel?, securityModel?, securityName?,
     securityLevel?, contextName?, contextEngineID?, command?
   )>
 <!ATTLIST SNMPService
     %attlist.global;
   >
 <!ELEMENT User                          (
     UserId+
   )>
 <!ATTLIST User
     ident               CDATA                   '0'
     category            %attvals.usercat;       'unknown'
     %attlist.global;

Debar, et al. Experimental [Page 112] RFC 4765 The IDMEF March 2007

   >
 <!ELEMENT UserId                        (
     (name, number?) | (number, name?)
   )>
 <!ATTLIST UserId
     ident               CDATA                   '0'
     type                %attvals.idtype;        'original-user'
     tty                 CDATA                   #IMPLIED
     %attlist.global;
   >
 <!ELEMENT WebService                    (
     url, cgi?, http-method?, arg*
   )>
 <!ATTLIST WebService
     %attlist.global;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 8.  Simple elements with sub-elements or attributes of a
  ===            special nature.
  ===================================================================
  =============================================================== -->
 <!ELEMENT Action              (#PCDATA) >
 <!ATTLIST Action
     category            %attvals.actioncat;     'other'
     %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

Debar, et al. Experimental [Page 113] RFC 4765 The IDMEF March 2007

     %attlist.global;
   >
 <!ELEMENT Confidence          (#PCDATA) >
 <!ATTLIST Confidence
     rating              %attvals.rating;        'numeric'
     %attlist.global;
   >
 <!ELEMENT Impact              (#PCDATA) >
 <!ATTLIST Impact
     severity            %attvals.severity;      #IMPLIED
     completion          %attvals.completion;    #IMPLIED
     type                %attvals.impacttype;    'other'
     %attlist.global;
   >
 <!ELEMENT alertident          (#PCDATA) >
 <!ATTLIST alertident
     analyzerid          CDATA                   #IMPLIED
     %attlist.global;
   >
 <!-- ===============================================================
  ===================================================================
  === SECTION 9.  Simple elements with no sub-elements and no special
  === attributes.
  ===================================================================
  =============================================================== -->
 <!ELEMENT boolean           (#PCDATA)         >
 <!ATTLIST boolean           %attlist.global;  >
 <!ELEMENT byte              (#PCDATA)         >
 <!ATTLIST byte              %attlist.global;  >
 <!ELEMENT character         (#PCDATA)         >
 <!ATTLIST character         %attlist.global;  >
 <!ELEMENT date-time         (#PCDATA)         >
 <!ATTLIST date-time         %attlist.global;  >
 <!ELEMENT integer           (#PCDATA)         >
 <!ATTLIST integer           %attlist.global;  >
 <!ELEMENT ntpstamp          (#PCDATA)         >
 <!ATTLIST ntpstamp          %attlist.global;  >

Debar, et al. Experimental [Page 114] RFC 4765 The IDMEF March 2007

 <!ELEMENT real              (#PCDATA)         >
 <!ATTLIST real              %attlist.global;  >
 <!ELEMENT string            (#PCDATA)         >
 <!ATTLIST string            %attlist.global;  >
 <!ELEMENT byte-string       (#PCDATA)         >
 <!ATTLIST byte-string       %attlist.global;  >
 <!ELEMENT xmltext           ANY               >
 <!ATTLIST xmltext           %attlist.global;  >
 <!ELEMENT access-time       (#PCDATA)         >
 <!ATTLIST access-time       %attlist.global;  >
 <!ELEMENT address           (#PCDATA)         >
 <!ATTLIST address           %attlist.global;  >
 <!ELEMENT arg               (#PCDATA)         >
 <!ATTLIST arg               %attlist.global;  >
 <!ELEMENT buffer            (#PCDATA)         >
 <!ATTLIST buffer            %attlist.global;  >
 <!ELEMENT c-major-device    (#PCDATA)         >
 <!ATTLIST c-major-device    %attlist.global;  >
 <!ELEMENT c-minor-device    (#PCDATA)         >
 <!ATTLIST c-minor-device    %attlist.global;  >
 <!ELEMENT cgi               (#PCDATA)         >
 <!ATTLIST cgi               %attlist.global;  >
 <!ELEMENT change-time       (#PCDATA)         >
 <!ATTLIST change-time       %attlist.global;  >
 <!ELEMENT command           (#PCDATA)         >
 <!ATTLIST command           %attlist.global;  >
 <!ELEMENT create-time       (#PCDATA)         >
 <!ATTLIST create-time       %attlist.global;  >
 <!ELEMENT data-size         (#PCDATA)         >
 <!ATTLIST data-size         %attlist.global;  >
 <!ELEMENT disk-size         (#PCDATA)         >
 <!ATTLIST disk-size         %attlist.global;  >

Debar, et al. Experimental [Page 115] RFC 4765 The IDMEF March 2007

 <!ELEMENT env               (#PCDATA)         >
 <!ATTLIST env               %attlist.global;  >
 <!ELEMENT http-method       (#PCDATA)         >
 <!ATTLIST http-method       %attlist.global;  >
 <!ELEMENT location          (#PCDATA)         >
 <!ATTLIST location          %attlist.global;  >
 <!ELEMENT major-device      (#PCDATA)         >
 <!ATTLIST major-device      %attlist.global;  >
 <!ELEMENT minor-device      (#PCDATA)         >
 <!ATTLIST minor-device      %attlist.global;  >
 <!ELEMENT modify-time       (#PCDATA)         >
 <!ATTLIST modify-time       %attlist.global;  >
 <!ELEMENT name              (#PCDATA)         >
 <!ATTLIST name              %attlist.global;  >
 <!ELEMENT netmask           (#PCDATA)         >
 <!ATTLIST netmask           %attlist.global;  >
 <!ELEMENT number            (#PCDATA)         >
 <!ATTLIST number            %attlist.global;  >
 <!ELEMENT oid               (#PCDATA)         >
 <!ATTLIST oid               %attlist.global;  >
 <!ELEMENT path              (#PCDATA)         >
 <!ATTLIST path              %attlist.global;  >
 <!ELEMENT permission        (#PCDATA)         >
 <!ATTLIST permission        %attlist.global;  >
 <!ELEMENT pid               (#PCDATA)         >
 <!ATTLIST pid               %attlist.global;  >
 <!ELEMENT port              (#PCDATA)         >
 <!ATTLIST port              %attlist.global;  >
 <!ELEMENT portlist          (#PCDATA)         >
 <!ATTLIST portlist          %attlist.global;  >
 <!ELEMENT program           (#PCDATA)         >
 <!ATTLIST program           %attlist.global;  >

Debar, et al. Experimental [Page 116] RFC 4765 The IDMEF March 2007

 <!ELEMENT protocol          (#PCDATA)         >
 <!ATTLIST protocol          %attlist.global;  >
 <!ELEMENT size              (#PCDATA)         >
 <!ATTLIST size              %attlist.global;  >
 <!ELEMENT url               (#PCDATA)         >
 <!ATTLIST url               %attlist.global;  >
 <!ELEMENT HeartbeatInterval (#PCDATA)         >
 <!ATTLIST HeartbeatInterval %attlist.global;  >
 <!ELEMENT messageProcessingModel (#PCDATA)    >
 <!ATTLIST messageProcessingModel %attlist.global;>
 <!ELEMENT securityModel     (#PCDATA)         >
 <!ATTLIST securityModel     %attlist.global;  >
 <!ELEMENT securityName      (#PCDATA)         >
 <!ATTLIST securityName      %attlist.global;  >
 <!ELEMENT securityLevel     (#PCDATA)         >
 <!ATTLIST securityLevel     %attlist.global;  >
 <!ELEMENT contextName       (#PCDATA)         >
 <!ATTLIST contextName       %attlist.global;  >
 <!ELEMENT contextEngineID   (#PCDATA)         >
 <!ATTLIST contextEngineID   %attlist.global;  >
 <!ELEMENT value             (#PCDATA)         >
 <!ATTLIST value             %attlist.global;  >
 <!ELEMENT key               (#PCDATA)         >
 <!ATTLIST key               %attlist.global;  >
 <!-- End of IDMEF DTD -->

9. Security Considerations

 This document 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.

Debar, et al. Experimental [Page 117] RFC 4765 The IDMEF March 2007

 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.

10. IANA Considerations

 Section 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 extend 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 created a repository for
 attribute values called "Intrusion Detection Message Exchange Format
 (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.

Debar, et al. Experimental [Page 118] RFC 4765 The IDMEF March 2007

 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:
 +------+-----------------+------------------------------------------+
 | Rank | Keyword         | Description                              |
 +------+-----------------+------------------------------------------+
 |    0 | unknown         | Origin of the name is not known          |
 |    1 | vendor-specific | A vendor-specific name (and hence, URL); |
 |      |                 | this can be used to provide              |
 |      |                 | product-specific information             |
 |    2 | user-specific   | A user-specific name (and hence, URL);   |
 |      |                 | this can be used to provide              |
 |      |                 | installation-specific information        |
 |    3 | bugtraqid       | The SecurityFocus ("Bugtraq")            |
 |      |                 | vulnerability database identifier        |
 |      |                 | (http://www.securityfocus.com/bid)       |
 |    4 | cve             | The Common Vulnerabilities and Exposures |
 |      |                 | (CVE) name (http://cve.mitre.org/)       |
 |    5 | osvdb           | The Open Source Vulnerability Database   |
 |      |                 | (http://www.osvdb.org)                   |
 +------+-----------------+------------------------------------------+

Debar, et al. Experimental [Page 119] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Source
 IDMEF Attribute Name:  spoofed
 Registered Values:
      +------+---------+----------------------------------------+
      | 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"        |
      +------+---------+----------------------------------------+
 IDMEF Class Name:  Target
 IDMEF Attribute Name:  decoy
 Registered Values:
      +------+---------+----------------------------------------+
      | 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"        |
      +------+---------+----------------------------------------+

Debar, et al. Experimental [Page 120] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  AdditionalData
 IDMEF Attribute Name:  type
 Registered Values:
 +------+-------------+----------------------------------------------+
 | Rank | Keyword     | Description                                  |
 +------+-------------+----------------------------------------------+
 |    0 | boolean     | The element contains a boolean value, i.e.,  |
 |      |             | the strings "true" or "false"                |
 |    1 | byte        | The element content is a single 8-bit byte   |
 |      |             | (see Section 3.2.4)                          |
 |    2 | character   | The element content is a single character    |
 |      |             | (see Section 3.2.3)                          |
 |    3 | date-time   | The element content is a date-time string    |
 |      |             | (see Section 3.2.6)                          |
 |    4 | integer     | The element content is an integer (see       |
 |      |             | Section 3.2.1)                               |
 |    5 | ntpstamp    | The element content is an NTP timestamp (see |
 |      |             | Section 3.2.7)                               |
 |    6 | portlist    | The element content is a list of ports (see  |
 |      |             | Section 3.2.8)                               |
 |    7 | real        | The element content is a real number (see    |
 |      |             | Section 3.2.2)                               |
 |    8 | string      | The element content is a string (see         |
 |      |             | Section 3.2.3)                               |
 |    9 | byte-string | The element content is a byte[] (see         |
 |      |             | Section 3.2.4)                               |
 |   10 | xmltext     | The element content is XML-tagged data (see  |
 |      |             | Section 5.2)                                 |
 +------+-------------+----------------------------------------------+

Debar, et al. Experimental [Page 121] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Impact
 IDMEF Attribute Name:  severity
 Registered Values:
     +------+---------+-----------------------------------------+
     | Rank | Keyword | Description                             |
     +------+---------+-----------------------------------------+
     |    0 | info    | Alert represents informational activity |
     |      |         |                                         |
     |    1 | low     | Low severity                            |
     |      |         |                                         |
     |    2 | medium  | Medium severity                         |
     |      |         |                                         |
     |    3 | high    | High severity                           |
     +------+---------+-----------------------------------------+
 IDMEF Class Name:  Impact
 IDMEF Attribute Name:  completion
 Registered Values:
         +------+-----------+--------------------------------+
         | Rank | Keyword   | Description                    |
         +------+-----------+--------------------------------+
         |    0 | failed    | The attempt was not successful |
         |    1 | succeeded | The attempt succeeded          |
         +------+-----------+--------------------------------+

Debar, et al. Experimental [Page 122] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Impact
 IDMEF Attribute Name:  type
 Registered Values:
 +------+---------+--------------------------------------------------+
 | Rank | Keyword | Description                                      |
 +------+---------+--------------------------------------------------+
 |    0 | admin   | Administrative privileges were attempted or      |
 |      |         | obtained                                         |
 |    1 | dos     | A denial of service was attempted or completed   |
 |    2 | file    | An action on a file was attempted or completed   |
 |    3 | recon   | A reconnaissance probe was attempted or          |
 |      |         | completed                                        |
 |    4 | user    | User privileges were attempted or obtained       |
 |    5 | other   | Anything not in one of the above categories      |
 +------+---------+--------------------------------------------------+
 IDMEF Class Name:  Action
 IDMEF Attribute Name:  category
 Registered Values:
 +------+-------------------+----------------------------------------+
 | Rank | Keyword           | Description                            |
 +------+-------------------+----------------------------------------+
 |    0 | block-installed   | A block of some sort was installed to  |
 |      |                   | prevent an attack from reaching its    |
 |      |                   | destination.  The block could be a     |
 |      |                   | port block, address block, etc., or    |
 |      |                   | disabling a user account.              |
 |    1 | notification-sent | A notification message of some sort    |
 |      |                   | was sent out-of-band (via pager,       |
 |      |                   | e-mail, etc.).  Does not include the   |
 |      |                   | transmission of this alert.            |
 |    2 | taken-offline     | A system, computer, or user was taken  |
 |      |                   | offline, as when the computer is shut  |
 |      |                   | down or a user is logged off.          |
 |    3 | other             | Anything not in one of the above       |
 |      |                   | categories.                            |
 +------+-------------------+----------------------------------------+

Debar, et al. Experimental [Page 123] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Confidence
 IDMEF Attribute Name:  rating
 Registered Values:
 +------+---------+--------------------------------------------------+
 | Rank | Keyword | Description                                      |
 +------+---------+--------------------------------------------------+
 |    0 | low     | The analyzer has little confidence in its        |
 |      |         | validity                                         |
 |    1 | medium  | The analyzer has average confidence in its       |
 |      |         | validity                                         |
 |    2 | high    | The analyzer has high confidence in its validity |
 |    3 | numeric | The analyzer has provided a posterior            |
 |      |         | probability value indicating its confidence in   |
 |      |         | its validity                                     |
 +------+---------+--------------------------------------------------+
 IDMEF Class Name:  Node
 IDMEF Attribute Name:  category
 Registered Values:
    +------+----------+------------------------------------------+
    | Rank | Keyword  | Description                              |
    +------+----------+------------------------------------------+
    |    0 | unknown  | Domain unknown or not relevant           |
    |    1 | ads      | Windows 2000 Advanced Directory Services |
    |    2 | afs      | Andrew File System (Transarc)            |
    |    3 | coda     | Coda Distributed File System             |
    |    4 | dfs      | Distributed File System (IBM)            |
    |    5 | dns      | Domain Name System                       |
    |    6 | hosts    | Local hosts file                         |
    |    7 | kerberos | Kerberos realm                           |
    |    8 | nds      | Novell Directory Services                |
    |    9 | nis      | Network Information Services (Sun)       |
    |   10 | nisplus  | Network Information Services Plus (Sun)  |
    |   11 | nt       | Windows NT domain                        |
    |   12 | wfw      | Windows for Workgroups                   |
    +------+----------+------------------------------------------+

Debar, et al. Experimental [Page 124] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Address
 IDMEF Attribute Name:  category
 Registered Values:
 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | unknown       | Address type unknown                       |
 |    1 | atm           | Asynchronous Transfer Mode network address |
 |    2 | e-mail        | Electronic mail address (RFC 822)          |
 |    3 | lotus-notes   | Lotus Notes e-mail address                 |
 |    4 | mac           | Media Access Control (MAC) address         |
 |    5 | sna           | IBM Shared Network Architecture (SNA)      |
 |      |               | address                                    |
 |    6 | vm            | IBM VM ("PROFS") e-mail address            |
 |    7 | ipv4-addr     | IPv4 host address in dotted-decimal        |
 |      |               | notation (a.b.c.d)                         |
 |    8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation  |
 |    9 | ipv4-net      | IPv4 network address in dotted-decimal     |
 |      |               | notation, slash, significant bits          |
 |      |               | (a.b.c.d/nn)                               |
 |   10 | ipv4-net-mask | IPv4 network address in dotted-decimal     |
 |      |               | notation, slash, network mask in           |
 |      |               | dotted-decimal notation (a.b.c.d/w.x.y.z)  |
 |   11 | ipv6-addr     | IPv6 host address                          |
 |   12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation  |
 |   13 | ipv6-net      | IPv6 network address, slash, significant   |
 |      |               | bits                                       |
 |   14 | ipv6-net-mask | IPv6 network address, slash, network mask  |
 +------+---------------+--------------------------------------------+

Debar, et al. Experimental [Page 125] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  User
 IDMEF Attribute Name:  category
 Registered Values:
      +------+-------------+------------------------------------+
      | Rank | Keyword     | Description                        |
      +------+-------------+------------------------------------+
      |    0 | unknown     | User type unknown                  |
      |    1 | application | An application user                |
      |    2 | os-device   | An operating system or device user |
      +------+-------------+------------------------------------+
 IDMEF Class Name:  UserId
 IDMEF Attribute Name:  category
 Registered Values:
 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | current-user  | The current user id being used by the user |
 |      |               | or process.  On Unix systems, this would   |
 |      |               | be the "real" user id, in general.         |
 |    1 | original-user | The actual identity of the user or process |
 |      |               | being reported on.  On those systems that  |
 |      |               | (a) do some type of auditing and (b)       |
 |      |               | support extracting a user id from the      |
 |      |               | "audit id" token, that value should be     |
 |      |               | used.  On those systems that do not        |
 |      |               | support this, and where the user has       |
 |      |               | logged into the system, the "login id"     |
 |      |               | should be used.                            |
 |    2 | target-user   | The user id the user or process is         |
 |      |               | attempting to become.  This would apply,   |
 |      |               | on Unix systems for example, when the user |
 |      |               | attempts to use "su", "rlogin", "telnet",  |
 |      |               | etc.                                       |

Debar, et al. Experimental [Page 126] RFC 4765 The IDMEF March 2007

 |    3 | user-privs    | Another user id the user or process has    |
 |      |               | the ability to use, or a user id           |
 |      |               | associated with a file permission.  On     |
 |      |               | Unix systems, this would be the            |
 |      |               | "effective" user id in a user or process   |
 |      |               | context, and the owner permissions in a    |
 |      |               | file context.  Multiple UserId elements of |
 |      |               | this type may be used to specify a list of |
 |      |               | privileges.                                |
 |    4 | current-group | The current group id (if applicable) being |
 |      |               | used by the user or process.  On Unix      |
 |      |               | systems, this would be the "real" group    |
 |      |               | id, in general.                            |
 |    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            |
 |      |               | "effective" 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.     |
 +------+---------------+--------------------------------------------+
 IDMEF Class Name:  File
 IDMEF Attribute Name:  category
 Registered Values:
 +------+----------+-------------------------------------------------+
 | 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                                 |
 +------+----------+-------------------------------------------------+

Debar, et al. Experimental [Page 127] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  File
 IDMEF Attribute Name:  fstype
 Registered Values:
       +------+---------+-------------------------------------+
       | Rank | Keyword | Description                         |
       +------+---------+-------------------------------------+
       |    0 | ufs     | Berkeley Unix Fast File System      |
       |    1 | efs     | Linux "efs" file system             |
       |    2 | nfs     | Network File System                 |
       |    3 | afs     | Andrew File System                  |
       |    4 | ntfs    | Windows NT File System              |
       |    5 | fat16   | 16-bit Windows FAT File System      |
       |    6 | fat32   | 32-bit Windows FAT File System      |
       |    7 | pcfs    | "PC" (MS-DOS) file system on CD-ROM |
       |    8 | joliet  | Joliet CD-ROM file system           |
       |    9 | iso9660 | ISO 9660 CD-ROM file system         |
       +------+---------+-------------------------------------+
 IDMEF Class Name:  FileAccess
 IDMEF Attribute Name:  permission
 Registered Values:
 +------+-------------------+----------------------------------------+
 | Rank | Keyword           | Description                            |
 +------+-------------------+----------------------------------------+
 |    0 | noAccess          | No access at all is allowed for this   |
 |      |                   | user                                   |
 |    1 | read              | This user has read access to the file  |
 |    2 | write             | This user has write access to the file |
 |    3 | execute           | This user has the ability to execute   |
 |      |                   | the file                               |
 |    4 | search            | This user has the ability to search    |
 |      |                   | this file (applies to "execute"        |
 |      |                   | permission on directories in Unix)     |
 |    5 | delete            | This user has the ability to delete    |
 |      |                   | this file                              |
 |    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                 |
 +------+-------------------+----------------------------------------+

Debar, et al. Experimental [Page 128] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Linkage
 IDMEF Attribute Name:  category
 Registered Values:
 +------+---------------+--------------------------------------------+
 | Rank | Keyword       | Description                                |
 +------+---------------+--------------------------------------------+
 |    0 | hard-link     | The <name> element represents another name |
 |      |               | for this file.  This information may be    |
 |      |               | more easily obtainable on NTFS file        |
 |      |               | systems than others.                       |
 |    1 | mount-point   | An alias for the directory specified by    |
 |      |               | the parent's <name> and <path> elements.   |
 |    2 | reparse-point | Applies only to Windows; excludes symbolic |
 |      |               | links and mount points, which are specific |
 |      |               | types of reparse points.                   |
 |    3 | shortcut      | The file represented by a Windows          |
 |      |               | "shortcut".  A shortcut is distinguished   |
 |      |               | from a symbolic link because of the        |
 |      |               | difference in their contents, which may be |
 |      |               | of importance to the manager.              |
 |    4 | stream        | An Alternate Data Stream (ADS) in Windows; |
 |      |               | a fork on MacOS.  Separate file system     |
 |      |               | entity that is considered an extension of  |
 |      |               | the main <File>.                           |
 |    5 | symbolic-link | The <name> element represents the file to  |
 |      |               | which the link points.                     |
 +------+---------------+--------------------------------------------+

Debar, et al. Experimental [Page 129] RFC 4765 The IDMEF March 2007

 IDMEF Class Name:  Checksum
 IDMEF Attribute Name:  algorithm
 Registered Values:
    +------+----------+------------------------------------------+
    | Rank | Keyword  | Description                              |
    +------+----------+------------------------------------------+
    |    0 | MD4      | The MD4 algorithm.                       |
    |    1 | MD5      | The MD5 algorithm.                       |
    |    2 | SHA1     | The SHA1 algorithm.                      |
    |    3 | SHA2-256 | The SHA2 algorithm with 256 bits length. |
    |    4 | SHA2-384 | The SHA2 algorithm with 384 bits length. |
    |    5 | SHA2-512 | The SHA2 algorithm with 512 bits length. |
    |    6 | CRC-32   | The CRC algorithm with 32 bits length.   |
    |    7 | Haval    | The Haval algorithm.                     |
    |    8 | Tiger    | The Tiger algorithm.                     |
    |    9 | Gost     | The Gost algorithm.                      |
    +------+----------+------------------------------------------+

10.1.2. Registration Template

 IDMEF Class Name:
    <provide the name of the class that contains the attribute to
    which you want to add a new value, e.g., "Address">
 IDMEF Attribute Name:
    <provide the name of the attribute to which you want to add a new
    value, e.g., "category">
 New Attribute Value to Be Defined:
    <provide the name of the new attribute value that you want to add,
    e.g., "sneaker-net">
 Meaning of New Attribute Value:
    <describe in detail what the attribute value means -- i.e., if an
    analyzer sends this value, what is it telling the receiver of the
    information?>
 Contact Person and E-Mail Address:
    <your name and e-mail address>

Debar, et al. Experimental [Page 130] RFC 4765 The IDMEF March 2007

10.2. Adding New Attributes and Classes

 To the extent possible, the IDMEF classes and attributes specified in
 this document have been designed to accommodate 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.

11. References

11.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Wood, M. and M. Erlinger, "Intrusion Detection Mesage Exchange
       Requirements", RFC 4766, March 2007.

Debar, et al. Experimental [Page 131] RFC 4765 The IDMEF March 2007

 [3]   Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
       "Extensible Markup Language (XML) 1.0 (Second Edition)", World
       Wide Web Consortium
       FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006,
       October 2000.
 [4]   Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
       World Wide Web Consortium
       Recommendation http://www.w3.org/TR/1999/
       REC-xml-names-19990114, January 1999.
 [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
       Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
       January 2005.
 [6]   International Organization for Standardization, "Data elements
       and interchange formats - Information interchange -
       Representation of dates and times", ISO Standard 8601, Second
       Edition, December 2000.
 [7]   Mills, D., "Network Time Protocol (Version 3) Specification,
       Implementation", RFC 1305, March 1992.
 [8]   Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
       IPv4, IPv6 and OSI", RFC 4330, January 2006.
 [9]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434,
       October 1998.
 [10]  Phillips, A. and M. Davis, "Tags for Identifying Languages",
       BCP 47, RFC 4646, September 2006.

11.2. Informative References

 [11]  St. Johns, M., "Identification Protocol", RFC 1413,
       February 1993.
 [12]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
 [13]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
       Language) XML-Signature Syntax and Processing", RFC 3275,
       March 2002.
 [14]  Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
       Language Reference Model", ISBN 020130998X, 1998.

Debar, et al. Experimental [Page 132] RFC 4765 The IDMEF March 2007

 [15]  Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
       for Describing Simple Network Management Protocol (SNMP)
       Management Frameworks", STD 62, RFC 3411, December 2002.
 [16]  Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence
       between Version 1, Version 2, and Version 3 of the
       Internet-standard Network Management Framework", BCP 74,
       RFC 3584, August 2003.

Debar, et al. Experimental [Page 133] RFC 4765 The IDMEF March 2007

Appendix A. Acknowledgements

 The following individuals contributed substantially to this document
 and should be recognized for their efforts.  This document would not
 exist without their help:
 Dominique Alessandri, IBM Corporation
 Spencer Allain, Teknowledge Corporation
 James L. Burden, California Independent Systems Operator
 Marc Dacier, IBM Corporation
 Oliver Dain, MIT Lincoln Laboratory
 Nicolas Delon, Prelude Hybrid IDS project
 David J. Donahoo, AFIWC
 Michael Erlinger, Harvey Mudd College
 Reinhard Handwerker, Internet Security Systems, Inc.
 Ming-Yuh Huang, The Boeing Company
 Glenn Mansfield, Cyber Solutions, Inc.
 Joe McAlerney, Silicon Defense
 Cynthia McLain, MIT Lincoln Laboratory
 Paul Osterwald, Intrusion.com
 Jean-Philippe Pouzol
 James Riordan, IBM Corporation
 Paul Sangree, Cisco Systems
 Stephane Schitter, IBM Corporation
 Michael J. Slifcak, Trusted Network Technologies, Inc.
 Steven R. Snapp, CyberSafe Corporation
 Stuart Staniford-Chen, Silicon Defense
 Michael Steiner, University of Saarland
 Maureen Stillman, Nokia IP Telephony
 Vimal Vaidya, AXENT
 Yoann Vandoorselaere, Prelude Hybrid IDS project
 Andy Walther, Harvey Mudd College
 Andreas Wespi, IBM Corporation
 John C. C. White, MITRE
 Eric D. Williams, Information Brokers, Inc.
 S. Felix Wu, University of California Davis

Debar, et al. Experimental [Page 134] RFC 4765 The IDMEF March 2007

Appendix B. The IDMEF Schema Definition (Non-normative)

 <?xml version="1.0"?>
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:idmef="http://iana.org/idmef"
             targetNamespace="http://iana.org/idmef"
             elementFormDefault="qualified" >
   <xsd:annotation>
     <xsd:documentation>
       Intrusion Detection Message Exchange Format (IDMEF) Version 1.0
     </xsd:documentation>
   </xsd:annotation>
   <!-- Section 1 -->
   <!-- Omitted.  This section did namespace magic and is not
        needed with XSD validation. -->
   <!-- Section 2 -->
   <!--
     Values for the Action.category attribute.
   -->
   <xsd:simpleType name="action-category">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="block-installed"   />
       <xsd:enumeration value="notification-sent" />
       <xsd:enumeration value="taken-offline"     />
       <xsd:enumeration value="other"             />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
     Values for the Address.category attribute.
    -->
   <xsd:simpleType name="address-category">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="unknown"       />
       <xsd:enumeration value="atm"           />
       <xsd:enumeration value="e-mail"        />
       <xsd:enumeration value="lotus-notes"   />
       <xsd:enumeration value="mac"           />
       <xsd:enumeration value="sna"           />
       <xsd:enumeration value="vm"            />
       <xsd:enumeration value="ipv4-addr"     />
       <xsd:enumeration value="ipv4-addr-hex" />
       <xsd:enumeration value="ipv4-net"      />
       <xsd:enumeration value="ipv4-net-mask" />

Debar, et al. Experimental [Page 135] RFC 4765 The IDMEF March 2007

       <xsd:enumeration value="ipv6-addr"     />
       <xsd:enumeration value="ipv6-addr-hex" />
       <xsd:enumeration value="ipv6-net"      />
       <xsd:enumeration value="ipv6-net-mask" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the Impact.severity attribute.
    -->
   <xsd:simpleType name="impact-severity">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="info" />
       <xsd:enumeration value="low" />
       <xsd:enumeration value="medium" />
       <xsd:enumeration value="high" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
     Values for the Impact.completion attribute.
    -->
   <xsd:simpleType name="impact-completion">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="failed" />
       <xsd:enumeration value="succeeded" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the Impact.type attribute.
    -->
   <xsd:simpleType name="impact-type">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="admin" />
       <xsd:enumeration value="dos"   />
       <xsd:enumeration value="file"  />
       <xsd:enumeration value="recon" />
       <xsd:enumeration value="user"  />
       <xsd:enumeration value="other" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
     Values for the File.category attribute.
    -->
   <xsd:simpleType name="file-category">
     <xsd:restriction base="xsd:token">

Debar, et al. Experimental [Page 136] RFC 4765 The IDMEF March 2007

       <xsd:enumeration value="current"  />
       <xsd:enumeration value="original" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
     Values for the FileAccess.Permissions attribute
   -->
   <xsd:simpleType name="file-permission">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="noAccess"/>
       <xsd:enumeration value="read"/>
       <xsd:enumeration value="write"/>
       <xsd:enumeration value="execute"/>
       <xsd:enumeration value="search" />
       <xsd:enumeration value="delete" />
       <xsd:enumeration value="executeAs" />
       <xsd:enumeration value="changePermissions" />
       <xsd:enumeration value="takeOwnership" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
     Values for the Id.type attribute.
    -->
   <xsd:simpleType name="id-type">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="current-user"  />
       <xsd:enumeration value="original-user" />
       <xsd:enumeration value="target-user"   />
       <xsd:enumeration value="user-privs"    />
       <xsd:enumeration value="current-group" />
       <xsd:enumeration value="group-privs"   />
       <xsd:enumeration value="other-privs"   />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the Linkage.category attribute.
    -->
   <xsd:simpleType name="linkage-category">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="hard-link"     />
       <xsd:enumeration value="mount-point"   />
       <xsd:enumeration value="reparse-point" />
       <xsd:enumeration value="shortcut"      />
       <xsd:enumeration value="stream"        />
       <xsd:enumeration value="symbolic-link" />

Debar, et al. Experimental [Page 137] RFC 4765 The IDMEF March 2007

     </xsd:restriction>
   </xsd:simpleType>
   <!--
     | Values for the Checksum.algorithm attribute
   -->
   <xsd:simpleType name="checksum-algorithm">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="MD4" />
       <xsd:enumeration value="MD5" />
       <xsd:enumeration value="SHA1" />
       <xsd:enumeration value="SHA2-256" />
       <xsd:enumeration value="SHA2-384" />
       <xsd:enumeration value="SHA2-512" />
       <xsd:enumeration value="CRC-32" />
       <xsd:enumeration value="Haval" />
       <xsd:enumeration value="Tiger" />
       <xsd:enumeration value="Gost" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the Node.category attribute.
    -->
   <xsd:simpleType name="node-category">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="unknown"  />
       <xsd:enumeration value="ads"      />
       <xsd:enumeration value="afs"      />
       <xsd:enumeration value="coda"     />
       <xsd:enumeration value="dfs"      />
       <xsd:enumeration value="dns"      />
       <xsd:enumeration value="hosts"    />
       <xsd:enumeration value="kerberos" />
       <xsd:enumeration value="nds"      />
       <xsd:enumeration value="nis"      />
       <xsd:enumeration value="nisplus"  />
       <xsd:enumeration value="nt"       />
       <xsd:enumeration value="wfw"      />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the reference.origin attribute.
    -->
   <xsd:simpleType name="reference-origin">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="unknown" />

Debar, et al. Experimental [Page 138] RFC 4765 The IDMEF March 2007

       <xsd:enumeration value="vendor-specific" />
       <xsd:enumeration value="user-specific" />
       <xsd:enumeration value="bugtraqid" />
       <xsd:enumeration value="cve" />
       <xsd:enumeration value="osvdb" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the Confidence.rating attribute.
    -->
   <xsd:simpleType name="confidence-rating">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="low"    />
       <xsd:enumeration value="medium" />
       <xsd:enumeration value="high"   />
       <xsd:enumeration value="numeric" />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
    | Values for the User.category attribute.
    -->
   <xsd:simpleType name="user-category">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="unknown"     />
       <xsd:enumeration value="application" />
       <xsd:enumeration value="os-device"   />
     </xsd:restriction>
   </xsd:simpleType>
   <!--
   / Values for the additionaldata.type attribute.
   -->
   <xsd:simpleType name="additionaldata-type">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="boolean"     />
       <xsd:enumeration value="byte"        />
       <xsd:enumeration value="character"   />
       <xsd:enumeration value="date-time"   />
       <xsd:enumeration value="integer"     />
       <xsd:enumeration value="ntpstamp"    />
       <xsd:enumeration value="portlist"    />
       <xsd:enumeration value="real"        />
       <xsd:enumeration value="string"      />
       <xsd:enumeration value="byte-string" />
       <xsd:enumeration value="xml"         />
     </xsd:restriction>

Debar, et al. Experimental [Page 139] RFC 4765 The IDMEF March 2007

   </xsd:simpleType>
   <!--
    | Values for yes/no attributes such as Source.spoofed and
    | Target.decoy.
    -->
   <xsd:simpleType name="yes-no-type">
     <xsd:restriction base="xsd:token">
       <xsd:enumeration value="unknown" />
       <xsd:enumeration value="yes"     />
       <xsd:enumeration value="no"      />
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="port-range">
     <xsd:restriction base="xsd:string">
       <xsd:pattern value="[0-9]{1,5}(\-[0-9]{1,5})?"/>
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="port-list">
     <xsd:list itemType="idmef:port-range" />
   </xsd:simpleType>
   <xsd:simpleType name="ntpstamp">
     <xsd:restriction base="xsd:string">
       <xsd:pattern value="0x[A-Fa-f0-9]{8}.0x[A-Fa-f0-9]{8}"/>
     </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="mime-type">
     <xsd:restriction base="xsd:string">
     </xsd:restriction>
   </xsd:simpleType>
   <!-- Section 3: Top-level element declarations.  The IDMEF-Message
        element and the types of messages it can include. -->
   <xsd:complexType name="IDMEF-Message" >
     <xsd:choice minOccurs="1" maxOccurs="unbounded">
       <xsd:element ref="idmef:Alert"     />
       <xsd:element ref="idmef:Heartbeat" />
     </xsd:choice>
     <xsd:attribute name="version" type="xsd:decimal"
                    fixed="1.0" />
   </xsd:complexType>

Debar, et al. Experimental [Page 140] RFC 4765 The IDMEF March 2007

   <xsd:element name="IDMEF-Message" type="idmef:IDMEF-Message" />
   <xsd:complexType name="Alert">
     <xsd:sequence>
       <xsd:element name="Analyzer"
                    type="idmef:Analyzer" />
       <xsd:element name="CreateTime"
                    type="idmef:TimeWithNtpstamp" />
       <xsd:element name="DetectTime"
                    type="idmef:TimeWithNtpstamp"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="AnalyzerTime"
                    type="idmef:TimeWithNtpstamp"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Source"
                    type="idmef:Source"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="Target"
                    type="idmef:Target"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="Classification"
                    type="idmef:Classification" />
       <xsd:element name="Assessment"
                    type="idmef:Assessment"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:choice minOccurs="0" maxOccurs="1">
         <xsd:element name="ToolAlert"
                      type="idmef:ToolAlert" />
         <xsd:element name="OverflowAlert"
                      type="idmef:OverflowAlert" />
         <xsd:element name="CorrelationAlert"
                      type="idmef:CorrelationAlert" />
       </xsd:choice>
       <xsd:element name="AdditionalData"
                    type="idmef:AdditionalData"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="messageid"
                    type="xsd:string"
                    default="0" />
   </xsd:complexType>

Debar, et al. Experimental [Page 141] RFC 4765 The IDMEF March 2007

   <xsd:element name="Alert" type="idmef:Alert" />
   <xsd:complexType name="Heartbeat">
     <xsd:sequence>
       <xsd:element name="Analyzer" type="idmef:Analyzer" />
       <xsd:element name="CreateTime"
                    type="idmef:TimeWithNtpstamp" />
       <xsd:element name="HeartbeatInterval"
                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="AnalyzerTime"
                    type="idmef:TimeWithNtpstamp"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="AdditionalData"
                    type="idmef:AdditionalData"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="messageid"
                    type="xsd:string"
                    default="0" />
   </xsd:complexType>
   <xsd:element name="Heartbeat"
                type="idmef:Heartbeat" />
   <!-- Section 4: Subclasses of the Alert class that provide
        more data for specific types of alerts. -->
   <xsd:complexType name="CorrelationAlert">
     <xsd:sequence>
       <xsd:element name="name"
                    type="xsd:string" />
       <xsd:element name="alertident"
                    type="idmef:Alertident"
                    minOccurs="1"
                    maxOccurs="unbounded" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="OverflowAlert">
     <xsd:sequence>
       <xsd:element name="program"
                    type="xsd:string" />
       <xsd:element name="size"
                    type="xsd:string" />

Debar, et al. Experimental [Page 142] RFC 4765 The IDMEF March 2007

       <xsd:element name="buffer"
                    type="xsd:hexBinary" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="ToolAlert">
     <xsd:sequence>
       <xsd:element name="name"
                    type="xsd:string" />
       <xsd:element name="command"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="alertident"
                    type="idmef:Alertident"
                    minOccurs="1"
                    maxOccurs="unbounded" />
     </xsd:sequence>
   </xsd:complexType>
   <!-- Section 5: The AdditionalData element.  This element allows an
        alert to include additional information that cannot be encoded
        elsewhere in the data model. -->
   <xsd:complexType name="AdditionalData">
     <xsd:choice>
       <xsd:element name="boolean"
                    type="xsd:boolean" />
       <xsd:element name="byte"
                    type="xsd:byte" />
       <xsd:element name="character">
         <xsd:simpleType>
           <xsd:restriction base="xsd:string">
             <xsd:minLength value="1"/>
             <xsd:maxLength value="1"/>
           </xsd:restriction>
         </xsd:simpleType>
       </xsd:element>
       <xsd:element name="date-time"
                    type="xsd:dateTime" />
       <xsd:element name="integer"
                    type="xsd:integer" />
       <xsd:element name="ntpstamp"
                    type="idmef:ntpstamp" />
       <xsd:element name="portlist"
                    type="idmef:port-list" />
       <xsd:element name="real"
                    type="xsd:decimal" />

Debar, et al. Experimental [Page 143] RFC 4765 The IDMEF March 2007

       <xsd:element name="string"
                    type="xsd:string" />
       <xsd:element name="byte-string"
                    type="xsd:hexBinary" />
       <xsd:element name="xml"
                    type="idmef:xmltext" />
     </xsd:choice>
     <xsd:attribute name="type"
                    type="idmef:additionaldata-type" />
     <xsd:attribute name="meaning"
                    type="xsd:string" />
   </xsd:complexType>
   <!-- Section 6: Elements related to identifying entities -
        analyzers (the senders of these messages), sources (of
        attacks), and targets (of attacks). -->
   <xsd:complexType name="Analyzer">
     <xsd:sequence>
       <xsd:element name="Node"
                    type="idmef:Node"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Process"
                    type="idmef:Process"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Analyzer"
                    type="idmef:Analyzer"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
     <xsd:attribute name="analyzerid"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="name"
                    type="xsd:string" />
     <xsd:attribute name="manufacturer"
                    type="xsd:string" />
     <xsd:attribute name="model"
                    type="xsd:string" />
     <xsd:attribute name="version"
                    type="xsd:string" />
     <xsd:attribute name="class"
                    type="xsd:string" />
     <xsd:attribute name="ostype"
                    type="xsd:string" />
     <xsd:attribute name="osversion"

Debar, et al. Experimental [Page 144] RFC 4765 The IDMEF March 2007

                    type="xsd:string" />
   </xsd:complexType>
   <xsd:complexType name="Source">
     <xsd:sequence>
       <xsd:element name="Node"
                    type="idmef:Node"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="User"
                    type="idmef:User"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Process"
                    type="idmef:Process"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Service"
                    type="idmef:Service"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="spoofed"
                    type="idmef:yes-no-type"
                    default="unknown" />
     <xsd:attribute name="interface"
                    type="xsd:string" />
   </xsd:complexType>
   <xsd:complexType name="Target">
     <xsd:sequence>
       <xsd:element name="Node"
                    type="idmef:Node"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="User"
                    type="idmef:User"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Process"
                    type="idmef:Process"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Service"
                    type="idmef:Service"

Debar, et al. Experimental [Page 145] RFC 4765 The IDMEF March 2007

                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="File"
                    type="idmef:File"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="decoy"
                    type="idmef:yes-no-type"
                    default="unknown" />
     <xsd:attribute name="interface"
                    type="xsd:string" />
   </xsd:complexType>
   <!-- Section 7: Support elements used for providing detailed info
        about entities - addresses, names, etc. -->
   <xsd:complexType name="Address">
     <xsd:sequence>
       <xsd:element name="address"
                    type="xsd:string" />
       <xsd:element name="netmask"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="category"
                    type="idmef:address-category"
                    default="unknown" />
     <xsd:attribute name="vlan-name"
                    type="xsd:string" />
     <xsd:attribute name="vlan-num"
                    type="xsd:string" />
   </xsd:complexType>
   <xsd:complexType name="Assessment">
     <xsd:sequence>
       <xsd:element name="Impact"
                    type="idmef:Impact"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Action"

Debar, et al. Experimental [Page 146] RFC 4765 The IDMEF March 2007

                    type="idmef:Action"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="Confidence"
                    type="idmef:Confidence"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="Reference">
     <xsd:sequence>
       <xsd:element name="name"
                    type="xsd:string" />
       <xsd:element name="url"
                    type="xsd:string" />
     </xsd:sequence>
     <xsd:attribute name="origin"
                    type="idmef:reference-origin"
                    default="unknown" />
     <xsd:attribute name="meaning"
                    type="xsd:string" />
   </xsd:complexType>
   <xsd:complexType name="Classification">
     <xsd:sequence>
       <xsd:element name="Reference"
                    type="idmef:Reference"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="text"
                    type="xsd:string"
                    use="required" />
   </xsd:complexType>
   <xsd:complexType name="File">
     <xsd:sequence>
       <xsd:element name="name"
                    type="xsd:string" />
       <xsd:element name="path"
                    type="xsd:string" />
       <xsd:element name="create-time"
                    type="xsd:dateTime"
                    minOccurs="0"
                    maxOccurs="1" />

Debar, et al. Experimental [Page 147] RFC 4765 The IDMEF March 2007

       <xsd:element name="modify-time"
                    type="xsd:dateTime"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="access-time"
                    type="xsd:dateTime"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="data-size"
                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="disk-size"
                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="FileAccess"
                    type="idmef:FileAccess"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="Linkage"
                    type="idmef:Linkage"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="Inode"
                    type="idmef:Inode"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="Checksum"
                    type="idmef:Checksum"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="category"
                    type="idmef:file-category"
                    use="required" />
     <xsd:attribute name="fstype"
                    type="xsd:string"
                    use="required" />
     <xsd:attribute name="file-type"
                    type="idmef:mime-type" />
   </xsd:complexType>
   <xsd:complexType name="Permission">
     <xsd:attribute name="perms"

Debar, et al. Experimental [Page 148] RFC 4765 The IDMEF March 2007

                    type="idmef:file-permission"
                    use="required" />
   </xsd:complexType>
   <xsd:complexType name="FileAccess">
     <xsd:sequence>
       <xsd:element name="UserId"
                    type="idmef:UserId" />
       <xsd:element name="permission"
                    type="idmef:Permission"
                    minOccurs="1"
                    maxOccurs="unbounded" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="Inode">
     <xsd:sequence>
       <xsd:element name="change-time"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:sequence minOccurs="0" maxOccurs="1">
         <xsd:element name="number"
                      type="xsd:string" />
         <xsd:element name="major-device"
                      type="xsd:string" />
         <xsd:element name="minor-device"
                      type="xsd:string" />
       </xsd:sequence>
       <xsd:sequence minOccurs="0" maxOccurs="1">
         <xsd:element name="c-major-device"
                      type="xsd:string" />
         <xsd:element name="c-minor-device"
                      type="xsd:string" />
       </xsd:sequence>
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="Linkage">
     <xsd:choice>
       <xsd:sequence>
         <xsd:element name="name" type="xsd:string" />
         <xsd:element name="path" type="xsd:string" />
       </xsd:sequence>
       <xsd:element name="File" type="idmef:File" />
     </xsd:choice>
     <xsd:attribute name="category"
                    type="idmef:linkage-category"

Debar, et al. Experimental [Page 149] RFC 4765 The IDMEF March 2007

                    use="required" />
   </xsd:complexType>
   <xsd:complexType name="Checksum">
     <xsd:sequence>
       <xsd:element name="value"
                    type="xsd:string" />
       <xsd:element name="key"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
     <xsd:attribute name="algorithm"
                    type="idmef:checksum-algorithm"
                    use="required" />
   </xsd:complexType>
   <xsd:complexType name="Node">
     <xsd:sequence>
       <xsd:element name="location"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:choice>
         <xsd:element name="name"
                      type="xsd:string" />
         <xsd:element name="Address"
                      type="idmef:Address" />
       </xsd:choice>
       <xsd:element name="Address"
                    type="idmef:Address"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="category"
                    type="idmef:node-category"
                    default="unknown" />
   </xsd:complexType>
   <xsd:complexType name="Process">
     <xsd:sequence>
       <xsd:element name="name"
                    type="xsd:string" />
       <xsd:element name="pid"
                    type="xsd:integer"

Debar, et al. Experimental [Page 150] RFC 4765 The IDMEF March 2007

                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="path"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="arg"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="unbounded" />
       <xsd:element name="env"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
   </xsd:complexType>
   <xsd:complexType name="Service">
     <xsd:sequence>
       <xsd:choice>
         <xsd:sequence>
           <xsd:element name="name"
                        type="xsd:string" />
           <xsd:element name="port"
                        type="xsd:integer"
                        minOccurs="0"
                        maxOccurs="1" />
         </xsd:sequence>
         <xsd:sequence>
           <xsd:element name="port"
                        type="xsd:integer" />
           <xsd:element name="name"
                        type="xsd:string"
                        minOccurs="0"
                        maxOccurs="1" />
         </xsd:sequence>
         <xsd:element name="portlist"
                      type="idmef:port-list" />
       </xsd:choice>
       <xsd:element name="protocol"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="SNMPService"
                    type="idmef:SNMPService"

Debar, et al. Experimental [Page 151] RFC 4765 The IDMEF March 2007

                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="WebService"
                    type="idmef:WebService"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="ip_version"
                    type="xsd:integer" />
     <xsd:attribute name="iana_protocol_number"
                    type="xsd:integer" />
     <xsd:attribute name="iana_protocol_name"
                    type="xsd:string" />
   </xsd:complexType>
   <xsd:complexType name="WebService">
     <xsd:sequence>
       <xsd:element name="url"
                    type="xsd:anyURI" />
       <xsd:element name="cgi"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="http-method"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="arg"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="unbounded" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="SNMPService">
     <xsd:sequence>
       <xsd:element name="oid"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="messageProcessingModel"
                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="securityModel"

Debar, et al. Experimental [Page 152] RFC 4765 The IDMEF March 2007

                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="securityName"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="securityLevel"
                    type="xsd:integer"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="contextName"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="contextEngineID"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
       <xsd:element name="command"
                    type="xsd:string"
                    minOccurs="0"
                    maxOccurs="1" />
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="User">
     <xsd:sequence>
       <xsd:element name="UserId"
                    type="idmef:UserId"
                    minOccurs="1"
                    maxOccurs="unbounded" />
     </xsd:sequence>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="category"
                    type="idmef:user-category"
                    default="unknown" />
   </xsd:complexType>
   <xsd:complexType name="UserId" >
     <xsd:choice>
       <xsd:sequence>
         <xsd:element name="name"
                      type="xsd:string" />
         <xsd:element name="number"
                      type="xsd:integer"

Debar, et al. Experimental [Page 153] RFC 4765 The IDMEF March 2007

                      minOccurs="0"
                      maxOccurs="1" />
       </xsd:sequence>
       <xsd:sequence>
         <xsd:element name="number"
                      type="xsd:integer" />
         <xsd:element name="name"
                      type="xsd:string"
                      minOccurs="0"
                      maxOccurs="1" />
       </xsd:sequence>
     </xsd:choice>
     <xsd:attribute name="ident"
                    type="xsd:string"
                    default="0" />
     <xsd:attribute name="type"
                    type="idmef:id-type"
                    default="original-user" />
     <xsd:attribute name="tty"
                    type="xsd:string" />
   </xsd:complexType>
   <!-- Section 8: Simple elements with sub-elements or attributes
        of a special nature. -->
   <xsd:complexType name="Action">
     <xsd:simpleContent>
       <xsd:extension base="xsd:string" >
         <xsd:attribute name="category"
                        type="idmef:action-category"
                        default="other" />
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="Confidence">
     <xsd:simpleContent>
       <xsd:extension base="xsd:string" >
         <xsd:attribute name="rating"
                        type="idmef:confidence-rating"
                        use="required" />
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="TimeWithNtpstamp">
     <xsd:simpleContent>
       <xsd:extension base="xsd:dateTime">

Debar, et al. Experimental [Page 154] RFC 4765 The IDMEF March 2007

         <xsd:attribute name="ntpstamp"
                        type="idmef:ntpstamp"
                        use="required"/>
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="Impact">
     <xsd:simpleContent>
       <xsd:extension base="xsd:string" >
         <xsd:attribute name="severity"
                        type="idmef:impact-severity" />
         <xsd:attribute name="completion"
                        type="idmef:impact-completion" />
         <xsd:attribute name="type" type="idmef:impact-type"
                        default="other" />
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="Alertident">
     <xsd:simpleContent>
       <xsd:extension base="xsd:string" >
         <xsd:attribute name="analyzerid"
                        type="xsd:string" />
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
   <xsd:complexType name="xmltext">
     <xsd:complexContent mixed="true">
       <xsd:restriction base="xsd:anyType">
         <xsd:sequence>
           <xsd:any namespace="##other"
                    processContents="lax"
                    minOccurs="0"
                    maxOccurs="unbounded" />
         </xsd:sequence>
       </xsd:restriction>
     </xsd:complexContent>
   </xsd:complexType>
 </xsd:schema>

Debar, et al. Experimental [Page 155] RFC 4765 The IDMEF March 2007

Authors' Addresses

 Herve Debar
 France Telecom R & D
 42 Rue des Coutures
 Caen  14000
 FR
 Phone: +33 2 31 75 92 61
 EMail: herve.debar@orange-ftgroup.com
 URI:   http://www.francetelecom.fr/
 David A. Curry
 Guardian Life Insurance Company of America
 7 Hanover Square, 24th Floor
 New York, NY  10004
 US
 Phone: +1 212 919-3086
 EMail: david_a_curry@glic.com
 URI:   http://www.glic.com/
 Benjamin S. Feinstein
 SecureWorks, Inc.
 PO Box 95007
 Atlanta, GA 30347
 US
 Phone: +1 404 327-6339
 Email: bfeinstein@acm.org
 URI:   http://www.secureworks.com/

Debar, et al. Experimental [Page 156] RFC 4765 The IDMEF March 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Debar, et al. Experimental [Page 157]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4765.txt · Last modified: 2007/03/08 22:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki