rozpoznanie zagrożenia

Rozpoznanie zagrożenia to identyfikacja charakteru i skali incydentu bezpieczeństwa.

Pierwszy etap obsługi incydentu

Rozpoznanie zagrożenia to moment, w którym z chaosu sygnałów — dziwnego okna, spowolnienia komputera, telefonu od kontrahenta o podejrzanej fakturze — powstaje odpowiedź na cztery pytania: co się dzieje, od kiedy, jak daleko sięgnęło i co jest zagrożone dalej. To etap poprzedzający jakiekolwiek naprawianie i najczęściej pomijany, bo pierwszym odruchem jest sformatowanie zainfekowanej maszyny. Tymczasem właśnie odruch czyszczenia niszczy dowody: dzienniki systemowe, próbkę złośliwego pliku, notatkę z żądaniem okupu zawierającą identyfikator kampanii, historię logowań. Bez tego materiału nie da się ustalić, czy zagrożenie ograniczyło się do jednego stanowiska, czy porusza się po sieci.

Rozróżnianie skali: awaria, infekcja, wyciek

Trzy zdarzenia wyglądają na początku podobnie, a wymagają zupełnie innych działań. Zwykła awaria oprogramowania nie ma śladów sieciowych ani nowych kont w systemie. Infekcja jednego stanowiska objawia się nieznanym procesem, wpisem w autostarcie i zwykle konkretnym wektorem wejścia: załącznikiem, plikiem z pendrive'a albo instalatorem pobranym z fałszywej strony. Poważny incydent obejmujący sieć poznaje się po logowaniach kontem administratora domeny poza godzinami pracy, po tych samych zaszyfrowanych plikach na zasobach współdzielonych i po znikających kopiach zapasowych — atakujący kasują je jako pierwsze, żeby wymusić zapłatę. Osobna kategoria to wyciek danych bez szyfrowania: nic nie przestaje działać, a jedynym śladem jest nietypowy ruch wychodzący albo zgłoszenie z zewnątrz. Zaszyfrowany plik z obcym rozszerzeniem i plikiem instrukcji w każdym katalogu to sygnał, żeby natychmiast odłączyć maszynę od sieci, ale nie wyłączać jej zasilaniem — pamięć operacyjna bywa jedynym miejscem, gdzie zapisany jest klucz.

Co sabotuje własne rozpoznanie

Najczęstsza pomyłka to zaufanie jednemu narzędziu: skaner zgłasza czysto, więc uznaje się sprawę za zamkniętą, podczas gdy złośliwy komponent uruchamiany zadaniem harmonogramu lub skryptem w profilu użytkownika w ogóle nie jest plikiem, który skaner potrafi zobaczyć. Druga to zbyt krótka retencja dzienników — domyślne ustawienia potrafią nadpisywać zapisy w kilka dni, więc gdy ktoś zgłasza problem po tygodniu, historia już nie istnieje. Trzecia to praca na zainfekowanym systemie: przeglądanie dzienników z konta administratora na zaatakowanej maszynie oddaje napastnikowi kolejne poświadczenie. Czwarta to milczenie — pracownik, który kliknął w link, boi się przyznać, a każda godzina zwłoki zwiększa zasięg. Warto z góry ustalić, że zgłoszenie pomyłki nie ma konsekwencji dyscyplinarnych, bo to jedyny sposób, żeby dowiadywać się o incydentach wcześnie.

Reakcja w trybie pilnym

Przy podejrzeniu ataku liczy się to, co dzieje się w pierwszych godzinach: odcięcie zajętych stanowisk od sieci, sprawdzenie stanu kopii zapasowych, przegląd kont z podwyższonymi uprawnieniami i zmiana haseł kont, przez które napastnik mógł się poruszać. Pracujemy przez całą dobę siedem dni w tygodniu, także w święta, bo szyfrowanie danych firmowych zaczyna się zwykle w nocy z piątku na sobotę, gdy nikt nie patrzy na monitory. Serwery i stanowiska z oprogramowaniem handlowym opartym o SQL Server sprawdzamy osobno, bo bazy trzymane w plikach na dysku bywają szyfrowane razem z resztą, a odtworzenie działającego systemu wymaga zgodnej kopii bazy i właściwej wersji aplikacji. Na czas odbudowy stanowiska udostępniamy sprzęt zastępczy, żeby firma mogła wystawiać dokumenty.