MTTD vs MTTR — różnice, wzory, benchmark

TL;DR — czy MTTD i MTTR to to samo?

Nie, to dwie różne metryki w tym samym pipeline Incident Response. MTTD (Mean Time To Detect) mierzy, ile czasu zajmuje wykrycie incydentu od momentu jego rzeczywistego wystąpienia w środowisku. MTTR (Mean Time To Respond lub Recover) startuje dokładnie tam, gdzie kończy się MTTD — od potwierdzonego wykrycia — i mierzy czas pełnej reakcji aż do zamknięcia. Razem definiują tzw. dwell time, czyli łączny czas obecności atakującego w sieci. W modelu dojrzałego SOC 24/7 obie metryki są raportowane wspólnie, ponieważ szybkie wykrycie bez sprawnej reakcji daje znikomy efekt obronny, a sprawna reakcja bez wczesnego wykrycia oznacza, że atakujący zdążył już zrealizować swoje cele (eksfiltracja, ransomware deployment, persistence).

MTTD vs MTTR — porównanie

Aspekt	MTTD (Mean Time To Detect)	MTTR (Mean Time To Respond / Recover)
Co mierzy	Czas od wystąpienia zdarzenia do jego wykrycia	Czas od wykrycia do pełnego zamknięcia incydentu
Jednostka	Minuty / godziny / dni	Godziny / dni
Punkt startu	Timestamp zdarzenia w logach źródłowych (endpoint, firewall, IdP)	Moment potwierdzenia alertu jako incydentu
Punkt końcowy	Potwierdzenie alertu w SIEM/EDR/XDR	Containment (Respond) lub przywrócenie usług (Recover)
Wzór	Σ(t_wykrycia − t_wystąpienia) / N	Σ(t_zamknięcia − t_wykrycia) / N
Typowy benchmark 2026	Finance ~24h, Healthcare ~72h, OT ~5 dni	Finance ~48h, Healthcare ~5 dni, OT ~2 tygodnie
Główne narzędzia poprawy	EDR/XDR, SIEM, threat hunting, NDR, honeypots	SOAR, EDR isolation, runbooki, retainer DFIR, 24/7 SOC

Definicja MTTD (Mean Time To Detect)

MTTD to średni czas między wystąpieniem zdarzenia bezpieczeństwa w środowisku a jego wykryciem przez system detekcyjny lub analityka SOC. Wartość ta najlepiej obrazuje dojrzałość warstwy detekcyjnej — czyli jakość reguł SIEM, korelacji, polityk EDR, programu threat huntingu oraz pokrycia logami (log coverage). Pełna definicja, źródła historyczne metryki i zaawansowane warianty (per typ ataku, per priorytet) znajdują się w osobnym wpisie MTTD.

Kluczowy niuans: MTTD nie powinien być liczony od momentu pierwszego alertu w konsoli SIEM, lecz od timestampu zdarzenia w logach źródłowych (np. wpis w logu endpoint, w firewall syslog, w Entra ID sign-in log). Często okazuje się, że dane wskazujące na incydent były dostępne wiele godzin lub dni wcześniej, ale reguła detekcyjna albo nie istniała, albo wymagała zbyt długiego okna agregacji.

Definicja MTTR (Mean Time To Respond / Recover)

MTTR jest dziś jedną z najczęściej raportowanych metryk SOC, ale historycznie skrót ten ma dwa znaczenia używane wymiennie:

• MTTR jako Mean Time To Respond — czas od wykrycia do containmentu, czyli zatrzymania rozprzestrzeniania zagrożenia (izolacja hosta, blok konta, segmentacja sieci, zablokowanie domeny C2 na DNS).
• MTTR jako Mean Time To Recover — czas od wykrycia do pełnego przywrócenia usług biznesowych do stanu produkcyjnego (re-image endpointów, restore z backupu, rotacja poświadczeń, przywrócenie SLA).

We współczesnym podejściu (NIST IR 2025, ENISA Good Practices for IR 2024) coraz częściej rozdziela się te dwie wartości na MTTR-Respond i MTTR-Recover, ponieważ między nimi może być wielogodzinna lub wielodniowa luka — host można zaizolować w 5 minut, ale przywrócić go produkcyjnie dopiero po dniu forensiki. Pełną definicję, decompozycję wzoru i wskazówki implementacyjne opisaliśmy w osobnym wpisie MTTR.

