Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group M. Wood Request for Comments: 4766 Internet Security Systems, Inc. Category: Informational M. Erlinger

                                                   Harvey Mudd College
                                                            March 2007
         Intrusion Detection Message Exchange Requirements

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).


 The purpose of the Intrusion Detection Exchange Format Working Group
 (IDWG) 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 the high-level requirements for such a
 communication mechanism, including the rationale for those
 requirements where clarification is needed.  Scenarios are used to
 illustrate some requirements.

Table of Contents

 1. Introduction ....................................................3
    1.1. Conventions Used in This Document ..........................3
 2. Overview ........................................................4
    2.1. Rationale for IDMEF ........................................4
    2.2. Intrusion Detection Terms ..................................4
    2.3. Architectural Assumptions ..................................8
    2.4. Organization of This Document ..............................9
    2.5. Document Impact on IDMEF Designs ..........................10
 3. General Requirements ...........................................10
    3.1. Use of Existing RFCs ......................................10
    3.2. IPv4 and IPv6 .............................................10
 4. Message Format Requirements ....................................11
    4.1. Internationalization and Localization .....................11
    4.2. Message Filtering and Aggregation .........................11

Wood & Erlinger Informational [Page 1] RFC 4766 IDME Requirements March 2007

 5. IDMEF Communication Protocol (IDP) Requirements ................12
    5.1. Reliable Message Transmission .............................12
    5.2. Interaction with Firewalls ................................12
    5.3. Mutual Authentication .....................................13
    5.4. Message Confidentiality ...................................13
    5.5. Message Integrity .........................................13
    5.6. Per-source Authentication .................................14
    5.7. Denial of Service .........................................14
    5.8. Message Duplication .......................................14
 6. Message Content Requirements ...................................15
    6.1. Detected Data .............................................15
    6.2. Event Identity ............................................15
    6.3. Event Background Information ..............................16
    6.4. Additional Data ...........................................16
    6.5. Event Source and Target Identity ..........................17
    6.6. Device Address Types ......................................17
    6.7. Event Impact ..............................................17
    6.8. Automatic Response ........................................18
    6.9. Analyzer Location .........................................18
    6.10. Analyzer Identity ........................................19
    6.11. Degree of Confidence .....................................19
    6.12. Alert Identification .....................................19
    6.13. Alert Creation Date and Time .............................20
    6.14. Time Synchronization .....................................21
    6.15. Time Format ..............................................21
    6.16. Time Granularity and Accuracy ............................21
    6.17. Message Extensions .......................................22
    6.18. Message Semantics ........................................22
    6.19. Message Extensibility ....................................22
 7. Security Considerations ........................................23
 8. References .....................................................23
    8.1. Normative References ......................................23
    8.2. Informative References ....................................23
 9. Acknowledgements ...............................................23

Wood & Erlinger Informational [Page 2] RFC 4766 IDME Requirements March 2007

1. Introduction

 This document defines requirements for the Intrusion Detection
 Message Exchange Format (IDMEF) [5], a product of the Intrusion
 Detection Exchange Format Working Group (IDWG).  IDMEF was planned to
 be a standard format that automated Intrusion Detection Systems
 (IDSs) [4] could use for reporting what they have deemed to be
 suspicious or of interest.  This document also specifies requirements
 for a communication protocol for communicating IDMEF.  As chartered,
 IDWG has the responsibility to first evaluate existing communication
 protocols before choosing to specify a new one.  Thus the
 requirements in this document can be used to evaluate existing
 communication protocols.  If IDWG determines that a new communication
 protocol is necessary, the requirements in this document can be used
 to evaluate proposed solutions.

1.1. Conventions Used in This Document

 This is not an IETF standards-track document [2], and thus the key
 words MUST, MUST NOT, SHOULD, and MAY are NOT as in BCP 14, RFC 2119
 [1], but rather:
 o  MUST: This word, or the terms REQUIRED or SHALL, means that the
    described behavior or characteristic is an absolute requirement
    for a proposed IDWG specification.
 o  MUST NOT: This phrase, or the phrase SHALL NOT, means that the
    described behavior or characteristic is an absolute prohibition of
    a proposed IDWG specification.
 o  SHOULD: This word, or the adjective RECOMMENDED, means that there
    may exist valid reasons in particular circumstances for a proposed
    IDWG specification to ignore described behavior or
 o  MAY: This word, or the adjective OPTIONAL, means that the
    described behavior or characteristic is truly optional for a
    proposed IDWG specification.  One proposed specification may
    choose to include the described behavior or characteristic,
    whereas another proposed specification may omit the same behavior
    or characteristic.

