セキュリティ机上演習の観察記録｜状況付与・判断・課題を改善計画につなげる方法

セキュリティの机上演習では、状況付与に対して参加者が何を判断し、どの計画や手順を根拠にし、結果として何が未確認のまま残ったかを記録します。発言をたくさん残すことが目的ではありません。演習の目的に関係する判断と、次に確認すべき課題を、後から別の担当者が追える形にすることが目的です。

CISA Tabletop Exercise Packages（CTEP）は、組織が自分たちの脅威シナリオを話し合うための目的、シナリオ、討議質問、参考資料を組み合わせたパッケージです。そこに含まれるFacilitator / Evaluator HandbookとAfter-Action Report / Improvement Plan（AAR / IP）の考え方を使うと、演習中の観察を改善計画へつなげやすくなります。

観察記録は「状況付与→観察記録→原因分析→改善・再確認」の4段階で作ります。各行に、誰が、何を、なぜ、どのように判断したか、判断の結果、未確認の点、原因の仮説、改善担当、期限、再確認条件を記録してください。参加者が「実行できる」と答えたことは、実際に手順を実行できた証拠とは分けて扱います。

この4段階は、製品の画面や特定の訓練方式に依存しない記録の枠組みです。演習の目的や参加者、想定する脅威によって項目は調整しますが、事実、判断、未確認、仮説を同じ欄に混ぜないことが品質を左右します。演習で実行できると発言したことは、手順を実際に実行して結果を確認した証拠とは分けて記録します。

---

本記事のポイント

1. 机上演習の観察記録は、状況付与と参加者の判断を対応付け、発言・行動・結果・未確認を分けて残します。
2. 原因分析では計画との差異、役割、訓練、資源、組織間調整を確認し、原因仮説を確認済みの事実と混ぜません。
3. 改善課題は担当・期限・完了の証拠・再確認条件まで決め、AARの提案と実行用の改善計画を分けて管理します。

---

1. 机上演習の観察記録は、状況付与と判断を対応付ける

状況付与は、演習の進行に合わせて参加者へ提示する出来事や情報です。たとえば「特権アカウントに通常と異なる地域からのログイン通知が届いた」「バックアップ管理者へ連絡がつかない」といった情報を、提示時刻、提示した担当、前提条件と一緒に識別します。提示内容そのものと、参加者がそれをどう解釈したかは別の記録です。

CISAのFacilitator / Evaluator Handbookは、評価者が正確な記録を取り、誰が意思決定したか、何が起きたか、なぜその判断をしたか、どのような手順で判断したか、結果はどうなったかを残すよう求めています。解決策が話し合われた場合は、担当者と完了までの期間も記録対象です。演習目的に関係する出来事へ集中し、発言を逐語録のように写し続けないことも示されています。

観察記録に最低限そろえる項目

項目	記録する内容	判定の注意
記録ID・時刻	状況付与ID、提示時刻、判断が始まった時刻	演習上の時刻であり、実事故の発生時刻ではない
参加者	氏名ではなく役職・担当でもよい。誰が発言・判断したか	参加していない部署の判断を補わない
判断	何を決めたか、判断のトリガーは何か	提案、合意、決定を分ける
方法と根拠	参照した計画、手順、連絡網、権限、前提	「知っている」と「確認した」を分ける
結果	演習内で確認できた行動・成果・残った不明点	発言だけで実行済みとしない
改善情報	課題、原因仮説、担当、期限、再確認条件	仮説には根拠と確認方法を添える

演習の時刻は、実事故のログを扱うセキュリティ事故の時系列整理と混同せず、状況を提示した時刻と討議の経過として記録します。

2. 状況付与→観察記録→原因分析→改善・再確認の4段階

第1段階：状況付与を、目的と期待する判断に結び付ける

最初に、状況付与を単なるストーリーではなく、演習目的を検証する問いとして設計します。付与ごとに「どの目的に関係するか」「参加者にどの判断を促すか」「判断に必要な情報は何か」「情報が足りない場合に何を観察するか」を決めます。付与の出所が想定メール、監視通知、取引先からの連絡などであれば、演習用の情報であることと、提示条件も記録します。

CISA資料の要点：CTEPは目的、シナリオ、討議質問を組織に合わせて調整でき、事前の情報共有、対応、事後の復旧を話し合うモジュールも用意しています。したがって、状況付与は参加者を驚かせる演出ではなく、あらかじめ定めた目的と討議を観察するための入力として設計します。

実務例：「管理者アカウントの異常ログイン」という付与なら、観察者は、参加者が本人確認、影響範囲、連絡責任者、追加情報の取得をどの順で判断するかを記録します。実際のアカウント停止やログ取得を行わない演習なら、その未実施も明記します。

影響範囲を討議する付与では、セキュリティ事故の影響範囲評価で扱う資産・データ・顧客の区分を問いに使えます。ただし、想定上の範囲を実事故で確定した範囲として記録しないでください。

第2段階：観察記録を、発言・判断・結果に分ける

