ネットワークワーキンググループ
Request for Comments: 3067
分類: 情報提供

J. Arvidsson
Telia CERT
A. Cormack
JANET-CERT
Y. Demchenko
TERENA
J. Meijer
SURFnet
2001年 2月

English

TERENA の IODEF(インシデントオブジェクト記述法と交換フォーマット)要件
(TERENA's Incident Object Description and Exchange Format Requirements)

このメモの位置付け

このメモは、インターネットコミュニティのために情報を提供します。これは、いかなる種類のインターネット標準をも仕様化するものではありません。このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (2001). All Rights Reserved.

要旨

IODEF(インシデントオブジェクト記述法と交換フォーマット)要件の目的は、CSIRT (Computer Security Incident Response Teams) 間でインシデントについて情報の記述/アーカイビング/交換を行うことのための共通データフォーマットを規定することにあります。(調査中のインシデント、アーカイビング、統計情報、報告、等を含みます。)本書は、このような記述や交換フォーマットのための上位層の要件を記述し、このような要件の理由を含みます。必要に応じて要件を表現するために例が使用されます。

 

1. 本書中で使用される用語法 English

本書中の "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"、というキーワードは、RFC 2119 [1] に記述されているように解釈されるべきものです。

 

2. はじめに English

本書は、TERENA における ITDWG ( Incident Taxonomy and Description Working Group ) [2] の成果として意図された、IODEF( Incident object Description and Exchange Format )のための要件を規定します。IODEF は、CSIRT が運用的/統計的情報を交換することができる標準フォーマットとされることが計画されていました。; これは、互換性/相互運用可能性のあるインシデントを記録/追跡/交換するためのツールの開発のための基礎も提供します。

他のねらいは、(現在、侵入検知交換フォーマットとコミュニケーションプロトコルに焦点を当てられている) IETF IDWG の作業を、ネットワークセキュリティにおける上位層の要素としてのインシデントの記述に拡張することにあります。これは、CSIRT とそのサービス対象関連論点を含みます。

本書が最初となる一連の IODEF 文書は、IODEF データモデルと XML DTD 仕様を含む予定です。本書の以降の検討は、ITDWG メーリングリスト <incident-taxonomy@terena.nl> もしくは <iodef@terena.nl> において行われる予定であり、アーカイブは、http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/http://hypermail.terena.nl/iodef-list/mail-archive/ で対応して入手可能です。

2.1. 基礎 English

この作業は、ヨーロッパにおける主導的/先進的 CSIRT 間と、FIRST コミュニティ内における協力と情報交換を確立する試みに基づきます。これらの CSIRT は、セキュリティインシデントを処理/追跡/調査することにおける情報交換と協力の長所を理解しています。

コンピュータインシデントは、分散的、国際的になりつつあり、境界・言語・文化を越えて多くの CSIRT を巻き込みます。インシデント情報や統計情報の交換は、将来のインシデント予防やインターネットセキュリティ向上のために重要です。これらすべてのケースにおいて、情報交換のための鍵となる要素は、インシデント(オブジェクト)記述のための共通フォーマットです。

以降の開発/実装において、IODEF は、法的目的に使用される可能性があり、これは、インシデント記述は、明確であり、将来のカストディ(アーカイブ化/文書化)機能を許容できなければならないことを意味します。

IODEF を開発することによって標的とされた他の論点は、IDS (Intrusion Detection Systems) によって提供されるものや、提案されている IDEF (Intrusion Detection Exchange Format) より、上位層のインシデント記述と交換フォーマットを持つことの必要性についてです。IDEF や他の関連標準との互換性は、モジュール性と拡張可能性についてのIODEF 要件によって充足されます。IODEF は逆に、IDMEF と互換性をもつ必要があり、IODEF は、IDMEF アラートメッセージをインシデントについての初期情報として含めること、または参照することができる可能性があります。

2.2. インシデント規定用語 English

本書の以降で使用される主な用語の定義は、明確化のために与えられます。

可能である限り、既存の定義が使用されます。; 定義には追加的な詳細や考慮が必要なものがあります。

TERENA の ITDWG によって作成された「コンピュータセキュリティ関連用語法の分類学(Taxonomy of the Computer Security Incident related terminology)」 [2] は、[12] において提供されています。

2.2.1. 攻撃(Attack) English

知的脅威によってもたらされるシステムセキュリティ上の攻撃、すなわち、(特に手法、もしくはテクニックの観点から)セキュリティサービスを迂回したり、システムのセキュリティポリシーを侵害する計画的な試みである知的行為。

攻撃は、能動的/受動的、内部者による/外部者による、または仲介者経由の攻撃である可能性があります。

2.2.2. 攻撃者(Attacker) English

攻撃者は、目的を達成するために、ひとつの/複数の攻撃を試みる個人です。

IODEF の目的では、攻撃者は、そのネットワーク ID、ネットワーク/コンピュータ攻撃の起点であった組織体、物理的位置情報(オプショナル)によって記述されます。

2.2.3. CSIRT English

CSIRT (Computer Security Incident Response Team) は、IODEF において、インシデントに対処し、Incident Object Description を作成する機関を言及するのに使用されます。CSIRT はまた、証拠収集やカストディ、インシデント救済策、等に巻き込まれる可能性が高いといえます。

IODEF において、CSIRT は、その ID、サービス対象構成員、公開鍵、等によって表現されます。

2.2.4. ダメージ( Damage ) English

標的とされたシステムもしくはサービスの通常の運用に影響を与える故意/過失による攻撃 の結果です。ダメージの記述は、実際の攻撃の結果の自由形式テキスト記述を含む可能性があり、可能である限り、特定のダメージを受けたシステム/サブシステム/サービスについての構造化された情報を含む可能性があります。

2.2.5. イベント( Event ) English

標的の状態(ステータス)の変更をもたらすことを意図された、標的において検知された活動です。イベントが起きた組織体の観点からは、アラートが生成されるようになった、システムもしくはネットワーク中における、いかなる観察可能な事象として定義されます。例えば、10 秒間以内に 3 回のログイン失敗は、ブルートフォースログイン攻撃を示している可能性があります。

2.2.6. 証拠( Evidence ) English

証拠は、イベントについての結論を提供する、またはサポートするイベントに関する情報です。セキュリティインシデント(イベント)に関しては、以下のものを含みますが、これに限られません。: IDS(侵入検知システム)によって作成されたデータダンプ、syslog ファイルからのデータ、カーネル統計情報、キャッシュ、メモリ、テンポラリファイルシステム、またはアラートをもたらした/インシデントが発生した後に集められた、データ。

証拠を蓄積しアーカイブ化する際、特にそのインテグリティを確保するためには、特別なルールと注意が適用されなければなりません。必要不可欠な場合、証拠は暗号化されて蓄積される必要があります。

Guidelines for Evidence Collection and Archiving (Evidence) によれば、証拠は、厳密にセキュアにされなければなりません。証拠カストディの連鎖は、明確に文書化される必要があります。

証拠が、現地の規制に基づいて収集され、アーカイブされ、確保される必要があることが、肝要です。

2.2.7. インシデント( Incident ) English

インシデントは、セキュリティ侵害に関わるセキュリティイベントです。インシデントは、攻撃の手法、攻撃者、被害者、サイトの識別、目的、日時等によって、他の攻撃から区別することができる、単独の攻撃、もしくは攻撃のグループとして定義することができます。

インシデントは、IODEF の幹( root )となる要素です。IODEF の文脈においては、インシデントという用語は、コンピュータセキュリティインシデント、もしくは IT セキュリティインシデントを意味するのに使用されます。

しかし、さほど深刻でないダメージに導いたり、もしくはダメージを与えるイベントである一般的な「インシデント」の定義と、下記に定義される「セキュリティインシデント」や「IT セキュリティインシデント」を区別する必要があります。:

a) セキュリティインシデントは、セキュリティ侵害に関するイベントです。これは、セキュリティポリシー、UAP、法や司法管轄、等を侵害するイベントである可能性があります。セキュリティインシデントはまた、セキュリティインシデントにエスカレートされたインシデントである可能性があります。

