Raport powłamaniowy

Raport powłamaniowy dokumentuje przebieg incydentu, wykorzystane luki i podjęte działania naprawcze.

Cel i zakres raportu powłamaniowego

Raport powłamaniowy jest technicznym zapisem incydentu bezpieczeństwa, przygotowywanym po opanowaniu nieautoryzowanego dostępu do komputera, serwera, konta lub aplikacji. Jego celem jest odtworzenie przebiegu zdarzeń na podstawie dostępnych dowodów, a nie samo opisanie objawów zauważonych przez użytkownika. Raport powinien wskazywać, kiedy wykryto problem, jaki zasób został zaatakowany, w jaki sposób napastnik uzyskał dostęp, jakie działania wykonał po zalogowaniu oraz kiedy zakończono incydent. Jeżeli dokładnego momentu zdarzenia nie można ustalić, należy podać przedział czasowy i wyraźnie zaznaczyć, że jest to wartość szacunkowa.

Zakres dokumentu obejmuje również systemy powiązane z zaatakowanym urządzeniem. W przypadku komputera z systemem Windows analizuje się między innymi dzienniki logowania, zdarzenia uruchamiania procesów, zadania harmonogramu, usługi, reguły zapory i historię zmian kont. W systemach Linux istotne mogą być logi uwierzytelniania, historia użycia sudo, procesy, usługi systemd oraz zmiany w plikach konfiguracyjnych. Raport powinien rozdzielać fakty potwierdzone dowodami od hipotez. Stwierdzenie „plik został pobrany” wymaga konkretnego śladu, na przykład wpisu w logu, historii przeglądarki, zdarzenia procesu lub kopii pliku; sama obecność podejrzanego pliku nie dowodzi jeszcze sposobu jego dostarczenia.

Odtworzenie przebiegu zdarzeń

Najważniejszą częścią raportu jest chronologia incydentu. Powinna zawierać kolejno: pierwszą obserwację nietypowego działania, prawdopodobny początek uzyskania dostępu, wykonane operacje, wykrycie naruszenia, odcięcie napastnika i działania przywracające prawidłowy stan. Wszystkie czasy trzeba sprowadzić do jednej strefy czasowej albo zapisać razem z informacją o strefie. Należy uwzględnić różnice między czasem systemowym komputera, czasem serwera logów i czasem urządzeń sieciowych. Błędny zegar może przesunąć zdarzenia i prowadzić do nieprawidłowych wniosków o kolejności działań.

Opis techniczny powinien identyfikować konta, adresy IP, nazwy hostów, identyfikatory procesów, ścieżki plików, porty oraz użyte mechanizmy dostępu, o ile dane te są dostępne. Warto odnotować, czy logowanie nastąpiło lokalnie, przez usługę zdalnego pulpitu, SSH, panel administracyjny, VPN albo aplikację internetową. Należy również wskazać czynności wykonane na urządzeniu, takie jak utworzenie nowego konta, dodanie konta do grupy uprzywilejowanej, zmiana konfiguracji zapory, instalacja usługi, pobranie programu lub modyfikacja zadania automatycznego. Jeżeli nie ma dowodu na wykonanie określonej operacji, raport powinien używać sformułowań „nie potwierdzono” albo „brak danych”, zamiast przedstawiać przypuszczenie jako fakt.

Dowody, zakres naruszenia i analiza przyczyny

Dowody należy zabezpieczać tak, aby późniejsza analiza nie zmieniła ich treści. Dotyczy to logów, obrazów dysków, kopii podejrzanych plików, zrzutów pamięci, konfiguracji systemu oraz eksportów z urządzeń sieciowych. Dla plików dowodowych można obliczyć skrót SHA-256 i zapisać go razem z nazwą pliku, datą pozyskania, źródłem oraz osobą wykonującą kopię. Taki skrót nie szyfruje danych i nie zastępuje kopii dowodowej, ale pozwala sprawdzić, czy zawartość pliku zmieniła się po zebraniu materiału. Oryginalne logi powinny być przechowywane oddzielnie od kopii roboczych używanych do filtrowania i sortowania.

Raport powinien określać, jakie zasoby mogły zostać odczytane, zmienione, usunięte lub wykorzystane do dalszego ruchu w sieci. Trzeba sprawdzić nie tylko urządzenie, na którym wykryto incydent, lecz także inne hosty korzystające z tego samego konta, klucza, hasła, udziału sieciowego lub mechanizmu zdalnego dostępu. Analiza przyczyny powinna wskazywać konkretny czynnik umożliwiający włamanie, na przykład niezałatany komponent, ujawnione dane uwierzytelniające, błędną regułę dostępu, złośliwy załącznik albo usługę wystawioną do Internetu. Samo usunięcie pliku lub odinstalowanie podejrzanego programu nie jest dowodem usunięcia przyczyny; konieczne jest sprawdzenie kont, kluczy, harmonogramów, usług i sposobów ponownego wejścia.

Działania naprawcze i wnioski techniczne

W raporcie należy oddzielić działania wykonane natychmiast od zmian zaplanowanych na później. Do czynności doraźnych może należeć odłączenie urządzenia od sieci, zablokowanie konkretnego konta, unieważnienie kluczy dostępu, zamknięcie wskazanego portu i zabezpieczenie kopii logów. Przywracanie systemu powinno odbywać się z wiarygodnego źródła, a nie przez bezwarunkowe przywrócenie plików z urządzenia, którego integralność jest kwestionowana. Po zmianie haseł trzeba uwzględnić także zapisane poświadczenia, tokeny sesyjne, klucze SSH, certyfikaty i inne mechanizmy umożliwiające dostęp bez wpisywania hasła.

Końcowa część dokumentu powinna zawierać wyniki weryfikacji po naprawie. Należy sprawdzić, czy usunięto nieautoryzowane konta i usługi, czy nie pozostały podejrzane zadania automatyczne, czy poprawki zostały zainstalowane oraz czy logowanie i monitorowanie rejestrują zdarzenia potrzebne do wykrycia powtórki. Wnioski powinny być konkretne: wskazywać zmianę konfiguracji, dodatkowe źródło logów, częstotliwość aktualizacji, zakres przeglądu uprawnień albo sposób testowania kopii zapasowych. Dobrze sporządzony raport pozwala odtworzyć decyzje podjęte podczas incydentu, ograniczyć ryzyko ponownego włamania i szybciej rozpoznać podobne zdarzenie w przyszłości.