机上演習のシナリオは、「攻撃ストーリーを細かく作ること」から始めると失敗しやすくなります。
先に決めるのは、参加者に何を判断してほしいかです。
たとえば、
- 重大インシデントの宣言基準を確認したい
- 経営層への報告経路を確認したい
- 委託先事故の初動を確認したい
- 情報流出が未確定な段階の公表判断を確認したい
- ランサムウェア時の業務停止・復旧優先順位を確認したい
といった演習目的を決め、その判断が必要になるように状況を組み立てます。
IPAの机上演習教材は、過去のランサムウェア被害事例を参考にシナリオを作り、座学とグループディスカッションを組み合わせています。米CISAのCTEPも、シナリオだけでなく、計画、進行、評価、After Action Reportまで一体で設計しています。
シナリオ作成は「目的→判断→状況」の順で考える
机上演習のシナリオ作成では、次の順序が使いやすくなります。
- 演習目的を決める
- 確認したい判断を列挙する
- 参加者と役割を決める
- 初期状況を作る
- 追加情報（Inject）を作る
- 設問を作る
- 評価基準を決める
- 進行役向け補足を作る
- 演習後の改善管理方法を決める
「ランサムウェアのシナリオを作る」だけでは範囲が広すぎます。
同じランサムウェアでも、
- 封じ込め
- 顧客通知
- 工場停止
- 身代金対応
- バックアップ復旧
- 取引先対応
のどこを確認するかでシナリオは変わります。
まず演習目的を1～3個に絞る
1回の演習ですべて確認しようとすると、議論が浅くなります。
90分程度の演習なら、主要目的を1～3個に絞る方法があります。
例：
「委託先から不正アクセスの第一報が来たとき、情報システム、法務、個人情報保護担当が、必要情報を確認して社内報告できるか」
ここまで具体化すると、必要なシナリオが見えてきます。
逆に、
「ランサムウェアへの対応力を高める」
だけでは、何をもって演習成功とするか決まりません。
シナリオの基本構造
実務で使いやすいシナリオは、次の要素で構成できます。
| 要素 | 内容 |
|---|---|
| 背景 | 会社・業務・システムの前提 |
| 初期状況 | 最初に参加者へ伝える事象 |
| Inject | 時間経過とともに追加する情報 |
| 設問 | 参加者へ判断を求める問い |
| 想定確認事項 | 手順書、連絡先、ログ、契約など |
| 評価 | 判断できたか、根拠があったか |
| 改善項目 | 演習後に修正する事項 |
CISAのCTEPでも、参加者向けSituation Manualと、進行役・評価者向けの資料を分け、進行役が追加質問を使えるようにしています。
Injectとは
Injectは、演習中に追加で提示する情報です。
一度に全情報を渡さず、状況が変化するたびに参加者へ判断を求めます。
たとえばランサムウェア演習では、
- 9:00 ファイルサーバーの一部へアクセスできない
- 9:15 複数端末で暗号化を確認
- 9:30 バックアップ管理サーバーへの不審アクセスを確認
- 10:00 主要取引先から納期確認の電話
- 10:15 攻撃者が情報窃取を主張
- 10:30 復旧見込みが48時間以上と判明
のように段階化します。
ここで「攻撃者の主張」と「実際に情報流出を確認した事実」は分けます。
ニュース記事と同じく、机上演習でも確認済み事実と未確認情報を混同しない方が、現実に近い判断を練習できます。
良いInjectは「新しい判断」を発生させる
Injectは演出のために追加するものではありません。
追加情報によって、誰かが新しい判断をする必要がある状態を作ります。
悪い例：
「攻撃者のIPアドレスが判明した」
技術チーム以外の判断が変わらないなら、経営層や法務を含む演習では効果が限定的です。
改善例：
「受注システム停止が2時間から48時間へ延びる見込みになった」
これなら、
- 業務継続
- 顧客説明
- 売上影響
- 復旧優先順位
- 経営エスカレーション
の判断が発生します。
設問は「何をしますか」だけにしない
「この状況で何をしますか」だけでは、抽象的な回答になりやすくなります。
具体的には次の形にします。
- 誰が意思決定しますか
- 何分以内に誰へ報告しますか
- 判断に不足している情報は何ですか
- その情報を誰から取得しますか
- どの手順書・契約・台帳を確認しますか
- 業務停止による影響は誰が評価しますか
- 社外へ説明するとき、確認済み事実と未確認事項をどう分けますか
- 次の判断期限はいつですか
机上演習では、回答内容だけでなく「判断する仕組み」があるかを見ます。
フェーズ別の設問例
| フェーズ | 設問例 |
|---|---|
| 検知 | どの条件で重大インシデントとして宣言するか |
| 初動 | 端末・ネットワークを誰の権限で遮断するか |
| 影響調査 | 顧客情報へのアクセス有無を確認するために何のログが必要か |
| 経営報告 | 経営層へ何を確定情報として報告するか |
| 法務・規制 | 報告・通知要否の判断に不足している事実は何か |
| 広報 | 第一報で何を公表し、何を「調査中」とするか |
| 復旧 | どの業務から戻すか、理由は何か |
| 再発防止 | 演習後に誰が何をいつまでに修正するか |
実インシデントからシナリオを作る方法
セキュリティ対策Labには多数の実インシデントがあります。
そのまま再現するのではなく、事故の「判断が発生した箇所」を抜き出します。
シナリオ例1：事業停止・復旧優先順位
Boston Scientificは2026年8月、一部ITシステムに関するサイバーインシデントで、製造、顧客注文処理、製品出荷に影響が出たと公表しました。
関連記事：ボストン・サイエンティフィック、サイバー攻撃で製造・出荷に影響
この事実から、自社向けには次のような架空シナリオへ変換できます。
初期状況：
「受注管理システムが利用できず、出荷指示を出せない」
Inject：
「復旧見込みは当初2時間だったが、48時間以上へ変更された」
設問：
- 手作業へ切り替える業務は何か
- どの顧客を優先するか
- 売上・契約・医療・安全など、何を復旧優先順位に使うか
- 顧客へいつ説明するか
- 経営会議を招集する条件は何か
シナリオ例2：再委託先で情報漏えいのおそれ
大阪・関西万博では2026年、催事業務の再委託先Microsoft 365への不正アクセスが発生し、関係者や出演者の情報を含むメール・添付ファイルに漏えい等のおそれがあると公表されました。
関連記事：大阪・関西万博、再委託先のMicrosoft 365へ不正アクセス
架空シナリオ：
「再委託先から『Microsoft 365へ不正アクセスがあった。対象範囲は調査中』と第一報が届いた」
Inject：
「12時間後、過去プロジェクトの個人情報が残っていたことが判明した」
設問：
- 何のログ、メールボックス、ファイル一覧を要求するか
- 契約上の報告期限は満たしているか
- 再委託先へ直接確認できるか
- 個人情報の対象者を誰が特定するか
- 委託終了後の削除確認はどうなっていたか
シナリオ例3：ランサムウェアと営業継続
ワシントンホテルは2026年2月、ランサムウェア感染を公表しました。その後、通常営業を継続しながら調査・復旧を進めています。
関連記事：ワシントンホテル、第3報でランサムウェア被害の状況を更新
架空シナリオ：
「社内管理サーバーが暗号化されたが、顧客向けサービスは動いている」
Inject：
「一部業務データが利用できず、復旧時期は未定」
設問：
- 営業継続の条件を誰が決めるか
- 顧客向けシステムと侵害環境の分離をどう確認するか
- バックアップ復旧前に何を確認するか
- 公表文で『影響なし』と『確認されていない』をどう使い分けるか
実際の各社対応と、上記の架空シナリオは別です。実インシデントを演習材料にする場合は、この区別を資料上でも明記します。
シナリオに技術情報を入れすぎない
技術情報は、判断に必要な範囲に限定します。
経営層を含む演習で、
- マルウェアの詳細な挙動
- exploitの具体的手順
- 高度なフォレンジック解析
を長く説明すると、技術解説会になりやすくなります。
代わりに、
「外部から不正アクセスが確認された」
「顧客データへのアクセス有無は未確認」
「復旧には最低48時間必要」
といった、判断に直結する情報へ変換します。
ファシリテーター向け資料を別に作る
参加者用と進行役用は分けます。
ファシリテーター用には次を入れます。
- 演習目的
- 各Injectの提示タイミング
- 想定される論点
- 議論が止まった場合の追加質問
- 実際の社内規程・手順で確認したい箇所
- 「正解」ではなく最低限確認したい事項
- 時間配分
- 演習終了条件
CISAもFacilitator/Evaluator Handbookを用意し、シナリオに加えて進行と評価を支援する構成を採っています。
評価基準は演習前に決める
演習後に感想だけ集めても、対応力の変化を測りにくくなります。
評価例：
| 評価項目 | 確認方法 |
|---|---|
| 重大インシデント宣言 | 責任者と基準を答えられたか |
| 連絡 | 必要部門へ所定時間内に連絡できたか |
| 情報収集 | 必要ログ・台帳を特定できたか |
| 経営判断 | 業務影響を踏まえ判断できたか |
| 外部報告 | 確認済み事実と未確認情報を分離できたか |
| 復旧 | 優先順位に事業上の根拠があったか |
| 改善 | 課題に担当者と期限を設定したか |
NIST SP 800-84も、演習を実施して終えるのではなく、評価して計画・能力の改善につなげる考え方を示しています。
机上演習を90分で実施する構成例
セキュリティ対策Labの既存資料は、約90分で実施する構成です。
一例として次の配分にできます。
| 時間 | 内容 |
|---|---|
| 10分 | 目的・ルール・役割確認 |
| 15分 | 初期事象・検知 |
| 20分 | 封じ込め・影響把握 |
| 20分 | 経営報告・外部対応 |
| 15分 | 復旧・事業継続 |
| 10分 | 振り返り |
自社で利用できる演習資料として、セキュリティインシデント対応 机上演習シナリオ｜不正アクセス編・ランサムウェア感染編も公開しています。
シナリオ作成時のチェックリスト
- 演習目的が1～3個に絞られているか
- 参加者が実際に担当する役割で参加するか
- Injectごとに新しい判断が発生するか
- 情報を最初から全部渡していないか
- 確認済み事実と未確認情報を分けているか
- 攻撃手法の説明が長くなっていないか
- 社内手順書・契約・連絡先を使わせる設計か
- 技術、法務、広報、事業の判断が交差する場面があるか
- 評価基準を事前に決めたか
- 演習後の改善管理まで設計したか
シナリオの完成度は、ストーリーのリアリティだけで決まりません。
参加者が自社の手順書や連絡先を開き、「この判断は誰がするのか」と確認する場面が生まれるかどうかで評価します。
<!– 公開後の内部リンク候補: – 机上演習とは – 経営層向けサイバーセキュリティ机上演習 –>
<!– SEOディスクリプション案: セキュリティ机上演習のシナリオは、攻撃ストーリーより先に「何を判断させるか」を決めます。演習目的、Inject、設問、評価基準、ファシリテーター資料の作り方を、IPA・CISA・NISTの公的資料と実インシデントを使った具体例で解説します。 –>