観察者は、参加者を誘導したり質問へ答えたりする役割ではありません。CISAの資料が示すように、進行はファシリテーターが担い、評価者は議論を妨げず、目的と能力に関係する主要な出来事を記録します。記録は「情報を受け取った」「担当者が確認を提案した」「責任者が連絡先を決めた」「実際の連絡は時間内に確認できなかった」のように、観察可能な単位へ分解します。

ここで「バックアップから復元できる」と参加者が話した場合、記録は「復元可能との発言があった」です。机上演習の目的が意思決定や合意形成なら、実操作を必須にせず、その討議上の達成を判定できます。一方、操作や復元能力まで確かめる目的なら、別途、訓練環境で機能訓練を行い、手順を実行して所定のデータが戻ったかを確認します。机上演習で実行しなかった理由や、実行に必要な権限・担当・時間が不明なら、未確認の課題として残します。

第3段階：原因分析は、計画との差異と仮説を分けて書く

観察の後は、議論の記録を既存の計画、ポリシー、手順と照合します。CISAのEvaluator Handbookは、討議メモの確認、既存計画との比較、差異の特定と説明、問題を解決する提案の整理を分析の流れとして示しています。差異が見つかっただけで原因が確定するわけではありません。

原因仮説は「連絡先台帳が一元化されていない可能性」「復元担当の権限境界が手順に書かれていない可能性」のように書き、何を確認すれば仮説を絞れるかを添えます。訓練不足、手順の欠落、役割の重複、情報不足、資源不足、組織間の合意不足など、候補を分けて検討してください。CISAの資料でも、根本原因を探るために緊急計画、訓練、ポリシー、手順を確認する必要があるとしています。

第4段階：改善と再確認を、課題の完了条件まで決める

改善提案は「連絡網を見直す」「復元手順を整備する」だけで終わらせません。誰が、いつまでに、何を変更し、何を証拠として残し、どの状況付与で再確認するかを決めます。再確認は、文書を更新しただけで終えるのか、担当者への説明まで行うのか、実際の演習環境で手順を試すのかを課題ごとに区別します。

CISA資料の要点：AAR/IPテンプレートは、観察された改善事項を「観察」「関係する計画や規程」「分析」「提案」に分け、実行する是正措置を改善計画側へ置く構成です。提案の文章に担当・期限・完了条件を詰め込むのではなく、AARでなぜ改善が必要かを説明し、改善計画で実行を追跡します。

実務例：課題台帳に「担当：IT運用責任者」「期限：次回演習の14日前」「完了の証拠：連絡網の版番号と配布記録」「再確認：同じ付与で10分以内に担当者へ到達」と記録すると、更新したかどうかと、使える状態になったかどうかを分けて確認できます。ここで示す5分・10分は説明のための独自の実務例であり、すべての組織に適用する普遍的な基準ではありません。組織の目的、体制、リスクに合わせて設定してください。

3. 判断・未確認・原因仮説を混ぜない記録表

次の表は、サイバー事故を想定した演習で使える独自の記録例です。CISAのテンプレートをそのまま置き換えるものではなく、現場が観察者用の行を作るための実務例です。固有の製品名、実在の人物、実際の事故の証拠は記載しません。

机上演習の観察から改善計画へつなぐ記録例

ID・状況付与	観察した発言・行動	判断・結果	状態	原因仮説	改善担当・期限・再確認
O-01 管理者の異常ログイン	情報システム担当が監視通知を読み上げ、アカウント停止を提案。責任者が影響範囲の確認を先に行うと決定。	停止条件と承認者は合意。実際の停止操作は演習内で未実施。	判断は確認済み、操作は未確認	緊急停止の承認者一覧が手順の別紙に分かれている可能性。	情報システム責任者／2週間後／同じ付与で承認者へ5分以内に到達し、訓練環境で操作ログを確認。
O-02 バックアップ復元の要求	担当者が「バックアップから復元できる」と発言。復元対象、復元先、必要権限を確認する質問が出た。	復元の方針は話し合ったが、データの復元と整合性確認は未実施。	発言は確認済み、実行結果は未確認	復元手順の担当境界とテスト環境が定義されていない可能性。	基盤運用責任者／次回演習前／テスト用データを復元し、件数・更新日時・利用可否を照合。
O-03 顧客への初報	広報担当が初報の必要性を提起。法務確認と技術事実の確定を待つ判断になった。	初報を保留する条件は合意。誰が次の更新を判断するかは決まらなかった。	保留条件は確認済み、後続責任者は未確認	技術・法務・広報の引き継ぎ点と更新期限が手順にない可能性。	危機対応責任者／1か月以内／次回付与で更新時刻と承認者を記録し、判断が途切れないことを確認。

表の「状態」は、観察者が確認できた範囲を示すものです。「確認済み」は演習中の発言や合意を確認したという意味であり、本番環境の安全性や実事故への対応能力を証明しません。「未確認」は失敗と同義ではなく、演習の範囲・時間・権限では確認できなかったという意味です。判断を保留した理由も、判断しなかったこととは分けて記録します。

