Umiejętności analityka SOC: co trzeba znać

Najważniejsze umiejętności analityka SOC to triage alertów, interpretacja logów, analiza ruchu, zapytania SIEM, korelacja encji, threat hunting, detection engineering, Incident Response i jasne raportowanie. Narzędzia pomagają wykonać te zadania, ale sama znajomość Splunka, Sentinela czy Wiresharka nie dowodzi jeszcze, że analityk potrafi podjąć bezpieczną decyzję.

Poniższa macierz pokazuje, czego warto się uczyć, jak mierzyć postęp i gdzie poszczególne kompetencje znajdują się w bezpłatnej Ścieżce Analityka SOC.

Umiejętności analityka SOC w skrócie

Dobry analityk powinien potrafić:

odróżnić log, zdarzenie, alert, finding i incydent;
ustalić priorytet na podstawie wpływu, krytyczności i pewności;
zbudować oś czasu dla użytkownika, hosta, procesu i połączenia;
ocenić zdrowie telemetrii przed wykluczeniem aktywności;
tworzyć małe, czytelne zapytania SIEM;
analizować Windows, Active Directory, Linux, sieć i cloud;
testować hipotezy huntingowe i jakość detekcji;
proponować proporcjonalny containment oraz recovery;
komunikować fakty, niewiadome, ryzyko i następny krok;
uczyć się nowych domen bez mylenia nazwy narzędzia z kompetencją.

NICE Workforce Framework opisuje cyberpracę przez zadania, wiedzę i obserwowalne umiejętności. To lepszy model rozwoju niż lista certyfikatów: pytanie brzmi nie „czy znam SIEM?”, lecz „czy potrafię użyć danych do wykonania konkretnego zadania?”.

Macierz kompetencji SOC: zadanie, narzędzie i dowód

Poniższe umiejętności analityka SOC są powiązane z zadaniem, narzędziem i obserwowalnym dowodem:

Kompetencja	Typowe narzędzia lub źródła	Dowód opanowania
Triage alertów	SIEM, EDR, ticketing, CMDB	decyzja z wpływem, pewnością i ownerem
Logi Windows	Event Viewer, WEF, Sysmon, EDR	timeline logowanie–proces–sieć
Analiza sieci	Wireshark, tshark, Zeek, DNS logs	opis rozmówców, protokołu i ograniczeń
SIEM i korelacja	Splunk, Sentinel, Elastic	query od surowego eventu do encji
Threat hunting	SIEM, EDR, ATT&CK	hipoteza, dowód za/przeciw, luka
Detection engineering	Sigma, YARA, repozytorium Git	reguła z testami i false positives
Incident Response	case management, EDR, IAM	plan containmentu, rollback i recovery
Forensics	timeline, artefakty hosta, hashe	manifest dowodów i jawne ograniczenia
Cloud i SaaS	audit logs, IAM, control plane	scope principal–resource–action
Komunikacja	raport, decision log, handover	zapis możliwy do odtworzenia przez zmianę

Narzędzie jest przykładem realizacji zadania, nie celem samym w sobie. Firma może używać innego stacku, ale nadal potrzebuje tych samych rezultatów analitycznych.

1. Triage alertów i priorytetyzacja

Triage odpowiada na pytanie, co należy zrobić teraz. Severity reguły jest tylko jednym sygnałem. Priorytet zależy również od krytyczności zasobu, tożsamości, możliwego wpływu, ekspozycji, pewności detekcji i aktywnych kontroli.

Podstawowe umiejętności analityka SOC w triage to:

odczytanie dokładnej logiki alertu;
sprawdzenie czasu, źródła i kompletności pól;
identyfikacja konta, hosta, procesu, zasobu i sesji;
porównanie z legalną administracją oraz change window;
rozdzielenie false positive, benign true positive i real threat;
wskazanie dowodu, który może zmienić ocenę.

Silny analityk nie zamyka alertu komentarzem „użytkownik potwierdził”. Zapisuje, co użytkownik potwierdził, z czym to porównano i czego nadal nie wiadomo.

2. Logi, czas i jakość telemetrii

Negatywny wynik wyszukiwania ma wartość tylko wtedy, gdy źródło działało. Trzeba rozumieć audit policy, forwarding, parser, retencję, opóźnienie, pokrycie populacji i synchronizację czasu.

Przykład małego sprawdzenia syntetycznych danych:

jq -r '.sources[] | [.name,.coverage_pct,.last_event,.parser_status,.retention_days] | @tsv' telemetry/health.json

Reprezentatywny wynik:

