セキュリティの成熟度を分ける問いは、「侵害されないか」ではありません。「侵害されたとき、どれだけ速く・正しく動けるか」です。完璧な防御は存在しません。だから一流の組織は、「侵害は必ず起きる」という前提に立ち、その瞬間に慌てないための準備に投資します。
その準備の世界標準が、NISTの SP 800-61 です。重要な注意点があります——この指針は2025年4月に大きく刷新されました（Rev.3）。古い記事の多くが解説する「準備 → 検知・分析 → 封じ込め・根絶・復旧 → 事後活動」という独立した4フェーズは、Rev.2（旧版）の枠組みです。本記事は、最新のRev.3に忠実に、インシデント対応の設計を実コード付きで解説します。
この記事の位置づけ： NIST CSF 2.0の**「対応（Respond）」「復旧（Recover）」**を担う中核技能です。職種全体はセキュリティエンジニアになるには、対応の前段（異常に気づく検知）はログ設計・検知エンジニアリング、AWS上の自動対応（SOAR）はGuardDutyの自動インシデント対応を参照してください。
0. NISTがインシデント対応を“刷新”した — Rev.3 の新しい枠組み
NIST SP 800-61 Rev.3（2025年4月最終化）は、旧版「Computer Security Incident Handling Guide」を置き換えました。最大の変更は、インシデント対応を独立した工程ではなく、CSF 2.0のリスク管理の一部（コミュニティプロファイル）として再定義したことです。
なぜ変えたのか。NISTはこう説明します——インシデント対応の“具体的なやり方”は、技術・環境・組織で大きく異なり、変化も速い。だから固定的な手順書として縛るのをやめ、CSF 2.0の機能に沿った“成果（outcomes）”で示すようにした、と。
新しい枠組みは、CSFの6機能を2つの群に整理します。
| 群 | CSF機能 | インシデント対応における意味 |
|---|---|---|
| 準備（Preparation） | 統治（Govern） | 方針・役割・責任・サプライチェーンを定める |
| 識別（Identify） | 資産・リスク・脆弱性を把握する | |
| 防御（Protect） | 防御策を講じ、被害を起きにくくする | |
| 対応（Incident Response） | 検知（Detect） | インシデントを発見し、分析・トリアージする |
| 対応（Respond） | 封じ込め・根絶・関係者への連絡を行う | |
| 復旧（Recover） | 通常業務へ戻し、監視を強化する | |
| 教訓（Lessons Learned） | 識別-改善（Identify: Improvement） | 学びを次の「準備」へ還元する |
この円環が核心です——準備 → 検知 → 対応 → 復旧 → 教訓 → そして教訓が次の準備を強くする。インシデント対応は、一度きりの消火活動ではなく、組織が回し続けるリスク管理のループになりました。以降、この流れに沿って実務を見ます。
1. 準備（Govern / Identify / Protect）— 9割はここで決まる
インシデント対応の成否は、起きる前の準備でほぼ決まります。火事が起きてから消火器の場所を探すようでは遅い。準備すべきものを具体化します。
- CSIRT（対応体制）の定義。 誰が指揮を執り（インシデント指揮官）、誰が技術対応し、誰が法務・広報・経営に連絡するか。役割を、人ではなく“役割”として決めておく（担当者が休暇でも回るように）。
- 連絡網とエスカレーション。 深刻度に応じて、誰に・いつ・どう伝えるか。社外（JPCERT/CC、監督官庁、顧客）への連絡基準も含める。
- 権限の事前付与。 「封じ込めのためにサーバーを隔離する」「鍵をローテーションする」権限を、緊急時に誰が行使できるか。事前に決めておかないと、初動が止まる。
- Runbook（手順書）の整備。 典型的なシナリオ（アカウント侵害、ランサムウェア、データ漏えい等）ごとの対応手順を、後述の“コード”として用意する。
- 訓練。 机上演習（tabletop exercise）で、実際に動けるかを確認する。手順書は、使って初めて穴が見える。
経営層を巻き込むことも準備の一部です。経済産業省のサイバーセキュリティ経営ガイドラインは、インシデント対応体制の整備を経営の責務と位置づけ、付録に体制構築の手引きを用意しています。
2. 検知・トリアージ（Detect）— 深刻度を即断する
異常を検知したら（→ 検知エンジニアリング）、まずトリアージ——「これは本物のインシデントか、誤検知か。本物ならどれだけ深刻か」を素早く判定します。深刻度の基準を事前に決めておくのが肝心です。
| 深刻度 | 例 | 初動 |
|---|---|---|
| Critical | 本番データ漏えい、ランサムウェア、認証基盤の侵害 | 即時にCSIRT招集・指揮官任命・経営連絡 |
| High | 特権アカウントの侵害、重要システムの不正アクセス | 1時間以内に対応開始 |
| Medium | 一般アカウントの侵害、限定的な不正操作 | 当営業日中に対応 |
| Low | 偵察の痕跡、軽微なポリシー違反 | 記録・監視強化 |
トリアージで最も重要なのは、**「迷ったら深刻側に倒す」**ことです。後で「大したことなかった」と分かるのは健全。逆に過小評価して放置するのが、最悪の結果を生みます。
3. 対応（Respond）— 冪等なRunbookで封じ込める
封じ込め（containment）は、被害の拡大を止める最優先の行動です。ここで重要なのが、対応手順を“冪等なコード（Runbook as Code）”として持つことです。手作業はミスを生み、深夜の緊急時には特にミスが増えます。
優れた封じ込めRunbookには、3つの性質が必要です——冪等性（何度実行しても同じ結果）、dry-run（実行前に影響を確認できる）、人間の承認ゲート（破壊的操作は自動実行しない）。
// containment-runbook.ts — アカウント侵害時の封じ込めRunbook。
// 冪等・dry-run・承認ゲートを備え、深夜の緊急時でも安全に実行できる。
import { z } from "zod";
const Options = z.object({
userId: z.string().uuid(),
dryRun: z.boolean().default(true), // ① 既定はdry-run。実行は明示的に。
approvedBy: z.string().optional(), // ② 破壊的操作には承認者が必須。
});
type Options = z.infer<typeof Options>;
interface Step {
readonly name: string;
readonly destructive: boolean; // 破壊的＝承認ゲートを要する
run(userId: string): Promise<void>;
}
// 各ステップは冪等：既に無効化済みでも、再実行で同じ最終状態に収束する。
const STEPS: readonly Step[] = [
{ name: "全セッションを失効", destructive: false,
run: (id) => revokeAllSessions(id) }, // 何度呼んでも「失効済み」に収束
{ name: "APIトークンを失効", destructive: false,
run: (id) => revokeApiTokens(id) },
{ name: "アカウントを一時停止", destructive: true,
run: (id) => suspendAccount(id) }, // 破壊的：承認が要る
{ name: "認証情報の強制リセット", destructive: true,
run: (id) => forcePasswordReset(id) },
];
export async function containAccount(rawOptions: unknown): Promise<void> {
const opts: Options = Options.parse(rawOptions); // 境界で検証
for (const step of STEPS) {
// ③ 破壊的ステップは、承認者なしには実行しない（dry-runでも一貫して警告）。
if (step.destructive && !opts.approvedBy) {
console.warn(`⏸ [承認待ち] ${step.name}（--approvedBy が必要）`);
continue;
}
if (opts.dryRun) {
console.log(`🔍 [dry-run] ${step.name} を実行予定`);
continue; // ④ dry-runでは副作用を起こさず、何が起きるかだけ示す
}
await step.run(opts.userId); // 冪等なので、途中失敗後の再実行も安全
console.log(`✅ ${step.name} 完了`);
}
}
この設計の価値は、**「焦りの中でも、安全側にしか倒れない」**ことです。既定がdry-run、破壊的操作は承認必須、各ステップは冪等——だから、緊急時にコマンドを一つ間違えても、二次被害（正規ユーザーの巻き添えロックなど）を起こしにくい。封じ込めのつもりが、自分でサービスを壊す——これは実際によくある二次災害で、冪等性と承認ゲートがそれを防ぎます。
根絶（eradication）——マルウェアの除去、悪用された脆弱性の修正——は、封じ込めの後に行います。封じ込めずに根絶を急ぐと、証拠を消し、攻撃者に気づかれて被害が拡大します。順序が大切です。
4. 復旧（Recover）— 安全に通常へ戻す
封じ込めと根絶が済んだら、通常業務へ戻します。ここでも慎重さが要ります。
- クリーンな状態から復元する。 侵害された状態のバックアップから戻しては意味がない。侵害前の正常なバックアップを使う（バックアップ/PITRの設計）。
- 段階的に戻す。 一気に全開にせず、監視を強化しながら段階的にサービスを復旧する。
- 監視を強化する。 同じ攻撃者が戻ってこないか、復旧後しばらくは検知の感度を上げる。
- 復旧の完了基準を定める。 「何をもって収束とするか」を曖昧にしない。
復旧は「元に戻す」だけでなく、**「同じ攻撃が二度と通らない状態で戻す」**ことがゴールです。
5. 教訓（Lessons Learned）— 人ではなく仕組みを直す
Rev.3が「識別-改善（Identify: Improvement）」として重視するのが、**事後の振り返り（ポストモーテム）**です。ここが、組織が強くなる唯一の場所です。
最大の原則は、**ブレームレス（blameless：個人を責めない）**であること。「誰がミスしたか」を問う文化では、人は事実を隠し、二度と本当の原因に辿り着けません。問うべきは——
- 何が起きたか（時系列の事実）
- なぜ防げ／気づけなかったか（仕組みの欠陥）
- どうすれば再発しないか（仕組みの改善）
- 検知・対応は速かったか（MTTD/MTTRの計測）
「Aさんがフィッシングに引っかかった」で止めるのではなく、「なぜ1クリックで認証情報を奪われる設計だったのか（MFAは？）」まで掘る。人の注意力ではなく、仕組みの欠陥を直す——この学びが、CSFの円環を通じて次の“準備”を強くします。これこそ、インシデントを「損失」から「投資」に変える分岐点です。
6. 自動化（SOAR）へつなぐ
成熟したら、検知から対応の一部を自動化（SOAR：Security Orchestration, Automation and Response）します。原則は、本記事のRunbookと同じ——「通知は広く、封じ込めは限定的に、破壊は人間の承認を通す」。
たとえばAWSなら、GuardDutyの検知をEventBridgeで受け、Lambda/Step Functionsで冪等な初動（通知・隔離）を自動化し、破壊的操作だけ人間の承認を挟む、という設計が定石です。具体的な実装はGuardDutyの自動インシデント対応（SOAR）にまとめています。自動化しても、冪等性と承認ゲートという安全装置は外さない——これが鉄則です。
8. まとめ
インシデント対応は、「侵害は必ず起きる」という前提に立つ大人の備えです。
- 準備が9割。 CSIRTの役割・連絡網・権限・Runbook・訓練を、起きる前に整える。
- NISTの新枠組み（Rev.3）に沿う。 インシデント対応はCSF 2.0のリスク管理の一部。準備（統治・識別・防御）と対応（検知・対応・復旧）の円環。
- トリアージは深刻側に倒す。 深刻度基準を事前に定め、迷ったら重く見る。
- 封じ込めは冪等なRunbookで。 dry-run・承認ゲート・冪等性で、焦りの中でも安全側に倒す。
- 教訓で仕組みを直す。 ブレームレスなポストモーテムで、人ではなく設計の欠陥を直し、次の準備に還す。
インシデント対応の体制づくり、Runbookの整備、机上演習の設計を伴走してほしい——あるいはリリース前に「いざという時、本当に動けるか」を点検したい場合は、お気軽にご相談ください。「速く作る力」と同じく、「正しく対応できる備え」も、事業の継続性を支える投資です。