Raportowanie incydentu w reżimie 24h i 72h do CSIRT NASK – runbooki, telemetria i rola dyżuru 24/7/365

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (uKSC) oraz dyrektywa NIS2 odbierają działom IT komfort wielodniowego, cichego diagnozowania awarii za zamkniętymi drzwiami serwerowni. Podmiot kluczowy lub ważny ma maksymalnie 24 godziny od momentu powzięcia wiedzy o incydencie poważnym na wysłanie wczesnego ostrzeżenia do właściwego zespołu CSIRT (najczęściej CSIRT NASK) przez rządowy system S46, a następnie 72 godziny na pełne zgłoszenie techniczne. Dotrzymanie tych okien czasowych przy ataku w nocy z piątku na sobotę nie zależy od sprawności prawników – wymaga scentralizowanego repozytorium logów (WORM), zsynchronizowanego czasu NTP, gotowych runbooków inżynierskich oraz dyżuru 24/7/365, który odróżni zwykłą usterkę od włamania i zabezpieczy dowody w pamięci RAM przed restartem maszyn.

Zegar uKSC tyka od pierwszej minuty – co w praktyce oznacza reżim 24h?

Koniec z „cichym łataniem” awarii w weekend

Przez lata w polskich firmach technologicznych, produkcyjnych i e‑commerce obowiązywał niepisany protokół kryzysowy. Gdy w sobotę nad ranem padała baza danych albo na serwerach pojawiały się podejrzane procesy, administratorzy zamykali się na kanale komunikatora, po cichu odtwarzali środowisko z kopii zapasowych i łatali dziurę w zaporze sieciowej.

Dopiero w poniedziałek po południu, gdy produkcja znów działała stabilnie, zarząd wspólnie z prawnikami zastanawiał się, czy o zdarzeniu trzeba kogokolwiek informować.

W reżimie znowelizowanej ustawy o KSC taki model działania jest najkrótszą drogą do katastrofy regulacyjnej i wizerunkowej.

Ustawodawca zaprojektował trzystopniowy mechanizm raportowania (24h / 72h / 30 dni) z zupełnie innego powodu niż chęć karania firm za sam fakt padnięcia ofiarą cyberprzestępców. Zespoły poziomu krajowego – CSIRT NASK, CSIRT GOV oraz CSIRT MON – pełnią funkcję centralnego układu nerwowego gospodarki. Kiedy zgłaszasz im wczesne ostrzeżenie w pierwszej dobie ataku, analitycy państwowi otrzymują wzorce ruchu i adresację serwerów sterujących (C2), dzięki czemu mogą natychmiast ostrzec inne firmy z Twojego sektora, zanim ta sama kampania ransomware sparaliżuje kolejnych dostawców.

Właśnie dlatego prawo traktuje terminowe zgłoszenie jako parasol ochronny dla zarządu i zespołu IT:

• Sam fakt włamania nie oznacza automatycznej kary – jeżeli organizacja posiada udokumentowane zabezpieczenia i współpracuje z CSIRT w ustawowych oknach czasowych, występuje w roli poszkodowanego, który otrzymuje wsparcie analityczne państwa.
• Zatajenie incydentu zmienia kwalifikację czynu – ukrycie ataku, o którym CSIRT NASK dowie się z zewnątrz (np. ze zgłoszenia Twojego klienta B2B, z monitoringu wycieków w darknecie albo od bliźniaczego zespołu CSIRT z innego kraju UE w ramach sieci CSIRTs Network), natychmiast uruchamia kontrolę doraźną z urzędu.
• Brak wpisu w S46 blokuje ścieżkę zgłoszeniową – jeśli podczas próby wysłania raportu okaże się, że spółka zignorowała obowiązki rejestrowe, zarząd naraża się na surowe sankcje finansowe i osobiste, które szczegółowo rozpisaliśmy w naszym przewodniku omawiającym kwalifikację podmiotu w uKSC i rejestrację w systemie S46.

Wniosek dla dyrektorów IT jest prosty. Dziś nie ukryjesz poważnego przestoju ani wycieku danych w powiązanym łańcuchu dostaw, bo Twoje API, certyfikaty i dostępność usług są nieustannie monitorowane przez systemy zewnętrznych kontrahentów.

Moment zero – od kiedy dokładnie bije licznik 24 godzin?

Jedno z najczęstszych pytań, jakie słyszymy od architektów i szefów infrastruktury podczas audytów gotowości, brzmi następująco – czy zegar 24 godzin rusza w sekundzie, w której napastnik wysłał pierwszy złośliwy pakiet do naszej sieci, czy dopiero wtedy, gdy człowiek odczyta alert?

