Wdrażając wymogi dyrektywy NIS2 oraz znowelizowanej ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), firmy B2B skupiają się najczęściej na prewencji. Jednak z punktu widzenia prawnego i operacyjnego, kluczowym elementem dojrzałości cybernetycznej jest to, co dzieje się po przełamaniu zabezpieczeń. Zdolność do odpowiedniego zabezpieczenia dowodów cyfrowych oraz prawidłowa retencja logów to fundament, który pozwala na skuteczną współpracę z krajowymi zespołami CSIRT, przeprowadzenie analizy root-cause oraz uniknięcie bolesnych sankcji za brak rozliczalności.
Dlaczego informatyka śledcza to wymóg prawny, a nie opcja?
Nowe przepisy wymagają od podmiotów kluczowych i ważnych wdrożenia środków zarządzania ryzykiem, które obejmują m.in. obsługę incydentów. W świetle standardów branżowych, prawidłowa obsługa incydentu nie kończy się na przywróceniu systemów z kopii zapasowej. Zgodnie z duchem KSC, organizacja musi być w stanie udowodnić, w jaki sposób doszło do naruszenia, jakie dane zostały skompromitowane oraz jakie kroki zaradcze podjęto.
Brak logów systemowych lub zniszczenie artefaktów powłamaniowych w trakcie pospiesznego przywracania usług (tzw. zacieranie śladów) może zostać zinterpretowane przez organ nadzorczy jako rażące zaniedbanie. Jeśli firma nie potrafi wskazać wektora ataku, organ kontrolny może uznać, że wdrożone środki techniczne były nieadekwatne do skali ryzyka, co otwiera drogę do nałożenia kar finansowych przewidzianych w ustawie o KSC.
Złota zasada "First Respondera" – czego unikać po wykryciu ataku?
Najczęstszym błędem popełnianym przez wewnętrzne działy IT w firmach B2B jest instynktowna chęć natychmiastowego zrestartowania zainfekowanego serwera lub wyłączenia zasilania w przypadku wykrycia np. ataku ransomware. Z perspektywy informatyki śledczej (Digital Forensics) jest to działanie destrukcyjne.
Działania typu "First Response" w reżimie KSC powinny opierać się na następujących zasadach:
- Nie restartuj maszyn: Restart powoduje bezpowrotną utratę danych z pamięci operacyjnej (RAM), w której przechowywane są klucze szyfrujące, aktywne procesy złośliwego oprogramowania oraz otwarte połączenia sieciowe atakującego.
- Izoluj na poziomie sieci, nie zasilania: Zainfekowany host powinien zostać odcięty od sieci firmowej i internetu (np. poprzez reguły na switchu, odpięcie kabla LAN lub izolację z poziomu konsoli systemu EDR), ale pozostawiony włączony w celu umożliwienia zrzutu pamięci RAM.
- Dokumentuj każde działanie: Każdy krok wykonany przez administratora po wykryciu ataku musi być zapisany. Zmiany stanu systemu wprowadzone przez zespół IT mogą zostać później błędnie przypisane atakującym.
Retencja logów a KSC – jak długo przechowywać dane?
Aby móc przeprowadzić dochodzenie po incydencie i spełnić obowiązek współpracy z odpowiednim CSIRT poziomu krajowego (np. CSIRT NASK, CSIRT GOV), organizacja musi dysponować historycznymi logami zdarzeń. W tym miejscu często dochodzi do konfliktu między działami bezpieczeństwa a inspektorami ochrony danych (IOD), którzy naciskają na jak najkrótsze przechowywanie danych (zasada minimalizacji z RODO).
Należy jednak pamiętać, że ustawa o KSC oraz względy bezpieczeństwa IT stanowią silną podstawę prawną (prawnie uzasadniony interes administratora / realizacja obowiązku prawnego) do wydłużonej retencji. Średni czas przebywania atakującego w sieci (tzw. Dwell Time) przed ujawnieniem swojej obecności wynosi obecnie od kilku tygodni do nawet kilku miesięcy. Dlatego zaleca się, aby kluczowe logi były przechowywane znacznie dłużej.
Jakie logi są absolutnie krytyczne?
- Logi uwierzytelniania: Active Directory, Azure AD, logowania do VPN, systemy MFA. Należy przechowywać historię udanych i nieudanych prób logowania przez minimum 6 do 12 miesięcy.
- Telemetria z punktów końcowych (EDR/XDR): Zdarzenia tworzenia procesów, modyfikacji rejestru i komunikacji sieciowej na hostach. Ze względu na ogromny wolumen danych, retencja rzędu 30-90 dni w formie "gorącej" jest powszechnie akceptowalnym standardem.
- Logi z urządzeń brzegowych i sieciowych: Firewalle, systemy IDS/IPS, serwery proxy, logi zapytań DNS. Są kluczowe do identyfikacji komunikacji ze wskaźnikami kompromitacji (IoC) i infrastrukturą Command & Control (C2) atakujących.
Ochrona logów przed zniszczeniem (WORM) i centralizacja
Jednym z pierwszych działań zaawansowanych grup przestępczych po zdobyciu uprawnień administratora jest wyczyszczenie lokalnych dzienników zdarzeń (np. Windows Event Logs) w celu zatarcia śladów. Zgodność z KSC wymaga, aby systemy logowania były odporne na takie manipulacje.
Firmy B2B muszą wdrażać scentralizowane systemy zarządzania logami (np. SIEM, dedykowane serwery Syslog). Co więcej, kopie kluczowych logów powinny być przesyłane do repozytorium w modelu WORM (Write Once, Read Many) lub na zasoby o ściśle odseparowanych uprawnieniach, do których nawet administrator domeny nie ma prawa modyfikacji (tzw. append-only). Tylko tak zabezpieczone dowody mają wartość analityczną i prawną dla zespołów reagowania.
Łańcuch dowodowy (Chain of Custody) we współpracy z CSIRT
Jeśli incydent zostanie zakwalifikowany jako poważny, podmiot KSC jest zobowiązany do współpracy z właściwym CSIRT. W praktyce może to oznaczać konieczność przekazania zrzutów dysków, próbek złośliwego oprogramowania lub wyekstrahowanych logów. Przekazanie to nie może odbywać się w sposób chaotyczny.
Profesjonalne zabezpieczenie dowodów wymaga zachowania łańcucha dowodowego (Chain of Custody). Oznacza to, że każdy zrzut dysku (np. wykonany w formacie E01 lub RAW) lub zrzut pamięci musi posiadać wyliczoną sumę kontrolną (kryptograficzny hash, np. SHA-256). Kopia posektorowa dysku z wyliczonym hashem daje gwarancję, że przekazany materiał dowodowy nie został zmodyfikowany od momentu jego skopiowania. Dokumentacja przekazania powinna zawierać informacje o tym, kto zebrał dane, kiedy, w jaki sposób i komu zostały one udostępnione.
Najważniejsze wnioski
- Informatyka śledcza to część compliance: Prawidłowa obsługa incydentów i analiza root-cause, wymagane przez ustawę o KSC, są niemożliwe bez odpowiednio zabezpieczonych dowodów cyfrowych.
- Brak restartów przy incydentach: W przypadku ataku powstrzymaj zespół przed restartem systemów; izoluj urządzenia na poziomie sieciowym, by nie zniszczyć cennych danych w pamięci RAM.
- Retencja musi uwzględniać Dwell Time: Krótki czas przechowywania logów (np. 14 dni) jest niewystarczający w zderzeniu z rzeczywistością dzisiejszych ataków APT. Rekomendowana retencja kluczowych logów to 6-12 miesięcy.
- Centralizacja i niezmienność danych (WORM): Logi muszą być wysyłane w czasie rzeczywistym do centralnego repozytorium odpornego na modyfikacje i kasowanie nawet przez uprzywilejowanych użytkowników.
- Zadbaj o sumy kontrolne: Przekazując artefakty złośliwego oprogramowania i zrzuty dysków do organów państwowych (np. CSIRT NASK), zawsze dokumentuj ich kryptograficzne sumy kontrolne (SHA-256), aby zachować ciągłość dowodową.
Treść ma charakter informacyjny i edukacyjny — nie stanowi porady prawnej. Przy wyniku granicznym skonsultuj się z radcą prawnym lub adwokatem.