セキュリティインシデントは、組織体の/中のセキュリティに影響を与えるのでインシデントより悪いといえます。セキュリティインシデントは、論理的/物理的/組織的である可能性があります。例えば、コンピュータ侵入、秘密の消失、情報窃盗、火災、正しく動作しないアラームです。セキュリティインシデントは、故意または過失によって引き起こされます。後者は、誰かがドアをロックすることを忘れた場合、もしくは、ルータ中のアクセスリストを有効にし忘れた場合、起きる可能性があります。
 

b) IT セキュリティインシデントは、[9] によれば、コンピュータ、もしくはコンピュータネットワークのセキュリティに関連する、いかなる現実の、または逆に疑惑のイベントとして定義されます。IT 分野における典型的なセキュリティインシデントには、以下のものがあります。:コンピュータ侵入、DoS(サービス妨害)攻撃、情報窃盗もしくはデータの不正操作等。

2.2.8. インパクト( Impact ) English

インパクトは、ユーザコミュニティの文脈で表現される攻撃の結果を記述します。例えば、金銭的文脈におけるコスト、または他の破壊です。

2.2.9. 標的( Target ) English

コンピュータ、もしくはネットワークの、論理的主体 (アカウント、プロセス、データ)、または物理的主体(コンポーネント、コンピュータ、ネットワーク、インターネット)です。

