多くのランサムウェア復旧作業は、同じように始まります。誰かが災害復旧計画を取り出し、別の誰かがバックアップベンダーに連絡します。そして、おそらく自然災害や誤削除を想定して策定されたその計画は、現実と向き合うと、たちまち破綻してしまうのです。

復旧体制における課題は、検知や防御に多額の投資を行ってきた組織であっても、驚くほど根強く、組織を問わず一貫して見受けられます。これは、構造的な問題の存在を示唆しています。組織は数十年にわたり、セキュリティ体制の構築や脅威の予見能力の向上に注力してきました。しかし、復旧能力の向上に費やされた時間はそのほんの一部に過ぎず、Mythosのような最先端のAIモデルは、なぜそれが大きな代償を伴う過ちであるかを明らかにしています。

ランサムウェア攻撃者にとって、すでに低い参入障壁は、まもなく事実上ゼロに近くなるだろう。今日の攻撃者は、十分な動機さえあれば、ほぼあらゆる防御を突破することができる。1年後には、適切なAIモデルが自律的に脆弱性を探知するようになれば、攻撃者にはそれほど強い動機さえ必要なくなるかもしれない。

検証されていない復旧計画にかかるコストは増大の一途をたどっています。もし貴社がこれらの変化を、単に脅威をいかに迅速に検知するかという観点からのみ捉えているのであれば、問題の半分は未解決のまま残されていることになります。

組織が繰り返し犯している過ち

以下に挙げる失敗例は、セキュリティ対策が不十分な組織に限ったことではありません。これらは、検知体制が成熟し、強力なチームを擁し、多額のセキュリティ予算を投じている企業でも発生しています。共通点は、検知能力に比べて、復旧能力への投資やテストが不十分であったという点です。

バックアップに対する信頼のギャップ

これは、一見解決したように感じられるため、最も危険な失敗です。

バックアップは整っています。ジョブは正常に完了しています。ダッシュボードは正常（緑色）を示しています。取締役会には、バックアップ体制が整っていることを報告しました。おそらく何年も前に、その項目にチェックを入れて、次の課題に移ったことでしょう。

そして、攻撃が発生する。環境を把握し、特権的な認証情報を保持し、意図的にバックアップインフラを狙ってくる攻撃者に対して、それらのバックアップは持ちこたえられるのだろうか？

実際の現場では、Fenix24は、本番環境と同じネットワークセグメント上にバックアップインフラが配置されているケースを頻繁に確認しています。また、サービスアカウントに依然として削除権限が与えられている「不変」なリポジトリも存在します。さらに、完全な復元を誰も検証することなく、何年も正常に完了し続けているバックアップジョブも見受けられます。

ランサムウェアの攻撃者がバックアップを標的にするのは、バックアップがあれば被害者が身代金を支払わずに済むためです。環境を自律的にマッピングできるフロンティアAIモデルが登場すれば、その標的選定はさらに精密なものとなるでしょう。もしモデルがOS全体にわたる脆弱性を発見できるなら、3年前にチームが設定して以来一度も移動されていないバックアップサーバーさえも特定できてしまうのです。

耐障害性のあるバックアップには、不変性（管理者権限を持つ攻撃者であっても、バックアップを改変または削除できないこと）、セグメンテーション（侵害されたネットワークからバックアップ環境にアクセスできないこと）、および復旧の検証（ジョブが完了したことが確認されただけでなく、完全な復旧がテスト済みであること）が必要です。多くの組織は、これら3つの要件のうち1つを満たしています。3つすべてを満たしている組織は、はるかに少ないのが実情です。そして、3つすべてを満たしている組織は、通常、それらを満たさない場合に何が起こるかを身をもって学んだ結果、その境地に達しているのです。

RTOフィクション

御社のRTOは48時間となっています。これは計画に盛り込まれ、取締役会へのプレゼンテーションを経て、組織全体で共有されるリスク認識の一部となりました。

それは結構ですが……身元情報が漏洩し、バックアップへのアクセスが制限され、チームの通信環境も悪化しているというシナリオ下での完全復旧にかかる時間を、実際に計測した人は誰もいません。全員が資料を手にし、SIEMも正常に動作している机上演習では意味がありません。また、予定されたメンテナンス期間中に1つのシステムをバックアップから復元したケースも、同様です。

