Było włamanie, co dalej?

Zaczynamy działanie

Pierwszym działaniem grupy powinno być oszacowanie skali zagrożenia.

  • Czy jest to kompromitacja przez pasjonata mało znaczącego serwera w oddzielonej części sieci, a przeznaczonego do publikacji powszechnie dostępnych dokumentów w Internecie? Jeśli tak, to zagrożenie dla infrastruktury jest niewielkie.
  • Czy jest to kompromitacja zapory sieciowej powodująca otwarcie części sieci dla ataków - ryzyko jest duże.
  • Czy jest to kradzież niektórych dokumentów niskiego szczebla - ryzyko jest duże, bo analiza miejsca naruszenia bezpieczeństwa (czytaj - znalezienie winnej osoby) bywa bardzo trudna w firmach, które nie są na to przygotowane.
  • Czy jest to wykrycie kradzieży danych polegającej na instalacji rootkita w serwerze aplikacyjnym lub bazodanowym - zagrożenie jest bardzo duże.
  • Czy jest to zastosowanie dedykowanego wirusa, któremu udało się uniknąć alarmu programu antywirusowego i systemów IDS/IPS - zagrożenie jest bardzo duże, bo oznacza użycie narzędzi specjalnie skierowanych przeciw firmie, czyli dostosowanych do konkretnej konfiguracji sprzętu i oprogramowania.
  • Czy jest to przeciek informacji na wysokim szczeblu - ryzyko jest bardzo duże, zaś metody przeciwdziałania są często ograniczone ze względów proceduralnych lub zależności służbowych.
Oszacowanie skali obejmuje nie tylko narażone elementy infrastruktury firmy. Powinno także zawierać dokumentację danych, które mogą być zagrożone. Ze względu na to, że na początku analizy wiele danych nie zostało jeszcze dostatecznie poznanych, niektórzy administratorzy dzielą je z reguły na trzy grupy:
  • Obszary <font color="#ff0000">"czerwone", które na pewno zostały skompromitowane (np. serwer z pracującym rootkitem lub ewidentnie skradzione dokumenty z narady).
  • Strefy <font color="#ffff00">"żółte", które prawdopodobnie zostały narażone na atak (np. inne maszyny z tej samej podsieci albo inne dokumenty pochodzące z tego samego źródła).
  • Miejsca <font color="#008000">"zielone", w których naruszenie bezpieczeństwa jest możliwe, ale znacznie mniej prawdopodobne (np. komputery z izolowanej podsieci albo dokumenty dostępne w innej formie, z innego źródła). Kwalifikacja do tej strefy powinna być bardzo ostrożna. Dobrym przykładem są dane z archiwum przechowywane offline lub w wersji papierowej, gdy atak nastąpił niewątpliwie drogą elektroniczną, zaś kopii tych danych nie ma w zagrożonym obszarze, albo dokumenty, do których sprawca nie mógł mieć dostępu, ponieważ są chronione w inny sposób.
Dzięki takiemu podziałowi grupa może skoncentrować działania tam, gdzie są niezbędne w pierwszej kolejności. Nie zawsze musi to być obszar IT, bo podczas wstępnej analizy może się okazać, że źródłem naruszenia bezpieczeństwa jest pracownik ochrony lub recepcji, który wpuścił intruza z laptopem, lub sprzątaczka, która prawdopodobnie zainstalowała podsłuch. Wówczas znacznie ważniejsze będą działania prawne.

Odłączyć kabel od sieci

Najczęściej podejmowana decyzja — natychmiastowe odłączenie maszyny od sieci i wyłączenie jej — prawdopodobnie spowoduje utratę informacji cennych dla śledztwa. Bardzo wiele rootkitów zawiera istotne dane tylko w pamięci operacyjnej, zatem "położenie" komputera niszczy ich ślady. Są przypadki, gdy w celu śledztwa konieczne jest analizowanie skompromitowanej maszyny podczas jej rzeczywistej eksploatacji, wiedząc o tym, że włamywacz ma kontrolę nad pewnymi zasobami. Bywa, że samo odłączenie maszyny od sieci (przy pracującym nadal systemie operacyjnym i aplikacjach) wystarczy, by stracić możliwość analizy — są rootkity posiadające wbudowany mechanizm autodestrukcji, gdy komunikacja nie jest możliwa przez pewien czas. Dedykowany program powoduje w takich przypadkach nadpisanie używanych obszarów pamięci oraz zakończenie procesów, nadpisanie plików i zniszczenie ich. Komputer po zakończonej pracy rootkita może nie odróżniać się niczym od "zdrowej" maszyny. Szczególnie dotyczy to niektórych nowoczesnych rootkitów instalowanych w bazach danych Oracle’a i modyfikujących obszar SGA.

