From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4765.txt | 8795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 8795 insertions(+) create mode 100644 doc/rfc/rfc4765.txt (limited to 'doc/rfc/rfc4765.txt') diff --git a/doc/rfc/rfc4765.txt b/doc/rfc/rfc4765.txt new file mode 100644 index 0000000..7a849ed --- /dev/null +++ b/doc/rfc/rfc4765.txt @@ -0,0 +1,8795 @@ + + + + + + +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 "

" 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: + + + + + + + + + + +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 | + +-----------+------------------+ + | & | & | + | | | + | < | < | + | | | + | > | > | + | | | + | " | " | + | | | + | ' | ' | + +-----------+------------------+ + +3.2.3.2. Character Code References + + Any character defined by the ISO/IEC 10646 and Unicode standards may + be included in an XML document by the use of a character reference. + A character reference is started with the characters '&' and '#', and + ended with the character ';'. Between these characters, the + character code for the character is inserted. + + If the character code is preceded by an 'x' it is interpreted in + hexadecimal (base 16); otherwise, it is interpreted in decimal (base + 10). For instance, the ampersand (&) is encoded as & or & + and the less-than sign (<) is encoded as < or <. + + + + + +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: + + + + + 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: + + + + +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. + + + + +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: + + + + +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: + + + + + 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: + + + + + 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: + + + + + 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: + + + + + 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: + + + + + 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: + + + + + + +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: + + + + + + + + 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: + + + + + + + + + + + + + + The DATETIME format of the 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 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: + + + + + + + + + + + + + + + + + + + +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: + + + + + + + + + + + + + +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: + + + + + + + + +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: + + + + + + + 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 + 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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: + + + + + + + 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: + + + + + + + + + + + + + + + +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: + + + + + + + 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: + + + + + 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 + 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: + + + + + + + + + + +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: + + + + +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: + + + + + + + + +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 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: + + + + + + + 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: + + + + + + +4.2.7.6.2. The Linkage Class + + The Linkage class represents file system connections between the file + described in the element and other objects in the file system. + For example, if the element is a symbolic link or shortcut, + then the element should contain the name of the object the + link points to. Further information can be provided about the object + in the element with another 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 element may be used in place of the + and elements if additional information about the file is to + be included. + + This is represented in the IDMEF DTD as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 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 and 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 . | + | 5 | symbolic-link | The 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 , , and must be given + together, and the and must be given + together. + + This is represented in the IDMEF DTD as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + +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: + + + + + + + + + + + +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 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. + + + + + ... + + + + content element of example + + + + + + + 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., "") 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 element, which may be used to perform + rudimentary time synchronization (see below). + + 3. IDMEF-compliant applications SHOULD permit the user to enable/ + disable the method of time synchronization as a + configuration option. + + A number of caveats apply to the use of for time + synchronization: + + 1. 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 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, 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 + 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 + element of the message. This difference should + then be used to adjust the times in the and + 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 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. + + + + + + + + Headquarters DMZ Network + analyzer01.example.com + + + + 2000-03-09T10:01:25.93464-05:00 + + + + badguy.example.net + + 192.0.2.50 + 255.255.255.255 + + + + + + + 0xde796f70 + + + + + + 124 + http://www.securityfocus.com/bid/124 + + + + + + +Debar, et al. Experimental [Page 86] + +RFC 4765 The IDMEF March 2007 + + + + +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. + + + + + + + + sensor.example.com + + + + 2000-03-09T10:01:25.93464Z + + + + + 192.0.2.200 + + + + + + + 192.0.2.50 + + + + + + lollipop + + + + + Cabinet B10 + Cisco.router.b10 + + + + + +Debar, et al. Experimental [Page 87] + +RFC 4765 The IDMEF March 2007 + + + + + CVE-1999-128 + http://www.cve.mitre.org/cgi-bin/ + cvename.cgi?name=CVE-1999-128 + + + + + +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]). + + + + + + + + sensor.example.com + + + + 2000-03-09T18:47:25+02:00 + + + + + 192.0.2.200 + + + + + badguy + + + + 31532 + + + +Debar, et al. Experimental [Page 88] + +RFC 4765 The IDMEF March 2007 + + + + + + + myhost + + 192.0.2.50 + + + + finger + 79 + + + + + finger + http://www.vendor.com/finger + + + Distributed attack + http://www.vendor.com/distributed + + + + + +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 to show the ports + that were scanned. + + + + + + + + Headquarters Web Server + analyzer62.example.com + + + + 2000-03-09T15:31:00-08:00 + + + +Debar, et al. Experimental [Page 89] + +RFC 4765 The IDMEF March 2007 + + + + + + + 192.0.2.200 + + + + + + www.example.com + + 192.0.2.50 + + + + 5-25,37,42,43,53,69-119,123-514 + + + + + + portscan + http://www.vendor.com/portscan + + + + + +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 and + to identify the user attempting the exploit and how he's + doing it. + + + + + + + + +Debar, et al. Experimental [Page 90] + +RFC 4765 The IDMEF March 2007 + + + + + fileserver.example.com + + + monitor + 8956 + monitor + -d + -m + idmanager.example.com + -l + /var/logs/idlog + + + + 2000-03-09T08:12:32.3-05:00 + + + + + joe + 13243 + + + + loadmodule + /usr/openwin/bin + + + + + fileserver.example.com + + + + + 33 + http://www.securityfocus.com + + + + + + + + + + +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: + + + + + + + + fileserver.example.com + + + monitor + 8956 + monitor + -d + -m + idmanager.example.com + -l + /var/logs/idlog + + + + 2000-03-09T08:12:32.3-05:00 + + + + + joe + 13243 + + + + loadmodule + /usr/openwin/bin + + + + + fileserver.example.com + + + + root + 0 + + + + +Debar, et al. Experimental [Page 92] + +RFC 4765 The IDMEF March 2007 + + + + + sh + 25134 + /bin/sh + + + + + + + + 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 + element to provide more details about this particular + attack. + + + + + + + + sensor.example.com + + + + 2000-03-09T08:12:32-01:00 + + + + + 192.0.2.200 + + + + 21534 + + + + + www.example.com + + + +Debar, et al. Experimental [Page 93] + +RFC 4765 The IDMEF March 2007 + + + + 192.0.2.100 + + + + 8080 + + + http://www.example.com/cgi-bin/phf?/etc/group + + /cgi-bin/phf + GET + + + + + + 629 + + http://www.securityfocus.com/bid/629 + + + + + + +7.3.3. File Modification + + Host-based detection of a race condition attack. Note the use of the + to provide information about the files that are used to + perform the attack. + + + + + + + + etude + + 192.0.2.1 + + + + + + +Debar, et al. Experimental [Page 94] + +RFC 4765 The IDMEF March 2007 + + + + 2000-03-09T08:12:32-01:00 + + + + console + + 192.0.2.1 + + + + + + local + + 192.0.2.1 + + + + + 456 + + + fred + 456 + + + 456 + + + + xxx000238483 + /tmp/xxx000238483 + + + alice + 777 + + + + + + + + + user + 42 + + + + +Debar, et al. Experimental [Page 95] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + world + + + + + passwd + /etc/passwd + + + + + + DOM race condition + file://attack-info/race.html + + + + + + +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 to provide + information about the policy being violated. + + + + + + + + dialserver.example.com + + + + 2000-03-09T22:18:07-05:00 + + + + + + +Debar, et al. Experimental [Page 96] + +RFC 4765 The IDMEF March 2007 + + + + 127.0.0.1 + + + + 4325 + + + + + mainframe.example.com + + + + louis + 501 + + + + login + 23 + + + + + out-of-hours activity + http://my.company.com/policies + + + + + 2000-03-09T07:00:00-05:00 + + + 2000-03-09T19:30:00-05:00 + + + + + + + + + + + + + + +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. + + + + + + + + correlator01.example.com + + + + 2000-03-09T15:31:07Z + + + + + 192.0.2.200 + + + + + + www.example.com + + 192.0.2.50 + + + + 5-25,37,42,43,53,69-119,123-514 + + + + + + portscan + http://www.vendor.com/portscan + + + + multiple ports in short time + 123456781 + 123456782 + + + +Debar, et al. Experimental [Page 98] + +RFC 4765 The IDMEF March 2007 + + + 123456783 + 123456784 + 123456785 + 123456786 + 987654321 + + 987654322 + + + + + +7.6. Analyzer Assessments + + Host-based detection of a successful unauthorized acquisition of root + access through the eject buffer overflow. Note the use of + to provide information about the analyzer's evaluation + of and reaction to the attack. + + + + + + + + + 2000-03-09T08:12:32-01:00 + + + + console + + 192.0.2.1 + + + + + + local + + 192.0.2.1 + + + + + 456 + + + + +Debar, et al. Experimental [Page 99] + +RFC 4765 The IDMEF March 2007 + + + + root + 0 + + + 0 + + + + eject + 32451 + /usr/bin/eject + \x90\x80\x3f\xff...\x08/bin/sh + + + + + Unauthorized user to superuser + file://attack-info/u2s.html + + + + + + page + + + disabled user (fred) + + + logout user (fred) + + + + + + +7.7. Heartbeat + + This example shows a Heartbeat message that provides "I'm alive and + working" information to the manager. Note the use of + elements, with "meaning" attributes, to provide some + additional information. + + + + + + +Debar, et al. Experimental [Page 100] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + Headquarters DMZ Network + analyzer01.example.com + + + + 2000-03-09T14:07:58Z + + + 62.5 + + + 87.1 + + + + +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: + + + + + + Intrusion Detection Message Exchange Format (IDMEF) Extension + for geographic information + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + Headquarters DMZ Network + analyzer01.example.com + + + + 2000-03-09T10:01:25.93464-05:00 + + + + +Debar, et al. Experimental [Page 102] + +RFC 4765 The IDMEF March 2007 + + + + + badguy.example.net + + 192.0.2.50 + 255.255.255.255 + + + + + + + 0xde796f70 + + + + + + 124 + http://www.securityfocus.com/bid/124 + + + + + + 38.89 + -77.02 + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 103] + +RFC 4765 The IDMEF March 2007 + + +8. The IDMEF Document Type Definition (Normative) + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 104] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 105] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 107] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 110] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 111] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 114] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 115] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 116] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 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 and 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 . | + | 5 | symbolic-link | The 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: + + + + IDMEF Attribute Name: + + + + New Attribute Value to Be Defined: + + + + Meaning of New Attribute Value: + + + + Contact Person 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) + + + + + + + Intrusion Detection Message Exchange Format (IDMEF) Version 1.0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 135] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 136] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 137] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 138] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 139] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 140] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 141] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 142] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 143] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 147] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Debar, et al. Experimental [Page 154] + +RFC 4765 The IDMEF March 2007 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3