火曜日は「防御・検知・対応（消火）に予算を配分しないと燃える」という話をしました。
金曜日はその続きで、実際に燃えたときに会社を救うのは“高いツール”ではなく、最初の30分の動きだ、という話をします。

サイバー事故の怖さは、被害そのものより「初動が遅れて被害が連鎖する」ことです。
逆に言うと、完璧に守れなくても、初動が良ければ被害は小さくできます。

目次 [ close ]
  1. なぜ「最初の30分」なのか
  2. 事故対応が崩れる3つの理由
  3. “最初の30分”チェックリスト（現場向け）
  4. 1) 事故の宣言（5分）
  5. 2) 影響範囲の暫定特定（10分）
  6. 3) 止血（10分）
  7. 4) エスカレーション（5分）
  8. 「机上訓練」をやる会社が強い／経営が決めること
  9. 今週、経営が決めること（1つ）
  10. 問いかけ
  11. 参考資料（リンク）

なぜ「最初の30分」なのか

インシデントが起きた直後は、情報が少なく、混乱し、誰も確信を持てません。
このタイミングで意思決定が止まると、攻撃者は横展開し、データは持ち出され、ログは消され、復旧は難しくなります。

よくあるのはこのパターンです。
「これ本当に事故？誤検知じゃない？」→ 30分議論 → その間に被害拡大。

だから必要なのは、“正しい判断”ではなく、止血のための暫定判断です。

事故対応が崩れる3つの理由

事故対応がうまくいかない組織は、だいたい同じところで詰まります。

  • 権限がない：遮断やパスワードリセットをしたくても「誰がやる？」で止まる。
  • 連絡が遅い：情シス、開発、法務、広報、事業部がバラバラに動き始める。
  • 証拠が消える：調査のためのログや端末を、善意で再起動・初期化してしまう。

「手順書はあります」でも、実際に動けないのはここが穴だからです。

“最初の30分”チェックリスト（現場向け）

手順書を分厚くするより、30分の定型動作を決めた方が強いです。
以下は「完璧に原因特定」ではなく「被害を小さく止める」ための型です。

1) 事故の宣言（5分）

  • 「インシデント疑い」を宣言する条件を決める（例：管理者ログイン異常、端末の大量暗号化、重要SaaSの不審操作）。
  • 宣言したら、Slack/Teamsで専用チャンネルを作り、時系列で記録を始める（後で監査・報告に効きます）。

2) 影響範囲の暫定特定（10分）

  • 何が起きたかを“仮説”でいいので置く（例：アカウント侵害、マルウェア感染、設定ミス）。
  • 「対象ユーザー」「対象端末」「対象サービス」を3点だけ押さえる（完璧は不要）。

3) 止血（10分）

  • アカウント侵害の疑い：該当アカウントのセッション強制失効、パスワードリセット、MFA再登録。
  • 端末感染の疑い：ネットワーク隔離（Wi‑Fi切断・有線を抜く）、EDR隔離（あるなら）、電源は落とさない。
  • クラウド/SaaS侵害の疑い：APIキー無効化、特権権限の一時停止、外部共有リンク停止。

4) エスカレーション（5分）

  • 技術判断の責任者（情シス/CSIRT）
  • 事業判断の責任者（事業部長/CIO等）
  • 対外判断の責任者（法務/広報）

この3ラインを同時に呼ぶ（順番に呼ぶと遅れます）。

「机上訓練」をやる会社が強い／経営が決めること

インシデント対応はスポーツと同じで、“本番で初めて動く”のが一番危険です。
月1回でいいので、15分の机上訓練を回すだけで初動が改善します。

例題はシンプルでOKです。

  • 「退職者のアカウントが生きていた」
  • 「役員のMFAが突破された」
  • 「共有フォルダが外部公開になっていた」

重要なのは、正解を当てることではなく、「誰が何をするか」を体に覚えさせることです。

今週、経営が決めること（1つ）

“止血の権限”を明確にしてください。
「インシデント疑い」が出た瞬間に、CSIRT（または情シス責任者）が一時的に実行できることを決めます。

  • アカウント停止（役職者含む）
  • 外部共有の停止
  • ネットワーク遮断（重要拠点含む）
  • 監査ログ保全の指示

ここが曖昧だと、現場は怖くて動けません。
動けない間に被害が広がります。

問いかけ

御社は「インシデント疑い」を誰が宣言し、誰が止血し、誰が対外判断しますか？
答えが3秒で出ないなら、手順書より先に“最初の30分の役割”を決めるところから始めるのが最短ルートです。

参考資料（リンク）