インシデント対応計画の作り方｜CSIRT・初動記録・BCPと復旧訓練

インシデント対応計画は、守る業務と判断・連絡の体制を先に決める

インシデント対応計画は、異常や被害の連絡を受けたときに、誰が状況を確認し、被害拡大の防止、報告、復旧をどう進めるかを準備するものです。文書を作るだけで対応できるとは限らず、対象の業務・システム、必要な権限、社内外の担当を具体化します。本稿の確認表と進め方は、自社の計画を検討するための提案です。個別の攻撃への操作手順や、全組織共通の人員・対応時間を定めるものではありません。

JPCERT/CCのCSIRTマテリアル案内は、CSIRTを組織内の情報セキュリティ問題を専門に扱うインシデント対応チームとして説明しています。また、全組織が同じ機能を全て達成するという考え方ではなく、状況に合う形を検討する資料と位置付けています。専任の大きな組織を置くことと、必要な判断・作業を担える体制を持つことを分けて考えます。

最初に、止まると影響が大きい業務、扱う情報、依存するシステムや委託先を対応させます。メールや認証基盤が使えない場合に、連絡先や手順へアクセスできるかも確かめます。クラウドサービス、取引先との連携、保守用アカウント等は、社内の端末とは別の担当や契約が関わることがあります。資産一覧だけでなく、どの窓口に何を依頼できるかを併せて整理します。

体制には、対応を統括する担当、技術調査・作業の担当、事業の停止・継続を判断する担当、法務・広報・顧客対応等を含めて検討します。役職名を並べるだけでなく、判断できる範囲、不在時の代行、夜間・休日の経路、外部へ依頼できる条件を決めます。監視を委託していても、監視側の検知・連絡と、自社の業務判断や復旧の承認を同じ仕事とみなさず、境界を確認します。

IPAの緊急対応体制の案内も、役割・体制、証拠保全等の初動、通知・開示と演習を扱っています。これらを、自社の担当と実行できる手順へ落とし込みます。手順書の保管先、連絡先の管理者、構成や契約が変わったときの更新担当を決め、必要な人が必要な情報を取り出せる状態を確認します。体制の名称を付けたことだけで、対応能力を評価しないようにします。

初動は、事実と推測を分けて記録し、影響に応じて判断する

IPAのインシデント対応の説明資料は、検知・初動、報告・公表、復旧・再発防止を整理しています。初動では、被害拡大を防ぐ対応と、不用意な操作で記録を失わない配慮が必要です。事前の計画では、誰が何を確認し、どの操作を誰の承認で行うかを対象環境に合わせて決めておきます。

連絡を受けた時点では、分かっている事実、推測、未確認を分けます。検知した日時、対象、画面や通知に出た事象、影響する業務、既に行った操作を記録します。「情報が漏れた可能性がある」と「漏れた情報と範囲を確認した」は違う状態です。不明な項目をゼロや問題なしに置き換えず、次に調べる担当と、判断に必要な情報を明らかにします。

計画で定める観点	記録・確認する内容の例
受付と対象	検知・通報の時刻、受付者、対象の端末・アカウント・サービス、連絡経路
事業への影響	止まっている業務、関係する情報・取引先、影響範囲の確定・未確定
判断と操作	判断者、根拠、承認した操作、実行者・実行時刻、結果と残る問題
証拠と共有	記録の所在、保全の担当、閲覧・共有の範囲、外部専門家へ渡す条件
次の確認	未解決事項、確認担当、次回報告の時点、判断を上げる条件

重大度は、対象の台数やアラート名だけで機械的に決めず、業務の停止、情報の重要性、被害が広がる可能性、外部への影響などから評価します。情報が足りない時に暫定で扱う方法と、状況の変化で上位へ報告する条件を決めます。「軽微なら連絡しない」という運用で判断が止まらないよう、疑いの段階で相談する窓口も用意します。本稿では一律の時間目標や、全件を同じ順番で処理する基準は置きません。

隔離やサービス停止を検討するときは、被害拡大のリスクと停止による影響を判断者へ伝えます。承認を待つ間に許される操作、緊急時の権限と事後の報告も、事前に合意する対象です。実際の調査・保全は対象の環境と状況に応じて技術担当や専門組織と進め、全端末を一律に再起動・初期化する手順にはしません。作業の重複や連絡の食い違いを防ぐため、状況と実行記録を共有する場所を決めます。

