| ネットワーク WG Request for Comments： 3227 BCP： 55 分類： ベストカレントプラクティス |
D. Brezinski |
証拠収集とアーカイビングのためのガイドライン
(Guidelines for Evidence Collection and Archiving)
このメモの位置づけ
この文書は、インターネットの「現時点における最善の実践（ベストカレントプラクティス）」を示すものであり、改善するために議論と示唆を求めるものです。このメモの配布に制限はありません。
著作権表記
Copyright (C) The Internet Society (2002). All Rights Reserved.
要旨
「インターネットセキュリティ小辞典 (Internet Security Glossary)」において定義されているように、「セキュリティインシデント」とは、「セキュリティ関連のシステムイベントであり、システムのセキュリティポリシーが破壊もしくは突破されるイベント」です。本書の目的は、システム管理者に、このようなセキュリティインシデントに関する証拠の収集とアーカイビングについてのガイドラインを提供することにあります。
証拠収集が適切に行われた場合、攻撃者を逮捕する際に一層有用で、訴訟の際に採用される可能性が高まります。
目次
「インターネットセキュリティ小辞典 (Internet Security Glossary)」 [RFC2828] において定義されているように、「セキュリティインシデント」とは、「セキュリティ関連のシステムイベントであり、システムのセキュリティポリシーが破壊もしくは突破されるイベント」です。本書の目的は、システム管理者に、このようなセキュリティインシデントに関する証拠の収集とアーカイビングについてのガイドラインを提供することにあります。「すべてのシステム管理者が、セキュリティインシデントに直面するたびごとに、これらのガイドラインに忠実に従うべき」と主張することが、我々の意図ではありません。むしろ、我々は、 「システム管理者が侵入に関する情報を収集し防護することを選んだ場合、何をする必要があるか」についての指針を提供することを望んでいます。
このような収集は、システム管理者の役割に相当な苦労をもたらします。近年、OS（オペレーティングシステム）の再インストールを迅速にすること、および「既知」の状態へのシステムの回復を容易にすることについては、大いに進展し、それゆえ、より魅力的な「容易なオプション」をもたらしました。一方、証拠をアーカイブすることの容易なやり方（困難なオプション）を提供することは、あまり進展しませんでした。さらに、増加するディスクとメモリの容量と、攻撃者によるステルス及び痕跡隠喩戦術の一層広範な使用は、この問題を悪化させてきました。
証拠収集が適切に行われた場合、攻撃者を逮捕する際に一層有用で、訴訟の際に採用される可能性が高まります。
あなたは、これらのガイドラインを、あなたのサイトの証拠収集手順を規定するための基礎として利用する必要があり、あなたのサイトの手順を、あなたのインシデント対処文書中に組み込む必要があります。本書中の本ガイドラインは、すべての司法管轄圏において適切であるとは限りません。あなたが、あなたのサイトの証拠収集手順を規定し終えたら、法執行者にそれらが適切であることを確認する必要があります。
本書中のキーワード "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" および "MAY" は、「RFC において要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」 [RFC2119] に記述されているように解釈されるべきものです。
- あなたのサイトのセキュリティポリシーを遵守し、適切なインシデント対処要員と法務要員を充てる。
- 可能である限り正確に、システムの全体像をキャプチャする。
- 詳細なノートをつける。これらは、日付と時間を含む必要がある。可能であれば、自動的に複製を生成する。（例： Unix システムにおいて、「スクリプト」プログラムが、利用可能。ただし、それが生成する出力トファイルは、証拠の部分であるメディアであってはならない。ノートと印刷物には、署名と日付が付される必要がある。
- システム時間と UTC 間の時差をノートする。各タイムスタンプ期間において、UTC 時間もしくは現地時間のいずれかを示す。
- （おそらく数年後に）あなたが行ったすべての行為と、その時刻を概説する証言に備える。詳細なノートは、決定的に重要である。
- データを収集する際に、その変更を最小限にする。これは、内容の変更に限定されない。； ファイル／ディレクトリのアクセス時間を変更することを避ける必要がある。
- 変更するための外部経路を削除する。
- 収集と分析のどちらかを選択しなければならない場面においては、収集を優先し、分析を後にする必要がある。
- ことさら述べるまでもないが、手順は実装可能である必要がある。インシデント対応ポリシーの、あらゆる観点において、特に危機における実行可能性を検証するために手順は、テストされる必要がある。スピードと正確性の理由により、可能であれば、手順は自動化される必要がある。方法論的にせよ。
- 各デバイスについて、あなたの収集手順の中にあるガイドラインに従った方法論的アプローチが採用される必要がある。しばしば、スピードは、決定的に重要であるので、検査しなければならないデバイスが数多くある場合、証拠を平行して収集するために、作業をあなたのチーム内で分担させるのが適切であろう。しかし、各々のシステムについては、収集は段階を踏んで行われなければならない。
- 揮発性の高いものから揮発性の低いものへの順に進行する。（下記の「揮発性の順序」を見よ。）
- システムのメディアのビットレベルの複製を作成する必要がある。法務分析を行いたい場合、そのために証拠資料のビットレベルの複製を作成する必要がある。それは、分析によりファイルアクセス時刻を、ほぼ確実に変更してしまうことによる。証拠資料上で法務分析をすることは避けよ。
証拠を収集する際に、あなたは、揮発性の高いものから揮発性の低いものへの順に進行する必要があります。ここに、典型的システムについての揮発性の一例を示します。
- レジスタ、キャッシュ
- ルーティングテーブル、arp キャッシュ、プロセステーブル、カーネル統計、メモリ
- テンポラリファイルシステム
- ディスク
- 当該システムと関連する遠隔ロギングと監視データ
- 物理的設定、ネットワークトポロジ
- アーカイブ用メディア
証拠を壊すことは、あまりに簡単ですが、逆は困難です。
- 証拠収集 を完了するまでは、シャットダウンしてはならない。多くの証拠が、失われる可能性があり、攻撃者は、証拠を破壊するために、スタートアップ／シャットダウンのスクリプト／サービスを置き換えた可能性がある。
- システム上のプログラムを信頼してはならない。適切に保護されたメディアから証拠収集プログラムを実行せよ。（下を見よ。）
- システム上のあらゆるファイルのアクセス時刻を変更するプログラムは、実行するな。（例： 'tar' または 'xcopy'。）
- 変更するための外部経路を削除する際に、単に接続を絶つこと、もしくはネットワークからフィルタリングすることが、ネットと接続されていないことを検知して証拠を消す「死人のスイッチ」の引き金を引く可能性があることを銘記せよ。
- あなたの会社と司法管轄圏のプライバシーについてのルールとガイドラインを遵守せよ。特に、普段はこの情報へのアクセスを持たない者の誰にでも探している証拠が入手可能である限り、情報が収集されていないことを確認せよ。これは、個人情報とともに、（ユーザ行為のパターンを明らかにする可能性がある）ログファイルへのアクセスを含む。
- 強い司法権なしに、人々のプライバシーを侵害してはならない。特に、本当にインシデントが起きているという十分な根拠を持たない限り、（個人的なファイルストレージのような）普段アクセスする理由をもたない領域から情報を収集してはならない。
- インシデントの証拠を収集するために行う段階において、あなたの会社の確立された手順の支援があることを確認せよ。
コンピュータ証拠には、次の事項が必要とされます。
- 採用可能： 法廷に提出される前に、特定の法的ルーツに適合しなければならない。
- 真正： 積極的に材料をインシデントと証拠論的に結びつけることが可能でなければならない。
- 完全： 特定の観点のみならず、全体像を伝えるものでなければならない。
- 依拠可能： どのように証拠が収集され、扱われたかについて、その真正性と真実性についての疑いを招くことがあってはならない。
- 信用可能： 法廷によってただちに信用可能であり、理解可能でなければならない。
あなたの収集手順は、可能な限り詳細化される必要があります。あなたのインシデント対処手順全般に関する限り、それらは、曖昧でない必要があり、収集手順において必要とされる意思決定の量を最小化する必要があります。
証拠を収集するために使用する手法は、透過的かつ再現可能である必要があります。あなたは、利用した手法を詳細に再現することを備える必要があり、それらの手法を独立の専門家によってテストされる必要があります。
- 証拠は、どこにあるか？どのシステムがインシデントに巻き込まれているか、また、どのシステムから証拠が収集されるかをリストする。
- 何が関連し、また管理可能でありそうかを確立する。失敗が疑われるとき、不足しているのではなく、集めすぎている。
- 各システムについて、関連する揮発性の順序を入手する。
- 変更するための外部経路を削除する。
- 揮発性の順序に従い、第 5 章で検討するルールで証拠を収集する。
- システムの時計のずれの程度を記録する。
- 収集段階を通じて作業する際に、他のものが証拠である可能性を問う。
- 各段階を文書化する。
- 巻き込まれた人を忘れない。誰が居て何をしていたか、何を観察し、どのように反応したか、のノートをつける。
実施可能である場合、あなたは、チェックサムを生成し、収集された証拠に暗号技術的に署名することを検討する必要があります。それは、これにより強い証拠の連鎖を保全することが一層容易になるからです。この際に、証拠を変更してはなりません。
証拠は、厳密にセキュアにしなければなりません。さらに、「カストディの連鎖」は、明確に文書化される必要があります。
あなたは、「どのように証拠が発見されたか」、「どのように扱われたか」および「それについて起きたすべての事項」を明確に記述することができるはずです。
下記事項が、文書化される必要があります。
- どこで／いつ／誰によって、証拠が発見、収集されたか。
- どこで／いつ／誰によって、証拠が対処、検査されたか。
- 誰が証拠のカストディとなり、その期間は。どのように、それは保存されたか。
- いつ、証拠のカストディを変えたか、いつ、どのように転送が行われたか。（送付番号等を含む。）
可能な場合、（あまり使われていない保存メディアではなく）普通に利用されているメディアが、アーカイビングに利用される必要があります。
証拠へのアクセスは、厳格に制限される必要があり、明確に文書化される必要があります。認可されていないアクセスを検知することができる必要があります。
あなたは、証拠収集と法務に必要なプログラムを、読み取り専用メディア（例： CD）上に持つ必要があります。あなたは、利用する前に、 あなたが管理している各 OS（オペレーティングシステム）用のこのようなツールセットを備える必要があります。
あなたのツールセットは、下記のものを含む必要があります。：
- プロセスを検査するためのプログラム（例： 'ps'）
- システム状態を検査するためのプログラム（例： 'showrev'、'ifconfig'、'netstat'、'arp'）
- ビットレベルで複製するためのプログラム（例： 'dd', 'SafeBack'）
- チェックサムと署名を生成するためのプログラム（例： 'sha1sum'、チェックサムを使える'dd'、'SafeBack'、'PGP'）
- core イメージを生成し、それらを検査するためのプログラム（例： 'gcore', 'gdb'）
- 証拠収集を自動化するスクリプト（例： The Coroner's Toolkit [FAR1999]）
あなたのツール中のプログラムは、スタティック（静的）にリンクされている必要があり、読みとり専用メディア上のライブラリ以外のいかなるライブラリの利用を要求するものであってはなりません。これでも、最近のルートキット（rootkit）は、ロード可能なカーネルモジュールとしてインストールされる可能性があるので、あなたは、あなたのツールがシステムの全体像を提供していない可能性があることを考慮する必要があります。
あなたは、あなたが利用するツールの真正性と依拠可能性について証言する準備をする必要があります。
[FAR1999] Farmer, D., and W Venema,
"Computer Forensics Analysis Class Handouts",
http://www.fish.com/forensics/
[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.
[RFC2196] Fraser, B.,
「サイトセキュリティハンドブック (Site Security Handbook)」,
FYI 8, RFC 2196, 1997年 9月.
[RFC2350] Brownlee, N. and E. Guttman,
「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」,
FYI 8, RFC 2350, 1998年 6月.
[RFC2828] Shirey, R.,
「インターネットセキュリティ小辞典 (Internet Security Glossary)」,
FYI 36, RFC 2828, 2000年 5月.
我々は、Harald Alvestrand氏、Byron Collie氏、Barbara Y. Fraser氏、Gordon Lennox氏、Andrew Rees氏、Steve Romig氏および Floyd Short氏から受け取った生産的なコメントに大いに感謝します。
本書全体が、セキュリティ論点を検討しています。
Dominique Brezinski
In-Q-Tel
1000 Wilson Blvd., Ste. 2900
Arlington, VA 22209
USAEMail： dbrezinski＠In-Q-Tel.org
Tom Killalea
Lisi/n na
Bro/n Be/al A/tha na Muice
Co. Mhaigh Eo
IRELAND電話： +1 206 266-2196
EMail： tomk＠neart.org翻訳者のアドレス
宮川 寧夫
情報処理振興事業協会
セキュリティセンターEMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2002). 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 によって提供されています。