封じ込めのパラドックス:ランサムウェア対応計画の指揮系統は間違っていないか

Verizon「2026年版DBIR」はランサムウェアを侵害全体の48%に関連付けています。システムをオフラインにする権限の所在が不明確なままでは対応計画が機能不全に陥ります。NISTに準拠した3つの対策でこのギャップを埋めます。

私はこの2年間で、3つの業界にわたってほぼ同じ筋書きのインシデント事後検証に立ち会ってきました。展開はほとんど変わりません。土曜日の午前4時47分、当直のSOCアナリストがデータセンター内の3台のサーバーにランサムウェアのペイロードが拡散しているのを発見します。プレイブックには「隔離せよ」と書いてあります。アナリストはスイッチを切ります。16分後、CFOから電話がかかってきます。その3台は本番環境の決済ゲートウェイだったのです。マルウェアはおそらく他の十数台のエンドポイントにも到達していたでしょう。しかし隔離措置によって14時間にわたり収益が失われました。月曜朝、取締役会が問うのは「攻撃者がどうやって侵入したか」ではありません。「これほどの商業的影響を及ぼす判断を、組織内の誰が午前4時47分の時点で下す権限を持っていたのか」ということです。

この問いこそ、ほとんどのインシデント対応プログラムが文書化を避けているものです。計画自体は文書化されています。SOCの2台目のモニターにはそれが常に表示されています。欠けているのは、たった一つの問いへの答えです。「事業上重要なシステムをオフラインにすると決めるのは誰で、その判断による事業上・財務上の結果を誰が引き受けるのか」ということです。私がこれまで見てきたプレイブックの大半では、その権限の所在が定められていません。実質的にはその時シフトに入っているSOCアナリストに委ねられており、そのアナリストは往々にして、影響を受ける事業プロセスの当事者でもなければ、これから取ろうとしている行動がもたらす下流への影響を十分に見通せる立場にもありません。

本稿では、技術的なインシデント対応と業務上の説明責任との間に存在するギャップを取り上げます。「封じ込めのパラドックス」という概念、ガバナンスの仕組みとしての「タッチ禁止台帳(no-touch register)」、封じ込め判断のためのRACI構造、そして最もよく挙がる反論――拒否権を設けると攻撃者の動きに対して対応が遅れるだけではないか――への回答を紹介します。

「まず隔離せよ」がもはや安全なデフォルトではなくなった理由

従来型のインシデント対応教義は企業ITの世界から生まれたものです。かつては安全に正しいとされていた一つの反射的行動を伴います――迷ったら隔離せよ、というものです。不審なエンドポイントはネットワークから切り離す。侵害されたサーバーは停止する。フラグの立ったアカウントは無効化する。迅速な行動は滞留時間(dwell time)を減らし、滞留時間が減れば被害も減る。この論理はあらゆるSOARのデフォルト設定と、ほとんどのIRランブックの背骨をなしています。

しかしこの教義は、隔離そのものが損失事象になった瞬間に破綻します。ネットワークから切り離されたワークステーション一台なら、知識労働者の生産的な1時間が失われるだけで済みます。ところが決済ゲートウェイやERPの基幹システム、ID基盤、製造ラインや取引プラットフォームが切断されれば、収益や契約上の違約金、規制上のリスク、信頼の失墜が、時には数分のうちに発生します。封じ込め措置そのものが被害になってしまうのです。もはや被害軽減ではなく、別ルートでのエスカレーションにほかなりません。145か国にわたる3万1,000件超のインシデントを分析したVerizonの「2026年版データ侵害調査報告書(DBIR)」によれば、ランサムウェアは現在、全侵害の48%に関与していることが判明しています。一方で、被害者の69%は身代金を支払わないことを選び、身代金の中央値は139,875ドルまで低下しました。インシデント対応の実務に照らしてこれらの数字を読み解くと、2つのことが見えてきます。トリガーとなる事象はかつてなく頻発するようになっており、それに続く判断はかつてなく重い商業的意味を持つようになっているということです。

