Pytanie „ile trwa wykrycie incydentu w firmie?” nie ma jednej odpowiedzi. W organizacji z działającym monitoringiem i całodobową analizą alertów może to być kilka minut. W firmie, która polega na tym, że „użytkownik da znać”, mogą to być tygodnie. Raporty branżowe publikowane co roku przez firmy zajmujące się reagowaniem na incydenty od dawna pokazują, że atakujący często działają w sieci ofiary przez dni, a nierzadko miesiące, zanim ktoś ich zauważy.
Ten czas ma swoją nazwę: MTTD. W tym artykule wyjaśniamy, od czego zależy i jak go skrócić.
Co to jest MTTD i dlaczego ma znaczenie
MTTD (Mean Time To Detect) to średni czas od rozpoczęcia incydentu do jego wykrycia. Uzupełnia go MTTR — czas od wykrycia do opanowania incydentu lub przywrócenia usług.
MTTD ma znaczenie z trzech powodów:
- Szkody rosną z czasem. Atakujący, który ma kilka dni, zdąży rozpoznać sieć, przejąć kolejne konta, wykraść dane i zaszyfrować kopie zapasowe.
- Terminy ustawowe biegną od wykrycia. Podmioty objęte UKSC mają 24 godziny na wczesne ostrzeżenie — ale dopiero od chwili, w której wiedzą o incydencie. Szczegóły opisujemy w artykule o zgłaszaniu incydentów w 24 i 72 godziny.
- Późne wykrycie komplikuje analizę. Logi mogą być już nadpisane, a ślady zatarte.
Dlaczego wykrycie trwa tak długo — typowe przyczyny
- Brak źródeł sygnałów. Stacje robocze mają tylko antywirus, serwery nie wysyłają logów, a logowania do Microsoft 365 nie są analizowane.
- Alerty bez odbiorcy. Narzędzie wykrywa podejrzane zdarzenie, ale powiadomienie trafia na skrzynkę, której nikt nie czyta wieczorem i w weekend.
- Szum. Setki alertów dziennie bez priorytetów powodują, że te naprawdę ważne giną w tłumie.
- Brak kontekstu. Pojedyncze zdarzenie — logowanie z nietypowego kraju, nowe zadanie harmonogramu na serwerze — wygląda niewinnie, dopóki nie zestawi się go z innymi.
- Brak procedury. Nikt nie wie, kto ma ocenić sygnał i kiedy uznać go za incydent.
Jak wykryć incydent bezpieczeństwa w firmie — źródła sygnałów
Skuteczne wykrywanie łączy kilka warstw:
| Źródło | Co pozwala wykryć | Przykład |
|---|---|---|
| EDR na komputerach i serwerach | Podejrzane zachowanie procesów, szyfrowanie plików, uruchamianie narzędzi atakujących | Program pakujący pliki i wysyłający je na nieznany serwer |
| Logi tożsamości (Active Directory, Entra ID) | Przejęte konta, nietypowe logowania, nadawanie uprawnień | Logowanie konta księgowej o 3:00 z innego kraju |
| Poczta i Microsoft 365 | Phishing, reguły przekierowania poczty, masowe udostępnianie plików | Nowa reguła przekazująca faktury na zewnętrzny adres |
| Firewall i VPN | Połączenia z adresami atakujących, skanowanie sieci, nietypowy ruch | Połączenia z serwera do usługi szyfrującej ruch w godzinach nocnych |
| Kopie zapasowe | Próby usunięcia lub zaszyfrowania kopii | Nagłe usunięcie punktów przywracania |
| Użytkownicy | Objawy, których narzędzia nie widzą | Pracownik zgłasza dziwny telefon „z działu IT” |
Sama liczba źródeł nie wystarczy. Zdarzenia trzeba zebrać w jednym miejscu i powiązać — tym zajmuje się SIEM — oraz ocenić przez człowieka, który wie, co jest normalne w danej organizacji.
Jak skrócić MTTD — 7 praktycznych kroków
- Zacznij od inwentaryzacji. Nie da się monitorować systemów, o których się nie wie. Spisz serwery, konta uprzywilejowane, usługi chmurowe i dostęp zdalny.
- Wdróż EDR na wszystkich stacjach i serwerach. Różnice między EDR a XDR opisujemy w artykule EDR a XDR — różnice i zastosowania.
- Zbieraj logi tożsamości i poczty. Większość ataków zaczyna się od przejętego konta — to tam pojawiają się pierwsze sygnały.
- Ustal, kto analizuje alerty poza godzinami pracy. Własny dyżur, zewnętrzny SOC albo usługa MDR — ważne, żeby ktoś faktycznie reagował.
- Zdefiniuj priorytety. Alert o szyfrowaniu plików na serwerze wymaga reakcji w minutach, a alert o nieudanym logowaniu — przeglądu w ciągu dnia.
- Ćwicz. Symulowany incydent pokazuje, ile czasu mija między sygnałem a decyzją — i gdzie proces się zacina.
- Mierz. Zapisuj moment rozpoczęcia i wykrycia każdego incydentu. Bez danych nie da się ocenić, czy MTTD się poprawia.
Przykład: ten sam atak, dwa różne MTTD
Firma A ma antywirus i serwer plików. W piątek wieczorem atakujący loguje się przez VPN przejętym hasłem. W sobotę uruchamia narzędzia do rozpoznania sieci, w niedzielę szyfruje dane. Incydent zostaje wykryty w poniedziałek rano, gdy pracownicy nie mogą otworzyć plików.
Firma B ma EDR, zbiera logi VPN i Microsoft 365, a alerty analizuje zewnętrzny zespół przez całą dobę. Logowanie przez VPN z nietypowej lokalizacji, a chwilę później uruchomienie narzędzia skanującego sieć tworzą razem alert o wysokim priorytecie. Analityk blokuje konto i izoluje komputer w piątek wieczorem — zanim dojdzie do szyfrowania.
Różnica nie wynika z lepszego antywirusa, tylko z tego, czy ktoś łączy sygnały i reaguje w nocy. Koszty takiej różnicy opisujemy w artykule Ile kosztuje firmę zbyt późne wykrycie incydentu.
Od czego zacząć
Jeśli nie wiesz, jaki jest dziś czas wykrycia w Twojej organizacji, zacznij od oceny obecnych zabezpieczeń i źródeł logów — to element audytu cyberbezpieczeństwa. Jeśli brakuje Ci osób do analizy alertów, sprawdź, jak działa monitoring bezpieczeństwa i SOC.