インシデント対応計画が本当に動くかを会議室で確かめる机上演習の進め方

インシデント対応計画を作ったものの、実際に事故が起きたときにその通りに動けるのかは誰も確かめていない。連絡網は最新か、深夜に第一報を受けるのは誰か、社内ネットワークを止める判断は誰が下すのか。文書には書いてあるはずですが、書いてあることと動けることは別です。机上演習は、その差を会議室の中だけで見つけるための方法です。

机上演習は議論だけで進みます。サーバーを止めることも、実際に外部へ連絡することもしません。参加者が集まり、進行役が提示する状況に対して、誰が何を根拠にどう判断するかを口に出す。それだけの活動ですが、計画の抜けはかなりの割合でここで表に出ます。連絡先が古い、判断権限が誰にあるか合意されていない、広報と情報システムで公表の時期の想定が食い違っている。こうした問題は技術検証では見つからず、会話ではじめて見えます。

この記事は、机上演習をはじめて実施する組織に向けて、目的の決め方から参加者の選び方、シナリオと状況付与の作り方、当日の運営、終わったあとの報告と改善までを手順として並べます。土台にするのはNIST SP 800-84とNIST SP 800-61 Rev.3、CISAのTabletop Exercise Packages、JPCERT/CCのCSIRTマテリアル、日本シーサート協議会のマニュアル、IPAの資料です。

机上演習と実機を動かす演習は何が違うのか#

NIST SP 800-84「Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities」(2006年9月公開)は、IT計画を使える状態に保つ活動を、テスト、トレーニング、演習の3種類に分けています。そのうち演習をさらに机上演習と機能演習に分け、机上演習を討論に基づく演習と定義します。参加者が教室のような場や分科会に集まり、緊急時の自分の役割と特定の状況への対応を議論する。ファシリテータがシナリオを提示してシナリオに関する質問を投げ、役割、責任、連携、意思決定についての議論を起こす。机上演習は討論のみで、機器やその他の資源を展開することはない、という書き方です。

機能演習は、模擬的な運用環境で実際に手を動かして役割を果たす演習です。通信、緊急通知、機器のセットアップといった機能ごとに検証し、範囲を広げていくと計画の全要素を扱う総合演習になります。テストという語は、SP 800-84では計画ではなくシステムや構成要素の動作を定量的に検証する活動に限定して使われています。連絡網が制限時間内に回るかを実測する、電源を落として挙動を見る、といった活動がテストです。

NIST SP 800-84は、机上演習を討論に基づく演習と定義し、ファシリテータがシナリオを提示して役割、責任、連携、意思決定の議論を起こすものであり、機器やその他の資源を展開することはないと述べています。

日本語では演習と訓練が混ざりがちですが、日本シーサート協議会の「サイバー攻撃演習訓練実施マニュアル」は、JIS Q 22300(ISO 22300)の定義を引いて両者を分けています。演習は組織内でパフォーマンスに関する教育訓練を実施し、評価し、練習し、改善するプロセスで、目的は検証です。訓練は特定の技能を練習し繰り返しを伴う活動で、目的は技能の習得です。同マニュアルはこの違いから、演習は途中で重大な問題が見つかって中断せざるを得なくなっても、問題を発見できた結果として成果があったとみなす一方、訓練が中断すれば目的の技能を習得できず失敗になる、と整理しています。この線引きを最初に共有しておくと、演習中に手順の欠落が出たときに場が沈む事態を避けられます。

目的は3つのうち1つに寄せる#

SP 800-84は、机上演習の目的として、計画と関連する方針や手順の内容の妥当性を確かめること、計画に文書化された参加者の役割と責任を確かめること、計画に文書化された相互依存関係を確かめることの3点を挙げています。実務では、この枠をもう少し噛み砕いて次のどれを主にするかを決めると設計が進みます。

計画の検証を狙う場合は、手順書の記述が実際の状況に当てはまるかを見ます。参加者には計画を手元に置いてもらい、書いてある通りに動こうとして詰まる箇所を探します。役割の習熟を狙う場合は、誰が何をするかを体験させることを優先し、判断を厳しく問いません。意思決定の練習を狙う場合は、情報が足りない状態で止めるか止めないかを決めさせ、その根拠を言語化させます。

