ネットワーク WG Request for Comments: 2350 BCP: 21 分類: ベストカレントプラクティス |
N. Brownlee The University of Auckland E. Guttman Sun Microsystems 1998年6月 |
本書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 より良くするために議論と示唆を求めるものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (1998). All Rights Reserved.
本書の目的は、 CSIRT (Computer Security Incident Response Teams)に対する一般的なインターネットコミュニティの期待を表明することにあります。 すべてのチームについて、 適切な要求事項を定めることは不可能ですが、 そのコミュニティに関心や興味を持たれている一般的な話題や論点を掲げて記述することは可能であり、 有用です。
CSIRT周辺の者は、 「彼らの」CSIRTのポリシーと手続きをよく理解する正当な要求と権利を持っています。 この理解を支援するひとつのやり方は、ユーザが、 そのCSIRTが完成させた公式なテンプレートと考えるような詳細な情報を提供することです。 そのようなテンプレートのあらましと、設例が提供されます。
2 範囲
2.1 CSIRT ポリシーと手続きを公表する
2.2 異なる CSIRT 間の関係
2.3 セキュアなコミュニケーションを確立する
3 情報、ポリシーおよび手順
3.1 文書を入手する
3.2 連絡先情報
3.3 憲章
3.3.1 使命の表明
3.3.2 構成員
3.3.3 スポンサー組織/組織間関係
3.3.4 オーソリティ
3.4 ポリシー
3.4.1 インシデントの種類とサポートのレベル
3.4.2 協力、相互関係、情報の開示
3.4.3 コミュニケーションと認証
3.5 サービス
3.5.1 インシデント対応
3.5.1.1 インシデントトリアージ
3.5.1.2 インシデントコーディネーション
3.5.1.3 インシデント解決
3.5.2 予防的な活動
3.6 インシデント報告様式
3.7 免責について
補遺 C: 既知のコンピュータセキュリティインシデント対応チーム
補遺 E: 例: ある CSIRT のために「埋められた」テンプレート
GRIPワーキンググループがCSIRTに対するコミュニティの期待を記述する文書を作成するために編成されました。 そのような文書の必要性は、 インターネットコミュニティ一般がきっかけとなってはいますが、 表明される期待は、 より狭い範囲のコミュニティのものと整合する必要もあります。
かつてCSIRTに期待することに関して誤解がありました。 本書の目的は、 コミュニティの関心事である(インシデント対応に関する)重要な問題を説明するためのフレームワークを提供することにあります。
続ける前に、"CSIRT"という用語の意味を正確に理解することが重要です。 この文書においては、CSIRTとは、 定められた範囲内のサイトに関するセキュリティインシデントについてコーディネーション、 サポート、対応を行うものの用語です。 (より完全な定義については、 補遺 Aをご覧ください。) それゆえ自身を特定の範囲のCSIRTと名乗るグループは皆、 報告されたセキュリティインシデントと「彼らの」構成員への脅威に、 その特定のコミュニティがその全般的な関心であると合意するようなやり方で、 対応する必要があります。
構成員のコミュニティの各メンバーが、 何を彼らのチームに期待してよいのがを理解できることが決定的に重要なので、 CSIRTは、誰が構成員に含まれるかを明確にし、 そのチームがコミュニティに提供するサービスを定める必要があります。 さらに、各CSIRTは、そのポリシーと運用手続きを公表する必要があります。 同様に、このような構成員は、彼らのチームからサービスを受けるために、 何が期待されているかを知る必要があります。 これは、インシデントを、どのように、 どこへ報告するかを表明することも要求します。
この文書は、CSIRTが彼らの構成員と、 この情報をコミュニケートするのに使用されるテンプレートについて詳説します。 構成員は、確実に、 CSIRTが完成したテンプレートに書いたサービスを提供することを期待するようになることでしょう。
ユーザからの活発な貢献なくしては、 CSIRTのサービスの有効性は大きく失われる可能性があることを強調しておかなければなりません。 これは特に報告においていえます。 少なくともユーザは、 セキュリティインシデントを報告する必要があることを知っておく必要があり、 どのように、どこへ、 それらを報告する必要があるかを知っておく必要があります。
多くのコンピュータセキュリティインシデントには、 ローカルコミュニティの境界外部を起点として内部のサイトに影響をもたらすものもあれば、 ローカルコミュニティ内部を起点として外部のホストもしくはユーザに影響を与えるものもあります。 それゆえ、しばしば、セキュリティインシデントを扱う際には、 複数のサイトや、 可能性としては複数のCSIRTを巻き込むことになります。 このようなインシデントを解決するには、個々のサイトとCSIRT間、 CSIRT相互間の協力が要求されます。
構成員のコミュニティは、どのように彼らのCSIRTが他のCSIRTや、 彼らの構成員以外の組織体と活動していくのかということと、 どのような情報が共有されるのかを正確に知る必要があります。
この文書の残りの部分でCSIRTが、 彼らの構成員のためによく検討する必要がある話題や論点を述べます。 しかし、 どの領域においても「正しい」答えを決めようとするものではありません。 むしろ、それぞれの話題は、その意義について検討されます。
第2章では、3つの主だった領域の概略を述べます。 :対応チームによる情報の公表、 対応チームの他の対応チームとの関係の規定、 セキュアなコミュニケーションの必要性。 第3章では、 コミュニティが彼らの対応チームについて知る必要がある、 すべての種類の情報を詳細に記述します。
コミュニティの使用の便宜のために、このような話題は、 補遺 Dにある概略を示すテンプレートに凝縮されています。 このテンプレートは、 構成員が彼らのCSIRTから情報を引き出すのに使用することができます。
このワーキンググループの心からの希望は、 この文書にある話題を明確化することを通じて、コミュニティと、 そのCSIRT間の相互理解が促進されることにあります。
インシデントチーム間との相互関係と、 その構成員のコミュニティとの相互関係において、 まず対応チームはコミュニティがその対応チームのポリシーと手続きを理解することを要求します。 第2に、多くの対応チームがインシデントを扱うのに協力しあうので、 そのコミュニティは、 彼らの対応チームと他のチームとの関係も理解しなければなりません。 最後に、多く相互関係を持つことが既存の公衆インフラストラクチャで有利であるので、 コミュニティは、 どのようにそのようなコミュニケーションが保護されるのかを知る必要があります。 これらの各論点は、以降の3つの章でより詳細に記述されます。
あるCSIRTにアクセスできる各ユーザは、 実際にそれを必要とするよりかなり前に、 このチームのサービスと相互関係を、 できるだけよく知っておく必要があります。
CSIRTのポリシーと手続きの明確な表明は、 構成員がどのようにインシデントを報告するかや、 何が事後処理への期待の支えになるかを理解するのに役立ちます。 そのCSIRTがインシデントを解決するのをアシストしてくれるか? 将来のインシデントを避けるのを助けてくれるか? 明確な期待、特にCSIRTによって提供されるサービスの制限は、 それとの相互関係をより効率的で有効なものにします。
対応チームには、様々な種類があります。 :非常に広い構成員を持つものもありますし(例:CERT/CCとインターネット)、 よりboundedな構成員をもつものもあり(例:DFN-CERT、CIAC)、 さらに非常に制限された構成員をもつものもあります(例、 商業対応チーム、企業内対応チーム)。 対応チームの種類にかかわらず、 それにサポートされているコミュニティは、 そのチームのポリシーと手続きを知っておかなければなりません。 それゆえ、対応チームがそのような情報を、 その構成員に公表することは必須です。
CSIRTは、そのポリシーとサービスについてのすべての必要な情報を、 その構成員の要求にそう形式でコミュニケートする必要があります。 必ずしもすべてポリシーと手順が公衆に入手可能である必要はないことを理解することが重要です。 例えば、相互関係において、インシデントの報告をする際、 もしくは分析方法やシステムをセキュアにする指針を受け取る際に、 チームの内部運営を理解する必要はありません。
かつて、運営フレームワークのようなものを提供しているチームもあれば、 FAQを提供しているチームもあり、 さらにユーザ会議で配布する紙を書いたり、 もしくはニュースレターを送るチームもあるという状況にありました。
我々は、各CSIRTがそのポリシーと手続きを、 自身の情報サーバ(例:WWWサーバー)に公表することをお薦めします。 これによって構成員は、それに容易にアクセスできるようになりますが、 どのように構成員が、 そのチームを見つけるかという問題は残ります。 ;構成員はCSIRTが「自由につかえる」ところにあることを発見する必要があります。
埋められたCSIRTテンプレートが、 すぐにモダンなサーチエンジンによって検索可能となることでしょう。 これは、既存のCSIRTについての情報と、 それらにアプローチするのに基礎的な情報の配布を助けることでしょう。
すべての埋められたテンプレートをもった中央レポジトリがあれば、 とても有用となるでしょう。 そのようなレポジトリは、この執筆時点では存在していませんが、 これは将来、変化することでしょう。
その情報が取得された入手元がどこであれ、 そのテンプレートのユーザは、 その真正性をチェックしなければなりません。 そのような決定的に重要な文書がデジタル署名で保護されていることが強く推奨されます。 このようにすることによって、ユーザは、 そのテンプレートが本当にそのCSIRTによって公表されていることと、 それが改ざんされていないことを検証することができるようになります。 本書において、読者は、 文書が本物であるかを判定するのにデジタル署名の正しい使用法に慣れていることを想定します。
CSIRTが、 自身とその構成員の密接な協力によって有効に運営できることはあります。 しかし今日の国際的なネットワーク化に伴って、 CSIRTによって扱われる大部分のインシデントが、 その構成員外部の主体を巻き込むようになってきました。 それゆえ、そのチームは、 他のCSIRTや構成員外部のサイトと相互関係をもつ必要があります。
構成員のコミュニティは、 この協力の性格と程度を理解する必要があります。 それは、個々の構成員に関する非常に取り扱いに注意を要する情報が、 この過程で開示される可能性があるからです。
CSIRT間の相互関係には、他のチームにアドバイスを要請したり、 問題の知識を普及させることや、CSIRTの構成員のひとつ、 もしくは複数に影響を及ぼしているセキュリティインシデントを解決するのに協力して働くことが含まれます。
そのような相互関係を支援するための協力関係を築く際に、 CSIRTは安全に護るべき情報を共有するために、 どのような種類の契約が両者間に存在しうるか、 この関係が開示されうるか、この場合誰に対してか、 を決めなければなりません。
関与するCSIRTが共に働き、情報を共有することに合意する、 契約を取り交わすことと、 CSIRT(もしくは他の組織体)が単に他のCSIRTと連絡をとり、 助けもしくはアドバイスを求める、 単純な協力は異なることを覚えておいてください。
そのような関係を築くことは非常に重要で、 その構成員をサポートするCSIRTの能力に影響を与えますが、 詳細についての判断はそのチームによります。 この過程について推奨事項を述べることは、この文書の範囲外です。 しかし、 情報の共有に関してユーザコミュニティがいだく期待のために使われる同じ情報は、 他の主体が特定のCSIRTの目的とサービスを理解するのを助け、 最初のコンタクトを支援するのです。
コンピュータセキュリティインシデント対応のコーディネーションの必要性に際して - ひとたび、ひとつの主体が他の主体と情報を共有することを決断したとき、 あるいは、ふたつの主体が情報を共有したり、 あるいは共に働くことに合意したとき、関与するすべての主体は、 セキュアなコミュニケーションのチャネルを必要とします。 (この文脈において「セキュア」とは、 異なる主体間で共有される保護された情報のやりとりのことをいい、 その主体による情報の適切な利用のことではありません。)
セキュアなコミュニケーションの目的:
変造した電子メールを送ることは、非常に簡単で、 電話で(虚偽の)身元をつくろうことは難しいことではありません。 暗号技術、例えばPGP (Pretty Good Privacy)もしくは PEM (Privacy Enhanced Mail)は、 電子メールをセキュアにする有効なやり方を提供することができます。 正しい機器をもつことによって、 電話のコミュニケーションもセキュアにすることができます。 しかし、そのような機構を使う前に、 双方の主体が「正しい」基盤を必要とします。 つまり、事前の準備です。 最も重要な準備は、 セキュアなコミュニケーションで使用される暗号鍵の真正性を確認することです。:
コミュニケーションは、 インシデント対応のすべての局面において極めて重要です。 チームは、上記の技術の使用を、 一貫したやり方で関連するすべての情報を集めることによって最もよくサポートすることができます。 (鍵の真正性をチェックするために特別の番号を尋ねることのような) 特別な要件は、最初から明確である必要があります。 CSIRTテンプレートは、 この情報を配信するために標準化された乗り物を提供します。
セキュアなコミュニケーションの技術的問題や管理的問題に対応することは、 本書の範囲外です。 要点は、対応チームは、 自身や彼らの構成員(あるいは他の対応チーム)との間のコミュニケーションをセキュアにする手段をサポートし、 使用しなければならないということです。 機構が何であれ、それが提供する保護のレベルは、 構成員のコミュニティが許容できるものでなければなりません。
第2章において、 対応チームのポリシーと手続きがその構成員のコミュニティに公表される必要があることが述べられました。 この章において、我々は、 コミュニティがその対応チームから受ける必要があるすべての種類の情報を掲げます。 どのようにこの情報がコミュニティとコミュニケートされるかは、 固有の情報内容があるでしょうから、 チームによって異なることでしょう。 ここでの意図は、 構成員のコミュニティがその対応チームから期待する様々な種類の情報を明確に記述することにあります。
構成員と「彼らの」CSIRTの相互関係に関する論点と話題をより簡単に理解できるようにするため、 我々は、CSIRTがすべての情報、 その構成員に対応したポリシーと手続きを文書として、 補遺 Dにあるテンプレートに従って公表することを示唆します。 そのテンプレート構造は、 固有の情報を埋めやすいように要素を配置してあります。 ;補遺 E において、 我々は架空のXYZ大学のための埋められたテンプレートの例を提供します。 何をCSIRTがそのポリシー、 もしくは手続きとして採用する必要があるかに関して、 推奨事項を述べてはいませんが、 別の可能性が例示のために概略が述べられています。 最も重要なことは、CSIRTがポリシーを持っていることと、 CSIRTに連絡をとる人が、それを入手できて、理解できることです。
いつもながら、各環境や、 あるいはチームのためのすべての観点が網羅できるわけではありません。 この概略は、示唆としてみていただく必要があります。 各チームは、彼らがその構成員をサポートするために必要と考えることなら何でも自由に含めることができるものととらえる必要があります。
CSIRTの詳細は、時間の経過に伴って変化するので、 埋められたテンプレートには、 いつ最後に更新されたかが含まれなければなりません。 さらに、将来の更新について、 どのように見つけることができるかに関して情報が提供される必要があります。 これが無い場合、誤解や思い違いが何度も生ずることを避けられません。 ;概略の文書は、かえって有害であることがあります。
- 最終更新日 | これによって、 興味を持つ人がそのテンプレートが最新であるかを評価することができるようになります。 |
- 配布リスト | メーリングリストは、 大勢のユーザに最新の情報を配信するのに便利な機構です。 チームは、この文書が変更される都度、自身の、 もしくは既存のリストを使用することを決めることができます。 このリストは通常、 そのCSIRTが頻繁に相互関係を持っているグループとなることでしょう。 CSIRTによって送られる更新メッセージには、 デジタル署名が使用される必要があります |
- 文書の在り処 | 現行バージョンの文書の在り処は、 チームのオンライン情報サービスを通じてアクセスすることができます。 これによって構成員は容易に、そのチームについてより詳しく学び、 最近の更新がないかをチェックすることができます。 このオンライン版は、デジタル署名を伴っている必要もあります。 |
CSIRTへの連絡方法の完全な詳細は、チームごとにまちまちでしょうが、 ここに掲載される必要があります。 ;例えば、ある者は、 彼らのチームのメンバーの名前を公表しないことを選択するかもしれません。 項目の意味が推測可能なものについては、説明文はつけておりません。
- CSIRTの名前 | |
- 所在地(郵便物のアドレス) | |
- 時間帯 | これは時間帯をまたぐインシデントをコーディネートする際に有用です。 |
- 電話番号 | |
- FAX 番号 | |
- 他の遠隔地通信 | チームによっては、 セキュアな声によるコミュニケーションを提供することでしょう。 (例:STU III) |
- 電子メール アドレス | |
- 公開鍵と暗号化 | 特定の技術の利用は、コミュニケーションの相手がプログラム、 鍵等にアクセスできることに依存しています。 そのCSIRTとやり取りをする際に、 ユーザが暗号化されたコミュニケーションを利用できるか、 どのように利用できるかを判断できるように、 関連情報が提供される必要があります。 |
- チームのメンバー | |
- 業務時間 | 業務時間と休業日スケジュールがここに提供される必要があります。 24時間ホットラインはありますか? |
- 追加的な連絡先 | 何か特定の顧客連絡先情報はありませんか? |
より詳細な連絡先情報が、提供されることもありえます。 これには、サービスごとに異なる連絡先が含まれたり、 もしくはオンライン情報サービスのリストであることがありえます。 何らかのサービスへのアクセスに特定の手続きがある場合 (例:メーリングリストの要求に対応する場合)、 それらはここで説明される必要があります。
各CSIRTは、何を行おうとしているのか、 何のオーソリティのもとにそれを行うのかを規定する憲章をもたねばなりません。 この憲章は、少なくとも下記の要素を含む必要があります。:
使命の表明は、 CSIRTの規定によって既に開始されているチームの核となる活動に焦点を当てる必要があります。 CSIRTとしてみなされるためには、そのチームは、 インシデントの報告をサポートし、 インシデントを扱うことによってその構成員をサポートしなければなりません。
チームの目標と目的は、特に重要であり、 明確で曖昧さのない規定が求めれられます。
CSIRTの構成員は、 いくつかあるやり方のどのようにでも決めることができます。 例えば、それは会社の従業員、 あるいは会費を払った会員である可能性があり、また、 特定のオペレーティング・システムのユーザのように技術的な観点から定めることもありえます。
構成員の定義は、 誰にそのチームはサービスを提供するのかに関してグループの周囲に境界を作る必要があります。 この文書のポリシーの章(後述)では、 この境界の外部からの要求がどのように扱われるかが説明される必要があります。
CSIRTがその構成員を開示しないことを決定した場合、 この決定の背後にある理由付けを説明する必要があります。 例えば、有償のCSIRTは、彼らの顧客を掲載しないかもしれませんが、 数多くの顧客に対して顧客の契約により秘密に保たれているサービスを提供していることを宣言することでしょう。
ISPがCSIRTを提供する場合、 CSIRTを持った顧客サイトにもサービスを提供するので構成員は重複している可能性があります。 CSIRTの記載(後述)のオーソリティの章は、 そのような関係を明確にする必要があります。
CSIRTの活動をオーソライズするスポンサー組織が次に掲げられる必要があります。 これを知っておくことは、CSIRTの背景と設立を理解することを助け、 構成員とCSIRT間の信頼を築くための決定的な情報です。
この節は、そのチームと、その構成員の間の関係に基づいて、 各CSIRTごとに大きく異なります。 組織体のCSIRTは、そのオーソリティを、 その組織体の経営管理者によって与えられることでしょうが、 コミュニティのCSIRTは通常、 アドバイザリーの役割を果たすことをそのコミュニティによって支持、 選択されます。
CSIRTは、 その境界内のすべてのシステムの運用において介在するオーソリティを持っている場合もあれば、 無い場合もあります。 それは、その構成員の境界で区別される、 そのコントロールの範囲を識別する必要があります。 他のCSIRTが、その境界内で階層的に運用する場合には、 これはここに記述され、関連するCSIRTが識別される必要があます。
チームのオーソリティの開示は、 自身を義務としての要求にさらすことになるでしょう。 各チームは、このような事柄については法的な助言を仰ぐ必要があります。 (義務についての詳細は、 3.7をご覧ください。)
CSIRT自身のポリシーを定めることが極めて重要です。 以降の章では、 このようなポリシーの構成員コミュニティとのコミュニケーションを検討します。
そのチームが対応することができるイシデントの種類と、 各種のインシデントに対応するときにそのチームが提供するサポートのレベルは、 一覧形式でここに示される必要があります。 サービスの章(後述)では、より詳細な記述を与える機会を提供し、 インシデントに関連しない話題に対応します。
サポートのレベルは、チームの仕事量や、 入手可能な情報の完全性のような要素によって変化することでしょう。 このような要素は、概略が述べられる必要があり、 それらの影響が説明される必要があります。 既知の種類のインシデントについてのリストが、潜在的な、 もしくは将来のインシデントに関して不完全であるのと同様に、 CSIRTは、さもなければ言及されることのない種類のインシデントに対する「デフォルト」サポートについて、 何らかの背景を提供する必要もあります。
そのチームは、 彼らが受け取る将来のインシデントの可能性を作り出す脆弱性の情報について、 行動を起こすか否かについて表明する必要があります。 そのコミュニティの代わりにそのような情報についての行動に参画することは、 CSIRTの核となるサービス要件ではなく、 オプションの予防的サービスポリシーとみなされます。
この章では、どの関係グループとそのCSIRTは、 規則的に相互関係をもっているかを明確にする必要があります。 そのような相互関係は、 発生するコンピュータセキュリティインシデント対応に関しては不要ですが、 技術的な話題、 もしくはサービスについてのより良い協力関係を促進するのに使用されます。 決して協力関係の契約の詳細が記載される必要はありません。 ;この章の主たる目的は、その構成員に、 どのような種類の相互関係が確立されて、 それらの目的が何であるかについての基本的理解を与えることです。
CSIRT間のコーディネーションは、 明確な引継ぎ手続きと組み合わされた固有のチケット番号割り当ての利用によって促進される可能性があります。 これによって、インシデント追跡における誤解の可能性、 努力や支援の重複が減少し、 コミュニケーションにおける「抜け穴」を防ぎます。
報告と開示のポリシーは、各状況下において、 誰がCSIRTの報告の受取人となるかを明確にする必要があります。 そのチームが他のCSIRT経由で運用することを予定しているのか、 あるいは他の構成員のメンバーと直接、 そのメンバーに個別的に関係のある事項について運用することを予定しているのかを明記しておく必要もあります。
CSIRTが相互関係をもつ関連グループを次に示します。:
チームが受け取る、いかなる、 すべてのセキュリティ関連の情報のデフォルトの位置付けは、 通常「秘密」扱いです。 しかし、厳密なこれについての固執は、 そのチームが情報の「ブラックホール」に見えるようにしてしまいます。 これは、そのチームがクライアントや他の組織から得られる協力の可能性を減らしてしまう可能性があります。 CSIRTのテンプレートは、どの情報を、誰に、 いつ報告ないし開示するかを定義する必要があります。
チームが異なれば、開示を要求したり規制する、 異なる法的規制の対象となることがよくあります。 特に異なる司法管轄権で働いている場合にいえます。 さらに、チームは彼らのスポンサー組織によって提起される報告要件を持っているかもしれません。 各チームのテンプレートは、ユーザの期待を明確化する目的と、 他のチームに知らせる目的の両方のために、いかなる、 そのような制約を規定する必要があります。
利益のコンフリクト、特に商業的な事項も、 チームによる開示を制約する可能性があります。; この文書は、そのようなコンフリクトがどのように対応される必要があるかについて推奨するものではありません。
チームは、通常、統計情報を集めます。 統計情報が配布されている場合、 そのテンプレートの報告と開示のポリシーには、 そのように書かれる必要があり、 そのような統計情報を入手する方法を記述する必要があります。
あなたが使用するセキュアで検証可能なコミュニケーション手段を記述するポリシーを持たねばなりません。 これは、CSIRT間と、CSIRTとその構成員間のコミュニケーションに必須です。 テンプレートには、公開鍵、もしくはそれらへのポインターが、 鍵のフィンガープリントを含めて含まれている必要があります。 これには、真正性をチェックするためにこの情報の使う方法と、 壊れた情報の扱い方(例えば、 どこにこれを報告するか)についてのガイドラインが伴っている必要があります。
現時点では、最低限、 各CSIRTが(可能であれば)PGP鍵を入手可能にすることが推奨されます。 チームによっては、自身のニーズや、その構成員のニーズに従って、 他の機構(例:PEM、MOSS、S/MIME)も利用可能にするかもしれません。 しかし、CSIRTやユーザは、 現地の法や規制に敏感である必要があることを覚えておいてください。 国によっては強い暗号を許していなかったり、 または暗号技術の利用にあったって特定のポリシーが強制されています。 取り扱いに注意を要する情報を、 暗号化可能な限り暗号化することに加えて、 書簡がデジタル署名を含んでいる必要があります。 (大部分の国においては、デジタル署名による真正性の保護は、 既存の暗号規制によって影響を受けないことを覚えておいてください。)
電話もしくはファクシミリによるコミュニケーションのために、 CSIRTは、扱う主体のために、 合意されたパスフレーズのような秘密の認証データを保持するかもしれません。 明らかに、そのような秘密鍵は、存在していようとも公表してはなりません。
CSIRTによって提供されるサービスは、 大雑把に2つのカテゴリに分類することができます。 :インシデント対応の主な仕事に直接関わるリアルタイムの活動と、 インシデント対応の仕事を支援するリアルタイムでない予防的な活動です。 2番目の分野と、最初の分野の部分が、 必ずしもすべてのCSIRTがそれらを提供するわけではないという観点からは、 オプションのサービスを構成しています。
インシデント対応には、通常、 インシデントについて届けられる報告の評価(「インシデントトリアージ」)、 それらについて他のCSIRT、 ISPやサイトとのフォローアップ(インシデントコーディネーション)が含まれます。 3番目の領域のサービスであるローカルサイトのインシデントからの復旧の補助(「インシデント復旧」)は、 必ずしもすべてのCSIRTが提供するわけではない、 典型的なオプションのサービスに含まれています。
インシデントトリアージには通常、次のことが含まれます。:
- 報告の分析 | 届けられるインシデント報告の解釈、 それらのプライオリティ付けと、 進行中のインシデントや趨勢との関連付け。 |
- 証明(Verification) | インシデントが本当に起きているかの判断とその範囲の判断を補助する。 |
インシデントコーディネーションには、通常、次のことが含まれます。:
- 情報分類 | インシデント関連情報(ログファイル、 連絡先、等)の分類。情報開示ポリシーに準拠してなされます。 |
- コーディネーション | 情報開示ポリシーに従い、必要に応じて関連する他の主体に通知する。 |
通常、追加的、オプションのインシデント解決サービスには、 次のことが含まれます。:
- 技術的な支援 | これには、被害を受けたシステムの分析が含まれる。 |
- 根絶 | セキュリティインシデントの原因(攻略された脆弱性)と、 その影響(例えば、システムへの侵入者による継続的なアクセス)を根絶する。 |
- 復旧 | セキュリティインシデント前の状態に影響を受けたシステムやサービスを復旧することを追加する。 |
通常、追加的もしくはオプションの予防的サービスには、次のことが含まれます。:
- 情報提供 | これには既知の脆弱性のアーカイブ、 過去の問題のパッチもしくは解消法、 またはアドバイザリーメーリングリストが含まれる可能性がある。 |
- セキュリティツール | これには、 サイトのセキュリティを監査するためのツールが含まれる可能性がある。 |
- 教育と訓練 | |
- 製品評価 | |
- サイトセキュリティ監査とコンサルティング |
報告様式の利用は、ユーザとチームの双方にとってインシデントの扱いを、 より単純にします。 構成員は、実際にチームに連絡する前に、 様々な重要な質問に対する答を準備することができるので、 よく備えることができます。 そのチームは、 最初の報告で一度にすべての必要な情報を得ることができるので、 効果的に処理することができます。
特定のCSIRTの目的やサービスに応じて、 複数の様式が使用される可能性があり、例えば、 新しい脆弱性の報告のための様式は、 インシデント報告に使用される様式とは相当に異なることでしょう。
そのチームのオンラインの情報サービスを通じて様式を提供するのが最も効率的です。 それらへの正確なポインターは、適切な使用法についての表明と、何時、 どのようにその様式を使うかのガイドラインとともにCSIRT概要の文書中に掲載される必要があります。 独立した電子メールアドレスが、 様式に基づいた報告においてサポートされている場合、 それらもここに掲載される必要があります。
そのような様式の一例は、 CERT/CCによって提供されているIncident Reporting Form です。:
CSIRTの記述文書は、契約を構成するものではありませんが、義務は、 おそらくそのサービスや目的の記述によることでしょう。 それゆえ、免責についてをテンプレートの末尾に含めることが推奨され、 制限の可能性についてユーザに警告する必要があります。
文書の原文が他の言語に翻訳されなければならない状況においては、 その翻訳は免責についての記述を掲載し、 原文へのポインターを掲載する必要があります。 例:
我々は注意深く原文書をドイツ語から英語に翻訳することを試みましたが、 双方の文書が同一の考えを同程度の詳細さと正確さで表現していることに確信をもつことはできません。 双方のバージョンに差異があるいかなる場合においても、 ドイツ語版が優先されます。
免責についての記述による保護の使用は、 各CSIRTが認識している必要がある現地の法や規制によって影響を受けます。 迷う場合には、そのCSIRTは法律家に免責について確認する必要があります。
この小辞典は、 セキュリティインシデントやコンピュータセキュリティインシデント対応チームを記述する際に使用される用語を定義します。 限られたリストが含められています。 より他のの定義については、例えば Internet User's Glossary [RFC 1983] のような他の情報をご覧ください。
インシデントの定義は、組織体間で様々である可能性がありますが、 少なくとも次の分類は、一般に適用可能です。:
これらは、非常に一般的な分類です。 例えば、トロイの木馬によるシステムユーティリティの置き換えは、 「インテグリティの侵害」の一例であり、パスワード攻撃の成功は、 「守秘性の喪失」の一例です。
攻撃は、たとえ正しい防護によって失敗しても、 インシデントとみなされる可能性があります。
インシデントの定義において、 「侵害(compromised)」という単語が使われます。 しばしば、管理者は、 インシデントの「疑い」だけをもつ可能性があります。 対応において、 インシデントが現実に発生したのか否かを確立しなければなりません。
CSIRT とみなされるためには、チームは、:
我々は、ここで警察、 もしくは他のコンピュータ犯罪を捜査する可能性がある法執行機関を指していないことに注意してください。 CSIRTメンバーは、まさに、 通常の市民の力以上のいかなる力も持つ必要がありません。
テクノロジーの供給者が必ずしも、 そのテクノロジーの「ベンダー」ではないことに注意してください。 一例として、インターネットサービスプロバイダー(ISP)は、 その各顧客にルーターを提供する可能性がありますが、 「ベンダー」は、製造者であり、製造者ゆえ、 ISPではなく、そのルーターの技術的な内容に責任ある主体です。
サイトレベルにおいて、 セキュリティインシデントに対応する際の重要な論点は、 サイトセキュリティワーキンググループによって作成された「サイトセキュリティハンドブック(SSH)」 [RFC 2196] に含まれています。 本書は、SSHワーキングによって改訂され、 主にセキュリティインシデントの回避に関するローカルポリシーと手順についての推奨事項を提供するでしょう。
CSIRTとそのタスクの検討に関する他の文書は、 anonymous FTPによって入手可能です。 コレクションは、こちらにあります。:
本書に関連するいくつかの特別に興味深い文書は、次のとおり。:
今日、多くの異なるCSIRTがありますが、 各チームを列挙する唯一の情報源は、ありません。 主要で長く設立されているチーム(最初のCSIRTは、 1988年に設立されました。)は、今日、 世界規模のインシデント対応とセキュリティのチームのフォーラムであるFIRSTのメンバーです。 執筆時点において、55チーム以上がメンバーです。 (オーストラリアに1、ヨーロッパに13、北米に他のすべて。) FIRSTについての情報は、こちらで見つけられます。:
現在のメンバーの一覧も、 関連連絡先情報と特定のチームによって提供されている何らかの追加情報とともに入手可能です。:
このフォーラムのメンバーになることを望むCSIRTのためには、 下記のファイルが、より情報を含んでいます。 (チームは、紹介されるスポンサー(既にFIRSTのフルメンバーであるチーム)を必要とすることに注意してください。):
多くのヨーロッパのチームは、FIRSTメンバーであるか否かに関わらす、 ドイツのCSIRTによって維持されいるページ情に国ごとにリストされています。:
ニーズに適合する既存のチームについて学ぶためには、しばしば、 既知のチーム、もしくはISPに「正しい」連絡先を尋ねることが有益です。
この骨子は、本書において示された論点から要点を概説し、 CSIRT記述文書用に推奨されるテンプレートです。 この構造は、CSIRTの構成員や他のCSIRTのような外部の組織体に向けて、 CSIRTのポリシー、 手順および他の関連情報のコミュニケーションを円滑にするために設計されました。 このテンプレートの「埋められた」例は、 補遺 Eとして提供されます。
1. 文書情報
1.1 最終更新日
1.2 通知のための配布リスト
1.3 本書がある場所
2. 連絡先情報
2.1 チームの名前
2.2 所在地
2.3 時間帯
2.4 電話番号
2.5 ファクシミリ番号
2.6 他の遠隔コミュニケーション
2.7 電子メールアドレス
2.8 公開鍵と他の暗号化情報
2.9 チームメンバー
2.10 他の情報
2.11 顧客連絡先
3. 憲章
3.1 使命表明
3.2 構成員
3.3 スポンサーシップ、かつ/または提携
3.4 オーソリティ
4. ポリシー
4.1 インシデントの種類とサポートのレベル
4.2 協力、相互活動および情報の開示
4.3 コミュニケーションと本人認証
5. サービス
5.1 インシデント対応
5.1.1. インシデントトリアージ
5.1.2. インシデントコーディネーション
5.1.3. インシデント解決
5.2 予防的活動
下記は、 「XYZ-CSIRT」と呼ばれる架空のCSIRTのために埋められたテンプレートの例です。 本文は、例示目的にすぎず、 ワーキンググループもしくはIETFによる、 いかなる特定の手順もしくはポリシーの推奨をも構成するものではありません。 CSIRTが本文のいかなる部分もしくは全部を使用することを望む場合、 歓迎しますが、このような利用は、当然ながら強制ではなく、あるいは、 多くの場合、適切でさえありません。
This is version 1.01, published 1997/03/31.
Notifications of updates are submitted to our mailing list <xyz-cert-info@xyz-univ.ca>. Subscription requests for this list should be sent to the Majordomo at <xyz-cert-info-request@xyz-univ.ca> the body of the message should consist of the word "subscribe". Send the word "help" instead if you don't know how to use a Majordomo list manager. This mailing list is moderated.
The current version of this CSIRT description document
is available from the XYZ-CERT WWW site; its URL is
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt
Une version francaise de ce document est igalement disponible:
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt
Please make sure you are using the latest version.
Both the English and French versions of this document have
been signed with the XYZ-CERT's PGP key. The signatures are
also on our Web site, under:
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc
"XYZ-CERT": the XYZ University Computer Emergency Response Team.
XYZ-CERT
XYZ University, Computing Services Department
12345 Rue Principale
UniversityTown, Quebec
Canada H0H 0H0
Canada/Eastern (GMT-0500, and GMT-0400 from April to October)
+1 234 567 7890 (ask for the XYZ-CERT)
+1 234 567 7899 (this is *not* a secure fax)
None available.
<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail to the human(s) on duty for the XYZ-CERT.
The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
whose fingerprint is
11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.
The key and its signatures can be found at the usual large
public keyservers.
Because PGP is still a relatively new technology at XYZ University, this key still has relatively few signatures; efforts are underway to increase the number of links to this key in the PGP "web of trust". In the meantime, since most fellow universities in Quebec have at least one staff member who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has signed the XYZ-CERT key, and will be happy to confirm its fingerprint and that of her own key to those people who know her, by telephone or in person.
Zoe Doe of Computing Services is the XYZ-CERT
coordinator. Backup coordinators and other team members,
along with their areas of expertise and contact information,
are listed in the XYZ-CERT web pages, at
http://www.xyz-univ.ca/xyz-cert/teamlist.html
Management, liaison and supervision are provided by Steve Tree, Assistant Director (Technical Services), Computing Services.
General information about the XYZ-CERT, as well as links to
various recommended security resources, can be found at
http://www.xyz-univ.ca/xyz-cert/index.html
The preferred method for contacting the XYZ-CERT is via e-mail at <xyz-cert@xyz-univ.ca> e-mail sent to this address will "biff" the responsible human, or be automatically forwarded to the appropriate backup person, immediately. If you require urgent assistance, put "urgent" in your subject line.
If it is not possible (or not advisable for security reasons) to use e-mail, the XYZ-CERT can be reached by telephone during regular office hours. Telephone messages are checked less often than e-mail.
The XYZ-CERT's hours of operation are generally restricted to regular business hours (09:00-17:00 Monday to Friday except holidays).
If possible, when submitting your report, use the form mentioned in section 6.
The purpose of the XYZ-CERT is, first, to assist members of XYZ University community in implementing proactive measures to reduce the risks of computer security incidents, and second, to assist XYZ community in responding to such incidents when they occur.
The XYZ-CERT's constituency is the XYZ University community,
as defined in the context of the "XYZ University Policy on
Computing Facilities". This policy is available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
However, please note that, notwithtanding the above, XYZ-CERT services will be provided for on-site systems only.
The XYZ-CERT is sponsored by the ACME Canadian Research Network. It maintains affiliations with various University CSIRTs throughout Canada and the USA on an as needed basis.
The XYZ-CERT operates under the auspices of, and with
authority delegated by, the Department of Computing Services
of XYZ University. For further information on the mandate
and authority of the Department of Computing Services,
please refer to the XYZ University "Policy on Computing
Facilities", available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
The XYZ-CERT expects to work cooperatively with system administrators and users at XYZ University, and, insofar as possible, to avoid authoritarian relationships. However, should circumstances warrant it, the XYZ-CERT will appeal to Computing Services to exert its authority, direct or indirect, as necessary. All members of the XYZ-CERT are members of the CCSA (Committee of Computer Systems Administrators), and have all of the powers and responsibilities assigned to Systems Administrators by the Policy on Computing Facilities, or are members of University management.
Members of the XYZ University community who wish to appeal the actions of the XYZ-CERT should contact the Assistant Director (Technical Services), Computing Services. If this recourse is not satisfactory, the matter may be referred to the Director of Computing Services (in the case of perceived problems with existing policy), or to the XYZ University Office of Rights and Responsibilities (in the case of perceived errors in the application of existing policy).
The XYZ-CERT is authorized to address all types of computer security incidents which occur, or threaten to occur, at XYZ University.
The level of support given by XYZ-CERT will vary depending on the type and severity of the incident or issue, the type of constituent, the size of the user community affected, and the XYZ-CERT's resources at the time, though in all cases some response will be made within one working day. Resources will be assigned according to the following priorities, listed in decreasing order:
Types of incidents other than those mentioned above will be prioritized according to their apparent severity and extent.
Note that no direct support will be given to end users; they are expected to contact their system administrator, network administrator, or department head for assistance. The XYZ-CERT will support the latter people.
While the XYZ-CERT understands that there exists great variation in the level of system administrator expertise at XYZ University, and while the XYZ-CERT will endeavor to present information and assistance at a level appropriate to each person, the XYZ-CERT cannot train system administrators on the fly, and it cannot perform system maintenance on their behalf. In most cases, the XYZ-CERT will provide pointers to the information needed to implement appropriate measures.
The XYZ-CERT is committed to keeping the XYZ University system administration community informed of potential vulnerabilities, and where possible, will inform this community of such vulnerabilities before they are actively exploited.
While there are legal and ethical restrictions on the flow of information from XYZ-CERT, many of which are also outlined in the XYZ University Policy on Computing Facilities, and all of which will be respected, the XYZ-CERT acknowledges its indebtedness to, and declares its intention to contribute to, the spirit of cooperation that created the Internet. Therefore, while appropriate measures will be taken to protect the identity of members of our constituency and members of neighbouring sites where necessary, the XYZ-CERT will otherwise share information freely when this will assist others in resolving or preventing security incidents.
In the paragraphs below, "affected parties" refers to the legitimate owners, operators, and users of the relevant computing facilities. It does not refer to unauthorized users, including otherwise authorized users making unauthorized use of a facility; such intruders may have no expectation of confidentiality from the XYZ-CERT. They may or may not have legal rights to confidentiality; such rights will of course be respected where they exist. Information being considered for release will be classified as follows:
Private user information will be not be released in identifiable form outside the XYZ-CERT, except as provided for below. If the identity of the user is disguised, then the information can be released freely (for example to show a sample .cshrc file as modified by an intruder, or to demonstrate a particular social engineering attack).
While intruder information, and in particular identifying information, will not be released to the public (unless it becomes a matter of public record, for example because criminal charges have been laid), it will be exchanged freely with system administrators and CSIRTs tracking an incident.
It will not be released without the permission of the site in question, except as provided for below.
Vulnerability information will be released freely, though every effort will be made to inform the relevant vendor before the general public is informed.
Embarrassing information will not be released without the permission of the site or users in question, except as provided for below.
Statistical information will be released at the discretion of the Computing Services Department.
Contact information will be released freely, except where the contact person or entity has requested that this not be the case, or where XYZ-CERT has reason to believe that the dissemination of this information would not be appreciated.
Potential recipients of information from the XYZ-CERT will be classified as follows:
For the purposes of resolving a security incident, otherwise semi-private but relatively harmless user information such as the provenance of connections to user accounts will not be considered highly sensitive, and can be transmitted to a foreign site without excessive precautions. "Intruder information" will be transmitted freely to other system administrators and CSIRTs. "Embarrassing information" can be transmitted when there is reasonable assurance that it will remain confidential, and when it is necessary to resolve an incident.
In view of the types of information that the XYZ-CERT will likely be dealing with, telephones will be considered sufficiently secure to be used even unencrypted. Unencrypted e-mail will not be considered particularly secure, but will be sufficient for the transmission of low-sensitivity data. If it is necessary to send highly sensitive data by e-mail, PGP will be used. Network file transfers will be considered to be similar to e-mail for these purposes: sensitive data should be encrypted for transmission.
Where it is necessary to establish trust, for example before relying on information given to the XYZ-CERT, or before disclosing confidential information, the identity and bona fide of the other party will be ascertained to a reasonable degree of trust. Within XYZ University, and with known neighbor sites, referrals from known trusted people will suffice to identify someone. Otherwise, appropriate methods will be used, such as a search of FIRST members, the use of WHOIS and other Internet registration information, etc, along with telephone call-back or e-mail mail-back to ensure that the party is not an impostor. Incoming e-mail whose data must be trusted will be checked with the originator personally, or by means of digital signatures (PGP in particular is supported).
XYZ-CERT will assist system administrators in handling the technical and organizational aspects of incidents. In particular, it will provide assistance or advice with respect to the following aspects of incident management:
In addition, XYZ-CERT will collect statistics concerning incidents which occur within or involve the XYZ University community, and will notify the community as necessary to assist it in protecting against known attacks.
To make use of XYZ-CERT's incident response services, please send e-mail as per section 2.11 above. Please remember that the amount of assistance available will vary according to the parameters described in section 4.1.
The XYZ-CERT coordinates and maintains the following services to the extent possible depending on its resources:
Detailed descriptions of the above services, along with instructions for joining mailing lists, downloading information, or participating in certain services such as the central logging and file integrity checking services, are available on the XYZ-CERT web site, as per section 2.10 above.
There are no local forms developed yet for reporting
incidents to XYZ-CERT. If possible, please make use of the
Incident Reporting Form of the CERT Coordination Center
(Pittsburgh, PA). The current version is available from:
ftp://info.cert.org/incident_reporting_form
While every precaution will be taken in the preparation of information, notifications and alerts, XYZ-CERT assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained within.
著者一同は、Anne Bennett氏の提供してくださった原稿と、編集、 校正に大変感謝しています。 インシデント対応チームサービスの記述を推敲するのを支援してくださった Don Stikvoort氏にも感謝します。
[RFC 2196] |
Fraser, B., 「サイトセキュリティハンドブック (Site Security Handbook)」, FYI 8, RFC 2196, 1997年9月. |
[RFC 1983] |
Malkin, G., 「インターネットユーザの小辞典 (Internet Users' Glossary)」, FYI 18, RFC 1983(English), 1996年8月. |
本書は、CSIRTの運営と、 チームの彼らの構成員や他の組織体との相互関係を検討しています。 それゆえ、プロトコル、 アプリケーションもしくはネットワークシステム自体のセキュリティに、 直接関連するものではありません。 さらに、特定の対応や、 セキュリティインシデントに対する対応に関するものではありませんが、 CSIRTによって提供される対応についての適切な記述に関するものです。
それでもなお、CSIRT自身がセキュアに運営されることが決定的に重要です。 これは、他のチームや構成員のメンバーとセキュアなコミュニケーションチャネルを確立しなければならないことを意味します。 彼らは、その構成員の利益を保護し、 被害者やセキュリティインシデントの報告者の識別情報の守秘性を維持するために、 自身のシステムやインフラストラクチャもセキュアにしなければなりません。
Nevil Brownlee
ITSS Technology Development
The University of Auckland
電話: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Erik Guttman
Sun Microsystems, Inc.
Bahnstr. 2
74915 Waibstadt Germany
電話: +49 7263 911484
EMail: Erik.Guttman@sun.com
翻訳者のアドレス
宮川 寧夫
情報処理振興事業協会
セキュリティセンター
EMail: miyakawa@ipa.go.jp
Copyright (C) The Internet Society (1998). 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.