Firma produkcyjna spod Poznania dowiedziała się o ataku ransomware, gdy księgowa zadzwoniła, że nie może zalogować się do systemu ERP. Było wtorkowe popołudnie. Administrator sprawdził serwer plików, zobaczył zaszyfrowane katalogi i przez kolejne trzy godziny próbował ustalić, co się właściwie stało, kiedy zaczęło się szyfrowanie i które systemy są jeszcze bezpieczne. Dopiero wieczorem ktoś przypomniał sobie, że NIS2 i ustawa o KSC każą zgłosić poważny incydent w ciągu 24 godzin. Problem w tym, że nikt nie wiedział, co dokładnie zgłosić, bo logów sprzed ataku po prostu nie było.
To najczęstszy scenariusz, jaki widzimy u klientów, którzy dopiero zaczynają układać sobie zgodność z NIS2. Termin 24 godzin na wczesne ostrzeżenie i 72 godzin na pełniejsze zgłoszenie brzmi jak biurokratyczna formalność, dopóki nie trzeba go dotrzymać bez przygotowania. Wtedy okazuje się, że to wyścig z czasem, który firma przegrywa, zanim w ogóle wystartuje.
Co trzeba zdążyć w 24 i 72 godziny
Nie chodzi o to, żeby po ataku napisać elaborat prawniczy. Wczesne ostrzeżenie w ciągu 24 godzin to w praktyce krótka informacja: co się stało, czy podejrzewasz działanie transgraniczne lub przestępcze, jak poważny jest incydent. Zgłoszenie w ciągu 72 godzin to już bardziej szczegółowy opis: wstępna ocena skutków, wektor ataku, jeśli go znasz, wskaźniki naruszenia. Potem, w zależności od przebiegu, dochodzi raport końcowy. Dokładne wymogi opisaliśmy w artykule o tym, jak polska ustawa o KSC przekłada unijną dyrektywę na krajowe przepisy, więc tutaj nie będziemy powtarzać paragrafów. Interesuje nas co innego: jak sprawić, żeby te terminy dało się w ogóle dotrzymać.
Dlaczego te terminy są nierealne bez wcześniejszego przygotowania
Zegar w NIS2 nie startuje od momentu ataku. Startuje od momentu, w którym firma dowiaduje się, że doszło do poważnego incydentu. I to jest właśnie miejsce, w którym większość małych firm traci najwięcej czasu, zanim jeszcze zacznie działać zegar formalny.
Bez monitoringu firma dowiaduje się o incydencie od klienta, który nie może się zalogować, od pracownika, który zauważył dziwny e-mail wysłany z jego skrzynki, albo od banku, który zablokował podejrzany przelew. To zwykle kilka dni, czasem tygodni, po faktycznym włamaniu. W tym czasie atakujący ma pełną swobodę, a firma nie ma żadnych danych, na podstawie których mogłaby opisać, co się stało. Nie da się zgłosić incydentu w 24 godziny, jeśli dowiadujesz się o nim z trzytygodniowym opóźnieniem, a logów, które pokazałyby początek ataku, po prostu nie zapisano.
Drugi problem to brak danych do opisu, nawet gdy incydent zostanie wykryty na czas. Zgłoszenie wymaga konkretów: który system, jaki zakres, jakie wskaźniki. Jeśli jedynym śladem jest zrzut ekranu z komunikatem okupu, a serwery nie logowały nic poza podstawowym dziennikiem systemowym Windows, zespół spędza 72 godziny na odtwarzaniu przebiegu zdarzeń zamiast na pisaniu zgłoszenia.
Jak ułożyć ścieżkę: zdarzenie, wykrycie, decyzja, zgłoszenie
Cały sens dobrze ustawionego monitoringu polega na tym, żeby skrócić odstęp między zdarzeniem a wykryciem z dni do minut, a potem dać zespołowi gotowe dane, zamiast każąc mu je rekonstruować pod presją czasu. W praktyce oznacza to cztery ogniwa, które muszą działać jedno po drugim bez przestojów.
- Zdarzenie: coś dzieje się w infrastrukturze – nietypowe logowanie, masowa zmiana rozszerzeń plików, ruch do nieznanego adresu IP, nowy proces uruchomiony z lokalizacji tymczasowej.
- Wykrycie: system monitoringu (u nas najczęściej Wazuh) zbiera logi z serwerów, stacji roboczych i urządzeń sieciowych w czasie rzeczywistym, koreluje je z regułami i generuje alert, zanim ktokolwiek zauważy problem gołym okiem.
- Decyzja: ktoś konkretny, z imienia i nazwiska, ocenia alert i stwierdza, czy to poważny incydent w rozumieniu NIS2, czy fałszywy alarm albo drobna usterka.
- Zgłoszenie: osoba decyzyjna albo wyznaczony kontakt wysyła wczesne ostrzeżenie do właściwego CSIRT, korzystając z gotowego szablonu i danych, które monitoring już zebrał.
Jeśli któreś z tych ogniw nie jest ustawione zawczasu, cały łańcuch się zatrzymuje. Najczęściej pęka na wykryciu (bo nikt nie zbiera logów) albo na decyzji (bo nikt nie wie, kto ma prawo powiedzieć „to jest poważny incydent, zgłaszamy”). Więcej o tym, jak zbudować tę ścieżkę krok po kroku i dopasować ją do realiów małej firmy, opisaliśmy w tekście o tym, jak wyglądają procedury obsługi incydentów bez korporacyjnego budżetu.
Co musi być gotowe, zanim coś się wydarzy
Poniższa lista to minimum, które sprawdzamy u klientów przed pierwszym „na sucho” przetestowaniem procedury. Bez tego nawet najlepszy monitoring nie pomoże, bo dane będą, ale nikt nie będzie wiedział, co z nimi zrobić.
- ✅ Kontakt do właściwego CSIRT: zapisany numer, adres e-mail i link do formularza zgłoszeniowego, dostępny nie tylko w głowie administratora, ale w dokumencie, do którego dotrze każdy z zespołu.
- ✅ Szablon zgłoszenia: gotowy dokument z polami do wypełnienia (rodzaj incydentu, dotknięte systemy, wstępna ocena skutków, wskaźniki naruszenia), żeby nie zastanawiać się nad formą w środku kryzysu.
- ✅ Jasno wskazana osoba decyzyjna: kto ocenia powagę incydentu i kto ma uprawnienia, żeby wysłać zgłoszenie, także w weekend albo na urlopie kogoś z zespołu.
- ✅ Dane z Wazuh pod ręką: dashboard albo wyeksportowany raport z logami z ostatnich godzin, gotowy do wklejenia do zgłoszenia bez czekania, aż ktoś odtworzy historię ręcznie.
- 🚩 Brak ustalonego zastępstwa: jeśli jedyna osoba znająca procedurę akurat nie odbiera telefonu, cała ścieżka się zawiesza.
Warto też sprawdzić, jakie dokładnie dane firma ma obowiązek zebrać na potrzeby zgłoszenia, bo zakres różni się w zależności od sektora i wielkości firmy. Zebraliśmy to w formie do odhaczenia w osobnym artykule, gdzie znajdziesz checklistę NIS2 z podziałem na to, co da się zrobić samemu, a co lepiej zlecić.
Dlaczego próba jest ważniejsza niż procedura na papierze
Procedura, która istnieje tylko jako dokument w folderze, zawodzi przy pierwszym prawdziwym incydencie. Sprawdza się to regularnie: zespół wie w teorii, co robić, ale gdy przychodzi realny alert, traci pół dnia na ustalanie, kto ma dostęp do konsoli Wazuh, gdzie jest numer do CSIRT i kto w ogóle podejmuje decyzję o zgłoszeniu.
Dlatego warto raz na kwartał albo pół roku zrobić symulację: wygenerować testowy alert, uruchomić całą ścieżkę od wykrycia po wysłanie (niewysłanego naprawdę) zgłoszenia i zmierzyć czas. Taka próba pokazuje słabe ogniwa, zanim zrobi to prawdziwy atak. Zwykle po pierwszym ćwiczeniu okazuje się, że coś jest nieaktualne: kontakt do CSIRT się zmienił, osoba decyzyjna odeszła z firmy, dashboard w Wazuh nie pokazuje danych, których faktycznie potrzeba do zgłoszenia. Lepiej odkryć to na sucho niż w środku realnego incydentu, z zegarem tykającym w tle.
Co dalej w cyklu
W kolejnym wpisie pokażemy, jak wygląda to od strony technicznej: gdzie i jak postawić Wazuh na Proxmoxie, żeby monitoring, o którym tu piszemy, faktycznie zbierał dane z serwerów i stacji roboczych w małej firmie, bez przepłacania za infrastrukturę, której nikt nie wykorzysta.
W Zjawa.IT stawiamy monitoring incydentów pod klucz: od instalacji Wazuh, przez skonfigurowanie alertów pod realne zagrożenia, po przygotowanie procedury zgłoszeniowej razem z Twoim zespołem i pierwszą próbą na sucho. Napisz do nas.