インシデント収束後に何を報告するか ― 経営層と監査人が求める証跡
インシデント収束後、監査人が本当に求めているのは数字の良し悪しではなく証跡です。承認者や時刻まで揃った報告の条件をあわせて詳しく解説します。
インシデント収束後に何を報告するか ― 経営層と監査人が求める証跡
案件をクローズしてから3週間後、監査人からメールが届きます。「12日の件ですが、あのユーザーアカウントの無効化は誰が承認しましたか。承認は何時ですか」
対応したチームは答えられます。まだ覚えているからです。ただ、覚えていることと証明できることは別物です。資料を求められて出てくるのは、たいてい後から作った報告スライドと、チケットシステムから吐き出したCSV。いつ抽出したのか、何度直したのか、どこまでを数えた数字なのか、誰も説明できません。
経営層と監査人は、別のことを聞いている
経営層が知りたいのは「今月は統制できていたか」です。件数、対応にかかった時間、傾向は改善しているのか。これは経営判断のための質問で、グラフで答えられます。
監査人の関心はそこにありません。数字が良いか悪いかを見ているのではなく、その数字をなぜ信じられるのかを見ています。誰が作成したのか、誰が承認したのか、承認は公開の前だったのか後だったのか。そして、来月あらためて同じ月のレポートを出したとき、数字は同じになるのか。
後者がやっかいなのは、多くのシステムが「現在の状態を見る」ために設計されていて、「あの時点の状態を証明する」ためには設計されていないからです。
本当の問題は、レポートが動き続けること
ユーザーがリンクを踏んでしまったフィッシング案件を例にします。チームは必要な対応をすべて実施しました。ドメインのブロック、パスワードのリセット、セッションの失効、そしてクローズ。対応が自動playbookで動いていれば、各アクションのログはすでに残っています（フィッシング対応playbookの実例で各ステップの中身を詳しく説明しています）。
問題はログではありません。ログをレポートに変換する段階で起きます。
8月3日に「7月分」を出力すると、ある数字が出ます。8月20日にもう一度出力すると、違う数字が出ます。その間に古い案件が再オープンされ、遅れて届いたアラートが集計に入り、severityを遡って修正した人がいたからです。数字が間違っているわけではありません。ただ確定していない。確定していないものは証跡として使えません。
時刻の問題もあります。レポートには「7月1日〜31日」と書いてあり、一見明確です。ところが「それはタイ時間ですか、UTCですか」と聞かれた瞬間に崩れます。ログ基盤の多くはUTCで保持し、レポートを読む人はバンコクにいる。差は7時間です。つまり7月31日の21時に発生した案件がその月に入るかどうかは、誰がどこで締めたかで変わってしまいます。
証跡として通用するために答えるべきこと
| よく聞かれる質問 | レポートに必要なもの |
|---|
| このレポートの対象期間は正確にいつか | ローカル時刻とUTCを併記した期間 |
| 数字はどこまで数えているのか | 境界を含むか含まないかを明示したas-of |
| 誰がいつ承認したのか | 承認者とtimestamp（公開者とは別項目） |
| 公開後に誰かが編集していないか | revision番号と、編集を封じるステータス |
| 手元のファイルは原本と同じか | snapshotのchecksum |
この5点は贅沢な要件ではありません。「レポート」と「証跡」を分ける境界線です。zcrSOARが通常のダッシュボードとは別にevidence専用の画面を持っているのも、同じ画面からPDFを書き出して事足りるはずと考えなかったからです。
実際の画面はどうなっているか
zcrSOARデモのMonthly operations reports画面は、見出しの直下で自らをこう説明しています。「a frozen English evidence record for each closed month」― 締めた月ごとに凍結された記録。その横にはChecksum-backedの表示があります。
ステータスは3段階あります。 デモのregisterでは、Draft・Approved・Publishedの3状態を同時に並べて表示できます。起点になるボタンでさえ「レポート作成」ではなく、Generate draftと書かれています。まずdraftが出て、そこからステータスを一段ずつ進む形で、承認の記録時刻は常に公開の記録時刻より前になります（デモ画面に表示されている具体的な日付はサンプルデータで、実際のレポート期間ではありません）。
時刻は2通りで併記されます。 各レコードには、期間がタイ時間（Asia/Bangkok）とUTCの両方で併記され、境界がinclusiveかどうかも明記されます。さらに別枠のas-ofにはexclusive boundと明記されています。inclusiveとexclusive ― この2つの注記があるおかげで、読み手は境界を文書自体から割り出せます。ボタンを押した本人を探し出す必要がありません。作成パネル側にも「the server freezes the as-of to the period end」と書かれています。締めの時点はサーバー側が決めるのであって、誰かが手で入力する数字ではありません（デモ画面に表示されている具体的な時刻もサンプルであり、確定したレポート期間を示すものではありません）。
承認者と公開者は別項目です。 Approved byとPublished byは別項目で、それぞれ独自のtimestampを持ちます。ここは正確に書いておきます。デモのApproved byは人名ではなく内部のユーザーIDで表示され、Published byは「recorded」とだけ記されています。つまり画面から確認できるのは、承認と公開がそれぞれ別の項目に、それぞれの時刻とともに記録されているということです。監査人が職務分掌（segregation of duties）を確認するときに使うのは、まさにこの材料です。実名で表示されるかどうかは、自社のID基盤とどう連携させるか次第になります。
公開したら編集できません。 Publication ruleの枠にはっきり書かれています。published runs are immutable ― 公開済みの記録は変更できず、修正が必要なら理由を明記した新しいrevisionとして発行し、元の記録は監査可能なまま残る。だからregisterでは、修正が入った行だけでなく全行にrevision番号が付いています。
snapshotのchecksumがあります。 レコードの末尾にSnapshot checksumの項目があります。用途は単純で、半年後に誰かが7月分のレポートファイルを持ってきたとき、checksumを照合すれば公開時のものと同一か、途中で編集されたものかがその場で分かります。
ここまでのすべてはメタデータです。検知能力そのものとは何の関係もありません。しかし、検知の結果を後から根拠として使えるようにしているのは、この層です。
この種のレポートにできないこと
1つ目 ― 記録の中身は英語です。 画面自身が「frozen English evidence record」と明示しているとおりです。海外の監査人や、すでに英語で業務を回しているコンプライアンス部門には適しています。ただし国内の取締役会や規制当局に出すなら、翻訳と再構成の工程が別途必要です。zcrSOARが提供するのは確定した参照可能な証跡であって、そのまま使えるプレゼン資料ではありません。
2つ目 ― これは締めた月次のレポートであって、漏えい報告書ではありません。 個人データの漏えいが起きて法定期限内の報告が必要になった場合、提出するのはその個別事案の詳細であり、月次の総括ではありません。月次レポートは「プロセスが実際に、継続して回っていた」ことを示す補強証拠として有効ですが、代替にはなりません。PDPA側で何を準備すべきか不明な場合は、まず8項目のチェックリストを確認してください。
3つ目 ― 調査報告書ではありません。 この証跡が答えるのは「何を実施し、誰が承認し、いつだったか」です。「攻撃者はどこから侵入し、どこまで到達したか」には答えません。攻撃経路を辿るのは別の作業です（MITRE ATT&CKと突き合わせたattack flowの読み方がその領域を扱っています）。実務では、インシデント後の報告書は両方をそろえて初めて形になります。
当てはまったら要注意
- 過去のレポートを求められるたびに、チケットを追って組み立て直している
- 同じ月を2回出力して数字が食い違ったが、理由を説明できない
- 先月のレポートを誰が承認したのか、誰も答えられない
- 経営層に送っているレポートが編集可能なファイルで、相手が開いているのがどのバージョンか分からない
- 文書に「7月」とだけ書かれていて、タイムゾーンの記載がない
2つ以上当てはまるなら、弱いのは検知ではなく、その後の工程です。検知ツールをもう1つ増やしても、この一連の質問には何も効きません。
どこから着手するか
対応プロセスがまだ手作業中心なら、最初の一歩は各アクションが自動的に記録される状態を作ることです（SOARとは何かでその基礎を説明しています）。最良の証跡は、作業の過程で自然に生まれたものです。後から記憶をたどって記入したものではありません。
そのうえでレポート層を整えます。zcrSOARがステータスと承認記録付きのサイクルとして構成しているのがこの部分で、draftからpublishedまで、全行にrevision番号とsnapshotのchecksumが付きます。どのパッケージがこの範囲を含むかは料金ページに記載があります。判断の前に、zcrSOARのデモで実際のevidence画面を自分で確かめることもできます。
お問い合わせ
今チームが出しているインシデント後のレポートが、監査人の質問に耐えられるか気になりませんか。お気軽にお声がけください。ご相談は無料です。
出典
- 個人データ保護法 B.E. 2562（2019年）（PDPA） — データ漏えい通知義務（本記事では具体的な時間数を明記していません。実際の期限はインシデントの性質とDPOの判断によって変わるためです）
- NIST SP 800-92 — Guide to Computer Security Log Management — ログの完全性と証跡保持に関する一般原則