RFC3067 日本語訳
3067 TERENA'S Incident Object Description and Exchange FormatRequirements. J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. February 2001. (Format: TXT=36836 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.アルビドソンの要求をネットワークでつないでください: 3067年の冬胞子堆本命カテゴリ: 情報のA.のジャネット-本命Y.Demchenko TERENA J.Meijer SURFnetコーマック2001年2月
TERENA's Incident Object Description and Exchange Format Requirements
TERENAの付随しているオブジェクト記述と交換形式要件
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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.
Incident Object記述とExchange Formatの目的は記述、格納、および情報交換のためにCSIRTs(コンピュータセキュリティ事件対応チーム)の間のインシデントに関して一般的なデータの形式を定義する(注意深くて、調査で付随していて、格納している統計、報告などを含んでいて)ことです。 このドキュメントはそれらの要件の理由を含むそのような記述と交換形式のためのハイレベルの要件について説明します。 例は、必要であるところで要件を例証するのに使用されます。
1. Conventions used in this document
1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、推薦される、」、「5月」、このドキュメントで「任意」はRFC2119[1]で説明されるように解釈されることであるべきです。
Arvidsson, et al. Informational [Page 1] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [1ページ]情報のRFC3067IODEF要件2001年2月
2. Introduction
2. 序論
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.
このドキュメントはIncidentオブジェクト記述とExchange Format(IODEF)のための要件を定義します。(Exchange FormatはTERENA[2]のIncident Taxonomy作業部会(ITDWG)の意図している製品です)。 IODEFはCSIRTsが操作上と統計情報を交換できる標準書式になるように計画されています。 また、それはコンパチブル、そして、共同利用できるツールの開発の基礎をIncident録音、追跡、および交換に提供するかもしれません。
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.
別の目的はNetwork Securityの、より高い平らな要素としてIETF IDWG(現在、Intrusion Detection交換形式と通信プロトコルに焦点を合わせる)の仕事をインシデントの記述に広げることです。 これはCSIRTsと彼らの選挙民関連する問題にかかわるでしょう。
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/
このドキュメントが1番目であるドキュメントのIODEFセットはIODEF Data ModelとXML DTD仕様を含むでしょう。 または、このドキュメントのさらなる議論が lists <incident-taxonomy@terena.nl に郵送するITDWGで行われる、gt;、lt;、iodef@terena.nl>、アーカイブは http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ と http://hypermail.terena.nl/iodef-list/mail-archive/ で対応であって利用可能です。
2.1. Rationale
2.1. 原理
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.
この仕事はヨーロッパの主であるか高度なCSIRTsの間と、そして、FIRST共同体で協力と情報交換を確立する試みに基づいています。 これらのCSIRTsは処理への情報交換と協力と、追跡とセキュリティインシデントを調査する利点を理解しています。
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.
コンピュータIncidentsは分配されてインターナショナルになっていて、境界、言語、および文化の向こう側に多くのCSIRTsにかかわります。 ポスト将来のIncident防止とインターネットセキュリティ改良に、付随している情報と統計交換は重要です。 これらのすべての場合における情報交換のための主要な要素はIncident(オブジェクト)記述のための一般的な形式です。
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が法廷の目的に使用されるかもしれなくて、これが、Incident記述が明白であり、今後の保護(格納/ドキュメンテーション)機能を考慮しなければならないことを意味するのは、ありえそうです。
Arvidsson, et al. Informational [Page 2] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [2ページ]情報のRFC3067IODEF要件2001年2月
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(侵入Detection Systems)と提案されたIDEF(侵入Detection Exchange Format)によって提供されるよりさらに高い平らなIncident記述と交換形式を持つ必要性です。 IDEFとの互換性と他の関連する規格はモジュール方式と伸展性に関するIODEF要件によって満たされるでしょう。 IODEFは垂直にIDMEFと互換性があるべきである、IODEFがIncidentの初期の情報として含むことができるか、参照IDMEF Alertメッセージであるかもしれません。
2.2. Incident Description Terms
2.2. 付随している記述用語
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]によって作られたコンピュータSecurity Incident関連用語の分類学は[12]に提示されます。
2.2.1. Attack
2.2.1. 攻撃
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.
攻撃は、インサイダーか部外者か攻撃仲介を通して活発であるか、または受け身である場合があります。
2.2.2. Attacker
2.2.2. 攻撃者
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によって説明されて、機構は、どのネットワーク/コンピュータ攻撃が溯源されたか、そして、物理的な位置情報(任意の)です。
2.2.3. CSIRT
2.2.3. CSIRT
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(コンピュータSecurity Incident Response Team)は、権威を示すのにIncidentを扱って、Incident Object記述を作成しながら、IODEFで使用されます。 また、CSIRTも証拠収集と保護、付随している療法などにかかわりそうです。
In IODEF CSIRT represented by its ID, constituency, public key, etc.
ID、選挙民、公開鍵などによって表されたIODEF CSIRTで
Arvidsson, et al. Informational [Page 3] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [3ページ]情報のRFC3067IODEF要件2001年2月
2.2.4. Damage
2.2.4. 損害
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.
狙っているシステムの、または、サービスの通常操作に影響する攻撃の意図しているか故意でない結果。 損害の記述は攻撃の実際の結果の無料のテキスト記述、および可能であるところの特定の破損しているシステム、サブシステムまたはサービスに関する構造化された情報を含むかもしれません。
2.2.5. Event
2.2.5. イベント
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つの失敗したログインが獣の力のログイン攻撃を示すかもしれません。
2.2.6. Evidence
2.2.6. 証拠
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.
証拠はイベントに関する結論を立証するか、またはサポートするイベントに関連する情報です。 セキュリティインシデント(イベント)に関して、それは、包含するかもしれませんが、以下のことのために制限されません。 Intrusion Detection System(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.
Evidence CollectionのためのGuidelinesとArchiving(証拠)によると、厳密に証拠を保証しなければなりません。 証拠保護のチェーンは、明確に記録される必要があります。
It is essential that evidence should be collected, archived and preserved according to local legislation.
ローカルの法律によると、証拠が集められて、格納されて、保存されるのは、不可欠です。
2.2.7. Incident
2.2.7. インシデント
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.
Incidentは安全の侵害にかかわるセキュリティイベントです。 攻撃方法が他の攻撃と区別できる攻撃、攻撃者、犠牲者、サイト、目的またはタイミングのアイデンティティなどのただ一つの攻撃かグループとインシデントを定義できます。
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の文脈では、Incidentという用語は、コンピュータSecurity IncidentかIT Security Incidentを意味するのに使用されます。
Arvidsson, et al. Informational [Page 4] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [4ページ]情報のRFC3067IODEF要件2001年2月
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:
しかしながら、私たちは以下で定義されるそれほど重大でない損害か損害につながるかもしれないイベントである'インシデント'、'セキュリティIncident'、および'IT Security Incident'のジェネリック定義を見分けるべきです:
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.
機構か機構でセキュリティに影響するので、セキュリティインシデントはインシデントより悪いです。 セキュリティインシデントは、論理的であって、物理的であって、organisational、例えば、コンピュータ侵入であるかもしれません(適切に働いていない秘密保持、情報窃盗、炎またはアラームの損失)。 セキュリティインシデントはわざとか偶然に引き起こされるかもしれません。 後者はだれかが、ドアをロックするのを忘れるか、またはルータでアクセスリストを動かすのを忘れるということであるかもしれません。
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) [9]に従って、ITセキュリティインシデントはコンピュータかコンピュータネットワークのセキュリティと関連してどんな本当の、または、疑われた有害事象とも定義されます。 IT領域の中の典型的なセキュリティインシデントは以下の通りです。 コンピュータ侵入やサービス不能攻撃や情報窃盗やデータ操作など
2.2.8. Impact
2.2.8. 影響
Impact describes result of attack expressed in terms of user community, for example the cost in terms of financial or other disruption
影響はユーザーコミュニティに関して言い表された攻撃の結果について説明します、例えば、財政的であるか他の分裂による費用
2.2.9. Target
2.2.9. 目標
A computer or network logical entity (account, process or data) or physical entity (component, computer, network or internetwork).
コンピュータ的、または、ネットワーク論理的な実体(アカウント、プロセスまたはデータ)か物理的実体(コンポーネント、コンピュータ、ネットワークまたはインターネットワーク)。
2.2.10. Victim
2.2.10. 犠牲者
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、機構、および位置情報によって説明されます。
2.2.11. Vulnerability
2.2.11. 脆弱性
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.
システムの安全保障政策に違反するのに利用できたシステムのデザインか、実装か、操作と管理における欠点か弱点。
Arvidsson, et al. Informational [Page 5] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [5ページ]情報のRFC3067IODEF要件2001年2月
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.
ほとんどのシステムには、ある種の脆弱性がありますが、これは、システムが使用するのにあまり失敗していることを意味しません。 あらゆる脅威が攻撃をもたらすというわけではありません、そして、あらゆる攻撃が成功するというわけではありません。 成功は脆弱性の度合い、攻撃の強さ、および使用中のどんな対策の有効性にも依存します。 脆弱性を利用するのに必要である攻撃は行うのが非常に難しいなら、脆弱性が許容できるかもしれません。 攻撃者への知覚された利益がわずかであるなら、容易に利用された脆弱性さえ許容できるかもしれません。 しかしながら、攻撃をよく理解して、容易にして、さまざまなユーザが害を被りやすいシステムを使うと、攻撃するだれかのための利益が十分ありそうでしょう。
2.2.12. Other terms
2.2.12. 他の用語
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、Security Policyなど - 関連するI-Ds、RFCs、および規格[3、6、7、8、9、10]では、定義されます。
3. General Requirements
3. 一般要件
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のための互換性の別の問題は現在IETF IDEWGによって開発されるIDEFとの一般的な互換性です。 時間と互換性のために、定義されて受け入れられた規格はどこでも、可能であるところで使用されるべきです。
In particularly, IODEF specification proposals SHOULD rely heavily on existing communications, encryption and language standards, where possible.
SHOULDが可能であるところで大いに既存のコミュニケーション、暗号化、および言語規格に依存するという特にIODEF仕様提案で。
4. Description Format
4. 記述形式
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.
コメント: いくつかのIncidentsが異なった国、文化的で地理的な領域からCSIRTsのかかわり合いを必要とするので、現地語と地方のプレゼンテーション形式を固く守る際にオペレータにそれらを提示できるようにIODEF記述をフォーマットしなければなりません。
Arvidsson, et al. Informational [Page 6] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [6ページ]情報のRFC3067IODEF要件2001年2月
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(または、ISO8859-1)以外のキャラクタを必要とするテキスト文字列と名前を含んでいて、望ましくは、情報が表されるべきである場合では、ISO/IECを使用するのは、UTF-8変換形式を使用して、任意にローカルキャラクターセットとencodings[13]を使用することで10646-1 文字集合であってコード化されています。
4.2. The IODEF must support modularity in Incident description to
allow aggregation and filtering of data.
4.2. IODEFは、データの集合とフィルタリングを許容するためにIncident記述におけるモジュール方式をサポートしなければなりません。
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.
コメント: 例えば、IDSからIODEFとのIncident記述が外部の情報を含むかもしれないことが提案されるか、参照が外部的に証拠保護データを保存したか、またはそのような情報は現在のIODEF記述から取り除かれるかもしれません、例えば、プライバシーかセキュリティの目的で。 この要件に関する別の実用的な/現実動機は何人かのCSIRTs/マネージャが彼らの統計の目的、CSIRTsの間の報告と高い平らなIncident情報交換、そして/または、選挙民とスポンサーのために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 Incident記述は、潜在的に、敏感であるか個人的な情報(パスワード、人々/機構識別子または法廷の情報(証拠データ)などの)を含んでいて、いくつかの場合、非認可された人々に暴露されるかもしれません。 そのような状況は特にCSIRTsか他のかかわったボディーの間のIncident情報交換の場合に起こるかもしれません。 いくつかのケースが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オブジェクトの一部がアクセス制限属性で示されなければなりません。 自動化された処理システムと共に使用されると、これらの印は特に役に立ちます。
Arvidsson, et al. Informational [Page 7] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [7ページ]情報のRFC3067IODEF要件2001年2月
5. Communications Mechanisms Requirements
5. コミュニケーションメカニズム要件
5.1. IODEF exchange will normally be initiated by humans using
standard communication protocols, for example, e-mail, WWW/HTTP,
LDAP.
5.1. LDAP、通常、IODEF交換は、人間によって標準の通信プロトコル、メール、例えばWWW/HTTPを使用することで起こされるでしょう。
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は自動化されたIncident取り扱いシステムによって処理されるために狙いますが、まだ読み込み可能で、標準のツール(MS ExcelやAccessのような例えば、ブラウザ、電子テーブルプロセッサまたはデータベースツール)で見られて、ブラウズされるのにおいて有能な人間であるに違いありません。 通常、付随している情報交換がオペレータによる認可を必要とするだろうか、またはしたがって、CSIRTマネージャによって自動的に開始されないと予想されます。 Incident取り扱いシステムの役割は支援とツールを交換を実行するのに提供することです。
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 Intrusionの目的を区別するために、IODEF Incident記述を適応して、作成したのは、重要です。
Communications security requirements will be applied separately according to local policy so are not defined by this document.
したがって、ローカルの方針によると、別々に適用されていて、要件がそうする通信秘密保全はこのドキュメントによって定義されません。
6. Message Contents
6. メッセージ内容
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.
コメント: ユニークな識別番号(または、識別子)が、別のものと1Incidentを区別するのに必要です。 ユニークな識別番号がすなわち、IOクリエイター、少なくともCSIRTの情報を含むか、またはボディーを関係づけたと示唆されます。 また、Incidentの分類は、ユニークな識別番号を形成するのに使用されるかもしれません。 IO目的は実際にどの要素がIODEFに含まれていて、オブジェクトPurposesが付随している警戒/登録を含むかもしれません、取り扱い、格納しているということであるか、そして、報告か統計を制御するでしょう。 Incident調査の目的、付随しているタイプまたは状態がIncident情報のための異なったレベルの参照許可を必要とするかもしれません。
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>になると考えられて、追加情報は根の要素の属性として扱われるでしょう。
Arvidsson, et al. Informational [Page 8] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [8ページ]情報のRFC3067IODEF要件2001年2月
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. CERT/CCからのそれらなどの関連どんな状況報告(CVE)にも参照をつけることができるようにIODEF記述を構造化しなければなりません。
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.
コメント: 知られているAttacksとVulnerabilitiesの標準のAdvisoriesとリストを使用すると、Incident取り扱い/防止の彼らの推薦の使用は許されるでしょう。 そのような情報は属性として攻撃か脆弱性型定義に含められるかもしれません。
6.4. IODEF may include a detailed description of the attack that
caused the current Incident.
6.4. IODEFは現在のIncidentを引き起こした攻撃の詳述を含むかもしれません。
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.
コメント: 攻撃の記述は攻撃者と犠牲者の情報、攻撃と可能な影響の外観を含んでいます。 Intrusionの初期段階に、そこの警戒とIncident取り扱いは最小量の情報である傾向があります、これがIncident調査と療法に十分になるように育てるIncidentの取り扱いの間。 要素<ATTACK>はIncident記述の主な要素の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].
コメント: 多くの目的のために、Incident記述はIncidentを引き起こした特定のイベント/活動に関する多くの詳細を必要としません。 この情報は外部の情報(URLによる)として参照をつけられるかもしれません。 いくつかの場合、別々に異なったアクセス許容を持っている証拠を保存するのは便利であるかもしれません。 別の規格が証拠保護[5]のために提案されるのが見通されます。
Arvidsson, et al. Informational [Page 9] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [9ページ]情報のRFC3067IODEF要件2001年2月
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かインターネット・アドレスである、拡張情報はCSIRTsが彼らの特定の選挙民に適宜の処置を取ることができる彼らの機構を特定するでしょう。
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記述は異なったタイプのデバイスアドレス(例えば(バージョン4か6)とインターネットが命名するIPアドレス)の表現をサポートしなければなりません。
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.
コメント: 攻撃が進水するサイトはネットワークプロトコル階層(例えば、Data層2のMACアドレスかNetwork層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はIncident Object(CSIRTか他の権威)のクリエイターのIdentityを含まなければなりません。 これは、情報交換における送付者か現在インシデントを扱うチームであるかもしれません。
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.
コメント: Incident記述クリエイターのアイデンティティはIncident応答のためのしばしば貴重な情報です。 攻撃がネットワークを通して進行するかもしれない1つの可能なシナリオに、異なった当局によって報告された対応するインシデントの比較は攻撃の発生源に関する何らかの追加情報を提供するかもしれません。 また、これはポストインシデント情報取り扱い/交換段階の役に立つ情報です。
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
コメント: 目標システムの上のイベントの可能な影響に関する情報は、攻撃者がするのを試みていることのしるしを供給して、CSIRTsが行動を取って、働く重要なデータです。
Arvidsson, et al. Informational [Page 10] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [10ページ]情報のRFC3067IODEF要件2001年2月
damage assessment. If no reference information (Advisories) is available, this field may be filled in based on CSIRT team experience.
査定を破損してください。 どんな参考情報(状況報告)も利用可能でないなら、この分野は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.
ほとんどのCSIRTsがIncident取り扱いサポート・システムを開発すると予想されます、通常、特定された攻撃のための可能な影響のリストを含む既存のAdvisories(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.
コメント: この情報を含んでいるのはIncident作成の段階で不可欠です、知的な自動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記述はこのインシデントの間に前のCSIRTsによって取られた行動の情報を提供しなければなりません。
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はAlertから閉鎖と格納までの生涯の間中出来事を描写します。 すべての関係者によって取られたすべての行動を追跡するのは不可欠です。 これは、どんなさらなる動作が、もしあれば取られる必要であるかを決定するのを助けるでしょう。 これは調査のプロセスのCSIRTsの間のIncident情報交換の場合に特に重要です。
6.12. The IODEF must support reporting of the time of all stages
along Incident life-time.
6.12. IODEFはIncident生涯に沿ってすべてのステージの現代の報告をサポートしなければなりません。
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.
コメント: 時間は報告と相関関係観点の両方から重要です。 時間は多くのサイトから始められるか、またはネットワークの上に分配されるなら同じIncidentか攻撃を特定できる主なコンポーネントの1つです。 また、時間も、調査のプロセスのCSIRTsの間のIncident交換を含むIncidentの寿命は追跡できるように不可欠です。
Arvidsson, et al. Informational [Page 11] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [11ページ]情報のRFC3067IODEF要件2001年2月
6.13. Time shall be reported as the local time and time zone offset
from UTC. (Note: See RFC 1902 for guidelines on reporting time.)
6.13. 時間は現地時間と時間帯のオフセットとしてUTCから報告されるものとします。 (注意: 報告時のガイドラインに関してRFC1902を見てください。)
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. 日付を報告するための形式はY2Kロールオーバーのすべての現在の規格で対応するに違いありません、そして、それには、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が生涯の間中Incidentについて説明するだろうと述べられています。 この持続時間は格納の場合が無制限であるかもしれません。 したがって、時間的価値(「unix時間」の間の2038年の日付の表現制限などの)の式を制限する実装を避けなければなりません。
6.15. Time granularity in IO time parameters shall not be specified
by the IODEF.
6.15. IODEFはIO時間パラメタにおける時間粒状を指定しないものとします。
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
コメント: IODEF Incident記述は潜在的にすごく攻撃者か悪人におもしろい敏感であるか個人的な情報(法廷のデータ(証拠データ)、パスワード、または人々/機構識別子などの)を含んでいます。 通常、付随している情報はネットワーク・コンピュータで保存されるでしょう。(それは、潜在的に攻撃(または、妥協する)に暴露されるかもしれません)。 付随している情報は非制御のネットワークセグメントの向こう側に伝えられるかもしれません。 したがって、内容が権限のないアクセスと変更から保護されるのは、重要です。 その上、プライバシーのための法的環境
Arvidsson, et al. Informational [Page 12] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [12ページ]情報のRFC3067IODEF要件2001年2月
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.
そして、暗号技術は、領域と国から変えられて、しばしば変化して、選択されたデザインが多くの異なった暗号化オプションをサポートできて、ユーザがさまざまな環境に融通がきくのは、重要です。 追加措置はコミュニケーションの間、Incidentを固定するために引き受けられるかもしれませんが、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.
追加措置はコミュニケーションの間、Incidentを固定するために引き受けられるかもしれませんが、この問題は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の信憑性と非拒否と特にそれらのコミュニケーションの場合の重要性のために、これらの要件の実装は強くそうです。RECOMMENDED。
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記述はimplementersによって使用されるかもしれない拡張機能をサポートしなければなりません。 これは将来の実装特有の、または、実験しているデータを許容します。 implementerはどんな含まれている拡大も解釈する方法を示さなければなりません。
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.
コメント: Implementersは内部の目的のために情報としてそのようであるかそれらのIncident取り扱いシステムの特定の実装に必要な付加的なデータを提供したがっているかもしれません。 これらのデータは、取り除くかもしれないか、または外部コミュニケーションで不可欠であるのではなく、異系統で間違った解釈を防ぐために追加するとしてそれらをマークするのにそれで不可欠です。
Arvidsson, et al. Informational [Page 13] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [13ページ]情報のRFC3067IODEF要件2001年2月
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はIncident記述のための人間の指向の形式です、そして、人間はIODEF記述が読むことができるべきです。 自動構文解析ツールの使用は、見通されますが、批判的に必要であるべきではありません。 したがって、IODEFは良い意味論を提供しなければなりません。(それは、記述が何を含むかを理解しているのに主要になるでしょう)。 いくつかの場合、IODEF記述が自動意思決定に使用されるので、記述が正しく解釈されるのは、重要です。 これは、言語ベースの意味論を使用するための議論です。 IODEF識別子とラベルのためのメタ言語はイギリスであるために提案されて、必要なら、地方のIODEF実装はメタ言語識別子とラベルを現地語とプレゼンテーションに翻訳できるかもしれません。
7. IODEF extensibility
7. 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自身は広げることができるに違いありません。 新情報を含んでいるのは新技術の使用と自動化されたIncident取り扱いシステムの開発が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.
コメント: また、新しいIncident取り扱いがツールであるとサポートするためにIODEFを広げる必要性に加えて、IODEFがIDSのためのIDEFなどの関連する規格化領域か証拠保護のための特別な形式の開発から新しい開発を取り入れることが提案されます。 拡大のための手順はCSIRT/IODEF共同体承認/承認に基づくべきです。
8. Security Considerations
8. セキュリティ問題
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.
このメモはIncident Object記述とExchange Formatに要件について説明します(注意深くて、調査で付随していて、格納している統計、報告などを含んでいて)。(Exchange Formatは記述、格納、および情報交換のためにCSIRTsの間のインシデントに関して一般的なデータの形式を定義するつもりです)。 その点で、IODEFの実装はセキュリティ問題への対象です。 セクション4.3で制限指示にアクセスするという特定のセキュリティ要件について議論して、要件はセクション6.16、6.17、6.18でIncident記述秘密性、保全、信憑性、および非拒否に説明されます。
Arvidsson, et al. Informational [Page 14] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [14ページ]情報のRFC3067IODEF要件2001年2月
9. References
9. 参照
[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月。
[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] 木のそばの侵入検出交換形式要件(2000年M.--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] 証拠収集とドミニクでBrezinskiを格納するためのガイドライン(2000年トムKillalea--7月)は進行中で働いています。
[6] Brownlee, N. and E. Guttman, "Expectations for Computer Security
Incident Response", BCP 21, RFC 2350, June 1998.
[6] ブラウンリー、N.とE.Guttman、「コンピュータセキュリティインシデント応答への期待」BCP21、1998年6月のRFC2350。
[7] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
2000.
[7] Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
[8] Establishing a Computer Security Incident Response Capability
(CSIRC). NIST Special Publication 800-3, November, 1991
[8] コンピュータセキュリティインシデント応答能力(CSIRC)を確立すること。 NISTの特別な公表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)のためのハンドブック、モイラ・J.西洋-ブラウンはStikvoort、クラウス-ピーターKossakowskiを身につけます。 - セイ98米カーネギーメロン大学/HB001。 - ピッツバーグ(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.ロングスタッフによるコンピュータセキュリティインシデントのための共通語。 - Sandiaは報告します: 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] 体系が現在アクティブなCSIRTsで使用した付随している分類と報告の最も良いCurrent Practice。 - http://www.terena.nl/task-forces/tf-csirt/i- 分類学/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
コンピュータSecurity Incident関連用語の[12]分類学-- http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i- 分類学_terms.html
[13] Multilingual Support in Internet/IT Applications. -
http://www.terena.nl/projects/multiling/
[13] インターネット/ITアプリケーションにおける多言語サポート。 - http://www.terena.nl/projects/multiling/
Arvidsson, et al. Informational [Page 15] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [15ページ]情報のRFC3067IODEF要件2001年2月
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 Task Force TF-CSIRT( http://www.terena.nl/task-forces/tf-csirt/ )のフレームのIncident Taxonomyと記述作業部会セミナー( http://www.terena.nl/task-forces/tf- csirt/tf-csirt000929prg.html#itdwg)でこのドキュメントについて議論しました。 または、郵送 lists <incident-taxonomy@terena.nl を通してTERENAの付随しているTaxonomyと記述作業部会に連絡できる、gt;、lt;、iodef@terena.nl>、アーカイブは http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ と http://hypermail.terena.nl/iodef-list/mail-archive/ で対応であって利用可能です。
Authors' Addresses
作者のアドレス
Jimmy Arvidsson Telia CERT
ジミーアルビドソン冬胞子堆本命
EMail: Jimmy.J.Arvidsson@telia.se
メール: Jimmy.J.Arvidsson@telia.se
Andrew Cormack JANET-CERT
アンドリューコーマックジャネット-CERT
EMail: Andrew.Cormack@ukerna.ac.uk
メール: Andrew.Cormack@ukerna.ac.uk
Yuri Demchenko TERENA
ユリDemchenko TERENA
EMail: demch@terena.nl
メール: demch@terena.nl
Jan Meijer SURFnet
ジャンMeijer SURFnet
EMail: jan.meijer@surfnet.nl
メール: jan.meijer@surfnet.nl
Arvidsson, et al. Informational [Page 16] RFC 3067 IODEF Requirements February 2001
アルビドソン、他 [16ページ]情報のRFC3067IODEF要件2001年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Arvidsson, et al. Informational [Page 17]
アルビドソン、他 情報[17ページ]
一覧
スポンサーリンク
