ランサムウェア前提BCPをどう書くか|IPA机上演習教材を自社用にデチューンする実務

okash1n
okash1n

執行役員 / 情報セキュリティ管理者

どうも おかしん です。

ランサムウェア対応のBCPを作るとき、最初から完璧な文書を目指すと手が止まります。経営層、情シス、セキュリティ担当、業務部門が同じ場に集まり、「感染したら最初の90分で何を決めるか」を一度しゃべってみる方が、弱点はずっと早く見えます。

本稿では、IPAのセキュリティインシデント対応机上演習教材を出発点に、ランサムウェア前提BCPを90分の自社版机上演習へ落とし込む方法を整理します。

結論サマリー

  • ランサムウェア前提BCPとは、「検知・初動対応」「報告・公表」「復旧・再発防止」の3局面を、侵入・感染が起きる前提で事前に設計し、机上演習で確認できる状態にしたBCP/BCMです。
  • IPAは2025年4月15日に「セキュリティインシデント対応机上演習教材」を公開し、一般企業向けと医療機関向けのランサムウェア感染シナリオを提供しています。ページ上の最終更新日は2025年4月30日です。
  • IPA実施マニュアルの標準想定は3時間、1グループ4-6名です。本稿の90分版は、この標準教材の代替ではなく、最初の1回を実施するための自社向け編集案です。
  • 推奨は、初回だけ90分にデチューンし、検知・初動を厚めに扱うことです。2回目以降は、経営層、部門責任者、拠点ごとに分けて深掘りします。

想定読者と、この記事で分かること

この記事は、次のような方に向けて書いています。

  • 中堅・中小企業の経営層、情シス、インシデント責任者
  • BCPはあるが、サイバー攻撃を前提にした机上演習をまだ実施していない方
  • 医療、製造、インフラ企業などで、ランサムウェア対応を部門横断で確認したいセキュリティ担当
  • SaaS構成、緊急連絡網、取引先連絡を含めて、自社版の演習シナリオを作りたい方

持ち帰ってほしいのは、90分で回せる「不完全だが成果の残る」自社版机上演習の雛型です。完璧なBCP文書を作る話ではなく、最初の演習で何を見つけ、次にどこを直すかを決めるための記事です。

IPA「セキュリティインシデント対応机上演習教材」の概要

IPAの教材は、ランサムウェア感染を題材にしたTable Top Exercise、つまり討論型の机上演習教材です。IPAの説明では、教材は座学パートと演習パートで構成され、演習パートでは受講者がグループでディスカッションしながら対応方針・方法を検討し、発表します。

項目内容
公開日2025年4月15日
最終更新日2025年4月30日
シナリオ一般企業向けランサムウェア感染、医療機関向けランサムウェア感染
ベース中小企業のためのセキュリティインシデント対応の手引き
標準所要時間実施マニュアル上は3時間想定
1グループ人数実施マニュアル上は4-6名
主な提供物講師用テキスト、受講者用テキスト、回答例、実施マニュアル

この教材のよいところは、ランサムウェア感染という一つの事象を、技術対応だけで終わらせていない点です。経営層、情報システム、セキュリティ、影響を受ける事業部門が参加し、発覚から報告、公表、復旧、再発防止までを話し合う構造になっています。

一方で、初めての組織がいきなり3時間、複数グループ、講師・ファシリテーター付きで実施するのは重いはずです。そこで本稿では、教材の構造を崩さず、初回だけ90分に切り詰める前提で考えます。

なお、IPAは経営者向けインシデント対応机上演習も提供しています。報告・公表、顧客対応、事業継続の判断は現場だけでは決めきれないため、経営層の参加を前提に置いた方が現実に近づきます。

90分版にデチューンする3つの編集方針

IPA実施マニュアルでは、グループディスカッションが重要であり、その時間の短縮は推奨しないと説明されています。つまり、90分版は「IPAが推奨する標準形」ではありません。初回開催のハードルを下げるための、本稿としての読み替えです。

その前提で、編集方針は3つです。