日本シーサート協議会のマニュアルは、机上演習をシナリオ開示型と非開示型に分けています。開示型は事前にシナリオを参加者へ渡し、何を行うべきかを検討したうえで臨む形で、インシデント対応に不慣れな参加者でも円滑に進みます。非開示型は参加者が自分の知識と既存の手順書だけで対応するため、臨機応変な判断力が要る代わりに難易度が上がります。初回は開示型から入るのが無難です。

IPAの「サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集」に載る事例も同じ順序を取っています。ある企業は初回の演習では参加者に判断や検討を求めず、インシデント対応の流れを最後まで一通り体験してもらうことに絞り、2回目以降に演習中の判断を求めてスキルの習得を確認する設計にしています。企画した担当役員は、演習が形だけのものになることを懸念し、緊急時に役割を担う全員で実施すること、通常業務へのしわよせを抑えるため規模は半日程度に留めること、参加者が自分事として体験できる機会にすることを先に要件として定めました。

参加者は計画に名前が書かれている人から選ぶ#

参加者の決め方には、SP 800-84がはっきりした指針を置いています。計画に責任を持つ全員が演習に参加すべきだが、責任のレベルが異なるため、上級層のチームと実務層のチームは最初は別々の机上演習に参加させる。両者がそれぞれ経験したあとで合同の演習を行い、グループ間の連携を検証する、という順序です。所要時間の目安も分かれていて、上級層向けは2時間から4時間、実務層向けは2時間から8時間とされています。4時間を超える机上演習では、役割と責任の理解を最新にするために研修を併せて行うのが効果的だとも書かれています。

NIST SP 800-84は、責任のレベルが異なるため上級層と実務層は当初は別々に机上演習を行い、双方が個別に経験したあとで合同の演習を実施してグループ間の連携を検証すべきだとしています。

JPCERT/CCの「CSIRTマテリアル付録 インシデント対応演習プログラム」が紹介するサンプル事例では、参加者は経営層やシニアマネージャーを含む、インシデント対応に関与するすべての部門です。ビジネスオペレーション、顧客対応、広報、法務リスク管理、情報システム、CSIRTなどが挙がっています。形式は討論主体の机上演習で2時間から3時間程度、プレーヤーは数名から十数名程度が適当とされています。CISAのCTEP向け手引きも、プレーヤーは自分が代表する組織を代弁できる権限を持つ人が望ましいとしています。名簿だけ揃えても、判断できない人が座っていると議論が止まります。

JPCERT/CCの資料は、この形式のチャレンジとして、意思決定が可能な上級管理職を含むプレーヤーを組織横断で集めること、そしてプレーヤーに対し中立に振る舞えるファシリテータを用意することの2点を挙げています。前者への対処として、経営層の承認とサポートによるトップダウンのアプローチが有効だとしています。同資料は参加者のスケジュール調整を、企画準備の最重要事項でありおそらく最も困難なタスクだとも書いています。開催日を先に押さえてから中身を作る進め方のほうが、現実には成立しやすいです。

運営側は4つの役割に分ける#

演習の運営は、参加者とは別の役割として設計します。JPCERT/CCのサンプル事例は、ファシリテータ、プレーヤー、記録係、評価者、オブザーバーを置いています。ファシリテータは進行役として演習のペースと流れを制御し、目的と基本ルールを説明し、状況を提示して議論を促し、回答と解決策を引き出します。ここには但し書きが付いていて、プレーヤーに回答や解決策を与えるのではない、とされています。記録係は演習とホットウォッシュでのプレーヤーの議論と対応を記録します。評価者は事前に定めた評価基準に従って対応を評価する役ですが、ファシリテータや記録係、場合によってはプレーヤー自身が兼ねてもよいと書かれています。小さな組織で始めるなら、ファシリテータと記録係の2人からでも成立します。