Przepisy uKSC oraz dyrektywy NIS2 posługują się precyzyjnym terminem – czas liczy się od momentu powzięcia wiedzy o wystąpieniu incydentu poważnego (awareness of the significant incident).

Z perspektywy inżynierii systemowej musimy tu wyraźnie oddzielić trzy stany operacyjne:

1. Surowa anomalia telemetryczna (zegar jeszcze nie bije) – system monitoringu (np. Prometheus, Zabbix lub Datadog) rejestruje nagły skok utylizacji procesora do 98%, wzrost opóźnień I/O na macierzy dyskowej albo serię błędów 502 Bad Gateway na brzegu sieci. Na tym etapie nie wiesz jeszcze, czy przyczyną jest zapętlone zapytanie SQL po piątkowym wdrożeniu, awaria kości pamięci RAM, czy atak szyfrujący.
2. Wstępna weryfikacja techniczna, czyli triage (moment zero – start zegara 24h) – inżynier dyżurny loguje się do środowiska, koreluje metryki z logami systemowymi i potwierdza, że niedostępność usługi przekroczyła progi akceptowalne, albo odkrywa ślady nieautoryzowanego dostępu (np. podejrzane wywołania powłoki, zmodyfikowane klucze SSH czy ruch wychodzący do nieznanych adresów IP). W tej dokładnie minucie organizacja „powzięła wiedzę” o incydencie poważnym i rusza odliczanie 24 godzin na wysłanie wczesnego ostrzeżenia.
3. Pełna analiza powłamaniowa (trwa równolegle po zgłoszeniu) – dokładne ustalenie, jak intruz wszedł do sieci, jakie konta przejął i ile dokładnie rekordów wykradł, zajmuje często kilkanaście lub kilkadziesiąt godzin. Ustawa nie wymaga posiadania tych wszystkich odpowiedzi w pierwszej dobie – na ich zebranie masz kolejne etapy (72 godziny oraz 30 dni).

Pułapka nieodebranych alertów – wielu zarządom wydaje się, że skoro zegar startuje dopiero od momentu „powzięcia wiedzy”, to wyłączenie powiadomień na weekend i odczytanie czerwonych alertów dopiero w poniedziałek o 8.00 rano legalnie przesunie start okna 24‑godzinnego. To niebezpieczna iluzja. Podczas analizy powypadkowej audytor porówna znaczniki czasu (timestamps) z logów zapory sieciowej i systemu SIEM z godziną pierwszej reakcji administratora. Jeżeli systemy bezpieczeństwa wygenerowały krytyczny alarm o włamaniu w piątek o 23.15, a przez 56 godzin nikt na niego nie spojrzał z braku dyżuru, organ nadzorczy zakwalifikuje to jako rażące naruszenie wymogu ciągłego monitorowania zagrożeń.

Kiedy zdarzenie staje się incydentem poważnym? Twarde progi kwalifikacji

Nie każda usterka w serwerowni wymaga budzenia prezesa zarządu i wysyłania pilnego formularza w systemie S46. Gdyby zespoły DevOps i administratorzy zgłaszali do CSIRT NASK każdy zrestartowany kontener w Kubernetesie czy chwilowe wysycenie puli połączeń do bazy danych, państwowy system uległby paraliżowi w ciągu jednego przedpołudnia.

Ustawa nakłada obowiązek raportowania w reżimie 24h i 72h wyłącznie wtedy, gdy zdarzenie przekroczy próg incydentu poważnego.

Zwykła awaria sprzętowa a incydent w rozumieniu uKSC

W codziennej praktyce inżynierskiej łatwo pomylić pojęcie „cyberataku” z pojęciem „incydentu”. W świetle przepisów uKSC oraz dyrektywy NIS2 incydentem jest każde zdarzenie, które ma niekorzystny wpływ na bezpieczeństwo sieci i systemów informacyjnych – czyli na ich dostępność, autentyczność, integralność lub poufność.

Oznacza to bardzo ważną rzecz dla architektów infrastruktury.

Jeżeli w Twojej serwerowni przepali się pojedynczy zasilacz redundantny (PSU) albo wypadnie jeden dysk NVMe w macierzy RAID 10, a klaster automatycznie przejmie ruch bez żadnej degradacji usługi dla klientów – to zwykłe zdarzenie eksploatacyjne, które zamykasz wewnętrznym biletem serwisowym.

Sytuacja zmienia się diametralnie w dwóch przypadkach:

