# インシデント対応 実践ガイド【2026年版】NIST SP 800-61 Rev.3（CSF 2.0）に沿うCSIRT・Runbook・自動封じ込め

> セキュリティインシデント対応（IR）を本番品質で設計するための実践ガイド。2025年に刷新されたNIST SP 800-61 Rev.3（CSF 2.0 Community Profile）の新しい枠組みを軸に、CSIRT体制、深刻度トリアージ、冪等な封じ込めRunbook、ブレームレスなポストモーテム、SOAR自動化までを、公式情報に忠実な実コードで解説します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: セキュリティ, インシデント対応, CSIRT, NIST, セキュリティエンジニア
- URL: https://tomodahinata.com/blog/incident-response-nist-800-61r3-csirt-runbook-playbook-production-guide
- カテゴリ: セキュリティエンジニア・キャリア
- 総合ガイド: https://tomodahinata.com/blog/security-engineer-how-to-become-roadmap-skills-certification-guide

## 要点

- 侵害は『起きるか』ではなく『いつ起きるか』。準備の質が、被害規模と復旧速度を決める。インシデント対応の9割は“起きる前”の設計で決まる
- NISTは2025年4月にインシデント対応指針を刷新（SP 800-61 Rev.3）。従来の独立した4フェーズを廃し、CSF 2.0の6機能（統治・識別・防御・検知・対応・復旧）に統合した『コミュニティプロファイル』として再定義した
- 新しい枠組みは2つの群：『準備』＝統治・識別・防御＋教訓（継続改善）と、『対応』＝検知・対応・復旧。インシデント対応はリスク管理の一部であり、組織全体で回す営みになった
- 封じ込めは“冪等なRunbook”として実装する。何度実行しても同じ結果になり、破壊的操作は人間の承認ゲートを通す。dry-runで影響を確認してから実行する設計が、二次被害を防ぐ
- 復旧後の『教訓（Lessons Learned）』が最重要。ブレームレス（個人を責めない）ポストモーテムで、人ではなく仕組みの欠陥を直す。これがCSFの『識別-改善』として次の準備に還る

---

セキュリティの成熟度を分ける問いは、「侵害されないか」ではありません。**「侵害されたとき、どれだけ速く・正しく動けるか」**です。完璧な防御は存在しません。だから一流の組織は、**「侵害は必ず起きる」という前提**に立ち、その瞬間に慌てないための準備に投資します。

