Roadmapa do roli Security Analyst: laby, certy i pierwsze case’y

Cel czytelnika: realistyczna droga do pierwszego stanowiska Security Analyst

Celem jest ułożenie konkretnej, wykonalnej roadmapy do roli Security Analyst (głównie w SOC/Blue Team), tak aby po kilku miesiącach systematycznej pracy mieć: działający homelab, przerobione praktyczne laby, sensownie dobrane certyfikaty oraz pierwsze udokumentowane case’y do pokazania na rozmowie rekrutacyjnej.

Chodzi o przejście od „lubię cyber, oglądam filmiki” do „umiem zdiagnozować prosty incydent, opisać go i obronić swoje wnioski przed rekruterem i senior analitykiem”.

Kim jest Security Analyst i gdzie pracuje?

Rola Security Analyst na tle innych ról w cyberbezpieczeństwie

Security Analyst (w kontekście tej roadmapy) to przede wszystkim osoba z Blue Teamu, która zajmuje się monitorowaniem, analizą i reagowaniem na incydenty bezpieczeństwa. Nie pisze głównie exploitów, nie łamie systemów klientów jak pentester, tylko pilnuje, żeby nikt niepożądany nie przeszedł niezauważony przez istniejące zabezpieczenia.

Typowe zadania analityka bezpieczeństwa to m.in.:

• monitorowanie alertów z systemów SIEM, EDR, IDS/IPS, firewalli i innych źródeł logów,
• triage – szybka ocena, które alerty są ważne, a które można odrzucić jako false positive,
• proste śledztwa – sprawdzanie, co się faktycznie wydarzyło, kto, kiedy i skąd się logował, jakie procesy działały, jaki ruch sieciowy był generowany,
• eskalacja – przekazywanie poważniejszych incydentów do bardziej doświadczonych analityków (Tier 2/3, Incident Response),
• raportowanie i dokumentacja – opisywanie przebiegu incydentu, wniosków i rekomendacji.

W odróżnieniu od Security Engineer czy Security Architect, początkujący Security Analyst rzadko projektuje całe rozwiązania. Bardziej działa w ramach istniejącej infrastruktury: korzysta z już wdrożonych narzędzi, korzysta z ustalonych playbooków i standardowych procedur reakcji.

Główne typy analityków: SOC Tier 1/2, Threat Analyst, Incident Responder

Przy planowaniu roadmapy najważniejsza jest rola SOC Analyst (Security Operations Center). W uproszczeniu można wyróżnić kilka poziomów:

• SOC Tier 1 (entry-level) – pierwszy kontakt z alertem:
  • ogląda dashboard SIEM i innych narzędzi,
  • robi wstępny triage (czy to w ogóle incydent),
  • sprawdza podstawowe konteksty (IP, host, użytkownik, geolokalizacja),
  • zamyka oczywiste false positives,
  • eskaluje to, co niebezpieczne lub niejasne.
• SOC Tier 2 – bardziej pogłębiona analiza:
  • przeprowadza mini-śledztwa,
  • konsultuje się z adminami / devopsami,
  • stosuje bardziej zaawansowane narzędzia (np. forensic na endpointach),
  • koordynuje podstawowe działania naprawcze.
• Threat Analyst / Threat Hunter – aktywnie szuka ataków:
  • tworzy własne zapytania i korelacje w SIEM,
  • analizuje TTPs według MITRE ATT&CK,
  • szuka anomalii w dużych zbiorach logów.
• Incident Responder – reaguje na poważne incydenty:
  • koordynuje odpowiedź na ransomware, wycieki danych,
  • prowadzi digital forensic (np. analiza dysków, pamięci, artefaktów systemowych),
  • współpracuje z prawnymi i biznesem.

Roadmapa z tego tekstu celuje przede wszystkim w poziom Junior SOC / Tier 1, ale jeśli dobrze zbudujesz fundament, przejście w kierunku Threat Huntingu czy Incident Response będzie naturalnym kolejnym krokiem.

Typowe środowiska pracy: gdzie realnie trafia początkujący analityk

Security Analyst może pracować w różnych typach organizacji. Od tego, gdzie trafisz, zależy tempo nauki, zakres obowiązków i poziom stresu.

• Wewnętrzny SOC w dużej korporacji – np. bank, telco, duży retail:
  • dużo procedur, często dobrze zdefiniowane playbooki,
  • często praca zmianowa (24/7 SOC),
  • dużo rutynowych alertów, ale także ekspozycja na realne incydenty.