• Awaria fizyczna lub błąd ludzki kładzie produkcję – jeżeli błędna aktualizacja tablicy routingu BGP, awaria chłodzenia w serwerowni albo przypadkowe usunięcie wolumenu przez administratora spowoduje długotrwałą niedostępność usługi kluczowej bądź ważnej, zdarzenie to staje się incydentem poważnym (mimo że nie stał za nim żaden haker).
• Wystąpiło działanie bezprawne lub złośliwe – każdy udany włam do infrastruktury, uruchomienie złośliwego kodu, przejęcie uprawnień administracyjnych (IAM / Active Directory), skuteczny atak DDoS wycinający ruch produkcyjny czy wykorzystanie podatności zero‑day w aplikacji z miejsca kwalifikuje zdarzenie do przyspieszonej ścieżki zgłoszeniowej.

Trzy metryki istotności, które musisz mierzyć w infrastrukturze

Aby zespół dyżurny nie musiał w środku nocy zgadywać, czy dana sytuacja wymaga uruchomienia procedury S46, organizacja musi przełożyć przepisy na mierzalne parametry techniczne. Ustawodawca definiuje incydent poważny poprzez dwa główne filtry – dotkliwość zakłócenia operacyjnego oraz skalę strat po stronie odbiorców.

W praktyce monitoringu serwerów sprowadza się to do trzech twardych wskaźników:

1. Czas przestoju i utrata ciągłości działania (metryki SLA) – incydent staje się poważny, gdy powoduje (lub może spowodować) dotkliwe zakłócenie funkcjonowania usług kluczowych bądź ważnych. Jeśli Twój system ERP, platforma handlowa B2B, węzeł logistyczny albo chmura obliczeniowa przestaje odpowiadać powyżej zdefiniowanego progu tolerancji, a przełączenie na środowisko zapasowe zawodzi, przekraczasz próg ustawowy.
2. Naruszenie integralności, autentyczności lub poufności danych – nawet jeśli serwery odpowiadają w czasie poniżej 50 milisekund i żaden klient nie widzi błędu na ekranie, włamanie, w którym intruz uzyskał nieautoryzowany dostęp do bazy danych, podmienił paczki w pipeline CI/CD lub wykradł klucze prywatne i tajemnice aplikacyjne, automatycznie otwiera obowiązek raportowania.
3. Efekt domina i wpływ na inne podmioty (w tym transgraniczny) – zdarzenie kwalifikuje się jako poważne zawsze wtedy, gdy wywołuje (lub jest w stanie wywołać) znaczne szkody majątkowe lub niemajątkowe u innych osób fizycznych bądź prawnych. Dotyczy to w szczególności dostawców IT, chmury i usług zarządzanych (MSP), których awaria rykoszetem zatrzymuje procesy biznesowe u dziesiątek klientów w Polsce lub w innych krajach Unii Europejskiej.

Porównanie kategorii zdarzeń – od anomalii do incydentu poważnego

Dla ułatwienia pracy inżynierów dyżurnych oraz osób kontaktowych wyznaczonych w systemie S46 zebraliśmy różnice między poszczególnymi kategoriami zdarzeń w praktycznym zestawieniu operacyjnym.

Trzystopniowa procedura raportowania – 24h, 72h i 30 dni krok po kroku

Największym paraliżem podczas realnego incydentu jest przekonanie zarządu oraz inżynierów, że już w pierwszym zgłoszeniu trzeba przedstawić państwu kompletny raport ze śledztwa. Zespół techniczny odkłada więc otwarcie formularza w systemie S46 z godziny na godzinę, bo „wciąż analizujemy logi i nie wiemy dokładnie, przez którą lukę weszli atakujący”.

Takie podejście mija się z konstrukcją ustawy.

Ustawodawca doskonale zdaje sobie sprawę, że w pierwszych godzinach po wykryciu włamania lub ataku szyfrującego w serwerowni trwa walka o utrzymanie procesów biznesowych. Dlatego procedura w systemie S46 została rozbita na trzy niezależne etapy, w których stopień szczegółowości rośnie wraz z postępem prac inżynierskich.

Faza 1 (do 24 godzin) – wczesne ostrzeżenie (early warning)

Pierwszy komunikat wysyłany do właściwego zespołu CSIRT (CSIRT NASK, CSIRT GOV lub CSIRT MON) nie jest elaboratem powłamaniowym, lecz szybkim sygnałem alarmowym. Musisz go przesłać niezwłocznie, nie później niż w ciągu 24 godzin od momentu powzięcia wiedzy o wystąpieniu incydentu poważnego.