SP 800-84も同じ構成で、設計チームがファシリテータとデータ収集係を指名し、両者が計画の内容と演習の目的を熟知したうえで、事前に打ち合わせて過去の演習結果を確認するとしています。CISAのCTEP向け手引きは、良いファシリテータの条件として、私語を最小限に保ち議論を時間内に収めること、場の力学と強い個性を制御すること、話題を支配せずに的確に話せること、対象領域の知識と経験、計画と手順の把握、よく聞いて議論を要約する力を挙げています。あわせて、記録役を別に指名しておけばファシリテータが議論の中身に集中できるとしています。

シナリオは自組織の資産とリスクから起こす#

シナリオ作成でつまずきやすいのは、作り込みすぎることです。SP 800-84は、シナリオは詳細でなければ効果がないというのはよくある誤解だと明記しています。実際には短く簡潔なシナリオのほうが効果的な場合が多く、長く詳細なシナリオでは参加者がシナリオの解剖と内容の議論に時間を使い、演習の目的を満たすための時間が減るためです。詳細なシナリオを望む場合は、計画と手順を熟知した人が作成に加わって正確さを担保し、参加者がシナリオの記述そのものに引きずられ始めたらファシリテータが焦点を目的へ戻せるようにしておく、という条件が付きます。

NIST SP 800-84は、シナリオが詳細でなければ効果がないというのは誤解であり、長く詳細なシナリオでは参加者がシナリオの内容の議論に時間を使い、演習の目的に費やす時間が減ると述べています。

JPCERT/CCの資料はシナリオ作成の注意点を3つ挙げています。1つ目は現実を反映したストーリーであること。組織の事業環境、組織構造、提供または利用するサービス、保有するデータに根差した内容にし、現実に存在し得る脅威を想定して荒唐無稽にならないようにします。2つ目は観測可能な事実を記述すること。インシデント報告、検知情報、利用者からの問い合わせ、分析結果、メディア報道、社内外のステークホルダーの反応といった、参加者が実際に受け取る形の情報で書きます。3つ目はプレーヤーが理解しやすい記述にすること。解釈のぶれが生じないよう明確に書き、参加者の前提知識に合わせて用語を調節します。

題材は、自組織のリスク評価や過去のインシデントから引きます。日本シーサート協議会のマニュアルも、過去に発生したインシデントは最もリアリティのあるシナリオの手本であり、リスクアセスメント結果から自組織で発生しやすく影響度の大きいインシデントを選ぶことを勧めています。

JPCERT/CCのサンプルシナリオは最後の類型から始まります。警察から自社の代表窓口へ、押収したサーバーの分析で自社と取引先の間で交換された情報が見つかり、自社が管理するIPアドレスからの通信が6カ月前から記録されていたという連絡が入る、という状況付与です。シナリオはシーン1でインシデントの認知と初動対応、シーン2で組織の危機管理と業務影響の緩和、シーン3で再発防止と中長期的な対策を議論する3部構成になっており、各シーンに主な論点が設定されています。

ランサムウェアを題材にする場合は、感染経路と被害の広がり方を運営側が正しく理解していないと、状況付与が不自然になります。

あわせて読みたい

ランサムウェアの感染経路と被害最小化。初期侵入を断ち、復旧できる備えをつくる

状況付与の刻み方#

演習中に参加者へ提示する情報を、状況付与と呼びます。SP 800-84は機能演習の文脈でメッセージインジェクトを定義していて、演習中にプレーヤーへ提供される事前に作成されたメッセージだとしています。例として挙がっているのは、バックアップテープを輸送中の車両が渋滞に巻き込まれ、到着が当初の予定より3時間遅れる見込みだ、という一文です。各インジェクトには、投入する時刻、宛先、差出人、伝達手段、本文が含まれます。数は参加者が適度に手一杯になる程度にし、圧倒されるほど多くしない。演習の長さに応じて決める、という書き方です。同じ機能演習の文脈で、運営側は模擬事象の時系列と期待される行動と達成すべき目的を並べたMaster Scenario Events Listを作り、進行の管理に使います。

机上演習では、この仕組みを簡略化して3つ前後のシーンに切って提示するのが扱いやすい形です。刻み方の原則を挙げます。

