NIST SP 800-61 Rev.3とは？要点とRev.2との違い、CSF 2.0に沿うインシデント対応・CSIRT・Runbook実践ガイド【2026年版】

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

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

この記事の位置づけ： NIST CSF 2.0の「対応（Respond）」「復旧（Recover）」を担う中核技能です。職種全体はセキュリティエンジニアになるには、対応の前段（異常に気づく検知）はログ設計・検知エンジニアリング、AWS上の自動対応（SOAR）はGuardDutyの自動インシデント対応を参照してください。

NIST SP 800-61 Rev.3とは — 発行日・範囲・構成・Rev.2との違い

先に結論です。NIST SP 800-61 Rev.3（NIST SP 800-61r3）は、NISTが2025年4月に最終版を公開したインシデント対応の指針で、2012年8月のRev.2を置き換えました。細かな手順書ではなく、CSF 2.0の機能に沿って「インシデント対応のために何を優先して整えるか」を示すCSF 2.0コミュニティプロファイルです。

基本情報

範囲 — 手順を一冊に固定するのをやめた

Rev.3は、スコープが旧版と大きく異なると自ら書いています。インシデント対応の具体的なやり方は変化が速く、技術・環境・組織によって大きく異なるため、それを「1冊の静的な出版物に収めて維持することは、もはや現実的ではない」（"it is no longer feasible to capture and maintain that information in a single static publication"）。代わりに、CSF 2.0の全機能にわたるリスク管理を改善することで、組織のインシデント対応能力を支える、という方針です。

実装の細部は文書の外に出しました。参考リンクの大半はNISTのIncident Responseプロジェクトページへ移され、CSF 2.0の成果とSP 800-53の管理策などの対応づけは、CPRT（Cybersecurity and Privacy Reference Tool）で参照する形です。

構成

• 第2章：リスク管理の一部としてのインシデント対応（ライフサイクルモデル、役割と責任、ポリシー・プロセス・手順）
• 第3章：CSF 2.0コミュニティプロファイル本体。表2「準備と教訓」（統治・識別・防御と、識別の改善カテゴリ）と、表3「インシデント対応」（検知・対応・復旧）の2表
• 付録：略語一覧、用語集、変更履歴（付録C）

表2と表3では、CSFの機能・カテゴリ・サブカテゴリが1行ずつ並び、それぞれにインシデント対応上の優先度（High／Medium／Low）が付きます。最後の列の項目はIDの頭文字で種類が分かれ、Rは推奨事項（すべきこと）、Cは考慮事項（検討すべきこと）、Nは注記です。たとえば GV.OC-03.R1 は、サブカテゴリGV.OC-03の推奨事項1を指します。

CSF 2.0の6機能との対応

Rev.3は、統治・識別・防御の準備活動を「インシデント対応そのものの一部ではなく、それを支える、より広いサイバーセキュリティリスク管理活動」と位置づけています。旧版の4フェーズとの対応は、本文の表1にこうまとめられています。

Rev.2との主な違い

Rev.2側の欄は、Rev.3の本文（2.1節・2.2節）と付録Cの変更履歴が旧版について説明している内容に基づきます。付録Cは、全面的な書き直し、焦点の転換、CSF 2.0コミュニティプロファイルへの再編、リンクのプロジェクトサイトへの移設、最新テンプレートへの書式変更を挙げています。

日本語訳はあるか

あります。IPAの「セキュリティ関連NIST文書について」に、邦題「サイバーセキュリティリスクマネジメントにおけるインシデント対応の推奨事項と考慮事項」としてSP 800-61 Rev. 3のPDFが2025年9月に掲載されています。IPAは翻訳にあたってNISTから事前に承諾を得ていると説明していますが、訳文の冒頭には「本翻訳は米国政府または NIST の公式な翻訳ではない」と明記されています。公式版はNISTの英語版なので、解釈に迷う箇所は原文で確かめてください。

どう使うか

1. ライフサイクルモデルは自社に合うものでよい。 Rev.3は「組織は自らに最も合うインシデント対応ライフサイクルのフレームワークやモデルを使うべき」としています。旧4フェーズで回している運用を捨てる必要はありません。
2. 表2・表3を出発点にして、自社向けに調整する。 優先度は組織ごとの出発点として示されたもので、自社の優先度とニーズに合わせて変えることが推奨されています。推奨事項や考慮事項は網羅的ではなく、すべてが自社に当てはまるわけでもありません。
3. よくあるインシデントの手順を文書化し、Playbookにする。 Rev.3は、最も一般的な種類のインシデントや脅威への対応手順は文書化を検討すべき（should consider）とし、主要な認証基盤の再展開のように緊急時に急ぎ必要になる特に重要なプロセスについては、手順を整備し維持すべき（should also develop and maintain）としています。Playbookの例としてCISAのPlaybookを紹介しています。
4. 実装の細部はプロジェクトページとCPRTで引く。 本文に書かれていない具体策は、前述のオンライン資料で補う設計です。