2021年5月のColonial Pipelineの事例は、CISOなら誰もが知っているものの、正しく教訓化できている人は少ないケーススタディです。DarkSideのランサムウェアが感染していたのは企業側の請求システムであり、パイプラインの制御ネットワークではありませんでした。それでもColonial社はパイプラインを停止させました。ランサムウェアがIT側にとどまり続ける保証がなかったからです。この停止は6日間続き、17州とコロンビア特別区に影響を及ぼし、米東海岸で数十年ぶりとなる規模の燃料供給危機を引き起こしました。侵入によって侵害されたのは一つのネットワークでしたが、対応によって機能不全に陥ったのは一つの地域全体だったのです。JBS社も数週間後に同様のパターンをたどりました。ある大手米消費財メーカーは2023年、委託先ベンダーが復旧時間を長引かせたとして、その結果生じた停止時間についてベンダーに責任があると主張し、訴訟を提起しました。復旧に要した期間は今や訴訟において立証可能な損害額として扱われています。数年前には考えられなかった変化です。

説明責任と権限の非対称性

多くの企業では、ある事業サービスの可用性に責任を負う役員――決済部門長、トレーディング部門長、工場長、臨床システム責任者など――は、インシデント発生時にそのサービスをオフラインにされないようにする権限を持っていません。その権限はSOCが握っています。事業側の責任者は説明責任(accountability)を負う一方、権限はSOCにある。両者は別の人間であり、多くの場合報告系統も異なります。この非対称性は、実際に何かが停止されて初めて表面化します。2025年4月にAmy Nelson、Shanée Rekhi、Murugiah Souppaya、Karen Scarfoneの4氏によって確定されたNISTのSP 800-61改訂第3版は、インシデント対応モデル全体をNISTサイバーセキュリティフレームワーク2.0を軸に再構築し、その位置づけを「戦術的な実行」から「より広範なリスクマネジメントとの戦略的整合」へと明確に転換させています。この転換こそ、まさに私が指摘しているギャップです。新しい教義はインシデント対応を単なるSOCの機能としてではなく、事業側の責任者が名指しで参加する組織的リスクマネジメント活動として扱っています。

これはSOCの訓練を強化すれば解消するような問題ではありません。ガバナンスの問題です。この非対称性が生じるのは、IRプレイブックがセキュリティ部門によって、セキュリティ部門のためだけに作成され、この問題を浮き彫りにしたであろう法務・業務両面からのレビューを一度も経ていないためです。土曜日の午前4時のSOCアナリストは、攻撃者の滞留時間を4時間減らすために会社の決済業務を14時間止めるべきかどうかを判断するのにふさわしい人物ではありません。その判断は、名指しされた業務上の責任者に属するべきものです。そして、その責任者に時間内に連絡が取れない場合、プレイブックはアナリストにその場の判断を委ねるのではなく、あらかじめ合意された安全な状態への移行策を明示しておくべきです。

タッチ禁止台帳:「重要資産リスト」の新たな読み方

多くのセキュリティプログラムは、すでに「クラウンジュエル(重要資産)台帳」――失えば存続に関わるシステムの一覧――を保有しています。通常の読み方では、この台帳は投資判断やパッチ適用の頻度、バックアップの頻度、監視の深度を左右するものです。その読み方は正しいものの、不完全です。同じリストには、少なくとも同じくらい重要な第二の機能があります。それは、SOCが名指しの事業責任者による確認なしに手を出してはならないシステムの一覧という機能です。

私はこの第二の機能を「タッチ禁止台帳」と呼んでいます。これは別のデータベースではありません。同じクラウンジュエル台帳に、一つの列を追加したものです。すなわち各資産について、どの封じ込め措置ならSOCがあらかじめ承認された範囲内で実行できるか、そしてどの措置には業務側の確認が必要かを定めるものです。区分はおおむね次のようになります。

資産クラス SOCが事前承認された措置 拒否権で保護される措置
決済ゲートウェイ 検知、分析、証拠保全、監視、送信トラフィックの制限。 ネットワークからの隔離、サービスのオフライン化、運用アカウントの認証情報の強制リセット。
ID基盤(IdP) 検知、ログの拡充、セッション異常の警告、追加のMFAの要求。 フェデレーション信頼の無効化、アクティブセッションの一斉失効、テナント全体の強制ログアウト。
製造制御システム 検知、受動的な監視、エスカレーション。 連続工程を中断させたり安全対応を誘発したりし得るあらゆる措置。
臨床用電子カルテ(EHR)基盤 検知、管理者アクセスの制限、ログ機能の強化。 システムのオフライン化、臨床医のアクセス遮断、病床機器へのデータ送信の停止。
標準的なエンドポイント(ノートPC、開発用ワークステーション) 全面的な封じ込め――隔離、イメージ取得、再構築。 なし。

