[要約] RFC 4766は、侵入検知メッセージの交換要件に関する規格であり、セキュリティイベントの共有と相互運用性を向上させることを目的としています。
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）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.
侵入検知交換形式のワーキンググループ（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
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]の侵入検出メッセージ交換形式の要件を定義します。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 Standards-Trackドキュメント[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 5月：この単語、または形容詞オプションは、説明されている動作または特性が提案されたIDWG仕様で本当にオプションであることを意味します。提案された1つの仕様は、記載された動作または特性を含めることを選択できますが、別の提案された仕様は同じ動作または特性を省略する場合があります。
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. 多くの商用および無料の侵入検知システムが利用可能であり、常に利用可能になっています。一部の製品は、ネットワーク上の侵入を検出することを目的としており、他の製品はホストオペレーティングシステムを対象としていますが、さらに他の製品はアプリケーションを対象としています。特定のカテゴリ内でさえ、製品の長所と短所は非常に異なります。したがって、ユーザーは1つ以上の製品を展開する可能性が高く、ユーザーは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. 侵入には、被害者としての複数の組織、または同じ組織内の複数のサイトが頻繁に関与しています。通常、これらのサイトは異なるIDSを使用します。このような分散型侵入を複数のサイトや管理ドメインに相関させることは非常に役立ちます。一般的な形式ですべてのサイトからレポートを作成すると、このタスクが促進されます。
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.
要件の残りをより明確にするために、典型的なIDSに関するいくつかの用語を定義します。これらの用語は、アルファベット順に表示されます。このセクションの最後の図は、本明細書で定義されている用語の一部の関係を示しています。
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.
組織のセキュリティポリシーを設定するための全体的な責任を負う人間、したがって、IDの展開と構成に関する決定について。これは、IDSのオペレーターと同じ人物である場合とそうでない場合があります。一部の組織では、管理者はネットワークまたはシステム管理グループに関連付けられています。他の組織では、それは独立した立場です。
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コンポーネントまたはプロセスは、不正または望ましくないアクティビティの兆候、またはセキュリティ管理者にとって興味深いイベントについて。多くの既存のIDSでは、センサーとアナライザーは同じコンポーネントの一部です。このドキュメントでは、Analyzerという用語は、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.
侵入検知システム。次のコンポーネントの1つ以上の組み合わせのいくつかの組み合わせ：センサー、アナライザー、マネージャー。
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マネージャーがオペレーターにアラートの発生とイベントを認識させる方法。多くのIDSSでは、これは、IDSマネージャー画面に色付きアイコンの表示、電子メールまたはページャーメッセージの送信、または単純なネットワーク管理プロトコル（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コンポーネント。データ収集の頻度は、IDの提供によって異なります。センサーは、イベントをアナライザーに転送するためにセットアップされています。
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が侵入を検出するメカニズムの1つ（必ずしも唯一のメカニズムではありません）を表します。
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 |__|
|_______________|
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が表示されているように、これらの個別のコンポーネントをすべて持っているわけではありません。一部のIDSSは、これらのコンポーネントを単一のモジュールに結合します。これらのモジュールの複数のインスタンスがあるものもあります。
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 protocol that communicates IDMEF as the IDMEF Communication Protocol (IDP).
このドキュメントの目的のために、アナライザーとマネージャーは個別のコンポーネントであり、TCP/IPネットワーク全体でペアワイズを通信していると想定しています。これらのエンティティ間の他の形式のコミュニケーションは、このドキュメントでは考慮されておらず、IDMEFアラートの他の使用は考慮されていません。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 アナライザーとマネージャーが分離されているか、コンポーネントのいくつかの大きな階層または分散メッシュに埋め込まれているか。
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 コンポーネントが1つのコンポーネントに対してアナライザーとして機能すると同時に、別のコンポーネントに関してマネージャーとして機能するかどうか。
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は他の2つのドキュメントを作成する必要があります。1つ目は、疑わしいイベントに関する情報を交換するためのデータ形式または言語を説明する必要があります。これでは、要件文書では、そのドキュメントを「データフォーマット仕様」と呼びます。作成される2番目のドキュメントでは、フォーマットされたデータを伝達するために最適に使用される既存のIETFプロトコルを識別し、これらの既存の形式またはドキュメントでこのデータをパッケージ化する方法を説明する必要があります。これをIDP（IDMEF通信プロトコル）と呼びます。
Accordingly, the requirements here are partitioned into four sections:
したがって、ここの要件は4つのセクションに分割されます。
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 2番目のセクションでは、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 3番目のセクションでは、AnalyzerからManagerに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設計と提案された通信プロトコルの評価における多くの基準の1つとしてのみ使用されます。ワーキンググループが追加のメトリックを使用して、競合するIDMEFデザインおよび/または通信プロトコルを評価できることが認識されています。
The IDMEF SHALL reference and use previously published RFCs where possible.
IDMEFは、可能であれば、以前に公開されていたRFCSを参照および使用するものとします。
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を使用して表現される可能性があります。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マネージャーは、多くの場合、IDアナライザーからのデータの受領に依存して、仕事を効果的に行います。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.
考えられる設計の1つは、IDMEFメッセージを伝えるためにTCPを使用することです。この場合の一般的な目標は、ファイアウォールに危険なインバウンド「穴」を開くことを避けることです。マネージャーがファイアウォールの内側にあり、アナライザーがファイアウォールの外側にいる場合、これはマネージャーに各アナライザーへのアウトバウンド接続を開始させることで達成されることがよくあります。ただし、マネージャーをファイアウォールの外に置き、アナライザーを内側に配置することもできます。これは、サードパーティベンダー（ISPなど）がユーザーに監視サービスを提供している場合に発生する可能性があります。この場合、アウトバウンド接続は各アナライザーによってマネージャーに開始されます。マネージャーまたはアナライザーが接続を開始できるようにするメカニズムは、マネージャーとアナライザーの展開に最大限の柔軟性を提供します。
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.
攻撃者は、IDによって防御されているネットワークに侵入します。攻撃者はIDが存在することを確信していませんが、アプリケーションレベルの暗号化されたトラフィック（つまり、IDMEFトラフィック）が攻撃されているネットワーク上のコンポーネント間で交換されていることを確信しています。彼は、1つ以上の洪水イベントを開始することにより、自分の存在を隠し、暗号化されたコミュニケーションを混乱させることにしました。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.
攻撃者は、IDによって防御されているネットワークに侵入します。攻撃者は、IDSが存在することを疑い、システムコンポーネント間で流れる暗号化されたトラフィックを脅威であると迅速に識別します。彼女はこのトラフィックを読むことができませんが、彼女はメッセージをコピーし、それを混乱させるためにレシーバーに複数のコピーを指示します。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設計は、IDが検出したのではなく、IDが検出したもの *を伝えることに集中することにより、これらの多様なアプローチに対応するよう努力する必要があります。
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には多くの種類があります。プロファイルに基づいて、ログファイル、攻撃署名などに基づいて動作するものもあります。他のものは異常に基づいており、通常の動作を定義し、確立されたベースラインからの逸脱を検出します。これらの各IDSSは、侵入検知方法論に一部依存するさまざまなデータを報告しています。すべてがこの標準でサポートされる必要があります。
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メッセージのコンテンツには、既知の場合、イベントの識別名（イベントID）が含まれている必要があります。この名前は、イベントの標準化されたリスト（利用可能な場合）から描画するか、イベントIDがまだ標準化されていない場合は実装固有の名前になります。この標準化されたリストがどのように定義または更新されるかはわかりません。このリストの作成に関する要件は、私たちの努力を超えています。セキュリティアリーナ内の他のグループは、そのようなリストの作成を調査しています。
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.
侵入者は、2つの異なる実装から2つの異なるアナライザーによって検出される攻撃を開始します。どちらも同じイベントIDを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.
攻撃者はよく知られている攻撃を実行します。攻撃に関する背景情報へのURLへの参照は、IDMEFメッセージに含まれています。オペレーターはこの情報を使用して、脆弱なシステムの修理を開始します。
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メッセージには、イベントのソースとターゲットコンポーネント識別子のIDがわかっている場合は含まれている必要があります。ネットワークベースのイベントの場合、これはイベントの開始に使用されるセッションのソースおよび宛先IPアドレスになります。ソースとターゲットのIDは、オペレーティングシステムやアプリケーションレベルで起動/検出されたイベントなど、他のタイプのイベントで異なることに注意してください。
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.
興味深いシナリオの1つは、ネットワーク全体での侵入イベントの進捗状況です。同じイベントが複数のアナライザーによって検出および報告された場合、アナライザーの身元（ネットワークベースのアナライザーの場合）は、ターゲットシステムのネットワーク位置の何らかの兆候を提供し、特定のタイプの応答を保証する可能性があります。これは、IPアドレスとして実装される場合があります。
The IDMEF message MUST be able to contain the identity of the implementor and the analyzer that detected the event.
IDMEFメッセージには、イベントを検出した実装者とアナライザーのIDを含めることができなければなりません。
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アドレス）で構成される場合があります。典型的なIDの展開では、低レベルのイベントアナライザーが生のセンサー情報を、たとえばデータベースに分析し、結果をより高いレベルにレポートします。この場合、一意の生のメッセージ識別子を、サポート証拠として結果メッセージに含めることができます。高レベルのアナライザーは、後でこの識別子を使用して、必要に応じてデータベースから生のメッセージを取得できます。
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.
実装者は、製品の特定の性質のために付加価値を提供すると思われる製品のバージョン番号やその他のデータなどの追加データを提供したい場合があります。実装者は、拡張機能を説明するドキュメントまたはWebサイトを公開できます。また、自己説明の帯域内拡張メカニズムを使用する場合があります。このような拡張機能は、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メッセージを受信し、1つの方法で解釈します。メッセージを作成した実装者は、オペレーターの解釈とは異なる意味を持つことを意図していました。したがって、結果の是正措置は正しくありません。
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.
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]
[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 4765、2007年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
デビッド・ドナフー、空軍情報戦センター
Mike Erlinger, Harvey Mudd College Fengmin Gong, Microcomputing Center of North Carolina
マイクアーリンガー、ハーベイマッドカレッジフェンミンゴング、ノースカロライナ州マイクロコンピューティングセンター
Dipankar Gupta, Hewlett-Packard
Dipankar Gupta、Hewlett-Packard
Glenn Mansfield, Cyber Solutions, Inc.
Glenn Mansfield、Cyber Solutions、Inc。
Jed Pickel, CERT Coordination Center
ジェド・ピッケル、証明書調整センター
Stuart Staniford-Chen, Silicon Defense
Stuart Staniford-Chen、シリコンディフェンス
Maureen Stillman, Nokia IP Telephony
Maureen Stillman、Nokia IPテレフォニー
Authors' Addresses
著者のアドレス
Mark Wood Internet Security Systems, Inc. 6303 Barfield Road Atlanta, GA 30328 US
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
マイケルA.アーリンガーハーベイマッドカレッジコンピューターサイエンス部301イースト12番街クレアモント、カリフォルニア91711 US
EMail: mike@cs.hmc.edu
URI: http://www.cs.hmc.edu/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（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.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。