ネットワーク WG
Request for Comments: 2350
BCP: 21
分類: ベストカレントプラクティス
N. Brownlee
The University of Auckland
E. Guttman
Sun Microsystems
1998年6月

English

コンピュータセキュリティインシデント対応への期待
(Expectations for Computer Security Incident Response)

このメモの位置付け

本書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 より良くするために議論と示唆を求めるものです。 このメモの配布に制限はありません。

著作権表記

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

要旨

本書の目的は、 CSIRT (Computer Security Incident Response Teams)に対する一般的なインターネットコミュニティの期待を表明することにあります。 すべてのチームについて、 適切な要求事項を定めることは不可能ですが、 そのコミュニティに関心や興味を持たれている一般的な話題や論点を掲げて記述することは可能であり、 有用です。

CSIRT周辺の者は、 「彼らの」CSIRTのポリシーと手続きをよく理解する正当な要求と権利を持っています。 この理解を支援するひとつのやり方は、ユーザが、 そのCSIRTが完成させた公式なテンプレートと考えるような詳細な情報を提供することです。 そのようなテンプレートのあらましと、設例が提供されます。

目次

1 はじめに

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 免責について

補遺 A: 用語の小辞典

補遺 B: 関連資料

補遺 C: 既知のコンピュータセキュリティインシデント対応チーム

補遺 D: CSIRT テンプレートについての骨子

補遺 E: 例: ある CSIRT のために「埋められた」テンプレート

4 謝辞

5 参考文献

6 セキュリティについての考慮事項

7 著者のアドレス

8 著作権表記全文

1 はじめに English

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 範囲 English

インシデントチーム間との相互関係と、 その構成員のコミュニティとの相互関係において、 まず対応チームはコミュニティがその対応チームのポリシーと手続きを理解することを要求します。 第2に、多くの対応チームがインシデントを扱うのに協力しあうので、 そのコミュニティは、 彼らの対応チームと他のチームとの関係も理解しなければなりません。 最後に、多く相互関係を持つことが既存の公衆インフラストラクチャで有利であるので、 コミュニティは、 どのようにそのようなコミュニケーションが保護されるのかを知る必要があります。 これらの各論点は、以降の3つの章でより詳細に記述されます。

2.1 CSIRT ポリシーと手続きを公表する English

あるCSIRTにアクセスできる各ユーザは、 実際にそれを必要とするよりかなり前に、 このチームのサービスと相互関係を、 できるだけよく知っておく必要があります。

CSIRTのポリシーと手続きの明確な表明は、 構成員がどのようにインシデントを報告するかや、 何が事後処理への期待の支えになるかを理解するのに役立ちます。 そのCSIRTがインシデントを解決するのをアシストしてくれるか? 将来のインシデントを避けるのを助けてくれるか? 明確な期待、特にCSIRTによって提供されるサービスの制限は、 それとの相互関係をより効率的で有効なものにします。

対応チームには、様々な種類があります。 :非常に広い構成員を持つものもありますし(例:CERT/CCとインターネット)、 よりboundedな構成員をもつものもあり(例:DFN-CERT、CIAC)、 さらに非常に制限された構成員をもつものもあります(例、 商業対応チーム、企業内対応チーム)。 対応チームの種類にかかわらず、 それにサポートされているコミュニティは、 そのチームのポリシーと手続きを知っておかなければなりません。 それゆえ、対応チームがそのような情報を、 その構成員に公表することは必須です。

CSIRTは、そのポリシーとサービスについてのすべての必要な情報を、 その構成員の要求にそう形式でコミュニケートする必要があります。 必ずしもすべてポリシーと手順が公衆に入手可能である必要はないことを理解することが重要です。 例えば、相互関係において、インシデントの報告をする際、 もしくは分析方法やシステムをセキュアにする指針を受け取る際に、 チームの内部運営を理解する必要はありません。

かつて、運営フレームワークのようなものを提供しているチームもあれば、 FAQを提供しているチームもあり、 さらにユーザ会議で配布する紙を書いたり、 もしくはニュースレターを送るチームもあるという状況にありました。

我々は、各CSIRTがそのポリシーと手続きを、 自身の情報サーバ(例:WWWサーバー)に公表することをお薦めします。 これによって構成員は、それに容易にアクセスできるようになりますが、 どのように構成員が、 そのチームを見つけるかという問題は残ります。 ;構成員はCSIRTが「自由につかえる」ところにあることを発見する必要があります。