windows-security 98.4 10:14:02 healthy 30
sysmon 81.2 10:13:58 delayed 14

Brak procesu w Sysmon nie wyklucza wykonania na 18,8% hostów poza pokryciem. Umiejętność opisania takiej granicy jest równie ważna jak samo query.

3. Windows, Active Directory i Linux

W środowisku Windows ucz się relacji między logowaniem, tokenem, procesem, usługą, taskiem, PowerShellem, połączeniem i zmianą uprawnień. W Active Directory analizuj principal, obiekt docelowy, kontroler domeny, protokół, delegację oraz blast radius zmiany.

Na Linuxie potrzebujesz procesów, systemd, journalctl, kont, sudo, SSH, cron, plików, pakietów i auditd. Nie chodzi o zapamiętanie wszystkich Event ID lub poleceń. Chodzi o wybór źródła, które widzi daną hipotezę, oraz o rozpoznanie, czego nie potwierdza.

4. Analiza ruchu sieciowego

Analityk SOC powinien rozumieć DNS, HTTP, TLS, SMB i podstawowe cechy sesji TCP/UDP. Wireshark pomaga zobaczyć pakiety, a tshark pozwala powtarzalnie filtrować przygotowany PCAP:

tshark -r evidence/traffic.pcapng -Y 'dns || http || smb2' \
  -T fields -e frame.time -e ip.src -e ip.dst -e _ws.col.Protocol -e _ws.col.Info

Nietypowa częstotliwość połączeń może pasować do beaconingu, ale także do monitoringu lub błędnej aplikacji. Analiza musi połączyć rytm z destination, DNS, procesem, tożsamością hosta i kontekstem biznesowym.

5. Zapytania SIEM i korelacja

Najlepsza kolejność to: surowy event, poprawne pola, mały filtr, agregacja, a dopiero potem korelacja. Każde zapytanie powinno mieć:

hipotezę i zakres czasu;
źródło oraz stan jego zdrowia;
stabilne encje: user, host, process, IP, session, resource;
jawne założenia dotyczące strefy czasowej i normalizacji;
reprezentatywny wynik oraz sposób walidacji.

Jeśli zastanawiasz się, czym różnią się warstwy platform, przeczytaj SIEM vs XDR vs EDR. Do nauki wybierz jeden język — SPL, KQL albo ES|QL — ale oceniaj kompetencję po jakości pytania i interpretacji, nie liczbie zapamiętanych funkcji.

6. Threat hunting i MITRE ATT&CK

Hunting zaczyna się od hipotezy: „jeżeli zachowanie X wystąpiło, źródła A i B powinny zawierać pola Y i Z”. Następnie analityk szuka dowodów potwierdzających oraz obalających, aktualizuje zakres i dokumentuje visibility gaps.

MITRE ATT&CK pomaga uporządkować zachowania przeciwnika. Nie jest checklistą gwarantującą pokrycie. Reguła przypisana do techniki może nie działać, jeśli brakuje źródła, parser zmienił pole albo legalna automatyzacja generuje ten sam wzorzec.

7. Detection engineering: Sigma, YARA i testy

Umiejętność napisania YAML nie wystarcza. Detekcja potrzebuje ownera, wersji, wymaganego logsource, testów pozytywnych i negatywnych, znanych false positives, playbooka triage oraz metryk jakości.

Sigma Rules Specification oddziela logikę reguły od backendu. Translacja do konkretnego SIEM nadal wymaga sprawdzenia mapowania pól i operatorów. YARA służy do opisu cech treści lub plików, ale pojedynczy string bez kontekstu często tworzy kruchą detekcję. Pełny cykl opisujemy w poradniku Detection engineering i Sigma.

8. Incident Response i digital forensics

Incident Response wymaga scope, priorytetu, authority modelu i bezpiecznej kolejności działań. Izolacja hosta może ograniczyć atak, ale może też przerwać krytyczny proces. Reset hasła bez unieważnienia sesji może zostawić aktywny dostęp. Każda akcja potrzebuje właściciela, akceptacji, wpływu i rollbacku.

NIST SP 800-61 Rev. 3 osadza response w szerszym zarządzaniu ryzykiem. Forensics wspiera decyzję przez artefakty, timeline, integralność kopii i udokumentowane luki — nie przez kolekcjonowanie wszystkiego bez pytania.

9. Cloud, kontenery, supply chain, OT i AI

Współczesny SOC wychodzi poza endpoint i firewall. Analityk powinien umieć rozwinąć znany model principal–resource–action–result na:

cloud control plane, tokeny i role workloadów;
Kubernetes audit, service accounts i runtime;
repozytorium, pipeline, provenance, artefakt i deployment;
OT/ICS, gdzie safety i operations authority mają pierwszeństwo;
system AI: model, retrieval, pamięć, policy engine, narzędzia i akcje.

Nie każdy junior będzie obsługiwać wszystkie domeny. Warto jednak rozumieć granice i wiedzieć, kiedy eskalować do właściciela procesu.

10. Komunikacja, handover i jakość sprawy

Raport analityka jest interfejsem decyzyjnym. Powinien zawierać fakty, hipotezy, zakres, oś czasu, dowody, niewiadome, działania, ownerów i następny termin. Handover musi powiedzieć także, czego nie wykonano.

Ta kompetencja jest często niedoceniana, choć bez niej dobra analiza nie przechodzi na kolejną zmianę ani do incident commandera. Język powinien kalibrować pewność: „potwierdzono”, „oceniamy z umiarkowaną pewnością” i „brak dowodu” oznaczają inne rzeczy.

Jak ocenić własny poziom bez zgadywania

Aby uczciwie ocenić umiejętności analityka SOC, dla każdej kompetencji przygotuj jeden artefakt na syntetycznych lub legalnie udostępnionych danych. Poproś drugą osobę, by odtworzyła Twoją decyzję bez dodatkowego wyjaśnienia. Sprawdź:

czy źródło i czas są jawne;
czy fakt jest oddzielony od hipotezy;
czy wskazujesz alternatywne wyjaśnienie;
czy wynik odpowiada na pytanie, a nie tylko pokazuje narzędzie;
czy containment jest proporcjonalny;
czy ograniczenia zmieniają poziom pewności.

Jeżeli nie wiesz, w jakiej kolejności budować te artefakty, zobacz plan nauki: jak zostać analitykiem SOC oraz opis programu kurs SOC Analyst po polsku.

Najczęstsze błędy w rozwijaniu kompetencji SOC

Tool collecting — pięć pobieżnie poznanych SIEM zamiast jednego dobrze rozumianego.
Event ID bez semantyki — numer bez perspektywy źródła, pól i wersji.
ATT&CK jako werdykt — technika przypisana po podobnej nazwie procesu.
Brak testu negatywnego — reguła wykrywa scenariusz, ale także całą legalną administrację.
Automatyczny containment — playbook wykonuje akcję bez authority i warunków stop.
Portfolio bez wniosków — same screenshoty, bez query, czasu, ograniczeń i rekomendacji.

FAQ: umiejętności i narzędzia analityka SOC

Jakie narzędzie SIEM warto poznać jako pierwsze?

Wybierz platformę, do której masz legalny dostęp i dobre materiały. Splunk, Microsoft Sentinel oraz Elastic uczą podobnych operacji analitycznych, choć mają inne języki i modele danych.

Czy Wireshark jest potrzebny analitykowi SOC?

Tak, przynajmniej na poziomie filtrów, protokołów i interpretacji sesji. Nie każdy alert wymaga PCAP, ale podstawy sieci pomagają oceniać DNS, C2, lateral movement i wyciek danych.

Jakie języki skryptowe są przydatne?

Bash i PowerShell pomagają pracować z systemami, a Python z analizą oraz automatyzacją. Na początku ważniejsze od dużych aplikacji są małe, czytelne skrypty, które nie niszczą dowodów.

Czy trzeba znać wszystkie Event ID Windows?

Nie. Poznaj kluczowe rodziny zdarzeń i naucz się sprawdzać dokumentację. Ważniejsza jest perspektywa logu, konfiguracja audytu, pola, wersja systemu oraz korelacja z hostem i identity.

Jak rozwijać umiejętności analityka SOC po poziomie L1?

Przejdź od disposition pojedynczego alertu do scope wielu źródeł, utrzymania detekcji, huntingu, forensics i prowadzenia decyzji. Wybierz jedną domenę pogłębioną, ale zachowaj szerokie podstawy.

Zbuduj kompetencje w logicznej kolejności

Ścieżka Analityka SOC mapuje te umiejętności na 32 moduły — od triage i telemetrii po AI, OT oraz finałowy capstone. Każdy moduł kończy quiz, a przykłady pokazują nie tylko polecenie, lecz także reprezentatywny wynik i granice wniosku.

Rozpocznij bezpłatną Ścieżkę Analityka SOC i zamieniaj kolejne tematy w obronione artefakty wiedzy.

Źródła: NIST NICE Framework, MITRE ATT&CK, Sigma Specification, NIST SP 800-61 Rev. 3.