summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4766.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4766.txt')
-rw-r--r--doc/rfc/rfc4766.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4766.txt b/doc/rfc/rfc4766.txt
new file mode 100644
index 0000000..998e059
--- /dev/null
+++ b/doc/rfc/rfc4766.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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).
+
+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 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
+ characteristics.
+
+ 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
+ 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
+ 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,
+ 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 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
+ controls.
+
+
+
+
+
+
+
+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
+ intrusions.
+
+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
+ 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
+ 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
+ (IDP).
+
+ 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
+ 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
+ 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
+ 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 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
+ 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 [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
+ 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.
+
+
+
+
+
+
+
+
+
+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
+ increases.
+
+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
+ duplication.
+
+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
+ 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.
+
+
+
+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
+ event.
+
+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
+ 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.
+
+
+
+
+
+
+
+
+
+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
+ event.
+
+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
+ 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]
+