Na tym etapie formularz w systemie S46 wymaga od Ciebie odpowiedzi przede wszystkim na dwa kluczowe pytania:

• Czy istnieje podejrzenie, że incydent został wywołany działaniem bezprawnym lub złośliwym? (np. ślady przełamania uwierzytelniania, złośliwy skrypt w kontenerze, wolumetryczny atak DDoS zamiast zwykłej awarii routera).
• Czy incydent wywołuje lub może wywołać wpływ transgraniczny? (czyli czy niedostępność Twojej usługi uderza w podmioty w innych państwach Unii Europejskiej bądź czy atak rozprzestrzenia się przez infrastrukturę międzynarodową).

Zasada inżynierska w pierwszej dobie brzmi jednoznacznie – nie czekaj na stuprocentową pewność i zakończenie analizy dysków.

Wpisujesz tylko te fakty, które zespół dyżurny ustalił podczas wstępnego triage’u (np. „od godziny 02.15 obserwujemy niedostępność klastra produkcyjnego wywołaną nieautoryzowanym szyfrowaniem wolumenów; trwa izolacja segmentów sieciowych”). Wysłanie wczesnego ostrzeżenia zamyka ryzyko formalnego przekroczenia terminu, a Twoim inżynierom daje kolejne dwie doby na spokojne zebranie twardych dowodów technicznych.

Faza 2 (do 72 godzin) – pełne zgłoszenie incydentu

Gdy pierwszy pożar zostanie opanowany, masz maksymalnie 72 godziny od momentu powzięcia wiedzy o incydencie na przesłanie właściwego zgłoszenia technicznego (incident notification). Ten dokument aktualizuje informacje z wczesnego ostrzeżenia i dostarcza analitykom CSIRT konkretny materiał inżynierski.

W zgłoszeniu 72‑godzinnym musisz zawrzeć trzy grupy danych:

1. Wstępną ocenę powagi i skali incydentu – określenie, które dokładnie usługi kluczowe lub ważne zostały zakłócone, ilu użytkowników lub kontrahentów dotknęła niedostępność, jak długo trwa przestój oraz jak zdarzenie klasyfikuje się według europejskiej taksonomii ENISA (np. Malware, Availability / DDoS, Intrusion, Unauthorised access).
2. Techniczne ślady włamania (IoC – Indicators of Compromise) – to najważniejsza sekcja z punktu widzenia inżynierów bezpieczeństwa. Przekazujesz w niej zewnętrzne adresy IP agresora, domeny serwerów sterujących (Command & Control – C2), sumy kontrolne (SHA‑256 / MD5) złośliwych plików binarnych, zidentyfikowane luki CVE oraz wzorce zapytań z logów zapory WAF.
3. Wdrożone działania zaradcze i mitygację – opis kroków, jakie podjął Twój zespół w celu powstrzymania ataku (np. odcięcie zainfekowanych podsieci VLAN/VPC, unieważnienie przejętych tokenów IAM i kluczy SSH, załatanie podatnej biblioteki czy przełączenie ruchu na ośrodek zapasowy, co w praktyce weryfikuje, jak zostało przeprowadzone projektowanie i testowanie planu Disaster Recovery (DRP) w Twojej organizacji).

Faza 3 (do 30 dni) – raport końcowy lub sprawozdanie z postępów

Ostatni etap procedury następuje nie później niż miesiąc od dnia złożenia zgłoszenia 72‑godzinnego. W tym momencie emocje już opadły, środowisko produkcyjne pracuje stabilnie, a zespół ma za sobą pełne dochodzenie techniczne.

Raport końcowy podsumowuje całe zdarzenie i musi zawierać:

• Szczegółowy opis incydentu, w tym jego dotkliwości i skutków – ostateczny bilans czasu niedostępności, wolumenu utraconych lub zmodyfikowanych danych oraz strat operacyjnych.
• Analizę przyczyn źródłowych (Root Cause Analysis – RCA) – precyzyjne wskazanie rodzaju zagrożenia oraz pierwotnego wektora wejścia (np. przejęte konto VPN bez wymuszonego MFA, niewyizolowany serwer testowy podpięty do produkcyjnej bazy danych czy luka w niezaktualizowanej wtyczce). W dojrzałych organizacjach technologicznych ten dokument powstaje na bazie ustrukturyzowanego procesu, który szerzej opisaliśmy w artykule pokazującym, jak działa analiza post‑mortem jako narzędzie ciągłego doskonalenia zespołów IT.
• Zastosowane i planowane środki naprawcze – wykaz trwałych zmian w architekturze (hardening systemów, przebudowa segmentacji sieci, wdrożenie niezmiennych kopii WORM), które gwarantują, że identyczny scenariusz ataku nie powtórzy się w przyszłości.