2.2.10. 被害者( Victim ) English

被害者は、インシデント報告中に記述された攻撃をわずらった個人または組織体です。

IODEF の目的のためには、被害者は、そのネットワーク ID、組織体、位置情報によって記述されます。

2.2.11. 脆弱性( Vulnerability ) English

システムのセキュリティポリシーを侵害するのに攻略される可能性があるシステムの設計、実装、または、運用や管理における欠陥もしくは弱点。

大部分のシステムは、何らかの脆弱性をもちますが、これは、そのシステムは、使用に耐えないほど欠陥があることを意味するものではありません。すべての脅威が攻撃に帰結するわけではなく、すべての攻撃が成功するわけではありません。成功は、脆弱性の程度、攻撃の強度、あらゆる使用されている対策の有効性に依存します。ある脆弱性を攻略するのに必要な攻撃が、実行困難である場合、その脆弱性は、耐えることができるでしょう。予想される攻撃者にとっての便益が小さい場合、簡単に攻略される脆弱性でも、耐えることができるでしょう。しかし、よく理解されており簡単に行えて、かつ、脆弱なシステムが広範なユーザによって採用されている場合、誰かが攻撃を行うのに十分な便益がある可能性が高いといえます。

2.2.12. 他の用語 English

他の用語も使用されます。: アラート、活動(activity)、IDS、セキュリティポリシー等は、関連インターネットドラフト、RFC や標準において定義されています。 [3, 6, 7, 8, 9, 10]

 

3. 一般的要件 English

3.1. IODEF は、可能な限り既発行 RFC を参照し利用しなければなりません。 English

コメント:
IETF は既に、ネットワークとセキュリティの分野において、現在のインターネットで実際に採用されている数多くの標準を開発してきました。現行の標準は、IODEF を実際に運用/実装するのに必要不可欠な、IODEF の他の関連技術との互換性のためのフレームワークを提供しています。IODEF のための互換性の他の論点は、現在 IETF IDEWG によって開発されている IDEF との一般的な互換性です。時間と互換性の観点からは、規定され、受容された標準は、可能である限り使用される必要があります。

特に、IODEF 仕様提案は、可能である限り、既存のコミュニケーション/暗号化/言語の標準に大きく依拠する必要があります(SHOULD)

 

4. 記述フォーマット English

