「想定外の複合障害」に情シスはどう動く？ インシデント対応計画の実践アプローチ：情シスが見直すべき「訓練の現実性」

サイバー攻撃が増加する中、企業ではインシデント対応計画（IRP）の整備を進める必要がある。しかし、計画を策定しただけでは実際の攻撃に対応できるとは限らない。IRPを有効にするためのポイントを紹介する。

[Paul Kirvan，TechTarget]

　「インシデント対応計画は作ったが、実際に機能するのか分からない」「訓練はしているが、実際の攻撃時に対応できる自信がない」――。ランサムウェアやサプライチェーン攻撃が増加する中、企業の情報システム部門（以下、情シス）では、インシデント対応計画（IRP：Incident Response Plan）の整備を進めているところがある。しかし、「計画を作ること」と「実際に機能すること」は別問題だ。

　そこで重要になるのが「計画をテストすること」だ。本稿では、事業継続、災害復旧の専門家であるポール・カーバン氏が、テスト実施の基本ステップや成功のかぎを紹介する。

インシデント対応計画は「作る」だけでは不十分

併せて読みたいお薦め記事

サイバー攻撃の関連記事

• 保険会社すら防げない？　「身代金支払い」を巡るサイバー保険の“残酷な現実”
• サイバー攻撃被害額10億円超の企業の特徴は？　調査結果から見る情シスの“傾向と対策”

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

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

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

TTX：机上演習

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

Functional Exercise：機能演習

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

Full-scale simulations：全機能演習

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

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

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

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

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

IRPの策定ステップ

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

ステップ	フェーズ	主体	実施内容	目的
1.	テスト範囲決定	セキュリティ担当／情シス	既存のインシデント対応計画を評価し、異常検知、封じ込め、復旧など何をテストするか決める	テスト対象を明確化する
2.	テスト計画策定	情シス／CSIRT	参加者、必要リソース、実施条件を整理したテスト計画書を作成する	実施体制を整える
3.	成功基準設定	情シス／管理職	検知時間、対応時間、復旧時間など評価指標を定義する	成果を測定できるようにする
4.	経営レビュー	経営層	テスト目的や範囲が組織方針に合致しているか確認する	経営承認を得る
5.	シナリオ準備	進行役／ベンダー	テスト用スクリプトや攻撃シナリオを準備する	訓練を円滑化する
6.	環境確認	IT運用担当	検知システムやネットワーク機器が正常に動作するか確認する	テスト失敗を防ぐ
7.	関係者通知	情シス／管理職	IT部門や業務部門、経営層に実施を通知する	混乱を防ぐ
8.	役割共有	CSIRT／進行役	各メンバーの役割と責任を事前共有する	対応漏れを防ぐ
9.	リハーサル	情シス／テストチーム	本番影響のない環境で試験実施や事前確認を行う	不備を洗い出す
10.	テスト実施	進行役／参加者	シナリオ提示、対応実施、議論を進める	実際の対応力を検証する
11.	記録・監視	記録担当	作業内容や対応時間を記録し、必要に応じて中断判断する	後で分析可能にする
12.	振り返り	全参加者	デブリーフィングを実施し、問題点を整理する	改善点を抽出する
13.	報告書作成	情シス／CSIRT	実施後レポートを管理職へ提出する	経営へ共有する
14.	計画改善	情シス／CSIRT	得られた教訓を基に計画を修正し、再テストする	継続的改善を実現する

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

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

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

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

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