PROBLEM
Dashboard SIEM bez dyscypliny analityka: alerty zamykane bez notatki albo eskalowane bez faktów.
PODEJŚCIE
Powtarzalny warsztat Security Analyst: intake alertu, weryfikacja telemetrii, klasyfikacja TP/FP, mapowanie ATT&CK i notatka eskalacyjna.
ARCHITEKTURA
- źródło alertu (Wazuh / Event Log z labu SOC)
- szablon triage (pola obowiązkowe)
- mapa ATT&CK tylko przy pokryciu w logu
- Wynik: escalate / watch / false positive / benign true positive
WDROŻENIE
- checklista pól pierwszej notatki
- ćwiczenia TP vs FP na tych samych regułach
- przegląd reguły detekcji po serii FP
- powiązanie z IR gdy decyzja = escalate
REZULTAT
- portfolio dowodzące kompetencji SA (triage + detekcja)
- Powiązane zasoby: Event Log, IR, przegląd reguły Wazuh
- nawyk notatki przed zamknięciem alertu
WNIOSKI
- alert bez kontekstu hosta/konta/czasu jest bezużyteczny
- FP to sygnał do poprawy reguły, nie do wstydu
Cel
Ten projekt zbiera kompetencje typowe dla Security Analyst (L1/L2): czytam alert, sprawdzam telemetrię, klasyfikuję, mapuję technikę tylko gdy log na to pozwala, piszę notatkę, którą da się eskalować. To nie jest tytuł na LinkedIn — to warsztat z dowodem pracy w labie.
Dwa problemy, które rozwiązałem
1. Alert zamykany bez śladu decyzyjnego
Wiedziałem „co kliknąć w SIEM”, ale po tygodniu nie dało się odtworzyć, dlaczego alert uznano za FP albo eskalowano. Brakowało pól obowiązkowych.
Co zyskałem: szablon pierwszej notatki (host, konto, czas ze strefą, źródło reguły, artefakty, decyzja, braki). Ćwiczę go na alertach z SOC Home Lab i Wazuh. To ten sam nawyk, którego wymaga kolejka SA.
2. False positive traktowane jak porażka zamiast jak sygnał detekcji
Gdy reguła „hałasowała”, albo ją wyłączałem, albo ignorowałem alerty. Żadne z tego nie poprawia detekcji.
Co zyskałem: pętlę FP → przegląd reguły → test hit/miss z szablonem przeglądu Wazuh. Rozróżniam: false positive, benign true positive, true positive → escalate. ATT&CK dopisuję dopiero przy pokryciu w logu — nie „na siłę”.
Co pokazuje predyspozycje do Security Analyst
| Kompetencja SA | Jak ćwiczę to w labie |
|---|---|
| Triage pod presją czasu | Scenariusz z zegarem: 10–15 min na pierwszą notatkę |
| Czytanie telemetrii Windows/Linux | Ściąga Event Log, syslog, alert Wazuh |
| Klasyfikacja TP/FP | Te same reguły, różne bodźce (admin vs podejrzane) |
| Detection hygiene | Przegląd reguły po serii FP, test odtworzeniowy |
| Eskalacja jakościowa | Notatka zgodna z checklistą IR |
| Kontekst ATT&CK | Tylko gdy Event ID / log pokrywa technikę |
Przebieg jednego ćwiczenia
- Intake — ID alertu, reguła, host, użytkownik, timestamp.
- Kontekst — czy host/konto są laboratoryjne, czy bodziec był zamierzony.
- Weryfikacja — surowy log / powiązane Event ID; czy da się odtworzyć zdarzenie.
- Klasyfikacja — TP / BTP / FP / potrzeba danych.
- ATT&CK — opcjonalnie, z uzasadnieniem w telemetrii.
- Decyzja — close z uzasadnieniem, watch, albo escalate do ścieżki IR.
- Detekcja — jeśli FP powtarzalny → ticket na regułę (nie tylko „ignore forever”).
Przykładowe scenariusze labu
- nieudane logowania Windows (4625) vs udane z nowego źródła (4624),
- nowa usługa / scheduled task jako sygnał persistence,
- alert Wazuh z jawnym testem pozytywnym i fałszywym tropem,
- „hałaśliwa” reguła → przegląd i zawężenie (nie ślepe wyłączenie).
Powiązane materiały
- SOC Home Lab
- Wazuh SIEM
- Incident Response Lab
- Pierwsza notatka po alercie
- Logi Windows pod SOC
- Architektura labu SOC L1
Granice
Lab na własnych hostach. Bez danych klientów, bez obietnicy „gotowy SOC L2 z certyfikatem”, bez monitoringu cudzej produkcji. Rola SA w firmie wymaga jeszcze procedur org, narzędzi ticketingowych i mentoringu — tu pokazuję fundament analityczny.
Stan
Status active: warsztat rośnie razem z labem SOC/Wazuh. Ten wpis jest kotwicą portfolio pod rozmowy o stanowisku Security Analyst.