埋められたCSIRTテンプレートが、 すぐにモダンなサーチエンジンによって検索可能となることでしょう。 これは、既存のCSIRTについての情報と、 それらにアプローチするのに基礎的な情報の配布を助けることでしょう。

すべての埋められたテンプレートをもった中央レポジトリがあれば、 とても有用となるでしょう。 そのようなレポジトリは、この執筆時点では存在していませんが、 これは将来、変化することでしょう。

その情報が取得された入手元がどこであれ、 そのテンプレートのユーザは、 その真正性をチェックしなければなりません。 そのような決定的に重要な文書がデジタル署名で保護されていることが強く推奨されます。 このようにすることによって、ユーザは、 そのテンプレートが本当にそのCSIRTによって公表されていることと、 それが改ざんされていないことを検証することができるようになります。 本書において、読者は、 文書が本物であるかを判定するのにデジタル署名の正しい使用法に慣れていることを想定します。

2.2 異なるCSIRT間の関係 English

CSIRTが、 自身とその構成員の密接な協力によって有効に運営できることはあります。 しかし今日の国際的なネットワーク化に伴って、 CSIRTによって扱われる大部分のインシデントが、 その構成員外部の主体を巻き込むようになってきました。 それゆえ、そのチームは、 他のCSIRTや構成員外部のサイトと相互関係をもつ必要があります。

構成員のコミュニティは、 この協力の性格と程度を理解する必要があります。 それは、個々の構成員に関する非常に取り扱いに注意を要する情報が、 この過程で開示される可能性があるからです。

CSIRT間の相互関係には、他のチームにアドバイスを要請したり、 問題の知識を普及させることや、CSIRTの構成員のひとつ、 もしくは複数に影響を及ぼしているセキュリティインシデントを解決するのに協力して働くことが含まれます。

そのような相互関係を支援するための協力関係を築く際に、 CSIRTは安全に護るべき情報を共有するために、 どのような種類の契約が両者間に存在しうるか、 この関係が開示されうるか、この場合誰に対してか、 を決めなければなりません。

関与するCSIRTが共に働き、情報を共有することに合意する、 契約を取り交わすことと、 CSIRT(もしくは他の組織体)が単に他のCSIRTと連絡をとり、 助けもしくはアドバイスを求める、 単純な協力は異なることを覚えておいてください。

そのような関係を築くことは非常に重要で、 その構成員をサポートするCSIRTの能力に影響を与えますが、 詳細についての判断はそのチームによります。 この過程について推奨事項を述べることは、この文書の範囲外です。 しかし、 情報の共有に関してユーザコミュニティがいだく期待のために使われる同じ情報は、 他の主体が特定のCSIRTの目的とサービスを理解するのを助け、 最初のコンタクトを支援するのです。

2.3 セキュアなコミュニケーションを確立する English

コンピュータセキュリティインシデント対応のコーディネーションの必要性に際して - ひとたび、ひとつの主体が他の主体と情報を共有することを決断したとき、 あるいは、ふたつの主体が情報を共有したり、 あるいは共に働くことに合意したとき、関与するすべての主体は、 セキュアなコミュニケーションのチャネルを必要とします。 (この文脈において「セキュア」とは、 異なる主体間で共有される保護された情報のやりとりのことをいい、 その主体による情報の適切な利用のことではありません。)

セキュアなコミュニケーションの目的:

変造した電子メールを送ることは、非常に簡単で、 電話で(虚偽の)身元をつくろうことは難しいことではありません。 暗号技術、例えばPGP (Pretty Good Privacy)もしくは PEM (Privacy Enhanced Mail)は、 電子メールをセキュアにする有効なやり方を提供することができます。 正しい機器をもつことによって、 電話のコミュニケーションもセキュアにすることができます。 しかし、そのような機構を使う前に、 双方の主体が「正しい」基盤を必要とします。 つまり、事前の準備です。 最も重要な準備は、 セキュアなコミュニケーションで使用される暗号鍵の真正性を確認することです。:

コミュニケーションは、 インシデント対応のすべての局面において極めて重要です。 チームは、上記の技術の使用を、 一貫したやり方で関連するすべての情報を集めることによって最もよくサポートすることができます。 (鍵の真正性をチェックするために特別の番号を尋ねることのような) 特別な要件は、最初から明確である必要があります。 CSIRTテンプレートは、 この情報を配信するために標準化された乗り物を提供します。

セキュアなコミュニケーションの技術的問題や管理的問題に対応することは、 本書の範囲外です。 要点は、対応チームは、 自身や彼らの構成員(あるいは他の対応チーム)との間のコミュニケーションをセキュアにする手段をサポートし、 使用しなければならないということです。 機構が何であれ、それが提供する保護のレベルは、 構成員のコミュニティが許容できるものでなければなりません。