有意義な復旧テストとは、最悪の事態を想定したものです。ID管理システムがダウンし、バックアップへのアクセスが制限され、通信環境も悪化しています。チームの半数は睡眠不足のまま意思決定を迫られており、CISOは携帯電話を持たずにサファリに出かけています。

ほぼすべての案件において、検証されていないRTO（復旧目標時間）がもたらす結果を目の当たりにしています。書類上の数値と現場の実態が一致することはほとんどありません。両者に乖離が生じると、その影響は雪だるま式に拡大します。売上高の損失、業務の混乱、顧客の離反、評判の失墜、そして規制上のリスクなどです。組織は、誰も検証したことのない数値に依存していたため、こうしたリスクをリスク管理体制に織り込んでいなかったのです。

アイデンティティの再構築

Active Directoryは、ほぼ常に攻撃の中心となります。したがって、復旧計画においても同様に中心的な位置づけとなるべきです。しかし実際には、アプリケーションやデータベースの復旧については、成熟した体系的な計画が策定されている一方で、ADの復旧に関する話題になると、議論が途絶えてしまうことがよくあります。オフラインのバックアップが存在しない。再構築プロセスが文書化されていない。再構築にかかる時間の測定がテストされていない。どのドメイン コントローラーが安全か、どのサービス アカウントを信頼できるか、あるいは特権アクセスをどのように安全に再確立するかについて、明確な答えがないのです。

これは、多くの復旧計画が認識している以上に重要な問題です。アイデンティティが再構築され、問題がないことが確認されるまでは、下流のシステムは一切信頼できません。アプリケーション、データベース、エンドポイント、ファイル共有、管理者アクセス権、サービスアカウント、クラウド連携、特権ワークフロー――これらすべてが、何らかの形でアイデンティティに依存しています。もしアイデンティティが侵害されれば、それに基づいて認証を行うすべてのシステムも、結果として侵害されることになります。

IDの復旧を適切に処理できる組織は、そのための準備を整えています。オフラインのADバックアップを用意し、クリーンな状態から再構築するための手順を文書化し、テスト済みです。実際に計測を行っているため、所要時間も把握しています。それ以外の組織は、キャリアの中で最悪の一週間を経験して初めて、その答えを知るのです。

依存盲点

環境がダウンすると、必ず誰かが、復旧のスピードを左右する質問を投げかけます。「何が最初に復旧するのか？」

あまりにも多くの組織において、その答えはたった一人のエンジニアの頭の中にある。時には、どこにも存在しないこともある。

リカバリとは、単にシステムのリストではありません。それは一連のプロセスです。ERPシステムが依存しているデータベースがまだダウンしている状態では、そのシステムを復旧させることはできません。アプリケーションが認証を行うためのIDインフラストラクチャが再構築されていない限り、アプリケーションをオンラインにすることはできません。また、それを支えるネットワーク、ストレージ、DNS、シークレット、サービスアカウントが欠落していたり、侵害されていたりする場合、重要なワークフローを復元することはできません。

最新の依存関係モデルがなければ、復旧チームは間違った順序で復旧作業を行うことで貴重な時間を浪費してしまいます。アプリケーションが依存するインフラが準備完了する前に、アプリケーションを稼働させてしまうのです。そして、ビジネスが深刻な打撃を受けている中で、プレッシャーにさらされながら、復旧の途中で依存関係の欠落に気づくことになります。最初から順序が間違っていたため、本来なら数日で済むはずの復旧作業が数週間もかかってしまうのです。

多くの組織では、資産データが数十ものツールに分散しています。データは古く、矛盾も生じています。CMDBにはある情報が記載されている一方、ネットワークチームは別のことを主張し、全体像を把握していたアプリケーション担当者は8ヶ月前に退職してしまいました。通常の運用環境下では、こうした情報の断片化は不便なだけです。しかし、アクティブリカバリの最中においては、致命的な事態を招くことになります。

最も迅速に復旧できる組織は、インシデント発生中にこの問題を解決しようとはしません。彼らはすでに解決策を把握しているからです。ティア0システムが特定されており、静的な図ではなく実際のデータに基づいて依存関係がマッピングされています。実際の関係性に基づいて復旧手順が作成され、実際に必要になる前にテスト済みです。それ以外の組織は、時間との戦いの中で、手探りの状態で一から計画を立てているのです。

平時と戦時の乖離

セキュリティプログラムは平時に策定され、文書化されます。平時には、SIEMは正常に稼働しています。SOCには人員が配置されています。フォレンジックパートナーにはすぐに連絡が取れます。スタッフは十分な休息をとっています。通信手段も確保されています。意思決定については、数日あるいは数週間かけて議論することができます。

