インシデント対応を台無しにする、テーブルトップ演習の7つの失敗パターン

IT部門、法務部門、その他の主要なリーダー層が、サイバーインシデントへの備えを確認するために理論上のシナリオを一緒に検討していく、議論ベースの低ストレスなシミュレーション——これは広く普及している非常に有用なツールです。しかし、テーブルトップ演習が適切に実施されなければ、結果は誤解を招くどころか逆効果になりかねません。

組織のインシデント対応訓練が目標を達成できない状態が続くと、予期しない多くのリスクへの扉が開かれてしまいます。幸い、効果的なテーブルトップの実施は、実際のインシデントへの対応ほど難しいものではありません。ここでは、避けるべき7つのよくある失敗パターンをご紹介します。

明確な目標設定の欠如

最大の失敗は、現実のビジネス上の意思決定に紐付いた、明確で測定可能な目標を設定せずにテーブルトップを実施することだと、デロイトの米国サイバー防衛・レジリエンス部門リーダーであるシャロン・チャンド氏は指摘します。

「実際には、汎用的なランサムウェアやインサイダー脅威のシナリオに漠然とした目標を組み合わせ、『良い結果』とは何かについて明確な合意がないという形で表れることがほとんどです」と彼女は説明します。「こうした状況では演習が迷走し、プロセスの質よりも自信ある即興対応が評価されてしまい、リーダーたちはインシデント対応計画が実際に機能するかどうかを判断できなくなります。」

代わりに、チャンド氏はサイバー・ITリーダーに対して、テーブルトップで何を達成しようとしているのかについて、明確なガイドラインと指示を示すよう助言しています。

「リーダーが『侵害シナリオを一通り確認しよう』という姿勢で臨むと、演習はすぐに準備態勢のテストではなく、ただの議論の場に成り下がってしまいます。『エスカレーション、法的通知、経営幹部の意思決定権限、復旧の優先順位をテストしよう』という明確な目的意識が欠かせません」と彼女は語ります。

対処法を熟知したシナリオのみのテスト

Oracle Healthのシニアソフトウェアエンジニアであるアユシュ・ラジ・ジャー氏は、テーブルトップに参加していた頃、毎回のインシデントが明確な判断ポイントを持つ整然としたランサムウェア事案ばかりだった経験を振り返ります。

「みんな完璧にこなしていました。ところが3か月後、マルチリージョンの災害復旧構成で実際の部分的な障害が発生したのです。状況は曖昧で、2つのシステムが矛盾した正常性ステータスを報告し、フェイルオーバーが実際に完了したかどうか誰も判断できませんでした」と彼は語ります。「そのシナリオは、どのテーブルトップでも一度も取り上げられていなかったのです。」

問題はパニックではありません。実際のインシデントが演習のものと似ていないため、人々が立ち往生してしまうことです——ジャー氏はそう言い、シナリオを最初から意図的に曖昧に設計することを勧めています。

「不完全な情報や矛盾するシグナルを与えて、不確かな状況下でどのように意思決定するかを見てみてください」と彼はアドバイスします。「なぜなら、それこそが実際のインシデントの現場の姿だからです。」

ビジネスに即したリスクシナリオの未設計

多くのITリーダーは、定期的なテーブルトップ演習を重要なセキュリティタスクではなく、形式的な義務として捉えていると、テクノロジーリサーチ・アドバイザリー企業ISGのディレクターであるジェイソン・スタディング氏は指摘します。そのため演習の重要性を軽視し、組織の実際のリスク、判断ポイント、関係者に即したシナリオを設計しないのです。

「実際には2つの形で表れます。組織にとってリアルでも関連性もないシナリオを選ぶこと、そして適切なステークホルダーを演習に含めないことです」と彼は述べます。

組織の現実のリスクに対応しないシナリオでは、参加者は「次に何をすべきか」に集中する代わりに「これは本当に起こりうるのか」という議論に終始してしまいがちだと、スタディング氏は言います。より良いアプローチは、演習開始前に丁寧で協調的な計画を立てることだと彼は主張します。

「シナリオは組織の実際の環境、ビジネス上の優先事項、過去のインシデント、そして業界で現実に見られる脅威を中心に構築されるべきです」とスタディング氏は勧めます。

参加者リストには、セキュリティ、IT、法務、広報、人事、オペレーション、そして場合によっては経営幹部など、実際の事案に関わるすべての関係者を含める必要があります。

「演習のたびに、意思決定が滞った箇所、責任の所在が不明確だった箇所、どのような声が欠けていたかを記録し、それを次のシナリオ改善に活かすべきです」と彼は語ります。

技術的詳細の欠如によるステークホルダーの関与喪失

重要なステークホルダーが訓練シミュレーションへの参加を敬遠することがよくあります。設計が不十分なシナリオのアーキテクチャや環境を見て、攻撃の連鎖が非現実的・非合理的だと判断するためです。