3 情報、ポリシーおよび手順 English

第2章において、 対応チームのポリシーと手続きがその構成員のコミュニティに公表される必要があることが述べられました。 この章において、我々は、 コミュニティがその対応チームから受ける必要があるすべての種類の情報を掲げます。 どのようにこの情報がコミュニティとコミュニケートされるかは、 固有の情報内容があるでしょうから、 チームによって異なることでしょう。 ここでの意図は、 構成員のコミュニティがその対応チームから期待する様々な種類の情報を明確に記述することにあります。

構成員と「彼らの」CSIRTの相互関係に関する論点と話題をより簡単に理解できるようにするため、 我々は、CSIRTがすべての情報、 その構成員に対応したポリシーと手続きを文書として、 補遺 Dにあるテンプレートに従って公表することを示唆します。 そのテンプレート構造は、 固有の情報を埋めやすいように要素を配置してあります。 ;補遺 E において、 我々は架空のXYZ大学のための埋められたテンプレートの例を提供します。 何をCSIRTがそのポリシー、 もしくは手続きとして採用する必要があるかに関して、 推奨事項を述べてはいませんが、 別の可能性が例示のために概略が述べられています。 最も重要なことは、CSIRTがポリシーを持っていることと、 CSIRTに連絡をとる人が、それを入手できて、理解できることです。

いつもながら、各環境や、 あるいはチームのためのすべての観点が網羅できるわけではありません。 この概略は、示唆としてみていただく必要があります。 各チームは、彼らがその構成員をサポートするために必要と考えることなら何でも自由に含めることができるものととらえる必要があります。

3.1 文書を入手する English

CSIRTの詳細は、時間の経過に伴って変化するので、 埋められたテンプレートには、 いつ最後に更新されたかが含まれなければなりません。 さらに、将来の更新について、 どのように見つけることができるかに関して情報が提供される必要があります。 これが無い場合、誤解や思い違いが何度も生ずることを避けられません。 ;概略の文書は、かえって有害であることがあります。

- 最終更新日 これによって、 興味を持つ人がそのテンプレートが最新であるかを評価することができるようになります。
- 配布リスト メーリングリストは、 大勢のユーザに最新の情報を配信するのに便利な機構です。 チームは、この文書が変更される都度、自身の、 もしくは既存のリストを使用することを決めることができます。 このリストは通常、 そのCSIRTが頻繁に相互関係を持っているグループとなることでしょう。 CSIRTによって送られる更新メッセージには、 デジタル署名が使用される必要があります
- 文書の在り処 現行バージョンの文書の在り処は、 チームのオンライン情報サービスを通じてアクセスすることができます。 これによって構成員は容易に、そのチームについてより詳しく学び、 最近の更新がないかをチェックすることができます。 このオンライン版は、デジタル署名を伴っている必要もあります。

3.2 連絡先情報 English

CSIRTへの連絡方法の完全な詳細は、チームごとにまちまちでしょうが、 ここに掲載される必要があります。 ;例えば、ある者は、 彼らのチームのメンバーの名前を公表しないことを選択するかもしれません。 項目の意味が推測可能なものについては、説明文はつけておりません。

- CSIRTの名前
- 所在地(郵便物のアドレス)
- 時間帯 これは時間帯をまたぐインシデントをコーディネートする際に有用です。
- 電話番号
- FAX 番号
- 他の遠隔地通信 チームによっては、 セキュアな声によるコミュニケーションを提供することでしょう。 (例:STU III)
- 電子メール アドレス
- 公開鍵と暗号化 特定の技術の利用は、コミュニケーションの相手がプログラム、 鍵等にアクセスできることに依存しています。 そのCSIRTとやり取りをする際に、 ユーザが暗号化されたコミュニケーションを利用できるか、 どのように利用できるかを判断できるように、 関連情報が提供される必要があります。
- チームのメンバー
- 業務時間 業務時間と休業日スケジュールがここに提供される必要があります。 24時間ホットラインはありますか?
- 追加的な連絡先 何か特定の顧客連絡先情報はありませんか?

より詳細な連絡先情報が、提供されることもありえます。 これには、サービスごとに異なる連絡先が含まれたり、 もしくはオンライン情報サービスのリストであることがありえます。 何らかのサービスへのアクセスに特定の手続きがある場合 (例:メーリングリストの要求に対応する場合)、 それらはここで説明される必要があります。

