[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04 05 06 07 08 09 10 RFC 4766

Intrusion Detection Working Group                                M. Wood
Internet-Draft                            Internet Security Systems, Inc
Expires: March 25, 2003                                      M. Erlinger
                                                     Harvey Mudd College
                                                      September 24, 2002


           Intrusion Detection Message Exchange Requirements
                    draft-ietf-idwg-requirements-09

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 25, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   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 which may need to interact with them.
   This Internet-Draft 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.





Wood & Erlinger          Expires March 25, 2003                 [Page 1]

Internet-Draft                Requirements                September 2002


Table of Contents

   1.     Conventions Used in This Document  . . . . . . . . . . . .   5
   2.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   6
   2.1    Rationale for IDMEF  . . . . . . . . . . . . . . . . . . .   6
   2.2    Intrusion Detection Terms  . . . . . . . . . . . . . . . .   7
   2.2.1  Activity:  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.2.2  Administrator: . . . . . . . . . . . . . . . . . . . . . .   7
   2.2.3  Alert: . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.2.4  Analyzer:  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.2.5  Data Source: . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.6  Event: . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.7  IDS: . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.8  Manager  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.9  Notification:  . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.10 Operator:  . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.11 Response:  . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.2.12 Sensor:  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   2.2.13 Signature: . . . . . . . . . . . . . . . . . . . . . . . .   9
   2.2.14 Security Policy: . . . . . . . . . . . . . . . . . . . . .   9
   2.3    Architectural Assumptions  . . . . . . . . . . . . . . . .  10
   2.4    Organization of This Document  . . . . . . . . . . . . . .  11
   2.5    Document Impact on IDMEF Designs . . . . . . . . . . . . .  12
   3.     General Requirements . . . . . . . . . . . . . . . . . . .  13
   3.1    Use of Existing RFCs . . . . . . . . . . . . . . . . . . .  13
   3.1.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  13
   3.2    IPv4 and IPv6  . . . . . . . . . . . . . . . . . . . . . .  13
   3.2.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.     Message Format Requirements  . . . . . . . . . . . . . . .  14
   4.1    Internationalization and Localization  . . . . . . . . . .  14
   4.1.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  14
   4.1.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  14
   4.2    Message Filtering and Aggregation  . . . . . . . . . . . .  14
   4.2.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  14
   4.2.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.     IDMEF Communications Protocol (IDP) Requirements . . . . .  15
   5.1    Reliable Message Transmission  . . . . . . . . . . . . . .  15
   5.1.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.2    Interaction with Firewalls . . . . . . . . . . . . . . . .  15
   5.2.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.2.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.3    Mutual Authentication  . . . . . . . . . . . . . . . . . .  16
   5.3.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.4    Message Confidentiality  . . . . . . . . . . . . . . . . .  16
   5.4.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.5    Message Integrity  . . . . . . . . . . . . . . . . . . . .  16
   5.5.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.6    Per-source Authentication  . . . . . . . . . . . . . . . .  17



Wood & Erlinger          Expires March 25, 2003                 [Page 2]

Internet-Draft                Requirements                September 2002


   5.6.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.7    Denial of Service  . . . . . . . . . . . . . . . . . . . .  17
   5.7.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.7.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.8    Message Duplication  . . . . . . . . . . . . . . . . . . .  17
   5.8.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.8.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  18
   6.     Message Content Requirements . . . . . . . . . . . . . . .  19
   6.1    Detected Data  . . . . . . . . . . . . . . . . . . . . . .  19
   6.1.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.2    Event Identity . . . . . . . . . . . . . . . . . . . . . .  19
   6.2.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.2.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.3    Event Background Information . . . . . . . . . . . . . . .  20
   6.3.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  20
   6.3.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  20
   6.4    Additional Data  . . . . . . . . . . . . . . . . . . . . .  20
   6.4.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  20
   6.5    Event Source and Target Identity . . . . . . . . . . . . .  20
   6.5.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  20
   6.6    Device Address Types . . . . . . . . . . . . . . . . . . .  21
   6.6.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.6.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.7    Event Impact . . . . . . . . . . . . . . . . . . . . . . .  21
   6.7.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.8    Automatic Response . . . . . . . . . . . . . . . . . . . .  21
   6.8.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.9    Analyzer Location  . . . . . . . . . . . . . . . . . . . .  22
   6.9.1  Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.9.2  Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.10   Analyzer Identity  . . . . . . . . . . . . . . . . . . . .  22
   6.10.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.10.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.11   Degree of Confidence . . . . . . . . . . . . . . . . . . .  22
   6.11.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.11.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.12   Alert Identification . . . . . . . . . . . . . . . . . . .  23
   6.12.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.12.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.13   Alert Creation Date and Time . . . . . . . . . . . . . . .  23
   6.13.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.13.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.14   Time Synchronization . . . . . . . . . . . . . . . . . . .  24
   6.14.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.14.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.15   Time Format  . . . . . . . . . . . . . . . . . . . . . . .  24
   6.15.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.16   Time Granularity and Accuracy  . . . . . . . . . . . . . .  25



Wood & Erlinger          Expires March 25, 2003                 [Page 3]

Internet-Draft                Requirements                September 2002


   6.16.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.17   Message Extensions . . . . . . . . . . . . . . . . . . . .  25
   6.17.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.18   Message Semantics  . . . . . . . . . . . . . . . . . . . .  25
   6.18.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.18.2 Scenario:  . . . . . . . . . . . . . . . . . . . . . . . .  26
   6.19   Message Extensibility  . . . . . . . . . . . . . . . . . .  26
   6.19.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . .  26
   7.     Security Considerations  . . . . . . . . . . . . . . . . .  27
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  27
   A.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  28
          Full Copyright Statement . . . . . . . . . . . . . . . . .  29







































Wood & Erlinger          Expires March 25, 2003                 [Page 4]

Internet-Draft                Requirements                September 2002


1. Conventions Used in This Document

   This is not an IETF standards track document and thus the keywords
   MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119, 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
      characteristics.

   o  MAY: This word, or the adjective "OPTIONAL", means that described
      behavior or characteristics are truly optional for a proposed IDWG
      specification.  One proposed specification may choose to include
      the described behavior or characteristic while another proposed
      specification may omit the same behavior or characteristic.




























Wood & Erlinger          Expires March 25, 2003                 [Page 5]

Internet-Draft                Requirements                September 2002


2. Introduction

   This document defines requirements for the Intrusion Detection
   Message Exchange Format (IDMEF), which is the intended work product
   of the Intrusion Detection Exchange Format Working Group (IDWG).
   IDMEF is planned to be a standard format which automated Intrusion
   Detection Systems (IDS) can 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.

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.



Wood & Erlinger          Expires March 25, 2003                 [Page 6]

Internet-Draft                Requirements                September 2002


   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.

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

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



Wood & Erlinger          Expires March 25, 2003                 [Page 7]

Internet-Draft                Requirements                September 2002


   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.

2.2.6 Event:

   The occurrence in the data source that is detected by the sensor and
   which may result in an IDMEF alert being transmitted.  For example,
   'N' failed logins in 'T' seconds might indicate a brute-force login
   attack.

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

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



Wood & Erlinger          Expires March 25, 2003                 [Page 8]

Internet-Draft                Requirements                September 2002


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

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

2.2.14 Security Policy:

   The predefined, formally documented statement which 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          Expires March 25, 2003                 [Page 9]

Internet-Draft                Requirements                September 2002


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

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

   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



Wood & Erlinger          Expires March 25, 2003                [Page 10]

Internet-Draft                Requirements                September 2002


   between these entities is contemplated in this document, and no other
   use of IDMEF alerts is considered.  We refer to the communication
   protocol that communicates IDMEF as the IDMEF Communication Protocol
   (IDP).

   The Trust Model is not specified as a requirement, but is rather left
   to the choice of the IDMEF communications protocol, i.e., a design
   decision.  What is specified are individual security related
   requirements, 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 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
      them.

   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 sections

   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



Wood & Erlinger          Expires March 25, 2003                [Page 11]

Internet-Draft                Requirements                September 2002


      the manager Section 5.

   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.





























Wood & Erlinger          Expires March 25, 2003                [Page 12]

Internet-Draft                Requirements                September 2002


3. General Requirements

3.1 Use of Existing RFCs

   The IDMEF SHALL reference and use previously published RFCs where
   possible.

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

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          Expires March 25, 2003                [Page 13]

Internet-Draft                Requirements                September 2002


4. Message Format Requirements

   The IDMEF message format is intended to be independent of the IDMEF
   communications 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
   localization.

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.

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          Expires March 25, 2003                [Page 14]

Internet-Draft                Requirements                September 2002


5. IDMEF Communications 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          Expires March 25, 2003                [Page 15]

Internet-Draft                Requirements                September 2002


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

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.

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



Wood & Erlinger          Expires March 25, 2003                [Page 16]

Internet-Draft                Requirements                September 2002


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

5.8 Message Duplication

   The IDP SHOULD resist malicious duplication of messages.

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




Wood & Erlinger          Expires March 25, 2003                [Page 17]

Internet-Draft                Requirements                September 2002


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.










































Wood & Erlinger          Expires March 25, 2003                [Page 18]

Internet-Draft                Requirements                September 2002


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:

   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.

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.




Wood & Erlinger          Expires March 25, 2003                [Page 19]

Internet-Draft                Requirements                September 2002


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

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.

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





Wood & Erlinger          Expires March 25, 2003                [Page 20]

Internet-Draft                Requirements                September 2002


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 nor a specific level of the
   network protocol hierarchy).  Additionally, 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 which has only a MAC address and includes only that address in
   the IDMEF message.  Another situation involves analyzers in an ATM
   switch fabric which use E.164 address formats.

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.

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