この表で重要なのは行の中身そのものではなく、これを実際に埋めるという作業自体です。私がこの演習を実施した現場では、いずれの場合もミーティング自体が価値を生み出しています。事業側の責任者はしばしば初めて、IRプレイブックがSOCに自分たちのサービスをオフラインにする権限を与えていることを知ります。SOC側もしばしば初めて、その措置が実際にどれほどの下流コストをもたらすかを知ります。この対話さえ行われれば、タッチ禁止台帳の内容の大半は自然に合意に至ります。この成果物は、その合意を強制力のあるものにするのです。

封じ込め判断のためのRACI

タッチ禁止台帳が整備されれば、拒否権で保護される措置についてのRACIは明快になります。以下のモデルは、政府・産業界・法執行機関にまたがる60超の組織による連合体であるInstitute for Security and Technology傘下のRansomware Task Forceが、その進捗報告書の中で繰り返し推奨してきた4つの役割に基づく論理と整合しています。封じ込めの権限は、セキュリティ部門単独ではなく、業務側の責任者に属するべきだというものです。

役割 RACI 理由
事業資産の責任者 説明責任者(Accountable) 可用性を確保する使命と、サービスをオフラインにした場合の商業上・安全上・規制上の下流への影響の両方を担っています。運用上の確認は指名済みの当直リーダーに委任しますが、戦略的な責任は保持し続けます。
セキュリティオペレーションセンター(SOC) 実行責任者(Responsible) 確認が得られた時点、あるいは定められたエスカレーションの猶予時間が経過し、事前合意済みの安全状態への移行策が適用される時点で、封じ込め措置を実行します。
CISO/セキュリティ責任者 助言対象者(Consulted) 手法上のガードレールを設定しますが、個々のインシデントにおける単独の意思決定者ではありません。組織横断的なインシデントについては、説明責任者(Accountable)への全社的な調整のエスカレーション先となります。
経営陣・取締役会 報告対象者(Informed) リアルタイムでの協議ではなく、構造化された形での報告を受けます。この「報告対象者」という位置づけこそが、インシデント後の事後検証を監査や規制当局のレビュー、訴訟の場において正当化できるものにします。

多くの企業では、このRACIの欄はこれまで一度も埋められたことがありません。この欠落によるコストは、平常時の業務では見えませんが、インシデントの事後検証の場面――社内の教訓抽出、規制当局、あるいは原告のいずれかが「誰が、どの根拠に基づき、どのような権限でシステムをオフラインにすると決めたのか」を問う場面――では、組織の存続に関わるほどの重みを持つようになります。

よくある反論:攻撃者が動いている間に対応が遅れないか

このテーマを扱うワークショップでは、必ず同じ反論が出てきます。SOCが事業責任者の確認を待たなければならないのなら、滞留時間は延び、被害の発生確率も高まり、拒否権が実質的に対応を無力化してしまうのではないか、というものです。一般論としてはこの反論は正しいと言えます。しかしタッチ禁止台帳に即して考えると、この反論には3つの誤解が含まれています。

まず、拒否権は限られた資産クラスにのみ適用されます。台帳がカバーするのはクラウンジュエル、すなわち通常は事業部門ごとにごく少数に限られる資産であり、組織全体の資産ではありません。侵害されたノートPCを封じ込めることに拒否権による保護は適用されません。しかしそのノートPCが認証を受けているID基盤を封じ込めることには適用されます。拒否権で保護される対象は、「失えば存続に関わる資産」と「まさにその損失を引き起こす措置」との重なりに限られるのです。

次に、拒否権には時間的な制限が設けられています。実用に耐えるプレイブックは、明確な時間枠を伴うエスカレーションの連鎖と、その連鎖が尽きた場合の意図的なフォールバック行動を定義しています。その構造は次のようになります。

ステップ エスカレーションの役割 最大待機時間 応答がない場合の措置
1 当直のサービス責任者(その資産の一次連絡先) 5分 事業資産の責任者へエスカレーション。
2 事業資産の責任者 10分 当直の役員へエスカレーション。
3 当直役員(サービスライン責任者またはCOO代理) 15分 事前合意済みの安全状態へのフォールバックを適用する――一方的な隔離ではない。

この事前合意済みの安全状態へのフォールバックこそ、ほとんどのプレイブックが見落としている設計上の要点です。これは猶予時間が切れた後にSOCが一方的に実行する当初の封じ込め措置とは異なります。あくまで別途、意図的に設計された措置であり、SOCがプレッシャーの中でその場しのぎの判断をせずに済むよう、資産を管理可能な状態へと移行させるものです。縮退モード、読み取り専用アクセス、トラフィック制限など、事業責任者がまさにこうしたケースに備えてあらかじめ書面で承認しておいた措置がこれに当たります。

