情報セキュリティの事故対応を支援する一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）は11月11日、「インシデント調査報告書チェックリスト」を公開した。ランサムウェア（身代金要求型ウイルス）の攻撃や情報漏えいの被害を受けた組織が、原因や被害の範囲の調査を外部の調査会社に任せるときに使う。調査を依頼する組織向けと、報告書を書く担当者向けの2種類があり、調査を始める前に双方で合意する事項と、出来上がった報告書で確かめる事項を一覧にした。架空の事案を使った42ページの報告書サンプルも合わせて公開した。
初めて被害に遭った組織は、調査の妥当性を見極めにくい
JPCERT/CCは公開の理由を、調査を外部に任せる組織が増えた一方で、それを評価する側の経験が乏しいことに置いている。公開のお知らせによると、ランサムウェア攻撃や情報漏えいの増加に伴い、インシデント（セキュリティ上の事故）の調査を調査会社などの外部組織に委託することが一般的になってきた。しかし初めて被害に対応する組織も多く、そうした組織では外部組織による調査の妥当性の評価や、インシデントが収まったかどうかの判断に迷うことがあるという。
そこでJPCERT/CCは、調査を依頼する被害組織と報告書を作る担当者が「共通認識」を持って調査を進めるための道具としてチェックリストを作った。対象はマルウェア（不正なプログラム）の感染などを伴うネットワークへの侵入で、社員らによる内部不正が疑われる事案などには当てはまらない項目があると断っている。
チェックリストの位置づけについても線を引いている。依頼する側の版は、調査や報告書が完全に正しいかを確かめるものではないと明記した。調査の技術的な質、調査範囲の選び方、証拠の妥当性、再発防止策の妥当性などを見極めるには専門的な知識が要るとして、技術面のレビューに不安があればJPCERT/CCなどの専門機関や専門家に相談するよう求めている。すでにインシデント対応やSOC（セキュリティ監視センター）のサービスを契約している場合は、契約書やサービス仕様書で調査範囲や報告事項が決まっていることがあるため、チェックリストと見比べ、追加の対応が要る項目を調査会社と協議するよう促した。
作成には、伊藤忠サイバー＆インテリジェンス、NTTセキュリティ・ジャパン、インターネットイニシアティブ、ラック、トレンドマイクロ、日本IBM、富士通など14社が協力した。チェックリストはソフトウェア開発の共有サービスGitHub上で、利用や改変を認めるクリエイティブ・コモンズの「表示－継承」の条件で公開されている。
依頼する側は、調査前に目的・範囲・判断できない事項を合意
依頼する組織向けの版は、調査前の「調査方針の合意」が10項目、報告書を受け取った後の「調査結果のレビュー」が9項目で、これに封じ込めと復旧、再発防止策、IoC（攻撃の痕跡を示す情報）、脅威情報の調査について確かめる14項目と、参考として示す25項目が続く。合わせて58項目になる。
最初に合意するのは、何を明らかにするための調査か、その結果を復旧の判断、再発防止、経営判断、法令への対応、被害の公表などのどれに使うかだ。侵入経路の特定、被害範囲の特定、情報漏えいの有無などから何を優先するかも決める。チェックリストは、侵入経路や漏えいの有無は証拠が残っていないため特定できない可能性があるとし、復旧を急げば証拠が失われる可能性があり、調査を優先すれば業務の再開が遅れる可能性があると、選択に伴う影響の説明を受けるよう求めた。
調査で判断できない可能性がある事項は、事前に説明を受ける。どのログやシステム、期間が欠けているのか、それが調査にどう影響するのか、追加の調査で確かめられる見込みがあるのかの3点だ。報告書を求める場合は、少なくともエグゼクティブサマリー（概要）、初期侵入の原因、影響範囲、被害内容、再発防止策を入れるよう合意する。
報告書は、監督官庁や警察、保険会社、取引先、親会社などに渡す可能性がある。その場合は共有先と目的を調査会社に伝え、第三者への提供や二次利用ができるかを確かめる。報告の回数については、増やすと調査の進み具合を妨げるおそれがあるとして、必要の無い報告の機会を設けないよう求めた。そのうえで、新たな侵害が見つかったときや情報漏えいの評価が変わったとき、調査範囲や追加費用、完了予定を変える必要が出たときに、速報を受けられるかを確かめておく。納品後の問い合わせにどこまで応じてもらえるか、追加費用がかかるかも事前に確認する。合意した内容は口頭だけで済ませず、メールなど記録の残る形で受け取るよう求めている。
受け取った報告書は「回答できない理由」まで点検する
報告書を受け取ったときは9項目で点検する。合意した調査目的が抜けていないか、目的ごとに回答か、回答できない理由が書かれているか。要旨と各章の説明や時系列が食い違っていないか。調査の対象から外したシステムやログ、期間が書かれているか。主要な結論について、証拠の番号やログの抜粋、日時など、根拠をたどれる情報が示されているか。ログの不足や暗号化、ファイルの削除で調べられなかった事項があれば、その説明があるか。
再発防止策については、一般的な推奨にとどまらず、その事案で確認された内容に基づく対策が入っているかを見る。攻撃に使われた通信先などのIoCは、報告書とは別にテキストやExcelの形で受け取れば、監視の仕組みに取り込みやすくなる場合があるとした。
参考として示した詳しい確認項目では、結論の書き方を具体的に求めている。調べたシステムごとに「侵害を確認した」「侵害の痕跡は確認されなかった」「ログ不足などにより判断できない」のいずれかを明示する。情報漏えいについては「漏えいを確認した」「漏えいした可能性がある」「漏えいを示す痕跡は確認されなかった」「判断できない」のいずれかを書く。痕跡が見つからなかったことと、調べられなかったことを分けて書かせる。
書く側には76項目、41項目を「必須」に
報告書を書く担当者向けの版は76項目ある。付属資料の7項目を除く69項目には「必須」「推奨」「任意」の区分を付け、必須が41項目、推奨が18項目、任意が10項目だった。
| 区分 | 項目数 | 主な内容 |
|---|---|---|
| 調査開始前の合意 | 11 | 事前の聞き取り、調査目的、対象と期間、判断できない可能性の説明 |
| 証拠保全 | 9 | 複製の日時や担当者、ハッシュ値の記録、証拠IDの付与 |
| 報告書（基本・目的・要旨・方法） | 23 | 時刻の基準、問い合わせ先、経営層が判断できる要旨 |
| 報告書（調査結果・脅威情報） | 19 | 根拠となる証拠、時系列、初期侵入、漏えいの判断の根拠 |
| 報告書（復旧・再発防止） | 7 | 調査結果との対応、優先度、実施時の注意 |
| 付属資料 | 7 | IoC一覧、侵害されたアカウント・端末の一覧など |
出典: JPCERTコーディネーションセンター「インシデント調査報告書チェックリスト」
必須とされた項目には、報告書の読み手を守る書き方の決まりもある。報告書内で使う時刻の基準（タイムゾーン）を書くこと、攻撃に関わるIPアドレスやドメイン名を「example[.]com」のように一部を書き換えて記すこと、問い合わせ先を書くことだ。書き換えは、文字列が自動でリンクになるのを避けるためとしている。
調査結果の質を確かめる14項目では、直接の証拠が無い事項を断定しないことを必須とし、推測や仮説であることが分かるように書くよう求めた。初期侵入の経路を断定できないときはその理由を書く。再発防止策は一般論で終わらせず、確認された侵入経路や悪用されたアカウント、ログの欠落などのどれに対応する対策かを明記する。経営層や技術に詳しくない人が理解し判断できる要旨にすることも必須とした。
あわせて公開した報告書サンプルは、架空の会社が攻撃を受けたと想定し、初期侵入、認証情報の悪用、内部での横展開、情報の持ち出しといった調査結果と、VPN装置やファイルサーバーなど対象ごとの詳しい結果を章立てで示した。組織名やIPアドレスなどは例として設けたものだが、記載したIPアドレスやドメインには実際の攻撃に悪用されたものが含まれるため、アクセスしないよう注意書きを付けている。サンプルは、報告書に含めるべき項目は調査の目的や範囲によって変わるとして、同じ項目を必ず入れる必要は無いと説明している。
ランサム被害は上半期に最多の123件、復旧費1000万円以上が6割
調査会社に頼る組織が増えた背景には、被害そのものの増加がある。警察庁によると、2026年上半期に報告されたランサムウェアの被害は123件で、半期の件数としては統計を取り始めた2020年下半期以降で最も多かった。被害を受けた企業・団体へのアンケートでは、復旧に総額1000万円以上かかった組織が全体の6割を占め、1か月未満で復旧できた組織は5割弱にとどまった。攻撃の入口や被害の内訳はサイバー攻撃と情報漏えいの全体像 ランサム被害は最多123件、入口はVPNと委託先にまとめている。
チェックリストは、調査結果の使い道の一つに被害の公表を挙げている。漏えいが「確認された」のか「可能性がある」のか、侵入経路が「特定された」のか「推定」なのかで、顧客や取引先が取るべき行動は変わる。今回のチェックリストは、こうした区別を報告書の段階で書き分けるよう、依頼する側と書く側の双方に求めている。