戦時下は正反対だ。

戦時下をうまく乗り切れる組織は、たいてい平時からその準備を整えていた。彼らは、機能低下状態下での復旧活動、連携、手順、意思決定を検証するシミュレーションを実施していた。そして、何が機能しなくなるかを事前に把握していたのだ。

苦境に立たされている組織は、事態が全面的に悪化しても計画は持ちこたえるだろうと考えていた。AIによって短縮された攻撃のタイムラインは、その火に油を注ぐことになるだろう。

フロンティア時代を過ぎたAIの世界におけるレジリエンスと回復力

レジリエンスや復旧能力に関する想定の多くは、実際の攻撃が発生すると通用しなくなる。

• 「不変のバックアップ」は、結局のところ不変ではなかったことが判明した。
• 破壊されるのはデータだけではありません。インフラも破壊されます。
• 資産と依存関係のマッピングが不十分だと、数日あるいは数週間にわたるダウンタイムが発生する。
• RTOやRPOは現実的ではありません。

アナリストたちは、レジリエンスの未来についてあらゆる側面を明らかにしています。真のサイバーレジリエンスを構築・実行するための青写真をお探しですか？Omdiaの新しい技術検証レポート『Fenix24を活用したレジリエンスの構築と実行』をダウンロードしてください。

生き残れるかどうかは、何によって決まるのか

迅速に回復する組織と、何週間も停滞した状態から抜け出せない（あるいは全く回復しない）組織とを分ける要因は、主に3つあります。Frontier AIは仕組みそのものを変えるわけではありません。変えるのはスピードです。そのため、これらの要因は重要性を増すのであって、減るわけではありません。

まず何よりも、アイデンティティを復旧させなければなりません。これは絶対条件であり、多くの組織が最も手薄に扱ってきたステップでもあります。 Active DirectoryやIDインフラは、現代のランサムウェア攻撃において真っ先に狙われる標的の一つである。それゆえ、復旧においても最優先で対応しなければならない。IDが再構築され、クリーンであることが確認されるまでは、下流のシステムは一切信頼できない。アプリケーション、データベース、サービスアカウント、特権ワークフロー、クラウド連携。これらすべてが、何らかの形でIDに対して認証を行っている。AIを活用した攻撃であっても、この依存関係は変わらない。ただ、対応すべき時間が大幅に短縮されるだけである。

バックアップは、ハードウェアの故障だけでなく、攻撃者からの攻撃にも耐えうるものでなければなりません。多くの組織ではバックアップを実施していますが、有効な認証情報を持っており、組織の環境を理解し、バックアップインフラの配置を正確に把握している攻撃者に対抗できるバックアップを備えている組織はほとんどありません。ハードウェアの故障や誤削除に備えたバックアップ戦略と、特権アクセス権を持つ知的な攻撃者に対抗するためのバックアップ戦略とは、全く異なるものです。

復旧作業は、想定上の依存関係ではなく、実際の依存関係に従って行わなければなりません。依存しているデータベースがまだダウンしている状態では、ERPシステムを復旧させることはできません。また、それを支えるインフラストラクチャが欠落していたり、機能不全に陥っていたりすれば、重要なワークフローを復元することは不可能です。復旧は一連のプロセスであり、その順序が正しくある必要があります。多くの組織において、マッピングされていない依存関係は、復旧作業の遅延を引き起こす最大の原因の一つとなっています。 環境の変化に合わせて常に最新の状態を維持する、ライブテレメトリに基づいて構築された自動化された依存関係マッピングこそが、現実を反映した復旧計画と、誰かが最後にスプレッドシートを更新した時点の状況を反映した計画との違いを決定づけるものです。

これら3つの要因は、5年前も当てはまっていました。そして、5年後も当てはまり続けるでしょう。Mythosや最先端のAIが変えるのは、それらを見誤った場合の代償の大きさです。攻撃のタイムラインが人間の反応速度を下回るほど加速すると、復旧体制のあらゆる不備が、より大きな代償を伴い、より顕著に表れるようになるのです。

報告すべき回復指標

もし、取締役会への報告において検知については扱っているものの、復旧については扱っていないのであれば、今こそその状況を変えるべき時です。これらは、CISOが検知指標と同じ厳格さで報告できる指標であり、議論の質を根本から変えるものです。