• MSSP (Managed Security Service Provider) – SOC usługowy:
  • obsługa wielu klientów jednocześnie,
  • różne środowiska, różne technologie,
  • dużo praktyki, ale też presja na SLA i wydajność.
• Fintechy i software house’y:
  • mniejszy, bardziej zwinny zespół bezpieczeństwa,
  • częściej mieszanka SOC + DevSecOps + compliance,
  • możliwość dotknięcia CI/CD, chmury, automatyzacji.
• Instytucje publiczne, uczelnie:
  • często ograniczone budżety, ale szeroka ekspozycja na różne systemy,
  • mniej „pudełkowych” narzędzi, więcej improwizacji.

Dla początkującego dobrym wyborem są firmy, które mają ustrukturyzowane SOC i jasno zdefiniowane poziomy (Tier 1/2/3). Oznacza to większą szansę na mentoring i dostęp do gotowych playbooków, z których można się uczyć.

Jak wygląda typowy dzień pracy Security Analyst

Praca analityka bezpieczeństwa to w dużej mierze ciągła gra „szum vs sygnał”. Codzienność to nie hollywoodzkie pościgi za hakerem, tylko konsekwentne filtrowanie hałasu i szukanie tego jednego wzorca, który naprawdę ma znaczenie.

Typowy dzień Junior SOC Analyst może wyglądać tak:

• Start zmiany: przegląd paneli
  • logowanie do SIEM, EDR, systemów ticketowych,
  • sprawdzenie, czy nie ma krytycznych, niezamkniętych incydentów z poprzedniej zmiany,
  • krótkie przekazanie informacji od poprzedniej zmiany (handover).
• Monitoring i triage alertów
  • otwieranie nowych alertów,
  • sprawdzanie podstawowych szczegółów (źródłowy IP, host, użytkownik, typ detekcji),
  • korzystanie z gotowych playbooków („jeśli alert X, sprawdź A, B, C”).
• Proste śledztwa
  • sprawdzenie dodatkowych logów (Windows Event Logs, syslog, proxy, VPN),
  • korzystanie z narzędzi OSINT (np. reputacja IP/domain),
  • zapisywanie ustaleń w systemie ticketowym lub w narzędziu do dokumentacji.
• Eskalacje i współpraca
  • kontakt z adminami, jeśli trzeba np. zablokować konto czy IP,
  • eskalacja incydentów do Tier 2/IR, jeśli przekraczają Twój zakres decyzyjności.
• Raporty i housekeeping
  • zamykanie incydentów z jasno opisanym powodem,
  • udział w krótkich spotkaniach zespołu,
  • czas na naukę – w lepiej zarządzonych SOC część dnia jest przeznaczona na rozwój.

Roadmapa, którą budujesz, powinna finalnie doprowadzić do sytuacji, w której nie tylko „klikasz w SIEM”, ale umiesz zinterpretować dane i bronić swoich wniosków argumentami technicznymi.

Z czego składa się „fundament” Security Analysta

Minimum techniczne: sieci jako język, którym mówi każdy incydent

Bez podstaw sieciowych Security Analyst jest ślepy. Większość incydentów zostawia ślad w postaci ruchu sieciowego, adresów IP, portów, protokołów, zapytań HTTP itp. To jest alfabet, którym napisane są logi, na które będziesz patrzeć.

Kluczowe elementy, które trzeba mieć w małym palcu:

• Model TCP/IP i OSI – nie po to, żeby recytować warstwy na pamięć, tylko żeby rozumieć:
  • czym różni się problem na poziomie DNS od problemu na poziomie HTTP,
  • dlaczego skanowanie portów (TCP SYN scan) zostawia konkretne ślady w logach firewalli.
• Protokoły: HTTP/HTTPS, DNS, SMTP, VPN:
  • jak wygląda typowe zapytanie HTTP i gdzie w logu widać URL/parametry,
  • jak z logu DNS wywnioskować, że host komunikuje się z podejrzaną domeną,
  • jak rozróżnić normalne logowanie VPN od prób brute-force.
• Adresacja IP, NAT, podstawy routingu:
  • umiejętność odróżnienia adresu wewnętrznego od zewnętrznego,
  • rozumienie, dlaczego w logach WAF widzisz inne IP niż w logach systemu docelowego.

Dobry test: jeśli wiesz, jak zinterpretować prosty log z firewalla (source IP, dest IP, source port, dest port, action, protocol) i na tej podstawie opisać, co się wydarzyło, fundament sieciowy jest na właściwej drodze.

