Alert jest początkiem analizy. Na potrzeby ćwiczenia przyjmijmy, że na testowym komputerze pojawiło się kilka nieudanych prób logowania, a później logowanie poprawne. Czy to pomyłka użytkownika, zadanie administratora, czy zdarzenie wymagające eskalacji? Sam poziom alertu nie rozstrzyga tej kwestii.
Ustal, co rzeczywiście widać
Otwórz alert w dashboardzie Wazuh i zapisz jego czas, agenta, użytkownika, źródło, identyfikator reguły oraz dostępne pola surowego zdarzenia. Następnie zawęź widok do tego samego hosta i krótkiego przedziału czasu. Wazuh udostępnia widoki zdarzeń, zarządzania agentami i moduł MITRE ATT&CK; filtruj dane według pól faktycznie obecnych w logach, bo ich zestaw zależy od źródła i konfiguracji.
Ułóż prostą oś czasu:
- Pierwsza i ostatnia nieudana próba.
- Ewentualne poprawne logowanie oraz użyte konto.
- Zdarzenia z tego samego źródła na innych hostach, jeżeli są zbierane.
- Działanie administratora lub zmiana środowiska, które mogły wyjaśnić sekwencję.
Brak zdarzeń na innym hoście nie jest dowodem, że nic się tam nie wydarzyło. Najpierw sprawdź, czy host był podłączony i czy potrzebny kanał był zbierany w analizowanym czasie.
Sprawdź kontekst przed decyzją
Porównaj oś czasu z harmonogramem prac, zgłoszeniami użytkowników i znanym użyciem konta. Jeśli zdarzenie dotyczy konta uprzywilejowanego, nieznanego źródła lub kilku urządzeń, zwiększ priorytet ręcznej weryfikacji. Jeśli istnieje wiarygodne wyjaśnienie administracyjne, udokumentuj je zamiast usuwać alert bez śladu.
Wazuh może mapować alerty do taktyk i technik MITRE ATT&CK. Takie przypisanie pomaga szukać powiązanych zdarzeń, lecz nie przesądza, że atak rzeczywiście nastąpił. Decyzja powinna wynikać z danych, kontekstu i dodatkowych ustaleń.
Karta jednej analizy
Praktyczna notatka może zmieścić się na jednej stronie: numer sprawy, czas i strefa, host, konto, źródło, ustalenia potwierdzone, dane brakujące, hipotezy, decyzja, właściciel kolejnego kroku. Jeżeli zdarzenie wymaga eskalacji, przekaż tę kartę wraz z odnośnikami do oryginalnych danych. Jeżeli zostaje zamknięte, zapisz przyczynę i warunek ponownego otwarcia, na przykład powtórzenie sekwencji na innym urządzeniu.
Rekomendacja praktyczna: przećwicz ten przebieg na uzgodnionym koncie testowym. Mierz, ile czasu zajmuje znalezienie pierwszego zdarzenia i czy operator może odtworzyć tok rozumowania po tygodniu. Dzięki temu sprawdzisz zarówno źródła logów, jak i użyteczność procedury.
Ta analiza zamyka serię: po instalacji, doborze źródeł, ocenie konfiguracji i strojeniu reguł mamy proces przejścia od alertu do decyzji. Powiązane obszary, takie jak FIM i Active Response, można dołączać do podobnych scenariuszy dopiero po ustaleniu celu i zakresu monitoringu.