最後に、拒否権が適用されるのは「措置」であって「検知」ではありません。SOCは、タッチ禁止リストに含まれていないすべてのシステムについて、検知、証拠保全、監視の強化、隔離を行う全権限を保持し続けます。拒否権によって保護されるのは、継続的な事業サービスに計画外の停止を引き起こしかねない、ごく一部の措置に限られます。現代のSOARプラットフォームは、こうした分岐処理をネイティブに扱えます。大統領令14028に基づいて公表され、民間セクターへの応用が明確に想定されているCISAの「連邦政府サイバーセキュリティ・インシデント/脆弱性対応プレイブック」も、まさにこの種の分岐した意思決定ツリーをモデル化しています。多くの企業実装がこれを実現できていない理由は、技術的なものではありません。単に、IRガバナンスがそれを求めてこなかっただけなのです。

導入のための3つのステップと、大半の価値を生み出す1回のミーティング

タッチ禁止台帳の導入に、新しいソフトウェアも追加人員も別枠の予算も必要ありません。必要なのは、適切な顔ぶれが揃った部屋での4時間と、これまで暗黙のうちに済ませてきた判断を明文化する意志だけです。

  • 台帳を作成する。事業資産の責任者たちと膝を突き合わせ、計画外に停止した場合の損害が、同じシステムに起こり得る最悪のサイバーインシデントよりも深刻になるようなシステムを洗い出します。このリストは、多くのCISOが想定するよりも短いものになるはずです。実際の成果はこの対話そのものであり、表はその成果物にすぎません。
  • セキュリティ上のチェックポイントを、監査フォルダに眠っているプレイブックではなく、SOCが実際に運用しているプレイブックに組み込みます。台帳に登録された資産に対する封じ込め措置を実行する前に、チェックポイントを挿入します――名指しされた事業側の役割による確認、定義済みのエスカレーション連鎖、定義済みの最大猶予時間、そして猶予時間が切れた場合の定義済みの安全状態へのフォールバックです。
  • RACIを埋めます。台帳登録資産の封じ込めについて、事業責任者を説明責任者(Accountable)、SOCを実行責任者(Responsible)、CISOを助言対象者(Consulted)、経営陣を報告対象者(Informed)とします。ほとんどの組織では、この欄はこれまで一度も完成したことがありません。これを完成させることこそ、インシデント発生後に「誰が、どの根拠に基づいて何を決めたのか」に答えられるようになるための前提条件です。

午前4時47分のテスト

現行のIRプログラムに対して一つだけ診断を行うとすれば、これです。私はこう問いかけます。「土曜日の午前4時47分、信頼性の高いランサムウェアのペイロードが3つのクラウンジュエル・システムに拡散しつつあるとき、SOCアナリストは自らの判断だけでそれらのシステムをオフラインにする権限を持っているか」。答えが「イエス」であれば、ガバナンスはその判断が持つコストにまだ追いついていません。答えが「ノー」であれば、「アナリストは定められた時間枠内に名指しされた説明責任者に連絡できるか、そしてその時間枠が切れた場合の事前合意済みの安全状態へのフォールバックは存在するか」を問います。両方の答えが「イエス」であれば、タッチ禁止台帳はたとえそう名付けられていなくても、実質的にすでに存在していることになります。どちらかの答えが「ノー」であれば、そのギャップは技術の問題ではなくガバナンスの問題です。

封じ込めのパラドックスは、自動化を高速化することでも、事後的に人間をループに加えることでも解決しません。これは、どの事業サービスをオフラインにする権限を誰が持つのか、そしてその人物に連絡が取れない場合にどう対応するのかを、平易な言葉であらかじめ明文化しておくことによってのみ解決します。その成果物はわずか1ページです。それを生み出す対話にかかる時間は数時間です。しかしそれを持たないことのコストは、取締役会への報告や規制当局への届け出、そして開示請求という言葉で測られることになります。

本稿はFoundry Expert Contributor Networkの一環として掲載されています。
参加をご希望ですか?

翻訳元: https://www.csoonline.com/article/4200141/the-containment-paradox-why-your-ransomware-playbook-has-the-wrong-people-in-charge.html

ソース: csoonline.com