AIを使ってサイバーセキュリティ事故の机上演習を行う方法

サイバーセキュリティ事故を想定した机上演習は、組織が現実に起こり得る事故へどう対応するかを、手順に沿って話し合う訓練です。本番環境には触れず、意思決定、責任分担、連絡、事業上の優先順位、復旧の前提を検証します。AIは演習想定の調整、進行資料の準備、観察記録の整理に役立ちますが、安全上の制約と承認済みの事故対応計画を守って使う必要があります。

この手引きは、セキュリティ、開発、IT、法務、個人情報保護、広報、顧客対応、運用、経営の各担当者を対象としています。攻撃手順や脆弱性の悪用方法は扱わず、専門知識を持つ事故対応責任者の代わりになるものでもありません。

演習の目的を定める

観察できる学習目標を二つから四つ選びます。たとえば、誰が事故対応の開始を宣言できるか、顧客への影響をどう評価するか、いつ法務や経営陣へ報告するか、重要な外部事業者へどう連絡するか、復旧の優先順位が事業上の要請と合っているか、対外発表を誰が承認するか、といった項目です。

「自社のセキュリティを試す」といった曖昧な目標は避けます。目的を絞ることで、意思決定を観察し、具体的な改善につなげられます。学習を主眼とするのか、整備済みの対応計画を検証するのか、以前に見つかった課題を再確認するのかも明確にします。

安全性、機密性、対象範囲を定める

冒頭で、すべてが模擬演習であると明示します。システムの走査、不正プログラムの実行、実際の認証情報の使用、外部の緊急機関への連絡、現実の事故と誤解される連絡は禁止します。演習を直ちに中止する合言葉と、演習中に本物の事故を発見した場合の報告経路も決めておきます。

事故対応計画やシステム情報を扱うことが許可されたAI環境だけを使います。認証情報、攻撃の具体的な手順、個人情報、顧客の機密、演習に不要な詳細構成は入力から除きます。参加者名簿、記録、事後検証報告書は、それぞれの機密区分に従って保管します。

信頼できる資料をそろえる

現行の事故対応計画、役割一覧、上申基準、サービス一覧、事業影響分析、依存関係図、復旧目標、連絡手順、広報文案、法令上の通知判断手順、外部事業者との契約上の義務、過去の演習で残った改善事項を集めます。

各資料の版と確認日を記録します。当番表や外部事業者の連絡先が古い場合は、既知の事務的な誤りを演習で再発見するのではなく、開始前に直します。

現実的で安全な演習想定を作る

演習想定は組織の技術構成や事業内容に合うものにしますが、攻撃の細かな仕組みまで書く必要はありません。管理者の認証情報の窃取、ソフトウェア供給元の侵害、身代金要求型攻撃による共通サービスの停止、無断でのデータ閲覧、不審な動きを伴うクラウド拠点の停止などが考えられます。

次の英語プロンプトを使います。

Act as a cybersecurity tabletop exercise designer. Using only the incident response plan, system inventory, business impact priorities, and participant roles I provide, propose three realistic exercise scenarios. For each scenario, define the learning objectives, initial conditions, affected services, threat assumptions, required participants, boundaries, safety controls, and evidence needed to judge decisions. Do not provide exploit instructions or assume controls that are not documented.

演習想定は情報セキュリティ責任者が承認し、防御上の弱点を不必要に明かす情報は削除します。難しさは保ちつつ、参加者が現実に入手できる情報で前に進める内容にします。

参加者と実際の権限を決める

セキュリティの技術担当者だけでなく、意思決定を担う人を招きます。主な役割は、事故対応統括者、技術責任者、運用担当者、サービス責任者、法務、個人情報保護、広報、顧客対応、人事、外部事業者との連絡担当者、経営責任者、進行役、記録担当者です。

参加者は通常業務と同じ権限で行動します。サービス停止や顧客通知に不在の経営幹部の承認が必要なら、その依存関係を明らかにすることが演習の成果です。演習のためだけに架空の権限を与えてはいけません。

進行用の状況情報を作る

監視警告、顧客からの連絡、利用できないバックアップ、報道機関からの質問、外部事業者からの続報、データ閲覧の証拠、法令上の期限、復旧方針の衝突などを段階的に提示します。各状況情報は、演習目標に結び付く意思決定を一つ以上検証するように設計します。

Create a facilitator inject sequence for this approved scenario: [scenario]. Each inject must include release time or trigger, information visible to each role, the decision being tested, expected discussion, optional follow-up evidence, and the condition for advancing. Include technical, customer, legal, executive, third-party, and recovery decisions without turning the exercise into a trivia test.

進行の速さに合わせられるよう、状況に応じた分岐も用意します。隠された筋書きを当てることに点を与えてはいけません。参加者が適切な運用上の質問をしたら、実際の事故対応で記録や担当者、外部事業者に確認するのと同じように、承認済みの証拠を提示します。

評価に使う証拠を定める

記録担当者が残す項目を先に決めます。事故と宣言するまでの時間、決定責任者、確認を求めた事実、置いた仮定、上申した時点、顧客影響の算定方法、被害拡大防止策の取捨選択、通知判断、復旧順序、未解決事項などです。話し方や個人の自信を評価するのではなく、決定とその根拠を記録します。

共通の時刻基準と意思決定記録を使い、各対応が現行計画に基づくものか、その場の判断か、何かに阻まれたものか、後日の確認が必要なものかを区別します。こうすることで、事後検証を証拠に基づいて行えます。

演習を進行する

開始時に、対象範囲、機密保持、安全上の制約、演習目標、通常業務と同じ役割で行動する原則を説明します。最初の状況を示した後は、参加者自身に体制を整えてもらいます。進行役は「誰がこの判断を担いますか」「どの事実が加われば判断が変わりますか」「事業上、どのサービスを優先しますか」「復旧前に何を確認する必要がありますか」といった中立的な質問をします。