Gdy istnieje możliwość analizy pracującego serwera, należy koniecznie zadbać o zebranie tak wielu śladów jak to tylko możliwe. Warto natychmiast uruchomić rejestrowanie całego ruchu TCP/IP serwera do późniejszej analizy. Bardzo pomocne jest duplikowanie ruchu przy wykorzystaniu przełącznika wyposażonego w port analizujący. Można to zrobić bardzo szybko, a działanie takie jest całkowicie niewidoczne dla intruza i przynosi wiele informacji. Można w tym celu także użyć maszyny z systemem takim jak OpenBSD, skonfigurowanej jako przezroczysty most i rejestrującej przepływające dane zgodnie z ustawionymi kryteriami. Analizą przechwyconych w ten sposób danych może zająć się później zewnętrzny specjalista.

Należy przyjąć żelazną zasadę braku zaufania do wszystkich składników skompromitowanego systemu operacyjnego i hostowanych aplikacji. Instalacja dedykowanych kart do przechwytywania pamięci pracującego komputera (takich jak CoPilot firmy Komoku) przeważnie wymaga wyłączenia maszyny, zatem potencjalnie zmniejsza możliwości uzyskania danych do analiz powłamaniowych ze skompromitowanego przez nieznany rootkit serwera. Należy też pamiętać, że popularne narzędzia (m.in. Process Explorer czy FileMon w środowisku Windows) są powszechnie znane włamywaczom, zatem warto świeżym ich kopiom nadać zupełnie inne nazwy plików (explorer.exe, svchost.exe i itd.).

Było włamanie, co dalej?

Niektóre decyzje podjęte po odkryciu naruszenia bezpieczeństwa muszą być podjęte z rozwagą, gdyż mogą powodować utratę ważnych informacji potrzebnych do dokumentacji wydarzenia.

Przy ustalaniu stref zagrożeń ważne jest określenie miejsca oraz drogi ataku. Pominięcie w analizach drogi, z której naprawdę skorzystał intruz, jest poważnym błędem, bo daje potencjalnie możliwość powtórzenia ataku. Ponadto powoduje błędną ocenę sytuacji. Przykładem może być udany atak, który nastąpił ze znacznej odległości przez przełamanie zabezpieczeń sieci bezprzewodowej, zaś przyczyn szukano w błędach zapory sieciowej lub potencjalnym wpuszczeniu intruza z laptopem na teren firmy. Wówczas sieć Wi-Fi może nadal być źle zabezpieczona, a inwestycja w lepszą, kosztowną zaporę lub zwolnienie pracownika recepcji - zupełnie nieuzasadnione.

Po oznaczeniu stref i dróg należy oszacować szkody w systemie. Gdy doszło do łatwego do odkrycia uszkodzenia danych lub ataku typu DoS, jest to dość proste. Trudniej jest w przypadku modyfikacji danych. Często niełatwo jest oszacować wartość strat, nawet gdy można z grubsza określić skutki ataku. Jeśli nastąpiło zniszczenie danych, które spowodowało awarię lub przestój w pracy firmy, jest to prostsze. Przestój kosztował X zł, praca serwisu i firm zewnętrznych - Y, czas pracowników poświęcony na usuwanie skutków - Z, zatem strata spowodowana atakiem jest co najmniej sumą tych wartości. Trudniej oszacować straty spowodowane kradzieżą danych, między innymi dlatego należy starać się możliwie dokładnie opisać obszary kompromitacji systemu, by później móc dokonać szacowania wartości materialnej szkód. Jest to ważne w przypadku podejmowania późniejszych działań prawnych przeciwko sprawcom, jeśli oczywiście zostaną wykryci. Bo nawet jeśli uda się udowodnić kradzież konkretnych danych, nie tak łatwo udowodnić wpływ tej kradzieży na rzeczywiste straty firmy. Właśnie dlatego działania prawne nie zawsze są później skuteczne.


TOP 200