4.1. IODEF は完全な国際化とローカライズすることをサポートしなければなりません。 English

コメント:
インシデントには、異なる国々、文化的地理的地域の CSIRT の関与を要するものがあるので、IODEF 記述は、オペレータにローカル言語で表現され、ローカル表現フォーマットに固執できるようにフォーマット化されなければなりません

IODEF 識別子とラベルのためのメタ言語は、英語であると考えられますが、ローカル IODEF 実装は、必要な場合、メタ言語識別子やラベルをローカル言語や表現に翻訳することできる可能性があります。

日付、時刻、名前のローカライズされた表現もまた要求されます。メッセージが Latin-1(または ISO 8859-1)以外のキャラクタが必要があるテキストストリングや名前をもつ場合、情報は、ISO/IEC IS 10646-1 キャラクタセットを使用して表現され UTF-8 変換フォーマットを使用してエンコードされることが選好され、オプションとして、ローカルキャラクタセットとエンコーディングされる必要があります [13] 。

4.2. IODEF はインシデント記述において、データの集積やフィルタリングを許容するために、モジュール性をサポートしなければなりません。 English

コメント:
IODEF におけるインシデント記述は、外部情報(例、IDS から)を含んだり、 外部的に蓄積された証拠カストディデータを参照することが示唆され、もしくは、そのような情報は、現行の IODEF 記述から削除される可能性があります(例、プライバシー、もしくはセキュリティの目的から)。この要件についての他の実践的/現実的な動機は、CSIRT/管理者たちに、統計情報の目的のために、IODEF descriptions についてフィルタリング、かつ/または、集積機能を行うこと、CSIRT 間、かつ/または、そのサービス対象やスポンサーとの間で、報告や上位層のインシデント情報交換の可能性を与えることにあります。

それゆえ、IODEF 記述は、これらの運用を容易にするように構成されなければなりません(MUST)。これはまた、強い IODEF 文法を意味します。

4.3. IODEF は、すべての要素に反映されるアクセス制限ポリシーのアプリケーションをサポートしなければなりません。 English

コメント:
IODEF インシデント記述は、潜在的に(パスワード、個人/法人識別子、もしくは法的情報(証拠データ)のような)取り扱い注意、もしくはプライベート情報を含み、場合によっては、認可されていない人にさらされる可能性があります。このような状況は特に、CSIRT 間、もしくは他の参画主体間でのインシデント情報交換の場合に起きます。場合によっては、IODEF 要素を暗号化することによって対応されることがありますが、これは常に可能であるとは限りません。

それゆえ、取り扱い注意情報の偶発的開示を防ぐために、IODEF オブジェクトのパートは、アクセス制限属性で、マークがつけられなければなりません。このようなマーキングは、自動化された処理システムによって使用される場合に特に有用です。

 

5. コミュニケーション機構要件 English

5.1. IODEF 交換は通常、人間によって標準コミュニケーションプロトコルを使用して、開始されます。(例: e-mail、WWW/HTTP、LDAP) English

コメント:
IODEF 記述は通常、人間によって、特別な/標準のテキストエディタを使用して作成されます。IODEF は、自動化されたインシデント対処システムによって処理されることを標的としていますが、人間が読むことができ、標準ツールで閲覧し見ることができなければなりません。(例 : ブラウザ、MS Excel もしくは Access のような表計算プロセッサー、もしくはデータベースツール 。)インシデント情報交換は通常、オペレーターもしくは CSIRT 管理者による認可を要求するので、自動的に開始されることは期待されていません。インシデント対処システムの役割は、交換を行うための支援やツールを提供することにあります。

マシンが読むことができ、交換可能な IDEF 侵入メッセージフォーマット と、人間によるものであり、作成される IODEF インシデント記述の目的を区別することが重要です。

コミュニケーションセキュリティ要件は、ローカルポリシーに従って別個に適用されるので、本書によって規定されません。

 

6. メッセージ内容 English

