W niniejszym artykule podzielimy się swoimi doświadczeniami z wykonywanych zawodowo procesów obsługi incydentów. Przedstawimy krajobraz, na jaki zwykle możemy natknąć się w organizacji bezpośrednio po wykryciu incydentu. Pokażemy przykłady błędnych działań, które są wtedy podejmowane, oraz takich, które powinny zostać podjęte.
Stare komputerowe porzekadło mówi, że administratorzy IT dzielą się na takich, którzy robią kopie zapasowe i na takich, którzy je będą robić. Na gruncie bezpieczeństwa IT można by powiedzieć, że firmy dzielą się na takie, które wykonują (zazwyczaj zlecają) testy bezpieczeństwa i takie, które kiedyś to zrobią. Należałoby tu też uczciwie zaznaczyć, że wykonane testy bezpieczeństwa (i oczywiście wdrożenie po nich poprawek) nie gwarantują, że do żadnego incydentu nie dojdzie. Takie działania po prostu wyeliminują szerokie spektrum zagrożeń technicznych, ale wciąż będzie mogło dojść do incydentu, którego źródłem będą metody socjotechniczne, np. phishing.
W każdym zatem wypadku warto na incydent być przygotowanym. Po pierwsze dlatego, że incydent wystąpi nagle, bez ostrzeżenia i prawdopodobnie w najmniej oczekiwanym przez organizację momencie (tu warto wtrącić, że atakujący z reguły najbardziej aktywni są w okolicach wolnych od pracy dni). Z jednej więc strony mamy niespodziewaną informację, że intruz kontroluje w jakimś stopniu naszą infrastrukturę, z drugiej nie wiemy właściwie w jakim zakresie i jakie ma zamiary. Nie wiemy, czy przerwał swoje działania czy może właśnie wyprowadza bądź niszczy nasze dane.
Można by się pokusić o porównanie włamania cybernetycznego z włamaniem fizycznym do lokalu bądź budynku i to drugie okaże się dla ofiary bardziej komfortowe, jakkolwiek by to nie brzmiało. Stwierdzić, że złodzieja nie ma w lokalu jest relatywnie łatwo i można to zrobić we własnym zakresie (teoretycznie, w praktyce zalecamy pomoc Policji). Nie nastręczy też większych problemów ustalenie jakich dóbr w lokalu ubyło i jakie zostały zniszczone. Zupełnie inaczej sprawy się mają w wypadku ataku IT, bo po pierwsze system komputerowy jest daleko bardziej skomplikowany niż mieszkanie a po drugie zawłaszczenia dóbr cyfrowych z reguły zwyczajnie nie widać. Wszystko to każdy administrator systemu czuje intuicyjne, ale ta wiedza niekoniecznie pomaga w działaniach. Ta świadomość oraz presja czasu ze strony przełożonych, współpracowników czy klientów mogą przekładać się (i przekładają się) na nieprzemyślane działania.
Najczęstszym działaniem w tego rodzaju okolicznościach jest odłączenie systemu komputerowego od zasilania, co jest kardynalnym błędem. Wyłączenie zasilania jest rozwiązaniem typowo chwilowym, które co prawda pozwoli przerwać atak, ale jednocześnie bardzo skutecznie zatrze jego ślady. Dla jasności powiedzmy, że tzw. grzeczne zamknięcie systemu (ang. shutdown) nie jest tu bardziej korzystne – a zapewne może i mniej. Dlaczego tak jest? W ulotnej pamięci operacyjnej komputera przechowywane są najważniejsze z punktu dalszego dochodzenia okoliczności ataku informacje: zainfekowane procesy systemowe, własne procesy atakujących czy informacje o otwartych połączeniach sieciowych. Zainfekowany komputer należy zatem odłączyć od sieci informatycznej – najpewniej jest wyciągnąć wtyczkę Ethernet z gniazdka. Dzięki temu definitywnie zostanie przerwana komunikacja pomiędzy maszyną a atakującym: więcej danych komputera nie opuści i nie zostaną też przekazane kolejne instrukcje z zewnątrz. To nam wystarczy.
No dobrze, a co jeśli zaatakuje nas nie człowiek, a skrypt, pokroju szyfrujących Wannacry czy CryptoLockera? Po odłączeniu komputera od sieci należy go zahibernować. Hibernacja (na szczęscie dostępna w każdym systeme rodziny Windows, ulubionej przez szkodliwe szyfratory), spowoduje, że szyfrowanie zostanie przerwane, a znajdujące się w pamięci operacyjnej dane (klucze szyfrujące), które mogą pomóc w deszyfracji danych przez specjalistę nie znikną z naszego zasięgu.
Przestrzeganie przedstawionych prostych zasady samo w sobie w ogromnym stopniu ułatwi proces późniejszego łagodzenia skutków incydentu teleinformatycznego. Należy jednak pamiętać, iż organizacja powinna wypracować na swój użytek bardziej złożone procedury reakcji na incydent bezpieczeństwa, które będą uwzględniały specyfikę danego środowiska, np. krytyczności i zależności systemów komputerowych czy kompetencje pracowników. Istnieją też różne kategorie incydentów i w ślad za nimi warto mieć różne warianty postępowań.
Od niedawna dużą rolę odgrywa też wszechobecne RODO – na zgłoszenie incydentu z udziałem danych osobowych mamy 72h, czyli 3 doby. W praktyce to nie jest wiele czasu, żeby choć wstępnie zapanować nad poincydentalnym chaosem i ocenić, czy faktycznie doszło do naruszenia ochrony danych osobowych. Procedury na taką okoliczność mogą okazać się zbawienne. Warto o tym pamiętać.