Wood & Erlinger          Expires March 25, 2003                [Page 21]

Internet-Draft                Requirements                September 2002


   determine what further action to take, if any.

6.9  Analyzer Location

   The IDMEF message MUST include information which would make it
   possible to later identify and locate the individual analyzer which
   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
   event.

6.9.2 Scenario:

   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.

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:

   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.



Wood & Erlinger          Expires March 25, 2003                [Page 22]

Internet-Draft                Requirements                September 2002


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

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.





Wood & Erlinger          Expires March 25, 2003                [Page 23]

Internet-Draft                Requirements                September 2002


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

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 timezones,
   all reporting to a single manager.  An intrusion occurs that spans
   multiple timezones 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.






Wood & Erlinger          Expires March 25, 2003                [Page 24]

Internet-Draft                Requirements                September 2002


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.

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.

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.

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.



Wood & Erlinger          Expires March 25, 2003                [Page 25]

Internet-Draft                Requirements                September 2002


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

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.

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.































Wood & Erlinger          Expires March 25, 2003                [Page 26]

Internet-Draft                Requirements                September 2002


7. Security Considerations

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


Authors' Addresses

   Mark Wood
   Internet Security Systems, Inc
   6303 Barfield Road
   Atlanta, GA  30328
   US

   EMail: mark1@iss.net


   Michael A. Erlinger
   Harvey Mudd College
   Computer Science Dept
   301 East 12th Street
   Claremont, CA  91711
   US

   EMail: mike@cs.hmc.edu
   URI:   http://www.cs.hmc.edu/

























Wood & Erlinger          Expires March 25, 2003                [Page 27]

Internet-Draft                Requirements                September 2002


Appendix A. Acknowledgements

   The following individuals contributed substantially to this document
   and should be recognized for their efforts.  This document would not
   exist without their help:

      Mark Crosbie, Hewlett-Packard

      David Curry, IBM Emergency Response Services

      David Donahoo, Air Force Information Warfare Center

      Mike Erlinger, Harvey Mudd College

      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


























Wood & Erlinger          Expires March 25, 2003                [Page 28]

Internet-Draft                Requirements                September 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Wood & Erlinger          Expires March 25, 2003                [Page 29]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/