Zespół bezpieczeństwa firmy produkcyjnej dostaje pytanie od zarządu po ćwiczeniu tabletop: „ile czasu zajmuje nam wykrycie włamania?”. Pada odpowiedź „średnio kilkadziesiąt minut” — wzięta z konsoli, w której faktycznie tyle upływa od zdarzenia do alertu. Trzy miesiące później, przy prawdziwej sprawie, analiza powłamaniowa pokazuje pierwsze logowanie skradzionym kontem jedenaście dni przed pierwszym alertem. Obie liczby są prawdziwe. Mierzą tylko dwie różne rzeczy.
MTTD (mean time to detect, średni czas wykrycia) skraca się nie przez szybsze narzędzie, tylko przez usunięcie miejsc, w których zegar stoi. Ten tekst nie jest przeglądem metryk operacji bezpieczeństwa — definicje, wzory i sposób raportowania opisaliśmy osobno w artykule o metrykach SOC: MTTD, MTTR i KPI bezpieczeństwa. Tutaj interesuje nas jedna rzecz: rozłożenie czasu wykrycia na odcinki i pokazanie, która dźwignia działa na który z nich.
Od którego momentu w ogóle biegnie zegar MTTD?
Od pierwszej aktywności napastnika, a nie od pierwszego alertu — i to jest najczęściej mylona granica w całym pomiarze. Konsola pokazuje odstęp między zarejestrowanym zdarzeniem a wygenerowanym alertem, bo tylko te dwa punkty w niej istnieją. Wszystko, co wydarzyło się przed pierwszym zarejestrowanym zdarzeniem, jest dla narzędzia niewidzialne i z definicji nie wchodzi do rachunku.
Sensowny podział trasy wygląda tak: (1) czas do pojawienia się sygnału w telemetrii, (2) czas do zamiany sygnału w alert, (3) czas do podjęcia alertu przez człowieka, (4) czas do decyzji, że to incydent i co z nim robimy. Suma tych czterech odcinków jest tym, co zarząd rozumie jako „czas wykrycia”. Konsola mierzy odcinek drugi.
NIST stawia ten problem wprost w rekomendacjach do obsługi incydentów. Dokument SP 800-61r3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management (kwiecień 2025) przy kategorii DE.AE zauważa, że „Signs of an incident may be more obvious later in the attack life cycle, but the incident’s impact and scope may be much larger” („oznaki incydentu mogą być bardziej oczywiste w późniejszej fazie cyklu życia ataku, ale wpływ i zasięg incydentu mogą być wtedy znacznie większe”) i zaleca, żeby organizacje dążyły do znajdowania incydentów wcześniej w tym cyklu.
Kluczowe rozróżnienie: „czas wykrycia” z konsoli to czas przetwarzania. „Czas wykrycia”, o który pyta zarząd, to czas ekspozycji. Dopóki obie liczby noszą tę samą nazwę, każda rozmowa o poprawie dotyczy innej wielkości u każdego rozmówcy.
Dlaczego szybszy silnik korelacji skraca najkrótszy odcinek trasy?
Bo pracuje wyłącznie na odcinku drugim, a ten jest w większości organizacji już najkrótszy. Korelacja zdarzenia w alert liczy się w sekundach i minutach — nawet przy obciążonym systemie mówimy o jednostkach minut. Odcinki pierwszy, trzeci i czwarty liczy się w godzinach, a przy brakującym źródle danych lub kolejce bez dyżuru w dobach.
Arytmetyka jest tu bezlitosna i warto ją zrobić przed rozmową z dostawcą. Jeśli trasa wygląda tak: cztery godziny do pojawienia się sygnału (log spływa wsadowo raz na kilka godzin), dwie minuty do alertu, czternaście godzin w kolejce do poniedziałku rano, trzy godziny do zgody na izolację — to skrócenie korelacji o połowę zmienia sumę o jedną minutę na ponad dwadzieścia godzin. Nowa licencja poprawia ten wynik o ułamek procenta.
To nie jest argument przeciwko narzędziom. To argument za mierzeniem odcinków osobno, zanim zapadnie decyzja zakupowa. Dopiero rozbita trasa pokazuje, gdzie realnie leży czas — i dopiero wtedy widać, że w części organizacji największym pojedynczym składnikiem jest oczekiwanie na człowieka, a nie przetwarzanie danych.
Ile do czasu wykrycia dokłada źródło logu, którego nie zbieramy?
Dokłada tyle, ile trwa dojście napastnika do systemu, który akurat logujemy — czyli wielkość nieograniczoną z góry. Brakujące źródło danych nie spowalnia wykrycia; ono je przenosi na inny, późniejszy moment cyklu ataku. Jeśli nie zbieramy zdarzeń uwierzytelnienia z konsoli chmurowej, przejęcie konta administracyjnego nie wygeneruje żadnego opóźnionego alertu — wygeneruje alert dopiero wtedy, gdy napastnik dotknie czegoś, co widzimy.
Zakres monitorowania, od którego to zależy, NIST wylicza konkretnie w kategorii DE.CM: sieci i usługi sieciowe (DE.CM-01), środowisko fizyczne (DE.CM-02), aktywność personelu i sposób korzystania z technologii (DE.CM-03), działania zewnętrznych dostawców usług (DE.CM-06) oraz sprzęt, oprogramowanie i środowiska uruchomieniowe wraz z danymi (DE.CM-09). Przy DE.CM-06 dokument wprost wymienia „remote and on-site administration and maintenance activities that providers perform on organizational systems” („zdalne i lokalne czynności administracyjne i konserwacyjne, które dostawcy wykonują na systemach organizacji”) — obszar, który w inwentarzu źródeł logów wypada najczęściej.
Drugą stroną tego samego równania jest retencja. CIS Critical Security Control 8 nosi tytuł Audit Log Management i streszcza się w jednym poleceniu: „Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack” („zbieraj, alertuj, przeglądaj i przechowuj logi zdarzeń, które mogą pomóc wykryć atak, zrozumieć go lub odtworzyć stan po nim”) — Center for Internet Security, opis kontroli 8. Ostatni czasownik decyduje o tym, czy wykrycie po dwóch tygodniach będzie się miało o co oprzeć. Log skasowany po siedmiu dniach nie wydłuża MTTD — on uniemożliwia jego policzenie wstecz.
Jak sprawdzić, czego Twoje detekcje nie widzą, zanim sprawdzi to napastnik?
Przez przyłożenie listy własnych detekcji do publicznego katalogu technik, zamiast pytania „czy mamy dobre reguły”. MITRE ATT&CK jest dziś takim katalogiem i — co ważne dla tego ćwiczenia — przebudował w ostatnim czasie właśnie warstwę wykrywania. Strona Data Sources nosi adnotację, że źródła danych zostały wycofane w wydaniu v18 z października 2025 roku i nie będą już rozwijane; ich rolę przejęły strategie detekcji i analityki.
Skala jest sprawdzalna w ciągu minuty. W katalogu ATT&CK widnieje 918 strategii detekcji (Detection Strategies) i 2066 analityk (Analytics) — liczby odczytane ze stron attack.mitre.org/detectionstrategies/ i attack.mitre.org/analytics/ 18 września 2026 roku. Analityka to konkretna logika detekcji dla danej platformy; strategia to pojemnik, który spina kilka analityk w jedną metodę wykrywania techniki.
Ćwiczenie do wykonania przez własny zespół wygląda tak: weź dziesięć technik najczęściej używanych w atakach na Twoją branżę, sprawdź w katalogu, jakich zdarzeń wymaga ich wykrycie, i skonfrontuj tę listę ze spisem źródeł, które faktycznie trafiają do systemu. Różnica jest mapą tego, czego nie wykryjesz w żadnym czasie — bo czas wykrycia czegoś, czego nie widać, nie jest długi. On nie istnieje.
Praktyczna fiszka: zanim zapytasz „jak szybko wykrywamy”, zapytaj „co w ogóle jesteśmy w stanie wykryć”. Pierwsze pytanie ma sens dopiero wtedy, gdy drugie ma odpowiedź w postaci listy, a nie deklaracji.
Dlaczego strojenie fałszywych alarmów skraca wykrycie, mimo że zmniejsza liczbę alertów?
Bo MTTD zależy od czasu dojścia do alertu prawdziwego, a nie od liczby alertów w kolejce. Reguła produkująca dziesiątki trafień dziennie, z których niemal wszystkie są nieszkodliwe, nie dokłada zdolności wykrywania — dokłada pracy, która odsuwa w czasie moment zajęcia się trafieniem istotnym. W kolejce obsługiwanej przez skończoną liczbę osób każdy fałszywy alarm jest opóźnieniem nałożonym na wszystkie pozostałe.
NIST opisuje ten mechanizm od strony projektowej. Przy kategorii DE.AE zaleca, żeby organizacje „rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis” („opierały się na rozwiązaniach technicznych filtrujących duże zbiory zdarzeń do podzbioru nadającego się do przeglądu i analizy przez człowieka”), a przy DE.CM — żeby stroić technologie monitorowania tak, by sprowadzić fałszywie dodatnie i fałszywie ujemne do akceptowalnego poziomu. Słowo „akceptowalnego” jest tu decyzją organizacji, nie ustawieniem producenta.
Strojenie ma jednak cenę, o której mówi się rzadziej: każde wyłączenie reguły przesuwa część ryzyka do kategorii „nie wykrywamy”. Dlatego dwie liczby trzeba prowadzić razem — udział trafień prawdziwych w alertach danej reguły oraz to, jaką technikę reguła miała pokrywać. Wyłączenie reguły bez zapisania drugiej z tych informacji poprawia MTTD i pogarsza bezpieczeństwo jednocześnie, a raport pokaże tylko pierwsze.
Co się dzieje z alertem, który trafia do kolejki w piątek po siedemnastej?
W organizacji bez dyżuru czeka do poniedziałku — i to czekanie wchodzi do MTTD w całości. To jest zwykle największy pojedynczy składnik czasu wykrycia w firmach, które mają wdrożony monitoring i nie mają obsady poza godzinami pracy. Alert powstał w minutę, a został podjęty po sześćdziesięciu godzinach.
Konsekwencja jest głębsza niż sam odstęp. Alert wygenerowany i nieprzekazany nikomu spełnia połowę wymogu i nie spełnia drugiej połowy: NIST przy DE.AE-06 żąda, żeby informacja o zdarzeniu trafiła do uprawnionych narzędzi i personelu, a wyniki analizy logów były dostępne dla osób obsługujących incydenty przez cały czas. Skrzynka zespołowa czytana w godzinach biurowych nie realizuje tego wymogu, mimo że w dokumentacji powdrożeniowej wygląda identycznie jak realizacja.
Ten sam wątek rozwijamy z innej strony w tekście o tym, dlaczego SIEM bez SOC nie działa — tam pytanie brzmi „czego narzędzie nie zrobi samo”, tutaj mierzymy, ile kosztuje w czasie każda z tych brakujących rzeczy. Jeśli rozważasz zamknięcie tej luki bez budowania własnego zespołu, porównanie dróg opisaliśmy w artykule o SOC jako usłudze dla firm średnich; samą usługę dyżuru i monitoringu prowadzimy w ramach SOC 24/7 nFlo.
Dlaczego kolejność obsługi alertów zmienia MTTD bardziej niż liczba analityków?
Bo przy skończonych zasobach o czasie dojścia do alertu istotnego decyduje reguła wyboru, a nie przepustowość. Dołożenie osoby do zespołu skraca kolejkę proporcjonalnie; zmiana kolejności obsługi potrafi przesunąć konkretny alert z końca kolejki na jej początek, czyli o cały jej czas przerobu.
NIST formułuje to jako zalecenie, nie jako sugestię: „Because of resource limitations, incidents should not be handled on a first-come, first-served basis” („ze względu na ograniczenia zasobów incydentów nie należy obsługiwać w kolejności zgłoszeń”). Ten sam fragment nazywa ocenę ryzyka i nadanie właściwego priorytetu „perhaps the most critical decision points in the incident response process” („być może najbardziej krytycznymi punktami decyzyjnymi w procesie obsługi incydentu”).
Wejścia do priorytetyzacji dokument wylicza przy RS.MA-03: zasięg zdarzenia, prawdopodobny wpływ, wrażliwość czasowa i dostępność zasobów. Trzy z tych czterech wielkości nie pochodzą z systemu bezpieczeństwa — pochodzą z rejestru usług, z mapy zależności biznesowych i z grafiku dyżurów. Brak któregokolwiek z tych rejestrów sprawia, że kolejka wraca do porządku zgłoszeń, niezależnie od tego, co mówi procedura.
Ile czasu zjada czekanie na decyzję, a nie sama analiza?
W organizacjach z rozbudowanym obiegiem zgód — więcej niż sama analiza, i jest to odcinek najtańszy do skrócenia. Analiza wymaga kompetencji i danych; zgoda wymaga wyłącznie tego, żeby ktoś odebrał telefon i miał prawo powiedzieć „tak”. Jeśli izolacja stacji roboczej wymaga akceptacji właściciela systemu, a właściciel jest jeden i pracuje w dzień, to nocna detekcja ma z góry ustalony czas domknięcia.
NIST rozróżnia tu dwie rzeczy, które w praktyce się zlewają. Przy RS.MA-04 opisuje eskalację jako zwiększenie zasobów lub ram czasowych, a podniesienie sprawy (elevation) jako włączenie wyższego szczebla zarządzania. Pierwsza operacja skraca czas, druga zwykle go wydłuża — i to jest powód, dla którego warto mieć zapisane, które decyzje wymagają tylko eskalacji.
Praktyczne domknięcie polega na wypisaniu działań odwracalnych — izolacja stacji, zablokowanie konta, odcięcie sesji — i nadaniu pierwszej linii uprawnienia do ich wykonania bez pytania. Ryzyko fałszywego odcięcia jest realne, ale mierzalne i odwracalne, a ryzyko czekania sześciu godzin na zgodę bywa jednorazowe i nieodwracalne. To jedyna zmiana z tej listy, która nie kosztuje ani licencji, ani etatu.
Jak zmierzyć własne MTTD, skoro nie znamy momentu zerowego?
Przez przyjęcie, że pomiar jest dwustopniowy, i przez jawne nazwanie, który stopień się raportuje. Stopień pierwszy to czas od pierwszego zdarzenia w telemetrii do potwierdzenia incydentu — liczba dostępna od razu, systematycznie zaniżona. Stopień drugi to czas od faktycznego początku aktywności napastnika, ustalony w analizie powłamaniowej — liczba prawdziwa, dostępna z opóźnieniem tygodni.
Jedno bez drugiego wprowadza w błąd w przewidywalny sposób. Raportowanie samego stopnia pierwszego daje wynik, który poprawia się po każdym wyłączeniu trudnej detekcji. Raportowanie samego stopnia drugiego daje liczbę, której nie da się użyć operacyjnie, bo spływa po zamknięciu sprawy. W nFlo prowadzimy u klienta oba: bieżący licznik z systemu jako sygnał operacyjny oraz przeliczenie wsteczne po każdej zamkniętej sprawie, z zapisaniem różnicy między nimi — bo to właśnie ta różnica pokazuje, ile czasu ataku spędza poza zasięgiem zbieranej telemetrii.
Trzy zasady liczenia, bez których metryka nie nadaje się do porównań w czasie: mediana zamiast średniej (jeden incydent znaleziony po miesiącach rozsadza średnią z kilkunastu spraw), rozbicie na klasy detekcji (alerty antywirusowe i wykrycia behawioralne to dwie różne populacje) oraz publikowanie liczby przypadków obok wyniku. Metryka bez licznika przypadków jest opinią zapisaną cyfrą. Szerszy zestaw mierników procesu obsługi incydentu opisaliśmy w tekście o zarządzaniu incydentami.
Które dźwignie skracania MTTD dają najwięcej i co każda z nich kosztuje?
Poniższa tabela porządkuje cztery odcinki trasy według tego, czym się je skraca i co trzeba mieć, żeby zmianę w ogóle zobaczyć w liczbach. Kolumna „dowód zmiany” jest tu najważniejsza: dźwignia, której skutku nie da się pokazać w pomiarze, nie nadaje się do uzasadnienia budżetu.
| Odcinek trasy | Dźwignia skracająca | Koszt wdrożenia | Dowód zmiany w pomiarze |
|---|---|---|---|
| Do pojawienia się sygnału | Domknięcie źródeł logów wg DE.CM-01…09, skrócenie interwału spływania danych, wydłużenie retencji | Licencje za wolumen, czas inżyniera integracji | Spis źródeł przed i po, zestawiony z listą technik z katalogu ATT&CK |
| Do zamiany sygnału w alert | Utrzymanie reguł, strojenie fałszywych alarmów, wycofanie reguł o najgorszym stosunku trafień | Stała pozycja w kalendarzu zespołu, bez zakupu | Udział trafień prawdziwych per reguła, liczony w oknach miesięcznych |
| Do podjęcia alertu przez człowieka | Dyżur poza godzinami pracy, imienny właściciel per kategoria alertu, ticket zakładany automatycznie | Obsada własna albo usługa zewnętrzna | Rozkład czasu oczekiwania w kolejce, osobno dla dnia i nocy |
| Do decyzji | Runbook z listą działań odwracalnych, uprawnienie pierwszej linii, rozdzielenie eskalacji od podniesienia sprawy | Decyzja organizacyjna, zero kosztu narzędziowego | Czas od podjęcia alertu do pierwszego działania powstrzymującego |
Warto zauważyć, w której kolumnie leżą zera. Dwa z czterech odcinków skraca się bez zakupu czegokolwiek — przez utrzymanie tego, co już działa, i przez rozdanie uprawnień. To zwykle są też te dwa, których nikt nie zgłasza jako projektu, bo nie mają dostawcy, który by je zaproponował.
Od czego zacząć, jeśli chcesz zobaczyć zmianę w ciągu kwartału?
Od pomiaru trasy, nie od zakupu dźwigni. Weź trzy ostatnie zamknięte sprawy — mogą być fałszywymi alarmami, byle przeszły całą ścieżkę — i rozpisz dla każdej cztery znaczniki czasu: pierwsze zdarzenie w telemetrii, powstanie alertu, podjęcie alertu przez człowieka, pierwsze działanie powstrzymujące. Trzy sprawy wystarczą, żeby zobaczyć, który odcinek dominuje; statystyki na tym etapie nie robimy.
Następnie zrób jedno ćwiczenie pokrycia: dziesięć technik istotnych dla Twojej branży, wymagane dla nich zdarzenia, konfrontacja ze spisem faktycznie zbieranych źródeł. To domyka pytanie „czego nie zobaczymy w żadnym czasie”, którego sam pomiar trasy nie zadaje.
Praktyczna fiszka na start: jeżeli po rozpisaniu trzech spraw okaże się, że odcinek trzeci — czekanie na człowieka — jest dłuższy niż suma pozostałych, to kolejny zakup narzędziowy nie zmieni Twojego MTTD. Zmieni go rozstrzygnięcie, kto odbiera alert o trzeciej w nocy i co wolno mu zrobić bez pytania.
Na końcu warto zapisać jedno ograniczenie tej metryki, żeby nie stała się celem samym w sobie. MTTD mierzy drogę tych zdarzeń, które wykryliśmy. O zdarzeniach niewykrytych nie mówi nic — i żadna jego wartość, nawet bardzo dobra, nie jest dowodem, że w środowisku nie dzieje się nic, czego nie widzimy. Dlatego raportuje się go zawsze w parze z pokryciem technik, a rozmowę o skracaniu zaczyna od pytania, co w ogóle trafia do telemetrii.
Najczęściej zadawane pytania
Od którego momentu biegnie czas wykrycia incydentu?
Formalnie od pierwszej aktywności napastnika w środowisku, a praktycznie od pierwszego zdarzenia, które zostało zarejestrowane w zbieranej telemetrii. Ta różnica jest całym problemem pomiaru MTTD: momentu zerowego nie znamy w chwili wykrycia, poznajemy go dopiero w analizie powłamaniowej. Dlatego wartość MTTD wyliczona na bieżąco jest zawsze zaniżona względem rzeczywistości i trzeba ją przeliczać wstecz po zamknięciu sprawy.
Co najbardziej wydłuża MTTD — narzędzia czy proces?
W typowym układzie proces, i to z prostego powodu arytmetycznego. Odcinek, na którym pracuje narzędzie — korelacja zdarzenia w alert — liczy się w sekundach i minutach. Odcinki procesowe: czekanie alertu w kolejce bez dyżuru, eskalacja do osoby z uprawnieniem, zgoda na działanie — liczą się w godzinach i dobach. Skrócenie o połowę odcinka mierzonego w minutach nie przesuwa sumy mierzonej w dobach.
Czy MTTD da się skrócić bez zwiększania budżetu na narzędzia?
Tak, i zwykle to właśnie tam leżą najtańsze zyski. Trzy zmiany nie wymagają nowej licencji: przypisanie imiennego właściciela do każdej kategorii alertu, wyłączenie reguł o najgorszym stosunku trafień do fałszywych alarmów oraz jawne nadanie pierwszej linii uprawnienia do działań odwracalnych, takich jak izolacja stacji. Każda z nich zdejmuje z trasy czekanie, a nie pracę.
Jak mierzyć MTTD, żeby liczba nie kłamała?
Mierz medianę zamiast średniej, licz osobno dla każdej klasy detekcji i publikuj liczbę przypadków, z których została policzona. Średnia z kilku zdarzeń przesuwa się o rzędy wielkości po jednym incydencie znalezionym po miesiącach, a MTTD liczone łącznie dla alertów antywirusowych i dla wykryć behawioralnych miesza dwie zupełnie różne populacje. Metryka bez licznika przypadków nie nadaje się do porównań w czasie.
Czy MTTD jest dobrą metryką do raportowania zarządowi?
Jest dobrą metryką kierunkową i złą metryką rozliczeniową. Pokazuje, czy organizacja skraca drogę od zdarzenia do decyzji, ale daje się poprawić w sposób pozorny — wystarczy wyłączyć detekcje o długim czasie potwierdzania albo przestać wykrywać trudne przypadki. Dlatego raportuje się ją zawsze razem z pokryciem technik i z liczbą wykryć, a nigdy jako pojedynczą liczbę.