6.1. IO 記述の幹( root )となる要素は、固有な識別番号(もしくは識別子)、IO 目的、デフォルトパーミッションレベルを含む必要があります。 English

コメント:
固有な識別番号(もしくは識別子)は、ひとつのインシデントを他から区別するために必要不可欠です。固有な識別番号が少なくとも IO 作成者、すなわち CSIRT もしくは関連主体についての情報を含むことが示唆されます。インシデントの分類はまた、固有の識別番号を形成するのに使用される可能性があります。IO 目的は、実際には、IODEF オブジェクト Purposes に含まれる要素をコントロールし、インシデントアラート/登録、対処、アーカイビング、報告もしくは統計情報を含みます。目的、インシデントタイプ、もしくはインシデント調査のステータスは、インシデント情報について異なるレベルのアクセス権限を要求する可能性があります。

IODEF の幹( root )となる要素は、<INCIDENT> であり、追加的情報は、幹( root )となる要素の属性として扱われることが考慮されます。

6.2. IODEF 記述の内容は、既知の場合、攻撃の種類を含む必要があります。 English

この種類は、標準化されたイベントのリストから引用されることが期待されます。; 新種のイベントは、そのイベントがまだ標準化されていない場合、暫定的実装固有の種類を使用する可能性があります。

コメント:
インシデント対処は、多くのスタッフメンバーやチームを巻き込む可能性があります。それゆえ、インシデントを記述するのに共通用語を使用することが肝要です。

イベント種類がまだ標準化されていない場合、暫定的な種別の定義が IO を作成したチームによって与えられる可能性があります。新しい種別は、自己説明的であり、同様の既存の種別定義から導かれることが期待されます。

6.3. IODEF 記述は、CERT/CC、CVE からのもののような、あらゆる関連アドバイザリを参照できるように構成されなければなりません。 English

コメント:
標準アドバイザリや、既知の攻撃や脆弱性のリストを使用することは、そのインシデント対処/予防についての推奨事項の利用を許容します。このような情報は、攻撃の性質、もしくは脆弱性種類規定として含まれる可能性があります。

6.4. IODEF は、現在のインシデントを引き起こした攻撃の詳細な記述を含む可能性があります。 English

コメント:
攻撃の記述は、攻撃者と被害者/攻撃の様子/可能性のある影響についての情報を含みます。侵入アラートとインシデント対処の初期段階において、最低限の情報である可能性が高く、インシデントの対処の過程で、これはインシデント調査や救済のために十分であるように成長します。要素 <ATTACK> は、インシデント記述の主要な要素のひとつである必要があります。

6.5. IODEF 記述は、しばしば証拠として参照される、この特定の基礎となっているイベント/活動( activity )に関する追加的詳細データを含むか、あるいは、参照することができなければなりません。 English

コメント:
多くの目的のために、インシデント記述は、インシデントを引き起こした特定のイベント/アクティビティについての多くの詳細は必要はありません。; この情報は、外部情報として (URL によって)参照される可能性があります。場合によっては、異なるアクセス権限をもつ証拠を別個に蓄積することが便利であることがあります。証拠カストディについては、他の標準が提案されることが予想されます [5]。

6.6. IODEF 記述は、攻撃者と被害者の記述を含まなければなりません。(MUST) English

コメント:
この情報は、攻撃の起点と標的を識別するのに必要不可欠です。攻撃者と被害者についての最低限の情報は、彼らの IP、もしくはインターネットアドレスであり、拡張された情報は、彼らの組織体を識別し、CSIRT がその特定のサービス対象のために適切な手段を講じることができるようにします。

6.7. IODEF 記述は、デバイスアドレスの様々な種類の表現をサポートしなければなりません。(例: IP アドレス (バージョン 4 または 6) やインターネット名。) English

コメント:
攻撃が放たれたサイトは、ネットワークプロトコル階層の様々なレベルのアドレスを持ちます。(例: データリンク(第 2 層)MAC アドレス、もしくはネットワーク層(第 3 層)IP アドレス。)さらに、侵害イベントにまきこまれたデバイスは、IP 中心的でないアドレスを使用する可能性がります。(例: ATM アドレス。)また、攻撃の起点と標的についての情報は、IDS から入手され、IP アドレス、MAC アドレス、もしくは両者を含むと理解されています。

