MTTD 是什麼？MTTR 是什麼？
資訊安全, 管理服務

MTTD / MTTR 是什麼？一看就懂的資安「速度指標」，用實例看懂平均偵測 / 回應時間，讓資安事件不再失控

首頁 » MTTD / MTTR 是什麼？一看就懂的資安「速度指標」，用實例看懂平均偵測 / 回應時間，讓資安事件不再失控

為什麼 MTTD / MTTR 是資安事件的「速度指標」?

企業每天都在面對釣魚信、帳號濫用、惡意程式、雲端設定錯誤等資安風險。重點不是「會不會發生」，而是發生後多快被發現（MTTD）、多久處理完（MTTR）。

MTTD 與 MTTR能把這件事量化，讓團隊有共同語言，把「安全」和「營運」真正接起來：

  • 越快被發現 → 攻擊者可活動的時間越短
  • 越快處理完 → 中斷、外洩與品牌風險越低

▌什麼是 MTTD（Mean Time To Detect｜平均偵測時間）

MTTD 指的是從問題真正發生到被您發現並確認為事件之間的平均時間，用來衡量「我們到底多快看見問題」。

怎麼算：把每起事件的（確認時間 – 發生時間）取平均。

例子：10:03 出現異常登入 → 10:17 被確認為安全事件 → 這一案的 MTTD = 14 分鐘。

MTTD 越短，攻擊者能在環境裡活動的空窗就越小，風險也更容易被壓住。因此在資安防護中，持續壓縮 MTTD 非常重要。讓 MTTD 下降的關鍵不在於多裝工具，而是看得到、看得懂、主動去看。

如何快速拉短 MTTD：

  1. 看得到：把端點行為、帳號登入、雲端稽核與對外出入口（Proxy/DNS/WAF/郵件）等常見跡象集中觀測。
  2. 看得懂：把零散訊號串成情境，像是「非常用地區登入後立刻大量下載」這類可直接引發警覺的條件。
  3. 主動巡檢/獵捕：不只是被動等告警，透過例行的異常巡檢與獵捕，主動把可疑的行為挑出來。

將這三件事做到位，偵測自然會更早、更穩定。

▌什麼是 MTTR（Mean Time To Respond/Remediate｜平均回應 / 修復時間）

MTTR 指的是從事件被您確認之後，到處理完成並關單之間的平均時間，用來衡量「我們多快把事情收拾好」。

怎麼算：把每起事件的（關單時間 − 確認時間）取平均。
例子：10:17 確認事件 → 12:00 修復並關單 → 這一案的 MTTR = 1 小時 43 分鐘。

MTTR 越短，停擺時間越少、外洩與法遵風險越低、對客戶與品牌的影響也更小。真正的關鍵，是把「下一步」設計得清楚且可執行。

如何快速拉短 MTTR：

  1. 劇本化（Runbook）：把高風險情境寫成 3–5 步的簡潔流程，值班人員一開單就知道怎麼做。
  2. 半自動／自動化（SOAR）：命中高可信度條件時，一鍵暫停帳號、隔離端點或封鎖網域。
  3. 授權與升級路徑：事前釐清誰能按關鍵動作、何時往上提，避免卡在簽核。當「下一步」始終清楚可執行，回應自然就會快。

▌一張表看懂 MTTD / MTTR 差別與怎麼變短

指標從 → 到代表什麼將 MTTD / MTTR 快速變短的方法
MTTD事件發生 → 被您「確認」發現速度完整可觀測面、情境關聯、主動巡檢/獵捕
MTTR被您「確認」 → 關單處理速度劇本化處置、半自動/自動隔離、明確授權與升級
MTTD/MTTR 事件時間線（發生→偵測→圍堵→關單）

▌從情境來看比較：MTTD / MTTR 快與慢，差很多

情境 A：釣魚信造成帳號被濫發郵件

  • 快的版本：15 分鐘內發現（MTTD 短），30 分鐘內停用帳號並重設密碼（MTTR 短），負面影響局部可控。
  • 慢的版本：隔天才發現（MTTD 長），黑名單擴散、客訴增加，郵件信任度下滑，恢復時間從「小時」變成「天」。

情境 B：端點（工作站）被植入惡意程式

  • 快的版本：偵測到可疑連線＋異常行為，自動隔離端點，2 小時內收尾。
  • 慢的版本：使用者抱怨變慢才追到感染源，內部清查多日，甚至發現橫向移動跡象。

▌如何設定企業的 MTTD / MTTR KPI 才合理？

以下提供幾個方向建議，重點在於先合理，再逐步上調，可先訂一個做得到、能穩定達標的目標，等穩了再一點一點加嚴。

  • 高風險事件（勒索前兆、疑似外洩）：MTTD < 15 分、MTTC < 30 分、MTTR < 2 小時
  • 一般事件：MTTD < 60 分、MTTR < 24 小時
  • 不要只看平均：同步追蹤 P50/P90（中位/90 分位），再看關單率與同因復發率，避免只有「漂亮數字」。