Co w sytuacji, gdy incydent jest na tyle złożony, że po upływie 30 dni działania naprawcze lub śledztwo wciąż trwają? Ustawa przewiduje na taką okoliczność sprawozdanie z postępów prac (progress report), a właściwy raport końcowy składasz wówczas w terminie miesiąca od momentu całkowitego zakończenia obsługi zdarzenia.

Obowiązek powiadomienia klientów i odbiorców usługi – punkt, o którym zapominają działy IT

Skupienie całej uwagi wyłącznie na formularzach wysyłanych do CSIRT NASK potrafi uśpić czujność w drugim, równie ważnym obszarze.

Znowelizowana ustawa o KSC nakłada na podmioty kluczowe i ważne obowiązek komunikacji w dół łańcucha dostaw:

• Powiadomienie o incydencie poważnym – jeżeli awaria lub włamanie ma niekorzystny wpływ na świadczenie Twojej usługi, musisz niezwłocznie poinformować o tym jej odbiorców (klientów końcowych lub kontrahentów B2B).
• Przekazanie środków zaradczych przy istotnym cyberzagrożeniu – jeżeli wykryjesz poważne zagrożenie, które może uderzyć bezpośrednio w systemy Twoich klientów (np. wykradziono z Twojej infrastruktury tokeny integracyjne API, doszło do zainfekowania biblioteki klienckiej lub sfałszowania webhooków), masz obowiązek wskazać tym klientom konkretne działania obronne, jakie mogą podjąć po swojej stronie (np. natychmiastowa rotacja kluczy dostępowych, blokada ruchu z określonych adresów IP czy wymuszenie wylogowania aktywnych sesji).

Dla firm technologicznych, dostawców SaaS, operatorów chmury i software house’ów oznacza to jedno – obok technicznego runbooka dla inżynierów musisz mieć przygotowany szablon komunikatu technicznego dla działów bezpieczeństwa Twoich klientów, obsługiwany przez osoby kontaktowe wyznaczone wcześniej zgodnie z art. 58 uKSC.

Dlaczego procedury w Wordzie polegną w niedzielę o 3.00 nad ranem?

Na papierze każde wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji wygląda wzorowo. W segregatorze CISO leży wydrukowana polityka obsługi incydentów, schemat eskalacji oraz tabela z numerami telefonów.

Problem w tym, że grupy ransomware oraz zautomatyzowane botnety nie atakują we wtorek o godzinie 11.00, gdy cały zespół DevOps siedzi przy biurkach z otwartymi terminalami.

Anatomia ataku w długi weekend i pułapka ulotnych logów

Z danych telemetrycznych zespołów reagowania jednoznacznie wynika, że ponad 70% niszczących ataków szyfrujących i prób wykradzenia baz danych rozpoczyna się w nocy z piątku na sobotę, w niedziele lub w dni ustawowo wolne od pracy. Intruzi celowo wybierają moment, w którym czas reakcji wewnętrznego działu IT wydłuża się z minut do kilkudziesięciu godzin.

Gdy w niedzielę o 3.00 nad ranem w firmie pozbawionej profesjonalnego dyżuru zaczyna wyć alarm, dochodzi zazwyczaj do jednego z dwóch scenariuszy – albo powiadomienie wpada na skrzynkę mailową, którą ktoś otworzy dopiero w poniedziałek rano, albo wyrwany ze snu administrator podejmuje działania pod wpływem stresu. O tym, jak uniknąć chaosu organizacyjnego w takich godzinach, pisaliśmy szerzej w artykule omawiającym skuteczne zarządzanie dyżurami i linią wsparcia 24/7.

Z technicznego punktu widzenia największym wrogiem raportowania w reżimie 24h/72h jest ulotność domyślnych logów w nowoczesnych architekturach:

• Kontenery i Kubernetes (kubectl delete pod) – jeżeli Twoja aplikacja działa w klastrze Kubernetesa lub w kontenerach Docker bez zewnętrznego kolektora logów, wszystkie wpisy ze strumieni stdout oraz stderr żyją wyłącznie tak długo, jak sam kontener. Gdy spanikowany administrator widzi zawieszony lub zainfekowany pod i odruchowo go restartuje, w ułamku sekundy bezpowrotnie kasuje całą historię wejścia agresora.
• Pułapka domyślnej rotacji (logrotate) – podczas ataku brute‑force, skanowania podatności lub masowego wyciągania danych z API serwer WWW (Nginx / Apache) oraz zapora sieciowa generują gigabajty wpisów na godzinę. Przy domyślnych ustawieniach logrotate na Linuksie stare pliki /var/log/auth.log czy access.log zostają nadpisane zanim ktokolwiek zdąży je zabezpieczyć.
• Celowe czyszczenie śladów przez intruza – atakujący, który zdobył uprawnienia root lub SYSTEM, w pierwszym kroku czyści historię powłoki (history ‑c, usunięcie .bash_history) oraz wycina wpisy w lokalnym dzienniku systemd‑journald lub Windows Event Log.

