Zanim zatrzesz ślady - reakcja na incydent cyberbezpieczeństwa. Wstępna analiza, łagodzenie skutków i wzmocnienie systemu
Kontekst: pierwsza godzina, która decyduje o wszystkim
Moment wykrycia incydentu wyzwala w niemal każdym zespole IT ten sam odruch: zatrzymać krwawienie, natychmiast. Zresetować zainfekowany serwer, odciąć podejrzane konto, przywrócić usługę z backupu i wrócić do pracy, zanim ktokolwiek zauważy przestój. To odruch zrozumiały - i w większości przypadków błędny. Pierwsza godzina po wykryciu ataku decyduje nie tylko o tym, jak szybko wrócicie do działania, ale o tym, czy w ogóle będziecie w stanie ustalić, co się właściwie stało, skąd atakujący miał dostęp i czy na pewno już go nie ma.
Znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, dokłada do tego drugi wymiar presji: podmioty kluczowe i ważne mają obowiązek zgłoszenia incydentu do właściwego CSIRT w ściśle określonych ramach czasowych - wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, a pełniejsze zgłoszenie w ciągu 72 godzin. Zgłoszenie oparte na domysłach, bo dowody zostały nadpisane w panice pierwszej godziny, jest trudne do obronienia przed organem nadzorczym - i jeszcze trudniejsze do wykorzystania wewnętrznie, żeby faktycznie załatać lukę, która do ataku doprowadziła.
W tym artykule pokazujemy, dlaczego zespoły tak często „zacierają ślady” zanim ktokolwiek zdąży je zbadać, i jak zorganizować reakcję na incydent w kolejności, która realnie ogranicza szkody, zamiast tylko dawać poczucie kontroli.
Dlaczego zespoły zacierają ślady, zanim ktokolwiek zdąży je zbadać
Presja na natychmiastowe przywrócenie usługi. Każda godzina przestoju to policzalny koszt biznesowy, a kierownictwo rzadko pyta „czy zabezpieczyliśmy dowody”, tylko „kiedy to znowu zadziała”. Administrator, który ma tę presję na karku, naturalnie priorytetyzuje przywrócenie działania nad zachowaniem stanu systemu do analizy - nawet jeśli wie, że to nie jest właściwa kolejność.
Mylenie „naprawienia” z „zareagowaniem”. Zresetowanie serwera daje natychmiastowe, namacalne poczucie, że coś się zrobiło. Zabezpieczenie logów i wykonanie obrazu dysku nie daje takiej satysfakcji - efekt jest niewidoczny, a system dalej stoi zainfekowany. Psychologicznie łatwiej jest wybrać działanie, które czuć jako postęp, nawet jeśli faktycznie niszczy możliwość zrozumienia, co się stało.
Strach przed konsekwencjami personalnymi. Jeśli incydent wynikł z zaniedbanej aktualizacji, niezmienianego od miesięcy hasła administracyjnego albo furtki, o której ktoś wiedział i nie zgłosił, osoba odpowiedzialna za dany system ma silny, choć rzadko wypowiedziany wprost, motyw, żeby jak najszybciej „posprzątać” - zanim ktokolwiek zada pytanie, jak długo ta luka tam była.
Brak przygotowanego planu. Zespół, który nie ma spisanej procedury reagowania na incydenty, improwizuje w warunkach maksymalnego stresu - a improwizacja pod presją domyślnie wybiera działania odwracalne w skutkach dla biznesu (przywrócenie usługi) kosztem działań nieodwracalnych, gdy się ich nie wykona w porę (zabezpieczenie ulotnych dowodów, takich jak zawartość pamięci RAM czy aktywne połączenia sieciowe, które znikają przy restarcie).
Restart zainfekowanej maszyny to jedna z niewielu decyzji w całym incydencie, której nie da się cofnąć. Dowody w pamięci RAM, aktywne połączenia, tymczasowe pliki procesu atakującego - znikają w kilka sekund. Możesz poczekać z przywróceniem usługi kilka godzin dłużej. Nie możesz odzyskać dowodów, które sam zniszczyłeś.
Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa
Trzy fazy reakcji na incydent
Faza 1: wstępna analiza, zanim cokolwiek ruszysz. Zanim padnie decyzja o restarcie, odłączeniu czy reinstalacji, trzeba ustalić zakres: które systemy są objęte, jak długo atakujący miał dostęp i jaką drogą go uzyskał. W praktyce oznacza to zabezpieczenie logów (systemowych, sieciowych, aplikacyjnych) w formie, której nie da się później podważyć, wykonanie obrazu dysku zainfekowanej maszyny przed jakąkolwiek ingerencją oraz odizolowanie systemu od sieci zamiast jego wyłączania - odcięcie dostępu zatrzymuje rozprzestrzenianie się ataku, nie niszcząc przy tym danych ulotnych, które przepadają przy zwykłym restarcie. Równie istotne jest ograniczenie liczby osób, które w ogóle dotykają zainfekowanego systemu w tej fazie - każda dodatkowa osoba logująca się „żeby zobaczyć, co się dzieje” to potencjalnie nadpisany dowód i luka w łańcuchu dowodowym, trudna do wyjaśnienia na etapie zgłoszenia do CSIRT.
Faza 2: łagodzenie skutków, nie tylko objawów. Dopiero mając choćby wstępny obraz sytuacji, można świadomie ograniczać szkody: blokować konta, przez które doszło do włamania, resetować dane uwierzytelniające w całej organizacji, jeśli podejrzewasz ich wyciek, i informować odpowiednie strony - od kierownictwa, przez klientów, których dane mogły zostać naruszone, po CSIRT w ramach czasowych wymaganych przez ustawę o KSC. To etap, na którym najłatwiej pomylić szybkość z jakością - ograniczenie skutków incydentu, który nie został poprawnie zdiagnozowany w fazie pierwszej, często oznacza zamknięcie jednej furtki, podczas gdy atakujący korzysta już z drugiej.
Faza 3: wzmocnienie systemu, żeby to się nie powtórzyło. Ostatni etap to analiza źródła - nie tego, co atakujący zrobił po wejściu, tylko tego, jak w ogóle wszedł - i usunięcie realnej przyczyny, a nie tylko jej skutku. Reinstalacja systemu bez ustalenia i załatania wektora wejścia daje fałszywe poczucie bezpieczeństwa: ten sam błąd konfiguracyjny czy ta sama niezałatana luka wpuści atakującego drugi raz, często szybciej, niż zespół zdąży się otrząsnąć po pierwszym incydencie. Ten etap kończy się zawsze udokumentowanym podsumowaniem powdrożeniowym (post-mortem) - nie po to, żeby kogoś obwinić, tylko żeby zaktualizować procedury na podstawie tego, co faktycznie zawiodło.
Studium przypadku
Firma świadcząca usługi hostingowe i utrzymania infrastruktury IT dla około 40 klientów biznesowych, zatrudniająca 19 osób, wykryła nietypowy ruch sieciowy na jednym z serwerów zarządzających kopiami zapasowych klientów - klasyczna sytuacja dostawcy usług zarządzanych objętego wymogami NIS2 jako element łańcucha dostaw swoich klientów. Dyżurujący administrator, widząc oznaki aktywności ransomware, w odruchu paniki natychmiast zrestartował serwer i rozpoczął przywracanie systemu z obrazu sprzed tygodnia, licząc, że w ten sposób „wyczyści” zagrożenie, zanim rozprzestrzeni się na kolejne maszyny.
Decyzja ta, choć podjęta w dobrej wierze, zniszczyła większość dowodów potrzebnych do ustalenia wektora wejścia - zawartość pamięci serwera, aktywne procesy i połączenia sieciowe przepadły w chwili restartu. Zespół nie wiedział, czy atakujący uzyskał dostęp przez lukę w oprogramowaniu do zarządzania kopiami, przejęte dane logowania jednego z pracowników, czy może przez zapomniany, wystawiony na zewnątrz port administracyjny - a bez tej wiedzy nie można było z pewnością stwierdzić, że zagrożenie faktycznie zostało usunięte, czy tylko chwilowo uśpione.
Dopiero po włączeniu do sprawy zewnętrznego zespołu analizy powłamaniowej udało się częściowo zrekonstruować przebieg zdarzeń na podstawie logów, które nie zostały nadpisane restartem - okazało się, że atakujący wykorzystał niezmienione od wdrożenia, domyślne hasło do panelu administracyjnego jednego z rzadziej używanych narzędzi monitorujących. Firma wdrożyła procedurę, w której każdy przyszły incydent najpierw jest izolowany na poziomie sieci, a dopiero potem - po zabezpieczeniu obrazu dysku i logów - poddawany dalszym działaniom naprawczym. Wprowadzono też cykliczny audyt haseł domyślnych we wszystkich narzędziach trzecich, nie tylko w systemach objętych główną polityką bezpieczeństwa.
W sytuacji kryzysowej ludzie potrzebują poczucia, że coś robią - i to jest naturalne, nie jest to błąd charakteru. Zadaniem dobrej procedury reagowania na incydenty jest pokierowanie tej potrzeby działania we właściwą stronę: dać zespołowi jasne, natychmiastowe kroki do wykonania, które faktycznie chronią dowody, zamiast zostawiać ludzi samych z instynktem, który każe im jak najszybciej nacisnąć „restart”.
Edyta Müller-Ciaś, współzałożycielka betternow.group | Chief Change & Culture Officer | dyrektorka ds. rozwoju organizacji | ekspertka ds. zarządzania zmianą i psychologii biznesu
Wnioski praktyczne
- Restart i reinstalacja to działania nieodwracalne - dane ulotne (pamięć RAM, aktywne połączenia, procesy) znikają bezpowrotnie. Zawsze izoluj system od sieci zamiast go wyłączać, jeśli tylko sytuacja na to pozwala.
- Kolejność ma znaczenie: najpierw analiza, potem łagodzenie skutków, na końcu wzmocnienie systemu - odwrócenie tej kolejności zwykle oznacza gaszenie objawów bez ustalenia i usunięcia realnej przyczyny.
- Zgłoszenie do CSIRT w ramach 24/72 godzin wymaganych przez ustawę o KSC jest łatwiejsze do rzetelnego wypełnienia, gdy dowody zostały zabezpieczone od pierwszej minuty - zgłoszenie oparte na domysłach słabo wygląda przed organem nadzorczym.
- Brak spisanej procedury reagowania oznacza improwizację pod presją - a improwizacja pod presją niemal zawsze wybiera działania dające natychmiastową ulgę kosztem tych, które chronią możliwość analizy.
- Każdy incydent powinien kończyć się udokumentowanym podsumowaniem powdrożeniowym - nie w celu obwiniania konkretnej osoby, lecz żeby zaktualizować procedury na podstawie tego, co faktycznie zawiodło.
Wykryłeś incydent i nie masz pewności, czy Twój zespół zareaguje we właściwej kolejności? betternow.group pomaga przygotować i przetestować procedury reagowania na incydenty, przeprowadza analizę powłamaniową i wzmacnia systemy po ataku - a jeśli incydent trwa u Ciebie teraz, skontaktuj się z nami od razu.