Systemy operacyjne: Windows i Linux z perspektywy logów i uprawnień

Analityk bezpieczeństwa nie musi być adminem systemowym, ale musi rozumieć jak system rejestruje zdarzenia i jak użytkownicy oraz procesy poruszają się w tym środowisku.

Dwa główne obszary:

• Windows:
  • podstawy Active Directory: konta, grupy, GPO, logon types,
  • Event Viewer – logi Security, System, Application,
  • typowe event ID przydatne w SOC (logowania, podwyższanie uprawnień, polityka haseł, RDP).
• Linux:
  • użytkownicy i grupy, sudo, SSH,
  • logi w /var/log: auth.log, syslog, messages,
  • podstawowe komendy diagnostyczne: ps, netstat/ss, journalctl.

Istotny jest też model uprawnień. Jeśli nie odróżniasz lokalnego administratora od domenowego, nie wiesz, co oznacza „przejęcie konta serwisowego” albo nie rozumiesz, dlaczego konto z uprawnieniami Domain Admins to „korona królestwa”, trudno będzie poprawnie ocenić wagę incydentu.

Dobry zwyczaj: podczas budowy homelabu regularnie patrz na logi po swoich działaniach. Zaloguj się na SSH, zmień plik, podnieś uprawnienia – a potem sprawdź, jak to wygląda w logach. To spina teorię z praktyką.

Podstawy bezpieczeństwa: słownik ataków i technik

Alerty w SIEM rzadko są opisane „ludzkim” językiem. Często zobaczysz nazwy typu Suspicious Lateral Movement Detected albo Possible Brute Force Attack. Bez znajomości podstawowych technik ataków trudno ocenić, co to znaczy w praktyce.

Minimalny zakres „słownika”:

• Phishing / spear phishing – jak prowadzi do przejęcia kont (credential theft), malware, BEC,
• Brute-force, credential stuffing – jak wyglądają w logach logowań i VPN,
• Malware – ogólne typy: trojan, ransomware, keylogger, backdoor,
• Lateral movement – przemieszczanie się po sieci wewnętrznej (Pass-the-Hash/Ticket, RDP, użycie kont adminów),
• Data exfiltration – wynoszenie danych (nietypowy ruch outbound, dziwne protokoły, kompresja/archiwizacja plików).

Nie chodzi o to, żeby od razu znać wszystkich APT z nazwy. Ważniejsze jest rozumienie łańcucha ataku (kill chain) i tego, że większość incydentów to kombinacja kilku kroków: wejście → utrzymanie dostępu → eskalacja → rozprzestrzenienie → exfiltracja/niszczenie.

Myślenie analityczne: praca z niepełnymi danymi i sceptycyzm

Security Analyst montuje historię z kilku niedoskonałych puzzli: fragmentów logów, informacji od użytkowników, częściowych detekcji. Dane prawie nigdy nie są pełne ani idealne.

Przydatne postawy i nawyki:

• Formułowanie hipotez – zamiast od razu mówić „atak”, lepiej przyjąć:
  • hipoteza 1: użytkownik zapomniał hasła i wpisywał je kilka razy,

  Myślenie analityczne: praca z hipotezami i redukcją szumu

  Kontynuując wątek pracy z niepełnymi danymi, dobrze jest narzucić sobie prostą, ale konsekwentną strukturę myślenia. W SOC gubi nie brak wiedzy technicznej, tylko skakanie po wnioskach bez sprawdzenia alternatyw.

  Przykładowy schemat analizy incydentu:

  • 1. Zdefiniuj problem – „system X zgłasza 50 nieudanych logowań do konta Y w ciągu 5 minut z adresu Z”. Bez jasnego opisu łatwo się rozproszyć.
  • 2. Postaw kilka hipotez:
    • H1: użytkownik zapomniał hasła i wpisywał je wielokrotnie,
    • H2: ktoś próbuje brute-force z zewnętrznego IP,
    • H3: automatyczny skrypt lub błędnie skonfigurowana aplikacja próbuje logowania.
  • 3. Określ, jakie dane potwierdzą/obalą każdą hipotezę – np. dla H1: kontakt z użytkownikiem, lokalizacja IP, godzina logowań vs godziny pracy.
  • 4. Sprawdź dane, zanotuj wnioski – nawet krótko, ale tak, żeby inny analityk mógł przejąć wątek.
  • 5. Podejmij decyzję – zamykasz, eskalujesz, blokujesz adres/IP, resetujesz hasło, itp.

  Im częściej przechodzisz przez ten cykl, tym szybciej zaczynasz oddzielać szum od realnego zagrożenia. Warto wyrobić nawyk zadawania sobie pytania: „Jakich danych jeszcze mi brakuje, żeby podjąć decyzję?” zamiast: „Czy to na pewno atak?”.

  Umiejętności „miękkie”, które chronią przed burnoutem

  W SOC stres robi swoje: alerty przychodzą non stop, klienci chcą szybkich odpowiedzi, a zmiany bywają nocne. Dwie kompetencje, które mocno pomagają przetrwać i rosnąć:

  • Komunikacja zwięzła, ale precyzyjna – musisz umieć napisać krótko:
    • co się stało,
    • co już zostało zrobione,
    • co trzeba zrobić dalej i kto ma to zrobić.

    Dobry opis incydentu oszczędza czas wszystkim: adminom, managerom, kolejnej zmianie SOC.

  • Zarządzanie własną energią – w praktyce:
    • robienie krótkich notatek w trakcie pracy (co już sprawdziłeś),
    • domykanie wątków przed końcem zmiany albo przekazanie ich z jasnym statusem,
    • odcinanie się po pracy – inaczej bardzo szybko pojawia się wrażenie ciągłego „dyżuru w głowie”.

  Mapowanie drogi: poziomy rozwoju od zera do pierwszej roli

  Poziom 0: „Zero techniczne”, czyli etap orientacyjny

  To etap dla osób, które nie mają jeszcze zaplecza IT. Celem nie jest „być analitykiem”, tylko sprawdzić, czy ten kierunek faktycznie ma sens.

  Co powinno się wydarzyć na tym poziomie:

  • Orientacja w krajobrazie IT – zrozumienie różnicy między:
    • adminem systemów a developerem,
    • SOC a „pentesterem”,
    • bezpieczeństwem aplikacji a bezpieczeństwem infrastruktury.
  • Prosty kontakt z techniką:
    • podstawowa praca z terminalem (PowerShell / bash),
    • zrozumienie, czym jest adres IP, przeglądarka, serwer, DNS – na poziomie użytkowym, ale świadomym.

  Na tym etapie wystarczą krótkie kursy wideo i proste ćwiczenia (np. pierwsze komendy w terminalu, podstawy sieci domowej). Jeśli już tutaj wszystko wydaje się męczące i kompletnie nieinteresujące, lepiej zatrzymać się niż na siłę iść dalej.

  Poziom 1: Fundament IT + podstawowy „security mindset”

  To etap przejścia od „lubię cyberbezpieczeństwo z YouTube’a” do realnych umiejętności technicznych. Kluczowy jest balans: nie chodzi o bycie seniorem od sieci, tylko o tyle wiedzy, żeby sensownie czytać logi.

  Zakres docelowy poziomu 1:

  • Sieci – tyle, żeby:
    • rozumieć sens podstawowych protokołów (HTTP, DNS, TCP, UDP),
    • umieć odczytać prosty ruch w Wiresharku,
    • skonfigurować podstawową sieć wirtualną w homelabie.
  • Systemy:
    • instalacja Windows i Linux w VM,
    • logowanie lokalne i zdalne (RDP/SSH),
    • podstawy użytkowników, uprawnień, logów.
  • Intro do bezpieczeństwa:
    • rozpoznawanie typowych ataków na wysokim poziomie,
    • świadomość, czym jest SOC, IR, Red Team, Blue Team.

  Na końcu poziomu 1 powinieneś być w stanie z grubsza zrozumieć opis prostego incydentu na blogu producenta EDR/SIEM, nawet jeśli nie rozumiesz wszystkich szczegółów konfiguracji.

  Poziom 2: „Pre-Junior” – pierwsze laby, pierwsze narzędzia

  To moment, kiedy same kursy teoretyczne przestają wystarczać. Celem jest kontakt z realnymi narzędziami, nawet w wersji community czy trial.

  Kluczowe elementy poziomu 2:

  • Homelab – prosta infrastruktura:
    • 1–2 VM z Windows (np. klient + „mini serwer”),
    • 1 VM z Linuxem (log collector, „serwer aplikacyjny”),
    • podstawowe logowanie zdarzeń i możliwość ich przeglądania.
  • Pierwsze narzędzia defensywne:
    • EDR/antywirus klasy „domowej” z logami,
    • prosty SIEM w wersji open source lub trial (np. Wazuh, Splunk Free, ELK z prostą konfiguracją),
    • zapoznanie z interfejsem: wyszukiwanie eventów, filtrowanie, podstawowe dashboardy.
  • Podstawowa automatyzacja:
    • kilka prostych skryptów (PowerShell/batch/bash) do zbierania logów lub informacji o systemie,
    • zrozumienie, jak te skrypty pomagają przy analizie incydentów.

  Na tym poziomie możesz zacząć szukać pierwszych, bardzo juniorowych ról lub praktyk/staży. Portfolio z prostymi labami (nawet w formie notatek i zrzutów ekranu) zaczyna mieć znaczenie.

  Poziom 3: Gotowość do roli Junior SOC Analyst

  Tu łączysz wszystkie elementy: sieci, systemy, bezpieczeństwo i narzędzia. Nie musisz znać odpowiedzi na wszystko, ale powinieneś potrafić:

  • przeprowadzić triage prostego alertu (np. podejrzane logowanie, malware detected),
  • zebrać i zinterpretować podstawowe logi z kilku źródeł (endpoint, AD, VPN),
  • udokumentować incydent w sposób zrozumiały dla kolejnego analityka.

  Dobrym wyznacznikiem jest to, czy potrafisz samodzielnie „odtworzyć” prosty incydent opisany w jakimś blogpoście: wygenerować podobny atak we własnym labie i prześledzić go w logach.

  Poziom 4: Ugruntowany Junior / aspirujący Mid

  To etap, na który wchodzisz już pracując jako analityk. Rozwój wynika głównie z realnych incydentów, ale laby i nauka w domu nadal odgrywają rolę.

  Obszary rozwoju na tym poziomie:

  • Pogłębienie wiedzy o narzędziach – tworzenie własnych dashboardów, prostych korelacji, customowych reguł detekcji.
  • Szersze zrozumienie ataków – MITRE ATT&CK nie tylko jako plakat na ścianie, ale jako mapa odniesienia do realnych alertów.
  • Współpraca z innymi zespołami – rozmowy z adminami, devami, udział w post-mortemach po większych incydentach.

  

  Laby krok po kroku: co, w jakiej kolejności i jak głęboko

  Etap 1: Lab „systemowo-sieciowy” bez bezpieczeństwa

  Paradoksalnie pierwszy lab powinien być prawie bez „security”. Chodzi o zrozumienie normalnego działania systemów. Dopiero wtedy widać odchylenia.

  Minimalna konfiguracja:

  • Host z dowolnym hypervisorem (VirtualBox, VMware, Hyper-V),
  • VM1: Windows (np. Windows 10/11) – „użytkownik”,
  • VM2: Linux (np. Ubuntu Server) – „serwer” (np. z prostym serwerem WWW lub SSH),
  • VM3: dodatkowa maszyna Windows lub Linux jako „narzędzie admina/analityka”.

  Ćwiczenia, które robią dużą różnicę:

  • Pingowanie, łączenie się po HTTP/SSH między VM – obserwacja logów po obu stronach.
  • Tworzenie użytkowników, nadawanie uprawnień, logowanie się różnymi kontami.
  • Świadome generowanie błędów (np. zła nazwa hosta, zły port) i sprawdzanie, jak to wygląda w logach systemu i aplikacji.

  Etap 2: Wprowadzenie narzędzi „atakujących” do labu

  Kolejny krok to dodanie kontrolowanego elementu ofensywnego. Nie chodzi o bycie pentesterem, tylko o zrozumienie, jak atak przekłada się na logi.

  Prosty setup:

  • dodatkowa VM z dystrybucją typu Kali/Parrot lub zwykłym Linuxem z kilkoma narzędziami (nmap, curl, ssh, hping),
  • docelowe maszyny z poprzedniego etapu (Windows/Linux).

  Przykładowe scenariusze ćwiczeń:

  • Skanowanie portów:
    • wykonaj skan nmapem na Linux/Windows,
    • sprawdź logi firewalla/systemu – co zostało zapisane?
  • Brute-force SSH/RDP na własne maszyny:
    • użyj prostych narzędzi (np. hydra na SSH) lub ręcznego powtarzania logowań,
    • porównaj: jak widać to w logach Windows (eventy logowania) vs Linux (auth.log).

  Etap 3: Pierwszy „mini-SIEM” w homelabie

  Moment, w którym lab zaczyna przypominać realne środowisko SOC. Nie trzeba od razu budować pełnego ELK, ale dobrze mieć jedno miejsce, w którym lądują logi z kilku maszyn.

  Opcje na start:

  • Wazuh – agent na Windows/Linux, centralny serwer zbierający logi, proste reguły detekcji.
  • Splunk Free – idealny do nauki wyszukiwania i budowania zapytań.
  • Elastic Stack (ELK) – jeśli lubisz grzebać w konfiguracji; dobra szkoła zrozumienia pipeline’u logów.

  Przykładowe ćwiczenia:

  • Skonfiguruj wysyłanie logów systemowych z 2–3 maszyn do centralnego narzędzia.
  • Wygeneruj znane zdarzenie (np. nieudane logowanie, restart usługi) i sprawdź, jak je znaleźć po stronie SIEM.
  • Spróbuj zbudować prosty dashboard: liczba nieudanych logowań w czasie, top źródła ruchu, itp.

  Etap 4: Laby symulujące pracę SOC (triage + śledztwo)

  Na tym etapie samo klikanie w narzędzie nie wystarczy. Celem jest symulacja typowego dnia pracy analityka: jest alert → trzeba go sprawdzić → udokumentować → podjąć akcję.

  W praktyce:

  • Przygotuj „scenariusze incydentów” w swoim labie:
    • seria nieudanych logowań z jednego IP,
    • podejrzane uruchomienie pliku EXE z nietypowej lokalizacji,
    • podejrzane połączenie wychodzące na rzadki port.
  • Odegraj rolę SOC:
    • stwórz dokument „alertu” (nawet jako notatkę),
    • zrób listę kroków triage (co sprawdzasz po kolei),
    • zapisz decyzję: fałszywy pozytyw/prawdziwy incydent + proponowane działania.

  Konkrety: platformy z labami i jak z nich wycisnąć maksimum

  Podział platform: czego się z której realnie nauczysz

  Platform z labami jest sporo, ale nie wszystkie są sensowne z perspektywy Security Analysta. Zamiast rejestrować się wszędzie, lepiej dobrać 2–3 i wycisnąć je do końca.

  Najczęściej użyteczne kategorie:

  • Platformy „Blue Team / SOC” – nastawione na logi, triage, pracę z SIEM:
    • Blue Team Labs Online,
    • LetsDefend,
    • RangeForce (część modułów),
    • TryHackMe – ścieżki „SOC Level 1”, „Blue Team”, wybrane pokoje.
  • Platformy ogólno–security z elementami Blue:
    • Hack The Box (szczególnie moduły Academy z DFIR/Logging/Blue),
    • INE/Cybrary – kursy z DFIR, SOC, Threat Hunting.
  • Platformy logowe / narzędziowe:
    • Splunk Boss of the SOC (BoTS) – okresowe eventy i zestawy danych,
    • Elastic Security Labs – dane do zabawy z Elastic SIEM,
    • Własny Wazuh/ELK/Splunk Free – lab + publiczne próbki logów.

  Jak dobrać platformę do swojego poziomu

  Jeśli wybór ma być sensowny, trzeba go powiązać z etapem z poprzedniej roadmapy.

  • Poziom 1 / wczesny 2:
    • TryHackMe – ścieżki „Pre Security”, „SOC Level 1 (początek)”.
    • Wybrane darmowe moduły na Cybrary/INE o podstawach SOC i logów.
  • Poziom 2 (Pre-Junior):
    • TryHackMe – kontynuacja „SOC Level 1”, pokoje z Wireshark, logami Windows/Linux.
    • LetsDefend/Blue Team Labs – pierwsze scenariusze „alert → śledztwo”.
    • Start z własnym Splunkiem Free lub Wazuhem.
  • Poziom 3 (ready Junior):
    • Blue Team Labs Online / LetsDefend – pełne scenariusze z kilkoma źródłami logów.
    • Hack The Box Academy – moduły „Introduction to SOC”, „Windows Event Logs”, „Network Traffic Analysis”, „Threat Hunting Fundamentals”.
    • Splunk BoTS / zestawy CTF-owe oparte o logi.

  Strategia korzystania z labów: „głębia zamiast kolekcjonowania odznak”

  Spory błąd na starcie: odhaczanie jak największej liczby scenariuszy. Dla rekrutera niewiele znaczy 200 zrobionych „pokoi”, jeśli nie jesteś w stanie opisać 3 konkretnych case’ów.

  Dla każdego labu, który chcesz „wrzucić do portfolio”, zrób trzy rzeczy:

  1. Notatka z kontekstem:
     • Jaki był scenariusz (np. „podejrzenie malware na stacji użytkownika”)?
     • Jakie były źródła danych (logi Windows, proxy, EDR)?
     • Jakie narzędzia wykorzystałeś (SIEM X, Wireshark, PowerShell)?
  2. Spis kroków analizy:
     • Jakie zapytania w SIEM wykonałeś (choćby w pseudo–kodzie, jeśli platforma nie pozwala skopiować)?
     • Jak filtrowałeś szum?
     • Co w logach przesądziło o decyzji?
  3. Krótka „post–mortemka”:
     • Co można by zautomatyzować (np. reguła korelacyjna, alert threshold)?
     • Jakie dwa–trzy artefakty były krytyczne (hash, IP, ścieżka do pliku, event ID)?

  Jak prowadzić notatki z labów, żeby nadawały się do portfolio

  Chaotyczne screeny w folderze „screenshots” niewiele dają. Lepiej przygotować prosty, powtarzalny szablon, np. w OneNote, Notion, Obsidian albo nawet w Markdown.

  Przykładowy szkielet notatki:

  • Tytuł / nazwa labu + link.
  • Cel: czego się uczysz (np. „analiza podejrzanego procesu na Windows z użyciem logów EDR + Sysmon”).
  • Środowisko: narzędzia, systemy, zakres logów.
  • Przebieg analizy:
    • kroki (w punktach),
    • istotne komendy/zapytania,
    • screeny tylko tam, gdzie coś pokazują (np. kluczowy event, pivot po IP).
  • Wnioski: 3–5 krótkich zdań – co nowego, co utrwalone, co poszło nie tak.

  Tak przygotowaną notatkę można przełożyć na wpis na GitHubie/Blogu/LinkedIn, zanonimizować i dołączyć do CV jako „wybrane case’y labowe”.

  Łączenie platform z własnym homelabem

  Platformy „SaaS” dają gotowe środowisko, ale nie nauczą konfiguracji logowania. Homelab wymaga dłubania, ale odwdzięcza się lepszym zrozumieniem „skąd się bierze event w SIEM”. Idealne jest połączenie obu.

  Przykładowe podejście:

  • Na TryHackMe/LetsDefend przechodzisz scenariusz „podejrzane logowanie RDP, możliwy brute-force”.
  • W swoim homelabie:
    • tworzysz użytkownika testowego i wymuszasz nieudane logowania RDP,
    • konfigurujesz wysyłkę eventów bezpieczeństwa (4625, 4624) do Wazuha/Splunka,
    • budujesz regułę/alert, który wykryje „X nieudanych logowań w Y minut”.

  Z czasem mapujesz prawie każdy ciekawy scenariusz z platformy na własny lab. Różnicę czuć przy rozmowie rekrutacyjnej – potrafisz opisać nie tylko „co kliknąłeś na stronie”, ale też jak wyglądały logi od strony systemu.

  Jak oceniać jakość labów

  Nie każdy lab jest tak samo wartościowy. Dobre scenariusze mają kilka wspólnych cech:

  • Brak „prowadzenia za rękę” – lab mówi, jaki jest problem i daje narzędzia, ale nie podaje każdego kliknięcia.
  • Kilka źródeł logów – endpoint + sieć + ewentualnie AD / proxy.
  • Możliwość popełnienia błędu – możesz wyciągnąć zły wniosek, ale dostajesz potem feedback (np. modelowe rozwiązanie).
  • Powiązanie z MITRE ATT&CK – nawet na poziomie „ta technika to T1110 – Brute-Force”.

  Jeśli lab polega wyłącznie na klikaniu „Next” i odczytaniu odpowiedzi z okna obok, lepiej potraktować go jak krótki tutorial narzędzia, a nie „case do portfolio”.

  Pierwsze „case’y”: jak samemu generować incydenty do analizy

  Dlaczego warto samemu generować incydenty

  Gotowe laby są ograniczone – mają z góry ustawione dane, logi, wynik. W prawdziwym SOC często nikt nie wie, czy alert jest fałszywie pozytywny, czy to początek większego ataku. Własny lab pozwala przećwiczyć cały proces, od generowania „hałasu” po wyciąganie wniosków.

  Dodatkowo własne case’y można dobrze opisać na GitHubie czy w portfolio, bo to twoja konfiguracja, twoje logi, twoje decyzje.

  Model case’a: „Alert → Hipoteza → Dane → Decyzja”

  Zanim zaczniesz generować zdarzenia, poukładaj sobie prosty model analizy:

  1. Alert – sygnał, że coś może być nie tak (reguła SIEM, event EDR, dziwny wzorzec w logach).
  2. Hipoteza – co może się dziać? (np. brute-force, malware, skan sieci).
  3. Dane – jakie źródła logów/materiałów sprawdzisz, żeby hipotezę potwierdzić lub obalić.
  4. Decyzja – fałszywie pozytywny, incydent niski/średni/wysoki priorytet, eskalacja, kompensacja.

  Każdy samodzielnie wygenerowany case opisuj na tej matrycy. Na rozmowie rekrutacyjnej możesz potem spokojnie przeprowadzić rekrutera po tym schemacie.

  Case 1: Brute-force / nieudane logowania

  To najprostszy typ case’a, a jednocześnie realny chleb powszedni w SOC.

  Scenariusz w homelabie:

  1. Przygotowanie:
     • Maszyna Windows z włączonym RDP i logowaniem eventów bezpieczeństwa do SIEM (4625, 4624).
     • Maszyna atakująca (Kali/Ubuntu) z dostępem do portu RDP.
     • Reguła w SIEM typu: „>= X nieudanych logowań z tego samego IP / na to samo konto w Y minut”.
  2. Generowanie incydentu:
     • Ręcznie lub przy pomocy narzędzia (np. hydra) wykonujesz serię nieudanych logowań.
     • Doprowadzasz do wyzwolenia alertu w SIEM.
  3. Analiza:
     • Sprawdzasz, które konta były celem (lokalne / domenowe).
     • Sprawdzasz, czy po serii nieudanych logowań nastąpiło udane logowanie (możliwy sukces ataku).
     • Identyfikujesz IP źródłowe, geolokalizację (nawet poglądowo) i czy było widoczne wcześniej.
  4. Wnioski i działania:
     • Czy alert ma sensowny threshold (nie generuje szumu przy zwykłym myleniu hasła)?
     • Jakie działania podjąłbyś w realnej firmie (blokada IP, reset hasła, MFA, ticket do adminów)?

  Case 2: Podejrzane uruchomienie pliku / procesów na Windows

  W wielu środowiskach SOC pierwszy sygnał problemu to nietypowy proces lub lokalizacja pliku. Taki scenariusz da się bardzo łatwo odtworzyć w homelabie z Sysmonem lub prostym EDR-em.

  Plan działania:

  1. Konfiguracja logowania:
     • Instalujesz Sysmon z rozsądną konfiguracją (np. popularne configi z GitHuba: SwiftOnSecurity itp.).
     • Wysyłasz eventy Sysmon do Wazuha/Splunka (Event ID 1 – process creation).
  2. Generowanie „podejrzanego” procesu:
     • Tworzysz katalog typu C:UsersPublic lub C:Temp i umieszczasz tam prosty EXE (może być legalny program, np. putty.exe).
     • Uruchamiasz go kilka razy z różnymi parametrami, ewentualnie przez cmd.exe / powershell.exe.
  3. Reguła / alert:
     • Budujesz zapytanie typu:
       • „process_name = *.exe AND parent_process_name = powershell.exe AND image_path zawiera UsersPublic”
     • Albo prostsze: „proces uruchomiony z nietypowej ścieżki użytkownika”.
  4. Analiza:
     • Sprawdzasz, który użytkownik zainicjował proces, z jakiego hosta, o której godzinie.
     • Patrzysz na łańcuch rodzic–potomek (parent–child) procesów: co uruchomiło EXE?
     • Sprawdzasz hash pliku w VirusTotal (nawet jeśli to całkiem legalny program – chodzi o wyrobienie nawyku).

  Case 3: Podejrzany ruch sieciowy wychodzący

  Nawet prosta komunikacja HTTP/HTTPS na nietypowe hosty potrafi być sygnałem problemu, szczególnie w połączeniu z innymi zdarzeniami.

  Scenariusz, który odzwierciedla prostą „komunikację do C2”, bez dotykania rzeczy nielegalnych:

  1. Środowisko:
     • Maszyna Windows z przeglądarką lub curl.
     • Maszyna Linux jako „pseudo–C2” z prostym serwerem HTTP (np. python3 -m http.server 8080).
     • NetFlow/logi firewallowe lub proxy w twoim homelabie (może być prosty firewall na pfsense / logi z Linuxa).