「ステークホルダーは、その活動を単なる時間の無駄と見なしてしまいます」と、セキュリティサービスプロバイダーGuidePoint Securityのシニアインシデント対応アドバイザリーコンサルタントであるブレイク・チフェリ氏は述べます。「シミュレーションで提示されるすべての内容は、技術的なレベルで理にかなっており、論理的につながっているべきです」と彼はアドバイスします。

「テーブルトップも他の評価と同様、投入した分だけの成果が得られます」とチフェリ氏は言います。「カスタマイズや参加に最低限の労力しか割かず、コンプライアンスのチェックボックスとして演習に臨めば、セキュリティの基準値には達しますが、対応チームやプログラムはほとんど恩恵を受けません。」

意思決定よりも暗記・再現の重視

テーブルトップ演習を、現実的で意思決定主導のシミュレーションではなく、台本通りのコンプライアンス対応の活動として扱うことが、よくある失敗だと、脅威インテリジェンスおよびデジタルリスク監視ソフトウェア企業SOCRadarのCISOであるエンサル・セケル氏は指摘します。

「多くの組織はあらかじめ決められた『ハッピーパス』を持つシナリオを設計し、参加者を期待される回答へと暗に誘導します。実際のインシデントの特徴である曖昧さ、矛盾するシグナル、不完全な情報といった状況に、参加者を直面させないのです」と彼は語ります。

このようなアプローチは、準備できているという誤った安心感を生み出しかねないとセケル氏は言います。「演習中はチームが連携しているように見えますが、実際のインシデントが発生すると、不確実性、エスカレーションのタイミング、部門横断的なコミュニケーションに苦慮します」と彼は指摘します。「事実上、組織はプロセスの想起をテストするだけで、プレッシャーの下での意思決定——実際にほとんどの失敗が起きる場面——はテストされないのです。」

実践よりも概念論の優先

マネージドサイバーセキュリティサービスプロバイダーNopalCyberのチーフソリューションアーキテクトであるミシェル・サユーン氏は、テーブルトップシナリオが理論的すぎて、具体的なリアルワールドの詳細に乏しいことへの注意を促します。

「例えば、ランサムウェアインシデントを題材にした演習でも、具体的な詳細がほとんど提供されないことがあります」と彼は言います。こうした場合、参加者は実際のインシデント対応で求められる具体的な行動や意思決定に向き合うのではなく、抽象的・高レベルな言葉で応じる傾向があります。

高度に詳細なシナリオは、テストしたい摩擦点を生み出すことができるとサユーン氏は言います。司会者が「侵害されたドメインコントローラー」「財務部門に紐付いた暗号化されたファイル共有」「祝日の週末の午前2時に発生したアラート」といった具体的な状況を提示すると、チームは混乱することがあると彼は指摘します。

「このような状況に直面したとき、参加者は不完全な情報、競合する優先事項、時間的プレッシャーと格闘しなければなりません」と彼はアドバイスします。「ここで初めて、ツールの不備、不明確なオーナーシップ、コミュニケーションの断絶といった課題が浮き彫りになるのです。」

理論主導のアプローチの根本的な問題は、偽りの準備態勢を生み出すことだとサユーン氏は言います。チームが高度に複雑なソリューションに到達しながらも、細部で迷子になってしまうことがあります。どのシステムを最初に隔離するのか。それをオフラインにする権限を持つのは誰か。そのシステムが重要なビジネス機能を担っていたらどうなるのか。ステークホルダーへの通知文を誰が起草し、どれだけ迅速に承認を得られるのか。

「こうした詳細がなければ、参加者は本当の意味で準備態勢をテストしているのではありません。プレイブックを概念レベルで理解していることを確認しているに過ぎないのです」とサユーン氏は言います。

インシデント対応の相互依存性の見落とし

アパルナ・ヒンマットラムカ氏も、汎用的なシナリオが根拠のない自信を生むという点に同意しています。しかしAmazonのセキュリティエンジニアリングマネージャーである彼女は、自社のビジネスに固有のハンドオフと相互依存関係をストレステストしないことも、偽りの自信につながると付け加えます。

「セキュリティチームはインシデントに対処できると思って演習を終えますが、実際の侵害時に機能する、自社環境特有の依存関係、コミュニケーション連鎖、システムの相互依存性を操作する練習を一度もしていないのです」と彼女は言います。

では、実際のインシデントが発生したらどうなるのか。「対応計画は、テーブルトップが一度も触れなかったまさにその部分で崩壊します——例えば、クラウドチームとSOCの間のハンドオフ、M&A統合環境が侵害された際のエスカレーション経路、またはサードパーティベンダーが侵入口となった場合の意思決定ツリーなどです」と彼女は語ります。「自社には存在しないシナリオのためにチームを訓練してしまっているのです。」

実際のリスク登録簿からシナリオを設計するようヒンマットラムカ氏はアドバイスします。「自社組織に固有の上位3〜5つの脅威を特定し、実際のアーキテクチャとチーム構成に照らし合わせてマッピングし、それを中心に演習を構築してください」と彼女は言います。