3.3 憲章 English

各CSIRTは、何を行おうとしているのか、 何のオーソリティのもとにそれを行うのかを規定する憲章をもたねばなりません。 この憲章は、少なくとも下記の要素を含む必要があります。:

3.3.1 使命の表明 English

使命の表明は、 CSIRTの規定によって既に開始されているチームの核となる活動に焦点を当てる必要があります。 CSIRTとしてみなされるためには、そのチームは、 インシデントの報告をサポートし、 インシデントを扱うことによってその構成員をサポートしなければなりません。

チームの目標と目的は、特に重要であり、 明確で曖昧さのない規定が求めれられます。

3.3.2 構成員 English

CSIRTの構成員は、 いくつかあるやり方のどのようにでも決めることができます。 例えば、それは会社の従業員、 あるいは会費を払った会員である可能性があり、また、 特定のオペレーティング・システムのユーザのように技術的な観点から定めることもありえます。

構成員の定義は、 誰にそのチームはサービスを提供するのかに関してグループの周囲に境界を作る必要があります。 この文書のポリシーの章(後述)では、 この境界の外部からの要求がどのように扱われるかが説明される必要があります。

CSIRTがその構成員を開示しないことを決定した場合、 この決定の背後にある理由付けを説明する必要があります。 例えば、有償のCSIRTは、彼らの顧客を掲載しないかもしれませんが、 数多くの顧客に対して顧客の契約により秘密に保たれているサービスを提供していることを宣言することでしょう。

ISPがCSIRTを提供する場合、 CSIRTを持った顧客サイトにもサービスを提供するので構成員は重複している可能性があります。 CSIRTの記載(後述)のオーソリティの章は、 そのような関係を明確にする必要があります。

3.3.3 スポンサー組織/組織間関係 English

CSIRTの活動をオーソライズするスポンサー組織が次に掲げられる必要があります。 これを知っておくことは、CSIRTの背景と設立を理解することを助け、 構成員とCSIRT間の信頼を築くための決定的な情報です。

3.3.4 オーソリティ English

この節は、そのチームと、その構成員の間の関係に基づいて、 各CSIRTごとに大きく異なります。 組織体のCSIRTは、そのオーソリティを、 その組織体の経営管理者によって与えられることでしょうが、 コミュニティのCSIRTは通常、 アドバイザリーの役割を果たすことをそのコミュニティによって支持、 選択されます。

CSIRTは、 その境界内のすべてのシステムの運用において介在するオーソリティを持っている場合もあれば、 無い場合もあります。 それは、その構成員の境界で区別される、 そのコントロールの範囲を識別する必要があります。 他のCSIRTが、その境界内で階層的に運用する場合には、 これはここに記述され、関連するCSIRTが識別される必要があます。

チームのオーソリティの開示は、 自身を義務としての要求にさらすことになるでしょう。 各チームは、このような事柄については法的な助言を仰ぐ必要があります。 (義務についての詳細は、 3.7をご覧ください。)

3.4 ポリシー English

CSIRT自身のポリシーを定めることが極めて重要です。 以降の章では、 このようなポリシーの構成員コミュニティとのコミュニケーションを検討します。

3.4.1 インシデントの種類とサポートのレベル English

そのチームが対応することができるイシデントの種類と、 各種のインシデントに対応するときにそのチームが提供するサポートのレベルは、 一覧形式でここに示される必要があります。 サービスの章(後述)では、より詳細な記述を与える機会を提供し、 インシデントに関連しない話題に対応します。

サポートのレベルは、チームの仕事量や、 入手可能な情報の完全性のような要素によって変化することでしょう。 このような要素は、概略が述べられる必要があり、 それらの影響が説明される必要があります。 既知の種類のインシデントについてのリストが、潜在的な、 もしくは将来のインシデントに関して不完全であるのと同様に、 CSIRTは、さもなければ言及されることのない種類のインシデントに対する「デフォルト」サポートについて、 何らかの背景を提供する必要もあります。

そのチームは、 彼らが受け取る将来のインシデントの可能性を作り出す脆弱性の情報について、 行動を起こすか否かについて表明する必要があります。 そのコミュニティの代わりにそのような情報についての行動に参画することは、 CSIRTの核となるサービス要件ではなく、 オプションの予防的サービスポリシーとみなされます。

3.4.2 協力、相互関係、情報の開示 English

