平均修復時間 (MTTR)

TL;DR

• MTTRは、識別後のセキュリティ脆弱性を解決するために必要な平均時間を表し、運用効率の直接的な指標を提供します。
• **MTTRを計算するには、**問題を修正するために費やした総時間をインシデントの数で割ります。
• **目標は、**攻撃者が既知のギャップを悪用する可能性を減らすために、露出時間を最小化することです。
• **解決策はプロセスを加速することです。**脆弱性検出からコード修正生成までを自動化し、手動のチケットキューでの遅延を排除し、迅速な修復を確保します。

MTTRとは何か？

平均修復時間 (MTTR) は、既知の脅威に対してどれだけ迅速に対応するかを示す重要なサイバーセキュリティ指標です。脆弱性が発見されてから修正が実施されるまでの時間を測定します。

MTTDのような指標が検出速度を反映する一方で、MTTRは組織の真の修復効率を明らかにします。迅速な検出は、リスク露出を抑え、ビジネス継続性を支援するために迅速な解決と一致する必要があります。

MTTRが重要な理由

サイバー犯罪者は従来の開発タイムラインよりも速く動作し、応答性のあるセキュリティ運用の需要を加速しています。業界のトレンドは、防御のウィンドウが縮小していることを示しています。

• 5日間のエクスプロイトウィンドウ: 2025年には、脆弱性が公表されてから実際に悪用されるまでの平均エクスプロイトまでの時間 (TTE) が32日からわずか5日に短縮されました (CyberMindr, 2025)。
• エクスプロイトの急増: 脆弱性を利用する方法が今年34%増加し、現在では確認されたすべての侵害の20%を引き起こしています。
• 修正の遅れ: 攻撃者は数日で行動しますが、組織は通常数週間かかります。エッジおよびVPNデバイスの重大な脆弱性を修正する中央値は32日であり、重大なリスクウィンドウを残しています。欠陥のうち完全に修正されるのは54%のみです (Verizon DBIR, 2025)。日数の加速: 悪用されたゼロデイ脆弱性の発見は昨年と比較して**46%**増加しました。攻撃者はこれらの欠陥を識別後数時間以内に武器化しています (WithSecure Labs, 2025)。
• 高いMTTRがビジネスコストを押し上げる: 技術的負債をはるかに超えます。2025年には、米国のデータ侵害の平均コストは4.4百万ドルであり、主に対応の遅れと規制上の罰則によるものです (IBM, 2025)。
• コンプライアンスの罰則: DORAなどの規則の下では、長い露出時間は運用上の回復力の失敗と見なされます。高いMTTRを持つ組織は、義務的な報告と大規模な不遵守罰金に直面しています。エクスプロイトスクリプトより速く動くことはできません。防御は純粋に理論的です。

MTTRの計算方法

MTTRは、特定の期間における修理回数でシステムの修理に費やした総時間を割ることで計算されます。

式

MTTR-formula

計算例

先月、あなたのエンジニアリングチームが4件のインシデントを処理したと仮定します。

1. インシデントA: データベースの停止（30分で修正）
2. インシデントB: APIの障害（2時間 / 120分で修正）
3. インシデントC: キャッシュエラー（15分で修正）
4. インシデントD: セキュリティパッチ（45分で修正）

• 総修理時間: 30 + 120 + 15 + 45 = 210分
• 修理回数: 4

MTTR-formula-calculation

これは、チームが問題の修正を開始してから平均して52分で修正することを意味します。

実践例

2つの会社が重大なセキュリティ脆弱性（例：Log4Shell）に直面していると考えてください。

会社A（高MTTR）:

• プロセス: 手動。アラートはメールに送信されます。エンジニアが手動でサーバーにSSHして脆弱なjarファイルを見つけ、一つずつパッチを適用する必要があります。
• MTTR: 48時間。
• 結果: 攻撃者は脆弱性を利用するために2日間の猶予があります。データが侵害される可能性が高いです。