▌為什麼 MTTD / MTTR 這兩個「時間指標」總是降不下來？

常見的情況在於：

  • 只盯攔截數：攔得多不代表安全，MTTR 長一樣會中斷。
    看到「擋了很多」就以為安全，但只要處理得慢，業務一樣會被拖住；真正該追的是「多快被發現、多久處理完」（也就是 MTTD／MTTR），而不是僅僅「擋了幾次」。

  • 時間不同步（NTP）：系統時鐘對不起來，數據一定失真。
    若各系統的時鐘沒校準，會讓事件時間線看起來比實際更快或更慢，導致 MTTD／MTTR 失真；先把 NTP 校時做好，數據才有意義。

  • 確認與關單的定義不一致：跨部門標準不一，指標就無法比較與改善。
    有人把 SOC（Security Operations Center｜資安營運中心）接手當確認、有人要人工複核才算；有人隔離就關單、有人要復原驗證完才關，定義不同數字就各說各話。

首先將系統時間對齊、再把「何時算確認／何時算關單」說清楚，然後把注意力從「攔了幾次」換成「多快發現、多久處理完」，MTTD / MTTR 才會真的、而且是穩定地往下走。

最後，MTTD / MTTR 和 MDR / EDR 的關係

  • EDR 是工具：會告警、能隔離；但不等於 7×24 有人看、有劇本會動作。
  • MDR 是服務：幫您把 MTTD／MTTR 壓低，有人持續看、主動找、照劇本做、按月給改善建議。
  • MTTD／MTTR 是時間指標：前者是多快發現（Detect），後者是多久處理完（Respond/Remediate）；是衡量 EDR／MDR 是否有效 的共同語言與 KPI。

EDR 工具解決「能不能做」，MDR 服務確保「有人做」，MTTD / MTTR 指標用來確認「做得夠不夠快、好不好、是否達到期望」。

延伸閱讀：

1. 什麼是 MTTD？

MTTD（Mean Time To Detect｜平均偵測時間）= 從事件「實際發生」到被您「發現並確認為事件」的平均時間；用來衡量多快看見問題。

2. 什麼是 MTTR？

MTTR（Mean Time To Respond/Remediate｜平均回應／修復時間）= 從事件「被確認」到「處理完成並關單」的平均時間；用來衡量多快把事情收拾好。

3. 為什麼要同時看 MTTD 與 MTTR？

一個管「發現速度」、一個管「處理速度」。兩者都短，才能把停擺、外洩與品牌風險壓到最低。

4. MTTD 與 Dwell Time 有何差別？

Dwell Time 是攻擊者「從發生到被您發現」的總停留時間；MTTD 是您「從發生到確認為事件」的時間。Dwell Time 通常更長。

5. 沒有專職資安團隊該如何著手改善？

可藉由 MDR 服務來協助企業規劃/建置/維運，透過專業的 MDR 服務廠商來協助，可以較輕鬆又正確的進行這項計劃。
歡迎與 Cloudmax 匯智聯繫，了解 MDR 服務
加入匯智官方 LINE （https://line.me/R/ti/p/@cloudmax）
留下詢問表單：https://support.cloudmax.com.tw/submitticket.php?step=2&deptid=18
來電詢問：02-2718-7200

6. 有了 EDR，還需要 MDR 嗎？

EDR 是工具，會告警、能隔離；但不等於 7×24 有人看、有劇本會動作。MDR 是服務，目標就是把 MTTD / MTTR 壓低。
了解 MDR 與 EDR 的差異：https://blog.cloudmax.com.tw/mdr-vs-edr/

7. MDR 與 EDR 差異比較表

MDR EDR 差異比較表

7. Cloudmax 匯智 MDR 服務方案提供哪些支援？

Cloudmax MDR 方案提供在地 24×7 SOC 監看、主動威脅獵捕、跨雲與端點整合偵測（如 Microsoft 365、AWS、GCP、Azure 等）、AI/行為關聯分析與降噪、以及依 標準化 Playbook 進行的快速回應與處置（含隔離/封鎖/帳號暫停）。
重大事件可進一步做鑑識與回溯，並協助您的稽核/合規需求。這些能力的核心目標是把 MTTD/MTTR 壓低，通常做到「30 分內通報、數小時內提出解法/完成處置」。
更多 MDR 服務方案說明可參考：https://www.cloudmax.com.tw/product/mdr-security-service

8. Cloudmax 匯智 MDR 服務方案會提供哪些資料 / 報告？

定期提供 月報/季報（事件趨勢、成效與建議）、重大事件鑑識/回溯報告（攻擊路徑、入侵來源、處置過程、改善清單），以及可用於合規/稽核的對照文件與佐證。

歡迎轉載！請見：轉載原則。

Image by AI-generated via ChatGPT / DALL·E