RFC4766 日本語訳
4766 Intrusion Detection Message Exchange Requirements. M. Wood, M.Erlinger. March 2007. (Format: TXT=50816 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Wood
Request for Comments: 4766 Internet Security Systems, Inc.
Category: Informational M. Erlinger
Harvey Mudd College
March 2007
コメントを求めるワーキンググループのM.の木製の要求をネットワークでつないでください: 4766年のインターネットセキュリティシステムInc.カテゴリ: 2007年の情報のM.Erlingerハーヴェイマッドの大学行進
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).
IETFが信じる著作権(C)(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.
Intrusion Detection Exchange Format作業部会(IDWG)の目的はそれらと対話する必要があるかもしれないマネージメントシステムに侵入検出と応答システムと、そして、興味がある情報交換のためにデータ書式と交換手順を定義することです。 このドキュメントはそのようなコミュニケーションメカニズムのためのハイレベルの要件について説明します、それらの要件のための明確化が必要である原理を含んでいて。 シナリオは、いくつかの要件を例証するのに使用されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Overview ........................................................4
2.1. Rationale for IDMEF ........................................4
2.2. Intrusion Detection Terms ..................................4
2.3. Architectural Assumptions ..................................8
2.4. Organization of This Document ..............................9
2.5. Document Impact on IDMEF Designs ..........................10
3. General Requirements ...........................................10
3.1. Use of Existing RFCs ......................................10
3.2. IPv4 and IPv6 .............................................10
4. Message Format Requirements ....................................11
4.1. Internationalization and Localization .....................11
4.2. Message Filtering and Aggregation .........................11
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. 概要…4 2.1. IDMEFのための原理…4 2.2. 侵入検出用語…4 2.3. 建築仮定…8 2.4. このドキュメントの組織…9 2.5. IDMEFデザインに影響を記録してください…10 3. 一般要件…10 3.1. 既存のRFCsの使用…10 3.2. IPv4とIPv6…10 4. メッセージ・フォーマット要件…11 4.1. 国際化とローカライズ…11 4.2. メッセージフィルタリングと集合…11
Wood & Erlinger Informational [Page 1] RFC 4766 IDME Requirements March 2007
2007年の[1ページ]RFC4766IDME要件行進の情報の木とErlinger
5. IDMEF Communication Protocol (IDP) Requirements ................12
5.1. Reliable Message Transmission .............................12
5.2. Interaction with Firewalls ................................12
5.3. Mutual Authentication .....................................13
5.4. Message Confidentiality ...................................13
5.5. Message Integrity .........................................13
5.6. Per-source Authentication .................................14
5.7. Denial of Service .........................................14
5.8. Message Duplication .......................................14
6. Message Content Requirements ...................................15
6.1. Detected Data .............................................15
6.2. Event Identity ............................................15
6.3. Event Background Information ..............................16
6.4. Additional Data ...........................................16
6.5. Event Source and Target Identity ..........................17
6.6. Device Address Types ......................................17
6.7. Event Impact ..............................................17
6.8. Automatic Response ........................................18
6.9. Analyzer Location .........................................18
6.10. Analyzer Identity ........................................19
6.11. Degree of Confidence .....................................19
6.12. Alert Identification .....................................19
6.13. Alert Creation Date and Time .............................20
6.14. Time Synchronization .....................................21
6.15. Time Format ..............................................21
6.16. Time Granularity and Accuracy ............................21
6.17. Message Extensions .......................................22
6.18. Message Semantics ........................................22
6.19. Message Extensibility ....................................22
7. Security Considerations ........................................23
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
9. Acknowledgements ...............................................23
5. IDMEF通信プロトコル(IDP)要件…12 5.1. 信頼できるメッセージ送信…12 5.2. ファイアウォールとの相互作用…12 5.3. 互いの認証…13 5.4. メッセージ秘密性…13 5.5. メッセージの保全…13 5.6. 1ソースあたりの認証…14 5.7. サービス妨害…14 5.8. メッセージ複製…14 6. メッセージ内容要件…15 6.1. データを検出します…15 6.2. イベントのアイデンティティ…15 6.3. イベント基礎的な情報…16 6.4. 追加データ…16 6.5. イベントソースと目標のアイデンティティ…17 6.6. デバイスアドレスタイプ…17 6.7. イベント影響…17 6.8. 自動応答…18 6.9. 分析器の位置…18 6.10. 分析器のアイデンティティ…19 6.11. 信用の度合い…19 6.12. 識別を警告してください…19 6.13. 作成日付と時間を警告してください…20 6.14. 時間同期化…21 6.15. 時間形式…21 6.16. 時間粒状と精度…21 6.17. メッセージ拡張子…22 6.18. メッセージ意味論…22 6.19. メッセージ伸展性…22 7. セキュリティ問題…23 8. 参照…23 8.1. 標準の参照…23 8.2. 有益な参照…23 9. 承認…23
Wood & Erlinger Informational [Page 2] RFC 4766 IDME Requirements March 2007
2007年の[2ページ]RFC4766IDME要件行進の情報の木とErlinger
1. Introduction
1. 序論
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.
このドキュメントはIntrusion Detection Message Exchange Format(IDMEF)[5](Intrusion Detection Exchange Format作業部会(IDWG)の製品)のための要件を定義します。 IDMEFは、自動化されたIntrusion Detection Systems(IDSs)[4]が彼らが疑わしげであるか、または興味があると考えたことを報告するのに使用できた標準書式になるように計画されていました。 また、このドキュメントはIDMEFを伝えるのに通信プロトコルのための要件を指定します。 チャーターされるように、IDWGには新しいものを指定するのを選ぶ前に最初に既存の通信プロトコルを評価する責任があります。 したがって、既存の通信プロトコルを評価するのに本書では要件を使用できます。 IDWGが、新しい通信プロトコルが必要であることを決定するなら、提案されたソリューションを評価するのに本書では要件を使用できます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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]でなく、その結果、キーワードが標準化過程文書でなければならない、NOT、SHOULD、および5月がBCP14、RFC2119[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 必須: 用語のこの単語、REQUIREDまたは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 必須NOT: この句、または句のSHALL NOTが、説明された振舞いか特性が提案された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 :であるべきです この単語、または形容詞的RECOMMENDED、特定の事情の無視する提案された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月: この単語、または形容詞的OPTIONALが、提案されたIDWG仕様には、本当に、説明された振舞いか特性が任意であることを意味します。 1つの提案された仕様が、説明された振舞いか特性を含んでいるのを選ぶかもしれませんが、別の提案された仕様は同じ振舞いか特性を省略するかもしれません。
Wood & Erlinger Informational [Page 3] RFC 4766 IDME Requirements March 2007
2007年の[3ページ]RFC4766IDME要件行進の情報の木とErlinger
2. Overview
2. 概要
2.1. Rationale for IDMEF
2.1. IDMEFのための原理
The reasons such a format should be useful are as follows:
そのような形式が役に立つべきである理由は以下の通りです:
1. A number of commercial and free Intrusion Detection Systems are
available and more are becoming available all the time. Some
products are aimed at detecting intrusions on the network, others
are aimed at host operating systems, while still others are aimed
at applications. Even within a given category, the products have
very different strengths and weaknesses. Hence it is likely that
users will deploy more than a single product, and users will want
to observe the output of these products from one or more
manager(s). A standard format for reporting will simplify this
task greatly.
1. 多くの商業の、そして、自由なIntrusion Detection Systemsが利用可能です、そして、以上は絶えず、利用可能になっています。 いくつかの製品はネットワークへの侵入を検出するのを目的とされます、他のものはホスト・オペレーティング・システムを向けられますが、それでも、他のものはアプリケーションを向けられます。 与えられたカテゴリの中にさえ、製品は非常に異なった長所と短所を持っています。 したがって、ユーザはただ一つの製品より展開しそうでしょう、そして、ユーザは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. 侵入は、頻繁に犠牲者として複数の組織にかかわるか、または同じ組織の中で複数のサイトにかかわります。 通常、それらのサイトは異なったIDSsを使用するでしょう。 複数のサイトと管理ドメインの向こう側にそのような分配された侵入を関連させるのは非常に役立っているでしょう。 すべてのサイトから一般的な形式において報告があるのはこのタスクを容易にするでしょう。
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. 一般的な形式の存在は、異なったIDSsからのコンポーネントが、より容易に統合しているのを許容するべきです。 したがって、Intrusion Detection(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市場が、より首尾よく成長して、革新されるのを助けるべきであり、本人確認のシステムの展開から効果を収めるIDSユーザをもたらすべきであると示唆します。
2.2. Intrusion Detection Terms
2.2. 侵入検出用語
In order to make the rest of the requirements clearer, we define some terms about typical IDSs. These terms are presented in alphabetical order. The diagram at the end of this section illustrates the relationships of some of the terms defined herein.
要件の残りを明らかにするために、私たちは典型的なIDSsに関するいくつかの用語を定義します。 これらの用語はアルファベット順に提示されます。 このセクションの端のダイヤグラムはここに定義されたいくつかの用語の関係を例証します。
Wood & Erlinger Informational [Page 4] RFC 4766 IDME Requirements March 2007
2007年の[4ページ]RFC4766IDME要件行進の情報の木とErlinger
2.2.1. Activity
2.2.1. 活動
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.
データ送信端末の中のオペレータにとって興味深いとしてセンサか分析器によって特定されるデータ送信端末か発生のElements。 しかし、この例が含んでいる、(制限されない、)、予期していなかった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).
活動は非常に重大な発生(明確に悪意がある攻撃などの)からそれほど重大でない発生(さらなる外観の価値がある珍しいユーザ活動などの)まで中立活動(ユーザログインなどの)に及ぶことができます。
2.2.2. Administrator
2.2.2. 管理者
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のオペレータと同じ人であるかもしれません。 いくつかの組織では、管理者はネットワークかシステム管理グループに関連しています。 他の組織では、それは独立している位置です。
2.2.3. Alert
2.2.3. 警戒
A message from an analyzer to a manager that an event of interest has been detected. An alert typically contains information about the unusual activity that was detected, as well as the specifics of the occurrence.
興味があるイベントが検出されたという分析器からマネージャまでのメッセージ。 警戒は検出された珍しい活動の情報、および発生の詳細を通常含んでいます。
2.2.4. Analyzer
2.2.4. 分析器
The ID component or process that analyzes the data collected by the sensor for signs of unauthorized or undesired activity or for events that might be of interest to the security administrator. In many existing IDSs, the sensor and the analyzer are part of the same component. In this document, the term analyzer is used generically to refer to the sender of the IDMEF message.
データを解析するIDコンポーネントかプロセスが権限のないか望まれない活動のサインかセキュリティ管理者にとって、興味深いかもしれないイベントのためのセンサで集まりました。 多くの既存のIDSsでは、センサと分析器は同じコンポーネントの一部です。 本書では、用語分析器は、IDMEFメッセージの送付者について言及するのに一般的に使用されます。
2.2.5. Data Source
2.2.5. データ送信端末
The raw information that an intrusion detection system uses to detect unauthorized or undesired activity. Common data sources include (but are not limited to) raw network packets, operating system audit logs, application audit logs, and system-generated checksum data.
侵入検知システムが権限のないか望まれない活動を検出するのに使用する生の情報。 しかし、一般的なデータ送信端末が含んでいる、(制限されない、)、生のネットワークパケット、オペレーティングシステム監査ログ、アプリケーション監査ログ、およびシステム生成のチェックサムデータ。
Wood & Erlinger Informational [Page 5] RFC 4766 IDME Requirements March 2007
2007年の[5ページ]RFC4766IDME要件行進の情報の木とErlinger
2.2.6. Event
2.2.6. イベント
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警戒をもたらすかもしれません、攻撃。
2.2.7. IDS
2.2.7. イド
Intrusion detection system. Some combination of one or more of the following components: sensor, analyzer, manager.
侵入検知システム。 以下のコンポーネントの1つ以上の何らかの組み合わせ: センサ、分析器、マネージャ。
2.2.8. Manager
2.2.8. マネージャ
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コンポーネントかプロセス。 しかし、管理機能が通常含んでいる、(制限されない、)、センサ構成、分析器の構成、イベント通知管理、データ強化、および報告。
2.2.9. Notification
2.2.9. 通知
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マネージャスクリーンにおける有色のアイコンのディスプレイ、メールかポケットベルのメッセージの伝達、またはSimple Network Managementプロトコル(SNMP)罠の送信でこれをします、また、他の通知のテクニックは使用されますが。
2.2.10. Operator
2.2.10. オペレータ
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マネージャの主たる利用者である人間。 オペレータは、さらなる動作をしばしば本人確認のシステムの出力をモニターして、開始するか、または推薦します。
2.2.11. Response
2.2.11. 応答
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アーキテクチャの何らかの実体によって自動的に引き受けられるか、または人間によって開始されるかもしれません。 オペレータに通知書を送るのは、非常に一般的な応答です。 しかし、他の応答が含んでいる、(制限されない、)、活動を登録します。 生データ(データ送信端末からの)を記録して、それはイベントを特徴付けました。 ネットワーク、ユーザ、またはアプリケーションセッションを終えます。 または、ネットワークかシステムアクセスを変更するのは制御されます。
Wood & Erlinger Informational [Page 6] RFC 4766 IDME Requirements March 2007
2007年の[6ページ]RFC4766IDME要件行進の情報の木とErlinger
2.2.12. Sensor
2.2.12. センサ
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提供の向こう側に異なるでしょう。 センサは分析器に前進のイベントまで設定されます。
2.2.13. Signature
2.2.13. 署名
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.
分析器によって使用される、セキュリティ管理者におもしろい活動を特定する規則。 署名はIDSsが侵入を検出するメカニズム(もっとも、必ず唯一のメカニズムであるというわけではない)の1つを表します。
2.2.14. Security Policy
2.2.14. 安全保障政策
The predefined, formally documented statement that defines what activities are allowed to take place on an organization's network or on particular hosts to support the organization's requirements. This includes, but is not limited to, which hosts are to be denied external network access.
どんな活動が組織の要件をサポートするために組織のネットワークの上、または、特定のホストの上で行われることができるかを定義する事前に定義されて、正式に記録された声明。 しかし、これが含んでいる、有限でないことで、外部のネットワークアクセサリーはどのホストに対して否定されることになっているか。
Wood & Erlinger Informational [Page 7] RFC 4766 IDME Requirements March 2007
2007年の[7ページ]RFC4766IDME要件行進の情報の木とErlinger
________
| | --------
| 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 |__|
|_______________|
________ | | -------- | データ|_________ ________| | __________ | ソース| 活動|センサ| | | |________| | |________| | オペレータ|_______ | | |__________| | \|/イベントA| _____V___ | /|\ | | | | \ | | センサ|__ | 通知| |_________| イベント| \ \|/A| V_________ \対/|\ | | | \応答| --->| 分析器|__ | A| | | 警戒| /|\ | |_________| | | | | A| | | | /|\ \|/ | | |________________| ____V___ | | | | |_| | | | マネージャ|_________| | |________| | セキュリティ/|\ _______________ | 方針__________| | | | | 管理者|__| |_______________|
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には、これらの別々のコンポーネントのすべてがちょうど示されるようにあるというわけではないでしょう。 いくつかのIDSsがこれらのコンポーネントをただ一つのモジュールに結合するでしょう。 或るものには、これらのモジュールの複数のインスタンスがあるでしょう。
2.3. Architectural Assumptions
2.3. 建築仮定
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
このドキュメントの目的のために、私たちは、分析器とマネージャが別々のコンポーネントであり、彼らがTCP/IPネットワークの向こう側に対状を伝えていると思います。 これらの実体のコミュニケーションの他のフォームは全く本書では熟考されません、そして、IDMEF警戒の他の使用は全く考えられません。 私たちはコミュニケーションを示します。
Wood & Erlinger Informational [Page 8] RFC 4766 IDME Requirements March 2007
2007年の[8ページ]RFC4766IDME要件行進の情報の木とErlinger
protocol that communicates IDMEF as the IDMEF Communication Protocol (IDP).
IDMEF Communicationプロトコル(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.
Trust Modelは要件として指定されませんが、むしろIDMEF Communicationプロトコル(すなわち、デザイン決定)の選択に残されます。 指定されることは個々のセキュリティ関連の要件です。 セクション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つのコンポーネントに関して機能であるかもしれないかどうか
2.4. Organization of This Document
2.4. このドキュメントの組織
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 Communicationプロトコル)にこれについて言及します。
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 これらの1番目は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セクションはコミュニケーションメカニズムに関する要件について概説します、IDP、分析器からマネージャ(セクション5)までIDMEFメッセージを動かすのにおいて、使用されています。
Wood & Erlinger Informational [Page 9] RFC 4766 IDME Requirements March 2007
2007年の[9ページ]RFC4766IDME要件行進の情報の木とErlinger
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.
各要件に関しては、私たちは、できるだけ明確にデザイン解決が何であるべきであるかに関する考えを押しつけないで要件を述べるのを試みます。 次に、私たちは、この要件が重要である理由のために原理を与えて、それは実現させるのが難しいなら、これが仕様に関する基本的な特徴であるべきですかそれとも欠けることができていながら有益であるかを述べます。 最終的に、それが必要に見えるところに、私たちは説明に役立ったシナリオを与えます。 いくつかの場合、私たちはシナリオで可能なデザイン解決を入れます。 これらは純粋に説明に役立っています。
2.5. Document Impact on IDMEF Designs
2.5. IDMEFデザインに関するドキュメント影響
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が設計する競争、そして/または、通信プロトコルを評価するのに追加測定基準を使用するかもしれないと認められます。
3. General Requirements
3. 一般要件
3.1. Use of Existing RFCs
3.1. 既存のRFCsの使用
The IDMEF SHALL reference and use previously published RFCs where possible.
IDMEF SHALL参照と使用は以前に、可能であるところでRFCsを発行しました。
3.1.1. Rationale
3.1.1. 原理
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は既に大きな研究と仕事をネットワークとセキュリティの領域に終了しました。 時間の関係で、既に定義されて、受け入れられた規格を使用するのは賢いです。
3.2. IPv4 and IPv6
3.2. IPv4とIPv6
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実装で作動するはずであることができるのを考慮に入れなければなりません。
3.2.1 Rationale
3.2.1 原理
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が環境であるとサポートしなければなりません。
Wood & Erlinger Informational [Page 10] RFC 4766 IDME Requirements March 2007
2007年の[10ページ]RFC4766IDME要件行進の情報の木とErlinger
4. Message Format Requirements
4. メッセージ・フォーマット要件
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 Communicationプロトコル(IDP)から独立していることを意図します。 IDMEF形式を変えないで完全に異なった移送機構を使用するのは可能であるべきです。 この要件の後ろの目標は意味論とコミュニケーションの間の清潔な分離にメカニズムを確実にすることです。明らかに、IDMEF Communicationプロトコルはお勧めです。
4.1. Internationalization and Localization
4.1. 国際化とローカライズ
IDMEF message formats SHALL support full internationalization and localization.
IDMEFメッセージ・フォーマットSHALLは完全な国際化とローカライズをサポートします。
4.1.1. Rationale
4.1.1. 原理
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メッセージをフォーマットしなければなりません。
4.1.2. Scenario
4.1.2. シナリオ
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仕様は数値事象IDを含むかもしれません。 IDMEF実装はこれらの数値事象IDを現地語記述に翻訳するかもしれません。 メッセージがストリングを含んでいて、情報が表されるかもしれない場合では、ISO/IECを使用するのは、国際化[3]を容易にするのにUTF-8変換形式を使用することで10646-1 文字集合であってコード化されています。
4.2. Message Filtering and Aggregation
4.2. メッセージフィルタリングと集合
The format of IDMEF messages MUST support filtering and/or aggregation of data by the manager.
IDMEFメッセージの形式はマネージャでデータのフィルタリング、そして/または、集合をサポートしなければなりません。
4.2.1. Rationale
4.2.1. 原理
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メッセージを構造化しなければなりません。
4.2.2. Scenario
4.2.2. シナリオ
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仕様提案は強い数字の意味論で固定フォーマットメッセージを推薦するかもしれません。 これは受入れステーションのそばで高い性能フィルタリングと集合に適しているでしょう。
Wood & Erlinger Informational [Page 11] RFC 4766 IDME Requirements March 2007
2007年の[11ページ]RFC4766IDME要件行進の情報の木とErlinger
5. IDMEF Communication Protocol (IDP) Requirements
5. IDMEF通信プロトコル(IDP)要件
5.1. Reliable Message Transmission
5.1. 信頼できるメッセージ送信
The IDP MUST support reliable transmission of messages.
IDP MUSTはメッセージの信頼できる伝達をサポートします。
5.1.1. Rationale
5.1.1. 原理
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に確かに提供するのは、重要です。
5.2. Interaction with Firewalls
5.2. ファイアウォールとの相互作用
The IDP MUST support transmission of messages between ID components across firewall boundaries without compromising security.
セキュリティに感染しないで、IDP MUSTはファイアウォール限界の向こう側にIDコンポーネントの間のメッセージの伝達をサポートします。
5.2.1. Rationale
5.2.1. 原理
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のできる分析器と彼らの対応するマネージャの間でしばしば配布されると予想されて、ファイアウォールの向こう側にプロキシか他の適当なメカニズムでメッセージをリレーする能力が必要です。 このコミュニケーションをセットアップするのは保護されたネットワークのセキュリティを弱める介入しているファイアウォールに釣り銭がいてはいけません。 または、SHOULD、これ、組織がIDMEFトラフィックと他の種類のトラフィックに別々の方針を適用するのがそれで難しくなるでしょう、したがって、他の種類のトラフィック(例えば、HTTPポストメソッドを積みすぎるのによる)にIDMEFメッセージを混ぜることによって、達成されてください。
5.2.2. Scenario
5.2.2. シナリオ
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などの)がモニターサービスをユーザに提供しているとき、これは起こることができます。 この場合、外国行きの接続はマネージャへの各分析器によって開始されるでしょう。 マネージャか分析器のどちらかが接続を開始するのを可能にするメカニズムはマネージャと分析器の展開に最大の柔軟性を提供するでしょう。
Wood & Erlinger Informational [Page 12] RFC 4766 IDME Requirements March 2007
2007年の[12ページ]RFC4766IDME要件行進の情報の木とErlinger
5.3. Mutual Authentication
5.3. 互いの認証
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 MUSTは分析器とマネージャの互いの認証を互いにサポートします。 応用層認証が基本的なトランスポート層の如何にかかわらず必要です。
5.3.1. Rationale
5.3.1. 原理
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.
警告メッセージが企業網のセキュリティに関連する応答かさらなる調査を指示するのにマネージャによって使用されるので、受信機は送付者のアイデンティティにおいて自信があって、送付者は受信機のアイデンティティにおいて自信があるのが、重要です。これはもう片方への各当事者のピアツーピア認証です。 それを基本的なコミュニケーションメカニズムの認証に制限してはいけなくて、例えば、リスクのために、この認証が処理されるのは、打倒されるか、またはmisconfiguredされるかもしれません。
5.4. Message Confidentiality
5.4. メッセージ秘密性
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 MUSTは交換処理の間、メッセージ内容の秘密性をサポートします。 選択されたデザインは、さまざまな暗号化がアルゴリズムであるとサポートすることができなければならなくて、さまざまな環境に融通がきくに違いありません。
5.4.1. Rationale
5.4.1. 原理
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メッセージは、潜在的に、非常に機密の情報(パスワードなどの)を含んでいて、すごく侵入者におもしろいでしょう。 これらのメッセージのいくつかが非制御のネットワークセグメントの向こう側に送られるのが、ありそうであるので、内容が保護されるのは、重要です。 その上、暗号技術のための法的環境が非常に様々であり、しばしば変化するので、選択されたデザインが多くの異なった暗号化オプションをサポートできて、ユーザがさまざまな環境に融通がきくのは、重要です。
5.5. Message Integrity
5.5. メッセージの保全
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 MUSTはメッセージ内容の保全を確実にします。 選択されたデザインは、さまざまな保全がメカニズムであるとサポートすることができなければならなくて、さまざまな環境に融通がきくに違いありません。
Wood & Erlinger Informational [Page 13] RFC 4766 IDME Requirements March 2007
2007年の[13ページ]RFC4766IDME要件行進の情報の木とErlinger
5.5.1. Rationale
5.5.1. 原理
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メッセージは、保護された企業網のセキュリティに関連する動作を指示するのにマネージャによって使用されます。 マネージャがメッセージの内容がトランスミッションの後に変えられていないのを確信しているのは、重大です。
5.6. Per-source Authentication
5.6. 1ソースあたりの認証
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 MUSTは、各送付者のために別々の認証がキーであるとサポートします。 左右対称のアルゴリズムが使用されているなら、これらのキーは、それがコミュニケートしているマネージャにとって知られている必要があるでしょう。
5.6.1. Rationale
5.6.1. 原理
Given that sensitive security information is being exchanged via the IDMEF, it is important that the manager can authenticate each analyzer sending alerts.
IDMEFを通して機密のセキュリティ情報を交換しているなら、マネージャが警戒を送る各分析器を認証できるのは、重要です。
5.7. Denial of Service
5.7. サービス妨害
The IDP SHOULD resist protocol denial-of-service attacks.
IDP SHOULDはプロトコルサービス不能攻撃に抵抗します。
5.7.1. Rationale
5.7.1. 原理
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がそのようなサービス不能攻撃に抵抗するのは、望ましいです。
5.7.2. Scenario
5.7.2. シナリオ
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トラフィック)が攻撃されるネットワークでコンポーネントの間で交換されているのを確信しています。 彼は、1つ以上の洪水イベントを開始することによって彼の存在にマスクをかけて、暗号化通信を混乱させると決めます。 IDPがそのような攻撃に抵抗できるなら、攻撃者が止められるという確率は増加します。
5.8. Message Duplication
5.8. メッセージ複製
The IDP SHOULD resist malicious duplication of messages.
IDP SHOULDはメッセージの悪意がある複製に抵抗します。
Wood & Erlinger Informational [Page 14] RFC 4766 IDME Requirements March 2007
2007年の[14ページ]RFC4766IDME要件行進の情報の木とErlinger
5.8.1. Rationale
5.8.1. 原理
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がそのようなメッセージ複製に抵抗するのは、望ましいです。
5.8.2. Scenario
5.8.2. シナリオ
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がそのようなメッセージ複製に抵抗するなら、攻撃者が止められるという確率は増加します。
6. Message Content Requirements
6. メッセージ内容要件
6.1. Detected Data
6.1. 検知データ
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.
IDSsの多くの異なったタイプがあります、署名、例外、相関関係、ネットワーク監視、ホストモニター、またはアプリケーションモニターに基づくものなどのように。 IDMEFデザインは、*それがそれを検出した*よりむしろIDSが検出したすべての*を*を運ぶのに集結するのによるこれらのさまざまのアプローチを収容するように努力しなければなりません。
6.1.1. Rationale
6.1.1. 原理
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.
さまざまなデータ送信端末を分析するIDSsの多くのタイプがあります。 或るものは、基づくプロフィールであり、ログファイル、攻撃署名などを作動させます。 他のものは、基づく異常であり、正常な行動を定義して、確立した基線からの逸脱を検出します。 それぞれのこれらのIDSsはそれらの侵入検出方法論に一部よる異なったデータを報告します。 この規格ですべてをサポートしなければなりません。
6.2. Event Identity
6.2. イベントのアイデンティティ
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メッセージの内容はイベント(イベントのアイデンティティ)の特定された名前を含まなければなりません。 イベントのアイデンティティがまだ標準化されていないなら、この名前は、イベント(利用可能であるなら)の標準化されたリストから得なければならないか、実装種名になるでしょう。 どのようにこの標準化されたリストを定義するか、またはアップデートするかが知られていません。 このリストの作成に関する要件は私たちの取り組みを超えています。 セキュリティアリーナの中の他のグループはそのようなリストの作成を調査しています。
Wood & Erlinger Informational [Page 15] RFC 4766 IDME Requirements March 2007
2007年の[15ページ]RFC4766IDME要件行進の情報の木とErlinger
6.2.1. Rationale
6.2.1. 原理
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マネージャが分析器から複数の実装から警戒を受けることができる、マネージャが報告されたイベントの意味論を理解しているのは、重要です。 したがって、それらのメソッドと可能なフィックスに関してこれらのイベントとして知られているイベントを特定して、情報を保存する必要があります。 いくつかのイベントがよく知られています、そして、この認識はオペレータを助けることができます。
6.2.2. Scenario
6.2.2. シナリオ
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マネージャへの同じイベントのアイデンティティを報告します、各分析器で攻撃を検出するのに使用されるアルゴリズムは異なったかもしれませんが。
6.3. Event Background Information
6.3. イベント基礎的な情報
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メッセージデザインは情報を含まなければならなくて、それは、受信機が警戒で報告されているイベントの種類に関する基礎的な情報の場所を見つけるのを許容します。(送付者は情報を提供するべきです)。
6.3.1. Rationale
6.3.1. 原理
This information is used by administrators to report and fix problems.
この情報は、問題を報告して、修正するのに管理者によって使用されます。
6.3.2. Scenario
6.3.2. シナリオ
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メッセージに含まれています。 オペレータは、害を被りやすいシステムで修理を開始するのにこの情報を使用します。
6.4. Additional Data
6.4. 追加データ
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メッセージはこの特定の基本的なイベントに関連する参照の追加詳細データにできるに違いありません。 それは実装がこの分野を使用するOPTIONALです。 要件は全くこの分野の形式か内容に置かれません。 これが作成者によって定義されて、説明されると予想されます。
6.4.1. Rationale
6.4.1. 原理
Operators might want more information on specifics of an event. This field, if filled in by the analyzer, MAY point to additional or more detailed information about the event.
オペレータはイベントの詳細に関する詳しい情報が欲しいかもしれません。 分析器によって記入されるなら、この分野はイベントの追加しているか、より詳細な情報を示すかもしれません。
Wood & Erlinger Informational [Page 16] RFC 4766 IDME Requirements March 2007
2007年の[16ページ]RFC4766IDME要件行進の情報の木とErlinger
6.5. Event Source and Target Identity
6.5. イベントソースと目標のアイデンティティ
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アドレスがイベントを始めるのに使用したソースと目的地になるでしょう。 オペレーティングシステムかアプリケーションレベルで始められるか、または検出されて、ソースと目標のアイデンティティが他のタイプのそれらなどのイベントのために異なることに注意してください。
6.5.1. Rationale
6.5.1. 原理
This will allow the operator to identify the source and target of the event.
これで、オペレータはイベントのソースと目標を特定できるでしょう。
6.6. Device Address Types
6.6. デバイスアドレスタイプ
The IDMEF message MUST support the representation of different types of device addresses.
IDMEFメッセージは異なったタイプのデバイスアドレスの表現をサポートしなければなりません。
6.6.1. Rationale
6.6.1. 原理
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中心でないアドレスを使用するかもしれません。
6.6.2. Scenario
6.6.2. シナリオ
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メッセージにそのアドレスだけを含んでいます。 別の状況はAsynchronous Transfer Mode(ATM)スイッチ骨組みのE.164アドレス形式を使用する分析器にかかわります。
6.7. Event Impact
6.7. イベント影響
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デザインドキュメントはこの価値の範囲を定義しなければなりません。
Wood & Erlinger Informational [Page 17] RFC 4766 IDME Requirements March 2007
2007年の[17ページ]RFC4766IDME要件行進の情報の木とErlinger
6.7.1. Rationale
6.7.1. 原理
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がそのような値の範囲を定義しなければならないと指定するだけです。
6.8. Automatic Response
6.8. 自動応答
The IDMEF message MUST provide information about the automatic actions taken by the analyzer in response to the event (if any).
IDMEFメッセージは分析器によってイベント(もしあれば)に対応して取られた自動行動の情報を提供しなければなりません。
6.8.1. Rationale
6.8.1. 原理
It is very important for the operator to know if there was an automated response and what that response was. This will help determine what further action to take, if any.
オペレータが自動化された応答があったかどうかと、その応答が何であったかを知るのは、非常に重要です。 これは、もしあればどんなさらなる行動を取ったらよいかを決定するのを助けるでしょう。
6.9. Analyzer Location
6.9. 分析器の位置
The IDMEF message MUST include information that would make it possible to later identify and locate the individual analyzer that reported the event.
IDMEFメッセージは後でイベントを報告した個々の分析器の特定して、場所を見つけるのを可能にする情報を含まなければなりません。
6.9.1. Rationale
6.9.1. 原理
The identity of the detecting analyzer often proves to be a valuable piece of data to have in determining how to respond to a particular event.
検出分析器のアイデンティティは特定のイベントに応じる方法を決定する際に持っている貴重なデータであるとしばしば判明します。
6.9.2. Scenario
6.9.2. シナリオ
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アドレスとして実装されるかもしれません。
Wood & Erlinger Informational [Page 18] RFC 4766 IDME Requirements March 2007
2007年の[18ページ]RFC4766IDME要件行進の情報の木とErlinger
6.10. Analyzer Identity
6.10. 分析器のアイデンティティ
The IDMEF message MUST be able to contain the identity of the implementor and the analyzer that detected the event.
IDMEFメッセージはイベントを検出した作成者と分析器のアイデンティティを含むことができなければなりません。
6.10.1. Rationale
6.10.1. 原理
Users might run multiple IDSs to protect their enterprise. This data will help the systems administrator determine which implementor and analyzer detected the event.
ユーザは、彼らの企業を保護するために複数のIDSsを実行するかもしれません。 このデータは、上級システムアドミニストレータが、どの作成者と分析器がイベントを検出したかを決心しているのを助けるでしょう。
6.10.2. Scenario
6.10.2. シナリオ
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の知られている能力か弱点を含むことができます。
6.11. Degree of Confidence
6.11. 信用の度合い
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メッセージはレポートの信用の度合いを述べることができなければなりません。 すべての分析器でこのデータを得ることができないかもしれないので、分析器によるこの分野の完成はOPTIONALです。
6.11.1. Rationale
6.11.1. 原理
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.
多くのIDSsが警戒を生成するかどうか決定する敷居を含んでいます。 これは、1つがレポートに持っている信用の度合いに影響を及ぼすかもしれないか、または恐らく間違い警報であるレポートの見込みを示すでしょう。
6.11.2. Scenario
6.11.2. シナリオ
The alarm threshold monitor is set at a low level to indicate that an organization wants reports on any suspicious activity, regardless of the probability of a real attack. The degree-of-confidence measure is used to indicate whether this is a low-probability or high- probability event.
アラーム敷居モニターは低レベルで組織がどんな不審な行動に関するレポートも欲しいのを示すように用意ができています、本当の攻撃の確率にかかわらず。 信用の度合い測定は、これが低い確率かそれとも高い確率イベントであるかを暗示するのに使用されます。
6.12. Alert Identification
6.12. 注意深い識別
The IDMEF message MUST be uniquely identifiable in that it can be distinguished from other IDMEF messages.
IDMEFメッセージは、他のIDMEFメッセージとそれを区別できるので、唯一身元保証可能でなければなりません。
Wood & Erlinger Informational [Page 19] RFC 4766 IDME Requirements March 2007
2007年の[19ページ]RFC4766IDME要件行進の情報の木とErlinger
6.12.1. Rationale
6.12.1. 原理
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メッセージを許容するでしょう。
6.12.2. Scenario
6.12.2. シナリオ
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展開、分析器が生のセンサ情報を登録する低レベルであるイベントでは、分析して、報告している間、例えばデータベースは、より高いレベルに結果として生じます。 この場合、証拠をサポートするとして結果メッセージにユニークな生のメッセージ識別子を含むことができます。 よりハイレベルの分析器は、後で必要なら、データベースからの生のメッセージを検索するのにこの識別子を使用できます。
6.13. Alert Creation Date and Time
6.13. 注意深い作成日付と時間
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 MUSTは注意深い作成日付と分析器が、警戒を作成すると決めた日時の各イベントにおける時に報告をサポートします。(作成日付と時間はイベントを参照します)。 IDMEF MAYは追加期日と回をサポートします、警戒によるイベント参照が始まった日時などのように。
6.13.1. Rationale
6.13.1. 原理
Time is important from both a reporting and correlation point of view. Event onset time might differ from the alert creation time because it might take some time for the sensor to accumulate information about a monitored activity before generating the event, and additional time for the analyzer to receive the event and create an alert. The event onset time is therefore more representative of the actual time that the reported activity began than is the alert creation time.
時間は報告と相関関係観点の両方から重要です。 センサがイベントを生成する前のモニターされた活動、および分析器がイベントを受けて、警戒を作成する追加およそ時間情報を蓄積するにはいくらかの時間がかかるかもしれないので、イベント発症時間は注意深い作成時間と異なるかもしれません。 したがって、イベント発症時間は注意深い作成時間より報告された活動が始まった実際の現代を代表しています。
6.13.2. Scenario
6.13.2. シナリオ
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.
イベントが夜の静かな時間報告されるなら、オペレータはそれの彼女が1日の忙しい時間報告された同じイベントに割り当てるだろうより高い優先度を割り当てるかもしれません。 その上、イベント(長いポート・スキャンなどの)は長日月の間、行われるかもしれません、そして、分析器がイベントが始まった時と同様に警戒の時間を報告するのは、役に立つでしょう。
Wood & Erlinger Informational [Page 20] RFC 4766 IDME Requirements March 2007
2007年の[20ページ]RFC4766IDME要件行進の情報の木とErlinger
6.14. Time Synchronization
6.14. 時間同期化
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.
SHALLを調節してください。同じマネージャが異なった時間帯における複数の分析器からのイベントを受け取ることができて、分析器の現地時間を推論できるくらいの報告されたそのようなものになってください。
6.14.1. Rationale
6.14.1. 原理
For event correlation purposes, it is important that the manager be able to normalize the time information reported in the IDMEF alerts.
イベント相関関係目的のために、マネージャがIDMEF警戒で報告された時間情報を正常にすることができるのは、重要です。
6.14.2. Scenario
6.14.2. シナリオ
A distributed ID system has analyzers located in multiple time zones, all reporting to a single manager. An intrusion occurs that spans multiple time zones as well as multiple analyzers. The central manager requires sufficient information to normalize these alerts and determine that all were reported near the same "time" and that they are part of the same attack.
分配された本人確認のシステムで、独身のマネージャにすべて報告して、複数の時間帯で分析器を位置させています。 複数の分析器と同様に複数の時間帯にわたる侵入は起こります。 主要なマネージャは、これらの警戒を正常にして、すべてが同じ「時間」の間報告されて、それらが同じ攻撃の一部であることを決定するために十分な情報を必要とします。
6.15. Time Format
6.15. 時間形式
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.
日付を報告するための形式はY2Kロールオーバーのすべての現在の規格で対応するに違いありません、そして、それには、2038年の先間、日付の値を報告し続けることができるくらいの能力がなければなりません。
6.15.1. Rationale
6.15.1. 原理
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年の日付の表現制限などの)の寿命を制限する特性を避けなければなりません。
6.16. Time Granularity and Accuracy
6.16. 時間粒状と精度
Time granularity and time accuracy in event messages SHALL NOT be specified by the IDMEF.
指定されていて、イベントメッセージSHALL NOTでIDMEFで粒状と時間精度を調節してください。
6.16.1. Rationale
6.16.1. 原理
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は、それが時計であると仮定できません。
Wood & Erlinger Informational [Page 21] RFC 4766 IDME Requirements March 2007
2007年の[21ページ]RFC4766IDME要件行進の情報の木とErlinger
6.17. Message Extensions
6.17. メッセージ拡張子
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メッセージは実装特有のデータを定義するのに作成者によって使用された拡張機能をサポートしなければなりません。 作成者によるこのメカニズムの使用はOPTIONALです。 このデータは各作成者で決定している実装特殊情報を含んでいます。 作成者はこれらの拡大を解釈する方法を示さなければなりません、作成者がどう彼らの実装特有の拡大について説明するかに置かれた決められた一定の要求が全くありませんが。 実装の特定のデータのためのそのようなメッセージ拡張子の不足か存在がinteroperationを壊してはいけません。
6.17.1. Rationale
6.17.1. 原理
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メッセージのinteroperationを壊すライセンスではありません。
6.18. Message Semantics
6.18. メッセージ意味論
The semantics of the IDMEF message MUST be well defined.
IDMEFメッセージの意味論をよく定義しなければなりません。
6.18.1. Rationale
6.18.1. 原理
Good semantics are key to understanding what the message is trying to convey so there are no errors. Operators will decide what action to take based on these messages, so it is important that they can interpret them correctly.
メッセージが誤りが全くないように何を伝えようとしているかを理解しているのに良い意味論は主要です。 オペレータが、これらのメッセージに基づいてどんな行動を取ったらよいかを決めるので、彼らが正しくそれらを解釈できるのは、重要です。
6.18.2. Scenario
6.18.2. シナリオ
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つの方法でそれを解釈します。 それには、メッセージを構成した作成者はオペレータの解釈からの異なった意味がいるつもりでした。 したがって、結果として起こる修正措置は不正確です。
6.19. Message Extensibility
6.19. メッセージ伸展性
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メッセージ・フォーマットはこの新情報を含むことができなければなりません。 そのようなメッセージ伸展性は相互運用性が影響を与えられないくらいの方法で起こらなければなりません。
Wood & Erlinger Informational [Page 22] RFC 4766 IDME Requirements March 2007
2007年の[22ページ]RFC4766IDME要件行進の情報の木とErlinger
6.19.1. Rationale
6.19.1. 原理
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メッセージのinteroperationを壊すライセンスではありません。
7. Security Considerations
7. セキュリティ問題
This document does not treat security matters, except that Section 5 specifies security requirements for the protocols to be developed.
セクション5がプロトコルが開発されるというセキュリティ要件を指定する以外に、このドキュメントはセキュリティの件を扱いません。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8.2. Informative References
8.2. 有益な参照
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[4] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[4] Shirey(R.、「インターネットセキュリティ用語集」、RFC2828)は2000がそうするかもしれません。
[5] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection
Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[5] 締め出してください、そして、H.、カレー、D.、およびB.ファインスティン、「侵入検出交換処理形式(IDMEF)」RFC4765は2007を行進させます。
9. Acknowledgements
9. 承認
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
デヴィッドCurry、IBMの非常時の応答サービス
David Donahoo, Air Force Information Warfare Center
デヴィッドDonahoo、空軍情報戦センター
Mike Erlinger, Harvey Mudd College
マイクErlinger、ハーヴェイマッド大学
Wood & Erlinger Informational [Page 23] RFC 4766 IDME Requirements March 2007
2007年の[23ページ]RFC4766IDME要件行進の情報の木とErlinger
Fengmin Gong, Microcomputing Center of North Carolina
Fengminゴング、ノースカロライナのMicrocomputingセンター
Dipankar Gupta, Hewlett-Packard
Dipankarグプタ、ヒューレット・パッカード
Glenn Mansfield, Cyber Solutions, Inc.
グレン・マンスフィールド、サイバーソリューション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
マーク・ウッドインターネットセキュリティシステムInc.6303Barfield Road GA30328アトランタ(米国)
EMail: mark1@iss.net
メール: mark1@iss.net
Michael A. Erlinger Harvey Mudd College Computer Science Dept 301 East 12th Street Claremont, CA 91711 US
第12東マイケルA.Erlingerハーヴェイマッド大学コンピュータサイエンス部301の通りカリフォルニア91711クレアーモント(米国)
EMail: mike@cs.hmc.edu URI: http://www.cs.hmc.edu/
メール: mike@cs.hmc.edu ユリ: http://www.cs.hmc.edu/
Wood & Erlinger Informational [Page 24] RFC 4766 IDME Requirements March 2007
2007年の[24ページ]RFC4766IDME要件行進の情報の木とErlinger
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Wood & Erlinger Informational [Page 25]
木製であってErlinger情報です。[25ページ]
一覧
スポンサーリンク