6.8. IODEF は、インシデントオブジェクトの作成者(CSIRT もしくは他の機関)の識別情報を含まなければなりません。これは、情報交換における送信者、もしくは、現在インシデントに対処しているチームである可能性があります。 English

コメント:
インシデント記述作成者の識別情報は、しばしば、インシデント対応のために価値ある情報です。可能性あるシナリオとして、攻撃がネットワークを経由して進展する可能性があり、異なる主体によって報告された同時期のインシデントの比較は、攻撃の起源についての何らかの追加的情報を提供する可能性があります。これはまた、インシデント後情報の対処/交換段階において有用な情報です。

6.9. IODEF 記述は、標的について、このイベントの可能性のある影響の表示を含まなければなりません。このフィールドの値は、攻撃が既知であると認識された場合、もしくは責任を負う CSIRT チーム番号によって自由形式で表現されている場合、値の標準化されたリストから引用される必要があります。 English

コメント:
標的システムについての可能性のある影響に関する情報は、攻撃者は何を試みているか、何が  CSIRT にとって活動するのに決定的に重要かの表示を提供し、ダメージアセスメントを実施します。参考情報(アドバイザリ)が入手不能な場合、このフィールドは、CSIRT チームの経験に基づいて埋められます。

大部分の CSIRT が、( CERT/CC、CVE、等からのもののような)識別された攻撃についての可能性ある影響のリストを通常含む既存のアドバイザリに基づいてインシデント対処サポートシステムを開発することが期待されます。

これはまた、攻撃や脆弱性の標準化されたデータベースから情報を取得すろことができるインテリジェントな IDS に実装される IDEF の開発と関連します [3] 。

6.10. IODEF は、レポート情報中に確信の程度を表明することができます。 English

コメント:
この情報を含むことは、特に、インテリジェントな自動的 IDS もしくはエキスパートシステムが使用されている場合、インシデント生成の段階において肝要です。通常、これらは、イベントの可能性を見積もるために統計的エンジンを使用します。

6.11. IODEF 記述は、当該インシデントのコースにおいて、前の CSIRT によって行われた活動についての情報を提供しなければなりません。 English

コメント:
IODEF は、アラートから完了とアーカイビングまで、そのライフタイムに渡ってインシデントを記述します。関与するすべての主体によってなされた行動を追跡することが肝要です。これは、さらにとるべき行動があるときに、とるべき行動を判断するのに役立ちます。これは、CSIRT 間のインシデント情報交換が調査処理中である場合、特に重要です。

6.12. IODEF は、インシデントライフタイムにおけるすべての段階の日時の報告をサポートしなければなりません。 English

コメント:
日時は、報告と相関性の両方の視点から重要です。日時は、インシデントまたは攻撃が多くのサイトから放たれた場合、またはネットワーク上に分散されている場合、同一のインシデントまたは攻撃を識別することができる主要コンポーネントのひとつです。日時はまた、インシデントの生涯を追跡できるようにするのに肝要で、CSIRT 間で調査中のインシデント交換を含みます。

6.13. 日時は、現地時間と UTC からのタイムゾーンオフセットとして報告されなければなりません。(注意:報告日時についてのガイドラインについては RFC 1902 参照。) English

コメント:
イベント収集目的のためには、管理者が IODEF 記述中に報告された日時情報を統一することができることが重要です。

6.14. 日時を報告することのためのフォーマットは、2000 年より前のすべての現行標準と互換性がなければならず、2038 年以降の日時データ値を報告することを継続させる十分な能力を持たなければなりません。 English

コメント:
IODEF の目的から、IODEF は、インシデントをそのライフタイムを通じて記述しなければならないと表明されています。アーカイブする場合、この期間は、制限されないかもしれません。それゆえ(「 Unix 日時」における 2038年表現限界のような)日時の表現を制限する実装は、避けなければなりません(MUST)

