Network Working Group J. Arvidsson
Request for Comments: 3067 Telia CERT
Category: Informational A. Cormack
JANET-CERT
Y. Demchenko
TERENA
J. Meijer
SURFnet
February 2001
TERENA's Incident Object Description and Exchange Format Requirements
TERENAのインシデントオブジェクト説明し、Exchange形式の要件
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 Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. Examples are used to illustrate the requirements where necessary.
インシデントオブジェクト説明と交換フォーマットの目的は、説明、アーカイブおよび調査、アーカイブ、統計でアラート、事件を含むのCSIRT（コンピュータセキュリティインシデント対応チーム）（間の事件についての情報を交換するための共通のデータ形式を定義することである、レポーティング、など）。この文書は、それらの要件の理由を含む、このような説明および交換フォーマットのための高レベルの要件を記載しています。例としては、ここで必要な要件を説明するために使用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHALL NOT"、 "SHOULD"、この文書では、 "べきでない" 推奨」、 "MAY"、および "" 任意のにありますRFC 2119に記載されるように解釈される[1]。
This document defines requirements for the Incident object Description and Exchange Format (IODEF), which is the intended product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2]. IODEF is planned to be a standard format which allows CSIRTs to exchange operational and statistical information; it may also provide a basis for the development of compatible and inter-operable tools for Incident recording, tracking and exchange.
この文書は、TERENAで入射分類作業部会（ITDWG）の目的物であるインシデントオブジェクトの説明と交換フォーマット（IODEF）、のための要件を定義する[2]。 IODEFはのCSIRTが動作し、統計情報を交換することができ、標準的なフォーマットであることが予定されています。それはまた、インシデント記録、追跡および交換のための互換性及び相互操作可能なツールの開発のための基礎を提供することができます。
Another aim is to extend the work of IETF IDWG (currently focused on Intrusion Detection exchange format and communication protocol) to the description of incidents as higher level elements in Network Security. This will involve CSIRTs and their constituency related issues.
別の目的は、ネットワークセキュリティの上位レベル要素として事件の説明にIETF IDWG（現在侵入検知交換フォーマットと通信プロトコルに焦点を当てた）の作業を拡張することです。これは、のCSIRTとその選挙関連の問題を伴います。
The IODEF set of documents of which this document is the first will contain IODEF Data Model and XML DTD specification. Further discussion of this document will take place in the ITDWG mailing lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>, archives are available correspondently at http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and http://hypermail.terena.nl/iodef-list/mail-archive/
文書のIODEFセットは、この文書には、IODEFデータモデルとXML DTDの仕様が含まれています最初のものです。この文書の更なる議論は、<incident-taxonomy@terena.nl>または<iodef@terena.nl> ITDWGのメーリングリストで行われる、アーカイブはhttp://hypermail.terena.nl/incident-taxonomy-でcorrespondentlyご利用いただけますリスト/メールアーカイブ/及びhttp://hypermail.terena.nl/iodef-list/mail-archive/
This work is based on attempts to establish cooperation and information exchange between leading/advanced CSIRTs in Europe and among the FIRST community. These CSIRTs understand the advantages of information exchange and cooperation in processing, tracking and investigating security incidents.
この作品は、ヨーロッパで最初のコミュニティの中で主導的/先進のCSIRT間の協力と情報交換を確立しようとする試みに基づいています。これらのCSIRTは、追跡し、セキュリティインシデントを調査し、情報交換や処理における協力の利点を理解しています。
Computer Incidents are becoming distributed and International and involve many CSIRTs across borders, languages and cultures. Post-Incident information and statistics exchange is important for future Incident prevention and Internet security improvement. The key element for information exchange in all these cases is a common format for Incident (Object) description.
コンピュータインシデントは、分散し、国際との国境、言語や文化を越えて多くのCSIRTを伴うなってきています。ポストインシデント情報と統計情報交換は、将来の事故防止やインターネットセキュリティの向上のために重要です。これら全ての場合において、情報交換のための重要な要素は、インシデント（オブジェクト）の説明のための一般的なフォーマットです。
It is probable that in further development or implementation the IODEF might be used for forensic purposes, and this means that Incident description must be unambiguous and allow for future custody (archiving/documentation) features.
さらに、開発や実装にIODEFは、法医学的目的のために使用されるかもしれないという可能性がある、これはインシデント記述は曖昧でないことや、将来の保管（アーカイブ/ドキュメント）の機能を可能にしなければならないことを意味します。
Another issue that is targeted by developing IODEF is a need to have higher level Incident description and exchange format than will be provided by IDS (Intrusion Detection Systems) and the proposed IDEF (Intrusion Detection Exchange Format). Compatibility with IDEF and other related standards will be satisfied by the IODEF requirement on modularity and extensibility. IODEF should vertically be compatible with IDMEF, IODEF might be able to include or reference IDMEF Alert message as initial information about Incident.
IODEFを開発することによって、標的にされたもう一つの問題は、IDS（侵入検知システム）と提案IDEF（侵入検知交換フォーマット）で提供されるよりも高いレベルのインシデントの記述と交換フォーマットを持っている必要があります。 IDEFや他の関連規格との互換性は、モジュール性と拡張性にIODEF要件によって満たされます。 IODEFが垂直IDMEFと互換性があり、IODEFは、インシデントに関する初期情報としてIDMEF警告メッセージを含むか、または参照することができるかもしれません。
A definition of the main terms used in the rest of document is given for clarity.
文書の残りの部分で使用される主な用語の定義は、明確にするために与えられています。
Where possible, existing definitions will be used; some definitions will need additional detail and further consideration.
可能であれば、既存の定義が使用されます。いくつかの定義は、追加の詳細、さらに検討が必要になります。
Taxonomy of the Computer Security Incident related terminology made by TERENA's ITDWG [2] is presented in [12].
TERENAのITDWG [2]によって作られたコンピュータセキュリティインシデントに関連する用語の分類は、[12]に提示されています。
An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system.
インテリジェントな脅威、セキュリティサービスを回避し、システムのセキュリティポリシーに違反する（特にメソッドや技術の意味での）意図的な試みである、すなわち、知的な行為から派生する、システムセキュリティ上の攻撃。
Attack can be active or passive, by insider or by outsider, or via attack mediator.
攻撃は、インサイダーまたは部外によって、または攻撃メディエーターを経由して、アクティブまたはパッシブことができます。
Attacker is individual who attempts one or more attacks in order to achieve an objective(s).
攻撃者は、客観的（複数可）を達成するために、1回のまたは複数の攻撃をしようとしている個人です。
For the purpose of IODEF attacker is described by its network ID, organisation which network/computer attack was originated and physical location information (optional).
IODEFの攻撃の目的は、そのネットワークID、ネットワーク/コンピュータ攻撃が発信された組織との物理的な位置情報（オプション）によって記載されているため。
CSIRT (Computer Security Incident Response Team) is used in IODEF to refer to the authority handling the Incident and creating Incident Object Description. The CSIRT is also likely to be involved in evidence collection and custody, incident remedy, etc.
CSIRT（コンピュータセキュリティインシデント対応チーム）権限事件を処理し、インシデントオブジェクトの説明の作成を参照するためにIODEFに使用されています。 CSIRTはまた、証拠収集と保管、入射救済などに関与している可能性があります
In IODEF CSIRT represented by its ID, constituency, public key, etc.
などそのID、選挙、公開鍵、で表さIODEF CSIRTで
An intended or unintended consequence of an attack which affects the normal operation of the targeted system or service. Description of damage may include free text description of actual result of attack, and, where possible, structured information about the particular damaged system, subsystem or service.
対象システムまたはサービスの正常な動作に影響を与え、攻撃の意図や意図せぬ結果。被害の説明は攻撃、および、特定の破損したシステム、サブシステムまたはサービスについての可能な、構造化された情報の実際の結果のフリーテキスト記述を含むことができます。
An action directed at a target which is intended to result in a change of state (status) of the target. From the point of view of event origination, it can be defined as any observable occurrence in a system or network which resulted in an alert being generated. For example, three failed logins in 10 seconds might indicate a brute-force login attack.
アクションは、ターゲットの状態（ステータス）の変化をもたらすことを意図している目標に向け。イベント発信の観点から、それが生成されるアラートをもたらしたシステムまたはネットワーク内の任意の観察発生として定義することができます。例えば、3つのブルートフォースログイン攻撃を示す可能性がある10秒でのログインに失敗しました。
Evidence is information relating to an event that proves or supports a conclusion about the event. With respect to security incidents (the events), it may include but is not limited to: data dump created by Intrusion Detection System (IDS), data from syslog file, kernel statistics, cache, memory, temporary file system, or other data that caused the alert or were collected after the incident happened.
証拠は、イベントについての結論を証明しているか、サポートされていたイベントに関する情報です。セキュリティインシデント（イベント）に関しては、それが含まれるが、これらに限定されない：侵入検知システム（IDS）によって作成されたデータ・ダンプ、syslogファイル、カーネル統計、キャッシュ、メモリ、一時ファイルシステム、または他のデータからその警告の原因となったか、事件が起こった後に採取しました。
Special rules and care must be taken when storing and archiving evidence, particularly to preserve its integrity. When necessary evidence should be stored encrypted.
特にその完全性を維持するために、保存し、証拠をアーカイブする場合には、特別なルールと注意が必要です。必要な証拠を保存しなければならない場合には暗号化されました。
According to the Guidelines for Evidence Collection and Archiving (Evidence) evidence must be strictly secured. The chain of evidence custody needs to be clearly documented.
証拠収集とアーカイブのためのガイドラインによると、（証拠）証拠が厳密に確保する必要があります。証拠保管の連鎖を明確に文書化する必要があります。
It is essential that evidence should be collected, archived and preserved according to local legislation.
証拠が現地の法律によると、収集し、アーカイブおよび保存されるべきであることが不可欠です。
An Incident is a security event that involves a security violation. An incident can be defined as a single attack or a group of attacks that can be distinguished from other attacks by the method of attack, identity of attackers, victims, sites, objectives or timing, etc.
インシデントは、セキュリティ侵害を伴うセキュリティイベントです。事件は、攻撃、攻撃者、被害者、サイト、目標やタイミングなどの身元の方法により、他の攻撃と区別することができ、単一の攻撃や攻撃のグループとして定義することができます
An incident is a root element of the IODEF. In the context of IODEF, the term Incident is used to mean a Computer Security Incident or an IT Security Incident.
インシデントは、IODEFのルート要素です。 IODEFの文脈において、用語のインシデントは、コンピュータセキュリティインシデントやITセキュリティインシデントを意味するために使用されます。
However we should distinguish between the generic definition of 'Incident' which is an event that might lead to damage or damage which is not too serious, and 'Security Incident' and 'IT Security Incident' which are defined below:
しかし、我々はあまりにも深刻ではない破損や損傷につながる可能性があるイベントである「事件」、および「セキュリティインシデント」と以下のように定義される「ITセキュリティインシデント」の一般的な定義を区別する必要があります。
a) Security incident is an event that involves a security violation. This may be an event that violates a security policy, UAP, laws and jurisdictions, etc. A security incident may also be an incident that has been escalated to a security incident.
a）は、セキュリティインシデントは、セキュリティ違反を伴うイベントです。これは、セキュリティインシデントは、セキュリティインシデントにエスカレートされた入射してもよいなど、セキュリティポリシー、UAP、法律や管轄区域に違反するイベントかもしれません。
A security incident is worse than an incident as it affects the security of or in the organisation. A security incident may be logical, physical or organisational, for example a computer intrusion, loss of secrecy, information theft, fire or an alarm that doesn't work properly. A security incident may be caused on purpose or by accident. The latter may be if somebody forgets to lock a door or forgets to activate an access list in a router.
セキュリティインシデントは、または組織内のセキュリティに影響を与えるように入射よりも悪いです。セキュリティインシデントは、例えば、コンピュータ侵入、機密性の喪失、情報の盗難、火災または正しく動作しないアラーム、論理的、物理的または組織であってもよいです。セキュリティインシデントは、故意に又は偶然によって引き起こされ得ます。誰かがドアをロックするのを忘れたり、ルータのアクセスリストを有効にし忘れた場合、後者であってもよいです。
b) An IT security incident is defined according to [9] as any real or suspected adverse event in relation to the security of a computer or computer network. Typical security incidents within the IT area are: a computer intrusion, a denial-of-service attack, information theft or data manipulation, etc.
B）ITセキュリティインシデントは、コンピュータ又はコンピュータネットワークのセキュリティに関連する任意の実際の又は疑われる有害事象として[9]に従って定義されます。 IT領域内の代表的なセキュリティインシデントは、次のとおりです。コンピュータ等の侵入、DoS攻撃、情報の盗難やデータ操作、
Impact describes result of attack expressed in terms of user community, for example the cost in terms of financial or other disruption
インパクトは、金融や他の混乱の面でコスト例えば、ユーザーコミュニティで表現攻撃の結果を説明します
A computer or network logical entity (account, process or data) or physical entity (component, computer, network or internetwork).
コンピュータやネットワークの論理エンティティ（アカウント、プロセスまたはデータ）または物理的実体（コンポーネント、コンピュータ、ネットワークまたはインターネット）。
Victim is individual or organisation which suffered the attack which is described in incident report.
被害者は、個人またはインシデントレポートに記述されている発作を起こし組織です。
For the purpose of IODEF victim is described by its network ID, organisation and location information.
IODEFの犠牲者のために、そのネットワークID、組織及び位置情報によって記述されます。
A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy.
システムのセキュリティポリシーに違反するために悪用される可能性がシステムの設計、実装、または運用・管理の欠陥や弱点。
Most systems have vulnerabilities of some sort, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds. Success depends on the degree of vulnerability, the strength of attacks, and the effectiveness of any countermeasures in use. If the attacks needed to exploit a vulnerability are very difficult to carry out, then the vulnerability may be tolerable. If the perceived benefit to an attacker is small, then even an easily exploited vulnerability may be tolerable. However, if the attacks are well understood and easily made, and if the vulnerable system is employed by a wide range of users, then it is likely that there will be enough benefit for someone to make an attack.
ほとんどのシステムは、ある種の脆弱性を持っているが、これはシステムが使用するにはあまりにも欠陥であることを意味するものではありません。必ずしもすべての脅威は、攻撃になり、そしてないすべての攻撃が成功します。成功は、脆弱性、攻撃の強さ、および使用中のいずれかの対策の有効性の程度に依存します。脆弱性を悪用するために必要な攻撃が実行するのが非常に困難である場合には、脆弱性は許容かもしれません。攻撃者に知覚される利益が小さい場合、次いでも容易に利用脆弱性は許容してもよいです。しかし、攻撃はよく理解し、簡単に作られ、かつ脆弱なシステムは、幅広いユーザーによって採用されている場合、誰かが攻撃を行うのに十分な利益があるだろうと考えているされている場合。
Other terms used: alert, activity, IDS, Security Policy, etc. - are defined in related I-Ds, RFCs and standards [3, 6, 7, 8, 9, 10].
他の使用された用語：アラート、活性などIDS、セキュリティポリシーは、 - 関連するI-DS、RFCおよび標準[3、6、7、8、9、10]で定義されています。
3.1. The IODEF shall reference and use previously published RFCs where possible.
3.1. IODEFは、以前に発表されたRFCは、可能な場合を参照して使用しなければなりません。
Comment: The IETF has already developed a number of standards in the areas of networks and security that are actually deployed in present Internet. Current standards provide framework for compatibility of IODEF with other related technologies necessary to operate /implement IODEF in practice. Another issue of compatibility for the IODEF is its general compatibility with IDEF currently being developed by IETF IDEWG. In the interest of time and compatibility, defined and accepted standards should be used wherever possible.
コメント：IETFは既に実際に存在するインターネットで展開されたネットワークとセキュリティの分野で多くの標準を開発しました。現在の基準は、実際に実装/ IODEFを動作させるために必要なその他の関連技術とIODEFの互換性のためのフレームワークを提供します。 IODEFのための互換性のもう一つの問題は、現在IETF IDEWGによって開発されているIDEFとの一般的な互換性です。時間と互換性の関心では、定義され、受け入れ基準は、可能な限り使用すべきです。
In particularly, IODEF specification proposals SHOULD rely heavily on existing communications, encryption and language standards, where possible.
可能な場合は特にで、IODEF仕様提案は、既存の通信、暗号化と言語の規格に大きく依存しているべきです。
Comment: Since some Incidents need involvement of CSIRTs from different countries, cultural and geographic regions, the IODEF description must be formatted such that they can be presented to an operator in a local language and adhering to local presentation formats.
コメント：一部のインシデントは、さまざまな国からのCSIRTの関与、文化的、地理的領域を必要とするので、IODEFの説明は、彼らが現地の言語でオペレータに提示し、地元のプレゼンテーション形式に付着することができるようにフォーマットする必要があります。
Although metalanguage for IODEF identifiers and labels is considered to be English, a local IODEF implementation might be capable to translate metalanguage identifiers and labels into local language and presentations if necessary.
IODEF識別子とラベルのためのメタ言語が英語であると考えられているが、ローカルIODEF実装は、必要に応じて現地の言語やプレゼンテーションにメタ言語識別子とラベルを翻訳することが可能かもしれません。
Localized presentation of dates, time and names may also be required. In cases where the messages contain text strings and names that need characters other than Latin-1 (or ISO 8859-1), the information preferably should be represented using the ISO/IEC IS 10646-1 character set and encoded using the UTF-8 transformation format, and optionally using local character sets and encodings [13].
日付、時間と名前のローカライズされたプレゼンテーションも必要になることがあります。メッセージはラテン1（またはISO 8859-1）以外の文字を必要とするテキスト文字列と名前が含まれているケースでは、情報は、好ましくはISO / IECを用いて表現する必要があります10646-1文字がUTF-8を使用して設定し、符号化され、変換形式、および必要に応じてローカル文字セットとエンコーディングを使用して[13]。
4.2. The IODEF must support modularity in Incident description to allow aggregation and filtering of data.
4.2. IODEFは、データの集約およびフィルタリングを可能にし、インシデントの説明で、モジュールをサポートしている必要があります。
Comment: It is suggested that Incident description with IODEF might include external information, e.g., from IDS, or reference externally stored evidence custody data, or such information might be removed from current IODEF description, e.g., in purposes of privacy or security. Another practical/real life motivation for this requirement is to give possibility for some CSIRTs/managers to perform filtering and/or data aggregation functions on IODEF descriptions for the purposes of statistics, reporting and high level Incident information exchange between CSIRTs and/or their constituency and sponsors.
コメント：IODEFとインシデント記述はIDSから、例えば、外部の情報が含まれる場合があります、または参照外部に保存された証拠の保管データ、またはそのような情報は、プライバシーやセキュリティの目的で、例えば、現在のIODEFの記述から削除される可能性がありますことを示唆しています。この要件のために別の実用的/現実の動機は、いくつかのCSIRT /管理者は統計の目的のためにIODEF記述にフィルタリングおよび/またはデータ集約機能を実行するために可能性を与えることのCSIRTおよび/またはその選挙区の間に報告し、高いレベルのインシデント情報交換でありますそして、スポンサー。
Therefore the IODEF descriptions MUST be structured to facilitate these operations. This also implies to strong IODEF semantics.
したがって、IODEF記述は、これらの操作を容易にするために、構造化されなければなりません。また、これは、強いIODEFのセマンティクスを意味します。
4.3. IODEF must support the application of an access restriction policy attribute to every element.
4.3. IODEFは、すべての要素へのアクセス制限ポリシー属性のアプリケーションをサポートしている必要があります。
Comment: IODEF Incident descriptions potentially contain sensitive or private information (such as passwords, persons/organisations identifiers or forensic information (evidence data)) and in some cases may be exposed to non-authorised persons. Such situations may arise particularly in case of Incident information exchange between CSIRTs or other involved bodies. Some cases may be addressed by encrypting IODEF elements, however this will not always be possible.
コメント：IODEFインシデント記述は、潜在的に（例えば、パスワード、個人/団体識別子または法医学的情報（証拠データ）のような）機密や個人情報が含まれているいくつかのケースでは非許可された人に暴露することができます。このような状況は、特に、のCSIRTまたは他の関与体間のインシデント情報交換の場合に生じ得ます。いくつかの例は、しかし、これは常に可能ではないだろう、IODEF要素を暗号化することによって対処することができます。
Therefore, to prevent accidental disclosure of sensitive data, parts of the IODEF object must be marked with access restriction attributes. These markings will be particularly useful when used with automated processing systems.
そのため、機密性の高いデータを誤って開示を防ぐために、IODEFオブジェクトの一部は、アクセス制限属性でマークされなければなりません。自動処理システムと共に使用される場合、これらのマーキングは、特に有用であろう。
5.1. IODEF exchange will normally be initiated by humans using standard communication protocols, for example, e-mail, WWW/HTTP, LDAP.
5.1. IODEF交換は、通常、電子メール、WWW / HTTP、LDAP、例えば、標準の通信プロトコルを使用して人間によって開始されます。
Comment: IODEF description is normally created by a human using special or standard text editors. The IODEF is targeted to be processed by automated Incident handling systems but still must be human readable, able to be viewed and browsed with standard tools (e.g., browsers or electronic table processors or database tools like MS Excel or Access). Incident information exchange will normally require authorisation by an operator or CSIRT manager so is not expected to be initiated automatically. The role of Incident handling system is to provide assistance and tools for performing the exchange.
コメント：IODEF記述は通常、特別なまたは標準のテキストエディタを使用して、人間によって作成されます。 IODEFは、システムを扱う自動化された事件で処理する対象としているが、それでも標準のツール（例えば、ブラウザや電子テーブルプロセッサまたはMS ExcelやAccessのようデータベースツール）で表示し、閲覧することができ、読める人間でなければなりません。インシデント情報交換は、通常その自動的に開始されることが予想されていないオペレータやCSIRT管理者による承認が必要になります。インシデントハンドリングシステムの役割は、交換を行うための支援やツールを提供することです。
It is important to distinguish the purposes of the machine readable and exchangeable IDEF Intrusion message format and the human oriented and created IODEF Incident description.
機械可読と交換可能IDEF侵入メッセージフォーマットと人間指向と作成したIODEFインシデント記述の目的を区別することが重要です。
Communications security requirements will be applied separately according to local policy so are not defined by this document.
コミュニケーションセキュリティ要件はそう、この文書で定義されていないローカルポリシーに応じて個別に適用されます。
6.1. The root element of the IO description should contain a unique identification number (or identifier), IO purpose and default permission level
6.1. IO記述のルート要素は、固有の識別番号（または識別子）、IO目的と既定のアクセス許可レベルを含むべきです
Comment: Unique identification number (or identifier) is necessary to distinguish one Incident from another. It is suggested that unique identification number will contain information at least about IO creator, i.e. CSIRT or related body. The classification of the Incident may also be used to form a unique identification number. IO purpose will actually control which elements are included in the IODEF object Purposes may include incident alert/registration, handling, archiving, reporting or statistics. The purpose, incident type or status of Incident investigation may require different levels of access permission for the Incident information.
コメント：固有の識別番号（または識別子）から別のインシデントを区別する必要があります。固有の識別番号が少なくともIO作成者、すなわちCSIRTまたは関連体についての情報を含むであろうことが示唆されます。インシデントの分類はまた、固有の識別番号を形成するために使用され得ます。 IOの目的は、実際にインシデント・アラート/登録、取扱い、保管、報告や統計を含むことがIODEFオブジェクトの目的に含まれる要素を制御します。インシデント調査の目的は、インシデントの種類または状態は、入射した情報に対するアクセス許可の異なるレベルを必要とするかもしれません。
It is considered that root element of the IODEF will be <INCIDENT> and additional information will be treated as attributes of the root element.
IODEFのルート要素は<INCIDENT>と追加情報がルート要素の属性として扱われることになると考えられます。
6.2. The content of the IODEF description should contain the type of the attack if it is known.
6.2. それがわかっている場合IODEF記述の内容は、攻撃の種類が含まれている必要があります。
It is expected that this type will be drawn from a standardized list of events; a new type of event may use a temporary implementation-specific type if the event type has not yet been standardized.
このタイプのイベントの標準化されたリストから引き出されることが期待されます。イベントタイプがまだ標準化されていない場合は、イベントの新しいタイプは、一時的な実装固有のタイプを使用することができます。
Comment: Incident handling may involve many different staff members and teams. It is therefore essential that common terms are used to describe incidents.
コメント：インシデントハンドリングは、多くの異なるスタッフとチームを伴うことがあります。一般的な用語は、事件を記述するために使用されていることが不可欠です。
If the event type has not yet been standardized, temporary type definition might be given by team created IO. It is expected that new type name will be self-explanatory and derived from a similar, existing type definition.
イベントタイプがまだ標準化されていない場合は、一時的な型定義は、IOを作成したチームによって与えられるかもしれません。新しいタイプの名前は自明と同様に、既存の型定義から派生であることが期待されます。
6.3. The IODEF description must be structured such that any relevant advisories, such as those from CERT/CC, CVE, can be referenced.
6.3. IODEF記述は、CERT / CC、CVEからのもののような任意の関連勧告は、参照することができるように構成されなければなりません。
Comment: Using standard Advisories and lists of known Attacks and Vulnerabilities will allow the use of their recommendations on Incident handling/prevention. Such information might be included as an attribute to the attack or vulnerability type definition.
コメント：既知の攻撃や脆弱性の標準勧告とリストを使用すると、インシデントハンドリング/予防に関する提言を使用することができるようになります。このような情報は、攻撃や脆弱性タイプの定義に属性として含まれている場合があります。
6.4. IODEF may include a detailed description of the attack that caused the current Incident.
6.4. IODEFは、現在のインシデントを引き起こした攻撃の詳細な記述を含むことができます。
Comment: Description of attack includes information about attacker and victim, the appearance of the attack and possible impact. At the early stage of Intrusion alert and Incident handling there is likely to be minimal information, during handling of the Incident this will grow to be sufficient for Incident investigation and remedy. Element <ATTACK> should be one of the main elements of Incident description.
コメント：攻撃の説明攻撃者と被害者、攻撃や可能性への影響の外観に関する情報が含まれています。侵入警報やインシデントハンドリングの初期の段階では、これが事件の調査と救済のために十分であるように成長するインシデントの取り扱い中に、最小限の情報がありそうです。要素<ATTACK>インシデント記述の主要な要素の一つであるべきです。
6.5. The IODEF description must include or be able to reference additional detailed data related to this specific underlying event(s)/activity, often referred as evidence.
6.5. IODEF記述は、しばしば、または証拠と呼ばれるこの特定の基礎となるイベント（単数または複数）/活動に関連する追加の詳細なデータを参照することができなければなりません。
Comment: For many purposes Incident description does not need many details on specific event(s)/activity that caused the Incident; this information may be referenced as external information (by means of URL). In some cases it might be convenient to store separately evidence that has different access permissions. It is foreseen that another standard will be proposed for evidence custody [5].
コメント：インシデント記述は、特定のイベント（複数可）インシデントを引き起こした/活性に多くの詳細を必要としない多くの目的のために、この情報は、（URLによって）外部情報として参照することができます。いくつかの場合には、別途異なるアクセス権限を持っている証拠を保存するために便利かもしれません。別の標準は、証拠のカストディ[5]のために提案されることが予想されます。
6.6. The IODEF description MUST contain the description of the attacker and victim.
6.6. IODEFの記述は、攻撃者と被害者の説明を含まなければなりません。
Comment: This information is necessary to identify the source and target of the attack. The minimum information about attacker and victim is their IP or Internet addresses, extended information will identify their organisations allowing CSIRTs to take appropriate measures for their particular constituency.
コメント：この情報は、攻撃のソースとターゲットを特定する必要があります。攻撃者と被害者についての最低限の情報は、そのIPアドレスまたはインターネットアドレスで、拡張情報は、のCSIRTが特定の選挙のための適切な措置をとることができ、組織を識別します。
6.7. The IODEF description must support the representation of different types of device addresses, e.g., IP address (version 4 or 6) and Internet name.
6.7. IODEF記述は、デバイスアドレス、例えば、IPアドレス（バージョン4又は6）と、インターネット名の異なるタイプの表現をサポートしなければなりません。
Comment: The sites from which attack is launched might have addresses in various levels of the network protocol hierarchy (e.g., Data layer 2 MAC addresses or Network layer 3 IP addresses). Additionally, the devices involved in an intrusion event might use addresses that are not IP-centric, e.g., ATM-addresses. It is also understood that information about the source and target of the attack might be obtained from IDS and include the IP address, MAC address or both.
コメント：起動された攻撃からサイトは、ネットワークプロトコル階層の様々なレベル（例えば、データ層2のMACアドレスまたはネットワークレイヤ3つのIPアドレス）のアドレスを持っているかもしれません。また、侵入イベントに関係するデバイスは、例えば、ATM-アドレス、IP中心のないアドレスを使用する場合があります。また、攻撃のソースとターゲットについての情報をIDSから取得し、IPアドレス、MACアドレス、またはその両方が含まれるかもしれないことが理解されます。
6.8. IODEF must include the Identity of the creator of the Incident Object (CSIRT or other authority). This may be the sender in an information exchange or the team currently handling the incident.
6.8. IODEFは、インシデントオブジェクト（CSIRTまたはその他の権限）の作成者のアイデンティティを含める必要があります。これは、情報交換における送信者または現在のインシデントハンドリングチームかもしれません。
Comment: The identity of Incident description creator is often valuable information for Incident response. In one possible scenario the attack may progress through the network, comparison of corresponding incidents reported by different authorities might provide some additional information about the origin of the attack. This is also useful information at post-incident information handling/exchange stage.
コメント：インシデント記述作成者の身元は、多くの場合、インシデント対応のための貴重な情報です。一つの可能なシナリオでは、攻撃は、ネットワークを介して進行することが、別の当局が報告し、対応する事件の比較は、攻撃の起源についていくつかの追加情報を提供するかもしれません。また、これは、ポストインシデント情報の取り扱い/交換段階で有用な情報です。
6.9. The IODEF description must contain an indication of the possible impact of this event on the target. The value of this field should be drawn from a standardized list of values if the attack is recognized as known, or expressed in a free language by responsible CSIRT team member.
6.9. IODEF記述は、ターゲット上でこのイベントの可能性のある影響の指標を含んでいなければなりません。攻撃が知られているように認識、または責任CSIRTチームのメンバーによる自由な言語で表現されている場合、このフィールドの値は、値の標準化されたリストから引き出されなければなりません。
Comment: Information concerning the possible impact of the event on the target system provides an indication of what the attacker is attempting to do and is critical data for the CSIRTs to take actions and perform damage assessment. If no reference information (Advisories) is available, this field may be filled in based on CSIRT team experience.
コメント：ターゲットシステム上のイベントの影響の可能性に関する情報は、攻撃者が何しようとしているかの指標を提供し、行動を取ると、損害評価を行うためのCSIRTのための重要なデータです。何の参照情報（アドバイザリ）が利用できない場合、このフィールドは、CSIRTチームの経験に基づいて、中に充填することができます。
It is expected that most CSIRTs will develop Incident handling support systems, based on existing Advisories (such as those from CERT/CC, CVE, etc.) that usually contain list of possible impacts for identified attacks.
ほとんどのCSIRTは、通常、特定された攻撃の可能な影響のリストが含まれている（たとえば、CERT / CC、CVEなどからのもののような）既存の勧告に基づいて、インシデントハンドリング支援システムを開発することが期待されます。
This also relates to the development of IDEF which will be implemented in intelligent IDS, able to retrieve information from standard databases of attacks and vulnerabilities [3].
これはまた、インテリジェントなIDSに実装されるIDEFの開発に関し、攻撃や脆弱性の標準データベースから情報を取り出すことができる[3]。
6.10. The IODEF must be able to state the degree of confidence in the report information.
6.10. IODEFは、レポートの情報の信頼度を述べることができなければなりません。
Comment: Including this information is essential at the stage of Incident creation, particularly in cases when intelligent automatic IDS or expert systems are used. These normally use statistical engines to estimate the event probability.
コメント：この情報を含めるには、特に、インテリジェントな自動IDSやエキスパートシステムが使用されている場合には、インシデントの作成の段階で必要不可欠です。これらは通常、発生確率を推定するために統計的なエンジンを使用しています。
6.11. The IODEF description must provide information about the actions taken in the course of this incident by previous CSIRTs.
6.11. IODEFの説明は、前のCSIRTによってこの事件の過程で行われたアクションに関する情報を提供する必要があります。
Comment: The IODEF describes an Incident throughout its life-time from Alert to closing and archiving. It is essential to track all actions taken by all involved parties. This will help determine what further action needs to be taken, if any. This is especially important in case of Incident information exchange between CSIRTs in process of investigation.
コメント：IODEFは、決算やアーカイブへのアラートからその寿命を通じてインシデントについて説明します。すべての関係者が取るすべてのアクションを追跡することが不可欠です。これは、さらなる行動があれば、注意が必要かを決定するのに役立ちます。これは、調査の過程でのCSIRT間のインシデント情報交換の場合には特に重要です。
6.12. The IODEF must support reporting of the time of all stages along Incident life-time.
6.12. IODEFは、インシデントの寿命に沿ってすべての段階の時間の報告をサポートしている必要があります。
Comment: Time is important from both a reporting and correlation point of view. Time is one of main components that can identify the same Incident or attack if launched from many sites or distributed over the network. Time is also essential to be able to track the life of an Incident including Incident exchange between CSIRTs in process of investigating.
コメント：時間は、ビューの両方の報告と相関の点からも重要です。時間は、多くのサイトから起動またはネットワーク上に分散場合には、同じインシデントや攻撃を識別することができます主な成分の一つです。時間はまた、調査の過程でのCSIRT間のインシデント交換など、インシデントの生活を追跡することができることが不可欠です。
6.13. Time shall be reported as the local time and time zone offset from UTC. (Note: See for guidelines on reporting time.)
6.13. 時間はUTCからのオフセット現地時間とタイムゾーンとして報告しなければなりません。 （注：時間の報告に関するガイドラインを参照してください。）
Comment: For event correlation purposes, it is important that the manager be able to normalize the time information reported in the IODEF descriptions.
コメント：イベント相関目的のためには、管理者がIODEFの説明で報告された時間情報を正規化することができることが重要です。
6.14. The format for reporting the date must be compliant with all current standards for Year 2000 rollover, and it must have sufficient capability to continue reporting date values past the year 2038.
6.14. 日付を報告するための形式は、2000年のロールオーバーのためのすべての現在の基準に準拠している必要があり、それは2038年過去の日付の値を報告し続けるために十分な能力を持たなければなりません。
Comment: It is stated in the purposes of the IODEF that the IODEF shall describe the Incident throughout its life-time. In the case of archiving this duration might be unlimited. Therefore, implementations that limit expression of time value (such as 2038 date representation limitation in "Unix time") MUST be avoided.
コメント：IODEFは、その寿命を通じてインシデントについて記述しなければならないことをIODEFの目的で記載されています。アーカイブの場合、この期間は無制限であるかもしれません。したがって、（「UNIX時間」におけるような2038年の日付表現制限）時間値の表現を制限する実装は避けなければなりません。
6.15. Time granularity in IO time parameters shall not be specified by the IODEF.
6.15. IOの時間パラメータの時間粒度はIODEFによって指定されてはなりません。
Comment: The time data may be included into IODEF description by existing information systems, retrieved from incident reporting messages or taken from IDS data or other event registration tools. Each of these cases may have its own different time granularity. For the purposes of implementation, it should be possible to handle time at different stages according to the local system capabilities.
コメント：データは、インシデントから取り出され、既存の情報システムによってIODEF記述に含めることができる時間は、メッセージをレポートまたはIDSデータまたは他のイベント登録ツールから採取しました。これらの例はそれぞれ独自の異なる時間精度を有することができます。実施の目的のためには、ローカルシステムの能力に応じて異なる段階で時間を扱うことが可能であるべきです。
6.16. The IODEF should support confidentiality of the description content.
6.16. IODEFは、記述内容の機密性をサポートする必要があります。
The selected design should be capable of supporting a variety of encryption algorithms and must be adaptable to a wide variety of environments.
選択されたデザインは、様々な暗号化アルゴリズムをサポートすることが可能であるべきとさまざまな環境に適応しなければなりません。
Comment: IODEF Incident descriptions potentially contain sensitive or private information (such as forensic data (evidence data), passwords, or persons/organisations identifiers) which would be of great interest to an attacker or malefactor. Incident information normally will be stored on a networked computer, which potentially may be exposed to attacks (or compromised). Incident information may be transmitted across uncontrolled network segments. Therefore, it is important that the content be protected from unauthorised access and modification. Furthermore, since the legal environment for privacy and encryption technologies are varied from regions and countries and change 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. Additional measures may be undertaken for securing the Incident during communication but this issue is outside of IODEF scope as it implies more strict rules for IO archiving and storing in general.
コメント：IODEFインシデント記述は、攻撃者や犯罪者に大きな関心があるであろう（例えばフォレンジックデータ（証拠データ）、パスワード、または個人/団体識別子など）、機密や個人情報が含まれています。インシデント情報は、通常、潜在的な攻撃にさらされる（または損なわ）することができるネットワーク化されたコンピュータ上に格納されます。インシデント情報は、制御されないネットワークセグメントを介して送信されてもよいです。したがって、コンテンツが不正なアクセスや変更から保護することが重要です。プライバシーと暗号化技術のための法的環境が地域や国から変えると、頻繁に変更されているので、選択されたデザインが異なる暗号化オプションの数をサポートすることができると、さまざまな環境にユーザーによって適応できることが重要です。追加の対策が通信中にインシデントを確保するために行われてもよいが、それはIOアーカイブと一般的に記憶するため、より厳格なルールを意味するように、この問題は、IODEFの範囲外です。
6.17. The IODEF should ensure the integrity of the description content.
6.17. IODEFは、記述内容の整合性を確保すべきです。
The selected design should be capable of supporting a variety of integrity mechanisms and must be adaptable to a wide variety of environments.
選択されたデザインは、整合性のさまざまなメカニズムをサポートすることが可能であるべきとさまざまな環境に適応しなければなりません。
Comment: Special measures should be undertaken to prevent malicious IO changes.
コメント：特別な措置は、悪質なIOの変化を防ぐために行われるべきです。
Additional measures may be undertaken for securing the Incident during communication but this issue is outside of IODEF scope.
追加の対策が通信中にインシデントを確保するために着手することができるが、この問題は、IODEFの範囲外です。
6.18. The IODEF should ensure the authenticity and non-repudiation of the message content.
6.18. IODEFは、メッセージ内容の信憑性と否認防止を確実にしなければなりません。
Comment: Authenticity and accountability is needed by many teams, especially given the desire to automatically handle IOs, therefore it MUST be included in the IODEF. Because of the importance of IO authenticity and non-repudiation to many teams and especially in case of communication between them, the implementation of these requirements is strongly RECOMMENDED.
コメント：真正性と説明責任は、特にそれゆえ、それがIODEFに含まれなければならない、自動的にOを処理するための欲求を与え、多くのチームが必要とされています。多くのチーム、特にそれらの間の通信の場合はIOの信憑性と否認防止の重要性のため、これらの要件の実装が強く推奨されます。
6.19. The IODEF description must support an extension mechanism which may be used by implementers. This allows future implementation-specific or experimental data. The implementer MUST indicate how to interpret any included extensions.
6.19. IODEF記述は、実装者によって使用することができる拡張メカニズムをサポートしなければなりません。これは、将来の実装固有または実験データを可能にします。実装者は、任意の付属の拡張機能をどのように解釈するかを指定する必要があります。
Comment: Implementers might wish to supply extra data such as information for internal purposes or necessary for the particular implementation of their Incident handling system. These data may be removed or not in external communications but it is essential to mark them as additional to prevent wrong interpretation by different systems.
コメント：実装者は、そのような彼らのインシデントハンドリングシステムの特定の実装のための内部的な目的のための情報や必要に応じて追加のデータを提供したいかもしれません。これらのデータは削除したりしない外部の通信ではなく、異なるシステムによって間違った解釈を防ぐために、追加としてそれらをマークすることが不可欠であることができます。
Comment: IODEF is a human oriented format for Incident description, and IODEF description should be capable of being read by humans. The use of automatic parsing tools is foreseen but should not be critically necessary. Therefore, IODEF must provide good semantics, which will be key to understanding what the description contains. In some cases the IODEF description will be used for automatic decision making, so it is important that the description be interpreted correctly. This is an argument for using language-based semantics. The metalanguage for IODEF identifiers and labels is proposed to be English, a local IODEF implementation might be able to translate metalanguage identifiers and labels into local language and presentations if necessary.
コメント：IODEFインシデント記述のヒト指向フォーマットであり、IODEF記述は、人間が読み取り可能でなければなりません。自動解析ツールの使用が予想されるが、批判的に必要ありません。したがって、IODEFは記述が含まれているものを理解するための鍵となるでしょう良い意味論を、提供しなければなりません。いくつかのケースではIODEFの記述は、自動意思決定のために使用されますので、説明が正しく解釈することが重要です。これは、言語ベースのセマンティクスを使用するための引数です。 IODEF識別子とラベルのためのメタ言語が英語であることが提案され、ローカルIODEF実装は、必要に応じて現地の言語やプレゼンテーションにメタ言語識別子とラベルを翻訳することができるかもしれません。
7.1. The IODEF itself MUST be extensible. It is essential that when the use of new technologies and development of automated Incident handling system demands extension of IODEF, the IODEF will be capable to include new information.
7.1. IODEF自体が拡張可能でなければなりません。自動化されたインシデントハンドリングシステムの新技術の利用と開発がIODEFの拡張を要求したときに、IODEFが、新しい情報を含むようにすることができるであろうことが不可欠です。
Comment: In addition to the need to extend IODEF to support new Incident handling tools, it is also suggested that IODEF will incorporate new developments from related standardisation areas such as IDEF for IDS or the development of special format for evidence custody. The procedure for extension should be based on CSIRT/IODEF community acceptance/approval.
コメント：ツールを扱う新しいインシデントをサポートするためにIODEFを拡張する必要性に加えて、IODEFは、IDSや証拠の保管のための特別なフォーマットの開発のためにこのようなIDEFなどの関連標準化の分野から新たな展開を組み込む予定ということも示唆されました。拡張のための手順は、CSIRT / IODEFコミュニティの受諾/承認に基づくべきです。
This memo describes requirements to an Incident Object Description and Exchange Format, which intends to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (including alert, incident in investigation, archiving, statistics, reporting, etc.). In that respect the implementation of the IODEF is a subject to security considerations. Particular security requirement to access restriction indication is discussed in section 4.3, requirements to Incident description confidentiality, integrity, authenticity and non-repudiation are described in sections 6.16, 6.17, 6.18.
このメモは、説明、アーカイブおよび調査でアラート、事件を含むのCSIRT間の事件（、アーカイブ、統計、レポート作成などについての情報を交換するための共通のデータフォーマットを定義することを意図インシデントオブジェクト説明と交換フォーマットへの要件について説明します）。その点において、IODEFの実装では、セキュリティの考慮の対象となります。アクセス制限指示に特定のセキュリティ要件は、セクション4.3で説明され、インシデント記述の機密性、完全性、真正性および否認防止の要件は、セクション6.16、6.17、6.18に記載されています。
[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] Incident Taxonomy and Description Working Group Charter - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/
[2]インシデント分類と説明ワーキンググループ憲章 - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/
[3] Intrusion Detection Exchange Format Requirements by Wood, M. - December 2000, Work in Progress.
[3]ウッド、M.による侵入検知交換フォーマットの要件 - 2000年12月には、進行中の作業します。
[4] Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition by D. Curry, H. Debar - February 2001, Work in Progress.
[4] D.カレー、H.禁ずることにより、侵入検知メッセージ交換フォーマット拡張マークアップ言語（XML）文書型定義 - 2001年2月、進行中の作業を。
[5] Guidelines for Evidence Collection and Archiving by Dominique Brezinski, Tom Killalea - July 2000, Work in Progress.
[5]ドミニクBrezinski、トム・Killaleaによって証拠収集とアーカイブのためのガイドライン - 2000年7月、進行中の作業を。
[6] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998.
[6]ブラウンリー、N.とE.グットマン、BCP 21、RFC 2350、1998年6月 "コンピュータセキュリティインシデント対応への期待"。
[7] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[7] Shirey、R.、 "インターネットセキュリティ用語集"、FYI 36、RFC 2828、2000年5月を。
[8] Establishing a Computer Security Incident Response Capability (CSIRC). NIST Special Publication 800-3, November, 1991
[8]コンピュータセキュリティインシデント対応能力（CSIRC）を確立します。 NIST Special Publication 800-3、11月、1991
[9] Handbook for Computer Security Incident Response Teams (CSIRTs), Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski. - CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon University, 1998.
[9]コンピュータセキュリティインシデント対応チーム（のCSIRT）、モイラJ.西ブラウン、ドンStikvoort、クラウス・ペーター・Kossakowskiのためのハンドブック。 - CMU / SEI-98-HB-001。 - ピッツバーグ、PA：カーネギーメロン大学、1998。
[10] A Common Language for Computer Security Incidents by John D. Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, Sandia National Laboratories - http://www.cert.org/research/taxonomy_988667.pdf
[10]ジョン・D.ハワード、トーマスA. Longstaffにより、コンピュータセキュリティインシデントのための共通言語。 - サンディア国立研究所のレポート：SAND98-8667、サンディア国立研究所 - http://www.cert.org/research/taxonomy_988667.pdf
[11] Best Current Practice of incident classification and reporting schemes currently used by active CSIRTs. - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/BCPreport1.rtf
[11]現在アクティブのCSIRTで使用入射分類と報告スキームの最も良い現在の習慣。 - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/BCPreport1.rtf
[12] Taxonomy of the Computer Security Incident related terminology - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i-taxonomy_terms.html
コンピュータセキュリティインシデントに関連する用語の[12]分類 - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i-taxonomy_terms.html
[13] Multilingual Support in Internet/IT Applications. - http://www.terena.nl/projects/multiling/
[13]インターネットでの多言語サポート/ ITアプリケーション。 - http://www.terena.nl/projects/multiling/
Acknowledgements:
謝辞：
This document was discussed at the Incident Taxonomy and Description Working Group seminars (http://www.terena.nl/task-forces/tf-csirt/tf-csirt000929prg.html#itdwg) in the frame of TERENA Task Force TF-CSIRT (http://www.terena.nl/task-forces/tf-csirt/). Incident Taxonomy and Description Working Group at TERENA can be contacted via the mailing lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>, archives are available correspondently at http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and http://hypermail.terena.nl/iodef-list/mail-archive/
この文書は、TERENAタスクフォースTF-CSIRTのフレームにインシデント分類と説明ワーキンググループセミナー（http://www.terena.nl/task-forces/tf-csirt/tf-csirt000929prg.html#itdwg）で議論されました（http://www.terena.nl/task-forces/tf-csirt/）。 TERENAで事件分類と説明ワーキンググループはメーリングリスト<incident-taxonomy@terena.nl>または<iodef@terena.nl>を介して接触させることができ、アーカイブはhttp://hypermail.terena.nl/incident-でcorrespondentlyご利用いただけます分類リスト/メールアーカイブ/及びhttp://hypermail.terena.nl/iodef-list/mail-archive/
Authors' Addresses
著者のアドレス
Jimmy Arvidsson Telia CERT
ジミーArvidssonテリアCERT
EMail: Jimmy.J.Arvidsson@telia.se
メールアドレス：Jimmy.J.Arvidsson@telia.se
Andrew Cormack JANET-CERT
アンドリュー・コーマックJANET-CERT
EMail: Andrew.Cormack@ukerna.ac.uk
メールアドレス：Andrew.Cormack@ukerna.ac.uk
Yuri Demchenko TERENA
ゆり でｍちぇんこ てれな
EMail: demch@terena.nl
メールアドレス：demch@terena.nl
Jan Meijer SURFnet
ジャン・メエヘルSURFNET
EMail: jan.meijer@surfnet.nl
メールアドレス：jan.meijer@surfnet.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。