この章では、どの関係グループとそのCSIRTは、 規則的に相互関係をもっているかを明確にする必要があります。 そのような相互関係は、 発生するコンピュータセキュリティインシデント対応に関しては不要ですが、 技術的な話題、 もしくはサービスについてのより良い協力関係を促進するのに使用されます。 決して協力関係の契約の詳細が記載される必要はありません。 ;この章の主たる目的は、その構成員に、 どのような種類の相互関係が確立されて、 それらの目的が何であるかについての基本的理解を与えることです。

CSIRT間のコーディネーションは、 明確な引継ぎ手続きと組み合わされた固有のチケット番号割り当ての利用によって促進される可能性があります。 これによって、インシデント追跡における誤解の可能性、 努力や支援の重複が減少し、 コミュニケーションにおける「抜け穴」を防ぎます。

報告と開示のポリシーは、各状況下において、 誰がCSIRTの報告の受取人となるかを明確にする必要があります。 そのチームが他のCSIRT経由で運用することを予定しているのか、 あるいは他の構成員のメンバーと直接、 そのメンバーに個別的に関係のある事項について運用することを予定しているのかを明記しておく必要もあります。

CSIRTが相互関係をもつ関連グループを次に示します。:

インシデント対応チーム:
CSIRTは、しばしば他のCSIRTと相互関係をもつ必要があります。 例えば、大企業内のCSIRTは、 インシデントを国レベルのCSIRTに報告する必要があるかもしれませんし、 国レベルのCSIRTは、 大規模な攻撃に巻き込まれたすべてのサイトを扱うために、 外国の国レベルのCSIRTにインシデントを報告する必要があるかもしれません。 CSIRT間の協力関係は、情報開示されます。 下記のものは、そのような開示の例ですが、 完全なリストを意図したものではありません。:
ベンダー:
ベンダーには自前のCSIRTをもっているところがありますが、 もっていないベンダーもあります。 そのような場合、CSIRTは、その技術的な問題を分析したり、 もしくは提供された解消法をテストするように、 改善もしくは修正を提案したり、ベンダーとともに直接、 働く必要があるでしょう。 ベンダーは、インシデントを扱う際に、自社製品の脆弱性が、 そのインシデントに関係している場合には特別な役割を演じます。
法執行機関団体:
これには、警察や他の捜査機関が含まれます。 CSIRTやテンプレートのユーザは、 国ごとに相当に異なるであろう現地の法規や規制に敏感である必要があります。 CSIRTによっては、攻撃の技術的な詳細をアドバイスしたり、 もしくはインシデントの法的な示唆についてのアドバイスを求めるかもしれません。 現地の法規や規制には、特定の報告要件や、 守秘の要件が含まれる可能性があります。
報道関係者:
CSIRTには、 報道関係者がひっきりなしに情報やコメントを求めてアプローチしてきます。 報道機関に対する開示に関する明確なポリシーは、 有用である可能性があります。 特にCSIRTの構成員の期待を明確にする際にはいえます。 報道ポリシーは、上記と同様の話題について、 より具体的に明確化する必要があるでしょう。 それは、構成員は通常、報道機関との接触に非常に敏感であるからです。
その他:
調査活動、もしくはそのスポンサー組織との関係が含まれます。

チームが受け取る、いかなる、 すべてのセキュリティ関連の情報のデフォルトの位置付けは、 通常「秘密」扱いです。 しかし、厳密なこれについての固執は、 そのチームが情報の「ブラックホール」に見えるようにしてしまいます。 これは、そのチームがクライアントや他の組織から得られる協力の可能性を減らしてしまう可能性があります。 CSIRTのテンプレートは、どの情報を、誰に、 いつ報告ないし開示するかを定義する必要があります。

チームが異なれば、開示を要求したり規制する、 異なる法的規制の対象となることがよくあります。 特に異なる司法管轄権で働いている場合にいえます。 さらに、チームは彼らのスポンサー組織によって提起される報告要件を持っているかもしれません。 各チームのテンプレートは、ユーザの期待を明確化する目的と、 他のチームに知らせる目的の両方のために、いかなる、 そのような制約を規定する必要があります。

利益のコンフリクト、特に商業的な事項も、 チームによる開示を制約する可能性があります。; この文書は、そのようなコンフリクトがどのように対応される必要があるかについて推奨するものではありません。

チームは、通常、統計情報を集めます。 統計情報が配布されている場合、 そのテンプレートの報告と開示のポリシーには、 そのように書かれる必要があり、 そのような統計情報を入手する方法を記述する必要があります。

3.4.3 コミュニケーションと認証 English

