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
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は、[4]、彼らが疑わしいか興味があるとみなされているものを報告するために使用することができます侵入検知システム（IDS;侵入を）自動化された標準フォーマットであることを計画しました。この資料はまた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]ではありませんので、キーの言葉は、SHOULD、MAYとは、BCP 14のようにされていないてはならないMUST、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必要があります。この単語、または必須の用語またはSHALLは、説明した動作又は特性が提案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 MAY：この単語、または形容詞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.商業用および無料の侵入検知システムの数が利用可能であり、より多くのすべての時間利用可能になりつつあります。まだ他の人がアプリケーションを目的としている間、いくつかの製品がネットワーク上の侵入を検出することを目的としている、他の人には、ホスト・オペレーティング・システムを目指しています。でも、与えられたカテゴリ内で、製品は非常に異なる長所と短所を持っています。したがって、ユーザーが単一の製品よりも展開すると、ユーザーは、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通知システムはまた、IDSコンポーネントの種々の間の通信を可能にすることができます。しかしながら、本文書の残りのために、我々は、マネージャにアナライザから行くような通信を指します。
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市場をより一層成長し、革新を助けなければならない、とIDシステムの展開から、より良い結果を得るIDSのユーザーになる必要があるものを報告するための共通のフォーマットが疑わしいとみなされることを示唆しています。
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.
IDSの導入と設定についての意思決定のために、このように、組織のセキュリティポリシーを設定、およびのための全体的な責任を持つ人間。これは、または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では、センサ及びアナライザは、同じコンポーネントの一部です。この文書では、用語アナライザは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マネージャは、アラート発生、したがって、イベントを認識オペレータを作るする方法。他の通知技術があるが、多くのIDSでは、これは、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コンポーネント。データ収集の頻度は、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.
セキュリティ管理者に興味深い活動を識別するために、アナライザで使用されるルール。署名は、侵入検出システムは、侵入を検出したことによって（必ずしも唯一のメカニズムが）メカニズムのいずれかを表します。
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.
上の図は、上記の用語とその関係を示しています。必ずしもすべてのIDSが示すとおりにこれらの別々のコンポーネントのすべてを持っています。いくつかのIDSは、単一のモジュールにこれらのコンポーネントを結合します。いくつかは、これらのモジュールの複数のインスタンスを持つことになります。
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通信プロトコル（IDP）としてIDMEFを通信する通信プロトコルを参照してください。
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。
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つの文書を作成する必要があります。最初は不審なイベントに関する情報を交換するためのデータ形式や言語を記述する必要があります。この、要件ドキュメントでは、「データ・フォーマット仕様」として、その文書を参照してください。製造される第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).
第3のセクションは、通信機構上の要件を概説O、IDPは、マネージャ（セクション5）にアナライザからIDMEFメッセージを移動するために使用されます。
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は、以前に発表された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を使用して表されるかもしれない10646-1キャラクタ・セットである、[3]国際化を容易にするために、UTF-8の変換フォーマットを使用してエンコード。
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できる分析装置およびそれに対応する管理者との間に配備されることが期待されているため、ファイアウォールを越えプロキシまたは他の適切な機構を介してメッセージを中継する機能が必要です。この通信を設定すると、保護されたネットワーク（複数可）のセキュリティを弱める介入ファイアウォール（S）への変更を要求してはなりません。それはそれが困難IDMEFトラフィックとトラフィックの他の種類の別のポリシーを適用する組織のために作ることになるので、NORこの（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.
一つの可能性のあるデザインは、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.
攻撃者は、IDSによって守られているネットワークに侵入します。攻撃者は、IDSが存在することは確かではないが、彼は特定のアプリケーション・レベルの暗号化されたトラフィック（すなわち、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によって守られているネットワークに侵入します。攻撃者は、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の多くの異なるタイプがあります。 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は、多くの種類があります。いくつか他の人が異常に基づくと、通常の動作を定義し、確立したベースラインからの逸脱を検知しているプロファイルベースであり、などのログファイル、攻撃シグネチャ、上で動作します。これらの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メッセージの内容は、イベント（イベントアイデンティティ）の識別名を含まなければなりません。この名前は、イベントの標準化されたリストから引き出さなければならない（使用可能な場合）またはイベント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つの異なる実装から二つの異なる分析装置によって検出された攻撃を開始します。どちらも、各アナライザによる攻撃を検出するのに使用されるアルゴリズムが違っていた場合でも、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メッセージは、イベントのソースの識別を含み、それが知られている場合、コンポーネント識別子を標的としなければなりません。ネットワークベースのイベントの場合、これは、イベントを起動するために使用されるセッションの送信元と宛先の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は、特定のデバイス上の侵入を認識し、IPアドレスとIDMEFメッセージ内のデバイスの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はアラートを生成するかどうかを判断するためのしきい値が含まれています。これは誤報であることの報告の可能性を示すことになるかもしれない報告書に1が持っている自信の度合いに影響を及ぼしたりすることがあります。
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長い寿命を有すること、および実装は、さまざまな環境での使用に適していることが望ましいです。したがって、（例えば、2038年日付表現制限など）IDMEFの寿命を制限する特性を避けなければなりません。
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は、検出素子上の特定のクロック精度を仮定することはできません、ので、イベントのタイムスタンプの粒度にすべての要件を課すことはできません。 NOR 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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2]ブラドナーの、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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、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]禁ずる、H.、カレー、D.、およびB.ファインスタイン、 "侵入検知メッセージ交換フォーマット（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
デビッド・カレー、IBM緊急対応サービス
David Donahoo, Air Force Information Warfare Center
デビッドDonahoo、空軍情報戦センター
Mike Erlinger, Harvey Mudd College
マイクErlinger、ハービーマッド・カレッジ
Fengmin Gong, Microcomputing Center of North Carolina
F工学ミンゴング、ノースカロライナ州のマイクロコンピューティング・センター
Dipankar Gupta, Hewlett-Packard
ディパンカー・グプタ、ヒューレット・パッカード
Glenn Mansfield, Cyber Solutions, Inc.
グレンマンスフィールド、サイバーソリューションズ株式会社
Jed Pickel, CERT Coordination Center
ジェドPickel、CERTコーディネーションセンター
Stuart Staniford-Chen, Silicon Defense
スチュアートStaniford・チェン、シリコン防衛
Maureen Stillman, Nokia IP Telephony
モーリーンスティルマン、ノキアIPテレフォニー
Authors' Addresses
著者のアドレス
Mark Wood Internet Security Systems, Inc. 6303 Barfield Road Atlanta, GA 30328 US
マーク・ウッドインターネットセキュリティシステムズ株式会社6303 Barfieldロードアトランタ、GA 30328米国
EMail: mark1@iss.net
メールアドレス：mark1@iss.net
Michael A. Erlinger Harvey Mudd College Computer Science Dept 301 East 12th Street Claremont, CA 91711 US
マイケルA. Erlingerハービーマッド大学のコンピュータサイエンス学部301東12ストリートクレアモント、CA 91711米国
EMail: mike@cs.hmc.edu URI: http://www.cs.hmc.edu/
電子メール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。