テスト済みの復旧時間。文書化されたRTO（復旧目標時間）ではありません。現実的な侵害シナリオを想定した復旧演習中に実際に計測された時間です。数値と、最後にテストを行った日付を報告してください。

バックアップの生存率。不変性、セグメント化、完全復元による検証という3つの基準をすべて満たすバックアップリポジトリの割合。経営陣が長期的に追跡できる単一の総合指標。

ティア0の依存関係カバレッジ。依存関係チェーンが完全にマッピングされ、復旧手順が文書化されている重要アプリケーションの割合。これにより、復旧作業のうち計画的なものと即興的なものの割合が把握できます。

IDの再構築時間。Active Directoryを初期状態から再構築するのにかかる時間。この数値が未検証の場合は、「未検証」と報告してください。

今後90日間で何をすべきか

復旧体制の整備を一度に完了させる必要はありませんが、この好機は現実のものとなっています。現在、経営陣の関心はAIによる脅威に集中しています。復旧への投資を提案する上で、来四半期ほど好機となる時期は二度とないでしょう。

バックアップの耐障害性を検証する。攻撃者が意図的にバックアップを標的にした場合でも、バックアップが維持されるかどうかをテストする。不変性、セグメンテーション、および完全復元についてテストを行う。社内で確実にこれを行うことができない場合は、これを専門にテストしているランサムウェア復旧業者に依頼する。

復旧手順を決定する依存関係チェーンを可視化します。Tier 0 システムを特定します。どのアプリケーションがどのインフラストラクチャに依存しているかを文書化します。仮定ではなく、実際の関係に基づいて復旧手順を構築します。環境が十分に複雑な場合、これにはインフラストラクチャ全体のリアルタイムなテレメトリデータを相関分析するツールが必要であり、保存する前からすでに情報が古くなってしまうような手動のスプレッドシートでは不十分です。

実証済みの復旧時間を算出しましょう。最悪の事態を想定したシナリオ（IDの侵害、バックアップへの攻撃、通信障害など）に基づいて復旧演習を実施します。所要時間を計測し、チームがどこで足止めを食らうかを把握します。その計測結果が基準値となり、取締役会に提示する数値となります。

検知と並行して復旧状況も報告してください。次回のダッシュボード更新時に、上記の指標を追加してください。検知と復旧を、一つの全体像を構成する二つの側面として提示してください。その対比が、その重要性を雄弁に物語ってくれるはずです。

復旧の遅れは、都合の良い時に改めて検討できるような静的なリスクではありません。それは価値が日々減じている資産なのです。四半期ごとに先送りすればするほど、環境の把握は困難になり、依存関係は複雑化し、攻撃者の能力曲線は、自社の復旧能力をさらに引き離していくことになります。

CISOたちは、リスクを低減できることを実証することで、長年にわたり経営陣の一員としての地位を確立してきました。今後10年は、セキュリティ侵害が発生しても業務を継続できることを証明できるかどうかが問われる時代となるでしょう。これには、これまでとは異なる能力、異なる投資、そして経営陣との異なる対話が求められます。この点を早期に理解した組織は回復を果たすでしょう。そうでない組織は、平時に学べたはずの教訓を、何週間もかけて学ぶ羽目になるでしょう。

レジリエンス評価を始めましょう

あなたのバックアップは、執拗な攻撃者から守れるでしょうか？Fenix24のレジリエンス評価なら、実際にインシデントが発生する前に、環境の耐性を徹底的に検証します。

このレジリエンス評価は、当社のエンタープライズ向けレジリエンスプラットフォーム「Argos99」によって実現されています。Argos99は、インフラストラクチャ全体にわたるリアルタイムのテレメトリデータを相関分析し、あらゆる資産、依存関係、およびギャップを可視化します。つまり、Fenix24のレジリエンス評価では、単なるジョブの状態だけでなく、アプリケーションレベルでのバックアップの網羅性を評価します。何が何に依存しているかを可視化し、それらの関係性に基づいて復旧手順を生成します。評価のすべては、数百件に及ぶ実際の侵害事案からの復旧経験に基づいています。

チェックリスト形式の監査は避けてください。そうした監査は、真実を明らかにするためではなく、あなたがすでに知っていると思っていることを確認するために設計されていることが多いためです。今すぐレジリエンス評価をご予約ください。お電話（423.305.7890）またはメール（info@fenix24.com）にてお問い合わせください。