Jak nie reagować na atak hackerski – 10 często spotykanych błędów

Złośliwe oprogramowanie, atak hackerski, przejęcie systemu. Jak najczęściej informatycy reagują na tego typu zdarzenia? Pod wpływem stresu i presji czasu postępują intuicyjnie, co niestety w większości przypadków oznacza problemy. Poniżej przygotowałem listę dziesięciu często spotykanych zachowań w obliczu wystąpienia poważnego zagrożenia. Wszystkie one stanowią przykłady działań, które w większości przypadków są nie wskazane i mogą utrudnić prawidłową obsługę incydentu bezpieczeństwa:

1. Odcięcie zasilania – ten krok wydaje się uzasadniony ponieważ pozwala na natychmiastowe zatrzymanie działań destrukcyjnych. Niestety w chwili wykrycia incydentu intruz najczęściej wyrządził już określone szkody i nagłe wyłączenie systemu spowoduje utratę cennych danych, których analiza mogłaby pomóc w jego identyfikacji. Również standardowe, bezpieczne wyłączenie systemu nie jest dużo lepszym rozwiązaniem.
2. Logowanie się do systemu dotkniętego incydentem bezpieczeństwa. System przejęty przez intruza może być wykorzystany do działań przeciwko nam. Już samo zalogowanie się w nim może spowodować przejęcie danych uwierzytelniających.
3. Pobieranie i instalowanie w systemie, którego dotyczy incydent narzędzi diagnostycznych lub śledczych w celu przeprowadzenia analizy. Może to spowodować nadpisanie danych na dysku i utrudnić analizę incydentu i poczynań intruza.
4. Pobieranie na dysk systemu dotkniętego incydentem jakichkolwiek danych, zwłaszcza poufnych (np. procedur postępowania, instrukcji, dokumentacji środowiska IT lub haseł). Poza opisanym w punkcie poprzednim ryzykiem nadpisania cennych informacji na dysku zachodzi ryzyko przejęcia poufnych danych przez intruza.
5. Podłączanie do analizowanego systemu nośników pamięci, na których mogą występować poufne dane. Administratorzy chcąc uniknąć pobierania narzędzi na dysk komputera mogą posługiwać się nośnikami zewnętrznymi. Częstym błędem jest jednak stosowanie nośników, na których zgromadzone zostały dane, które mogą zostać przejęte przez intruza.
6. Mapowanie w systemie objętym incydentem zasobów sieciowych zawierających poufne dane, lub zasobów do których dany użytkownik ma prawa zapisu. Należy pamiętać, że w przypadku przejęcia systemu intruz będzie miał dostęp do mapowanych zasobów z uprawnieniami użytkownika prowadzącego obsługę incydentu.
7. Usuwanie z dysku wszelkich śladów złośliwego oprogramowania. Pozbywając się zainfekowanych plików uniemożliwiamy jednocześnie ich analizę. Może to utrudnić identyfikację zagrożenia i określanie skali incydentu.
8. Unicestwianie podejrzanych procesów systemowych bez uprzedniego ich analizowania. Procesy związane ze złośliwym oprogramowaniem mogą dostarczyć cennych informacji do analizy.
9. Przywracanie stanu systemu bez uprzedniej analizy. Wykorzystanie punktow przywracania systemu Windows pozwala cofnąć system do stanu sprzed wystąpienia zagrożenia. Eliminuje jednak jednocześnie możliwość ustalenia w jaki sposób doszło do incydentu i jakie mogą być jego konsekwencje.
10. Formatowanie dysku. Często podejmowanym działaniem wobec systemów zainfekowanych złośliwym oprogramowaniem jest formatowanie dysku i postawienie systeemu od zera. Podobnie jak w punkcie poprzednim pozbawiamy się w ten sposób możliwości przeanalizowania zagrożenia, w związku z czym może się ono pojawić ponownie.

Powyższa lista ma na celu uświadomienie, że reakcja na incydent bezpieczeństwa nie jest rzeczą łatwą. Należy się do niej dobrze przygotować i zaopatrzyć w odpowiednią wiedzę teoretyczną oraz procedury i narzędzia. Jeżeli chciałbyś się dowiedzieć więcej na ten temat polecamy Twojej uwadze cykl artykułów  poświęconych obsłudze incydentów. W pierwszym z nich opisujemy jak przygotować się do obsługi incydentu bezpieczeństwa.

Obserwuj

Obserwuj