あなたが使用するセキュアで検証可能なコミュニケーション手段を記述するポリシーを持たねばなりません。 これは、CSIRT間と、CSIRTとその構成員間のコミュニケーションに必須です。 テンプレートには、公開鍵、もしくはそれらへのポインターが、 鍵のフィンガープリントを含めて含まれている必要があります。 これには、真正性をチェックするためにこの情報の使う方法と、 壊れた情報の扱い方(例えば、 どこにこれを報告するか)についてのガイドラインが伴っている必要があります。

現時点では、最低限、 各CSIRTが(可能であれば)PGP鍵を入手可能にすることが推奨されます。 チームによっては、自身のニーズや、その構成員のニーズに従って、 他の機構(例:PEM、MOSS、S/MIME)も利用可能にするかもしれません。 しかし、CSIRTやユーザは、 現地の法や規制に敏感である必要があることを覚えておいてください。 国によっては強い暗号を許していなかったり、 または暗号技術の利用にあったって特定のポリシーが強制されています。 取り扱いに注意を要する情報を、 暗号化可能な限り暗号化することに加えて、 書簡がデジタル署名を含んでいる必要があります。 (大部分の国においては、デジタル署名による真正性の保護は、 既存の暗号規制によって影響を受けないことを覚えておいてください。)

電話もしくはファクシミリによるコミュニケーションのために、 CSIRTは、扱う主体のために、 合意されたパスフレーズのような秘密の認証データを保持するかもしれません。 明らかに、そのような秘密鍵は、存在していようとも公表してはなりません。

3.5 サービス English

CSIRTによって提供されるサービスは、 大雑把に2つのカテゴリに分類することができます。 :インシデント対応の主な仕事に直接関わるリアルタイムの活動と、 インシデント対応の仕事を支援するリアルタイムでない予防的な活動です。 2番目の分野と、最初の分野の部分が、 必ずしもすべてのCSIRTがそれらを提供するわけではないという観点からは、 オプションのサービスを構成しています。

3.5.1 インシデント対応 English

インシデント対応には、通常、 インシデントについて届けられる報告の評価(「インシデントトリアージ」)、 それらについて他のCSIRT、 ISPやサイトとのフォローアップ(インシデントコーディネーション)が含まれます。 3番目の領域のサービスであるローカルサイトのインシデントからの復旧の補助(「インシデント復旧」)は、 必ずしもすべてのCSIRTが提供するわけではない、 典型的なオプションのサービスに含まれています。

3.5.1.1 インシデントトリアージ

インシデントトリアージには通常、次のことが含まれます。:

- 報告の分析 届けられるインシデント報告の解釈、 それらのプライオリティ付けと、 進行中のインシデントや趨勢との関連付け。
- 証明(Verification) インシデントが本当に起きているかの判断とその範囲の判断を補助する。
3.5.1.2 インシデントコーディネーション

インシデントコーディネーションには、通常、次のことが含まれます。:

- 情報分類 インシデント関連情報(ログファイル、 連絡先、等)の分類。情報開示ポリシーに準拠してなされます。
- コーディネーション 情報開示ポリシーに従い、必要に応じて関連する他の主体に通知する。
3.5.1.3 インシデント解決

通常、追加的、オプションのインシデント解決サービスには、 次のことが含まれます。:

- 技術的な支援 これには、被害を受けたシステムの分析が含まれる。
- 根絶 セキュリティインシデントの原因(攻略された脆弱性)と、 その影響(例えば、システムへの侵入者による継続的なアクセス)を根絶する。
- 復旧 セキュリティインシデント前の状態に影響を受けたシステムやサービスを復旧することを追加する。

3.5.2. 予防的な活動 English

通常、追加的もしくはオプションの予防的サービスには、次のことが含まれます。:

- 情報提供 これには既知の脆弱性のアーカイブ、 過去の問題のパッチもしくは解消法、 またはアドバイザリーメーリングリストが含まれる可能性がある。
- セキュリティツール これには、 サイトのセキュリティを監査するためのツールが含まれる可能性がある。
- 教育と訓練
- 製品評価
- サイトセキュリティ監査とコンサルティング

3.6 インシデント報告の様式 English

報告様式の利用は、ユーザとチームの双方にとってインシデントの扱いを、 より単純にします。 構成員は、実際にチームに連絡する前に、 様々な重要な質問に対する答を準備することができるので、 よく備えることができます。 そのチームは、 最初の報告で一度にすべての必要な情報を得ることができるので、 効果的に処理することができます。

特定のCSIRTの目的やサービスに応じて、 複数の様式が使用される可能性があり、例えば、 新しい脆弱性の報告のための様式は、 インシデント報告に使用される様式とは相当に異なることでしょう。

