[要約] 要約：RFC 3067は、TERENA（Trans-European Research and Education Networking Association）のインシデントオブジェクトの記述と交換形式の要件に関するものです。 目的：このRFCの目的は、インシデント情報の共有と交換を効率化し、ネットワークセキュリティの向上を促進するための標準化を提供することです。
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のインシデントオブジェクト説明と交換形式の要件
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.
Copyright（c）The Internet Society（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].
キーワード「必須」、「そうしない」、「必須」、「「shall」、「shall」、「suff」、 "low" of "、becomedended"、 ""、 "optional"は、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 [2]のインシデント分類ワーキンググループ（ITDWG）の意図された製品であるインシデントオブジェクト説明と交換形式（IODEF）の要件を定義します。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.
もう1つの目的は、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仕様が含まれます。このドキュメントのさらなる議論は、ITDWGメーリングリスト<Incise-Yongy@terena.nl>または<iodef@terena.nl>で行われ、アーカイブはhttp://hypermail.terena.nl/incident-caxonomy-で入手できます。List/Mail-Archive/and 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.
IODEFでは、ID、選挙区、公開鍵などで表されます。
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.
ターゲットの状態（ステータス）の変化をもたらすことを目的としたターゲットに向けられたアクション。イベントのオリジネーションの観点からは、システムまたはネットワークで観察可能な発生が発生し、アラートが生成されるようになると定義できます。たとえば、10秒で3つの失敗したログインは、ブルートフォースログイン攻撃を示している可能性があります。
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エリア内の典型的なセキュリティインシデントは次のとおりです。コンピューターの侵入、サービス拒否攻撃、情報の盗難またはデータ操作など。
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].
使用されるその他の用語：アラート、アクティビティ、ID、セキュリティポリシーなど - 関連する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は、可能であれば、以前に公開されていたRFCSを参照および使用するものとします。
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の互換性のもう1つの問題は、IETF IDEWGによって現在開発されているIDEFとの一般的な互換性です。時間と互換性のために、可能な限り定義され、受け入れられた標準を使用する必要があります。
In particularly, IODEF specification proposals SHOULD rely heavily on existing communications, encryption and language standards, where possible.
特に、IODEFの仕様提案は、可能であれば、既存の通信、暗号化、言語基準に大きく依存する必要があります。
4.1. IODEF shall support full internationalization and localization.
4.1. 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識別子とラベルのMetalanguageは英語と見なされますが、ローカルIODEFの実装は、必要に応じてMetalananguageの識別子とラベルをローカル言語とプレゼンテーションに翻訳することができる場合があります。
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説明から削除される可能性があります。この要件のもう1つの実用的/実生活の動機は、一部のCSIRTS/マネージャーが、CSIRTおよび/またはその構成関係の間の統計、報告、および高レベルのインシデント情報交換を目的として、IODEFの説明でフィルタリングおよび/またはデータ集約関数を実行する可能性を与えることです。スポンサー。
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のルート要素は<インシデント>になり、追加情報はルート要素の属性として扱われると考えられています。
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.
イベントタイプがまだ標準化されていない場合、Teamが作成した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>は、インシデント説明の主な要素の1つである必要があります。
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アドレス）。さらに、侵入イベントに関与するデバイスは、IP中心ではないアドレス、たとえばATMアドレスを使用する場合があります。また、攻撃のソースとターゲットに関する情報が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].
これは、インテリジェントIDに実装される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.
コメント：この情報を含めることは、インシデント作成の段階では、特にインテリジェントな自動IDまたはエキスパートシステムが使用される場合に不可欠です。これらは通常、統計エンジンを使用してイベント確率を推定します。
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.
コメント：レポートと相関の両方の観点からの時間は重要です。時間は、多くのサイトから起動したり、ネットワーク上に配布されたりした場合、同じインシデントまたは攻撃を識別できる主要なコンポーネントの1つです。調査の過程でのCSIRT間のインシデント交換など、インシデントの生活を追跡できるためには時間も不可欠です。
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 time」の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.
コメント：特にiOSを自動的に処理したいという欲求を考えると、多くのチームが信頼性と説明責任を必要とするため、IODEFに含める必要があります。多くのチームに対する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.
コメント：実装者は、内部目的のための情報などの追加データを提供したり、インシデント処理システムの特定の実装に必要な追加データを提供したい場合があります。これらのデータは、外部通信で削除されるか、そうでない場合がありますが、異なるシステムによる間違った解釈を防ぐために追加としてそれらをマークすることが不可欠です。
6.20. The semantics of the IODEF description must be well defined.
6.20. IODEF説明のセマンティクスは、明確に定義する必要があります。
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識別子とラベルのMetalanangageは英語であると提案されており、ローカルIODEFの実装は、必要に応じて、Metalananguage IdentifiersとLabelsをローカル言語とプレゼンテーションに翻訳できる可能性があります。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] 侵入検知交換形式のWood、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] 侵入検知メッセージ交換形式拡張可能なマークアップ言語（XML）ドキュメントタイプ定義D.カリー、H。デバル - 2001年2月、進行中の作業。
[5] Guidelines for Evidence Collection and Archiving by Dominique Brezinski, Tom Killalea - July 2000, Work in Progress.
[5] Tom KillaleaのDominique Brezinskiによる証拠収集とアーカイブのガイドライン - 2000年7月、進行中の作業。
[6] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998.
[6] Brownlee、N。およびE. Guttman、「コンピューターセキュリティインシデント対応への期待」、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、1991年11月
[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] コンピューターセキュリティインシデント対応チーム（CSIRTS）のハンドブック、Moira J. West-Brown、Don Stikvoort、Klaus-Peter Kossakowski。-CMU/SEI-98-HB-001。 - ペンシルバニア州ピッツバーグ：カーネギーメロン大学、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・ロングスタッフによるコンピューターセキュリティインシデントの共通言語。-Sandia Report：Sand98-8667、Sandia National Laboratories -http：//www.cert.org/research/taxonomy_9888667.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] 現在アクティブなCSIRTSが使用しているインシデント分類と報告スキームの最良の実践。-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/
Authors' Addresses
著者のアドレス
Jimmy Arvidsson Telia CERT
ジミー・アーヴィッドソン・テリア証明書
EMail: Jimmy.J.Arvidsson@telia.se
Andrew Cormack JANET-CERT
アンドリュー・コーマック・ジャネット・ザート
EMail: Andrew.Cormack@ukerna.ac.uk
Yuri Demchenko TERENA
Yuri Demchenko Terena
EMail: demch@terena.nl
Jan Meijer SURFnet
Jan Meijer Surfnet
EMail: jan.meijer@surfnet.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。