Cyberbezpieczeństwo • case study
Incydent w firmie: jak połączyć logi, komputer i dane aplikacji w jedną analizę
Metodyczny przykład analizy incydentu: źródła danych, oś czasu, alternatywne hipotezy i zakres opinii dla firmy z Krakowa lub Małopolski.
Najpierw pytanie badawcze, potem wybór źródeł
Firma może zauważyć nietypowe logowanie, zniknięcie pliku albo wysłanie wiadomości bez wiedzy pracownika. Każdy z tych objawów uzasadnia inne pytania. Techniczna analiza powinna określić, jakie zdarzenie jest badane, jaki okres obejmuje i jakie dane są dostępne. Ogólne polecenie „sprawdzić, czy był atak” łatwo prowadzi do raportu, którego zakres jest trudny do oceny.
NIST SP 800-86 omawia oddzielnie dane systemów operacyjnych, ruchu sieciowego i aplikacji oraz ich wspólne wykorzystanie. Dokument ma perspektywę reagowania na incydenty IT; nie zastępuje polskiej podstawy prawnej do pozyskania konkretnego materiału. [1, rozdz. 5–8]
Case study: logowanie nocne i plik w katalogu pobrań
Scenariusz hipotetyczny: organizacja z Małopolski dostrzega nocne logowanie do konta, a na komputerze znajduje plik związany z danymi kontrahentów. Na tym etapie nie wiadomo, czy doszło do przejęcia konta, działania uprawnionego użytkownika, automatycznej synchronizacji czy innego zdarzenia. Lokalizacja pliku i godzina logowania to dwie obserwacje, które trzeba dopiero powiązać.
Proponowany plan obejmuje weryfikację źródła logowania, rodzaju operacji zapisanej przez usługę, dostępnego kontekstu sesji oraz śladów na komputerze. Osobno należy ustalić, czy plik był pobrany, otwierany lub przesyłany — i jakie źródło pozwala odpowiedzieć na każde z tych pytań. Ustalenia nie powinny wykraczać poza to, co rzeczywiście zachowano.
Oś czasu wymaga wspólnego odniesienia
Łączenie zdarzeń zaczyna się od sprawdzenia znaczenia czasu w każdym źródle. Trzeba rozróżnić czas zdarzenia od czasu zapisu, przetworzenia i eksportu. Równie istotna jest strefa czasowa oraz dostępne informacje o ustawieniach zegara. Bez tego pozorna kolejność może wynikać ze sposobu prezentacji, a nie z następstwa czynności.
Proponowana tabela robocza zawiera czas oryginalny, źródło, znaczenie pola, regułę normalizacji i czas prezentowany we wspólnej osi. Oryginalnych wartości nie należy zastępować samymi przeliczeniami. Jeżeli niepewności nie da się usunąć, warto pokazać przedział lub opisać ograniczenie, zamiast prezentować pozorną precyzję co do sekundy.
Korelacja nie oznacza jeszcze przypisania osobie
Konto, urządzenie, adres sieciowy i człowiek to różne poziomy opisu. Nawet zgodne ślady aktywności konta nie wyjaśniają automatycznie, kto faktycznie korzystał z jego dostępu. Ustalenie odpowiedzialności wymaga uwzględnienia kontekstu organizacyjnego i innych dowodów. W technicznej opinii należy jasno oddzielić stwierdzoną aktywność od hipotezy dotyczącej osoby.
Przydatna jest macierz hipotez: dla każdej wersji wskazuje się obserwacje wspierające, obserwacje sprzeczne i brakujące informacje. Ma ona przeciwdziałać selekcji wyłącznie tych danych, które pasują do pierwszego podejrzenia. Nie musi prowadzić do jednej odpowiedzi; czasem prawidłowym wynikiem jest określenie, jakiego dodatkowego materiału potrzeba.
Co przygotować do rozmowy o incydencie?
W pierwszym kontakcie warto podać rodzaj środowiska, czas zauważenia problemu, działania podjęte przez administratora oraz zakres dostępnych logów i kopii. Nie należy przesyłać przez formularz haseł, tokenów dostępu ani całych baz klientów. Zakres dostępu i sposób przekazania danych trzeba ustalić przed badaniem.
Przegląd NIST zwraca uwagę, że znaczenie artefaktów może zmieniać się wraz z wersjami oprogramowania. To uzasadnia odnotowanie środowiska i ograniczeń interpretacji również wtedy, gdy zdarzenie wygląda znajomo. [2, Executive Summary] Dla firm z Krakowa, Tarnowa, Nowego Sącza i innych miejscowości dostępna jest informacja o organizacji zleceń w Małopolsce. Sam przykład nie jest opisem rzeczywistego incydentu klienta.
Źródła i literatura
- Kent, K.; Chevalier, S.; Grance, T.; Dang, H. (2006). Guide to Integrating Forensic Techniques into Incident Response. NIST SP 800-86, rozdz. 5, 6 i 7 oraz rozdz. 8, s. 8-1–8-5. DOI: 10.6028/NIST.SP.800-86.
- Lyle, J. R.; Guttman, B.; Butler, J. M.; Sauerwein, K.; Reed, C.; Lloyd, C. E. (2022). Digital Investigation Techniques: A NIST Scientific Foundation Review. NIST IR 8354, Executive Summary. DOI: 10.6028/NIST.IR.8354.
Linki i przywołane miejsca sprawdzono 18 października 2026 r. Numer strony oznacza paginację publikacji; dokumentacja internetowa bez paginacji jest wskazana przez nazwę sekcji. Przykłady są scenariuszami edukacyjnymi, nie opisami spraw klientów.