Pełny pipeline metryk IR — gdzie pasują MTTD i MTTR

W dojrzałym programie Incident Response mierzymy nie dwie, lecz siedem powiązanych metryk w sekwencji czasowej:

1. Event — zdarzenie wystąpiło w środowisku (timestamp w logu źródłowym).
2. MTTD (Mean Time To Detect) — czas do wykrycia i potwierdzenia, że to incydent, a nie szum.
3. MTTA (Mean Time To Acknowledge) — czas od pojawienia się alertu w kolejce do podjęcia go przez analityka. Wąskie gardło typowe dla zespołów 8/5 lub niedoinwestowanych.
4. MTTI (Mean Time To Investigate) — czas triage’u, scopingu i wstępnej atrybucji. Zależy od jakości log retention i dostępu do EDR telemetry.
5. MTTC (Mean Time To Contain) — czas do izolacji zagrożenia. Tu największą rolę gra automatyzacja: jeśli EDR potrafi sam zaizolować host przy score > X, MTTC może być liczony w minutach.
6. MTTR-Respond — czas do eradication: usunięcie malware, rotacja poświadczeń, zamknięcie wektora wejścia (np. wyłączenie konta serwisowego, łatanie podatności).
7. MTTR-Recover — czas do pełnego przywrócenia usług, re-imagingu, restore z backupu, weryfikacji integralności.
8. MTTI-Improve (opcjonalnie) — czas od zamknięcia incydentu do wdrożenia lessons learned: nowe reguły detekcji, aktualizacja runbooków, dodatkowe szkolenie zespołu.

Wartość każdej z tych metryk pokazuje inne wąskie gardło. Wysokie MTTA = brak zmianowych analityków lub przeciążona kolejka. Wysokie MTTC = brak automatyzacji izolacji. Wysokie MTTR-Recover = brak procedur backupowych albo brak procedur re-imagingu.

Wzór i przykład obliczenia

Obie metryki są klasycznymi średnimi arytmetycznymi liczonymi w spójnej jednostce czasu (minuty, godziny lub dni — w zależności od typowej skali incydentów):

MTTD = Σ (t_wykrycia_i - t_wystąpienia_i) / N
MTTR = Σ (t_zamknięcia_i - t_wykrycia_i) / N
dwell_time = MTTD + MTTR

gdzie N to liczba incydentów w analizowanym okresie (zwykle miesiąc lub kwartał).

Przykład numeryczny — 5 incydentów w miesiącu:

#	t_wystąpienia	t_wykrycia	t_zamknięcia	MTTD_i	MTTR_i
1	02:00	04:00	09:00	2h	5h
2	14:10	14:25	16:25	15min	2h
3	22:00 (D-1)	06:00	11:00	8h	5h
4	10:00	10:20	12:20	20min	2h
5	08:00	11:00	19:00	3h	8h

Średnie:

• MTTD ≈ 2h 51min
• MTTR ≈ 4h 24min
• dwell time ≈ 7h 15min

Najczęstsza pułapka pomiaru: zespoły liczą MTTD od pierwszego alertu w SIEM, nie od momentu wystąpienia zdarzenia w logach źródłowych. Te dwie wartości potrafią różnić się o godziny lub dni, zwłaszcza gdy reguła detekcyjna wymaga agregacji wielu zdarzeń (np. brute force po 50 nieudanych logowaniach w 1h). Tylko liczenie od źródła pokazuje prawdziwą skuteczność warstwy detekcyjnej.

Dodatkowa decyzja metodologiczna: czy do MTTD/MTTR włączać incydenty fałszywie pozytywne (false positive) lub zamknięte bez eskalacji? Większość organizacji raportuje tylko incydenty potwierdzone (True Positive po triage’u). To zawęża próbkę, ale daje porównywalność między miesiącami.

Benchmark MTTD/MTTR w 2026 — różne sektory

