|
ネットワークワーキンググループ Request for Comments： 3067 分類： 情報提供 |
J. Arvidsson Telia CERT A. Cormack JANET-CERT Y. Demchenko TERENA J. Meijer SURFnet 2001年2月 |
このメモは、 インターネットコミュニティのために情報を提供します。 これは、 いかなる種類のインターネット標準をも仕様化するものではありません。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2001). All Rights Reserved.
IODEF(インシデントオブジェクト記述法と交換フォーマット)要件の目的は、 CSIRT (Computer Security Incident Response Teams)間でインシデントについて情報の記述／アーカイビング／交換を行うことのための共通データフォーマットを規定することにあります。 (調査中のインシデント、アーカイビング、統計情報、報告、 等を含みます。) 本書は、 このような記述や交換フォーマットのための上位層の要件を記述し、 このような要件の理由を含みます。 必要に応じて要件を表現するために例が使用されます。
本書中の"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"、 というキーワードは、 RFC 2119 [1] に記述されているように解釈されるべきものです。
本書は、 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/ で対応して入手可能です。
この作業は、 ヨーロッパにおける主導的／先進的CSIRT間と、 FIRSTコミュニティ内における協力と情報交換を確立する試みに基づきます。 これらのCSIRTは、 セキュリティインシデントを処理／追跡／調査することにおける情報交換と協力の長所を理解しています。
コンピュータインシデントは、分散的、国際的になりつつあり、 境界・言語・文化を越えて多くのCSIRTを巻き込みます。 インシデント情報や統計情報の交換は、 将来のインシデント予防やインターネットセキュリティ向上のために重要です。 これらすべてのケースにおいて、情報交換のための鍵となる要素は、 インシデント(オブジェクト)記述のための共通フォーマットです。
以降の開発／実装において、IODEFは、 法的目的に使用される可能性があり、これは、 インシデント記述は、明確であり、 将来のカストディ(アーカイブ化／文書化)機能を許容できなければならないことを意味します。
IODEFを開発することによって標的とされた他の論点は、 IDS (Intrusion Detection Systems)によって提供されるものや、 提案されているIDEF (Intrusion Detection Exchange Format)より、 上位層のインシデント記述と交換フォーマットを持つことの必要性についてです。 IDEFや他の関連標準との互換性は、 モジュール性と拡張可能性についてのIODEF要件によって充足されます。 IODEFは逆に、IDMEFと互換性をもつ必要があり、 IODEFは、 IDMEFアラートメッセージをインシデントについての初期情報として含めること、 または参照することができる可能性があります。
本書の以降で使用される主な用語の定義は、 明確化のために与えられます。
可能である限り、既存の定義が使用されます。； 定義には追加的な詳細や考慮が必要なものがあります。
TERENAのITDWGによって作成された「コンピュータセキュリティ関連用語法の分類学(Taxonomy of the Computer Security Incident related terminology)」 [2] は、 [12] において提供されています。
知的脅威によってもたらされるシステムセキュリティ上の攻撃、 すなわち、(特に手法、 もしくはテクニックの観点から)セキュリティサービスを迂回したり、 システムのセキュリティポリシーを侵害する計画的な試みである知的行為。
攻撃は、能動的／受動的、内部者による／外部者による、 または仲介者経由の攻撃である可能性があります。
攻撃者は、目的を達成するために、 ひとつの／複数の攻撃を試みる個人です。
IODEFの目的では、攻撃者は、そのネットワークID、 ネットワーク／コンピュータ攻撃の起点であった組織体、 物理的位置情報(オプショナル)によって記述されます。
CSIRT (Computer Security Incident Response Team)は、 IODEFにおいて、インシデントに対処し、 Incident Object Descriptionを作成する機関を言及するのに使用されます。 CSIRTはまた、証拠収集やカストディ、インシデント救済策、 等に巻き込まれる可能性が高いといえます。
IODEFにおいて、CSIRTは、そのID、サービス対象構成員、 公開鍵、等によって表現されます。
標的とされたシステムもしくはサービスの通常の運用に影響を与える故意／過失による攻撃の結果です。 ダメージの記述は、 実際の攻撃の結果の自由形式テキスト記述を含む可能性があり、 可能である限り、 特定のダメージを受けたシステム／サブシステム／サービスについての構造化された情報を含む可能性があります。
標的の状態(ステータス)の変更をもたらすことを意図された、 標的において検知された活動です。 イベントが起きた組織体の観点からは、 アラートが生成されるようになった、 システムもしくはネットワーク中における、 いかなる観察可能な事象として定義されます。 例えば、10秒間以内に3回のログイン失敗は、 ブルートフォースログイン攻撃を示している可能性があります。
証拠は、イベントについての結論を提供する、 またはサポートするイベントに関する情報です。 セキュリティインシデント(イベント)に関しては、 以下のものを含みますが、これに限られません。： IDS(侵入検知システム)によって作成されたデータダンプ、 syslogファイルからのデータ、カーネル統計情報、キャッシュ、 メモリ、テンポラリファイルシステム、 またはアラートをもたらした／インシデントが発生した後に集められた、 データ。
証拠を蓄積しアーカイブ化する際、 特にそのインテグリティを確保するためには、 特別なルールと注意が適用されなければなりません。 必要不可欠な場合、証拠は暗号化されて蓄積される必要があります。
Guidelines for Evidence Collection and Archiving (Evidence)によれば、証拠は、 厳密にセキュアにされなければなりません。 証拠カストディの連鎖は、明確に文書化される必要があります。
証拠が、現地の規制に基づいて収集され、アーカイブされ、 確保される必要があることが、肝要です。
インシデントは、 セキュリティ侵害に関わるセキュリティイベントです。 インシデントは、攻撃の手法、攻撃者、被害者、サイトの識別、 目的、日時等によって、他の攻撃から区別することができる、 単独の攻撃、 もしくは攻撃のグループとして定義することができます。
インシデントは、IODEFの幹(root)となる要素です。 IODEFの文脈においては、インシデントという用語は、 コンピュータセキュリティインシデント、 もしくはITセキュリティインシデントを意味するのに使用されます。
しかし、さほど深刻でないダメージに導いたり、 もしくはダメージを与えるイベントである一般的な「インシデント」の定義と、 下記に定義される「セキュリティインシデント」や「ITセキュリティインシデント」を区別する必要があります。：
セキュリティインシデントは、 セキュリティ侵害に関するイベントです。 これは、セキュリティポリシー、UAP、法や司法管轄、 等を侵害するイベントである可能性があります。 セキュリティインシデントはまた、 セキュリティインシデントにエスカレートされたインシデントである可能性があります。
セキュリティインシデントは、 組織体の／中のセキュリティに影響を与えるのでインシデントより悪いといえます。 セキュリティインシデントは、 論理的／物理的／組織的である可能性があります。 例えば、コンピュータ侵入、秘密の消失、情報窃盗、火災、 正しく動作しないアラームです。 セキュリティインシデントは、 故意または過失によって引き起こされます。 後者は、誰かがドアをロックすることを忘れた場合、もしくは、 ルータ中のアクセスリストを有効にし忘れた場合、起きる可能性があります。
ITセキュリティインシデントは、[9] によれば、コンピュータ、 もしくはコンピュータネットワークのセキュリティに関連する、 いかなる現実の、 または逆に疑惑のイベントとして定義されます。 IT分野における典型的なセキュリティインシデントには、 以下のものがあります。 ：コンピュータ侵入、DoS(サービス妨害)攻撃、 情報窃盗もしくはデータの不正操作等。
インパクトは、 ユーザコミュニティの文脈で表現される攻撃の結果を記述します。 例えば、金銭的文脈におけるコスト、または他の破壊です。
コンピュータ、もしくはネットワークの、 論理的主体(アカウント、プロセス、データ)、 または物理的主体(コンポーネント、コンピュータ、 ネットワーク、インターネット)です。
被害者は、 インシデント報告中に記述された攻撃をわずらった個人または組織体です。
IODEFの目的のためには、被害者は、そのネットワーク ID、 組織体、位置情報によって記述されます。
システムのセキュリティポリシーを侵害するのに攻略される可能性があるシステムの設計、 実装、または、運用や管理における欠陥もしくは弱点。
大部分のシステムは、何らかの脆弱性をもちますが、これは、 そのシステムは、 使用に耐えないほど欠陥があることを意味するものではありません。 すべての脅威が攻撃に帰結するわけではなく、 すべての攻撃が成功するわけではありません。 成功は、脆弱性の程度、攻撃の強度、 あらゆる使用されている対策の有効性に依存します。 ある脆弱性を攻略するのに必要な攻撃が、実行困難である場合、 その脆弱性は、耐えることができるでしょう。 予想される攻撃者にとっての便益が小さい場合、 簡単に攻略される脆弱性でも、耐えることができるでしょう。 しかし、よく理解されており簡単に行えて、かつ、 脆弱なシステムが広範なユーザによって採用されている場合、 誰かが攻撃を行うのに十分な便益がある可能性が高いといえます。
他の用語も使用されます。 ： アラート、活動(activity)、IDS、セキュリティポリシー等は、 関連インターネットドラフト、 RFCや標準において定義されています。 [3, 6, 7, 8, 9, 10]
IETFは既に、ネットワークとセキュリティの分野において、 現在のインターネットで実際に採用されている数多くの標準を開発してきました。 現行の標準は、 IODEFを実際に運用／実装するのに必要不可欠な、 IODEFの他の関連技術との互換性のためのフレームワークを提供しています。 IODEFのための互換性の他の論点は、 現在IETF IDEWGによって開発されているIDEFとの一般的な互換性です。 時間と互換性の観点からは、規定され、受容された標準は、 可能である限り使用される必要があります。
特に、IODEF仕様提案は、可能である限り、 既存のコミュニケーション／暗号化／言語の標準に大きく依拠する必要があります(SHOULD)。
インシデントには、異なる国々、 文化的地理的地域のCSIRTの関与を要するものがあるので、 IODEF記述は、オペレータにローカル言語で表現され、 ローカル表現フォーマットに固執できるようにフォーマット化されなければなりません。
IODEF識別子とラベルのためのメタ言語は、 英語であると考えられますが、 ローカルIODEF実装は、必要な場合、 メタ言語識別子やラベルをローカル言語や表現に翻訳することできる可能性があります。
日付、時刻、 名前のローカライズされた表現もまた要求されます。 メッセージがLatin-1(またはISO 8859-1)以外のキャラクタが必要があるテキストストリングや名前をもつ場合、 情報は、ISO/IEC IS 10646-1キャラクタセットを使用して表現されUTF-8変換フォーマットを使用してエンコードされることが選好され、 オプションとして、 ローカルキャラクタセットとエンコーディングされる必要があります [13] 。
IODEFにおけるインシデント記述は、外部情報(例、 IDSから)を含んだり、 外部的に蓄積された証拠カストディデータを参照することが示唆され、 もしくは、そのような情報は、 現行のIODEF記述から削除される可能性があります(例、 プライバシー、もしくはセキュリティの目的から)。 この要件についての他の実践的／現実的な動機は、 CSIRT／管理者たちに、統計情報の目的のために、 IODEF descriptionsについてフィルタリング、かつ／または、 集積機能を行うこと、CSIRT間、 かつ／または、そのサービス対象やスポンサーとの間で、 報告や上位層のインシデント情報交換の可能性を与えることにあります。
それゆえ、IODEF記述は、 これらの運用を容易にするように構成されなければなりません(MUST)。 これはまた、強い IODEF 文法を意味します。
IODEFインシデント記述は、潜在的に(パスワード、 個人／法人識別子、もしくは法的情報(証拠データ)のような)取り扱い注意、 もしくはプライベート情報を含み、場合によっては、 認可されていない人にさらされる可能性があります。 このような状況は特に、CSIRT間、 もしくは他の参画主体間でのインシデント情報交換の場合に起きます。 場合によっては、 IODEF要素を暗号化することによって対応されることがありますが、 これは常に可能であるとは限りません。
それゆえ、取り扱い注意情報の偶発的開示を防ぐために、 IODEFオブジェクトのパートは、アクセス制限属性で、 マークがつけられなければなりません。 このようなマーキングは、 自動化された処理システムによって使用される場合に特に有用です。
IODEF記述は通常、人間によって、 特別な／標準のテキストエディタを使用して作成されます。 IODEFは、 自動化されたインシデント対処システムによって処理されることを標的としていますが、 人間が読むことができ、 標準ツールで閲覧し見ることができなければなりません。 (例： ブラウザ、MS ExcelもしくはAccessのような表計算プロセッサー、 もしくはデータベースツール。) インシデント情報交換は通常、 オペレーターもしくはCSIRT管理者による認可を要求するので、 自動的に開始されることは期待されていません。 インシデント対処システムの役割は、 交換を行うための支援やツールを提供することにあります。
マシンが読むことができ、 交換可能なIDEF侵入メッセージフォーマットと、 人間によるものであり、 作成されるIODEFインシデント記述の目的を区別することが重要です。
コミュニケーションセキュリティ要件は、 ローカルポリシーに従って別個に適用されるので、 本書によって規定されません。
固有な識別番号(もしくは識別子)は、 ひとつのインシデントを他から区別するために必要不可欠です。 固有な識別番号が少なくともIO作成者、 すなわちCSIRTもしくは関連主体についての情報を含むことが示唆されます。 インシデントの分類はまた、 固有の識別番号を形成するのに使用される可能性があります。 IO目的は、実際には、 IODEFオブジェクトPurposesに含まれる要素をコントロールし、 インシデントアラート／登録、対処、アーカイビング、 報告もしくは統計情報を含みます。 目的、インシデントタイプ、 もしくはインシデント調査のステータスは、 インシデント情報について異なるレベルのアクセス権限を要求する可能性があります。
IODEFの幹(root)となる要素は、 <INCIDENT> であり、追加的情報は、 幹(root)となる要素の属性として扱われることが考慮されます。
この種類は、 標準化されたイベントのリストから引用されることが期待されます。； 新種のイベントは、そのイベントがまだ標準化されていない場合、 暫定的実装固有の種類を使用する可能性があります。
インシデント対処は、 多くのスタッフメンバーやチームを巻き込む可能性があります。 それゆえ、 インシデントを記述するのに共通用語を使用することが肝要です。
イベント種類がまだ標準化されていない場合、 暫定的な種別の定義がIOを作成したチームによって与えられる可能性があります。 新しい種別は、自己説明的であり、 同様の既存の種別定義から導かれることが期待されます。
標準アドバイザリや、 既知の攻撃や脆弱性のリストを使用することは、 そのインシデント対処／予防についての推奨事項の利用を許容します。 このような情報は、攻撃の性質、 もしくは脆弱性種類規定として含まれる可能性があります。
攻撃の記述は、 攻撃者と被害者／攻撃の様子／可能性のある影響についての情報を含みます。 侵入アラートとインシデント対処の初期段階において、 最低限の情報である可能性が高く、 インシデントの対処の過程で、 これはインシデント調査や救済のために十分であるように成長します。 要素<ATTACK>は、 インシデント記述の主要な要素のひとつである必要があります。
多くの目的のために、インシデント記述は、 インシデントを引き起こした特定のイベント／アクティビティについての多くの詳細は必要はありません。 ； この情報は、 外部情報として(URLによって)参照される可能性があります。 場合によっては、 異なるアクセス権限をもつ証拠を別個に蓄積することが便利であることがあります。 証拠カストディについては、 他の標準が提案されることが予想されます[5]。
この情報は、 攻撃の起点と標的を識別するのに必要不可欠です。 攻撃者と被害者についての最低限の情報は、 彼らのIP、もしくはインターネットアドレスであり、 拡張された情報は、彼らの組織体を識別し、 CSIRTがその特定のサービス対象のために適切な手段を講じることができるようにします。
攻撃が放たれたサイトは、 ネットワークプロトコル階層の様々なレベルのアドレスを持ちます。 (例：データリンク(第2層)MACアドレス、 もしくはネットワーク層(第3層)IPアドレス。) さらに、侵害イベントにまきこまれたデバイスは、 IP中心的でないアドレスを使用する可能性がります。 (例：ATMアドレス。) また、攻撃の起点と標的についての情報は、 IDSから入手され、IPアドレス、 MACアドレス、もしくは両者を含むと理解されています。
インシデント記述作成者の識別情報は、しばしば、 インシデント対応のために価値ある情報です。 可能性あるシナリオとして、 攻撃がネットワークを経由して進展する可能性があり、 異なる主体によって報告された同時期のインシデントの比較は、 攻撃の起源についての何らかの追加的情報を提供する可能性があります。 これはまた、 インシデント後情報の対処／交換段階において有用な情報です。
標的システムについての可能性のある影響に関する情報は、 攻撃者は何を試みているか、 何がCSIRTにとって活動するのに決定的に重要かの表示を提供し、 ダメージアセスメントを実施します。 参考情報(アドバイザリ)が入手不能な場合、このフィールドは、 CSIRTチームの経験に基づいて埋められます。
大部分のCSIRTが、(CERT/CC、CVE、 等からのもののような)識別された攻撃についての可能性ある影響のリストを通常含む既存のアドバイザリに基づいてインシデント対処サポートシステムを開発することが期待されます。
これはまた、 攻撃や脆弱性の標準化されたデータベースから情報を取得すろことができるインテリジェントなIDSに実装されるIDEFの開発と関連します [3] 。
この情報を含むことは、特に、 インテリジェントな自動的IDSもしくはエキスパートシステムが使用されている場合、 インシデント生成の段階において肝要です。 通常、これらは、 イベントの可能性を見積もるために統計的エンジンを使用します。
IODEFは、アラートから完了とアーカイビングまで、 そのライフタイムに渡ってインシデントを記述します。 関与するすべての主体によってなされた行動を追跡することが肝要です。 これは、さらにとるべき行動があるときに、 とるべき行動を判断するのに役立ちます。 これは、 CSIRT間のインシデント情報交換が調査処理中である場合、 特に重要です。
日時は、報告と相関性の両方の視点から重要です。 日時は、 インシデントまたは攻撃が多くのサイトから放たれた場合、 またはネットワーク上に分散されている場合、 同一のインシデントまたは攻撃を識別することができる主要コンポーネントのひとつです。 日時はまた、 インシデントの生涯を追跡できるようにするのに肝要で、 CSIRT間で調査中のインシデント交換を含みます。
イベント収集目的のためには、 管理者がIODEF記述中に報告された日時情報を統一することができることが重要です。
IODEFの目的から、IODEFは、 インシデントをそのライフタイムを通じて記述しなければならないと表明されています。 アーカイブする場合、この期間は、制限されないかもしれません。 それゆえ(「Unix日時」における2038年表現限界のような)日時の表現を制限する実装は、 避けなければなりません(MUST)。
日時データは、既存の情報システムによって、 インシデント報告メッセージから取得されたり、または、 IDSデータもしくは他のイベント登録ツールから採られて、 IODEF記述中に含められる可能性があります。 これらの各事例は、 それぞれの異なる日時の詳細さをもつ可能性があります。 実装の目的のためには、 ローカルシステムの能力に従って日時を異なる段階で扱うことが可能である必要があります。
選択された設計は、 様々な暗号化アルゴリズムをサポートすることができる必要があり、 様々な環境において採用できなければなりません。
IODEFインシデント記述は潜在的に、(法的データ(証拠データ)、 パスワード、 もしくは個人／組織体の識別子のような)取り扱い注意、 もしくはプライベート情報を含み、 これは攻撃者／悪人にとって大変興味深いものとなります。 インシデント情報は通常、 ネットワーク化されたコンピュータ上に蓄積され、 これらは潜在的に攻撃にさらされる(または侵される)可能性があります。 インシデント情報は、 コントロールされていないネットワークセグメントを通過して転送される可能性があります。 それゆえ、 内容が認可されていないアクセスや改変から保護されていることが重要です。 さらに、プライバシーと暗号化技術についての法的環境は、 地域や国によって様々で、しばしば変化するので、 選択された設計が、 たくさんの様々な暗号化オプションをサポートすることとができることと、 ユーザによって様々な環境に採用できることが重要です。 コミュニケーションにおいて、 追加的手法がインシデントをセキュアにするために行われますが、 この論点は、これは一般的なIOアーカイビングや蓄積についての、 より厳密なルールを意味するのでIODEFの範疇外です。
選択された設計は、 様々なインテグリティ気候をサポートすることができる必要があり、 様々な環境に適用できなければなりません。
悪意あるIO変更を防ぐために、 特別な手段が講じられる必要があります。
追加的手段が、 コミュニケーションにおいてインシデントをセキュアにするために行われるでしょうが、 この論点は、IODEFの範囲外です。
真正性(authenticity)と説明責任(accountability)は、 多くのチームにとって必要とされ、特に、 自動的にIOを扱う要求がある場合に必要とされます。 それゆえ、 これはIODEF中に含まれなければなりません(MUST)。 多くのチームや、 特にそれらの間のコミュニケーションの場合のIO真正性(authenticity)と非否認性(non-repudiation)の重要性によって、 これらの要件の実装は、 強く推奨されます(RECOMMENDED)。
実装者は、内部目的ための情報、または、 彼らのインシデント対処システムの特定の実装のために必要不可欠な情報のような追加データを提供することを望む可能性があります。 これらのデータは、 外部コミュニケーションにおいて削除されたりされなかったりしますが、 異なるシステムによる誤った解釈を防ぐために、 それらを追加としてマークをつけることが肝要です。
IODEFは、 人間によるインシデント記述のためのフォーマットで、 IODEF記述は、人間によって読むことができる必要があります。 自動的解読ツールの利用が予定されていますが、 必ずしも必要不可欠であるわけではありません。 それゆえ、IODEFは、良い文法を提供しなければなりません。 これは、 記述が何を含んでいるかを理解するための鍵となります。 場合によっては、IODEF記述は、 自動的意思決定のために使用されます。 それゆえ、記述が正しく翻訳されることが重要です。 これは、言語ベース文法を使用するための言及です。 IODEF識別子やラベルのためのメタ言語は、 英語であることが提案され、ローカルIODEF実装は、 必要に応じてメタ言語識別子やラベルをローカル言語や表現に翻訳することができます。
新しいインシデント対処ツールをサポートするためにIODEFを拡張する要求に加えて、 IODEFが、 IDSのためのIDEFのような関連する標準化分野からの新しい開発、 または証拠カストディのための特別なフォーマットの開発を結合することも示唆されます。 拡張のための手続きは、 CSIRT／IODEFコミュニティの受容／承認に基づくものである必要があります。
このメモは、CSIRT間でインシデントについての記述、 情報のアーカイブ化と交換のための共通データフォーマットを規定することを意図したIODEFの要件を記述します。 (アラート、調査中のインシデント、アーカイブ化、統計情報、 報告、等が含まれます。) この観点において、IODEFの実装は、 セキュリティに関する考慮事項の論点です。 制限表示へのアクセスのための特定のセキュリティ要件は、 4.3節において検討されています。 インシデント記述の守秘性(confidentiality)／インテグリティ(integrity)／真正性(authenticity)／非否認性(non-repudiation)の要件は、 6.16、6.17、 6.18の節に記述されています。
| [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/ |
本書は、 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によって提供されています。