数十年にわたり、IT組織は災害復旧戦略を3つの指標――目標復旧時間（RTO）、目標復旧時点（RPO）、平均復旧時間（MTTR）――に基づいてきました。これらは不可欠である一方で、現代のサイバー脅威の状況に対しては危険なほど粗く、不十分になっています。単一の、混在した「MTTR」という数値は遅行指標であり、実行可能な洞察を何も提供しません。何が起きたかは示しますが、なぜそれほど時間がかかったのか、どこにボトルネックがあったのか、どう直すべきかは教えてくれません。
真の事業レジリエンスには、インシデント復旧イベントを明確に区切られた測定可能な段階へ分解する、新しいフェーズ認識型のフレームワークが必要です。Rubrik Zero Labsは、継続的なプログラム改善のために、包括的なサイバーレジリエンス・ライフサイクル戦略の採用を提案します。これは、インシデントを粒度高く測定し改善するための、戦術的な5段階のMTTRパイプラインによって支えられます。
このフレームワークを実世界のパフォーマンス・ベンチマークと組み合わせることで、曖昧な指標から、レジリエンスを事業成果に結び付け、確信を持って測定できる成熟した復旧態勢を構築するために必要な実行可能データへ、ようやく移行できます。
「粗い指標」という誤謬
単一のMTTR数値に依存するのは、工場の効率を「平均出荷時間」だけで判断し、受注処理、製造、品質保証、物流という個別で重要な工程を無視するようなものです。私たちは目隠し飛行を続けてきており、次のような最重要の問いに答えられませんでした。
-
遅延は検知の遅さが原因だったのか？
-
影響範囲（ブラスト半径）の特定に苦労したのか？
-
クリーンで侵害されていないバックアップを見つけるのに何時間もかかったのか？
-
アプリケーションチームが復元の検証を行う準備ができていなかっただけなのか？
実際の災害はこの問題を完璧に示しています。米国の医療業務に影響を与えた2024年のインシデントは、壊滅的な例を提供しました。対外的な指標は「1か月に及ぶ停止」でしたが、この粗い数値は実行可能な洞察を何も与えません。現実には、複数の未測定フェーズにわたる破局的な崩壊が起きていました。同社は「予防措置として」システムをオフラインにしており、侵害の範囲を迅速に把握する能力に重大な欠陥があったことを示しています。技術的にはデータが復旧した後でさえ、信頼の欠如により医療提供者は再接続をためらい、復旧の検証と事業の信頼回復における大きな失敗が浮き彫りになりました。
この問題は医療に固有ではありません。2019年に大手グローバル製造企業が受けたランサムウェア攻撃を考えてみてください。公表された指標は「7,000万ドル超の財務損失」と「1か月に及ぶ混乱」でした。これもまた粗い指標です。現実は多段階の失敗でした。全世界ネットワークの強制停止（スコーピングの失敗）と、数万人の従業員が数週間にわたり紙とペンで業務を強いられたこと（バリデーションの失敗）です。
これらの「ダークマター」指標――復元以外のフェーズに費やされた時間――こそが、真のレジリエンスが勝つか負けるかの分岐点です。
新しいモデル：サイバーレジリエンス・ライフサイクル
成熟したプログラムを構築するには、組織は単一のインシデントを超えた、継続的でプログラム的なライフサイクルを採用しなければなりません。このライフサイクルは4つの主要段階で構成されます。
1. レジリエンス評価：現在のセキュリティ態勢とリスクプロファイルを定義し理解する。これは基盤となる「特定（Identify）」段階であり、重要な事業サービスを、その背後にある技術的依存関係へマッピングします。
2. MVB（Minimum Viable Business：最小限の事業継続）を確立：事業を稼働させ続けるために必要な主要資産、アプリケーション、インフラを特定する。これにより、あらゆる復旧における「何を」「どの順序で」を定義します。
3. 危機シミュレーション：理論から実践へ。サンドボックス環境で防御とセキュリティ態勢を能動的にストレステストし、MVBに対する成果を測定します。
4. レジリエンス最適化：インシデントまたはシミュレーション後、各段階のパフォーマンスを分析し、将来の成果を改善するためにボトルネックを特定して解消します。
このライフサイクルは、レジリエンスを静的な「一度設定したら放置」のプロジェクトから、生きた継続的に改善される事業機能へと変革します。
図1：サイバーレジリエンス・ライフサイクル
MTTRパイプライン
「レジリエンス最適化」は、単一の復旧イベントを5つの測定可能なフェーズに分解する戦術的フレームワークによって支えられるべきです。このパイプラインこそが、実行可能データを解き放つ鍵です。
1. 平均検知時間（MTTD）：「認知までの時間」。最初の攻撃者による影響またはアラートから、復旧が必要であることの確認まで
2. 平均スコープ確定時間（MTTS）：「計画までの時間」。検知の妥当性確認から、すべての復旧対象オブジェクトの確定・確認済みリストがロックされるまで
3. 良好スナップショット選定までの平均時間（MTTGS）：「確信までの時間」。スコープがロックされてから、復元元となるクリーンで侵害されていないスナップショットを特定するまで
4. 平均復元時間（MTTr）：従来の「MTTR」。復元のトリガーから、ワークロードがデータを利用可能になるまで（例：Live MountまたはExport経由）
5. 平均検証時間（MTTV）：「事業機能までの時間」。初期データの提供から、アプリケーションの健全性の完全な検証と承認（サインオフ）まで
図2：5段階の戦術的MTTRパイプライン
この5段階のレンズを通して、グローバル製造企業のインシデントを再検討しましょう。従来の粗い指標では「数週間」という失敗しか見えません。しかし、このパイプラインは実行可能な改善経路を提供できたはずです。
-
MTTD：最初の暗号化ファイルから正式なインシデント宣言まで、どれくらいかかったのか？10分だったのか、4時間だったのか？これは実行可能な数値です。
-
MTTS：チームは全世界ネットワークを停止する判断を手作業で行うのに何時間も費やしました。この巨大で未測定のMTTSは、より良いデータ分類と影響範囲発見ツールの必要性を浮き彫りにします。
-
MTTGS：同社の数十の工場それぞれについて「ゴールデンスナップショット」を見つけて検証するのにどれくらいかかったのか？1時間だったのか、2日だったのか？これは、不変（イミュータブル）で脅威スキャン済みのバックアップの必要性を特定します。
-
MTTr：技術的な復元そのものに数週間かかりました。この指標は、データ転送速度と復元インフラを、解決すべき別個のボトルネックとして切り分けます。
-
MTTV：事業は1か月以上、紙とペンで運用されました。この指標は、復旧が検証段階で失敗したことを証明します。自動化された検証プレイブックと、アプリケーションオーナーによる承認（サインオフ）の必要性を示します。
これが実行可能な洞察です。問題は単に「復元」ではなく、スコーピングと検証で失われた、破局的で未測定の時間でした。これは、事後検証（ポストモーテム）を責任追及の場から、具体的な改善計画へと変えるデータです。
MTTrを用いて仮説を証明する
今日、重大なテレメトリのギャップが存在します。ほとんどの組織には、MTTD、MTTS、MTTGS、MTTVを自動的に測定する手段がありません。これらのデータは、分散したSIEMログ、インシデントチケット、スプレッドシートの中に埋もれていることが多いのです。
フェーズ認識型フレームワークの価値を理解するために、豊富で高忠実度のテレメトリがある唯一の段階――ステージ4の平均復元時間（MTTr）――に注目できます。この単一段階の分析は、中心仮説を縮図として証明します。すなわち、ここでさえ混在した平均値は無意味であり、パフォーマンスはオブジェクト種別と復元方法によって決まるのです。
このデータは、技術的なMTTrフェーズに対する強力なベンチマークを提供します。しかしさらに重要なのは、パイプライン全体に対する決定的なアナロジーとして機能することです。
MssqlとLinuxFilesetの復元の巨大な差を誤って隠してしまうため、単一の混在した「復元時間」が無意味であるなら、15分のMTTDと2日のMTTVの巨大な差を隠してしまう単一の混在した「総復旧時間」は、なおさら無意味です。
この表は、粒度の高いフェーズ認識型の測定が不可欠であることを証明します。目標はこの小さな1段階だけを最適化することではなく、同じ分析的厳密さを、真のボトルネックが潜む検知・スコーピング・検証という「ダークマター」フェーズに適用することです。
今後の道筋：パイプライン全体の運用化
このフレームワークは単なる分析モデルではなく、行動計画です。真のレジリエンスを達成するには、5段階すべての測定を運用化しなければなりません。
ステップ1：MTTRダッシュボード
まず、実行可能な可視性を提供する必要があります。MTTRダッシュボードが第一歩です。このダッシュボードには次が含まれるべきです。
-
フェーズ認識型の可視化：各インシデントについて、5段階それぞれに費やした時間を可視化するウォーターフォールチャート。
-
実行可能な指標：P50/P90のパフォーマンスとSLA違反率の明確な追跡。
-
コホート・ベンチマーキング：顧客が匿名で、自社のパフォーマンスを業界、地域、企業規模に対してベンチマークできる機能。
ステップ2：「レジリエンス・モジュール」（ITSM連携）
テレメトリのギャップを埋めるには、このフレームワークを、事業を動かすITSMプラットフォームに直接統合しなければなりません。ServiceNowやAtlassian Jiraのようなツールに、新しい「レジリエンス・モジュール」を作成することを提案します。このモジュールは既存ツールを置き換えるのではなく、中央のオーケストレーションおよび測定レイヤーとして機能し、次を実現します。
-
CMDBとの統合：資産を、その事業影響（ステージ1）データに動的に紐付ける。
-
インシデント管理およびSIEMとの統合：インシデントが宣言された瞬間に「レジリエンスタイマー」を自動起動し、MTTDとMTTSを取得する。
-
復旧プラットフォームとの統合：MTTGSとMTTrのために、リアルタイムのAPIテレメトリを取り込む。
-
検証のオーケストレーション：検証タスクをアプリケーションオーナーへ自動割り当てし、その応答時間を追跡してMTTVを取得する。
ステップ3：危機シミュレーション・エンジン
最後に、受動的な測定から能動的な危機シミュレーションへ進化しなければなりません。これにより、組織はサンドボックス環境で現実的なソフトウェア駆動のシナリオを実行し、MVBに対するパフォーマンスを能動的に測定して、レジリエンス態勢を真に成熟させることができます。
この5段階パイプラインを採用し、それを測定するツールを構築し、コア業務運用へ統合することで、私たちはようやく、反応的な態勢から予測的な態勢へ移行し――データに裏打ちされた確信をもって復旧を推進できるようになります。
翻訳元: https://zerolabs.rubrik.com/blog/beyond-mttr-a-measurable-framework-for-true-cyber-resilience