Wood & Erlinger Informational [Page 3] RFC 4766 IDME Requirements March 2007

2. Overview

2.1. Rationale for IDMEF

 The reasons such a format should be useful are as follows:
 1. A number of commercial and free Intrusion Detection Systems are
    available and more are becoming available all the time.  Some
    products are aimed at detecting intrusions on the network, others
    are aimed at host operating systems, while still others are aimed
    at applications.  Even within a given category, the products have
    very different strengths and weaknesses.  Hence it is likely that
    users will deploy more than a single product, and users will want
    to observe the output of these products from one or more
    manager(s).  A standard format for reporting will simplify this
    task greatly.
 2. Intrusions frequently involve multiple organizations as victims,
    or multiple sites within the same organization.  Typically, those
    sites will use different IDSs.  It would be very helpful to
    correlate such distributed intrusions across multiple sites and
    administrative domains.  Having reports from all sites in a common
    format would facilitate this task.
 3. The existence of a common format should allow components from
    different IDSs to be integrated more readily.  Thus, Intrusion
    Detection (ID) research should migrate into commercial products
    more easily.
 4. In addition to enabling communication from an ID analyzer to an ID
    manager, the IDMEF notification system may also enable
    communication between a variety of IDS components.  However, for
    the remainder of this document, we refer to the communication as
    going from an analyzer to a manager.
 All of these reasons suggest that a common format for reporting
 anything deemed suspicious should help the IDS market to grow and
 innovate more successfully, and should result in IDS users obtaining
 better results from deployment of ID systems.

2.2. Intrusion Detection Terms

 In order to make the rest of the requirements clearer, we define some
 terms about typical IDSs.  These terms are presented in alphabetical
 order.  The diagram at the end of this section illustrates the
 relationships of some of the terms defined herein.

Wood & Erlinger Informational [Page 4] RFC 4766 IDME Requirements March 2007