質問リストは、JPCERT/CCの資料に載る例がそのまま使えます。提示された状況から自社にどのような事態が起きていると考えられるか。外部から侵害の可能性を指摘された場合、その情報は社内でどのように扱われるか。経営層へのエスカレーションは誰がどのような判断基準で行うか。インターネットの遮断や重要なシステムの遮断は誰がどのような基準に基づいて判断するか。停止したシステムやネットワークの復旧は誰がどのような基準で判断するか。技術支援を求めるべき外部組織は誰か、どのような判断と手続きによって支援を要請するか。いずれも、答えられなければそこが計画の穴だと分かる形の問いです。

当日の進行とタイムボックス#

JPCERT/CCのサンプル事例は、タイムテーブルの例としてブリーフィング15分、演習1時間30分から2時間、ホットウォッシュ30分から45分、デブリーフィング30分を示しています。ホットウォッシュは演習終了の直後に行う振り返りで、ファシリテータの司会により、シナリオの解説、議論の要点の確認、演習中に十分に議論されなかった点の確認、プレーヤーの気付きや感想の共有という順で進めます。アンケートはホットウォッシュのあとに記入して提出してもらいます。デブリーフィングは、プレーヤーが解散したあとにファシリテータ、記録係、評価者が集まってそれぞれの観察内容を持ち寄る場です。

座席にも意図があります。SP 800-84は、参加者を同じチームの人と隣り合わせに座らせないのが通例だとしています。独立した思考を促し、他の業務領域に触れさせるためです。ネームプレートを置き、冒頭で参加者に自己紹介と組織内での役割を述べてもらってから、ファシリテータがブリーフィングを投影して範囲と段取りを説明します。シナリオを読み上げ、ファシリテータガイドの質問の1つで議論を始めると、以降は参加者の間で自然に議論が進みます。進まないときは追加の質問を投げて、すべての目的が満たされるまで続けます。

CISAのCTEP向け手引きは、進行形式を全体討議と分科会形式の2つに分けています。分科会形式では部門や機能ごとにテーブルを分け、まず全体へシナリオと討議課題を示してから各テーブルで議論し、最後に全体へ戻して各テーブルの代表が要点を報告します。時間配分は意識するものの、目的を満たしていれば全項目を消化しなくても演習は成功だ、とも書かれています。時間内に議論を終わらせること自体を目標にすると、掘るべき論点で切り上げてしまいます。

90分から半日で回す最小構成#

最初から3時間を確保できる組織ばかりではありません。時間の枠に合わせて構成を選びます。

90分の短縮版なら、ブリーフィング10分、シーン1の状況付与と議論25分、シーン2の状況付与と議論25分、ホットウォッシュ20分、予備10分という配分に収まります。参加者を絞り、判断を厳しく問わず、対応の流れを最後まで通すことだけを目標にします。

その手前に置ける、さらに軽い形もあります。日本シーサート協議会のマニュアルは、机上訓練のうちウォークスルー型を、インシデント対応フローの読み合わせを行うもので、所要は15分から60分、準備期間は1日、CSIRT内の簡易な調整のみで実行でき、ファシリテータが不在でも実施可能だと位置づけています。手順書が現実と食い違っていないかを定期的に確かめるだけなら、この形で十分です。

準備から改善までの流れは次の順です。

終わったあとに何を残すか#

演習の成果物はアフターアクションレポートです。SP 800-84は、ホットウォッシュで出た意見と、記録係が演習中に書き留めた教訓をこの報告書に取り込むとしています。導入部に目的、参加者、シナリオといった背景を書き、ファシリテータと記録係が演習中に行った観察と、演習した計画を改善するための提言を載せます。評価基準は演習の前に作ることも明記されています。報告書ができたあとは、計画の担当者が改訂の作業項目を割り当て、提言を実装する形で計画を更新します。管理職への報告や、関連する他の文書の更新が必要になることもあります。

進め方の時間軸は、CISAのCTEP向け手引きが具体的です。アフターアクションレポートと改善計画の草案は演習後3週間から4週間以内に作成し、5週間から6週間後にアフターアクションミーティングを開いて草案を検討します。この会議で強みと改善点について最終的な合意を作り、是正措置の案を修正して合意を取り、実施の期限と担当者を決めます。最終版は会議の2週間以内に確定して配布します。文書の取り扱いに配慮が要る箇所があれば、配布範囲もこの場で決めます。

