Network Working Group M. Wood
Request for Comments: 4766 Internet Security Systems, Inc.
Category: Informational M. Erlinger
Harvey Mudd College
March 2007
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).
版权所有（C）IETF信托基金（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.
入侵检测交换格式工作组（IDWG）的目的是定义数据格式和交换程序，以共享入侵检测和响应系统以及可能需要与之交互的管理系统感兴趣的信息。本文件描述了此类沟通机制的高级要求，包括需要澄清的要求的基本原理。场景用于说明一些需求。
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
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
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
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
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.
本文件定义了入侵检测消息交换格式（IDMEF）[5]的要求，该格式是入侵检测交换格式工作组（IDWG）的产品。IDMEF计划成为一种标准格式，自动入侵检测系统（IDSs）[4]可用于报告他们认为可疑或感兴趣的内容。本文件还规定了IDMEF通信协议的要求。作为特许人，IDWG有责任在选择指定新的通信协议之前，首先评估现有的通信协议。因此，本文件中的要求可用于评估现有通信协议。如果IDWG确定需要一个新的通信协议，则可以使用本文件中的要求来评估提议的解决方案。
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:
这不是IETF标准跟踪文件[2]，因此关键词必须、不得、应该和可能与BCP 14、RFC 2119[1]中的关键词不同，而是：
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 必须：该词，或所要求或应要求的术语，意味着所描述的行为或特征是拟定IDWG规范的绝对要求。
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 不得：该短语或短语不得表示所描述的行为或特征是对建议的IDWG规范的绝对禁止。
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 应该：这个词，或推荐的形容词，意味着在特定情况下，可能存在提议的IDWG规范忽略所描述的行为或特征的正当理由。
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.
o 阿美：这个词，或形容词OPTIONAL，意味着所描述的行为或特征对于建议的IDWG规范来说确实是可选的。一个提议的规范可以选择包括所描述的行为或特征，而另一个提议的规范可以省略相同的行为或特征。
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.
1. 许多商业和免费入侵检测系统可用，并且越来越多的系统随时可用。一些产品的目标是检测网络入侵，其他产品的目标是主机操作系统，还有一些产品的目标是应用程序。即使在一个特定的类别中，这些产品也有非常不同的优势和劣势。因此，用户可能会部署多个产品，并且用户希望从一个或多个经理处观察这些产品的输出。报告的标准格式将大大简化此任务。
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.
2. 入侵通常涉及多个组织作为受害者，或同一组织内的多个站点。通常，这些站点将使用不同的ID。将这种分布式入侵跨多个站点和管理域关联起来将非常有帮助。以通用格式提供所有站点的报告将有助于完成这项任务。
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.
3. 通用格式的存在应该允许来自不同IDS的组件更容易集成。因此，入侵检测（ID）研究应该更容易地移植到商业产品中。
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.
4. 除了启用从ID分析器到ID管理器的通信之外，IDMEF通知系统还可以启用各种ID组件之间的通信。然而，对于本文档的其余部分，我们将通信称为从分析器到管理器的通信。
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.
所有这些原因都表明，报告任何可疑信息的通用格式应有助于IDS市场更成功地发展和创新，并应使IDS用户从ID系统的部署中获得更好的结果。
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.
为了使其余的需求更加清晰，我们定义了一些关于典型IDSs的术语。这些术语按字母顺序排列。本节末尾的图表说明了本文定义的一些术语之间的关系。
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.
由传感器或分析仪识别为操作员感兴趣的数据源元素或数据源内的事件。这方面的示例包括（但不限于）显示意外telnet活动的网络会话、显示用户试图访问其无权访问的文件的操作系统日志文件条目、显示持续登录失败的应用程序日志文件等。
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).
活动范围从极其严重的事件（如明确的恶意攻击）到不太严重的事件（如值得进一步研究的异常用户活动）到中性活动（如用户登录）。
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.
负责设置组织安全策略的人员，从而负责有关部署和配置IDS的决策。这可能是也可能不是ID操作员的同一个人。在某些组织中，管理员与网络或系统管理组相关联。在其他组织中，这是一个独立的职位。
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.
从分析器发送给管理器的消息，表示已检测到感兴趣的事件。警报通常包含有关检测到的异常活动的信息以及事件的详细信息。
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.
ID组件或进程，用于分析传感器收集的数据是否存在未经授权或意外活动的迹象，或是否存在安全管理员可能感兴趣的事件。在许多现有的IDSs中，传感器和分析仪是同一组件的一部分。在本文档中，术语分析器一般用于指IDMEF消息的发送者。
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.
入侵检测系统用于检测未经授权或意外活动的原始信息。常见数据源包括（但不限于）原始网络数据包、操作系统审核日志、应用程序审核日志和系统生成的校验和数据。
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.
传感器检测到的数据源中可能导致IDMEF警报被传输的事件，例如攻击。
Intrusion detection system. Some combination of one or more of the following components: sensor, analyzer, 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.
操作员管理ID系统各个组件的ID组件或流程。管理功能通常包括（但不限于）传感器配置、分析仪配置、事件通知管理、数据整合和报告。
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.
IDS管理器使操作员了解警报发生并因此了解事件的方法。在许多IDS中，这是通过在IDS manager屏幕上显示彩色图标、传输电子邮件或寻呼机消息或传输简单网络管理协议（SNMP）陷阱来实现的，尽管也使用了其他通知技术。
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.
作为IDS管理器主要用户的人员。操作员经常监控ID系统的输出，并启动或建议进一步的操作。
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.
为响应事件而采取的行动。响应可以由IDS体系结构中的某个实体自动执行，也可以由人工启动。向操作员发送通知是一种非常常见的响应。其他响应包括（但不限于）记录活动；记录表征事件的原始数据（来自数据源）；终止网络、用户或应用程序会话；或更改网络或系统访问控制。
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.
从数据源收集数据的ID组件。数据收集的频率因IDS产品而异。传感器设置为将事件转发至分析仪。
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.
分析器用于向安全管理员标识感兴趣的活动的规则。签名代表IDS检测入侵的一种机制（但不一定是唯一的机制）。
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.
预定义的、正式记录的声明，定义了允许在组织的网络或特定主机上进行哪些活动以支持组织的需求。这包括但不限于拒绝哪些主机访问外部网络。
________
| | --------
| 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 |__|
|_______________|
________
| | --------
| 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.
上图说明了上述术语及其关系。并不是每个ID都会像图中所示的那样拥有所有这些单独的组件。一些智能决策支持系统将这些组件组合成单个模块；有些将有这些模块的多个实例。
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.
在本文档中，如上述术语所定义，我们假设分析仪以某种方式确定传感器已看到可疑事件，并向经理发送警报。IDMEF建议标准化该警报的格式和传达方法。
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
在本文档中，我们假设analyzer和manager是独立的组件，并且它们在TCP/IP网络上成对通信。本文件不考虑这些实体之间的其他通信形式，也不考虑IDMEF警报的其他用途。我们指的是通信
protocol that communicates IDMEF as the IDMEF Communication Protocol (IDP).
将IDMEF作为IDMEF通信协议（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.
信任模型没有被指定为需求，而是留给IDMEF通信协议的选择，即设计决策。规定的是个人安全相关要求；见第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 传感器和分析仪是集成的还是分开的。
o Whether the analyzer and manager are isolated or are embedded in some large hierarchy or distributed mesh of components.
o analyzer和manager是隔离的还是嵌入在一些大型层次结构或组件的分布式网格中。
o Whether the manager actually notifies a human, takes action automatically, or just analyzes incoming alerts and correlates them.
o 管理器是实际通知人员、自动采取行动，还是仅分析传入警报并将其关联起来。
o Whether a component might act as an analyzer with respect to one component, while also acting as a manager with respect to another.
o 组件是否可以作为一个组件的分析器，同时也可以作为另一个组件的管理器。
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).
除本要求文件外，IDWG还应编制另外两份文件。第一种应描述用于交换可疑事件信息的数据格式或语言。在本需求文件中，我们将该文件称为“数据格式规范”。要生成的第二份文件应确定最适合传输格式化数据的现有IETF协议，并解释如何以这些现有格式打包这些数据，或者该文件应指定一个新协议。我们称之为IDP（IDMEF通信协议）。
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 第一部分包含适用于IDMEF规范所有方面的一般要求（第3节）。
o The second section describes requirements on the formatting of IDMEF messages (Section 4).
o 第二节描述了IDMEF消息格式的要求（第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).
o 第三节概述了用于将IDMEF消息从分析仪移动到管理器的通信机制IDP的要求（第5节）。
o The final section contains requirements on the content and semantics of the IDMEF messages (Section 6).
o 最后一节包含对IDMEF消息的内容和语义的要求（第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.
对于每个需求，我们试图尽可能清楚地陈述需求，而不强加设计解决方案应该是什么的想法。然后，我们给出了为什么这一要求很重要的基本原理，并说明这是规范的一个基本特征，还是有益的，但如果很难实现，则可能缺乏。最后，在有必要的地方，我们给出一个说明性的场景。在某些情况下，我们在场景中包括可能的设计解决方案。这些纯粹是说明性的。
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.
预计拟定的IDMEF设计将至少满足本文件中所述的要求。然而，本文件将仅作为评估各种IDMEF设计和拟定通信协议的众多标准之一。人们认识到，工作组可以使用其他指标来评估竞争性IDMEF设计和/或通信协议。
The IDMEF SHALL reference and use previously published RFCs where possible.
IDMEF应尽可能参考和使用先前发布的RFC。
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.
IETF已经在网络和安全领域完成了大量的研究和工作。为了节省时间，明智的做法是使用已经定义和接受的标准。
The IDMEF specification MUST take into account that IDMEF should be able to operate in environments that contain IPv4 and IPv6 implementations.
IDMEF规范必须考虑到IDMEF应该能够在包含IPv4和IPv6实现的环境中运行。
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.
由于纯IPv4、混合IPv6/IPv4和纯IPv6环境预计将在IDMEF实施的时间范围内存在，因此IDMEF规范必须支持IPv6和IPv4环境。
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.
IDMEF消息格式旨在独立于IDMEF通信协议（IDP）。在不改变IDMEF格式的情况下，应该可以使用完全不同的传输机制。这个需求背后的目标是确保语义和通信机制之间的清晰分离。显然，建议使用IDMEF通信协议。
IDMEF message formats SHALL support full internationalization and localization.
IDMEF消息格式应支持完全国际化和本地化。
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.
由于网络安全和入侵检测是跨越地理、政治和文化边界的领域，IDMEF消息的格式必须确保能够以本地语言向运营商呈现，并遵守本地呈现习惯。
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].
IDMEF规范可能包括数字事件标识符。IDMEF实现可以将这些数字事件标识符转换为本地语言描述。在消息包含字符串的情况下，可以使用ISO/IEC IS 10646-1字符集表示信息，并使用UTF-8转换格式进行编码，以促进国际化[3]。
The format of IDMEF messages MUST support filtering and/or aggregation of data by the manager.
IDMEF消息的格式必须支持管理器对数据进行过滤和/或聚合。
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.
由于预计某些管理者可能希望对IDMEF消息执行过滤和/或数据聚合功能，因此必须对IDMEF消息进行结构化以方便这些操作。
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.
IDMEF规范建议可能推荐具有强数字语义的固定格式消息。这将有助于接收站进行高性能过滤和聚合。
The IDP MUST support reliable transmission of messages.
IDP必须支持消息的可靠传输。
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.
IDS管理员通常依靠从IDS分析器接收数据来有效地完成工作。由于IDS管理员将依赖IDMEF消息实现此目的，因此IDP可靠地传递IDMEF消息非常重要。
The IDP MUST support transmission of messages between ID components across firewall boundaries without compromising security.
IDP必须支持跨越防火墙边界的ID组件之间的消息传输，而不影响安全性。
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.
由于预期防火墙通常会部署在支持IDMEF的分析器及其相应的管理器之间，因此需要能够通过代理或其他合适的机制在防火墙之间中继消息。设置此通信不得要求更改干预防火墙，以免削弱受保护网络的安全性。这也不应该通过将IDMEF消息与其他类型的流量混合（例如，通过重载HTTP POST方法）来实现，因为这将使组织难以对IDMEF流量和其他类型的流量应用单独的策略。
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.
一种可能的设计是使用TCP传输IDMEF消息。这种情况下的总体目标是避免在防火墙中打开危险的入站“漏洞”。当管理器位于防火墙内而分析器位于防火墙外时，通常通过让管理器启动到每个分析器的出站连接来实现。但是，也可以将管理器置于防火墙外，将分析仪置于防火墙内；当第三方供应商（如ISP）向用户提供监控服务时，可能会发生这种情况。在这种情况下，出站连接将由每个分析器启动到管理器。允许manager或analyzer启动连接的机制将在manager和analyzer部署中提供最大的灵活性。
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.
IDP必须支持分析仪和管理器之间的相互认证。无论底层传输层是什么，都需要应用层身份验证。
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.
由于管理员使用警报消息来指导响应或进一步调查企业网络的安全性，因此接收方对发送方的身份有信心，发送方对接收方的身份有信心是很重要的。这是每一方对另一方的对等身份验证。它不能局限于底层通信机制的身份验证，例如，因为此身份验证过程可能被破坏或配置错误。
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.
IDP必须在消息交换期间支持消息内容的机密性。所选设计必须能够支持多种加密算法，并且必须能够适应多种环境。
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.
IDMEF消息可能包含极为敏感的信息（如密码），入侵者会非常感兴趣。由于其中一些消息可能会通过不受控制的网段传输，因此屏蔽内容非常重要。此外，由于加密技术的法律环境千差万别且经常发生变化，因此所选设计必须能够支持多种不同的加密选项，并由用户适应各种环境。
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.
IDP必须确保消息内容的完整性。所选设计必须能够支持各种完整性机制，并且必须能够适应各种环境。
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.
管理器使用IDMEF消息指导与受保护企业网络的安全相关的操作。管理者必须确保消息的内容在传输后没有改变。
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.
IDP必须为每个发送方支持单独的身份验证密钥。如果使用对称算法，则与之通信的管理器需要知道这些密钥。
Given that sensitive security information is being exchanged via the IDMEF, it is important that the manager can authenticate each analyzer sending alerts.
鉴于通过IDMEF交换敏感的安全信息，管理者必须对发送警报的每个分析仪进行身份验证。
The IDP SHOULD resist protocol denial-of-service attacks.
IDP应抵抗协议拒绝服务攻击。
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.
击败安全通信系统的一种常见方法是资源耗尽。虽然这不会损坏有效消息，但会阻止任何通信。理想的情况是IDP能够抵抗这种拒绝服务攻击。
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.
攻击者侵入由IDS保护的网络。尽管攻击者不确定是否存在ID，但他确定正在被攻击的网络上的组件之间交换应用程序级加密流量（即IDMEF流量）。他决定通过发起一个或多个洪水事件来掩盖自己的存在并中断加密通信。如果IDP能够抵抗这种攻击，那么攻击者被阻止的概率就会增加。
The IDP SHOULD resist malicious duplication of messages.
IDP应防止恶意复制消息。
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.
损害安全通信机制性能的一种常见方法是复制正在发送的消息，即使攻击者可能不理解这些消息，以试图混淆接收者。理想的是，IDP抵抗这种消息复制。
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.
攻击者侵入由IDS保护的网络。攻击者怀疑存在ID，并迅速将系统组件之间的加密通信流识别为可能的威胁。即使她无法读取此流量，她也会复制消息，并将多个副本指向接收者，试图将其混淆。如果IDP阻止此类消息复制，则攻击者被阻止的概率将增加。
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.
有许多不同类型的IDS，例如基于签名、异常、关联、网络监视、主机监视或应用程序监视的IDS。IDMEF设计必须努力适应这些不同的方法，专注于传达IDS检测到的信息，而不是它如何检测到的信息。
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.
有许多类型的IDS可以分析各种数据源。一些是基于配置文件的，并对日志文件、攻击特征等进行操作。另一些是基于异常的，定义正常行为，并检测与既定基线的偏差。这些入侵检测系统中的每一个都报告不同的数据，部分取决于它们的入侵检测方法。所有这些都必须得到本标准的支持。
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.
IDMEF消息的内容必须包含已知事件的标识名称（事件标识）。此名称必须取自标准化的事件列表（如果可用），或者如果事件标识尚未标准化，则将是特定于实现的名称。目前尚不知道该标准化列表将如何定义或更新。创建此列表的要求超出了我们的努力范围。安全领域内的其他团体正在调查此类名单的创建。
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.
鉴于本文档提出了标准化ID消息格式的要求，以便ID管理器能够从多个实现中接收来自分析器的警报，因此，管理器理解报告事件的语义非常重要。因此，需要识别已知事件并存储有关其方法和可能修复这些事件的信息。一些事件是众所周知的，这种识别可以帮助操作员。
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.
入侵者发起的攻击由两个不同实现的不同分析器检测。两者都向ID管理器报告相同的事件标识，即使每个分析器用于检测攻击的算法可能不同。
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.
IDMEF消息设计必须包括发送方应提供的信息，这些信息允许接收方定位警报中报告的事件类型的背景信息。
This information is used by administrators to report and fix problems.
管理员使用此信息报告和修复问题。
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.
攻击者执行众所周知的攻击。IDMEF消息中包含对攻击背景信息URL的引用。操作员使用此信息启动易受攻击系统的维修。
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.
IDMEF消息必须能够引用与此特定基础事件相关的其他详细数据。实现使用此字段是可选的。对该字段的格式或内容没有任何要求。预计这将由实现者定义和描述。
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.
操作员可能需要关于事件细节的更多信息。如果由分析仪填写，此字段可能指向有关事件的附加或更详细信息。
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.
IDMEF消息必须包含事件源的标识和目标组件标识符（如果已知）。对于基于网络的事件，这将是用于启动事件的会话的源和目标IP地址。请注意，源和目标的标识将因其他类型的事件而有所不同，例如在操作系统或应用程序级别启动/检测的事件。
This will allow the operator to identify the source and target of the event.
这将允许操作员识别事件的源和目标。
The IDMEF message MUST support the representation of different types of device addresses.
IDMEF消息必须支持不同类型设备地址的表示。
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.
设备是网络上唯一可寻址的元素（即，不限于计算机或网络或网络协议层次结构的特定级别）。此外，入侵事件中涉及的设备可能会使用不以IP为中心的地址。
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.
IDS识别特定设备上的入侵，并在IDMEF消息中包含设备的IP地址和MAC地址。在另一种情况下，IDS识别只有MAC地址且IDMEF消息中仅包含该地址的设备上的入侵。另一种情况涉及使用E.164地址格式的异步传输模式（ATM）交换结构中的分析器。
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.
IDMEF消息必须包含此事件对目标的可能影响的指示。IDMEF设计文档必须定义此值的范围。
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.
有关事件对目标系统的可能影响的信息提供了入侵者试图做什么的指示，是操作员进行损害评估的关键数据。并非所有系统都能够确定这一点，但对于那些能够确定的系统来说，传输数据非常重要。该要求不对列表本身提出任何要求（例如，列表属性、维护等），而该要求仅规定IDMEF必须包含一个用于指定影响的字段，并且IDMEF必须定义此类值的范围。
The IDMEF message MUST provide information about the automatic actions taken by the analyzer in response to the event (if any).
IDMEF消息必须提供有关分析仪响应事件（如果有）所采取的自动操作的信息。
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.
操作员了解是否有自动响应以及该响应是什么非常重要。这将有助于确定要采取的进一步行动（如果有的话）。
The IDMEF message MUST include information that would make it possible to later identify and locate the individual analyzer that reported the event.
IDMEF消息必须包含使以后能够识别和定位报告事件的单个分析仪的信息。
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.
在确定如何响应特定事件时，检测分析仪的身份通常被证明是有价值的数据。
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.
一个有趣的场景涉及整个网络中入侵事件的进程。如果多个分析仪检测到并报告同一事件，分析仪的标识（在基于网络的分析仪的情况下）可能提供目标系统网络位置的一些指示，并可能保证特定类型的响应。这可以实现为IP地址。
The IDMEF message MUST be able to contain the identity of the implementor and the analyzer that detected the event.
IDMEF消息必须能够包含检测到事件的实现者和分析器的标识。
Users might run multiple IDSs to protect their enterprise. This data will help the systems administrator determine which implementor and analyzer detected the event.
用户可以运行多个IDS来保护其企业。此数据将帮助系统管理员确定哪个实施者和分析器检测到该事件。
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.
来自实施者Y的分析器X检测到潜在的入侵。在X和Y中发现一条指定为中断的报告消息。因此，操作员能够在其关于进一步行动的决定中包括分析仪X的已知能力或弱点。
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.
IDMEF消息必须能够说明报告的可信度。分析仪填写此字段是可选的，因为此数据可能在所有分析仪上都不可用。
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.
许多IDS包含用于确定是否生成警报的阈值。这可能会影响一个人对报告的信心程度，或者可能表明该报告有可能是虚惊一场。
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.
报警阈值监视器设置为较低级别，以指示组织希望报告任何可疑活动，而不考虑实际攻击的可能性。置信度度量用于指示这是低概率事件还是高概率事件。
The IDMEF message MUST be uniquely identifiable in that it can be distinguished from other IDMEF messages.
IDMEF消息必须是唯一可识别的，因为它可以与其他IDMEF消息区分开来。
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.
IDMEF消息可能由多个地理分布的分析器在不同的时间发送。唯一标识符将允许有效地识别IDMEF消息，用于数据缩减和关联目的。
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.
唯一标识符可能由唯一的发起人标识符（例如，IPv4或IPv6地址）和发起人生成的唯一序列号组成。在典型的IDS部署中，低级别事件分析器将原始传感器信息记录到数据库中，同时分析结果并向更高级别报告结果。在这种情况下，唯一的原始消息标识符可以作为支持证据包含在结果消息中。如果需要，更高级别的分析器稍后可以使用该标识符从数据库检索原始消息。
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.
IDMEF必须支持在每个事件中报告警报创建日期和时间，其中创建日期和时间指分析仪决定创建警报的日期和时间。IDMEF可能支持其他日期和时间，例如警报开始引用事件的日期和时间。
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.
从报告和关联的角度来看，时间都很重要。事件开始时间可能与警报创建时间不同，因为在生成事件之前，传感器可能需要一些时间来积累有关受监控活动的信息，而分析仪可能需要额外的时间来接收事件并创建警报。因此，事件开始时间比警报创建时间更能代表报告的活动开始的实际时间。
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.
如果在夜间安静时间报告某个事件，操作员可能会为其分配比在白天繁忙时间报告的同一事件更高的优先级。此外，事件（如长时间端口扫描）可能会在很长一段时间内发生，分析仪报告警报时间以及事件开始的时间将非常有用。
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.
应报告时间，以便同一管理器可以接收来自不同时区的多个分析仪的事件，并且可以推断分析仪的本地时间。
For event correlation purposes, it is important that the manager be able to normalize the time information reported in the IDMEF alerts.
出于事件关联的目的，管理器必须能够规范化IDMEF警报中报告的时间信息。
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.
分布式ID系统具有位于多个时区的分析器，所有分析器都向单个管理器报告。发生跨越多个时区和多个分析器的入侵。中央管理器需要足够的信息来规范化这些警报，并确定所有警报都是在几乎相同的“时间”报告的，并且它们是同一攻击的一部分。
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.
报告日期的格式必须符合2000年过渡的所有现行标准，并且必须有足够的能力继续报告2038年之后的日期值。
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.
IDMEF具有较长的生命周期，并且实现适合在各种环境中使用，这是可取的。因此，必须避免限制IDMEF寿命的特性（例如2038日期表示限制）。
Time granularity and time accuracy in event messages SHALL NOT be specified by the IDMEF.
IDMEF不应规定事件消息的时间粒度和时间精度。
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.
IDMEF不能在感测元素上假设特定的时钟粒度，因此不能对事件时间戳的粒度施加任何要求。IDMEF也不能假设用于给事件加时间戳的时钟具有指定的精度。
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.
IDMEF消息必须支持实现者用来定义特定于实现的数据的扩展机制。实现者使用此机制是可选的。此数据包含每个实现者确定的特定于实现的信息。实现者必须指明如何解释这些扩展，尽管对于实现者如何描述其特定于实现的扩展没有具体的要求。对于特定于实现的数据，此类消息扩展的缺乏或存在不得中断互操作。
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.
实施者可能希望提供额外的数据，例如他们产品的版本号或其他他们认为由于其产品的特定性质而提供附加值的数据。实现者可以发布描述其扩展的文档或网站；他们还可能使用带内扩展机制，即自描述机制。此类扩展不是中断IDMEF消息互操作的许可证。
The semantics of the IDMEF message MUST be well defined.
IDMEF消息的语义必须定义良好。
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.
良好的语义是理解消息试图传达的内容的关键，这样就不会出现错误。操作员将根据这些消息决定要采取的行动，因此他们能够正确解释这些消息是很重要的。
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.
如果没有此要求，操作员将接收IDMEF消息并以单向方式对其进行解释。构建消息的实现者希望它与操作员的解释具有不同的含义。因此，由此产生的纠正措施是不正确的。
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.
IDMEF本身必须是可扩展的。随着新的ID技术的出现以及有关事件的新信息的可用，IDMEF消息格式必须能够包含这些新信息。这种消息扩展性必须以不影响互操作性的方式出现。
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.
随着入侵检测技术的不断发展，与检测到的事件相关的附加信息可能会变得可用。IDMEF消息格式必须能够通过特定的实现进行扩展，以包含这些新信息。此类扩展不是中断IDMEF消息互操作的许可证。
This document does not treat security matters, except that Section 5 specifies security requirements for the protocols to be developed.
本文件不涉及安全问题，但第5节规定了待开发协议的安全要求。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[4] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[4] Shirey，R.，“互联网安全词汇表”，RFC 2828，2000年5月。
[5] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[5] Debar，H.，Curry，D.，和B.Feinstein，“入侵检测消息交换格式（IDMEF）”，RFC 47652007年3月。
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 Curry，IBM紧急响应服务部
David Donahoo, Air Force Information Warfare Center
David Donahoo，空军信息战中心
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
Maureen Stillman，诺基亚IP电话
Authors' Addresses
作者地址
Mark Wood Internet Security Systems, Inc. 6303 Barfield Road Atlanta, GA 30328 US
美国佐治亚州亚特兰大巴菲尔德路6303号马克伍德互联网安全系统公司，邮编30328
EMail: mark1@iss.net
EMail: mark1@iss.net
Michael A. Erlinger Harvey Mudd College Computer Science Dept 301 East 12th Street Claremont, CA 91711 US
美国加利福尼亚州克莱蒙特市东12街301号迈克尔·埃林格·哈维·穆德学院计算机科学系91711
EMail: mike@cs.hmc.edu
URI: http://www.cs.hmc.edu/
EMail: mike@cs.hmc.edu
URI: http://www.cs.hmc.edu/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。