2.2.1. Activity

 Elements of the data source or occurrences within the data source
 that are identified by the sensor or analyzer as being of interest to
 the operator.  Examples of this include (but are not limited to)
 network session showing unexpected telnet activity, operating system
 log file entries showing a user attempting to access files to which
 he is not authorized to have access, application log files showing
 persistent login failures, etc.
 Activity can range from extremely serious occurrences (such as an
 unequivocally malicious attack) to less serious occurrences (such as
 unusual user activity that's worth a further look) to neutral
 activity (such as user login).

2.2.2. Administrator

 The human with overall responsibility for setting the security policy
 of the organization, and, thus, for decisions about deploying and
 configuring the IDS.  This may or may not be the same person as the
 operator of the IDS.  In some organizations, the administrator is
 associated with the network or systems administration groups.  In
 other organizations, it's an independent position.

2.2.3. Alert

 A message from an analyzer to a manager that an event of interest has
 been detected.  An alert typically contains information about the
 unusual activity that was detected, as well as the specifics of the

2.2.4. Analyzer

 The ID component or process that analyzes the data collected by the
 sensor for signs of unauthorized or undesired activity or for events
 that might be of interest to the security administrator.  In many
 existing IDSs, the sensor and the analyzer are part of the same
 component.  In this document, the term analyzer is used generically
 to refer to the sender of the IDMEF message.

2.2.5. Data Source

 The raw information that an intrusion detection system uses to detect
 unauthorized or undesired activity.  Common data sources include (but
 are not limited to) raw network packets, operating system audit logs,
 application audit logs, and system-generated checksum data.

Wood & Erlinger Informational [Page 5] RFC 4766 IDME Requirements March 2007

2.2.6. Event

 The occurrence in the data source that is detected by the sensor and
 that may result in an IDMEF alert being transmitted, for example,

2.2.7. IDS

 Intrusion detection system.  Some combination of one or more of the
 following components: sensor, analyzer, manager.

2.2.8. Manager

 The ID component or process from which the operator manages the
 various components of the ID system.  Management functions typically
 include (but are not limited to) sensor configuration, analyzer
 configuration, event notification management, data consolidation, and

2.2.9. Notification

 The method by which the IDS manager makes the operator aware of the
 alert occurrence and thus the event.  In many IDSs, this is done via
 the display of a colored icon on the IDS manager screen, the
 transmission of an e-mail or pager message, or the transmission of a
 Simple Network Management Protocol (SNMP) trap, although other
 notification techniques are also used.

2.2.10. Operator

 The human that is the primary user of the IDS manager.  The operator
 often monitors the output of the ID system and initiates or
 recommends further action.

2.2.11. Response

 The actions taken in response to an event.  Responses may be
 undertaken automatically by some entity in the IDS architecture or
 may be initiated by a human.  Sending a notification to the operator
 is a very common response.  Other responses include (but are not
 limited to) logging the activity; recording the raw data (from the
 data source) that characterized the event; terminating a network,
 user, or application session; or altering network or system access

Wood & Erlinger Informational [Page 6] RFC 4766 IDME Requirements March 2007

2.2.12. Sensor

 The ID component that collects data from the data source.  The
 frequency of data collection will vary across IDS offerings.  The
 sensor is set up to forward events to the analyzer.

2.2.13. Signature

 A rule used by the analyzer to identify interesting activity to the
 security administrator.  Signatures represent one of the mechanisms
 (though not necessarily the only mechanism) by which IDSs detect

2.2.14. Security Policy

 The predefined, formally documented statement that defines what
 activities are allowed to take place on an organization's network or
 on particular hosts to support the organization's requirements.  This
 includes, but is not limited to, which hosts are to be denied
 external network access.

Wood & Erlinger Informational [Page 7] RFC 4766 IDME Requirements March 2007

 |        |                   --------
 | Data   |_________ ________|        |  __________
 | Source |     Activity     |Sensor  | |          |
 |________|         |        |________| | Operator |_______
                    |            |      |__________|       |
                   \|/         Event         A             |
               _____V___         |          /|\            |
              |         |        |            \            |
              | Sensor  |__      |         Notification    |
              |_________| Event  |              \         \|/
                    A      |     V_________      \         V
                   /|\     |    |         |       \     Response
                    |       --->| Analyzer|__      |       A
                    |           |         | Alert  |      /|\
                    |           |_________|  |     |       |
                    |                A       |     |       |
                    |               /|\     \|/    |       |
                    |________________|   ____V___  |       |
                        |               |        |_|       |
                        |               | Manager|_________|
                        |               |________|
                        |                  A
                      Security            /|\
      _______________   |  Policy__________|
     |               |  |
     | Administrator |__|
 The diagram above illustrates the terms above and their
 relationships.  Not every IDS will have all of these separate
 components exactly as shown.  Some IDSs will combine these components
 into a single module; some will have multiple instances of these

2.3. Architectural Assumptions

 In this document, as defined in the terms above, we assume that an
 analyzer determines somehow that a suspicious event has been seen by
 a sensor, and sends an alert to a manager.  The format of that alert
 and the method of communicating it are what IDMEF proposes to
 For the purposes of this document, we assume that the analyzer and
 manager are separate components and that they are communicating
 pairwise across a TCP/IP network.  No other form of communication
 between these entities is contemplated in this document, and no other
 use of IDMEF alerts is considered.  We refer to the communication

Wood & Erlinger Informational [Page 8] RFC 4766 IDME Requirements March 2007

 protocol that communicates IDMEF as the IDMEF Communication Protocol
 The Trust Model is not specified as a requirement, but is rather left
 to the choice of the IDMEF Communication Protocol, i.e., a design
 decision.  What is specified are individual security-related
 requirements; see Section 5.
 We try to make no further architectural assumptions than those just
 stated.  For example, the following points should not matter:
 o  Whether the sensor and the analyzer are integrated or separate.
 o  Whether the analyzer and manager are isolated or are embedded in
    some large hierarchy or distributed mesh of components.
 o  Whether the manager actually notifies a human, takes action
    automatically, or just analyzes incoming alerts and correlates
 o  Whether a component might act as an analyzer with respect to one
    component, while also acting as a manager with respect to another.

2.4. Organization of This Document

 Besides this requirements document, the IDWG should produce two other
 documents.  The first should describe a data format or language for
 exchanging information about suspicious events.  In this, the
 requirements document, we refer to that document as the "data-format
 specification".  The second document to be produced should identify
 existing IETF protocols that are best used for conveying the data so
 formatted, and explain how to package this data in those existing
 formats or the document should specify a new protocol.  We refer to
 this as the IDP (IDMEF Communication Protocol).
 Accordingly, the requirements here are partitioned into four
 o  The first of these contains general requirements that apply to all
    aspects of the IDMEF specification (Section 3).
 o  The second section describes requirements on the formatting of
    IDMEF messages (Section 4).
 o  The third section outlines requirements on the communications
    mechanism, IDP, used to move IDMEF messages from the analyzer to
    the manager (Section 5).

Wood & Erlinger Informational [Page 9] RFC 4766 IDME Requirements March 2007

 o  The final section contains requirements on the content and
    semantics of the IDMEF messages (Section 6).
 For each requirement, we attempt to state the requirement as clearly
 as possible without imposing an idea of what a design solution should
 be.  Then we give the rationale for why this requirement is
 important, and state whether this should be an essential feature of
 the specification or is beneficial but could be lacking if it is
 difficult to fulfill.  Finally, where it seems necessary, we give an
 illustrative scenario.  In some cases, we include possible design
 solutions in the scenario.  These are purely illustrative.

2.5. Document Impact on IDMEF Designs

 It is expected that proposed IDMEF designs will, at a minimum,
 satisfy the requirements expressed in this document.  However, this
 document will be used only as one of many criteria in the evaluation
 of various IDMEF designs and proposed communication protocols.  It is
 recognized that the working group may use additional metrics to
 evaluate competing IDMEF designs and/or communication protocols.

3. General Requirements

3.1. Use of Existing RFCs

 The IDMEF SHALL reference and use previously published RFCs where

3.1.1. Rationale

 The IETF has already completed a great deal of research and work into
 the areas of networks and security.  In the interest of time, it is
 smart to use already defined and accepted standards.

3.2. IPv4 and IPv6

 The IDMEF specification MUST take into account that IDMEF should be
 able to operate in environments that contain IPv4 and IPv6

3.2.1 Rationale

 Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 environments are
 expected to exist within the time frame of IDMEF implementations, the
 IDMEF specification MUST support IPv6 and IPv4 environments.

Wood & Erlinger Informational [Page 10] RFC 4766 IDME Requirements March 2007

4. Message Format Requirements

 The IDMEF message format is intended to be independent of the IDMEF
 Communication Protocol (IDP).  It should be possible to use a
 completely different transport mechanism without changing the IDMEF
 format.  The goal behind this requirement is to ensure a clean
 separation between semantics and communication mechanisms.
 Obviously, the IDMEF Communication Protocol is recommended.

4.1. Internationalization and Localization

 IDMEF message formats SHALL support full internationalization and

4.1.1. Rationale

 Since network security and intrusion detection are areas that cross
 geographic, political, and cultural boundaries, the IDMEF messages
 MUST be formatted such that they can be presented to an operator in a
 local language and adhering to local presentation customs.

4.1.2. Scenario

 An IDMEF specification might include numeric event identifiers.  An
 IDMEF implementation might translate these numeric event identifiers
 into local language descriptions.  In cases where the messages
 contain strings, the information might be represented using the
 ISO/IEC IS 10646-1 character set and encoded using the UTF-8
 transformation format to facilitate internationalization [3].

4.2. Message Filtering and Aggregation

 The format of IDMEF messages MUST support filtering and/or
 aggregation of data by the manager.

4.2.1. Rationale

 Since it is anticipated that some managers might want to perform
 filtering and/or data aggregation functions on IDMEF messages, the
 IDMEF messages MUST be structured to facilitate these operations.

4.2.2. Scenario

 An IDMEF specification proposal might recommend fixed-format messages
 with strong numerical semantics.  This would lend itself to high-
 performance filtering and aggregation by the receiving station.

Wood & Erlinger Informational [Page 11] RFC 4766 IDME Requirements March 2007

5. IDMEF Communication Protocol (IDP) Requirements

5.1. Reliable Message Transmission

 The IDP MUST support reliable transmission of messages.

5.1.1. Rationale

 IDS managers often rely on receipt of data from IDS analyzers to do
 their jobs effectively.  Since IDS managers will rely on IDMEF
 messages for this purpose, it is important that IDP deliver IDMEF
 messages reliably.

5.2. Interaction with Firewalls

 The IDP MUST support transmission of messages between ID components
 across firewall boundaries without compromising security.

5.2.1. Rationale

 Since it is expected that firewalls will often be deployed between
 IDMEF capable analyzers and their corresponding managers, the ability
 to relay messages via proxy or other suitable mechanism across
 firewalls is necessary.  Setting up this communication MUST NOT
 require changes to the intervening firewall(s) that weaken the
 security of the protected network(s).  Nor SHOULD this be achieved by
 mixing IDMEF messages with other kinds of traffic (e.g., by
 overloading the HTTP POST method) since that would make it difficult
 for an organization to apply separate policies to IDMEF traffic and
 other kinds of traffic.

5.2.2. Scenario

 One possible design is the use of TCP to convey IDMEF messages.  The
 general goal in this case is to avoid opening dangerous inbound
 "holes" in the firewall.  When the manager is inside the firewall and
 the analyzers are outside the firewall, this is often achieved by
 having the manager initiate an outbound connection to each analyzer.
 However, it is also possible to place the manager outside the
 firewall and the analyzers on the inside; this can occur when a
 third-party vendor (such as an ISP) is providing monitoring services
 to a user.  In this case, the outbound connections would be initiated
 by each analyzer to the manager.  A mechanism that permits either the
 manager or the analyzer to initiate connections would provide maximum
 flexibility in manager and analyzer deployment.

Wood & Erlinger Informational [Page 12] RFC 4766 IDME Requirements March 2007

5.3. Mutual Authentication

 The IDP MUST support mutual authentication of the analyzer and the
 manager to each other.  Application-layer authentication is required
 irrespective of the underlying transport layer.

5.3.1. Rationale

 Since the alert messages are used by a manager to direct responses or
 further investigation related to the security of an enterprise
 network, it is important that the receiver have confidence in the
 identity of the sender and that the sender have confidence in the
 identity of the receiver.  This is peer-to-peer authentication of
 each party to the other.  It MUST NOT be limited to authentication of
 the underlying communications mechanism, for example, because of the
 risk that this authentication process might be subverted or

5.4. Message Confidentiality

 The IDP MUST support confidentiality of the message content during
 message exchange.  The selected design MUST be capable of supporting
 a variety of encryption algorithms and MUST be adaptable to a wide
 variety of environments.

5.4.1. Rationale

 IDMEF messages potentially contain extremely sensitive information
 (such as passwords) and would be of great interest to an intruder.
 Since it is likely some of these messages will be transmitted across
 uncontrolled network segments, it is important that the content be
 shielded.  Furthermore, since the legal environment for encryption
 technologies is extremely varied and changes often, it is important
 that the design selected be capable of supporting a number of
 different encryption options and be adaptable by the user to a
 variety of environments.

5.5. Message Integrity

 The IDP MUST ensure the integrity of the message content.  The
 selected design MUST be capable of supporting a variety of integrity
 mechanisms and MUST be adaptable to a wide variety of environments.

Wood & Erlinger Informational [Page 13] RFC 4766 IDME Requirements March 2007

5.5.1. Rationale

 IDMEF messages are used by the manager to direct action related to
 the security of the protected enterprise network.  It is vital for
 the manager to be certain that the content of the message has not
 been changed after transmission.

5.6. Per-source Authentication

 The IDP MUST support separate authentication keys for each sender.
 If symmetric algorithms are used, these keys would need to be known
 to the manager it is communicating with.

5.6.1. Rationale

 Given that sensitive security information is being exchanged via the
 IDMEF, it is important that the manager can authenticate each
 analyzer sending alerts.

5.7. Denial of Service

 The IDP SHOULD resist protocol denial-of-service attacks.

5.7.1. Rationale

 A common way to defeat secure communications systems is through
 resource exhaustion.  While this does not corrupt valid messages, it
 can prevent any communication at all.  It is desirable that IDP
 resist such denial-of-service attacks.

5.7.2. Scenario

 An attacker penetrates a network being defended by an IDS.  Although
 the attacker is not certain that an IDS is present, he is certain
 that application-level encrypted traffic (i.e., IDMEF traffic) is
 being exchanged between components on the network being attacked.  He
 decides to mask his presence and disrupt the encrypted communications
 by initiating one or more flood events.  If the IDP can resist such
 an attack, the probability that the attacker will be stopped

5.8. Message Duplication

 The IDP SHOULD resist malicious duplication of messages.

Wood & Erlinger Informational [Page 14] RFC 4766 IDME Requirements March 2007

5.8.1. Rationale

 A common way to impair the performance of secure communications
 mechanisms is to duplicate the messages being sent, even though the
 attacker might not understand them, in an attempt to confuse the
 receiver.  It is desirable that the IDP resist such message

5.8.2. Scenario

 An attacker penetrates a network being defended by an IDS.  The
 attacker suspects that an IDS is present and quickly identifies the
 encrypted traffic flowing between system components as being a
 possible threat.  Even though she cannot read this traffic, she
 copies the messages and directs multiple copies at the receiver in an
 attempt to confuse it.  If the IDP resists such message duplication,
 the probability that the attacker will be stopped increases.

6. Message Content Requirements

6.1. Detected Data

 There are many different types of IDSs, such as those based on
 signatures, anomalies, correlation, network monitoring, host
 monitoring, or application monitoring.  The IDMEF design MUST strive
 to accommodate these diverse approaches by concentrating on conveying
 *what* an IDS has detected, rather than *how* it detected it.

6.1.1. Rationale

 There are many types of IDSs that analyze a variety of data sources.
 Some are profile based and operate on log files, attack signatures,
 etc.  Others are anomaly based and define normal behavior and detect
 deviations from the established baseline.  Each of these IDSs reports
 different data that, in part, depends on their intrusion detection
 methodology.  All MUST be supported by this standard.

6.2. Event Identity

 The content of IDMEF messages MUST contain the identified name of the
 event (event identity) if it is known.  This name MUST be drawn from
 a standardized list of events (if available) or will be an
 implementation-specific name if the event identity has not yet been
 standardized.  It is not known how this standardized list will be
 defined or updated.  Requirements on the creation of this list are
 beyond our efforts.  Other groups within the security arena are
 investigating the creation of such lists.

Wood & Erlinger Informational [Page 15] RFC 4766 IDME Requirements March 2007

6.2.1. Rationale

 Given that this document presents requirements on standardizing ID
 message formats so that an ID manager is able to receive alerts from
 analyzers from multiple implementations, it is important that the
 manager understand the semantics of the reported events.  There is,
 therefore, a need to identify known events and store information
 concerning their methods and possible fixes to these events.  Some
 events are well known and this recognition can help the operator.

6.2.2. Scenario

 Intruder launches an attack that is detected by two different
 analyzers from two distinct implementations.  Both report the same
 event identity to the ID manager, even though the algorithms used to
 detect the attack by each analyzer might have been different.

6.3. Event Background Information

 The IDMEF message design MUST include information, which the sender
 should provide, that allows a receiver to locate background
 information on the kind of event that is being reported in the alert.

6.3.1. Rationale

 This information is used by administrators to report and fix

6.3.2. Scenario

 Attacker performs a well-known attack.  A reference to a URL to
 background information on the attack is included in the IDMEF
 message.  The operator uses this information to initiate repairs on
 the vulnerable system.

6.4. Additional Data

 The IDMEF message MUST be able to reference additional detailed data
 related to this specific underlying event.  It is OPTIONAL for
 implementations to use this field.  No requirements are placed on the
 format or content of this field.  It is expected that this will be
 defined and described by the implementor.

6.4.1. Rationale

 Operators might want more information on specifics of an event.  This
 field, if filled in by the analyzer, MAY point to additional or more
 detailed information about the event.

Wood & Erlinger Informational [Page 16] RFC 4766 IDME Requirements March 2007

6.5. Event Source and Target Identity

 The IDMEF message MUST contain the identity of the source of the
 event and target component identifier if it is known.  In the case of
 a network-based event, this will be the source and destination IP
 address of the session used to launch the event.  Note that the
 identity of source and target will vary for other types of events,
 such as those launched/detected at the operating system or
 application level.

6.5.1. Rationale

 This will allow the operator to identify the source and target of the

6.6. Device Address Types

 The IDMEF message MUST support the representation of different types
 of device addresses.

6.6.1. Rationale

 A device is a uniquely addressable element on the network (i.e., not
 limited to computers or networks or a specific level of the network
 protocol hierarchy).  In addition, devices involved in an intrusion
 event might use addresses that are not IP-centric.

6.6.2. Scenario

 The IDS recognizes an intrusion on a particular device and includes
 both the IP address and the MAC address of the device in the IDMEF
 message.  In another situation, the IDS recognizes an intrusion on a
 device that has only a MAC address and includes only that address in
 the IDMEF message.  Another situation involves analyzers in an
 Asynchronous Transfer Mode (ATM) switch fabric that use E.164 address

6.7. Event Impact

 The IDMEF message MUST contain an indication of the possible impact
 of this event on the target.  The IDMEF design document MUST define
 the scope of this value.

Wood & Erlinger Informational [Page 17] RFC 4766 IDME Requirements March 2007

6.7.1. Rationale

 Information concerning the possible impact of the event on the target
 system provides an indication of what the intruder is attempting to
 do and is critical data for the operator to perform damage
 assessment.  Not all systems will be able to determine this, but it
 is important data to transmit for those systems that can.  This
 requirement places no requirements on the list itself (e.g.,
 properties of the list, maintenance, etc.), rather the requirement
 only specifies that the IDMEF must contain a field for specifying the
 impact and that the IDMEF must define the scope of such values.

6.8. Automatic Response

 The IDMEF message MUST provide information about the automatic
 actions taken by the analyzer in response to the event (if any).

6.8.1. Rationale

 It is very important for the operator to know if there was an
 automated response and what that response was.  This will help
 determine what further action to take, if any.

6.9. Analyzer Location

 The IDMEF message MUST include information that would make it
 possible to later identify and locate the individual analyzer that
 reported the event.

6.9.1. Rationale

 The identity of the detecting analyzer often proves to be a valuable
 piece of data to have in determining how to respond to a particular

6.9.2. Scenario

 One interesting scenario involves the progress of an intrusion event
 throughout a network.  If the same event is detected and reported by
 multiple analyzers, the identity of the analyzer (in the case of a
 network-based analyzer) might provide some indication of the network
 location of the target systems and might warrant a specific type of
 response.  This might be implemented as an IP address.

Wood & Erlinger Informational [Page 18] RFC 4766 IDME Requirements March 2007

6.10. Analyzer Identity

 The IDMEF message MUST be able to contain the identity of the
 implementor and the analyzer that detected the event.

6.10.1. Rationale

 Users might run multiple IDSs to protect their enterprise.  This data
 will help the systems administrator determine which implementor and
 analyzer detected the event.

6.10.2. Scenario

 Analyzer X from implementor Y detects a potential intrusion.  A
 message is sent reporting that it found a potential break-in with X
 and Y specified.  The operator is therefore able to include the known
 capabilities or weaknesses of analyzer X in his decision regarding
 further action.

6.11. Degree of Confidence

 The IDMEF message MUST be able to state the degree of confidence of
 the report.  The completion of this field by an analyzer is OPTIONAL,
 as this data might not be available at all analyzers.

6.11.1. Rationale

 Many IDSs contain thresholds to determine whether or not to generate
 an alert.  This might influence the degree of confidence one has in
 the report or perhaps would indicate the likelihood of the report
 being a false alarm.

6.11.2. Scenario

 The alarm threshold monitor is set at a low level to indicate that an
 organization wants reports on any suspicious activity, regardless of
 the probability of a real attack.  The degree-of-confidence measure
 is used to indicate whether this is a low-probability or high-
 probability event.

6.12. Alert Identification

 The IDMEF message MUST be uniquely identifiable in that it can be
 distinguished from other IDMEF messages.

Wood & Erlinger Informational [Page 19] RFC 4766 IDME Requirements March 2007

6.12.1. Rationale

 An IDMEF message might be sent by multiple geographically-distributed
 analyzers at different times.  A unique identifier will allow an
 IDMEF message to be identified efficiently for data reduction and
 correlation purposes.

6.12.2. Scenario

 The unique identifier might consist of a unique originator identifier
 (e.g., IPv4 or IPv6 address) concatenated with a unique sequence
 number generated by the originator.  In a typical IDS deployment, a
 low-level event analyzer will log the raw sensor information into,
 e.g., a database while analyzing and reporting results to higher
 levels.  In this case, the unique raw message identifier can be
 included in the result message as supporting evidence.  Higher-level
 analyzers can later use this identifier to retrieve the raw message
 from the database if necessary.

6.13. Alert Creation Date and Time

 The IDMEF MUST support reporting alert creation date and time in each
 event, where the creation date and time refer to the date and time
 that the analyzer decided to create an alert.  The IDMEF MAY support
 additional dates and times, such as the date and time the event
 reference by the alert began.

6.13.1. Rationale

 Time is important from both a reporting and correlation point of
 view.  Event onset time might differ from the alert creation time
 because it might take some time for the sensor to accumulate
 information about a monitored activity before generating the event,
 and additional time for the analyzer to receive the event and create
 an alert.  The event onset time is therefore more representative of
 the actual time that the reported activity began than is the alert
 creation time.

6.13.2. Scenario

 If an event is reported in the quiet hours of the night, the operator
 might assign a higher priority to it than she would to the same event
 reported in the busy hours of the day.  Furthermore, an event (such
 as a lengthy port scan) may take place over a long period of time and
 it would be useful for the analyzer to report the time of the alert
 as well as the time the event began.

Wood & Erlinger Informational [Page 20] RFC 4766 IDME Requirements March 2007

6.14. Time Synchronization

 Time SHALL be reported such that events from multiple analyzers in
 different time zones can be received by the same manager and that the
 local time at the analyzer can be inferred.

6.14.1. Rationale

 For event correlation purposes, it is important that the manager be
 able to normalize the time information reported in the IDMEF alerts.

6.14.2. Scenario

 A distributed ID system has analyzers located in multiple time zones,
 all reporting to a single manager.  An intrusion occurs that spans
 multiple time zones as well as multiple analyzers.  The central
 manager requires sufficient information to normalize these alerts and
 determine that all were reported near the same "time" and that they
 are part of the same attack.

6.15. Time Format

 The format for reporting the date MUST be compliant with all current
 standards for Year 2000 rollover, and it MUST have sufficient
 capability to continue reporting date values past the year 2038.

6.15.1. Rationale

 It is desirable that the IDMEF have a long lifetime and that
 implementations be suitable for use in a variety of environments.
 Therefore, characteristics that limit the lifespan of the IDMEF (such
 as 2038 date representation limitation) MUST be avoided.

6.16. Time Granularity and Accuracy

 Time granularity and time accuracy in event messages SHALL NOT be
 specified by the IDMEF.

6.16.1. Rationale

 The IDMEF cannot assume a certain clock granularity on sensing
 elements, and so cannot impose any requirements on the granularity of
 the event timestamps.  Nor can the IDMEF assume that the clocks being
 used to timestamp the events have a specified accuracy.

Wood & Erlinger Informational [Page 21] RFC 4766 IDME Requirements March 2007

6.17. Message Extensions

 The IDMEF message MUST support an extension mechanism used by
 implementors to define implementation-specific data.  The use of this
 mechanism by the implementor is OPTIONAL.  This data contains
 implementation-specific information determined by each implementor.
 The implementor MUST indicate how to interpret these extensions,
 although there are no specific requirements placed on how
 implementors describe their implementation-specific extensions.  The
 lack or presence of such message extensions for implementation-
 specific data MUST NOT break interoperation.

6.17.1. Rationale

 Implementors might wish to supply extra data such as the version
 number of their product or other data that they believe provides
 value added due to the specific nature of their product.
 Implementors may publish a document or web site describing their
 extensions; they might also use an in-band extension mechanism that
 is self-describing.  Such extensions are not a license to break the
 interoperation of IDMEF messages.

6.18. Message Semantics

 The semantics of the IDMEF message MUST be well defined.

6.18.1. Rationale

 Good semantics are key to understanding what the message is trying to
 convey so there are no errors.  Operators will decide what action to
 take based on these messages, so it is important that they can
 interpret them correctly.

6.18.2. Scenario

 Without this requirement, the operator receives an IDMEF message and
 interprets it one way.  The implementor who constructed the message
 intended it to have a different meaning from the operator's
 interpretation.  The resulting corrective action is therefore

6.19. Message Extensibility

 The IDMEF itself MUST be extensible.  As new ID technologies emerge
 and as new information about events becomes available, the IDMEF
 message format MUST be able to include this new information.  Such
 message extensibility must occur in such a manner that
 interoperability is NOT impacted.

Wood & Erlinger Informational [Page 22] RFC 4766 IDME Requirements March 2007

6.19.1. Rationale

 As intrusion detection technology continues to evolve, it is likely
 that additional information relating to detected events will become
 available.  The IDMEF message format MUST be able to be extended by a
 specific implementation to encompass this new information.  Such
 extensions are not a license to break the interoperation of IDMEF

7. Security Considerations

 This document does not treat security matters, except that Section 5
 specifies security requirements for the protocols to be developed.

8. References

8.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

 [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.
 [3]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
      BCP 18, RFC 2277, January 1998.
 [4]  Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
 [5]  Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection
      Message Exchange Format (IDMEF)", RFC 4765, March 2007.

9. Acknowledgements

 The following individuals contributed substantially to this document
 and should be recognized for their efforts.  This document would not
 exist without their help:
 Mark Crosbie, Hewlett-Packard
 David Curry, IBM Emergency Response Services
 David Donahoo, Air Force Information Warfare Center
 Mike Erlinger, Harvey Mudd College

Wood & Erlinger Informational [Page 23] RFC 4766 IDME Requirements March 2007

 Fengmin Gong, Microcomputing Center of North Carolina
 Dipankar Gupta, Hewlett-Packard
 Glenn Mansfield, Cyber Solutions, Inc.
 Jed Pickel, CERT Coordination Center
 Stuart Staniford-Chen, Silicon Defense
 Maureen Stillman, Nokia IP Telephony

Authors' Addresses

 Mark Wood
 Internet Security Systems, Inc.
 6303 Barfield Road
 Atlanta, GA  30328
 Michael A. Erlinger
 Harvey Mudd College
 Computer Science Dept
 301 East 12th Street
 Claremont, CA  91711

Wood & Erlinger Informational [Page 24] RFC 4766 IDME Requirements March 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an

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


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

Wood & Erlinger Informational [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4766.txt · Last modified: 2007/03/08 22:46 (external edit)