そのチームのオンラインの情報サービスを通じて様式を提供するのが最も効率的です。 それらへの正確なポインターは、適切な使用法についての表明と、何時、 どのようにその様式を使うかのガイドラインとともにCSIRT概要の文書中に掲載される必要があります。 独立した電子メールアドレスが、 様式に基づいた報告においてサポートされている場合、 それらもここに掲載される必要があります。

そのような様式の一例は、 CERT/CCによって提供されているIncident Reporting Form です。:

3.7 免責について English

CSIRTの記述文書は、契約を構成するものではありませんが、義務は、 おそらくそのサービスや目的の記述によることでしょう。 それゆえ、免責についてをテンプレートの末尾に含めることが推奨され、 制限の可能性についてユーザに警告する必要があります。

文書の原文が他の言語に翻訳されなければならない状況においては、 その翻訳は免責についての記述を掲載し、 原文へのポインターを掲載する必要があります。 例:

我々は注意深く原文書をドイツ語から英語に翻訳することを試みましたが、 双方の文書が同一の考えを同程度の詳細さと正確さで表現していることに確信をもつことはできません。 双方のバージョンに差異があるいかなる場合においても、 ドイツ語版が優先されます。

免責についての記述による保護の使用は、 各CSIRTが認識している必要がある現地の法や規制によって影響を受けます。 迷う場合には、そのCSIRTは法律家に免責について確認する必要があります。


補遺 A: 用語の小辞典 English

この小辞典は、 セキュリティインシデントやコンピュータセキュリティインシデント対応チームを記述する際に使用される用語を定義します。 限られたリストが含められています。 より他のの定義については、例えば Internet User's Glossary [RFC 1983] のような他の情報をご覧ください。

Constituency(構成員):
コンピュータセキュリティインシデント対応チームの目的における暗黙の了解は、 構成員の存在です。 これは、ユーザ、サイト、ネットワークもしくは、 彼らによって働く組織体のグループです。 チームは、効果的であるよう、 その構成員によって認知されなければなりません。
Security Incident(セキュリティインシデント):
本書の目的において、この用語は、 コンピュータセキュリティインシデントと同意語です。 : コンピュータもしくはネットワークのセキュリティの何らかの観点を犯す、 あらゆる有害なイベント。

インシデントの定義は、組織体間で様々である可能性がありますが、 少なくとも次の分類は、一般に適用可能です。:

これらは、非常に一般的な分類です。 例えば、トロイの木馬によるシステムユーティリティの置き換えは、 「インテグリティの侵害」の一例であり、パスワード攻撃の成功は、 「守秘性の喪失」の一例です。

攻撃は、たとえ正しい防護によって失敗しても、 インシデントとみなされる可能性があります。

インシデントの定義において、 「侵害(compromised)」という単語が使われます。 しばしば、管理者は、 インシデントの「疑い」だけをもつ可能性があります。 対応において、 インシデントが現実に発生したのか否かを確立しなければなりません。

Computer Security Incident Response Team (CSIRT:コンピュータセキュリティインシデント対応チーム):
上記で与えられた2つの定義に基づき、CSIRTは、 規定された構成員中のサイトを巻き込むセキュリティインシデントへの対応をコーディネートし支援するチームです。

CSIRT とみなされるためには、チームは、:

我々は、ここで警察、 もしくは他のコンピュータ犯罪を捜査する可能性がある法執行機関を指していないことに注意してください。 CSIRTメンバーは、まさに、 通常の市民の力以上のいかなる力も持つ必要がありません。

Vendor(ベンダー):
「ベンダー」は、 ネットワーキングもしくはコンピューティングのテクノロジーを製作するあらゆる主体であり、 そのテクノロジーの技術的な内容に責任があります。 「テクノロジー」の例は、 ハードウェア(デスクトップコンピュータ、ルーター、 スイッチ等)とソフトウェア(オペレーティングシステム、 メール転送システム等)を含みます。

テクノロジーの供給者が必ずしも、 そのテクノロジーの「ベンダー」ではないことに注意してください。 一例として、インターネットサービスプロバイダー(ISP)は、 その各顧客にルーターを提供する可能性がありますが、 「ベンダー」は、製造者であり、製造者ゆえ、 ISPではなく、そのルーターの技術的な内容に責任ある主体です。

Vulnerability(脆弱性):
「脆弱性」は、 セキュリティインシデントを犯すために攻略することができるテクノロジーの一端の性格です。 例えば、あるプログラムが、意図せずに、 通常のユーザが勝手にオペレーティングシステムコマンドを特権モードで実行することを許した場合、 この「失敗」は、脆弱性といえます。

