インシデント対応とは — 初動・封じ込め・復旧の判断と記録

インシデント対応とは：被害拡大と業務影響を抑える活動

インシデント対応は、異常の確認、封じ込め、調査、復旧、改善を責任者の指揮で進める活動です。まず報告と被害拡大防止を並行し、観測した事実と実施した操作を記録します。原因を確定するまで連絡・隔離を待つ必要はありません。

対象は情シス、開発者、SaaS管理者、初動報告を受ける管理者です。人の安全、重要設備、業務固有の停止・復旧手順は一般的な教材より優先してください。

• 被害拡大防止

  端末・アカウント・共有への影響を、許可された手段で抑える。

• 責任者へ連絡

  誰が指揮し、停止・通知・復旧を承認するかを明確にする。

• 事実と操作を記録

  時刻、対象、根拠、変更、未確認事項を残す。秘密は転載しない。

NIST SP 800-61 Rev.3とCSF 2.0の関係

NIST SP 800-61 Rev.3は2025年4月に確定し、Rev.2を置き換えました。CSF 2.0の6機能にインシデント対応を結び付け、準備や改善を組織のリスク管理へ組み込みます。

CSF 2.0のGOVERN・IDENTIFY・PROTECTは準備を支え、DETECT・RESPOND・RECOVERは検知・対応・回復を扱います。6機能は、時間順に1回ずつ終わらせる工程ではありません。

以下の6つは教材上の作業区分です。「NIST Rev.3が定義する6段階のライフサイクル」と同一視しないでください。

現場で確認する6つの作業区分

作業	確認すること	記録・承認
準備	連絡先、権限、手順、バックアップ、代替連絡手段	所有者、訓練結果、未整備事項
検知・分析	何が起きたか、影響対象、根拠ログ	事実・仮説・未確認を分ける
封じ込め	拡大している経路、隔離・失効の影響	実施者、時刻、対象、承認
原因の除去	侵入経路、不正設定、残るアクセス	修正対象と再確認結果
復旧	復元元、隔離環境、業務の正常性	再開条件と承認者
改善	連絡・検知・復旧の不足	担当者、期限、再演習

調査の進展で前の作業へ戻ることもあります。複数端末や複数SaaSでは作業の状態が異なるため、全体を一律に「復旧フェーズ」として扱わないでください。

初動でまず確認するチェックリスト

• 発見時刻・タイムゾーン、対象端末・アカウント・サービス。
• 現在も被害が広がっているか、人や設備の安全に影響があるか。
• 自分に隔離・停止・失効を実施する権限があるか。
• 指揮責任者と連絡先、通常のメールが使えない場合の代替経路。
• 証跡が失われる期限、ログ保持期間、取得に必要な権限。
• 外部委託、法務、個人情報、契約上の連絡判断が必要か。

ランサムウェア初動、アカウント侵害の兆候など、事象に合った手順へ切り替えます。

電源を切るか：一律の禁止ではなく責任者が判断する

電源断でRAMなどの揮発性情報を失う可能性があります。可能なら、承認された手段でネットワーク隔離と証跡保全を進めます。ただし隔離できず被害が広がり続ける場合まで、絶対に電源を切らないとは決めません。

被害拡大、証跡喪失、人の安全、業務・設備への影響を踏まえ、緊急手順に従って責任者が判断します。高度なメモリ取得を未経験者が独断で行うと、対応遅延や証跡変更につながります。証跡保全の初動で役割を整理してください。

復旧の完了条件を先に決める

復元できたことと、業務を再開できることは別です。侵入経路への対処、復元元の確認、権限・連携設定、監視、業務データの整合性を担当者が確認します。未確認のまま元のネットワークへ一斉接続しません。

RTO・RPOと復旧テストを事前に検証しておくと判断材料がそろいます。

記録テンプレートとやってはいけないこと

発見時刻・タイムゾーン:
対象・所有者:
観測した事実・根拠:
業務／安全への影響:
指揮責任者・連絡状況:
実施した操作・時刻・承認:
未確認事項・次の確認:
復旧の条件・承認者:

証跡を独断で削除しない、未知のツールを感染端末へ追加しない、秘密情報を通常のチケットに貼らない、被害規模や原因を根拠なしに確定しないことが重要です。振り返りは報告者を責めるのではなく、仕組みと手順の改善へつなげます。

机上演習ガイドで、指揮・承認・代替連絡経路を事前に練習できます。