報告・公表とBCPをつなぎ、復旧は業務の再開まで確認する

インシデントへの技術対応と、停止中の事業をどう続けるかの判断は連携が必要です。IPAの事業継続・復旧体制の案内は、経営への影響に沿った復旧目標、既存BCPとの連携、優先するシステムの手順と演習を扱っています。セキュリティ担当だけで復旧順序を決めず、事業部門や既存のBCP担当と判断基準を合わせます。

計画には、継続する業務、停止する業務、代替手段、再開を優先する順序を整理します。「いつまでに何を再開したいか」という目標と、現在の構成・人員・委託契約で確認できた復旧能力は別に記載します。バックアップがあることだけで、必要なデータとシステムを業務に使える状態へ戻せるとは判断しません。データをどの時点まで戻す必要があるか、失われた取引等をどう照合・補完するかも検討します。

復旧の確認案として、技術的な修復、必要なデータと連携、権限、主要な業務処理、再開後の監視を分けます。起動できた状態と、受注・請求等を正しく処理できる状態は同じとは限りません。段階的に再開する場合は、対象と制限、判断者、確認する結果、問題が起きたときの対応を決めます。未確認の原因や残るリスクを、復旧完了の報告から落とさないようにします。

顧客・取引先・関係機関への連絡は、判明した事実、現在の影響、実施中の対応、利用者に依頼すること、次の案内を整理します。原因や対象範囲が確定していない段階では、その状態を明示し、誰が内容を確認・承認するかを決めます。個人情報、業法、契約等による報告・通知の対象、期限と必要事項は、個別条件を法務等の担当者へ照合します。一般的な計画のテンプレートだけで全ての法的義務が満たせるとは扱いません。

外部調査・復旧の費用や保険を使う場合は、依頼前の連絡条件、承認、作業記録、請求に必要な資料を契約に沿って確認します。サイバー保険の補償範囲と対応費用の確認点も参照し、保険の条件と技術対応の役割を分けて準備します。保険窓口へ連絡できること、費用が補償されること、業務を復旧できることは、それぞれ確認する事項です。補償の判断だけで必要な被害拡大防止や復旧の検討を止めないようにします。

訓練と見直しは、未解決事項を担当と期限のある改善へつなげる

計画を作成した後は、想定する状況で連絡・判断・作業を実行できるかを確認します。机上で役割を確認する演習と、許可された環境で復旧手順等を試す検証では、目的と準備が異なります。対象、参加者、前提、実施してよい操作、評価する条件を先に定めます。訓練を行った回数だけで実効性を評価せず、連絡が届いたか、必要な情報がそろったか、判断と実行を引き継げたかを記録します。

例えば、認証基盤やメールが使えず、通常の手順書へアクセスできない状況を机上で検討します。誰が代替経路で連絡し、どの資料を使い、何を確認して停止や再開を判断するかを追います。これは本稿の訓練例で、実際のシステム停止を求めるものではありません。取引先や外部窓口を含めた訓練は、相手と実施条件を調整してから行い、実インシデントの通報と混同させないようにします。

振り返りでは、手順がなかった、資料が古かった、権限が足りなかった、判断を上げる先が不明だった、といった問題を分けます。改善内容、担当、確認する時点と完了条件を決め、修正した手順が使えるか再確認します。構成、委託先、組織・担当、扱うデータが変わった場合も見直しの契機にします。全社共通の訓練頻度、固定人数や復旧時間を置かず、自社の影響と確認できていない点から計画します。

AIを記録の要約や対応案の下書きに使う場合も、元の記録、事実と推測、未解決事項を人が照合します。機密情報やログを外部へ送れる条件、閲覧権限、提案と実行の境界を確認します。自動操作は、承認した対象・条件・権限と実行記録を定めて検討し、AIの文章に書かれたことだけを理由に、本番の停止や削除、外部公表を実行しない運用にします。

技術的な弱点と、停止・復旧の手順を具体化する際は、renueのAI脆弱性診断・システム刷新支援へ相談できます。公開案内は、合意した対象・検証環境での診断、改善点の報告、別途範囲を合意する改修・移行・運用と、判断・復旧手順の整備を扱っています。相談時には対象システム、業務への影響、必要な成果物、対応時間と緊急時の連絡範囲を確認します。全事故の無停止・自動復旧、法的判断、保険金や一定の削減効果を保証する案内にはしません。