インシデント対応プレイブック完全ガイド
「やられたかもしれない」——その瞬間に、何を・どの順番で・誰に動かすか。ランサムウェア／ビジネスメール詐欺（BEC）／不正アクセスの初動手順を、日本の報告義務まで含めて“そのまま使える手順書”にまとめました。パニックの最中に正しく動くための、平時に読む地図です。
📋 このプレイブックの目次
サイバーインシデントは、もはや「起きるかどうか」ではなく「いつ起きるか」の問題です。そして被害の大きさを最終的に左右するのは、攻撃の高度さよりも「最初の数時間に、どれだけ正しく動けたか」。慌てて端末を再起動して証拠を消してしまう、独断で身代金を払ってしまう、報告すべき相手に報告しない——こうした“善意の誤対応”が被害を何倍にも広げます。プレイブック（対応手順書）とは、その判断を平時のうちに前倒しで決めておくための地図です。このページは、当サイトのDFIR・デジタルフォレンジック完全ロードマップの実践編として、代表的な3つのインシデントの初動を、日本の現場で使える形に落とし込みます。
本記事は、あなた自身が管理する、または明示的に対応を任された組織・システムを守るための防御者向けガイドです。調査で使うコマンドやツールは、許可された範囲でのみ用いてください。また、ここに書く手順は「考え方の型」であり、実際の重大インシデントでは、自社の体制・契約・法令に沿って、必要に応じて専門のインシデント対応（DFIR）事業者・弁護士・警察・JPCERT/CCと連携してください。迷ったら、証拠を壊す前に手を止めて相談する——それが最善手です。
🧭 インシデント対応とは？ 全体像とNIST最新動向
個別の手順に入る前に、「対応全体がどんな流れで進むのか」という共通言語を持ちましょう。
インシデント対応（IR）＝被害を最小化し、復旧し、次に活かす一連の活動
インシデント対応（Incident Response, IR）とは、サイバー攻撃や情報漏えいなどの「セキュリティ事故」が起きたとき（あるいは起きた疑いがあるとき）に、被害を食い止め・原因を突き止め・元の状態に戻し・再発を防ぐまでの一連の活動です。これを担うチームをCSIRT（シーサート／Computer Security Incident Response Team）と呼びます。専任チームがなくても、「誰が・何を・どの順で動くか」を決めておくこと自体がIRの第一歩です。
IRには、世界中の現場で共有されている“型”があります。最も広く参照されるのが、米国NISTのSP 800-61「インシデント対応ガイド」です。長年使われてきた旧版（Revision 2）は、対応を次の4つのフェーズに整理していました。これは今でも、初学者が流れをつかむのに最適な枠組みです。
🔄 インシデント対応ライフサイクル（NIST SP 800-61 の4フェーズ）
そして2025年4月、NISTはこのSP 800-61を約10年ぶりに大改訂し、Revision 3を公開しました。新版の最大の変化は、固定的な「4フェーズの直線」をやめ、サイバーセキュリティフレームワーク（CSF）2.0の6つの機能——統治（Govern）／識別（Identify）／防御（Protect）／検知（Detect）／対応（Respond）／復旧（Recover）に対応づけた点です。インシデント対応を「事故が起きてから走る特別作業」ではなく、組織のリスク管理サイクルの一部として、平時から継続的に改善し続けるものと位置づけ直したのです。とはいえ実務の初動では、上の4フェーズの感覚——備える→気づく→止める→学ぶ——がそのまま役に立ちます。本記事もこの流れに沿って進めます。
プレイブックの本質は「判断を平時に前借りする」こと
インシデントの最中は、時間も情報も人手も足りず、強いストレスがかかります。その状態で「電源は切るべき？」「誰に連絡？」「公表する？」を一から考えるのは危険です。プレイブックは、冷静なときに下した良い判断を、緊急時のあなたに渡しておく仕組み。だから“立派な分厚い文書”より、1枚で見渡せて、本当に使われるものが勝ちます。
⏱ 全インシデント共通の初動7原則（最初の1時間）
ランサムでもBECでも、最初に守るべき“型”は同じ。これを外すと、後の調査と復旧が台無しになります。
インシデントの種類が何であれ、発覚直後の「ゴールデンタイム（最初の1時間）」の動き方には共通の原則があります。ここでの目的はただ一つ——「被害をこれ以上広げず、かつ、原因を突き止めるための証拠を壊さない」。この2つはしばしば対立します（例：すぐ電源を切れば暗号化は止まるが、メモリ上の証拠は消える）。だからこそ、順番と原則が大切です。
①まず記録
時刻・気づいた経緯・画面をメモ＆撮影。対応自体の記録を取り始める
②落ち着く
過剰反応も過小評価もNG。まず事実を集め、影響範囲を見立てる
③隔離する
ネットワークから切り離す。ただし電源は安易に切らない
④証拠保全
消えやすい順（メモリ→通信→ディスク）に確保する
⑤連絡する
報告ライン・経営層・必要なら外部専門家へエスカレーション
⑥刺激しない
攻撃者が見ている前提で。不用意な操作・通知で気取られない
⑦独断しない
消さない・払わない・勝手に公表しない。重大判断は組織で
特に判断を誤りやすいのが③と④の関係です。「感染したらコンセントを抜け」と聞いたことがあるかもしれませんが、現代のDFIRでは原則として、いきなり電源を切ることは推奨されません。電源を切ると、メモリ（RAM）上にしか存在しない暗号鍵・実行中のマルウェア・ネットワーク接続・攻撃者の痕跡といった「揮発性の高い証拠」が永久に失われるからです。被害拡大を止めたいなら、まずネットワークからの隔離（LANケーブルを抜く／Wi-Fiを無効化／スイッチで遮断）を行い、端末は通電したまま保全するのが基本です。
「とりあえず再起動」「念のためシャットダウン」は、証拠破壊の典型的な初動ミスです。再起動でメモリは消え、一時ファイルは上書きされ、攻撃の全体像が霧の中に消えます。被害を止めたいときは、まずネットワーク隔離。電源断は「暗号化や破壊がリアルタイムで進行し、隔離だけでは止められない」といった例外的な場合に限り、判断と理由を記録した上で行います。可能なら、その前にメモリの取得（ライブフォレンジック）を。証拠を「消えやすい順」に確保する考え方は、DFIRロードマップの「証拠の揮発性順序（RFC 3227）」で図解しています。
| 場面 | ❌ やりがちな誤対応 | ✅ 正しい初動 |
|---|---|---|
| 被害を止めたい | いきなり電源OFF・再起動 | まずネットワークから隔離（通電は維持） |
| 不審ファイルを見つけた | ダブルクリックして中身を確認 | 開かない。ハッシュ値・パス・時刻を記録し保全 |
| マルウェアを消したい | その場でウイルス対策ソフトで駆除・削除 | 範囲を特定するまで保全優先。駆除は根絶フェーズで計画的に |
| 原因を調べたい | 本番環境で手当たり次第にコマンド実行 | 変更を最小化し、操作と時刻をすべて記録 |
| 関係者に伝えたい | 侵害された社内メール・チャットで共有 | 攻撃者に見られない別経路（電話・別系統）で連絡 |
| 早く元に戻したい | 原因不明のままバックアップから即復旧 | 侵入経路を塞いでから復旧（塞がないと再感染） |
「記録」はあなた自身を守る
誰が・いつ・何をしたかの対応ログ（アクションログ）は、後の原因究明だけでなく、「適切に対応した」ことを示す証拠になります。時系列メモ、実行コマンド、スクリーンショット、関係者とのやり取りを残しましょう。時刻のズレは混乱のもとなので、時計の基準（タイムゾーン）も明記します。最初の調査コマンドは、OS標準のフォレンジックコマンドやセキュリティ調査コマンドの記事が役立ちます。
🦠 ランサムウェア対応プレイブック
暗号化は「最終段階」。気づいたときには侵入から時間が経っていることが多い。だからこそ初動の型が効きます。
ランサムウェアは、ファイルを暗号化して身代金を要求するマルウェアです。近年の主流は、単に暗号化するだけでなくデータを盗み出してから暗号化し、「払わなければ公開する」と脅す「二重恐喝（ダブルエクストーション）」。つまり、暗号化が見えた時点で、すでに侵入・横展開・データ窃取が完了している可能性が高いのです。慌てず、しかし速く動きましょう。
🔍 こんなサインに気づいたら
ファイルが開けない／拡張子が変わった
書類や画像が一斉に開けなくなり、見慣れない拡張子（.locked など）に。共有フォルダ全体が対象になることも。
身代金メモが出現
各フォルダに「README」「DECRYPT」等のテキスト/HTMLファイルや、デスクトップに脅迫文。連絡先や支払い要求が記載。
セキュリティ製品が無効化
ウイルス対策やバックアップが勝手に停止・削除。攻撃者が暗号化前に防御とシャドウコピーを潰す典型動作。
深夜の大量ファイル更新・異常通信
短時間に膨大なファイルが更新され、外部への大量アップロード（データ窃取）や見知らぬ宛先へのC2通信が発生。
🚒 ランサムウェア初動フロー（発覚からの動き）
日本の現場では、JPCERT/CCが「侵入型ランサムウェア攻撃を受けたら読むFAQ」で、初動の方針を明快に整理しています。覚えておきたいのは次の3つの柱です。
🅰 被害範囲を把握し最小化
- 暗号化・侵害が確認された機器は、被害拡大を防ぐためすぐ隔離
- どこまで広がっているか（横展開）を見極める
🅱 侵入経路を塞ぐ
- どこから入られたか（VPN・RDP・脆弱性・フィッシング等）を特定
- 原因を残したまま復旧すると再感染する
🅲 要求に応じずバックアップから復旧
- 攻撃者の要求には応じないのが原則
- 安全なバックアップから、経路を塞いだ上で復旧
支払いは、次の理由から推奨されません。①復号できる保証がない（鍵が渡されない・復号ツールが不完全な事例は多数）。②盗まれたデータの削除も保証されない（二重恐喝では「消した」という言葉に根拠なし）。③攻撃者の資金源となり、次の攻撃と犯罪組織を育てる。④「払う組織」として再び標的にされる。さらに、相手が制裁対象の組織だった場合、支払い自体が別の法的リスクを生むこともあります。支払いの是非は、その場の独断ではなく、経営層・法務・警察・専門家を交えて判断を。まずは復旧の道（バックアップ・No More Ransom等の復号ツール）を探ります。
🧾 ランサムウェア対応チェックリスト
- 感染端末をネットワークから隔離した（通電は維持／必要時のみメモリ取得後に電源判断）
- バックアップを攻撃者の手から守った（オフライン化・切り離し・上書き防止）
- 身代金メモ・暗号化拡張子・検体を保全した（開かず、ハッシュと場所を記録）
- 窃取（情報持ち出し）の有無を確認した＝二重恐喝・漏えい報告の判断材料
- 侵入経路の仮説を立て、塞いでから復旧する計画にした
- 関係先（経営層・取引先・必要なら警察・JPCERT/CC・個人情報保護委員会）への連絡を検討した
- 独断で身代金を払っていない・証拠を消していない
調査を深めるための関連記事
感染有無の見極めはマルウェア感染の確認方法、外部通信（C2）の痕跡はC2通信の痕跡をたどる、検体の安全な解析は隔離環境（INetSim）でのマルウェア解析、攻撃者の指標（IOC）の活用は脅威インテリジェンスとIOCが参考になります。証拠の一括収集にはKAPE（トリアージ収集）が定番です。
📧 BEC（ビジネスメール詐欺）対応プレイブック
マルウェアを使わず「人をだまして送金させる」攻撃。気づいてからの数時間が、お金を取り戻せるかの分かれ目です。
BEC（Business Email Compromise／ビジネスメール詐欺）は、経営者や取引先になりすました偽メールで、偽の口座へ送金させる攻撃です。マルウェアを使わない“だまし”が主役なので、ウイルス対策では防ぎにくく、被害額が極めて大きいのが特徴。IPAの「情報セキュリティ10大脅威 2025」でも組織向け脅威の上位に入り続けています。近年はAIによる音声・ビデオのディープフェイクと組み合わさり、「上司の声で電話」「役員になりすましたビデオ会議」での指示など、手口が一段と巧妙になっています。
🔍 こんなメール・状況は要注意
「至急」「内密に」で急がせる
CEOや役員を名乗り、「今すぐ」「他言無用で」送金を指示。確認の隙を与えず、心理的に急かすのが常套手段。
振込先の急な変更
取引先を装い「振込口座が変わった」と通知。請求書の口座だけ差し替える“請求書詐欺”は被害が大きい。
ドメインが微妙に違う
本物そっくりの類似ドメイン（例：rn と m、0 と O）や、表示名だけ正規で実アドレスが別物。
不審なメール転送ルール
アカウントが乗っ取られると、攻撃者は気づかれぬよう自動転送・自動削除ルールを密かに仕込む。
⏱ BEC「送金してしまった」直後のタイムライン（速さが命）
BECで誤って送金した場合、最優先は「送金に使った銀行への連絡」です。攻撃者は着金後すぐ資金を引き出すため、スピードがすべて。国内口座宛なら、早ければ資金が動く前に組戻し（送金の取消）で取り戻せる可能性があります。海外宛は現地の警察・金融機関へ、米国の口座が絡む場合はFBIのIC3への通報も有効とされています。金額の大小にかかわらず、気づいたらすぐ動く。これが回収の可否を分けます。
BECの調査で使えるもの
メールアカウント乗っ取りの調査では、Microsoft 365 や Google Workspace のクラウドのログ解析が鍵になります（サインインログ、転送ルールの変更履歴、不審なIP）。送信元の偽ドメインや関連インフラを調べるにはOSINT（オープンソースインテリジェンス）の手法が役立ちます。そして何より効くのは技術ではなく運用ルール——「振込先変更は別経路（電話）で必ず確認」「高額送金は複数人承認」を平時に決めておくことです。
🔓 不正アクセス・アカウント侵害プレイブック
ID・パスワードの突破やセッション乗っ取り。Webサービス、社内システム、クラウドのどれでも起こり得ます。
不正アクセスは、漏えいしたパスワードの使い回し（パスワードリスト攻撃）、フィッシング、多要素認証（MFA）疲労攻撃などを通じて、正規のアカウントを乗っ取る攻撃です。マルウェアと違い「正規の認証情報で堂々と入ってくる」ため、ログを丁寧に見ないと気づきにくいのが厄介な点です。
🔍 こんな兆候は侵害のサイン
身に覚えのないログイン
普段と違う国・時間帯・端末からのサインイン通知。深夜や海外IPからの成功ログインは要警戒。
MFAの承認要求が連発
頼んでいないのに認証承認のプッシュが何度も。根負けを狙う「MFA疲労攻撃」。絶対に承認しない。
勝手にユーザー・権限が追加
見知らぬ管理者アカウントや、既存ユーザーへの権限昇格。攻撃者が居座るための“裏口”作り。
設定の不審な変更
メール転送ルール、API連携、セキュリティ通知のオフなど、気づかれにくくする設定変更。
アクセスを断つ（封じ込め）
侵害アカウントのパスワードを変更し、全セッションを強制ログアウト（失効）。盗まれたクッキーやトークンを無効化する。乗っ取られた管理者アカウントは速やかに権限を制限。
MFAと認証を立て直す
MFAを再設定し、攻撃者が登録した認証デバイス・アプリパスワード・APIキーを削除。MFA疲労が原因なら、承認方式を番号一致型などに見直す。
ログを保全して侵入経路と範囲を特定
認証ログ・アクセスログを保全し、いつ・どこから・何をされたかを時系列化。攻撃者が作った裏口（転送ルール・新規ユーザー・APIトークン）を洗い出す。
横への広がりを断つ
同じパスワードを使い回している他サービスも危険。関連アカウントのパスワードを変更し、影響範囲を広げない。VPN・RDPなどの侵入口も点検。
影響評価と報告
個人情報・機微情報へのアクセスがあったかを評価し、必要なら関係先・当局へ報告（次章）。再発防止（パスワード方針、MFA強化、監視）へつなげる。
ログ調査を武器にする
不正アクセスの調査は「ログを読む力」がそのまま実力になります。大量のログから異常を見つけるにはSplunkでのログ分析、ログを横断検索・抽出する正規表現によるログ解析、Windows端末の操作痕跡ならWindowsアーティファクト解析、サーバ側はLinuxフォレンジックが役立ちます。保全・解析の道具立てはフォレンジックツール総覧を参照してください。
📋 報告・公表・法的義務（日本版）
技術対応と並行して進む“もう一つの対応”。特に個人情報が絡むと、日本では法律上の報告義務が発生します。
インシデント対応は、技術的な封じ込め・復旧だけでは終わりません。「誰に・いつ・何を報告するか」という説明責任の対応が並行して走ります。特に個人データの漏えいが絡む場合、日本では個人情報保護法により、個人情報保護委員会（PPC）への報告と本人への通知が義務づけられる場合があります。
| 区分 | 期限の目安 | 内容 |
|---|---|---|
| 速報 | 速やかに（概ね3〜5日以内） | 事態を知った後、把握している範囲で個人情報保護委員会へ第一報を入れる |
| 確報 | 30日以内（※） | 原因・被害範囲・再発防止策などを確定させて報告する |
| 確報（不正目的） | 60日以内 | 不正アクセスなど「不正の目的」による漏えいは、調査に時間を要するため期限が延長される |
| 本人通知 | 速やかに | 対象となった本人へ、状況に応じて通知する |
※ 報告義務の対象となるのは、主に次のような事態です——①要配慮個人情報が含まれる、②財産的被害のおそれ（クレジットカード番号の漏えい等）、③不正の目的によるおそれ（不正アクセス・ランサムウェア等）、④1,000人を超える漏えい（またはそのおそれ）。1件でも該当すれば報告対象になり得ます。自社のケースが該当するか迷う場合は、早めに専門家・委員会の窓口へ確認しましょう。
🏛 個人情報保護委員会
- 個人データ漏えい時の報告・本人通知
- 該当性の判断に迷う前に確認を
👮 警察（サイバー窓口）
- 不正アクセス・詐欺・ランサムは被害申告
- BECの送金は時間との勝負、早めに相談
🛟 JPCERT/CC・IPA
- インシデントの届出・技術的な相談先
- 注意喚起や対応FAQなど情報も豊富
🤝 取引先・顧客・社内
- 二次被害を防ぐための注意喚起
- 広報・法務と連携し、誠実かつ正確に
「隠す」より「正しく早く伝える」
インシデントを隠そうとすると、後から発覚したときに信頼を大きく損ない、被害も広がります。一方で、未確定の情報を慌てて公表すると混乱を招きます。「いつ・どこまで分かったかを、事実に基づいて段階的に開示する」のが基本姿勢。誰が対外発表を担うか、どんな順で伝えるかを、平時にプレイブックへ書いておきましょう。法令や契約上の通知義務（取引先との秘密保持契約など）も事前に棚卸ししておくと安心です。
🛡 平時の備え：プレイブックと机上演習
対応の質は、事故が起きる前に9割決まっています。今日からできる備えをまとめます。
ここまでの初動手順は、平時の準備があって初めて機能します。連絡先が分からない、ログが残っていない、バックアップが暗号化されていた——本番でそれに気づいても手遅れです。最後に、被害を「事故」で止めて「災害」にしないための、平時の備えを整理します。
連絡網（エスカレーション）を1枚に
社内の報告ライン、経営層、情報システム、法務・広報、外部のDFIR事業者、サイバー保険、警察、JPCERT/CCの連絡先を1枚にまとめ、侵害されても見られる場所（紙・別系統）に保管。
バックアップは 3-2-1＋オフライン
データは3つのコピー・2種類の媒体・1つはオフライン（または切り離し）で保管。攻撃者はバックアップを真っ先に狙うため、復元テストまで定期的に行う。
ログを「事前に」確保する
認証ログ、プロキシ、EDR、クラウドの監査ログは、消える前に十分な期間保管。インシデント時に「ログがない＝何も分からない」を避ける。
机上演習（テーブルトップ）
「ランサムに感染した」という想定で、関係者が集まり判断と連絡を口頭でシミュレーション。プレイブックの穴は、平時の演習でしか見つからない。
□ インシデント時の連絡網を1枚で作り、オフラインにも保管した／□ バックアップを3-2-1＋オフラインで運用し、復元テストを実施した／□ 重要システムのログ保管期間を確認した／□ 高額送金・振込先変更に別経路確認と複数人承認のルールを設けた／□ 代表シナリオ（ランサム・BEC・不正アクセス）の簡易プレイブックを用意した／□ 年1回以上、机上演習を行う計画を立てた。まずは1つでも——「いつか」ではなく「今日」始めることが、最大の防御です。
守りを深めたい人へ
「攻撃者がどこから来るか」を平時に知るには、許可された範囲でのペネトレーションテスト（侵入テスト）入門が視野を広げてくれます。組織でのAI利用が広がる今は企業のAI利用ガイドライン雛形も合わせて整備を。そして、調査スキルそのものを体系的に伸ばすならDFIR・デジタルフォレンジック完全ロードマップへ。このプレイブックの「②保全」「③解析」を、手を動かして学べます。
📚 用語集・FAQ・次に読む
つまずきやすい用語と、現場でよく出る疑問をまとめました。
📖 そのまま使える用語集
| 用語 | 意味 |
|---|---|
| CSIRT（シーサート） | インシデント対応を担う専門チーム。専任でなくても「役割」を決めておくことが大切。 |
| 封じ込め／根絶／復旧 | 被害拡大を止める→原因（マルウェア・侵入口）を取り除く→正常な状態へ戻す、の3段階。 |
| トリアージ | 多数の機器・事象から、優先して調べるべきものを見極める初期選別。 |
| ライブフォレンジック | 電源を切らず、起動中の端末からメモリなど揮発性の証拠を取得する手法。 |
| 揮発性の順序 | 証拠は「消えやすい順（メモリ→通信→ディスク）」に確保するという原則（RFC 3227）。 |
| IOC（痕跡指標） | 不正なIP・ハッシュ値・ドメインなど、攻撃を示す手がかり。検知と範囲特定に使う。 |
| 二重恐喝 | 暗号化に加え「盗んだデータを公開する」と脅す、ランサムの主流手口。 |
| 組戻し（くみもどし） | 誤って行った銀行送金を取り消す手続き。BEC被害では早さが回収の鍵。 |
| MFA疲労攻撃 | 認証承認のプッシュを連発し、根負けや誤承認を狙う手口。承認しないのが鉄則。 |
| RTO／RPO | どれだけで復旧するか（RTO）／どの時点まで戻せるか（RPO）。バックアップ設計の指標。 |
❓ よくある質問（FAQ）
専任のセキュリティ担当がいない中小企業です。何から始めれば？
まずは「①連絡網を1枚作る」「②バックアップを3-2-1＋オフラインにする」「③振込ルールを決める」の3つから。高度な体制より、いざという時に誰へ連絡し、どこから復旧するかが決まっているかどうかが被害を分けます。重大インシデントに備え、外部のDFIR事業者やサイバー保険を平時に下調べしておくと安心です。
感染したら、まず電源を切るべきですか？
原則は「いきなり切らない」です。電源を切るとメモリ上の証拠（暗号鍵や攻撃の痕跡）が永久に失われます。被害を止めたいときは、まずネットワークから隔離（通電は維持）。暗号化や破壊がリアルタイムで進み隔離で止まらない等の例外時のみ、判断と理由を記録して電源を検討します。可能ならその前にメモリを取得します。
身代金は払ってもいいのでしょうか？
推奨されません。復号できる保証も、盗まれたデータが消される保証もなく、攻撃者の資金源となって次の攻撃を生み、再び標的にされるリスクもあります。その場の独断ではなく、経営層・法務・警察・専門家と判断を。まずはバックアップや公開されている復号ツール（No More Ransom 等）での復旧を探ります。
どこに通報・相談すればいいですか？
不正アクセスやランサム、詐欺の被害は警察へ。技術的な相談・届出はJPCERT/CCやIPAへ。個人データの漏えいが絡む場合は個人情報保護委員会への報告・本人通知が義務になることがあります。BECで送金してしまったら、まず銀行へ即連絡（組戻し）し、並行して警察へ。
ログは何を、どれくらい残せばいいですか？
最低限、認証（サインイン）ログ、プロキシ／通信ログ、EDRやサーバの監査ログ、クラウドの操作ログを。保管期間は要件次第ですが、侵入から発覚まで数ヶ月かかることも珍しくないため、できるだけ長めに確保しておくと、いざという時に「何も分からない」を防げます。ログ調査の実践はSplunkや正規表現でのログ解析の記事へ。
バックアップさえあれば安心ですか？
条件付きで「はい」。攻撃者はバックアップを真っ先に暗号化・削除しようとするため、オフライン（または切り離し）での保管が必須です。さらに、いざ復旧という時に復元できなければ意味がないので、定期的な復元テストを。復旧前に侵入経路を塞ぐことも忘れずに——塞がないと、復旧したそばから再感染します。
🧭 次に読む（このプレイブックの“実践編”）
🔬 調査の地図とツール
🦠 マルウェア・脅威情報
🤖 AI時代の詐欺・防御
📚 参考・出典（一次情報）
- NIST SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」（2025年4月）
- NIST SP 800-86「Guide to Integrating Forensic Techniques into Incident Response」
- JPCERT/CC「侵入型ランサムウェア攻撃を受けたら読むFAQ」「No More Ransom」
- IPA（情報処理推進機構）「ランサムウェア対策特設ページ」「ビジネスメール詐欺（BEC）対策特設ページ」「情報セキュリティ10大脅威 2025」
- 警察庁「ビジネスメール詐欺に注意！」／FBI IC3（Internet Crime Complaint Center）
- 個人情報保護委員会「漏えい等の報告・本人への通知の義務化について」
- RFC 3227「Guidelines for Evidence Collection and Archiving」／MITRE ATT&CK
コメント