Kiedy w poniedziałek rano zespół próbuje wypełnić formularz 72‑godzinny dla CSIRT NASK, okazuje się, że na serwerze produkcyjnym nie ma już ani jednego śladu IoC.

Fundament telemetrii – synchronizacja czasu NTP i centralne repozytorium logów

Aby organizacja była w stanie odtworzyć przebieg włamania i wygenerować wiarygodny raport w ustawowym oknie czasowym, musi spełnić dwa twarde warunki architektoniczne, których nie zastąpi żaden dokument prawny.

Pierwszym z nich jest bezwzględna synchronizacja czasu systemowego (NTP / chrony) w strefie UTC na każdym elemencie infrastruktury.

Wyobraź sobie próbę korelacji ataku, w której firewall brzegowy ma zegar przesunięty o 4 minuty do przodu, węzeł roboczy Kubernetesa działa w czasie lokalnym CET, a serwer bazy danych PostgreSQL spóźnia się o 90 sekund. W takich warunkach powiązanie pojedynczego żądania HTTP z konkretnym zapytaniem SQL i wywołaniem procesu w systemie operacyjnym staje się koszmarem analitycznym, a oś czasu (timeline) przedstawiona audytorowi rozpada się przy pierwszym pytaniu kontrolnym.

Drugim warunkiem jest strumieniowanie telemetrii w czasie rzeczywistym do odseparowanego, centralnego repozytorium logów (np. w oparciu o stos OpenSearch, Graylog, Grafana Loki lub dedykowany system SIEM):

• Izolacja uprawnień (append‑only / WORM) – serwer logów musi znajdować się w osobnej strefie bezpieczeństwa i przyjmować dane jednokierunkowo. Nawet całkowite przejęcie konta root na maszynie produkcyjnej nie może dawać intruzowi technicznej możliwości skasowania lub zmodyfikowania logów wysłanych sekundę wcześniej do centralnego kolektora.
• Kompletny zakres zbieranych zdarzeń – repozytorium nie może zbierać wyłącznie błędów aplikacji; pod kątem wymogów uKSC kluczowe są logi uwierzytelniania (SSH, VPN, IAM, Active Directory), logi ruchu z zapór WAF i firewalli L3/L4, wywołania uprzywilejowane (sudo, auditd) oraz zapytania DNS.

Zabezpieczenie dowodów cyfrowych przed postawieniem systemu na nowo

W chwili wykrycia włamania naturalnym priorytetem biznesu jest jak najszybsze przywrócenie działania sklepu, platformy usługowej czy linii produkcyjnej. Z kolei wymogi uKSC oraz analiza powłamaniowa wymagają zachowania dowodów (tzw. evidence preservation).

Jak pogodzić te dwa sprzeczne cele o czwartej nad ranem bez niszczenia materiału dowodowego?

Kluczem jest przestrzeganie inżynierskiej zasady ulotności danych (order of volatility). Zanim ktokolwiek wyda komendę reboot, zaorze maszynę wirtualną i odtworzy ją z czystego backupu, dyżurny inżynier musi wykonać czteroetapową procedurę zabezpieczającą:

1. Izolacja sieciowa zamiast wyłączania zasilania – nigdy nie wyłączaj zainfekowanego serwera z prądu (power off). Zamiast tego odetnij go na poziomie reguł Security Group w chmurze, wirtualnego switcha lub VLAN‑u, blokując komunikację z Internetem i resztą sieci lokalnej przy zachowaniu włączonego systemu operacyjnego.
2. Zrzut pamięci ulotnej RAM (memory dump) – współczesny złośliwy kod często działa wyłącznie w pamięci operacyjnej (fileless malware), nie zostawiając plików na dysku. Tylko w pamięci RAM znajdziesz otwarte gniazda sieciowe, wstrzyknięte biblioteki, niezapisane procesy oraz klucze szyfrujące sesji. Wyłączenie maszyny bez zrzutu RAM (np. narzędziem LiME na Linuksie) bezpowrotnie niszczy te dane.
3. Migawka dysku w trybie tylko do odczytu (read‑only snapshot) – wykonaj natychmiastowy snapshot wolumenów dyskowych na poziomie hiperwizora (VMware, Proxmox) lub chmury (AWS EBS, Azure Managed Disks) i oznacz go flagą blokującą modyfikację.
4. Zrzut aktywnego ruchu sieciowego (PCAP) – zabezpiecz próbki ruchu na interfejsie brzegowym (tcpdump), które pokażą analitykom CSIRT NASK, z jakimi adresami IP i domenami C2 próbował komunikować się przejęty host.

