“安全です”と言い切った根拠、説明できますか？ ～ログは「集めた時点で負け」になる理由～

安全の根拠は、ログの「量」ではありません。求める分析結果に到達するまでの「時間」こそが重要です。

そして、この「時間」を左右しているのが、ログを見るための「設計」です。
「10TBのログがあります」よりも、「異常を10分以内に把握できます」の方が、はるかに信頼に値します。

では今、あなたが「安全だ」と思っている根拠を、ステークホルダー（経営、顧客、監査人や株主など） に理解できる形で、すぐに示すことができるでしょうか。
ここでいう「集めた時点で負け」とは、ログを判断や説明に活用するための設計を行わず、収集すること自体が目的化してしまっている状態を指します。

ログを集めること自体が問題なのではありません。「何のために見るのか」を決めないまま集めることが、問題なのです。皆さんも、以前に導入したシステムについて、「ログは取れているから大丈夫」と、そのまま放置してしまってはいないでしょうか。

では、この「負け」とは、具体的に何に負けているのでしょうか。それは、攻撃者に負ける前に、自分たち組織が持つ「判断能力」が負けている状態です。

具体的には、次の3点が挙げられます。

• 判断のスピードで後れを取ってしまいます
• 説明責任を果たせなくなってしまいます
• 組織としての信頼失墜に繋がります

安全かどうかのレベルは、各環境や置かれた背景によって異なります。
そのため、これが正解だと一概に示すことはできません。自分たちに合った形を理解し、対応していくことが必要です。その一助として、以下の「すぐにできる簡単な演習」の実施を提案します。

ランサムウェア対応が一段落し、システムは復旧しています。ここからサービス再開の可否を判断しなければなりません。経営から、次の一言が投げられます。

Q：10分以内に、安全かどうかを“今わかっている範囲で”説明してください

経営者へ対してですので、以下は考慮してください。

• 「多分」「問題ないと思います」といった曖昧な表現は不可
• 技術用語は使用しない
• 「ログはあります」だけの説明は不可

実際、この問いにすぐ答えられる組織は多くありません。今、皆さんが困った理由は、ログがなかったからではありません。単なる失念や個人の問題でもありません。「安全だと証明するために、どのログを見るか」を決めていなかったからです。
これが、ログが「集めた時点で負け」になる状態です。

10分なんてと思うかもしれませんが、このような場合は、10分に完全な回答を求めているわけではありません。できていること、できていないことも踏まえて状況を把握していることを問われているのです。

実際に対応した事案の一つでは、「自分の管理者アカウントは自分しか使わない」という前提から、管理者ログイン失敗を監視に含めていませんでした。その結果、復旧後も侵入の継続にすぐ気づくことができませんでした。

問題はログが存在しなかったことではなく、「起こるはずがない」という思い込みが設計に入り込んでいたことです。設計が整理されていれば、10分でも状況の輪郭は十分に把握できます。

ここからは、演習への回答を出せるようになるためのログの設計をするための助言を、3つのポイントに分けて提示します。実際には環境・システム構成に応じて、対象やレベルや10分という時間などは調整して、自分たちに合う設計を心がけてください。

目的

• 「今は安全か？」を即答するため
• 侵入が継続していないことを判断するため

特徴

• 件数は少ない
• 人が毎日確認できる量
• 日常的に確認しないのであればAには含めない

代表的なログ（例）

• 管理者・特権IDのログイン成功／失敗
• 権限変更・設定変更
• セキュリティ機能の無効化操作

判断できること

• 不審な操作が続いていないか
• いま対応が必要な事象があるか

👉 演習で最初に詰まるログです。
これが「10分以内で判断できる」ための基本になります。

目的

• 「安全だと言い切ってよいか」を裏付ける
• 影響範囲・漏えい兆候を確認する

特徴

• 平時は見ない
• Aで何か起きたときだけ見る
• 「どの条件で見るか」を決めておく

代表的なログ（例）

• 通信・アクセスの概要ログ
• ファイル操作の要約
• API・サービス利用履歴

判断できること

• 想定外の通信や持ち出しがないか
• 影響はどこまで及んでいるか

👉 演習の「10分以内に説明できるか」を左右するログで、いくつもの連携確認が必要となります。
例として30分を目標に実施できればよいでしょう。

目的

• 説明責任・監査・事後検証
• 「なぜそう判断したか」を説明できるように残す

特徴

• 日常では見ない
• 保存期間・保管方法が重要
• 存在すること自体に価値がある

代表的なログ（例）

• 詳細な操作履歴
• 低頻度システムのログ
• 長期保存ログ

判断できること

• 後日、第三者に説明できるか
• 再発防止の材料になるか

👉 経営・法務・広報が最後に必要とするログです。

A / B / C を1枚でまとめると、

もし経営陣から指摘があっても、このA/B/Cがあればあなたは自信を持って『状況を掌握しています』と言えるようになります。

「今は安全ですか？ その根拠を説明してください」 という問いに対して、

• Aがなければ → 即答できません
• Bがなければ → 言い切れません
• Cがなければ → 後から説明できません

という、非常に分かりやすい構造になります。

その場で答えに詰まっても、それは失敗ではありません。一度、「今は安全か？」と問い、答えに詰まることから始めてみてください。それが、ログ設計を始めるための、最も健全なスタート地点です。

当ブログでは、実際のインシデント事案対応に基づくログに関する記事や、専門的なログについての記事も紹介しています。今回の演習は「最後の安全確認」に絞った内容でした。

しかし、インシデント発生時には複数のチェックポイントがあり、ブログ内の事案対応記事でも紹介しています。
それぞれの場面を自分たちの状況に置き換えながら、 「本当にログが役に立つのか」を事件の流れに沿って確認し、いざというときのために準備をしておいてください。