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
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.
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.
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.
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.
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.
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.
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.
The Extensible Markup Language (XML) [3] is a simplified version of the Standard Generalized Markup Language (SGML), a syntax for specifying text markup defined by the ISO 8879 standard. XML is gaining widespread attention as a language for representing and exchanging documents and data on the Internet, and as the solution to most of the problems inherent in HyperText Markup Language (HTML). XML was published as a recommendation by the World Wide Web Consortium (W3C) on February 10, 1998.
XML is a metalanguage -- a language for describing other languages -- that enables an application to define its own markup. XML allows the definition of customized markup languages for different types of documents and different applications. This differs from HTML, in which there is a fixed set of identifiers with preset meanings that must be "adapted" for specialized uses. Both XML and HTML use elements (tags) (identifiers delimited by '<' and '>') and attributes
Debar, et al. Experimental [Page 7]
RFC 4765 The IDMEF March 2007
(of the form "name='value'"). But where "<p>" always means "paragraph" in HTML, it may mean "paragraph", "person", "price", or "platypus" in XML, or it might have no meaning at all, depending on the particular application.
NOTE: XML provides both a syntax for declaring document markup and structure (i.e., defining elements and attributes, specifying the order in which they appear, and so on) and a syntax for using that markup in documents. Because markup declarations look radically different from markup, many people are confused as to which syntax is called XML. The answer is that they both are, because they are actually both part of the same language.
For clarity in this document, we will use the terms "XML" and "XML documents" when speaking in the general case, and the term "IDMEF markup" when speaking specifically of the elements (tags) and attributes that describe IDMEF messages.
The publication of XML was followed by the publication of a second recommendation [4] by the World Wide Web Consortium, defining the use of namespaces in XML documents. An XML namespace is a collection of names, identified by a Uniform Resource Identifier (URI) [5]. When using namespaces, each tag is identified with the namespace it comes from, allowing tags from different namespaces with the same names to occur in the same document. For example, a single document could contain both "usa:football" and "europe:football" tags, each with different meanings.
In anticipation of the widespread use of XML namespaces, this memo includes the definition of the URI to be used to identify the IDMEF namespace.
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.
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".
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.
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.
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.
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).
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.
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].
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.
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".
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.
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.
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:
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.
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:
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:
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.
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".
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.
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.
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.
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".
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
Zero or one. Information about the host or device on which the analyzer resides (network address, network name, etc.).
Process
Zero or one. Information about the process in which the analyzer is executing.
Analyzer
Zero or one. Information about the analyzer from which the message may have gone through. The idea behind this mechanism is that when a manager receives an alert and wants to forward it to another analyzer, it needs to substitute the original analyzer
Debar, et al. Experimental [Page 30]
RFC 4765 The IDMEF March 2007
information with its own. To preserve the original analyzer information, it may be included in the new analyzer definition. This will allow analyzer path tracking.
This is represented in the IDMEF DTD as follows:
<!ELEMENT Analyzer ( Node?, Process?, Analyzer? )> <!ATTLIST Analyzer analyzerid CDATA '0' name CDATA #IMPLIED manufacturer CDATA #IMPLIED model CDATA #IMPLIED version CDATA #IMPLIED class CDATA #IMPLIED ostype CDATA #IMPLIED osversion CDATA #IMPLIED %attlist.global; >
The Analyzer class has eight attributes:
analyzerid
Optional (but see below). A unique identifier for the analyzer; see Section 3.2.9.
This attribute is only "partially" optional. If the analyzer makes use of the "ident" attributes on other classes to provide unique identifiers for those objects, then it MUST also provide a valid "analyzerid" attribute. This requirement is dictated by the uniqueness requirements of the "ident" attribute (they are unique only within the context of a particular "analyzerid"). If the analyzer does not make use of the "ident" attributes, however, it may also omit the "analyzerid" attribute.
name
Optional. An explicit name for the analyzer that may be easier to understand than the analyzerid.
manufacturer
Optional. The manufacturer of the analyzer software and/or hardware.
Debar, et al. Experimental [Page 31]
RFC 4765 The IDMEF March 2007
model
Optional. The model name/number of the analyzer software and/or hardware.
version
Optional. The version number of the analyzer software and/or hardware.
class
Optional. The class of analyzer software and/or hardware.
ostype
Optional. Operating system name. On POSIX 1003.1 compliant systems, this is the value returned in utsname.sysname by the uname() system call, or the output of the "uname -s" command.
osversion
Optional. Operating system version. On POSIX 1003.1 compliant systems, this is the value returned in utsname.release by the uname() system call, or the output of the "uname -r" command.
The "manufacturer", "model", "version", and "class" attributes' contents are vendor-specific, but may be used together to identify different types of analyzers (and perhaps make determinations about the contents to expect in other vendor-specific fields of IDMEF messages).
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.
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.
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.
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.
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.
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:
<!ATTLIST AdditionalData type %attvals.adtype; 'string' meaning CDATA #IMPLIED %attlist.global; >
The AdditionalData class has one attribute:
meaning
Optional. A string describing the meaning of the element content. These values will be vendor/implementation dependent; the method for ensuring that managers understand the strings sent by analyzers is outside the scope of this specification. A list of acceptable meaning keywords is not within the scope of the document, although later versions may undertake to establish such a list.
The DATETIME format of the <CreateTime> element content is described in Section 3.2.6.
If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used.
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).
The AnalyzerTime class is used to indicate the current date and time on the analyzer. Its values should be filled in as late as possible in the message transmission process, ideally immediately before placing the message "on the wire".
The use of <AnalyzerTime> to perform rudimentary time synchronization between analyzers and managers is discussed in Section 6.3.
The Impact class is used to provide the analyzer's assessment of the impact of the event on the target(s). It is represented in the IDMEF DTD as follows:
<!ENTITY % attvals.severity " ( info | low | medium | high ) "> <!ENTITY % attvals.completion " ( failed | succeeded ) "> <!ENTITY % attvals.impacttype " ( admin | dos | file | recon | user | other ) ">
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.
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.
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.
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.
Required. The source from which the name of the alert originates. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.)
+------+-----------------+------------------------------------------+ | Rank | Keyword | Description | +------+-----------------+------------------------------------------+ | 0 | unknown | Origin of the name is not known | | | | | | 1 | vendor-specific | A vendor-specific name (and hence, URL); | | | | this can be used to provide | | | | product-specific information | | | | | | 2 | user-specific | A user-specific name (and hence, URL); | | | | this can be used to provide | | | | installation-specific information | | | | | | 3 | bugtraqid | The SecurityFocus ("Bugtraq") | | | | vulnerability database identifier | | | | (http://www.securityfocus.com/bid) | | | | | | 4 | cve | The Common Vulnerabilities and Exposures | | | | (CVE) name (http://www.cve.mitre.org/) | | | | | | 5 | osvdb | The Open Source Vulnerability Database | | | | (http://www.osvdb.org) | +------+-----------------+------------------------------------------+
Debar, et al. Experimental [Page 48]
RFC 4765 The IDMEF March 2007
meaning
Optional. The meaning of the reference, as understood by the alert provider. This field is only valid if the value of the <origin> attribute is set to "vendor-specific" or "user-specific".
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 | +------+----------+------------------------------------------+
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.)
<!ELEMENT User ( UserId+ )> <!ATTLIST User ident CDATA '0' category %attvals.usercat; 'unknown' %attlist.global; >
Debar, et al. Experimental [Page 55]
RFC 4765 The IDMEF March 2007
The User class has two attributes:
ident
Optional. A unique identifier for the user; see Section 3.2.9.
category
Optional. The type of user represented. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 10.)
+------+-------------+------------------------------------+ | Rank | Keyword | Description | +------+-------------+------------------------------------+ | 0 | unknown | User type unknown | | | | | | 1 | application | An application user | | | | | | 2 | os-device | An operating system or device user | +------+-------------+------------------------------------+
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.
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. | +------+---------------+--------------------------------------------+
Exactly one. STRING. The name of the program being executed. This is a short name; path and argument information are provided elsewhere.
pid
Zero or one. INTEGER. The process identifier of the process.
path
Zero or one. STRING. The full path of the program being executed.
arg
Zero or more. STRING. A command-line argument to the program. Multiple arguments may be specified (they are assumed to have occurred in the same order they are provided) with multiple uses of arg.
env
Zero or more. STRING. An environment string associated with the process; generally of the format "VARIABLE=value". Multiple environment strings may be specified with multiple uses of env.
This is represented in the IDMEF DTD as follows:
<!ELEMENT Process ( name, pid?, path?, arg*, env* )> <!ATTLIST Process ident CDATA '0' %attlist.global; >
The Process class has one attribute:
ident
Optional. A unique identifier for the process; see Section 3.2.9.
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.
Zero or one. STRING. The name of the service. Whenever possible, the name from the IANA list of well-known ports SHOULD be used.
port
Zero or one. INTEGER. The port number being used.
portlist
Zero or one. PORTLIST. A list of port numbers being used; see Section 3.2.8 for formatting rules. If a portlist is given, the iana_protocol_number and iana_protocol_name MUST apply to all the elements of the list.
protocol
Zero or one. STRING. Additional information about the protocol being used. The intent of the protocol field is to carry additional information related to the protocol being used when the <Service> attributes iana_protocol_number or/and iana_protocol_name are filed.
A Service MUST be specified as either (a) a name or a port or (b) a portlist. The protocol is optional in all cases, but no other combinations are permitted.
Service is represented in the IDMEF DTD as follows:
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.
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.
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.
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.
Exactly one. STRING. The name of the file to which the alert applies, not including the path to the file.
path
Exactly one. STRING. The full path to the file, including the name. The path name should be represented in as "universal" a manner as possible, to facilitate processing of the alert.
For Windows systems, the path should be specified using the Universal Naming Convention (UNC) for remote files, and using a drive letter for local files (e.g., "C:\boot.ini"). For Unix systems, paths on network file systems should use the name of the mounted resource instead of the local mount point (e.g., "fileserver:/usr/local/bin/foo"). The mount point can be provided using the <Linkage> element.
create-time
Zero or one. DATETIME. Time the file was created. Note that this is *not* the Unix "st_ctime" file attribute (which is not file creation time). The Unix "st_ctime" attribute is contained in the "Inode" class.
modify-time
Zero or one. DATETIME. Time the file was last modified.
access-time
Zero or one. DATETIME. Time the file was last accessed.
data-size
Zero or one. INTEGER. The size of the data, in bytes. Typically what is meant when referring to file size. On Unix UFS file systems, this value corresponds to stat.st_size. On Windows NTFS, this value corresponds to Valid Data Length (VDL).
Debar, et al. Experimental [Page 68]
RFC 4765 The IDMEF March 2007
disk-size
Zero or one. INTEGER. The physical space on disk consumed by the file, in bytes. On Unix UFS file systems, this value corresponds to 512 * stat.st_blocks. On Windows NTFS, this value corresponds to End of File (EOF).
FileAccess
Zero or more. Access permissions on the file.
Linkage
Zero or more. File system objects to which this file is linked (other references for the file).
Inode
Zero or one. Inode information for this file (relevant to Unix).
Checksum
Zero or more. Checksum information for this file.
This is represented in the IDMEF DTD as follows:
<!ENTITY % attvals.filecat " ( current | original ) ">
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 | +------+---------+-------------------------------------+
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.
The Linkage class represents file system connections between the file described in the <File> element and other objects in the file system. For example, if the <File> element is a symbolic link or shortcut, then the <Linkage> element should contain the name of the object the link points to. Further information can be provided about the object in the <Linkage> element with another <File> element, if appropriate.
The Linkage class is composed of three aggregate classes, as shown in Figure 24.
Exactly one. STRING. The name of the file system object, not including the path.
Debar, et al. Experimental [Page 73]
RFC 4765 The IDMEF March 2007
path
Exactly one. STRING. The full path to the file system object, including the name. The path name should be represented in as "universal" a manner as possible, to facilitate processing of the alert.
File
Exactly one. A <File> element may be used in place of the <name> and <path> elements if additional information about the file is to be included.
The type of object that the link describes. The permitted values are shown below. There is no default value. (See also Section 10.)
+------+---------------+--------------------------------------------+ | Rank | Keyword | Description | +------+---------------+--------------------------------------------+ | 0 | hard-link | The <name> element represents another name | | | | for this file. This information may be | | | | more easily obtainable on NTFS file | | | | systems than others. | | | | | | 1 | mount-point | An alias for the directory specified by | | | | the parent's <name> and <path> elements. | | | | | | 2 | reparse-point | Applies only to Windows; excludes symbolic | | | | links and mount points, which are specific | | | | types of reparse points. | | | | | | 3 | shortcut | The file represented by a Windows | | | | "shortcut". A shortcut is distinguished | | | | from a symbolic link because of the | | | | difference in their contents, which may be | | | | of importance to the manager. | | | | | | 4 | stream | An Alternate Data Stream (ADS) in Windows; | | | | a fork on MacOS. Separate file system | | | | entity that is considered an extension of | | | | the main <File>. | | 5 | symbolic-link | The <name> element represents the file to | | | | which the link points. | +------+---------------+--------------------------------------------+
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.
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.)
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.
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.
1. The AdditionalData class (see Section 4.2.4.6) allows implementors to include arbitrary "atomic" data items (integers, strings, etc.) in an Alert or Heartbeat message. This approach SHOULD be used whenever possible. See Section 7.4 and Section 7.5.
2. The AdditionalData class allows implementors to extend the IDMEF DTD with additional DTD "modules" that describe arbitrarily complex data types and relationships. The remainder of this section describes this extension method.
To extend the IDMEF DTD with a new DTD "module", the following steps MUST be followed:
1. The document declaration MUST define a DTD location that defines the namespace and contains the location of the extension DTD, and then reference that namespace.
2. Multiple extensions may be included by defining multiple namespaces and DTD locations, and referencing them.
3. Extension DTDs MUST declare all of their elements and attributes in a separate XML namespace. Extension DTDs MUST NOT declare any elements or attributes in the "idmef" or default namespaces.
Debar, et al. Experimental [Page 80]
RFC 4765 The IDMEF March 2007
4. Extensions MUST only be included in IDMEF Alert and Heartbeat messages under an <AdditionalData> element whose "type" attribute contains the value "xml". For example:
In this example, the "vendorco" namespace is defined and then referenced, causing the DTD for the extension to be read by the XML parser.
It is expected that IDMEF-compliant applications will not normally include the IDMEF DTD itself in their communications. Instead, the DTD will be referenced in the document type definition in the IDMEF message. Such IDMEF documents will be well-formed and valid as defined in [3].
Other IDMEF documents will be specified that do not include the document prolog (e.g., entries in an IDMEF-format database). Such IDMEF documents will be well-formed but not valid.
Debar, et al. Experimental [Page 81]
RFC 4765 The IDMEF March 2007
Generally, well-formedness implies that a document has a single element that contains everything else (e.g., "<Book>") and that all the other elements nest nicely within each other without any overlapping (e.g., a "chapter" does not start in the middle of another "chapter").
Validity further implies that not only is the document well-formed, but it also follows specific rules (contained in the Document Type Definition) about which elements are "legal" in the document, how those elements nest within other elements, and so on (e.g., a "chapter" does not begin in the middle of a "title"). A document cannot be valid unless it references a DTD.
XML processors are required to be able to parse any well-formed document, valid or not. The purpose of validation is to make the processing of that document (what's done with the data after it's parsed) easier. Without validation, a document may contain elements in nonsense order, elements "invented" by the author that the processing application doesn't understand, and so forth.
IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid whenever both possible and practical.
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).
Synchronization of time-of-day clocks between analyzers and managers is outside the scope of this document. However, the following comments and suggestions are offered:
Debar, et al. Experimental [Page 82]
RFC 4765 The IDMEF March 2007
1. Whenever possible, all analyzers and managers should have their time-of-day clocks synchronized to an external source such as NTP [7] or SNTP [8] Global Positioning System (GPS), Geosynchronous Operational Environmental Satellite (GOES), NIST radio station WWV clocks, or some other reliable time standard.
2. When external time synchronization is not possible, the IDMEF provides the <AnalyzerTime> element, which may be used to perform rudimentary time synchronization (see below).
3. IDMEF-compliant applications SHOULD permit the user to enable/ disable the <AnalyzerTime> method of time synchronization as a configuration option.
A number of caveats apply to the use of <AnalyzerTime> for time synchronization:
1. <AnalyzerTime> works best in a "flat" environment where analyzers report up to a single level of managers. When a tree topology of high-level managers, intermediate relays, and analyzers is used, the problem becomes more complex.
2. When intermediate message relays (managers or otherwise) are involved, two scenarios are possible:
* The intermediaries may forward entire IDMEF messages, or may perform aggregation or correlation, but MUST NOT inject delay. In this case, time synchronization is end-to-end between the analyzer and the highest-level manager.
* The intermediaries may inject delay, due to storage or additional processing. In this case, time synchronization MUST be performed at each hop. This means each intermediary must decompose the IDMEF message, adjust all time values, and then reconstruct the message before sending it on.
3. When the environment is mixed, with some analyzers and managers using external time synchronization and some not, all managers and intermediaries must perform <AnalyzerTime> synchronization. This is because determining whether or not compensation is actually needed between two parties rapidly becomes very complex, and requires knowledge of other parts of the topology.
4. If an alert can take alternate paths, or be stored in multiple locations, the recorded times may be different depending on the path taken.
Debar, et al. Experimental [Page 83]
RFC 4765 The IDMEF March 2007
The above being said, <AnalyzerTime> synchronization is probably still better than nothing in many environments. To implement this type of synchronization, the following procedure is suggested:
1. When an analyzer or manager sends an IDMEF message, it should place the current value of its time-of-day clock in an <AnalyzerTime> element. This should occur as late as possible in the message transmission process, ideally right before the message is "put on the wire".
2. When a manager receives an IDMEF message, it should compute the difference between its own time-of-day clock and the time in the <AnalyzerTime> element of the message. This difference should then be used to adjust the times in the <CreateTime> and <DetectTime> elements (NTP timestamps should also be adjusted).
3. If the manager is an intermediary and sends the IDMEF message on to a higher-level manager, and hop-by-hop synchronization is in effect, it should regenerate the <AnalyzerTime> value to contain the value of its own time-of-day clock.
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.
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.
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.
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.
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]).
Network-based detection of a port scan. This shows detection by a single analyzer; see Section 7.5 for the same attack as detected by a correlation engine. Note the use of <portlist> to show the ports that were scanned.
Host-based detection of the "loadmodule" exploit. This attack involves tricking the "loadmodule" program into running another program; since "loadmodule" is set-user-id "root", the executed program runs with super-user privileges. Note the use of <User> and <Process> to identify the user attempting the exploit and how he's doing it.
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:
Host-based detection of a race condition attack. Note the use of the <File> to provide information about the files that are used to perform the attack.
In this example, logins are restricted to daytime hours. The alert reports a violation of this policy that occurs when a user logs in a little after 10:00 pm. Note the use of <AdditionalData> to provide information about the policy being violated.
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.
Host-based detection of a successful unauthorized acquisition of root access through the eject buffer overflow. Note the use of <Assessment> to provide information about the analyzer's evaluation of and reaction to the attack.
This example shows a Heartbeat message that provides "I'm alive and working" information to the manager. Note the use of <AdditionalData> elements, with "meaning" attributes, to provide some additional information.
The following example shows how to extend the IDMEF DTD. In the example, the VendorCo company has decided it wants to add geographic information to the Node class. To do this, VendorCo creates a Document Type Definition or DTD that defines how their class will be formatted:
<xsd:annotation> <xsd:documentation> Intrusion Detection Message Exchange Format (IDMEF) Extension for geographic information </xsd:documentation> </xsd:annotation>
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.
<!-- *************************************************************** ******************************************************************* *** Intrusion Detection Message Exchange Format (IDMEF) XML DTD *** *** Version 1.0, 07 March 2006 *** *** *** *** The use and extension of the IDMEF XML DTD are described in *** *** RFC 4765, "The Intrusion Detection Message Exchange *** *** Format", H. Debar, D. Curry, B. Feinstein. *** ******************************************************************* *************************************************************** -->
<!-- | Attributes of the IDMEF element. In general, the fixed values of | these attributes will change each time a new version of the DTD | is released. -->
<!ENTITY % attlist.idmef " version CDATA #FIXED '1.0' ">
<!-- | Attributes of all elements. These are the "XML" attributes that | every element should have. Space handling, language, and name | space. --> <!ENTITY % attlist.global " xmlns:idmef CDATA #FIXED 'http://iana.org/idmef' xmlns CDATA #FIXED 'http://iana.org/idmef' xml:space (default | preserve) 'default' xml:lang NMTOKEN #IMPLIED ">
Debar, et al. Experimental [Page 104]
RFC 4765 The IDMEF March 2007
<!-- =============================================================== =================================================================== === SECTION 2. Attribute value declarations. Enumerated values for === many of the element-specific attribute lists. =================================================================== =============================================================== -->
<!-- | Values for the Action.category attribute. --> <!ENTITY % attvals.actioncat " ( block-installed | notification-sent | taken-offline | other ) ">
<!-- | Values for the Address.category attribute. --> <!ENTITY % attvals.addrcat " ( unknown | atm | e-mail | lotus-notes | mac | sna | vm | ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask | ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask ) ">
<!-- | Values for the AdditionalData.type attribute. --> <!ENTITY % attvals.adtype " ( boolean | byte | character | date-time | integer | ntpstamp | portlist | real | string | byte-string | xmltext ) ">
<!-- | Values for the Impact.completion attribute. --> <!ENTITY % attvals.completion " ( failed | succeeded ) "> <!-- | Values for the File.category attribute. --> <!ENTITY % attvals.filecat " ( current | original ) ">
| Values for the Confidence.rating attribute. --> <!ENTITY % attvals.rating " ( low | medium | high | numeric ) ">
<!-- | Values for the Impact.severity attribute. --> <!ENTITY % attvals.severity " ( info | low | medium | high ) ">
<!-- | Values for the User.category attribute. --> <!ENTITY % attvals.usercat " ( unknown | application | os-device ) ">
<!-- | Values for yes/no attributes such as Source.spoofed and | Target.decoy. --> <!ENTITY % attvals.yesno " ( unknown | yes | no ) ">
<!-- =============================================================== =================================================================== === SECTION 3. Top-level element declarations. The IDMEF-Message === element and the types of messages it can include. =================================================================== =============================================================== -->
<!-- =============================================================== =================================================================== === SECTION 4. Subclasses of the Alert element that provide more === data for specific types of alerts. =================================================================== =============================================================== -->
<!-- =============================================================== =================================================================== === SECTION 5. The AdditionalData element. This element allows an === alert to include additional information that cannot === be encoded elsewhere in the data model. ===================================================================
<!ATTLIST AdditionalData type %attvals.adtype; 'string' meaning CDATA #IMPLIED %attlist.global; >
<!-- =============================================================== =================================================================== === SECTION 6. Elements related to identifying entities - analyzers === (the senders of these messages), sources (of === attacks), and targets (of attacks). =================================================================== =============================================================== -->
<!ELEMENT Analyzer ( Node?, Process?, Analyzer? )> <!ATTLIST Analyzer analyzerid CDATA '0' name CDATA #IMPLIED manufacturer CDATA #IMPLIED model CDATA #IMPLIED version CDATA #IMPLIED class CDATA #IMPLIED ostype CDATA #IMPLIED osversion CDATA #IMPLIED %attlist.global; >
<!-- =============================================================== =================================================================== === SECTION 7. Support elements used for providing detailed info === about entities - addresses, names, etc. =================================================================== =============================================================== -->
<!-- =============================================================== =================================================================== === SECTION 8. Simple elements with sub-elements or attributes of a === special nature. =================================================================== =============================================================== -->
<!-- =============================================================== =================================================================== === SECTION 9. Simple elements with no sub-elements and no special === attributes. =================================================================== =============================================================== -->
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.
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.
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.
+------+-----------------+------------------------------------------+ | 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) | +------+-------------+----------------------------------------------+
+------+-----------+--------------------------------+ | 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 | +------+----------+------------------------------------------+
+------+-------------+------------------------------------+ | Rank | Keyword | Description | +------+-------------+------------------------------------+ | 0 | unknown | User type unknown | | 1 | application | An application user | | 2 | os-device | An operating system or device user | +------+-------------+------------------------------------+
IDMEF Class Name: UserId
IDMEF Attribute Name: category
Registered Values:
+------+---------------+--------------------------------------------+ | Rank | Keyword | Description | +------+---------------+--------------------------------------------+ | 0 | current-user | The current user id being used by the user | | | | or process. On Unix systems, this would | | | | be the "real" user id, in general. | | 1 | original-user | The actual identity of the user or process | | | | being reported on. On those systems that | | | | (a) do some type of auditing and (b) | | | | support extracting a user id from the | | | | "audit id" token, that value should be | | | | used. On those systems that do not | | | | support this, and where the user has | | | | logged into the system, the "login id" | | | | should be used. | | 2 | target-user | The user id the user or process is | | | | attempting to become. This would apply, | | | | on Unix systems for example, when the user | | | | attempts to use "su", "rlogin", "telnet", | | | | etc. |
Debar, et al. Experimental [Page 126]
RFC 4765 The IDMEF March 2007
| 3 | user-privs | Another user id the user or process has | | | | the ability to use, or a user id | | | | associated with a file permission. On | | | | Unix systems, this would be the | | | | "effective" user id in a user or process | | | | context, and the owner permissions in a | | | | file context. Multiple UserId elements of | | | | this type may be used to specify a list of | | | | privileges. | | 4 | current-group | The current group id (if applicable) being | | | | used by the user or process. On Unix | | | | systems, this would be the "real" group | | | | id, in general. | | 5 | group-privs | Another group id the group or process has | | | | the ability to use, or a group id | | | | associated with a file permission. On | | | | Unix systems, this would be the | | | | "effective" group id in a group or process | | | | context, and the group permissions in a | | | | file context. On BSD-derived Unix | | | | systems, multiple UserId elements of this | | | | type would be used to include all the | | | | group ids on the "group list". | | 6 | other-privs | Not used in a user, group, or process | | | | context, only used in the file context. | | | | The file permissions assigned to users who | | | | do not match either the user or group | | | | permissions on the file. On Unix systems, | | | | this would be the "world" permissions. | +------+---------------+--------------------------------------------+
IDMEF Class Name: File
IDMEF Attribute Name: category
Registered Values:
+------+----------+-------------------------------------------------+ | Rank | Keyword | Description | +------+----------+-------------------------------------------------+ | 0 | current | The file information is from after the reported | | | | change | | 1 | original | The file information is from before the | | | | reported change | +------+----------+-------------------------------------------------+
Debar, et al. Experimental [Page 127]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: File
IDMEF Attribute Name: fstype
Registered Values:
+------+---------+-------------------------------------+ | Rank | Keyword | Description | +------+---------+-------------------------------------+ | 0 | ufs | Berkeley Unix Fast File System | | 1 | efs | Linux "efs" file system | | 2 | nfs | Network File System | | 3 | afs | Andrew File System | | 4 | ntfs | Windows NT File System | | 5 | fat16 | 16-bit Windows FAT File System | | 6 | fat32 | 32-bit Windows FAT File System | | 7 | pcfs | "PC" (MS-DOS) file system on CD-ROM | | 8 | joliet | Joliet CD-ROM file system | | 9 | iso9660 | ISO 9660 CD-ROM file system | +------+---------+-------------------------------------+
IDMEF Class Name: FileAccess
IDMEF Attribute Name: permission
Registered Values:
+------+-------------------+----------------------------------------+ | Rank | Keyword | Description | +------+-------------------+----------------------------------------+ | 0 | noAccess | No access at all is allowed for this | | | | user | | 1 | read | This user has read access to the file | | 2 | write | This user has write access to the file | | 3 | execute | This user has the ability to execute | | | | the file | | 4 | search | This user has the ability to search | | | | this file (applies to "execute" | | | | permission on directories in Unix) | | 5 | delete | This user has the ability to delete | | | | this file | | 6 | executeAs | This user has the ability to execute | | | | this file as another user | | 7 | changePermissions | This user has the ability to change | | | | the access permissions on this file | | 8 | takeOwnership | This user has the ability to take | | | | ownership of this file | +------+-------------------+----------------------------------------+
Debar, et al. Experimental [Page 128]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Linkage
IDMEF Attribute Name: category
Registered Values:
+------+---------------+--------------------------------------------+ | Rank | Keyword | Description | +------+---------------+--------------------------------------------+ | 0 | hard-link | The <name> element represents another name | | | | for this file. This information may be | | | | more easily obtainable on NTFS file | | | | systems than others. | | 1 | mount-point | An alias for the directory specified by | | | | the parent's <name> and <path> elements. | | 2 | reparse-point | Applies only to Windows; excludes symbolic | | | | links and mount points, which are specific | | | | types of reparse points. | | 3 | shortcut | The file represented by a Windows | | | | "shortcut". A shortcut is distinguished | | | | from a symbolic link because of the | | | | difference in their contents, which may be | | | | of importance to the manager. | | 4 | stream | An Alternate Data Stream (ADS) in Windows; | | | | a fork on MacOS. Separate file system | | | | entity that is considered an extension of | | | | the main <File>. | | 5 | symbolic-link | The <name> element represents the file to | | | | which the link points. | +------+---------------+--------------------------------------------+
Debar, et al. Experimental [Page 129]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Checksum
IDMEF Attribute Name: algorithm
Registered Values:
+------+----------+------------------------------------------+ | Rank | Keyword | Description | +------+----------+------------------------------------------+ | 0 | MD4 | The MD4 algorithm. | | 1 | MD5 | The MD5 algorithm. | | 2 | SHA1 | The SHA1 algorithm. | | 3 | SHA2-256 | The SHA2 algorithm with 256 bits length. | | 4 | SHA2-384 | The SHA2 algorithm with 384 bits length. | | 5 | SHA2-512 | The SHA2 algorithm with 512 bits length. | | 6 | CRC-32 | The CRC algorithm with 32 bits length. | | 7 | Haval | The Haval algorithm. | | 8 | Tiger | The Tiger algorithm. | | 9 | Gost | The Gost algorithm. | +------+----------+------------------------------------------+
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.
[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] 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.
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)
<!-- Section 5: The AdditionalData element. This element allows an alert to include additional information that cannot be encoded elsewhere in the data model. -->
<!-- Section 6: Elements related to identifying entities - analyzers (the senders of these messages), sources (of attacks), and targets (of attacks). -->
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.