以降の章は、この枠組みを実務に落とした内容です。体制（CSIRT）と準備、トリアージ、冪等な封じ込めRunbook、復旧、ポストモーテムの順に見ていきます。

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

前節で見たとおり、Rev.3はインシデント対応をCSF 2.0のリスク管理の一部（コミュニティプロファイル）として位置づけ直しました。実務の観点では、CSFの6機能を次のように読み替えると整理しやすくなります。

ここが核心です——準備 → 検知 → 対応 → 復旧の各段階で得た教訓が改善（ID.IM）に集まり、すべての機能を強くする。教訓は最後にまとめて戻すものではなく、いつでも生まれ、見つかり次第共有されます。インシデント対応は、一度きりの消火活動ではなく、組織が回し続けるリスク管理のループになりました。以降、この流れに沿って実務を見ます。

スポンサーリンク

1. 準備（Govern / Identify / Protect）— 9割はここで決まる

インシデント対応の成否は、起きる前の準備でほぼ決まります。火事が起きてから消火器の場所を探すようでは遅い。準備すべきものを具体化します。

• CSIRT（対応体制）の定義。 誰が指揮を執り（インシデント指揮官）、誰が技術対応し、誰が法務・広報・経営に連絡するか。役割を、人ではなく“役割”として決めておく（担当者が休暇でも回るように）。
• 連絡網とエスカレーション。 深刻度に応じて、誰に・いつ・どう伝えるか。社外（JPCERT/CC、監督官庁、顧客）への連絡基準も含める。
• 権限の事前付与。 「封じ込めのためにサーバーを隔離する」「鍵をローテーションする」権限を、緊急時に誰が行使できるか。事前に決めておかないと、初動が止まる。
• Runbook（手順書）の整備。 典型的なシナリオ（アカウント侵害、ランサムウェア、データ漏えい等）ごとの対応手順を、後述の“コード”として用意する。
• 訓練。 机上演習（tabletop exercise）で、実際に動けるかを確認する。手順書は、使って初めて穴が見える。

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

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

異常を検知したら（→ 検知エンジニアリング）、まずトリアージ——「これは本物のインシデントか、誤検知か。本物ならどれだけ深刻か」を素早く判定します。深刻度の基準を事前に決めておくのが肝心です。

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

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）」として重視するのが、事後の振り返り（ポストモーテム）です。ここが、学びを仕組みの改善に変える中心の場です。なおRev.3は、教訓は復旧の完了を待たず、見つかり次第共有すべきことが多いとも述べています。ポストモーテムは最後のまとめの場であって、学びを溜めておく場ではありません。

最大の原則は、ブレームレス（blameless：個人を責めない）であること。「誰がミスしたか」を問う文化では、人は事実を隠し、二度と本当の原因に辿り着けません。問うべきは——

• 何が起きたか（時系列の事実）
• なぜ防げ／気づけなかったか（仕組みの欠陥）
• どうすれば再発しないか（仕組みの改善）
• 検知・対応は速かったか（MTTD/MTTRの計測）

「Aさんがフィッシングに引っかかった」で止めるのではなく、「なぜ1クリックで認証情報を奪われる設計だったのか（MFAは？）」まで掘る。人の注意力ではなく、仕組みの欠陥を直す——この学びが、改善（ID.IM）を通じてすべての機能を強くします。これこそ、インシデントを「損失」から「投資」に変える分岐点です。

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のリスク管理の一部。準備（統治・識別・防御）と対応（検知・対応・復旧）を、改善（ID.IM）がつなぐループ。
• トリアージは深刻側に倒す。 深刻度基準を事前に定め、迷ったら重く見る。
• 封じ込めは冪等なRunbookで。 dry-run・承認ゲート・冪等性で、焦りの中でも安全側に倒す。
• 教訓で仕組みを直す。 ブレームレスなポストモーテムで、人ではなく設計の欠陥を直し、すべての機能に反映する。

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

参考（公式一次情報）

• インシデント対応：NIST SP 800-61 Rev.3／NIST Incident Response プロジェクト
• フレームワーク：NIST CSF 2.0
• 国内：JPCERT/CC／経済産業省 サイバーセキュリティ経営ガイドライン
• 関連：ログ設計・検知エンジニアリング／GuardDuty 自動インシデント対応