インシデント調査報告書、どこを確認すればいい？――JPCERT/CCの「調査報告書チェックリスト」を依頼する側の目線で読み解く

ランサムウェアや不正アクセスの被害にあったとき、多くの企業は外部の調査会社にフォレンジック調査を依頼します。しかし、初めての事故対応で「何を頼めばいいのか」「届いた報告書で十分なのか」を判断するのは簡単ではありません。

JPCERTコーディネーションセンター（JPCERT/CC）は、この悩みに応えるため「インシデント調査報告書チェックリスト」を公開しました（公開の概要はニュース記事「JPCERT/CC、「インシデント調査報告書チェックリスト」を公開」をご覧ください）。この記事では、チェックリストの中身を、調査を依頼する側の目線で読み解きます。

インシデント調査報告書チェックリストとは

チェックリストは、被害を受けた組織（ユーザー）と、調査を担当して報告書を作る側（レポーター）が、調査の進め方について共通認識を持ち、調査を円滑に進めるための補助ツールです。JPCERT/CCは、初めて事故に対応する組織では、調査会社など外部による調査の妥当性の評価や、事故がいつ収束したと判断するかに迷うことがあったと説明しています。

チェックリストはHTMLとMarkdownで公開され、ライセンスは「クリエイティブ・コモンズ 表示・継承 4.0（CC BY-SA 4.0）」です。自社の手順書に合わせて改変して使うこともできます。作成にあたっては、国内のセキュリティ企業14社が協力しています。

利用にあたっては、次の2点に注意が必要です。

• 報告書の正しさを保証するものではない：チェックリストは、依頼時の合意事項と、報告書を受け取ったときに最低限確認すべき事項を整理するものです。調査の技術的な品質や、証拠の妥当性の精査には専門知識が必要で、懸念がある場合はJPCERT/CCなどの専門機関への相談が勧められています。
• 主な対象はネットワーク侵害：マルウェア感染などを伴うネットワーク侵害を想定しており、内部不正が疑われる事案では当てはまらない項目があります。

調査を依頼する前に合意しておく10項目

ユーザー向けチェックリストの前半は、調査を始める前に調査会社と合意しておくべき事項です。事故の直後は慌ただしく、口頭のやり取りだけで調査が始まりがちですが、ここを曖昧にすると、後で「欲しかった答えが報告書に書かれていない」という事態になります。

特に押さえたい3つのポイント

1つ目は「侵入経路や情報漏えいの有無は、特定できないことがある」という前提です。チェックリストは、証拠が足りないために特定できない可能性があると明記しています。依頼の段階で「何が判断できない可能性があるか」の説明を受けておけば、報告書で「判断できない」と書かれても、その理由と影響を正しく受け止められます。

2つ目は「復旧」と「調査」のトレードオフです。早く業務を再開したいあまりサーバーを初期化すると、侵入の痕跡も消えてしまいます。どちらを優先するかは、業務への影響、証拠の保全への影響、調査期間の説明を受けたうえで、経営として判断します。

3つ目は報告書の「使い道」です。個人情報保護委員会への報告、サイバー保険の請求、取引先や親会社への説明などに使う可能性があるなら、最初にそれを調査会社へ伝えておきます。用途によって、必要な記載や第三者に渡してよい範囲が変わるためです。

報告書を受け取ったら確認する9項目

チェックリストの後半は、届いた報告書のレビュー項目です。技術的に正しいかを判定するのではなく、「依頼したことに答えているか」「根拠をたどれるか」を確認するためのものなので、専門家でなくても使えます。

このほか、依頼していれば封じ込め・復旧の提案、再発防止策、攻撃の痕跡（IoC）、脅威インテリジェンス調査についても確認項目があります。再発防止策では「一般的な推奨事項だけでなく、この事案で確認された内容に基づく対策が含まれているか」を見ます。どの会社にも当てはまる対策の羅列になっていないかは、依頼側でも判断しやすいポイントです。IoCは、報告書とは別にテキストやExcelで受け取ると、監視や検索にそのまま使いやすくなるとしています。

「確認できた」「可能性がある」「判断できない」を区別する

詳細確認ポイントの中で、特に重要なのが結論の書き分けです。チェックリストは、調査した各システムについて「侵害を確認した」「侵害の痕跡は確認されなかった」「ログ不足などにより判断できない」のいずれかを明示するよう求めています。情報漏えいについても、次の4つのどれに当たるかを明示し、評価のために確認したログやデータを書くことを求めています。

