OSDA i SOC-200: analiza logów, SIEM i raportowanie

OSDA i SOC-200 rozwijają praktyczną analizę działań atakującego w SIEM. Od września 2025 egzamin używa wcześniej zarejestrowanych logów, aby zapewnić stabilne środowisko. Kandydat ma 23 godziny i 45 minut na dziesięć faz, a następnie 24 godziny na raport.

Co trzeba wykazać

Każda faza zawiera działania takie jak enumeracja, brute force, lateral movement, privilege escalation lub persistence. Zadaniem jest wykryć je, zrozumieć i opisać poziom dostępu napastnika.

Nie wystarczy screenshot alertu. Raport powinien zawierać query, zakres czasu, źródło danych, evidence i wniosek. Analityk musi odróżnić fakt z logu od hipotezy.

Workflow dochodzenia

1. Ustal oś czasu i systemy źródłowe.
2. Zidentyfikuj pierwszą anomalię.
3. Pivotuj po użytkowniku, hoście, IP i procesie.
4. Powiąż zdarzenia w technikę ataku.
5. Określ uzyskany dostęp oraz następny możliwy krok.
6. Zachowaj query i screenshot z kontekstem.

Twórz małe zapytania, a dopiero potem łącz je w korelację. Zbyt szeroki query ukrywa kolejność i generuje przypadkowe dopasowania.

Przygotowanie

Ćwicz Windows Event Logs, Sysmon, uwierzytelnianie, PowerShell, procesy, sieć i Active Directory. Dla każdej techniki zapisz wymagane źródło oraz ograniczenia detekcji.

OSDA jest dobrym uzupełnieniem ofensywy: pokazuje, jakie artefakty zostawia operator. Połącz naukę z purple teamingiem i cyklem Cyber Threat Intelligence.

Dochodzenie oparte na osi czasu

Najpierw ustal zakres czasu, hosty i tożsamości związane z pierwszym wiarygodnym sygnałem. Potem buduj oś czasu od zdarzeń o wysokiej wartości: logowania, tworzenia procesów, uruchomienia PowerShell, zmian usług, zadań harmonogramu i połączeń sieciowych. Pojedynczy event rzadko opisuje cały incydent; wartość powstaje z korelacji źródła, celu, użytkownika i kolejności.

Rozszerzaj okno czasowe stopniowo. Zbyt szerokie zapytanie na początku tworzy szum, a zbyt wąskie może ukryć przygotowanie lub persistence. Każdy filtr zachowuj wraz z założeniem, które miał sprawdzić. Jeżeli źródło nie rejestruje wymaganego pola, zaznacz ograniczenie zamiast dopowiadać brakujący fakt.

Jakość zapytań i dowodów

Dobre zapytanie jest czytelne, możliwe do ponownego uruchomienia i ogranicza wynik przez konkretne pola. Zacznij od surowego zdarzenia, sprawdź nazwy pól i dopiero potem dodawaj agregację. W raporcie pokaż query, zakres czasu, najważniejsze rekordy oraz interpretację. Zrzut wykresu bez zapytania i kontekstu nie jest pełnym dowodem.

Oddziel obserwację od oceny. „Proces A uruchomił proces B o 10:14” jest faktem z telemetrii. „Atakujący wykonał lateral movement” jest wnioskiem wymagającym dodatkowych zdarzeń i wyjaśnienia. Taki język poprawia wiarygodność raportu i ułatwia wskazanie luk telemetrycznych.

Plan nauki analityka

Buduj własny katalog małych detekcji dla uwierzytelniania, wykonania kodu, persistence, credential access i ruchu między hostami. Dla każdej zapisz wymagane źródło, kluczowe pola, potencjalne fałszywe alarmy i sposób walidacji. Następnie łącz po dwie lub trzy detekcje w scenariusze, zamiast od razu tworzyć jedno bardzo złożone zapytanie.

Gotowość oznacza, że potrafisz przejść od alertu do osi czasu, wskazać potwierdzone działania, opisać wpływ i zaproponować dodatkowe dane potrzebne do zamknięcia luk. To właśnie odróżnia analizę incydentu od mechanicznego wyszukiwania IOC.

Checklista raportu analitycznego

Każdy opisany etap powinien zawierać źródło logu, dokładny zakres czasu, host, konto, identyfikator zdarzenia lub pole oraz zapytanie użyte do odnalezienia danych. Jeżeli czas pochodzi z kilku stref lub systemów, ujednolić go i zaznaczyć przyjętą strefę. Bez tego kolejność może wyglądać poprawnie tylko pozornie.

W części wnioskowej oddziel initial access, execution, persistence, credential access, lateral movement i impact tylko wtedy, gdy telemetria rzeczywiście wspiera taki podział. Brak danych oznacz jako lukę widoczności. Nie dopisuj techniki ATT&CK wyłącznie na podstawie podobnej nazwy procesu; mapowanie powinno wynikać z zachowania.

Na końcu przedstaw działania krótkoterminowe, takie jak izolacja konta lub hosta, oraz poprawki długoterminowe: dodatkowe logowanie, retencja, korelacja i tuning reguł. Każda rekomendacja powinna odpowiadać konkretnej luce ujawnionej przez dochodzenie.

Po zakończeniu spróbuj odtworzyć oś czasu wyłącznie z raportu. Jeżeli musisz wracać do prywatnych zakładek SIEM, brakuje zapytania, zakresu lub kontekstu. Taki sam przegląd wykonaj dla wniosków: każdy powinien wskazywać dowody, stopień pewności i dane potrzebne do pełnego potwierdzenia.

---

Źródła: OffSec OSDA Exam Guide, OSDA Exam FAQ.