補遺 B: 関連資料 English

サイトレベルにおいて、 セキュリティインシデントに対応する際の重要な論点は、 サイトセキュリティワーキンググループによって作成された「サイトセキュリティハンドブック(SSH)」 [RFC 2196] に含まれています。 本書は、SSHワーキングによって改訂され、 主にセキュリティインシデントの回避に関するローカルポリシーと手順についての推奨事項を提供するでしょう。

CSIRTとそのタスクの検討に関する他の文書は、 anonymous FTPによって入手可能です。 コレクションは、こちらにあります。:

本書に関連するいくつかの特別に興味深い文書は、次のとおり。:


補遺 C: 既知のコンピュタセキュリティインシデント対応チーム English

今日、多くの異なる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 予防的活動

6. インシデント報告フォーム

7. 免責事項


補遺 E: 例:あるCSIRTのために「埋められた」テンプレート English

下記は、 「XYZ-CSIRT」と呼ばれる架空のCSIRTのために埋められたテンプレートの例です。 本文は、例示目的にすぎず、 ワーキンググループもしくはIETFによる、 いかなる特定の手順もしくはポリシーの推奨をも構成するものではありません。 CSIRTが本文のいかなる部分もしくは全部を使用することを望む場合、 歓迎しますが、このような利用は、当然ながら強制ではなく、あるいは、 多くの場合、適切でさえありません。

XYZ-CERT のための CSIRT 記述

1. 本書について

1.1 最終更新日

This is version 1.01, published 1997/03/31.

1.2 通知のための配布リスト

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.

1.3 本書がある場所

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.

1.4 本書のアーカイビング

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

2. 連絡策情報

2.1 チームの名前

"XYZ-CERT": the XYZ University Computer Emergency Response Team.

2.2 所在地

XYZ-CERT
XYZ University, Computing Services Department
12345 Rue Principale
UniversityTown, Quebec
Canada H0H 0H0

2.3 時間帯

Canada/Eastern (GMT-0500, and GMT-0400 from April to October)

2.4 電話番号

+1 234 567 7890 (ask for the XYZ-CERT)

2.5 ファクシミリ番号

+1 234 567 7899 (this is *not* a secure fax)

2.6 他のコミュニケーション

None available.

2.7 電子メールアドレス

<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail to the human(s) on duty for the XYZ-CERT.

2.8 公開鍵と他の暗号化情報

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.

2.9 チームメンバー

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.

2.10 他の情報

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

2.11 顧客連絡先

The preferred method for contacting the XYZ-CERT is via e-mail at &ltxyz-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.

3. 憲章

3.1 使命表明

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.

3.2 構成員

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.

3.3 スポンサーシップ、かつ/または提携

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.

3.4 オーソリティ

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).

4. ポリシー

4.1 インシデントの種類とサポートのレベル

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.

4.2 協力、相互活動および情報の開示

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:

Potential recipients of information from the XYZ-CERT will be classified as follows:

4.3 コミュニケーションと本人認証

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).

5. サービス

5.1 インシデント対応

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:

5.1.1 インシデントトリアージ

5.1.2 インシデントコーディネーション

5.1.3 インシデント解決

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.

5.2 予防的活動

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.

6. インシデント報告フォーム

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

7. 免責事項

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.


4 謝辞 English

著者一同は、Anne Bennett氏の提供してくださった原稿と、編集、 校正に大変感謝しています。 インシデント対応チームサービスの記述を推敲するのを支援してくださった Don Stikvoort氏にも感謝します。

5 参考文献

[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月.

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

本書は、CSIRTの運営と、 チームの彼らの構成員や他の組織体との相互関係を検討しています。 それゆえ、プロトコル、 アプリケーションもしくはネットワークシステム自体のセキュリティに、 直接関連するものではありません。 さらに、特定の対応や、 セキュリティインシデントに対する対応に関するものではありませんが、 CSIRTによって提供される対応についての適切な記述に関するものです。

それでもなお、CSIRT自身がセキュアに運営されることが決定的に重要です。 これは、他のチームや構成員のメンバーとセキュアなコミュニケーションチャネルを確立しなければならないことを意味します。 彼らは、その構成員の利益を保護し、 被害者やセキュリティインシデントの報告者の識別情報の守秘性を維持するために、 自身のシステムやインフラストラクチャもセキュアにしなければなりません。

7 著者のアドレス

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

8 著作権表記全文

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.