Dopiero po wykonaniu tych operacji – co przy zautomatyzowanych skryptach zajmuje kilkanaście minut – możesz bezpiecznie postawić czyste instancje produkcyjne na boku, podczas gdy zabezpieczone obrazy posłużą do przygotowania precyzyjnego zgłoszenia 72‑godzinnego.

Techniczne runbooki zamiast pięćdziesięciostronicowych polityk w segregatorze

Podczas rzeczywistego ataku nikt nie ma czasu na czytanie pięćdziesięciu stron ogólnej „Polityki Zarządzania Incydentami” napisanej językiem prawniczym.

Aby zespół techniczny był w stanie zamknąć triage i wysłać wczesne ostrzeżenie w 24 godziny, potrzebuje krótkich, operacyjnych runbooków inżynierskich (Standard Operating Procedures – SOP) przypisanych do konkretnych scenariuszy (np. Runbook A – wykrycie szyfrowania ransomware, Runbook B – przejęcie klucza IAM w chmurze, Runbook C – wolumetryczny atak DDoS / RCE na aplikację webową).

Dobry runbook inżynierski mieści się na dwóch ekranach i zawiera wyłącznie twarde instrukcje wykonawcze:

• Gotowe komendy CLI i skrypty automatyzujące – dokładne polecenia izolujące dany węzeł w klastrze, wywołujące snapshoty dysków oraz zbierające paczkę diagnostyczną z logami z ostatnich 24 godzin.
• Listę kontrolną pól do formularza S46 – wypunktowanie konkretnych danych, które inżynier musi wyciągnąć z systemu SIEM i przekazać osobie kontaktowej (art. 58 uKSC) na potrzeby wczesnego ostrzeżenia.
• Drzewo eskalacji z czasami granicznymi – jasny podział ról określający, kto w pierwszych 15 minutach izoluje infrastrukturę, kto zabezpiecza dowody, a kto o poranku składa podpis elektroniczny pod zgłoszeniem do CSIRT NASK.

Jak całodobowy dyżur inżynierski Centurii zdejmuje ciężar reżimu 24h z barków Twojego zespołu

Utrzymanie wewnętrznego zespołu inżynierów bezpieczeństwa i administratorów systemowych pracujących w systemie trzyzmianowym (24/7/365) wymaga zatrudnienia na wyłączność minimum pięciu lub sześciu wysokiej klasy specjalistów. Dla większości średnich i dużych przedsiębiorstw z sektorów produkcyjnych, logistycznych, handlowych czy technologicznych jest to bariera nie do przeskoczenia – zarówno budżetowo, jak i rekrutacyjnie.

Właśnie w tym miejscu wchodzi zespół Centurii, przejmując na siebie operacyjny ciężar całodobowego nadzoru nad infrastrukturą i technicznej obsługi incydentów.

Dyżur inżynierski SDO 24/7/365 z czasem reakcji SLA poniżej 15 minut

Wiele firm oferujących zewnętrzne wsparcie IT sprzedaje pod hasłem „całodobowego monitoringu” zwykłą infolinię pierwszej linii (L1 Helpdesk). W takim modelu, gdy w niedzielę o 3.15 nad ranem pada klaster produkcyjny albo zapora rejestruje próbę włamania, konsultant jedynie odbiera alert i zaczyna dzwonić do Twojego dyrektora IT, budząc go w środku nocy.

W Centurii działamy w zupełnie innym standardzie inżynierskim.

Nasz całodobowy monitoring serwerów i dyżur inżynierski 24/7/365 (SDO) jest obsadzony bezpośrednio przez doświadczonych administratorów SysOps oraz inżynierów DevOps. Gdy systemy telemetryczne wykryją anomalię o dowolnej porze dnia lub nocy, dyżurny inżynier podejmuje interwencję w gwarantowanym umową SLA czasie poniżej 15 minut – samodzielnie logując się do środowiska i rozpoczynając techniczny triage bez czekania na pobudkę Twojego zespołu.