Sektor	MTTD median	MTTR median	Źródło
Finance / FinTech	~24h	~48h	IBM Cost of Data Breach 2024, Verizon DBIR 2025
Tech / SaaS	12-48h	24-72h	SANS SOC Survey 2024
Healthcare	~72h	~5 dni	IBM Cost of Data Breach 2024
Retail / E-commerce	~48h	~3 dni	Verizon DBIR 2025
Manufacturing / OT-ICS	5-10 dni	2 tygodnie+	Mandiant M-Trends 2024, SANS ICS Survey 2024
Energy / Utilities	7-14 dni	2-4 tygodnie	Dragos Year in Review 2024
Public Sector	5-7 dni	1-2 tygodnie	Verizon DBIR 2025

Globalny median dwell time raportowany przez Mandiant M-Trends spadł z 16 dni (2022) do około 10 dni (2023), co jest pozytywnym trendem — zasługa szerszej adopcji EDR/XDR i programów MDR. Jednak w sektorach OT/ICS i Healthcare wartości pozostają wielokrotnie wyższe, głównie z powodu fragmentaryzacji infrastruktury, ograniczonej widoczności na warstwie OT (Purdue Model levels 0-2) i niemożności łatania w trakcie produkcji.

Cel pragmatyczny dla dojrzałego SOC 24/7 w 2026: MTTD < 1h i MTTR < 4h dla incydentów typowych (commodity malware, phishing z kradzieżą poświadczeń, próby brute force). Dla incydentów typu APT, ransomware z lateral movement lub insider threat — odpowiednio dłużej, ale z jasno udokumentowaną dekompozycją czasu między fazami (MTTA → MTTI → MTTC → MTTR).

Jak poprawić MTTD

Poprawa MTTD wymaga równoległej pracy w sześciu obszarach:

1. EDR / XDR z analizą behawioralną — Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity, Sophos Intercept X, Trend Vision One. Sygnaturowe AV nie wykryje fileless malware, living-off-the-land i nowoczesnych technik MITRE ATT&CK. EDR/XDR z UEBA potrafi.
2. SIEM z korelacją wielo-źródłową — Splunk Enterprise Security, Elastic SIEM, Microsoft Sentinel, IBM QRadar, Wazuh (open-source). Klucz to log coverage: jeśli SIEM nie ma logów z IdP (Entra ID, Okta), endpointów, firewalli i krytycznych aplikacji, korelacja będzie ślepa.
3. Proaktywny threat hunting — cykle 2-tygodniowe, oparte na frameworku MITRE ATT&CK, z hipotezami typu “czy w naszej sieci jest T1078 Valid Accounts?”. Wykrywa to, czego reguły jeszcze nie pokrywają.
4. NDR (Network Detection and Response) — Darktrace, ExtraHop Reveal(x), Vectra AI, open-source Zeek + Suricata w połączeniu z SIEM. Wykrywa lateral movement i C2 traffic, których EDR może nie złapać (zwłaszcza na urządzeniach niezarządzanych: IoT, OT, BYOD).
5. Deception technology / honeypots — Thinkst Canary, CounterCraft. Niskoszumne, wysokiej wiarygodności źródło alertów: każde dotknięcie honeypotu to z definicji aktywność złośliwa.
6. 24/7 SOC zamiast 8/5 — większość ataków startuje poza godzinami pracy, w weekendy lub święta. Bez całodobowego pokrycia MTTD nocnych incydentów rośnie do 8-12h.

Dodatkowo: threat intelligence feeds (komercyjne lub MISP), regularne purple teaming, oraz adopcja Sigma rules jako standardu wymiany reguł detekcyjnych między zespołami.

Jak poprawić MTTR

Lista kontroli dla MTTR jest dłuższa, bo dotyczy całego workflow od potwierdzenia incydentu do przywrócenia usług:

