MTTD

MTTD (mean time to detect) to uśredniony czas od początku złośliwej aktywności do jej wykrycia. Służy do oceny, jak skutecznie organizacja albo SOC (Security Operations Center) zauważa incydenty. NIST wymienia wśród miar zespołu reagowania czas, jaki upłynął od początku incydentu do jego odkrycia ^[1]. MTTD jest średnią z tej wartości dla wielu incydentów w wybranym okresie.

Jak działa

Dla każdego incydentu potrzebne są dwa znaczniki czasu: moment pierwszej złośliwej aktywności i moment wykrycia. Pierwszy zwykle ustala się dopiero po analizie, na przykład z logów, bo w chwili ataku nikt go nie zauważył. Drugi to chwila, w której powstał alert albo zgłoszenie. MTTD to suma różnic podzielona przez liczbę incydentów.

RYS. 1Co mierzy MTTD

Narzędzia SIEM przechowują oba znaczniki. W Microsoft Sentinel tabela SecurityIncident ma pole FirstActivityTime z czasem pierwszego zdarzenia i CreatedTime z czasem utworzenia incydentu ^[3]. Różnica tych pól daje czas wykrycia dla pojedynczego incydentu. Microsoft pokazuje też, jak liczyć percentyle czasów obsługi, na przykład 50., 90. i 99. percentyl ^[3]. Percentyle są przydatne, bo średnią łatwo zaburza jeden incydent wykryty po wielu miesiącach. Dokumentacja zwraca też uwagę na pułapkę w danych: każda zmiana incydentu dodaje do tabeli nowy wpis, więc przed liczeniem trzeba zostawić tylko ostatni rekord każdego incydentu ^[3]. Bez tego incydent edytowany dziesięć razy liczyłby się dziesięciokrotnie. Podobne pułapki występują w każdym systemie zgłoszeń, dlatego sposób liczenia MTTD warto zapisać razem z wynikiem, a wynik porównywać tylko z wcześniejszymi pomiarami tą samą metodą.

MTTD a dwell time

Pokrewną miarą jest czas przebywania atakującego w sieci (dwell time). Mandiant w raporcie M-Trends definiuje go jako czas od włamania do wykrycia ^[2]. Globalna mediana wyniosła 11 dni w 2024 roku i 14 dni w 2025 roku ^[2]. Dla incydentów szpiegowskich i incydentów z udziałem północnokoreańskich pracowników IT mediana sięgnęła 122 dni ^[2]. Te liczby pokazują, dlaczego MTTD ma sens tylko razem z rozkładem: kilka długich włamań zmienia średnią bardziej niż wiele krótkich.

Raport wskazuje też źródło wykrycia. W 2025 roku organizacje wykryły włamanie same w 52% badanych przypadków, wobec 43% rok wcześniej ^[2]. Wykrycie wewnętrzne jest celem, bo powiadomienie z zewnątrz oznacza zwykle, że napastnik zdążył już działać.

W WordPressie

Na stronie WordPress czas wykrycia zależy od tego, kto pierwszy zobaczy objaw. Dokumentacja WordPress.org wymienia typowe wskaźniki kompromitacji (IoC): wpis strony na czarną listę Google lub Bing, wyłączenie strony przez hostingodawcę, oznaczenie jej jako źródła złośliwego oprogramowania, skargi czytelników na ostrzeżenia antywirusa i nieautoryzowane działania, takie jak nowi użytkownicy ^[5]. Większość tych sygnałów przychodzi z zewnątrz, czyli po szkodzie. Skrócenie MTTD polega na przeniesieniu wykrycia do wnętrza strony i serwera.

Zmiany w plikach. Monitorowanie integralności plików porównuje sumy kontrolne z wzorcem i alarmuje przy niezgodności ^[4]. W Wazuh domyślne skanowanie odbywa się co 12 godzin, a atrybut realtime pozwala zgłaszać zmiany w wybranych katalogach na bieżąco ^[4]. Różnica między tymi trybami przekłada się wprost na MTTD dla webshelli wgranych do wp-content.

Zdarzenia logowania. WordPress udostępnia akcję wp_login_failed, wywoływaną po nieudanym logowaniu, z nazwą użytkownika i obiektem błędu ^[6]. Zapis takich zdarzeń ze znacznikiem czasu pozwala później ustalić początek ataku.

add_action( 'wp_login_failed', function ( $username ) {
    error_log( gmdate( 'c' ) . ' login_failed ' . sanitize_user( $username ) );
} );

Dziennik aktywności. Wtyczki bezpieczeństwa i logi serwera trafiają do SIEM, gdzie reguły korelacji łączą je w alerty. Bez retencji logów nie da się jednak ustalić pierwszego znacznika czasu, więc MTTD staje się niemierzalne.

Ograniczenia miary

• Porównania między organizacjami. NIST zaznacza, że każda organizacja definiuje incydent po swojemu, więc proste liczby incydentów nie nadają się do porównań między organizacjami ^[1]. To samo dotyczy MTTD.
• Zbieranie danych dla danych. NIST zaleca zbieranie danych, na podstawie których można działać, a nie wszystkiego, co jest dostępne ^[1].
• Tylko wykryte incydenty. MTTD liczy się z incydentów, które ktoś zauważył. Włamanie niewykryte nie obniża średniej, choć jest najgorszym przypadkiem.
• Presja na szybkość. Agresywne reguły skracają MTTD, ale mnożą fałszywe alarmy (false positive) i prowadzą do zmęczenia alertami (alert fatigue).

Jak skracać

• Włączenie źródeł telemetrii, które widzą wczesne etapy ataku: logi serwera WWW, logowania, zmiany plików.
• Reguły wykrywania oparte na technikach napastników, na przykład z MITRE ATT&CK, a nie tylko na sygnaturach.
• Threat hunting (polowanie na zagrożenia), czyli aktywne szukanie śladów, których nie złapały reguły.
• Przegląd każdego incydentu w ramach post-incident review; NIST zaleca sprawdzić, które wskaźniki incydentu zostały zarejestrowane i czy szkoda powstała przed wykryciem ^[1].