PROBLEM
SIEM zainstalowany, a analityk nie wie, skąd wziął się alert i jak go odtworzyć.
PODEJŚCIE
Zrozumieć i udokumentować drogę: endpoint → agent → parser → reguła → alert.
ARCHITEKTURA
- Wazuh manager w labie
- agenci na Windows i Linux
- kilka reguł z jawnym testem
WDROŻENIE
- instalacja w labie
- pierwsze logi z endpointu
- jedna reguła z testem pozytywnym i fałszywym tropem
REZULTAT
- opis pipeline w docs i na blogu
- szablon przeglądu reguły jako zasób
- brak metryk „MTTD klienta” — tego nie ma
WNIOSKI
- reguła bez testu to ozdoba
- alert ≠ incydent
Cel
Wazuh w tym portfolio to laboratorium SIEM: ma pokazać, jak powstaje alert, nie że „wdrożyłem Wazuh w firmie X”.
Dwa problemy, które rozwiązałem
1. Alert bez ścieżki wstecz
Miałem zielony dashboard i zero pewności, czy alert wynika z reguły, z dekodera, czy z szumu. Nie dało się go powtórzyć.
Co zyskałem: udokumentowaną drogę endpoint → agent → parser → reguła → alert. Potrafię wskazać, który plik reguły i które pole w logu decydują o trafieniu — albo o odrzuceniu.
2. Reguły „na oko”
Dokładałem detekcje bez testu pozytywnego i bez fałszywego tropu. Po tygodniu nie wiedziałem, które reguły są martwe.
Co zyskałem: nawyk jednej reguły z jawnym testem (hit / miss) oraz szablon przeglądu reguły. Alert traktuję jako hipotezę do weryfikacji, nie jako wyrok.
Co ćwiczę w labie
- instalacja managera i agentów Windows/Linux w izolacji,
- pierwsze Event Logi i syslog w indeksie,
- jedna reguła z mapowaniem ATT&CK tylko gdy log pokrywa technikę,
- notatka: true positive, false positive, escalate, ignore.
Powiązane materiały
Granice
To nie monitoring klienta, nie KPI MTTD/MTTR z produkcji i nie certyfikowane wdrożenie enterprise.
Stan
Status development. Manager, agenci i kilka scenariuszy są w toku. Nie publikuję zrzutów z cudzych środowisk.