会社のサイバー事故報告書を開くと、「原因を特定」「漏えいの痕跡なし」「再発防止策を実施」と並んでいる。読む側は、ひとまず胸をなで下ろしたくなります。ところが、この三つの短文だけでは、どこまで調べたのかが見えません。
ログが消えていた時間、調査対象に入らなかった機器、証拠から推定へ切り替わった地点。そこが書かれていなければ、結論の確かさを測れないんです。JPCERT/CCが公開した新しいチェックリストを手掛かりに、事故報告書を「答え」ではなく「答えまでの道筋」として読む方法をほどきます。
一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）は11月11日、「インシデント調査報告書チェックリスト」を、GitHub上で公開した。
今回の登場人物
- JPCERT/CC：日本でサイバー事故の相談を受け、分析や対応を支援する専門組織です。警察でも、報告書へ合格証を出す認証機関でもありません。今回は、調査を頼む側と調査する側、それぞれのチェックリストを公開しました。
- インシデント調査：パソコン、サーバー、通信記録などを調べ、侵入経路や被害の広がりを組み立て直す作業です。必ず攻撃者個人まで特定できる捜査、という意味ではありません。
- ログ：誰が、いつ、どのシステムへ接続し、何が動いたかを残す運行日誌のような記録です。保存期間が切れたり、攻撃で暗号化されたりすると、日誌に空白ができます。
- フォレンジック調査：機器やファイルを後から確かめられる形で記録しながら調べる作業です。現場の足跡を踏み荒らさず、写真と番号を付けて調べる鑑識に近い役目です。
- 残存リスク：応急対応の後も残る危険や、調べられなかったため否定できない危険です。業務が再開したことと、危険が全部消えたことを混ぜないための言葉でもあります。
何が起きたか
INTERNET Watchは11月12日、JPCERT/CCが前日に「インシデント調査報告書チェックリスト」を公開したと報じました。用意されたのは、調査を依頼する組織向けと、調査して報告書を作る事業者向けの2種類です。
主に想定しているのは、マルウェアを伴うネットワーク侵入です。調査の目的や範囲を決めるところから、証拠の保全、結論の書き方、未確認事項、再発防止策まで、依頼者と調査側が同じ順番で確認しやすくします。
このチェックリストは、報告書の安全度を採点する道具ではありません。JPCERT/CCも、調査や報告書の正確性と完全性を保証しないと明記しています。今回の本題は、項目を何個埋めたかではなく、報告書の結論が証拠と限界へきちんとつながっているかです。
途中式が読めるか
事故報告書を読むとき、つい最後の結論へ目が走ります。けれど、答えだけ載った算数ドリルでは、計算が合っているか確かめられません。報告書でも、途中式にあたる部分が要ります。
まず、何を明らかにするための調査だったのか。次に、どの機器、どのログ、どの期間を調べたのか。そこから何を証拠として、どの結論へ進んだのか。さらに、分からなかった点、その理由、残る危険、必要な対策まで続きます。
たとえば「原因は不正アクセスでした」だけでは、病院の診断書に「体調不良」と書くくらい話が大きい。入口は分かっても、どのアカウントが使われ、どこまで移動され、何を確認できなかったのかが見えません。
結論ごとに、対象機器、ログ、時刻、証拠の番号へ戻れる形が望まれます。直接確かめられなかったことは、仮説や推定だと分けて書く。この区別があると、読む側は「確認済み」と「筋は通るが未確認」を同じ箱へ放り込まずに済みます。
範囲が結論の天井になる
調査は、最初に決めた目的と範囲を超えて万能にはなりません。侵入経路を知りたいのか、被害が広がった機器を知りたいのか、情報が持ち出された可能性を調べたいのか。優先順位が違えば、集める証拠も作業の順番も変わります。
ログについては、種類、保存場所、対象期間、時刻の基準、古い記録を上書きする設定まで確認します。「ログを見ました」だけでは、何月何日の、どの箱を開けたのか分からない。冷蔵庫を見たのか、押し入れを見たのかで、見つからない物の意味は変わりますからね。
証拠に固有の番号を付け、取得日時、担当者、方法、使った道具を記録することも大切です。ファイルが調査中に変わっていないか確かめるため、ハッシュ値という「データの指紋」を残す方法もあります。ただし、指紋が一致しても、そのファイルがどこで生まれ、内容が真実かまで自動で証明してくれるわけではありません。
業務を早く戻そうとして再起動や初期化をすれば、記録を失う場合があります。証拠保全を優先すれば、復旧が遅れることもある。復旧と証拠保全が綱引きになる場面もあるので、何を優先し、何を残せなかったかまで報告書に要るわけです。
「痕跡なし」の四つの顔
情報が外へ持ち出されたかを扱うとき、JPCERT/CCの依頼者向けチェックリストは、状態を少なくとも四つに分けています。
- 漏えいを確認した
- 漏えいした可能性がある
- 漏えいを示す痕跡は確認されなかった
- 判断できない
この四つは、似た顔をしていても意味が違います。外部通信の送信元と宛先、時刻、通信量を確認し、必要な期間のログも残っていた。そのうえで痕跡が見つからなかった場合と、肝心なログが暗号化されて読めなかった場合では、結論の強さが変わります。
防犯カメラの録画が一晩分抜けているのに、映像に怪しい人が出てこないから侵入なし、と決めるのは早いですよね。報告書で見るべきなのは、安心できる言葉の有無より、その言葉を言えるだけの記録が残っていたかです。
調査できなかった理由も立派な情報です。ログの保存期間切れ、攻撃者による削除や暗号化、契約上の調査範囲外。理由が分かれば、追加調査の可能性や、次から何を保存すべきかも考えられます。空白を無理に結論で塗りつぶさず、「ここは見えていません」と線を引く方が、次の判断に役立つんです。
対策を原因へ戻す
報告書の最後には、よく「多要素認証を導入する」「社員教育を強化する」「監視を強化する」と並びます。どれも一般には大切です。ただ、事故調査の結果と結びついていなければ、薬箱を机に置いただけで、どの症状にどの薬を使うのかが分かりません。
悪用されたアカウントがあったなら、その認証をどう変えるのか。ログが短期間で消えたなら、何をどれだけ長く保存するのか。不審な外部通信を見逃したなら、どこで検知し、誰が対応するのか。対策ごとに対象、優先順位、期待する効果、運用上の注意まで結びます。
実施したことと、効いたことも分けて見ます。設定を入れた、研修を開いた、という記録は出発点です。その後に想定どおり検知できるか、古い侵入口が閉じたかを確かめて、ようやく対策の実力が見えてきます。チェックリストは、この実力まで保証してくれる魔法の採点板ではありません。
読む人ごとの見どころ
経営者は、未確認事項と残存リスクを見て、追加調査や投資の優先順位を決めます。取引先は、自社との接点が調査対象に入ったか、再接続の条件は何かを確かめる。利用者は、自分の情報が対象なのか、まだ判断できない範囲が残るのかを見ます。
広報や法務にとっては、「確認した」「可能性がある」「痕跡は確認されなかった」「判断できない」の使い分けが重要です。言葉を強くすると説明は短くなりますが、証拠より強い断定は、後から報告書そのものの信用を削ります。
公開版の報告書では、攻撃者に手の内を明かさないため、詳しい構成や設定を省くこともあります。報告書が短いから調査不足だと、ページ数だけで決めるのも乱暴です。読む側が確かめたいのは厚さではなく、結論の根拠と限界が追えるかどうかです。
まとめ
よい事故報告書は、原因らしい一文だけで終わりません。調べた範囲、使った証拠、分からなかった点、残る危険、再発防止策が一本につながり、読者が結論まで戻れる形になっています。
ログが足りなければ、「痕跡なし」でも漏えいを否定できません。JPCERT/CCのチェックリストは、その境界を依頼者と調査側が一緒に確かめる道具です。報告書の道が途中で切れているなら、切れた場所と理由もまた、大事な調査結果なんです。