1つ目は、検知・初動を厚くすることです。ランサムウェア対応で最初に詰まるのは、感染範囲の特定、端末隔離、SOC/MSPへの連絡、業務停止判断、社内外への連絡停止判断です。ここが曖昧なまま復旧や再発防止へ進んでも、実際の初動では使えません。

2つ目は、意思決定者を「役割名」ではなく自社の現実に置き換えることです。広報責任者、法務、サービス停止判断者、外部委託SOC窓口といった抽象名だけではなく、自社では誰が該当するかまで書きます。個人名を公開資料に残す必要はありませんが、演習の場では「誰に電話するのか」まで確認します。

3つ目は、自社のSaaS構成と取引先連絡をシナリオに入れることです。Microsoft 365、Google Workspace、Box、Slack、Salesforceなど、実際に使っている業務基盤を最低3つ入れるだけで、議論は急に現実味を帯びます。

90分版・自社版机上演習の進行台本

初回は、次のような時間配分にします。

時間フェーズ主な問いアウトプット
0:00-0:05オリエンテーション目的、ルール、守秘、記録方法を確認する記録シート
0:05-0:50検知・初動業務PCの暗号化が発覚してから60分以内に何をするか。SOC通報、感染範囲特定、隔離、業務停止、対外連絡停止を誰が決めるかタイムライン、判断ログ
0:50-1:10報告・公表個人情報保護委員会への報告要否、報告期限、取引先連絡、社内アナウンス、メディア対応をどう判断するか連絡テンプレ草案、報告期限チェック
1:10-1:25復旧・再発防止バックアップ復元手順、優先業務復旧順、再発防止アクションをどう決めるか復旧優先順位、再発防止TODO
1:25-1:30振り返り次の演習で必ず変える1点は何か次回課題

この90分版で大事なのは、すべてを解決しないことです。1回目の演習で完璧な対応手順を作ろうとすると、議論が発散します。初回のゴールは、次の3つに絞ります。

  • 最初の60分で誰が何を決めるかを見える化する
  • 報告・公表の期限と決裁者を確認する
  • 復旧に必要なバックアップ、アカウント、SaaS、委託先の依存関係を洗い出す

特に報告・公表では、個人情報保護委員会の漏えい等の対応とお役立ち資料を確認しておきます。漏えい等報告は、速報が発覚日から3-5日以内、確報が原則30日以内、不正な目的で行われたおそれがある場合は60日以内とされています。演習では、この期限を「誰が」「どの情報で」「どの様式で」確認するかまで決めます。

NotebookLM / Glean 等で自社シナリオを生成するプロンプト例

自社版シナリオを作るとき、生成AIや社内検索AI(エンタープライズSearchAI)は下準備の短縮に使えます。ただし、緊急連絡網、取引先一覧、SaaS構成図、インシデント対応履歴のような情報は、そのまま入れてよいとは限りません。

NotebookLMについて、Googleのヘルプでは、Google WorkspaceまたはGoogle Workspace for Educationユーザーのアップロード、クエリ、モデル回答は、人間のレビュアーによる確認やAIモデルのトレーニングに使用されないと説明されています。Gleanは、公式ページで100以上のツール横断検索とアクセス権限に対応した検索結果を説明しています。

それでも、ツール名だけで安全性を一括判断しない方がよいです。実際に投入する前に、次を確認してください。

確認項目何を見るか
データ分類緊急連絡網、取引先一覧、SaaS構成図を社内ルール上どの分類で扱うか
契約条件生成AI機能、学習利用、ログ保持、管理者監査の条件
共有範囲作ったノートや回答が誰に共有されるか
アクセス権限元データの閲覧権限が回答や検索結果にも継承されるか
匿名化顧客名、個人名、取引先名をA社、B社などに置き換えるか

投入範囲を決めたうえで、たとえば次のように指示します。

あなたはサイバーインシデント机上演習の脚本家です。以下を読み、当社向けの90分版シナリオを作成してください。