その準備の世界標準が、NISTの **[SP 800-61](https://csrc.nist.gov/pubs/sp/800/61/r3/final)** です。重要な注意点があります——**この指針は2025年4月に大きく刷新されました（Rev.3）**。古い記事の多くが解説する「準備 → 検知・分析 → 封じ込め・根絶・復旧 → 事後活動」という独立した4フェーズは、**Rev.2（旧版）の枠組み**です。本記事は、**最新のRev.3**に忠実に、インシデント対応の設計を実コード付きで解説します。

> **この記事の位置づけ：** NIST CSF 2.0の**「対応（Respond）」「復旧（Recover）」**を担う中核技能です。職種全体は[セキュリティエンジニアになるには](/blog/security-engineer-how-to-become-roadmap-skills-certification-guide)、対応の前段（異常に気づく検知）は[ログ設計・検知エンジニアリング](/blog/security-logging-detection-engineering-sigma-mitre-attack-siem-guide)、AWS上の自動対応（SOAR）は[GuardDutyの自動インシデント対応](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)を参照してください。

---

## 0. NISTがインシデント対応を“刷新”した — Rev.3 の新しい枠組み

[NIST SP 800-61 Rev.3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)（2025年4月最終化）は、旧版「Computer Security Incident Handling Guide」を置き換えました。最大の変更は、**インシデント対応を独立した工程ではなく、[CSF 2.0](/blog/security-engineer-how-to-become-roadmap-skills-certification-guide)のリスク管理の一部（コミュニティプロファイル）として再定義した**ことです。

なぜ変えたのか。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](https://www.jpcert.or.jp/)、監督官庁、顧客）への連絡基準も含める。
- **権限の事前付与。** 「封じ込めのためにサーバーを隔離する」「鍵をローテーションする」権限を、緊急時に誰が行使できるか。事前に決めておかないと、初動が止まる。
- **Runbook（手順書）の整備。** 典型的なシナリオ（アカウント侵害、ランサムウェア、データ漏えい等）ごとの対応手順を、後述の“コード”として用意する。
- **訓練。** 机上演習（tabletop exercise）で、実際に動けるかを確認する。手順書は、使って初めて穴が見える。

経営層を巻き込むことも準備の一部です。[経済産業省のサイバーセキュリティ経営ガイドライン](https://www.meti.go.jp/policy/netsecurity/mng_guide.html)は、インシデント対応体制の整備を経営の責務と位置づけ、付録に体制構築の手引きを用意しています。

---

## 2. 検知・トリアージ（Detect）— 深刻度を即断する

異常を検知したら（→ [検知エンジニアリング](/blog/security-logging-detection-engineering-sigma-mitre-attack-siem-guide)）、まず**トリアージ**——「これは本物のインシデントか、誤検知か。本物ならどれだけ深刻か」を素早く判定します。深刻度の基準を**事前に**決めておくのが肝心です。

| 深刻度 | 例 | 初動 |
|---|---|---|
| **Critical** | 本番データ漏えい、ランサムウェア、認証基盤の侵害 | 即時にCSIRT招集・指揮官任命・経営連絡 |
| **High** | 特権アカウントの侵害、重要システムの不正アクセス | 1時間以内に対応開始 |
| **Medium** | 一般アカウントの侵害、限定的な不正操作 | 当営業日中に対応 |
| **Low** | 偵察の痕跡、軽微なポリシー違反 | 記録・監視強化 |

トリアージで最も重要なのは、**「迷ったら深刻側に倒す」**ことです。後で「大したことなかった」と分かるのは健全。逆に過小評価して放置するのが、最悪の結果を生みます。

---

## 3. 対応（Respond）— 冪等なRunbookで封じ込める

封じ込め（containment）は、**被害の拡大を止める**最優先の行動です。ここで重要なのが、**対応手順を“冪等なコード（Runbook as Code）”として持つ**ことです。手作業はミスを生み、深夜の緊急時には特にミスが増えます。

優れた封じ込めRunbookには、3つの性質が必要です——**冪等性**（何度実行しても同じ結果）、**dry-run**（実行前に影響を確認できる）、**人間の承認ゲート**（破壊的操作は自動実行しない）。

```ts
// 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の設計](/blog/postgresql-backup-pitr-pg-dump-wal-archiving-guide)）。
- **段階的に戻す。** 一気に全開にせず、監視を強化しながら段階的にサービスを復旧する。
- **監視を強化する。** 同じ攻撃者が戻ってこないか、復旧後しばらくは検知の感度を上げる。
- **復旧の完了基準を定める。** 「何をもって収束とするか」を曖昧にしない。

復旧は「元に戻す」だけでなく、**「同じ攻撃が二度と通らない状態で戻す」**ことがゴールです。

---

## 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）](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)にまとめています。自動化しても、**冪等性と承認ゲートという安全装置は外さない**——これが鉄則です。

---

## 7. よくある質問（FAQ）

**Q. 小さな会社でもCSIRTは必要ですか？**
A. 専任チームは不要でも、**「インシデント時に誰が何をするか」を決めておく**ことは必須です。一人が複数の役割を兼ねてもよい。重要なのは、緊急時に「で、誰が決めるの？」とならない状態を作ることです。

**Q. 旧版（4フェーズ）の知識は無駄になりますか？**
A. なりません。「準備・検知・封じ込め・復旧・教訓」という実務の流れ自体は今も有効です。Rev.3はそれを**CSF 2.0のリスク管理に統合し、組織全体の営みとして位置づけ直した**もの。考え方は地続きです。

**Q. インシデント発生時、まず何をすべき？**
A. (1) 落ち着いて深刻度をトリアージし、(2) 指揮官を一人決め、(3) 記録を取り始める。慌てて手を動かす前に、**「誰が指揮し、何を記録するか」**を確立するのが初動の質を決めます。

**Q. 個人情報漏えいが疑われたら？**
A. 日本では個人情報保護委員会への報告義務（速報・確報）や本人通知が法定されています。**法務・広報を早期に巻き込み**、JPCERT/CCや専門家に相談を。技術対応と並行して、法的・対外的対応を進める必要があります。

**Q. Runbookはどのくらい用意すべき？**
A. まずは発生確率の高いシナリオ（アカウント侵害、フィッシング、ランサムウェア、公開漏えい）から。全部を最初から揃える必要はありません。一つ作って訓練で回し、穴を埋めながら増やすのが現実的です。

---

## 8. まとめ

インシデント対応は、**「侵害は必ず起きる」という前提**に立つ大人の備えです。

- **準備が9割。** CSIRTの役割・連絡網・権限・Runbook・訓練を、起きる前に整える。
- **NISTの新枠組み（Rev.3）に沿う。** インシデント対応はCSF 2.0のリスク管理の一部。準備（統治・識別・防御）と対応（検知・対応・復旧）の円環。
- **トリアージは深刻側に倒す。** 深刻度基準を事前に定め、迷ったら重く見る。
- **封じ込めは冪等なRunbookで。** dry-run・承認ゲート・冪等性で、焦りの中でも安全側に倒す。
- **教訓で仕組みを直す。** ブレームレスなポストモーテムで、人ではなく設計の欠陥を直し、次の準備に還す。

インシデント対応の体制づくり、Runbookの整備、机上演習の設計を伴走してほしい——あるいはリリース前に「いざという時、本当に動けるか」を点検したい場合は、お気軽にご相談ください。「速く作る力」と同じく、「正しく対応できる備え」も、事業の継続性を支える投資です。

---

### 参考（公式一次情報）

- インシデント対応：[NIST SP 800-61 Rev.3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)／[NIST Incident Response プロジェクト](https://csrc.nist.gov/projects/incident-response)
- フレームワーク：[NIST CSF 2.0](https://www.nist.gov/cyberframework)
- 国内：[JPCERT/CC](https://www.jpcert.or.jp/)／[経済産業省 サイバーセキュリティ経営ガイドライン](https://www.meti.go.jp/policy/netsecurity/mng_guide.html)
- 関連：[ログ設計・検知エンジニアリング](/blog/security-logging-detection-engineering-sigma-mitre-attack-siem-guide)／[GuardDuty 自動インシデント対応](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)