IRPのテストは、新車の試乗に似ている。カタログ上では問題なく見えても、実際に運転して初めて「ブレーキは適切に動くか」「運転しやすいか」「安全に走行できるか」が分かる。インシデント対応計画も同様で、実際に試してみなければ、計画が機能するかどうかは判断できない。

　テストの目的は、「手順を確認すること」だけではない。計画のどこに問題があるか、必要なリソースが足りているか、担当者が本当に役割を果たせるかを検証することにある。

　IRPのテスト手法は複数ある。

TTX：机上演習

　架空のシナリオを使い、特定の問題にどう対処すべきかをインシデント対応チームが議論する。実際のシステムは操作せず、対応フローや意思決定を確認する。

Functional Exercise：機能演習

　実際のインシデント発生時を想定し、実戦形式でIRPに記載の役割に基づいて行動し、計画内容を検証する。「インシデント発生時のコミュニケーション」や「バックアップを使ったデータの復旧作業」などを実施する。

Full-scale simulations：全機能演習

　本番環境に近い形で擬似攻撃を実施する。例えば、ファイアウォールが正しく機能するかを確認するために、疑似攻撃を実施し、チームが検知・対処できるかを確認する。

「ランサムウェア」だけではない　試すべきシナリオとは

　インシデント対応計画を検証する際は、どのようなシナリオを設定するかが重要になる。代表的なのは、ランサムウェア攻撃やフィッシング攻撃、DDoS攻撃、内部不正などだ。

　一方で、近年は「サイバー攻撃そのもの」だけではなく、周辺インフラの障害も重要な検証対象になっている。例えば、停電によってセキュリティシステムが停止した場合や、データセンター火災、インターネット接続断、クラウドの設定ミスなどがある。

　特に企業のITにおいては、「複数の障害が同時に発生する」ケースも想定する必要がある。例えば、「ランサムウェア感染とバックアップ障害」「クラウド設定ミスと情報漏えい」といったシナリオだ。単一の障害を前提にした訓練では、実際の危機対応力を計測できない恐れがある。

IRPの策定ステップ

　テストの準備と実行、結果のレビューには多大な労力を要する。しかし、その努力は実際に障害が発生した際、報われる。以下が、IRPを策定するステップだ。

「訓練がうまくいった」だけでは危険

　テスト実施時には、「何を成功とするか」を事前に定義することが重要だ。例えば、「検知までの時間」「封じ込め完了までの時間」「復旧時間」などを指標化することで、訓練結果を客観的に評価できる。

　テスト後の振り返り（After Action Report）も重要だ。どの対応が機能し、どこに問題があったのかを整理し、インシデント対応計画そのものを更新する。

　ただし、訓練が成功したからといって、実際の攻撃にも対応できるとは限らない。実際のインシデントでは、担当者が強いプレッシャーを受けたり、想定外の事態が発生したりする可能性がある。訓練時には機能した手順が、本番では通用しないケースもある。

　それでも、準備不足のまま本番を迎えるよりははるかに良い。脅威環境が高度化する中、インシデント対応計画のテストは、「やるべきかどうか」ではなく、「どこまで現実に近づけられるか」が問われる段階に入りつつある。