- 元教材: IPA「セキュリティインシデント対応机上演習教材」一般企業向けランサムウェアシナリオ
- 参照資料: 当社のSaaS構成図、取引先タイプ、緊急連絡網
- 出力構成:
  1. 感染発覚の状況描写 200字以内
  2. 検知・初動の問い 5つ
  3. 報告・公表の問い 4つ
  4. 復旧・再発防止の問い 3つ
  5. 想定回答
- 当社固有要素を3つ以上、自然に織り込むこと
- 顧客名、取引先実名、個人名は出さず、A社、B社、担当者Xのように匿名化すること
- 不明な点は推測せず、追加確認事項として列挙すること

このプロンプトの狙いは、AIに「正解」を作らせることではありません。演習前のたたき台を作り、当日の議論を具体化することです。

弊社の観点:本番で詰まりやすい3つの論点

公開情報ベースで一般化すると、ランサムウェア前提BCPの机上演習では、次の3点が詰まりやすいです。具体的な顧客名や個別事案は出していません。

1つ目は、いつ・誰に・何を出すかが曖昧なことです。規制報告、業界所管省庁、取引先連絡、メディア対応、社内アナウンスは、それぞれ期限、文面、決裁者が違います。演習では、連絡テンプレートそのものより、誰が最終決裁するかを先に確認します。

2つ目は、バックアップが「あるのに使えない」ことです。バックアップが暗号化対象に含まれている、世代が足りない、復元手順を試していない、復元後にSaaS連携や認証が戻らない。机上演習でも、復元時間と復旧優先順位を話すだけで見つかる弱点があります。

3つ目は、SOC/MSPへの通報経路が複線化されていないことです。契約はあるが夜間・休日の連絡先が一人に集中している、Slackが止まったときの代替経路がない、委託先と社内責任者の境界が曖昧。最低でも三人体制と代理ルートを書き出しておくと、初動の詰まりは減らせます。

このあたりは、弊社ブログのEDR運用支援サービスのご紹介で触れている「通知の先をどう判断するか」という論点や、運用支援を半年やって見えた、情シスが共通して抱える課題とアプローチで整理している運用上の共通課題ともつながります。机上演習では、ツールや委託先の有無だけでなく、その通知を受けて社内で誰が判断するのかまで確認してください。

まとめ:次のアクション

まず、IPAのセキュリティインシデント対応机上演習教材をダウンロードし、3局面の構造を確認してください。

次に、本稿の90分版進行台本を使って、経営層、情シス、セキュリティ担当、業務代表を含む第1回を設定してください。完璧なシナリオを作るより、最初の会議を入れる方が前に進みます。

最後に、2回目以降は自社のSaaS構成、連絡経路、取引先タイプを反映したシナリオへ広げます。NotebookLMやGleanを使う場合も、投入する社内データの分類と共有範囲を確認してから使ってください。

FAQ

Q1. 3時間取れません。短くしてよいですか?

A. 初回の立ち上げとしては、90分版でも意味があります。ただし、IPA実施マニュアルは3時間を想定し、グループディスカッションの短縮を推奨していません。90分版は最初の弱点発見に絞り、2回目以降で深掘りしてください。

Q2. ファシリテーターは社内で誰がやるべきですか?

A. 初回は経営層直下のセキュリティ責任者やCSIRT相当の責任者が現実的です。2回目以降は、情シス課長クラスやセキュリティ担当がローテーションする形でも回せます。

Q3. 医療機関向けシナリオは医療以外でも使えますか?

A. 医療機関向けシナリオは、患者影響や医療提供体制など、医療特有の論点を含みます。一般企業では、まず一般企業向けシナリオをベースにした方が編集コストは低いです。

Q4. 経営層の参加は本当に必要ですか?

A. 必要です。報告・公表、サービス停止、復旧優先順位、取引先連絡は現場だけでは決めきれません。経営層が不在の演習は、判断が必要な場面で現実から外れやすくなります。

Q5. 90分で全社展開できますか?

A. 1回では難しいです。初回は経営層と主要部門で実施し、2回目以降に部門責任者、拠点、重要SaaS単位へ広げる方が現実的です。

参考リンク

この記事をシェア