JPCERT/CCの資料は、評価と報告で整理すべき観点を並べています。どのような計画、ポリシー、手順を実行したか。各部署の役割と責任は明確に定義されたか。誰が決定権限を持ち、どのように決定が下されたか。組織内外のステークホルダーとの情報共有はどのようになされ、どのような情報が共有されたか。未解決またはフォローアップが必要な課題は何で、それらに対するアクションプランは何か。そのうえで、演習の目的は達成されたか、各シーンの中での鍵となった判断は何か、計画やポリシーや手順は活動を支えるものになっていてプレーヤーはそれらに精通していたか、といった分析を行い、ベストプラクティスと強み、改善点と提言を含む報告書にまとめます。

改善のフェーズはアフターアクションミーティングで行います。演習参加部署の意思決定者、評価者、演習計画チームが集まって演習を振り返り、修正措置を特定し、実施責任者を任命し、実施期限を設定した改善計画を作ります。日本シーサート協議会のマニュアルは、参加者アンケートを即時から1週間以内に回収するのが望ましいとしています。記憶が鮮明なうちに集めないと、書ける内容が痩せます。

出てきた課題を計画と連絡網と契約へ戻す#

演習の価値は、見つかった課題がどこへ着地するかで決まります。典型的な着地先を挙げます。

連絡網は最も高い確率で問題が出る箇所です。退職者や異動者が残っている、夜間や休日の連絡手段が個人の携帯番号しかない、社外の連絡先が担当者名で記載されていて代表窓口が分からない。サイバーセキュリティ経営ガイドライン Ver 3.0も対策例として、システム運用やセキュリティベンダなどの緊急連絡網と、社外を含む情報開示の通知先一覧を整備し、対応に従事するメンバーへ共有しておくことを挙げています。

エスカレーションと判断権限は、計画の記述へ戻します。どの深刻度で誰に上げるか、ネットワークの遮断や事業の停止や公表を誰が決めるか。演習で「たぶん社長ですかね」という答えが出たなら、それは計画に書かれていないという意味です。

法定の期限は、法務と経営層が同じ数字を持っているかを確かめます。個人データの漏えい等が起きた場合、個人情報保護委員会への報告は速報を発覚から3日から5日以内、確報を30日以内に行い、不正の目的による行為が原因の場合は確報の期限が60日以内になります。本人への通知も求められます。演習の中でこの期限が話題に出ないなら、初動の記録の取り方から見直す必要があります。

あわせて読みたい

情報漏えい発生時の対応と公表。委員会への報告義務と本人通知をどう判断するか

外部支援は契約に事前に組み込む項目です。事故が起きてから支援事業者を探すと、契約と与信の手続きだけで数日が消えます。事業者の選定にあたっては、IPAが公表する情報セキュリティサービス基準適合サービスリストを使うと、一定の品質が確保されたサービスを選べるとサイバーセキュリティ経営ガイドラインが案内しています。サイバー保険も同じ扱いで、ガイドラインはリスク移転の例として保険の活用を挙げ、IPAのプラクティス集は、現在のサイバー保険には金銭的な補償だけでなく、インシデント発生時の相談サービスを提供する商品もあると整理しています。ただしいずれも自社のリスクをゼロにするものではないという注記が付いています。

NIST SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」(2025年4月公開)は、インシデント対応をCSF 2.0のコミュニティプロファイルとして整理した文書で、演習の位置づけをこの文脈で示しています。改善に関するID.IM-02(セキュリティのテストと演習から改善点が特定される。サプライヤーや関連する第三者と共同で行うものを含む)は優先度がHighとされ、注記でシミュレーション、机上での討論、その他の形式の演習についてはSP 800-84を参照するよう指示しています。サプライチェーンに関するGV.SC-08(関連するサプライヤーや第三者をインシデントの計画、対応、復旧の活動に含める)も、テストと演習についてはID.IM-02を見るよう案内しています。演習を自社の中だけで閉じるか、委託先や重要な供給元まで広げるかは、この2つの項目に対する自社の答えとして決める話になります。

