Intrusion Detection Message Exchange Requirements
RFC 4766

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

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
   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              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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

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

Wood & Erlinger              Informational                     [Page 25]