【実務・中級編】 インシデント対応における法的証拠保全（Chain of Custody）の管理 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

証拠は「奪う」ものではなく「守り抜く」ものだ ― メモリフォレンジックにおけるChain of Custodyの鉄則

現場でインシデントが発生した時、焦って電源を落としたり、とりあえずログをコピーしたりしていないか？ もし君が「証拠さえあれば何とかなる」と思っているなら、それは大きな間違いだ。法廷や第三者委員会にその証拠を突きつける時、相手は技術的な内容以前に「その証拠が改ざんされていないこと」を証明しろと迫ってくる。

これが「証拠保全の連続性（Chain of Custody）」だ。今回は、ただメモリをダンプするだけでなく、それが法的に価値ある証拠として認められるための「泥臭い管理術」を伝授する。

なぜメモリダンプが「ただのデータ」に成り下がるのか

攻撃者は、メモリ上にのみ存在する「ファイルレスマルウェア」や、難読化されたPowerShellスクリプトを好む。これらを解析するにはメモリダンプが必須だが、取得の瞬間にタイムスタンプが書き換わったり、解析者が意図せずデータを上書きしたりすれば、その証拠は裁判で「証拠能力なし」と却下される。

「誰が、いつ、どこで、どのツールを使って取得し、どう保管したか」。このプロセスを厳格に管理できていない証拠は、ただのゴミと同義だ。

証拠保全の「鉄の掟」：実務における管理フロー

1. 取得者・ツールの記録: 誰が実行したか。使用したツール（DumpItやMagnet RAM Capture等）のバージョンとハッシュ値は何か。
2. ハッシュ値による完全性の担保: 取得した瞬間に SHA-256 以上のハッシュ値を生成し、ログに記録する。
3. 封印と追跡: 取得したメディアは物理的に封印し、アクセスした人間をすべて記録する（アクセスログと物理ログの照合）。

技術的アプローチ：Pythonによる「自動保全ログ記録スクリプト」

手作業でメモを取る時代は終わった。証拠保全を行う際、実行環境のメタデータと取得物のハッシュ値を自動的に記録するツールを介在させるのが、現代のDFIRエンジニアの基本だ。

以下は、メモリイメージをコピーし、同時にSHA-256ハッシュを生成して監査ログに記録するPythonの簡易スニペットだ。

import hashlib
import shutil
import logging
from datetime import datetime

# 監査ログの設定（改ざん防止のため、追記専用の別サーバーへ転送推奨）
logging.basicConfig(filename='evidence_log.txt', level=logging.INFO)

def secure_copy_and_hash(source_path, dest_path):
    # 取得開始のタイムスタンプ
    start_time = datetime.now().isoformat()
    
    # ハッシュ生成用オブジェクト
    sha256 = hashlib.sha256()
    
    with open(source_path, 'rb') as f_src, open(dest_path, 'wb') as f_dst:
        while chunk := f_src.read(8192):
            sha256.update(chunk)
            f_dst.write(chunk)
            
    hash_value = sha256.hexdigest()
    
    # 記録を残す（これがChain of Custodyの一部となる）
    log_entry = f"[{start_time}] File: {dest_path} | Hash: {hash_value} | Operator: SystemAdmin"
    logging.info(log_entry)
    print(f"証拠保全完了: {hash_value}")

# 使用例
# secure_copy_and_hash('captured_memory.raw', '/secure_vault/evidence_001.raw')

インフラ層での防御：そもそも「証拠」を残させないために

攻撃者がメモリを悪用するのは、ディスクに痕跡を残さないためだ。しかし、現代のクラウドインフラ（AWS/GCP/Azure）であれば、メモリ保護機能やカーネルレベルの防御を実装することで、攻撃の難易度を跳ね上げられる。

Nginx/WAFでの「攻撃の芽」を摘む設定

メモリフォレンジックに頼らざるを得ない事態を防ぐには、入口での防御が全てだ。例えば、Webアプリケーションの脆弱性を突いたメモリ展開を防ぐため、WAFでリクエストを厳格に制限しよう。

# Nginx 設定例：不正なペイロードをメモリに乗せないためのヘッダー強化
server {
    # XSSによるメモリへの悪意あるスクリプト注入を防ぐ
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";
    
    # バッファオーバーフローを狙った巨大なリクエストを拒否
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    client_max_body_size 1m;
    large_client_header_buffers 2 1k;
}

後輩エンジニアへ：教訓

「証拠保全」は、技術的なスキルの高さよりも、「手順への忠実さ」が問われる。どれだけ美しい解析コードが書けても、Chain of Custodyが崩れていれば、その結果は法廷で使えない。

1. ツールを信じるな: 取得ツール自体が侵害されていないか常に疑え。
2. ハッシュを信じろ: データの同一性は常に計算で証明せよ。
3. 記録を止めない: どんな些細なオペレーションも、必ずログに残せ。

インシデントの最前線で動く君たちが、証拠をただの「データ」で終わらせず、真実を語る「証拠」として扱えるようになることを期待している。さあ、次は君が現場の責任者だ。

スポンサーリンク

コメント

タイトルとURLをコピーしました