6.15. IO 日時パラメータ中の日時の詳細さは、IODEF によって仕様化されてはなりません。 English

コメント:
日時データは、既存の情報システムによって、インシデント報告メッセージから取得されたり、または、IDS データもしくは他のイベント登録ツールから採られて、IODEF 記述中に含められる可能性があります。これらの各事例は、それぞれの異なる日時の詳細さをもつ可能性があります。実装の目的のためには、ローカルシステムの能力に従って日時を異なる段階で扱うことが可能である必要があります。

6.16. IODEF は記述内容の秘匿性をサポートする必要があります。 English

選択された設計は、様々な暗号化アルゴリズムをサポートすることができる必要があり、様々な環境において採用できなければなりません。

コメント:
IODEF インシデント記述は潜在的に、(法的データ(証拠データ)、パスワード、もしくは個人/組織体の識別子のような)取り扱い注意、もしくはプライベート情報を含み、これは攻撃者/悪人にとって大変興味深いものとなります。インシデント情報は通常、ネットワーク化されたコンピュータ上に蓄積され、これらは潜在的に攻撃にさらされる(または侵される)可能性があります。インシデント情報は、コントロールされていないネットワークセグメントを通過して転送される可能性があります。それゆえ、内容が認可されていないアクセスや改変から保護されていることが重要です。さらに、プライバシーと暗号化技術についての法的環境は、地域や国によって様々で、しばしば変化するので、選択された設計が、たくさんの様々な暗号化オプションをサポートすることとができることと、ユーザによって様々な環境に採用できることが重要です。コミュニケーションにおいて、追加的手法がインシデントをセキュアにするために行われますが、この論点は、これは一般的な IO アーカイビングや蓄積についての、より厳密なルールを意味するので IODEF の範疇外です。

6.17. IODEF は、記述内容のインテグリティ確保する必要があります。 English

選択された設計は、様々なインテグリティ気候をサポートすることができる必要があり、様々な環境に適用できなければなりません。

コメント:
悪意ある IO 変更を防ぐために、特別な手段が講じられる必要があります。

追加的手段が、コミュニケーションにおいてインシデントをセキュアにするために行われるでしょうが、この論点は、IODEF の範囲外です。

6.18. IODEF は、メッセージ内容の真正性( authenticity )と非否認性( non-repudiation )を確保する必要があります。 English

コメント:
真正性( authenticity )と説明責任( accountability )は、多くのチームにとって必要とされ、特に、自動的に IO を扱う要求がある場合に必要とされます。それゆえ、これは IODEF 中に含まれなければなりません(MUST)。多くのチームや、特にそれらの間のコミュニケーションの場合の IO 真正性( authenticity)と非否認性( non-repudiation )の重要性によって、これらの要件の実装は、強く推奨されます(RECOMMENDED)

6.19. IODEF 記述は、実装者によって利用される拡張機構をサポートしなければなりません。これは、将来の実装固有/経験的データを許容します。実装者は、含められた各拡張をどのように解釈するかを表示しなければなりません(MUST)English

コメント:
実装者は、内部目的ための情報、または、彼らのインシデント対処システムの特定の実装のために必要不可欠な情報のような追加データを提供することを望む可能性があります。これらのデータは、外部コミュニケーションにおいて削除されたりされなかったりしますが、異なるシステムによる誤った解釈を防ぐために、それらを追加としてマークをつけることが肝要です。

6.20. IODEF 記述の文法は、よく定義されなければなりません。 English