判断を検証している最中に正解を教えてはいけません。議論が止まった場合は、あらかじめ承認された手掛かりを示すか、文書化された対応計画を確認するよう促します。技術上の出来事は、事業や連絡への影響と結び付けて扱います。

連絡と通知の判断を試す

必要に応じて、社内向けの状況共有、顧客対応部門への案内、経営陣への説明、外部事業者との調整、一般公開や報道機関からの問い合わせを含めます。参加者は、確認済みの事実、作業上の仮説、不明点、実施中の対応、次の更新時刻を分けて伝える必要があります。

契約や法令に基づく通知の結論は、法務と個人情報保護の専門担当者が出します。AIは関係する事実を整理し、暫定声明の案を作れますが、法的判断そのものを担わせてはいけません。

被害拡大防止と復旧の取捨選択を試す

少なくとも一つは難しい取捨選択を組み込みます。たとえば、データを守るために売上へ直結するサービスを止める、不完全かもしれないバックアップから復元する、主要担当者が不在のまま認証情報を更新する、証拠保全を優先して再構築を待つ、といった判断です。

判断基準、事業への影響、依存関係、元に戻す条件、復旧を宣言するために必要な証拠を参加者に説明してもらいます。サーバーが動き始めただけでは復旧完了とはいえません。完全性、安全性、データの突合、顧客への影響、継続監視まで確認する必要があります。

事後検証を行う

演習想定が終わった直後に短い振り返りを行います。その後、意思決定記録、観察記録、参加者の意見を演習目標と照らし合わせて分析します。個人を責めるのではなく、仕組みと手順に焦点を当てます。

Analyze the exercise notes against the approved objectives and response plan. Build an evidence-based after-action report with observed strengths, decision gaps, unclear ownership, missing information, communication delays, policy conflicts, and recovery assumptions. For every finding, include the exercise evidence, business impact, owner role, corrective action, priority, due date, and a measurable retest condition. Do not assign blame to individuals.

AIが作った草案は、進行役と各役割の責任者が確認します。重複する指摘をまとめ、根拠のない批判を除き、方針決定が必要な意見の相違は消さずに残します。

改善策を追跡し、再確認する

重要な指摘事項は、担当する役割、優先度、期限、依存関係、完了を示す証拠、再確認の方法を備えた具体的な改善策に変えます。権限、監視、バックアップの完全性、外部事業者との契約、人員配置、経営陣の承認権限に問題がある場合、対応計画の文章を書き換えるだけでは解決しません。

危険度の高い課題には、対象を絞った再演習を予定します。期限を過ぎた改善策は、事故対応上の危険を管理する正式な経路で報告します。組織の対応力が実際に変わって初めて、演習に価値が生まれます。

具体例

あるSaaS企業が、ソフトウェア供給元の侵害を想定した演習を行います。チームはAPIへの接続をすぐに制限できましたが、証拠が不十分な段階で顧客へ通知するかどうかを決める責任者がいないと分かりました。顧客対応部門は案内文を作り、法務は影響を受けた地域の情報を求めましたが、開発部門は演習時間内に信頼できる対象顧客一覧を出せませんでした。

事後対応では、通知判断の責任者を明確にし、影響を受けた顧客を抽出する照会手順を追加し、供給元への上申経路を更新し、60日後の再演習を設定しました。架空の攻撃者を見つけたことではなく、実際の事故で、より良い証拠を基に素早く判断できるようになったことが成果です。

品質確認

• 目的が具体的で、観察できる。
• 演習想定が実際のサービス、役割、事業上の優先順位に合っている。
• 攻撃の実行、本番環境の変更、誤解を招く対外連絡を行わない。
• 状況情報が、難解な技術知識ではなく意思決定を検証する。
• 参加者が実際の権限と依存関係の中で行動する。
• 記録担当者が時刻、証拠、決定、根拠を残す。
• 法的な結論は資格と権限を持つ担当者が出す。
• 指摘事項を、責任者と測定可能な再確認条件のある改善策に変える。

よくある失敗

• 学習目標を定めず、派手な攻撃の筋書きだけを作る
• 技術担当者だけを招く
• 古い対応計画や連絡先を使う
• 現実にはない権限を参加者へ与える
• 隠された答えを当てる試験にする
• AIにシステム構成、安全対策、法的義務を作り出させる
• 想定を解決できたかどうかだけで成功を測る
• 事後検証報告書を出した後、改善策を追跡しない

よくある質問

**演習にはどのくらい時間がかかりますか。** 対象を絞った演習なら、90分から3時間が目安です。国や地域をまたぐ複雑な想定や復旧を主題とする場合は、無理に一回へ詰め込まず、複数回に分けます。

**参加者へ演習想定を事前に知らせますか。** 目的、対象範囲、準備資料は共有します。意思決定を検証するために具体的な状況情報を伏せることはありますが、参加者を困らせたり恥をかかせたりするために不意打ちを使ってはいけません。

**AIに当日の進行を任せられますか。** AIは承認済みの状況情報の提示や記録整理を支援できますが、提示の時機、安全性、曖昧な状況の扱い、話し合いの流れは人間の進行役が管理します。

**どのくらいの頻度で行いますか。** 組織の危険度、法令や規制の要請、大きなシステム変更、経営体制の変更、以前の指摘事項を基に決めます。危険度の高い課題は、次の年次演習を待たずに再確認します。

関連ガイド

• AIを使って既存ソフトウェアの文書を整備する方法
• AIを使ってデータ移行を計画する方法
• AIを使って標準作業手順書を作成する方法