1. SOAR playbooki — Tines, Cortex XSOAR, Splunk SOAR, Microsoft Sentinel automation rules. Każdy powtarzalny scenariusz (phishing reporting → blok nadawcy + szukanie podobnych emaili w innych skrzynkach + reset haseł użytkowników, którzy kliknęli) powinien mieć playbook.
2. Automatic containment — izolacja hosta przez EDR jednym kliknięciem albo automatycznie, gdy score ryzyka przekroczy próg. CrowdStrike Falcon, Defender for Endpoint, SentinelOne wszystkie to wspierają.
3. Dokumentowane runbooki per typ incydentu — ransomware, BEC (Business Email Compromise), insider threat, DDoS, web app compromise, supply chain. Każdy z innym workflow, innym zespołem eskalacji i innym SLA.
4. Kwartalne tabletop exercises — symulacja incydentów z udziałem zarządu, prawnych, PR, ubezpieczyciela cyber. Ujawniają luki w komunikacji, które przy realnym incydencie kosztują dni.
5. Retainer agreement z DFIR vendorem — Mandiant, Kroll, CrowdStrike Services, Stroz Friedberg, Secureworks. SLA na rozpoczęcie engagementu w 1-4h, jeśli incydent przerasta wewnętrzny zespół. Bez retainera negocjacje kontraktu w środku incydentu kosztują 2-3 dni.
6. Automated forensics tools — Velociraptor, GRR, KAPE do zbierania artefaktów z setek endpointów w minutach zamiast ręcznej akwizycji.
7. 24/7 SOC zamiast 8/5 — analogicznie jak dla MTTD, kontener i recovery często wymagają decyzji w środku nocy.
8. Integracja EDR ↔ SIEM ↔ SOAR ↔ ticketing — alert powinien automatycznie tworzyć ticket, wzbogacać go o kontekst z SIEM, sugerować playbook, a po decyzji analityka uruchomić akcję containment. Bez integracji każdy alert to ręczny pivot między 5 konsolami.

Top błędy w mierzeniu MTTD/MTTR

1. Liczenie MTTD od pierwszego alertu w SIEM, nie od wystąpienia zdarzenia w logach źródłowych. Daje sztucznie zaniżony MTTD i ukrywa luki w pokryciu detekcji.
2. Mieszanie MTTR-Respond i MTTR-Recover w jedną wartość. Bardzo różne procesy, bardzo różne dźwignie poprawy. Rozdziel raportowo.
3. Ignorowanie incydentów, które nie eskalowały do P1/P2. Zmniejsza próbkę i daje fałszywe poczucie kontroli — większość ataków rozpoczyna się od P3/P4, które rosną w czasie.
4. Brak segmentacji per typ ataku. MTTD i MTTR dla phishingu, ransomware, insider threat i DDoS różnią się o rzędy wielkości. Średnia ogólna ukrywa, gdzie jest realny problem.
5. Brak baseline previous month / quarter dla trend tracking. Pojedyncza wartość MTTD nic nie mówi; liczy się trend: czy MTTD spada miesiąc do miesiąca, czy rośnie?

Dodatkowy częsty błąd: traktowanie benchmarków sektorowych jako celu zamiast jako punktu odniesienia. Twoja organizacja ma inną architekturę, inny stack i inny krajobraz zagrożeń — porównuj się przede wszystkim ze sobą sprzed roku, a benchmarki sektorowe wykorzystuj jako kontekst dla rozmowy z zarządem.

Powiązane terminy

• MTTD (Mean Time To Detect) — pełna definicja, źródła historyczne i warianty per typ ataku
• MTTR (Mean Time To Respond / Recover) — pełna definicja i decompozycja Respond vs Recover
• SOC (Security Operations Center) — organizacyjne tło dla obu metryk
• SIEM — fundament warstwy detekcyjnej, bezpośredni driver MTTD
• XDR — Extended Detection and Response, kluczowe narzędzie poprawy MTTD/MTTR
• EDR — Endpoint Detection and Response, źródło alertów i punkt automatycznego containmentu
• Incydent bezpieczeństwa — definicja jednostki, którą mierzy MTTD i MTTR
• Threat hunting — proaktywna dźwignia obniżania MTTD

Sprawdź nasze usługi

Chcesz poprawić MTTD i MTTR w swojej organizacji? Sprawdź:

• SOC 24/7 — wykrywanie i reagowanie z mierzonym SLA na MTTD i MTTR
• Incident Response — gotowość na incydent z retainerem DFIR
• Audyt bezpieczeństwa — diagnoza dojrzałości detekcji i procesu IR

MTTD i MTTR nie są celami same w sobie — są wskaźnikami zdrowia procesu Incident Response. Organizacje, które traktują je jako KPI bez kontekstu (segmentacja, baseline, dekompozycja), ryzykują optymalizację metryki kosztem realnego bezpieczeństwa. Najlepsze SOC raportują te wartości jako trend kwartalny z rozbiciem per typ ataku, równolegle z miarami jakościowymi (procent incydentów wykrytych proaktywnie vs reaktywnie, procent zakończonych pełną eradication vs tylko containmentem).