会社B（低MTTR - Plexicusを使用して自動修復）:

• プロセス: 自動化。脆弱性は即座に検出されます。影響を受けたコンテナを隔離し、パッチまたは仮想ファイアウォールルールを適用するための自動プレイブックがトリガーされます。
• MTTR: 15分。
• 結果: 攻撃者が成功する前に脆弱性が閉じられます。

MTTRを使用する人

• DevOpsエンジニア - デプロイメントとロールバックのパイプラインの効率を追跡するため。
• SRE（サイト信頼性エンジニア） - アップタイムのSLA（サービスレベルアグリーメント）を満たすことを保証するため。
• SOCアナリスト - アクティブなセキュリティ脅威を迅速に無効化できるかどうかを測定するため。
• CTO & CISO - 自動化ツールへの投資を回復時間の短縮を示すことで正当化するため。

MTTRを適用するタイミング

MTTRは継続的に監視されるべきですが、特に重要なのはSDLC（ソフトウェア開発ライフサイクル）のインシデント対応フェーズです。

• インシデント中: ライブの脈拍チェックとして機能します。「これを十分に速く修正しているか？」
• 事後分析: インシデント後にMTTRをレビューすることで、遅延が問題の検出（MTTD）または修正（MTTR）によって引き起こされたかどうかを特定するのに役立ちます。
• SLA交渉: 平均MTTRが4時間である場合、「99.99%のアップタイム」を顧客に約束することはできません。

MTTRを削減するためのベストプラクティス

• すべてを自動化する: 手動の修正は遅く、エラーが発生しやすいです。Infrastructure as Code (IaC)を使用して、壊れたインフラストラクチャを手動で修正するのではなく、再デプロイします。
• より良い監視: 見えないものは修正できません。詳細な観測ツールは根本原因を迅速に特定するのに役立ち、「診断」部分の修理時間を短縮します。
• ランブックとプレイブック: 一般的な障害に対する事前に書かれたガイドを用意します。データベースがロックされた場合、エンジニアは「データベースのロック解除方法」をGoogleで検索する必要はありません。
• 非難のない事後分析: 人ではなくプロセスの改善に焦点を当てます。エンジニアが罰を恐れると、失敗を隠す可能性があり、MTTRメトリクスが不正確になります。

関連用語

• MTTD (Mean Time To Detect)
• MTBF (Mean Time Between Failures)
• SLA (Service Level Agreement)
• インシデント管理

一般的な誤解

• 誤解: 「ゼロ脆弱性」に到達できる。

  現実: 目標は、重大な問題を迅速に修正して悪用を防ぐことです。

• 誤解: スキャナーが多いほどセキュリティが向上する。

  実際には、ツールを追加するだけでは統合されていない場合、ノイズと手動作業が増えるだけです。

• 誤解: セキュリティツールは開発者を遅らせる。

  現実: セキュリティは「壊れた」アラートを生成する場合にのみ開発者を遅らせます。事前に書かれたプルリクエストを提供することで、彼らの調査時間を何時間も節約できます。

FAQ

「良い」MTTRとは何ですか？

トップのDevOpsチームは、重大な脆弱性に対して24時間以内のMTTRを目指しています。

MTTRはMTTDとどう違いますか？

MTTD（平均検出時間）は、脅威が存在していることに気付くまでの時間を示します。MTTRは、脅威を発見した後にそれが残る時間を示します。

AIは実際にMTTRに役立つのか？

はい。AIツールのPlexicusはトリアージを処理し、修正を提案します。これにより、通常は修復プロセスの80％を占める部分がカバーされます。

最終的な考え

MTTRはセキュリティプログラムの心臓部です。これが高いと、リスクも高くなります。問題の発見からプルリクエストの作成までの移行を自動化することで、セキュリティをボトルネックとして扱うのではなく、CI/CDパイプラインの通常の一部として扱うことができます。