NIST SP 800-61 Rev.3は、テストと演習から改善点を特定するID.IM-02をインシデント対応の文脈で優先度Highに置き、シミュレーションや机上での討論などの演習形式についてはSP 800-84を参照するよう示しています。

計画そのものの見直しには、演習で出た課題を反映させる先として社内規程の階層を意識しておくと作業が進みます。

あわせて読みたい

社内セキュリティポリシーの作り方。基本方針・対策基準・実施手順の三層で実効性をつくる

年1回では足りない部分をどう補うか#

頻度の話をします。SP 800-84は、公開当時のNIST SP 800-53を引いて、連邦機関に対し緊急時計画とインシデント対応能力の演習またはテストを少なくとも年1回求めていると書いています。ただしこれは2006年時点の参照であり、現行のSP 800-53 Rev.5のIR-3は、組織が定める頻度と組織が定める手法でインシデント対応能力の有効性を検証する、という書き方に変わっていて、頻度は固定されていません。補足説明では、インシデント対応のテストにチェックリスト、ウォークスルーまたは机上演習、シミュレーション(並行実施または全面中断)が含まれるとされています。IR-3(2)は、インシデント対応のテストを事業継続計画や災害復旧計画や危機コミュニケーション計画の担当部門と調整して行うことを求めています。

年1回の演習だけでは埋まらない穴は3つあります。1つ目は人の入れ替わりです。新任者は次の演習まで自分の役割を知らないまま過ごします。2つ目は計画を改訂した直後です。SP 800-84は、組織変更、計画の更新、新しい指針の発行のあとにも演習を実施すべきだとしています。3つ目は手順の細部です。机上演習は判断を扱いますが、ログの抽出や端末の隔離の操作は議論では手が覚えません。

IPAのプラクティス集に載る事例も、この方向です。ある企業は机上演習を半年に1回実施し、各自が担当する役割を毎回変更するとともに、参加しない要員も交互に設定して経験の偏りを減らしています。別の企業は年1回の演習の日を定めて社内に周知し、認知度の向上と定着を図っています。経営ガイドライン Ver 3.0も、演習の対象を情報系のインシデントに限らず制御系に影響が及ぶものまで含めること、自社内に限定せず企業間をまたがった演習も考慮すること、社内で知見が得られない場合は演習を含む社外のトレーニングコースを活用することを対策例に挙げています。

外部のプログラムでは、IPAが中小企業の経営層を対象に、ランサムウェア感染のシナリオでインシデント対応の一連の流れを体験する約3時間の机上演習コースを案内しています。技術者向けには、NICTの実践的サイバー防御演習CYDERが、インシデントの検知から対応、報告までの流れを体験できるコースを提供しています。自組織でシナリオを作る前に、こうしたコースへ担当者を1人送って進行の型を持ち帰らせる進め方も現実的です。

初動の判断の型そのものを揃えておくと、演習の議論が浅いところで止まりにくくなります。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

準備と当日と事後のチェックリスト#

まとめ#

机上演習は、インシデント対応計画が紙の上だけの存在になっていないかを、会議室の中だけで確かめる方法です。討論だけで進み、機器も人員も動かしません。それでも、連絡網の劣化、判断権限の空白、部門間で食い違う前提といった問題は、ここで表に出ます。

設計の要点は多くありません。目的を1つに絞り、計画に役割が書かれている人を集め、自組織の資産とリスクから短いシナリオを起こし、状況付与を3件前後に刻む。当日はファシリテータと記録係を置き、責任追及の場にしないことを冒頭で約束し、ホットウォッシュまでを時間割に入れる。終わったらアフターアクションレポートを作り、改善計画の各項目に責任者と期限を付けて、計画と連絡網と契約へ戻す。

頻度は年1回に縛られる必要がありません。SP 800-53 Rev.5でも頻度は組織が定めるものになっています。四半期ごとの手順書の読み合わせ、半年ごとの90分の机上演習、年1回の実機を伴う演習という組み合わせのほうが、大きな演習を1回だけ行うより計画は生きた状態を保ちます。まずは90分と参加者5名から始めて、出てきた課題を1つ計画へ書き戻すところまでを1周してみてください。