コメント:
IODEF は、人間によるインシデント記述のためのフォーマットで、IODEF 記述は、人間によって読むことができる必要があります。自動的解読ツールの利用が予定されていますが、必ずしも必要不可欠であるわけではありません。それゆえ、IODEF は、良い文法を提供しなければなりません。これは、記述が何を含んでいるかを理解するための鍵となります。場合によっては、IODEF 記述は、自動的意思決定のために使用されます。それゆえ、記述が正しく翻訳されることが重要です。これは、言語ベース文法を使用するための言及です。IODEF 識別子やラベルのためのメタ言語は、英語であることが提案され、ローカル IODEF 実装は、必要に応じてメタ言語識別子やラベルをローカル言語や表現に翻訳することができます。

 

7. IODEF 拡張可能性 English

7.1. IODEF 自体は、拡張可能でなければなりません(MUST)。新技術の使用や、自動化されたインシデント対処システムの開発が IODEF の拡張を要求する際に、IODEF が、新しい情報を含むことができることが肝要です。 English

コメント:
新しいインシデント対処ツールをサポートするために IODEF を拡張する要求に加えて、IODEF が、IDS のための IDEF のような関連する標準化分野からの新しい開発、または証拠カストディのための特別なフォーマットの開発を結合することも示唆されます。拡張のための手続きは、CSIRT/IODEF コミュニティの受容/承認に基づくものである必要があります。

 

8. セキュリティについての考慮事項 English

このメモは、CSIRT 間でインシデントについての記述、情報のアーカイブ化と交換のための共通データフォーマットを規定することを意図した IODEF の要件を記述します。(アラート、調査中のインシデント、アーカイブ化、統計情報、報告、等が含まれます。)この観点において、IODEF の実装は、セキュリティに関する考慮事項の論点です。制限表示へのアクセスのための特定のセキュリティ要件は、4.3 節において検討されています。インシデント記述の守秘性(confidentiality)/インテグリティ(integrity)/真正性(authenticity)/非否認性(non-repudiation)の要件は、6.166.176.18 の節に記述されています。

 

9. 参考文献

[1] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.
 
[2] Incident Taxonomy and Description Working Group Charter -
http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/
 
[3] Intrusion Detection Exchange Format Requirements by Wood, M. -  2000年12月, 作業中.
 
[4] Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition by D. Curry, H. Debar -  2001年 2月, 作業中.
 
[5] Guidelines for Evidence Collection and Archiving by Dominique Brezinski, Tom Killalea - 2000年 7月, 作業中.
 
[6] Brownlee, N. and E. Guttman,
「コンピュータセキュリティインシデント対応への期待(Expectations for Computer Security Incident Response)」,
BCP 21, RFC 2350, 1998年 6月.
 
[7] Shirey, R.,
「インターネットセキュリティ小辞典 (Internet Security Glossary)」,
FYI 36, RFC 2828, 2000年 5月.
 
[8] Establishing a Computer Security Incident Response Capability (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年.
 
[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
 
[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
 
[12] Taxonomy of the Computer Security Incident related terminology -
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/

 

謝辞: English

本書は、TERENA タスクフォース TF-CSIRT( http://www.terena.nl/task-forces/tf-csirt/ )のフレームワークにおいて、Incident Taxonomy and Description Working Group セミナー( http://www.terena.nl/task-forces/tf-csirt/tf-csirt000929prg.html#itdwg )において検討されました。TERENA における Incident Taxonomy and Description Working Group は、メーリングリスト <incident-taxonomy@terena.nl> または <iodef@terena.nl> 経由でコンタクトすることができ、アーカイブは対応して http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/http://hypermail.terena.nl/iodef-list/mail-archive/ で入手可能です。

 

著者のアドレス

Jimmy Arvidsson
Telia CERT

EMail: Jimmy.J.Arvidsson@telia.se

Andrew Cormack
JANET-CERT

EMail: Andrew.Cormack@ukerna.ac.uk

Yuri Demchenko
TERENA

EMail: demch@terena.nl

Jan Meijer
SURFnet

EMail: jan.meijer@surfnet.nl

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

EMail: miyakawa@ipa.go.jp

 

著作権表記全文

Copyright (C) The Internet Society (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.

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.

謝辞

RFC 編集者のための資金は現在、Internet Society によって提供されています。