RFC 3227「Guidelines for Evidence Collection and Archiving (証拠収集とアーカイビングのためのガイドライン) 」の簡単なまとめです。 デジタル・フォレンジックの内容でもあります。
https://tools.ietf.org/html/rfc3227
概要
RFC 2828「インターネットセキュリティ用語集」で定義されている「セキュリティインシデント」とは、 セキュリティポリシーに違反するシステムの事象のことです。 この文書の目的は、セキュリティインシデントに関する証拠収集とアーカイビングのためのガイドラインを、 システム管理者に提供する事です。 適切な証拠収集は攻撃者の逮捕に繋がり、起訴の際に裁判で有利な証拠になるでしょう。
2. 証拠収集の原則
- サイトのセキュリティポリシーを遵守し、 適切なインシデント対応の担当者と法務要員を充てます。
- 可能な限り正確なシステムの状況を記録します。
- 詳細なメモを保管します。これには日付と時刻も含めます。 もし可能であれば自動で作業ログを作成します （Unixでは「script」コマンドが使えますが、それを証拠の一つにしてはいけません）。 メモとそれを印刷したものには署名と日付を記入します。
- システムの時刻とUTC間の時差に注意します。 それぞれのタイムスタンプについて、UTCまたは現地時間のどちらを使用されているかを示します。
- （数年後の自分のために） あなたが取ったすべての行動の概要とその時刻の証言できる準備をしましょう。 詳細なメモは極めて重要です。
- データを収集する際は、その変更を最小限にします。 これは内容の変更に限らず、ファイルの更新やディレクトリへのアクセス時間の変更も避ける必要があります。
- ネットワークと接続する手段を削除します（遠隔操作による証拠隠滅を防ぐため）
- 収集と分析のどちらかを選択しなければならない場面では、収集を優先し、分析を後回しにします。
- 言うまでもなく、証拠収集の手順は実装可能であること。 インシデント対応のあらゆる局面において、 実行可能性を確実にするために証拠収集の手順（プロシージャ）はテストされる必要があります。 可能であれば、速度と正確性から証拠収集は自動化されるべきです。
- 各デバイスについて、証拠収集の手順を策定したガイドラインに従った方法論的手法が採用されるべきです。 速度は重要なので検査しなければならないデバイスが複数あるときに、 並列で証拠収集をチーム内で分担させるのが適切です。 しかし、それぞれのシステムについて、証拠収集は段階を踏んで行うべきです。
- 揮発性の高いものから揮発性の低いものへ順番に証拠収集の作業を進めていきます（揮発性の順番を参照）。
- ビットレベルでのメディアの複製を作るべきです。 もしフォレンジック解析をしたい場合、解析によりファイルアクセス時刻をほぼ確実に変更してしまうので、 証拠資料のビットレベルの複製を作るべきです。 証拠資料をフォレンジック解析するのは避けましょう。
2.1. 揮発性の順番
証拠収集においては、揮発性の高いデータや保存期間の短いものから収集していきます。 揮発性の高い順に並べると以下の通りです。
- レジスタ、キャッシュ
- ルーティングテーブル、arpキャッシュ、プロセステーブル、カーネル統計、メモリ
- 一時ファイルシステム（/tmp）
- ディスク
- 当該システムに関連する遠隔操作ログと監視データ
- 物理的設定、ネットワークトポロジ
- アーカイブ用メディア
2.2. 避けるべき事項
証拠の破壊は簡単です。たとえ、それが不注意だとしても。
- 証拠収集が完了するまでシャットダウンしてはいけません。 多くの証拠が失われ、攻撃者が証拠隠滅のためにスタートアップやシャットダウンの時に動くスクリプトやサービスを書き換えて証拠を破壊させるかもしれないからです。
- システム上のプログラムを信頼してはいけません。 適切に保護されたメディアから証拠収集プログラムを実行します（詳細下記参照）。
- システム上のファイルの変更時刻やアクセス時刻を変更するプログラムを実行してはいけません （例えば tar や xcopy コマンド）。
- 単にネットワークから隔離した際に、 ネットワークと接続されていないことを検知して証拠を削除する「死人のスイッチ（Deadman switch）」に注意してください。
2.3. プライバシーについての考慮事項
- 会社と法律のプライバシーについてのルールとガイドラインを尊重すること。 特に、証拠と共に収集された情報は通常ではアクセスできないことに気をつけてください。 これには個人情報と同様に（ユーザの行動パターンを明らかにする可能性のある）ログファイルも含まれています。
- 強い司法権なしに、人々のプライバシーを侵害してはいけません。 特に、実際にインシデントが起きているという十分な根拠がない限り、 （個人的なファイルストレージのような）普段アクセスする理由がない領域から情報を収集してはいけません。
- インシデントの証拠を収集する段階において、 自身の会社が保証している証拠収集手順に従っていることを確認してください。
2.4. 法的な考慮事項
デジタルの証拠には、次のことが必要とされます。
- 正当性：裁判所に提出する前に、法律に従わなければなりません
- 真正性：インシデントと証拠資料を結びつけることが可能でなければなりません
- 完全性：特定の観点だけでなく、事の全体を伝えなければなりません
- 依拠可能性：どのように証拠が収集され、どう扱われたかについて、その真正性と真実性についての疑いを招くことがあってはなりません
- 信用可能性：法廷ですぐに信用可能であり、理解可能でなければならない
3. 証拠収集手順
収集手順は可能な限り詳細に書くべきです。 インシデント対応手順と同様に、収集手順は明確にすることで、 収集中における意思決定の量を最小限に抑えるべきです。
3.1. 透明性
証拠を集めるために実施した方法は、透明で再現可能であるべきです。 自分が実施した方法を正確に再現する用意ができていて、 それらの方法は独立した専門家によってテストされるべきです。
3.2. 証拠収集の手順
- 証拠はどこにあるか？ どのシステムがインシデントに関連しているか、またどの証拠から収集されるかをリストします。
- 関連性があり裁判で採用される証拠を明確にします。 疑問がある場合は、十分といえるまで証拠を収集します。
- 各システムについて、適切な揮発性の順番を選びます。
- ネットワークと接続する手段を削除します（遠隔操作による証拠隠滅を防ぐため）
- 揮発性の順に従って、第5章で検討するツールを使って証拠を収集します。
- システム時刻のずれの程度を記録します。
- 証拠収集しながら、他に証拠になりそうなものがないか疑います。
- 各段階について文書化します。
- 収集に関わった人の記名を忘れずに。 収集には誰がいて何をしたか、何を観測してどう対応したか、を文書にまとめます。
実現可能であれば、文書のチェックサムを生成し、暗号技術による署名を検討すべきです。 これは証拠の強い連鎖を保つことをより簡単にします。 その結果、証拠は改竄できなくなります。
4. アーカイビングの手順
証拠は厳重に保管しなければなりません。 さらに、証拠保全（裁判などに用いる証拠の確保）は明確に文書化される必要があります。
4.1. 証拠保全
証拠がどのように発見されたか、どう扱われた、それについて発生したことの全てについて、 明確に記述することができるはずです。
以下の項目は文書化する必要があります。
- いつ、どこで、誰が証拠を発見・収集したか。
- いつ、どこで、誰が証拠を扱い、検査したか。
- いつまでの期間に、誰が証拠を保護するのか。どのように保管されたか。
- いつ、証拠の管理者を変更したか。いつ、どのように証拠を転送・移動したか（追跡情報などを含む）
4.2. アーカイブする場所と方法
出来るだけ一般的に使われているメディアに保存します。 証拠へのアクセスは厳格に制限され、アクセス権やアクセスの記録は明確に文書化するべきです。 それによって許可されていないアクセスを検知することができます。
5. 必要なツール
証拠収集とフォレンジックに必要なプログラムを、読み取り専用メディア（CD など）上に保存すべきです。 また、それぞれのOSで動作するツールを事前に用意する必要があります。 ツールには以下のものが含まれます。
- プロセスを検査するプログラム（ps）
- システム状態を検査するプログラム（showrev, ifconfig, netstat, arp）
- ビットレベルで複製をするプログラム（dd, SafeBack）
- チェックサムや署名を生成するプログラム（sha1sum, チェックサムが有効なdd, SafeBack, pgp）
- coreファイルのダンプとそれを検査するプログラム（gcore, gdb）
- 自動で証拠収集を行うスクリプト（The Coroner's Toolkit）
これらのプログラムは静的リンクにして、読み取り専用メディア以外のライブラリを利用できないようにします。 このような対策をしても、最近のルートキット（rootkit）は読み込み可能なカーネルモジュールとしてインストールされている可能性があるので、上記のプログラムを使用したときにシステムの状況を正しく収集していない可能性があることに注意する必要があります。
使用するツールの真正性と依拠可能性について証言する準備もすべきです。
参考文献