Automatyczna korelacja telemetrii i izolacja zagrożenia w zarodku

Zanim zaczniemy chronić Twoją infrastrukturę, porządkujemy jej architekturę obserwowalności (observability). Konfigurujemy spójną synchronizację czasu NTP, wdrażamy odseparowane, niezmienne repozytoria logów oraz ustawiamy wielowarstwowe sondy monitorujące:

• Warstwę sieciową i brzegową – analiza ruchu na zaporach WAF (np. Cloudflare, AWS WAF), wykrywanie skanowania portów, anomalii w zapytaniach DNS oraz prób zestawienia połączeń z serwerami C2.
• Warstwę systemową i kontenerową – nadzór nad wywołaniami uprzywilejowanymi (auditd, sudo), kontrola integralności kluczowych plików konfiguracyjnych, monitorowanie podejrzanych procesów w klastrach Kubernetes i środowiskach wirtualnych (Proxmox, VMware, AWS, Azure).
• Warstwę aplikacyjną i bazodanową – wychwytywanie nietypowych wzorców zapytań SQL, skoków błędów autoryzacji API oraz prób masowego pobierania rekordów.

Dzięki temu nasz inżynier dyżurny jest w stanie odciąć przejęty węzeł lub zablokować wektor ataku w pierwszych kilkunastu minutach od wystąpienia anomalii – często zanim złośliwy skrypt zdąży zaszyfrować pierwszy wolumen produkcyjny.

Przygotowanie wsadu technicznego (evidence pack) pod zgłoszenie do CSIRT NASK

Co najważniejsze z punktu widzenia zarządu oraz osoby kontaktowej wpisanej do systemu S46 – nie zostawiamy Cię samego z pustym formularzem rządowym.

Podczas gdy nasi inżynierowie izolują zagrożenie i odtwarzają ciągłość działania usługi, równolegle zabezpieczamy materiał dowodowy zgodnie z zasadami informatyki śledczej (zrzuty pamięci RAM, migawki dysków read‑only, próbki ruchu PCAP). Na tej podstawie przygotowujemy dla Twojej organizacji gotowy wsad techniczny (evidence pack), który zawiera:

1. Precyzyjną oś czasu incydentu (timeline w UTC) – dokładną godzinę wystąpienia anomalii, moment powzięcia wiedzy (triage) oraz chronologię działań mitygujących pod formularz 24‑godzinny.
2. Wyekstrahowane wskaźniki włamania (IoC) – kompletną listę adresów IP atakujących, sum kontrolnych złośliwych plików, wykorzystanych luk CVE oraz logów dostępowych wymaganych w zgłoszeniu 72‑godzinnym.
3. Dokumentację Root Cause Analysis (RCA) – szczegółowy raport inżynierski z opisem wektora wejścia i wdrożonych poprawek architektonicznych, gotowy do załączenia jako raport końcowy po 30 dniach.

Twój zarząd oraz dział prawny otrzymują na biurko wyselekcjonowane, twarde dane techniczne, które wystarczy podpisać kwalifikowanym podpisem elektronicznym i wysłać w systemie S46 – bez nerwowego szukania logów i bez ryzyka przekroczenia ustawowych terminów.

Podsumowanie – zamień papierową procedurę w realną gotowość operacyjną

Ustawowe okno 24 godzin na zgłoszenie wczesnego ostrzeżenia do CSIRT NASK oraz 72 godzin na pełną notyfikację incydentu to brutalny sprawdzian dojrzałości technicznej dla każdej organizacji objętej nowelizacją uKSC. W zderzeniu z nocnym atakiem ransomware lub włamaniem do chmury wygrywają nie te firmy, które posiadają najgrubsze segregatory z politykami bezpieczeństwa, lecz te, które dysponują niezmiennymi logami, przetestowanymi runbookami i żywym inżynierem na dyżurze.

Zamiast ryzykować utratę dowodów cyfrowych i paraliż decyzyjny w środku weekendu, powierz nadzór nad swoją infrastrukturą zespołowi, który od lat utrzymuje systemy o krytycznym znaczeniu biznesowym.

Sprawdź, jak wygląda audyt gotowości i monitoring serwerów pod NIS2 w wykonaniu certyfikowanych inżynierów Centurii (ISO/IEC 27001, AWS Certified Security, CKA Kubernetes) – od wdrożenia centralnych repozytoriów logów WORM i konfiguracji zapór WAF, przez opracowanie technicznych runbooków, aż po całodobowy dyżur SDO 24/7/365 z gwarancją reakcji poniżej 15 minut.