「痕跡は確認されなかった」と「判断できない」は、似ているようで意味が大きく違います。前者は調べたうえで見つからなかったこと、後者は調べる材料がなかったことを示します。個人情報の漏えい等報告で「漏えいのおそれ」があるかを判断する場面では、この区別が判断の材料になります（関連記事：個人情報保護委員会への漏えい等報告、「確報」までに何を調べるか）。

調査する側のチェックリストにも、「直接証拠がない事項を断定していないか」「推測である場合はその旨と根拠を書いているか」という項目があります。報告書の中で、断定と推測が書き分けられているかを確認しましょう。

調査する側のチェックリストから分かること

レポーター向けのチェックリストは、項目ごとに「必須」「推奨」「任意」の区分が付いています。依頼する側にとっても、調査会社にどこまで求めてよいかの目安になります。たとえば次の項目は「必須」とされています。

• 報告書内で使うタイムゾーンを明記する（複数が混在する場合は協定世界時に統一する）
• 攻撃に関係するIPアドレスやドメインを、誤ってアクセスしないよう「example[.]com」のような形式で書く
• エグゼクティブサマリーを、経営層や技術者でない人が理解し、判断できる内容にする
• 調査結果ごとに、根拠となるログやファイルなどを書く
• インシデントの経過を時系列（タイムライン）で書く
• 初期侵入を断定できない場合、その理由を書く
• 再発防止策を、どの調査結果に対応する対策なのか分かるように書く

また、証拠を保全する際の記録（取得日時、取得者、使用機器、ハッシュ値など）や、すべての証拠に一意の証拠IDを付けることも推奨されています。付属資料としては、侵害された（疑われる）アカウントやホストの一覧、窃取された（疑われる）データの一覧、IoC一覧、検知用のシグネチャや検索クエリ、MITRE ATT&CKとの対応表などが挙げられています。

中小企業が今から備えておくこと

チェックリストは、事故が起きてから初めて開くより、平時に目を通しておくほうが効果的です。

• ログが残っているかを確認する：調査で「判断できない」が増える最大の原因はログの不足です。サーバーやネットワーク機器、クラウドサービスのログが、どこに・どのくらいの期間残っているかを把握しておきます。
• 既存の契約と照らし合わせる：チェックリストは、すでに契約しているSOCサービスやインシデント対応サービスの契約内容・SLAと比較し、必要な項目は担当者と協議するよう勧めています。事故のときにどこまで調査してもらえるのかを、今のうちに確認しておきます。
• 社内の事故対応手順に組み込む：ユーザー向けの「調査方針の合意」の10項目は、そのまま調査会社への依頼時の確認リストとして使えます。ライセンス上、自社向けに改変することもできます。
• 報告書の使い道を想定しておく：個人情報保護委員会への報告、サイバー保険、取引先への説明など、自社で報告書が必要になりそうな場面を洗い出しておくと、依頼時に伝えるべきことが明確になります。

よくある質問

Q. チェックリストは無料で使えますか？

はい。JPCERT/CCのGitHubページで公開されており、誰でも閲覧・ダウンロードできます。ライセンスはCC BY-SA 4.0で、出典を示し、改変したものも同じライセンスで公開する条件のもとで改変・再配布もできます。

Q. チェックリストを使えば、報告書が正しいか判断できますか？

いいえ。チェックリストは、依頼時の合意と、報告書を受け取ったときに最低限確認すべき事項を整理するもので、調査の技術的な正しさを保証するものではありません。技術面のレビューに不安がある場合は、JPCERT/CCなどの専門機関への相談が勧められています。

Q. 内部不正の調査にも使えますか？

チェックリストはマルウェア感染などを伴うネットワーク侵害を主な対象としており、内部不正が疑われる事案では当てはまらない項目があると注記されています。状況に応じて項目を追加・調整して使います。

まとめ：調査の質は「依頼の仕方」で変わる

インシデント調査報告書は、復旧の判断、再発防止、法令に基づく報告、取引先への説明など、事故の後のあらゆる判断の土台になります。JPCERT/CCのチェックリストは、調査会社に任せきりにせず、依頼する側が「何を知りたいのか」「何が分からない可能性があるのか」を最初に合意し、届いた報告書を自分の目で確認するための道具です。事故が起きる前に一度目を通し、自社の事故対応の手順に組み込んでおくことをおすすめします。

参照：JPCERT/CC インシデント調査報告書チェックリスト／ユーザー向けチェックリスト／レポーター向けチェックリスト