4. 実事故の証拠保全・調査とは記録の目的が違う

机上演習の観察記録は、仮想シナリオの討議から、組織がどの判断をし、どの準備が不足しているかを学ぶための記録です。実事故のログや端末を収集して原因や影響を調べる作業とは目的が違います。演習記録に実在のログ、顧客情報、端末の取得物を混ぜると、訓練用の仮定と現実の証拠の境界が崩れます。

実事故の調査では、原本の扱い、取得条件、保管、受け渡し、時刻、ハッシュなどを別の手順で管理します。必要な場合はセキュリティ事故の証拠保全で、ログ・端末・受け渡し記録を追跡する考え方を確認してください。

机上演習では、実事故の証拠を扱っているように見せるために現実の個人情報や本番ログを使う必要はありません。演習用の架空データ、権限、連絡先、状況付与を準備し、実事故対応の手順を試す場合も、演習で実施した操作と本番で必要な保全行為を分けて記録します。

5. 改善担当・期限・再確認条件を改善計画に落とす

演習終了直後のhot washでは、参加者とファシリテーターが目的を達成できたか、良かった点、改善すべき不足、追加の論点、短期・長期の次の行動を振り返ります。その後の評価者・ファシリテーターのデブリーフィングでは、食い違う結果を整理し、強みと改善領域を固めます。観察者の記録は、この振り返りで議論を思い出すための材料になります。

改善計画の完了条件を決める例

課題	改善提案	実行する是正措置	完了の証拠	再確認条件
緊急連絡先が分散	連絡網の管理責任と更新経路を明確にする	正本台帳を指定し、更新時に版番号を付ける	版番号、承認記録、配布先一覧	付与から5分以内に責任者へ到達
復元可否を討議だけで判断	復元手順とテストデータの確認を定期化する	訓練環境で復元し、照合項目を手順へ追加	実行日時、対象、照合結果、担当者	データ件数と利用可否が基準を満たす
顧客初報の更新責任が不明	技術・法務・広報の判断分担を決める	更新期限と承認者を状況別に台帳へ登録	承認済み手順と演習時の判断ログ	同じ付与で次の更新時刻と担当が確定

期限は「なるべく早く」ではなく、次回演習の前、四半期レビューの前、契約更新の前など、判断に使える日付へ落とします。期限を過ぎた場合は、未完了の理由、暫定的な代替策、次に責任を持つ人を更新します。再確認に合格しなかった場合も、元の観察行と同じIDで差分を記録すると、改善の有無だけでなく、どの条件で詰まったかを追跡できます。

よくある質問

机上演習の観察記録と実事故のログは同じですか？

同じではありません。机上演習の観察記録は、仮想の状況付与に対する参加者の判断、根拠、討議、未確認事項を残すものです。実事故のログは、実際に起きたイベントを調査するデータで、取得・保全・アクセス管理など別の扱いが必要です。演習の表へ本番ログや顧客情報をそのまま記載しないでください。

参加者が「実行できる」と答えたら、達成と判定できますか？

演習の目的に応じて判定します。意思決定や合意形成が目的なら、「実行できる」という発言を含む討議上の合意を達成として判定できる場合があります。ただし、それは操作や復元能力を実証したこととは別です。操作、権限、時間、結果まで確かめる目的なら、机上演習とは別に訓練環境で手順を実行し、結果を確認します。実行しなかった場合は、未確認の理由も残します。

原因仮説は、観察記録の中で断定してよいですか？

断定しません。計画との差異や討議から原因の候補を立てたら、根拠、追加確認する資料、確認担当を添えて「仮説」と記録します。訓練不足、手順の不足、役割の重複、権限や資源の不足などを分けて確認し、追加情報で説明が変わった場合は履歴を残します。

状況付与ごとに記録IDを付ける必要がありますか？

必須の形式は組織ごとに異なりますが、付与と観察を対応付けるために、識別子を付ける方法が実務的です。付与の時刻、提示者、関連する演習目的、判断、未確認、改善課題を同じIDで追えると、議論の記憶に頼らずAAR/IPへ整理できます。

再演習はいつ実施すればよいですか？

一律の間隔で決めるのではなく、課題の完了条件とリスクで決めます。連絡網の更新なら付与後の到達確認、復元手順ならテストデータの復元と照合、顧客連絡なら更新責任者の決定など、改善内容に合う条件を設定します。条件を満たせない場合は、未完了として担当・期限・暫定策を更新します。

参考資料

• CISA Tabletop Exercise Packages（目的、シナリオ、討議質問、情報共有・対応・復旧のモジュール）
• CISA CTEP Package Documents（planner、facilitator / evaluator、participant、AARのテンプレート）
• CISA CTEP Facilitator / Evaluator Handbook（観察、hot wash、分析、根本原因、改善提案の整理）
• CISA CTEP After-Action Report / Improvement Plan template（目的・能力、観察、分析、提案、改善計画の構成）