Sieci komputerowe

CYB-05 — Korelacja logów i podstawy SIEM

Cyberbezpieczeństwo

Ręczna analiza syntetycznej telemetrii ALFA-LAB: od jakości czasu i normalizacji pól do chronologii, korelacji, triage oraz udokumentowanej decyzji.

120–150 minbez komercyjnego SIEMdane syntetyczneUTC i NTPraport analityczny

Cele ćwiczenia

Od obserwacji do udokumentowanego wniosku

Rozpoznanie możliwości i ograniczeń logów uwierzytelniania, UFW, nginx, DNS, DHCP, przełącznika, VPN i alertów SIEM.
Normalizacja czasu, nazw pól oraz identyfikatorów bez modyfikowania plików źródłowych.
Budowa chronologii UTC i łączenie zdarzeń z kilku systemów w logiczne sekwencje.
Rozróżnienie logu, zdarzenia, alertu i incydentu na podstawie dowodów oraz kontekstu.
Ocena hipotez z jawnym poziomem pewności, brakującymi danymi i możliwym false positive.
Przygotowanie defensywnej decyzji: zamknięcie, dalsza obserwacja albo eskalacja zgodna z procesem reagowania.

Wyłącznie analiza defensywna

Zakres, bezpieczeństwo i etyka

Analizuj wyłącznie dostarczone, syntetyczne pliki ALFA-LAB. Nie generuj podejrzanego ruchu, nie wykonuj brute force, nie obchodź zabezpieczeń i nie testuj publicznych ani obcych systemów.

Nie wpisuj do raportu prawdziwych danych osobowych, haseł, tokenów, kluczy ani sekretów. Gdy pochodzenie lub zakres danych jest niejasny, przerwij ćwiczenie i skontaktuj się z prowadzącym.

Wpisy nie opisują autentycznego incydentu. Adresy 192.0.2.0/24 i 203.0.113.0/24 są użyte wyłącznie jako adresacja dokumentacyjna, a nazwy hostów i kont są fikcyjne.

ALFA-LAB

Wymagania wstępne, scenariusz i topologia logiczna

Wymagana jest znajomość podstaw monitoringu i SIEM, reagowania na incydenty, DHCP, DNS oraz interpretacji logów sieciowych. Wystarczy edytor tekstu, arkusz kalkulacyjny i narzędzie SHA-256 dostępne w systemie.

Scenariusz obejmuje normalną pracę, autoryzowane okno Nmap, błędy logowania, administrację, blokady UFW, zwykły i nietypowy ruch HTTP, zmianę dzierżawy, zdarzenie L2, VPN, alerty oraz przerwę telemetrii DNS. Aktywności przeplatają się, dlatego kolejność nazw plików nie jest chronologią.

Fikcyjna topologia logiczna ALFA-LAB
Element	Adres lub rola	Funkcja	Kontekst
VM-ANALITYK	192.168.77.50, później .51	autoryzowany test i administracja	adm-kowalski
WS-KSIEGOWOSC	192.168.77.42	zwykła praca użytkownika	u-nowak
srv-app-01	192.168.77.20	SSH, nginx i UFW	administrator Linux
dns-01	192.168.77.53	DNS i heartbeat	administrator DNS
dhcp-01	192.168.77.5	dzierżawy LAB-CYBER	administrator sieci
SW-ACCESS-01	urządzenie L2	porty, MAC i wysyłka Syslog	administrator sieci
vpn-gw-01	brama laboratoryjna	sesje zdalne i MFA	administrator bezpieczeństwa
collector-01	kolektor referencyjny	czas odbioru UTC i alerty	operator monitoringu

Dane wejściowe

Zestaw plików ćwiczeniowych

Pliki CYB-05 i ich rola
Plik	Zawartość	Zadanie studenta
README.txt	zakres, bezpieczeństwo i sposób pracy	przeczytaj przed analizą
inwentarz-zrodel.txt	właściciele, formaty czasu i kompletność	ustal założenia normalizacji
auth.log	SSH, sudo i konta	połącz próby, sesje i kontekst użytkownika
ufw.log	zablokowane pakiety	połącz źródło, cel, port i czas
nginx-access.log	żądania HTTP i odpowiedzi	oceń sekwencję, nie pojedynczy URI
dns.log	zapytania i heartbeat	zidentyfikuj granicę dostępnej telemetrii
dhcp.log	adres, MAC i hostname	śledź zmianę adresu tego samego urządzenia
switch-syslog.log	stan portu, MAC i kolejka	oddziel czas urządzenia od czasu odbioru
vpn.log	MFA, sesja i identyfikator zmiany	ustal użytkownika oraz okno autoryzacji
alerty-siem.csv	wyniki reguł detekcyjnych	traktuj jako hipotezy wymagające triage
SHA256SUMS.txt	wartości SHA-256	sprawdź niezmienność zestawu
szablon-raportu.txt	puste tabele i pola analizy	zapisuj własne decyzje

CYB-05 — README.txt CYB-05 — inwentarz-zrodel.txt CYB-05 — auth.log CYB-05 — ufw.log CYB-05 — nginx-access.log CYB-05 — dns.log CYB-05 — dhcp.log CYB-05 — switch-syslog.log CYB-05 — vpn.log CYB-05 — alerty-siem.csv CYB-05 — SHA256SUMS.txt CYB-05 — szablon-raportu.txt

Oryginał pozostaje bez zmian

Przygotowanie stanowiska i kontrola integralności

Pobierz cały zestaw do katalogu przeznaczonego wyłącznie dla tego ćwiczenia.
Przeczytaj README i inwentarz, a następnie ogranicz dostęp do katalogu.
Zweryfikuj każdy wpis z SHA256SUMS.txt; rozbieżność zgłoś przed analizą.
Utwórz kopię roboczą. Nie otwieraj oryginałów w programie, który automatycznie zmienia kodowanie lub zakończenia linii.
Zapisz w raporcie datę kontroli, narzędzie i wynik. Sam hash nie potwierdza pochodzenia pliku.

Kontrola pojedynczego pliku — PowerShell

Get-FileHash .\\auth.log -Algorithm SHA256

Działanie:: Oblicza SHA-256 bez zmiany pliku.
Oczekiwany wynik:: Wartość zgodna z manifestem.
Interpretacja:: Zgodność wskazuje niezmienność względem przygotowanego manifestu.
Ograniczenie:: Nie potwierdza autora ani pełnego chain of custody.

Kontrola pojedynczego pliku — Linux

sha256sum auth.log

Działanie:: Oblicza SHA-256 bez zmiany pliku.
Oczekiwany wynik:: Wartość zgodna z manifestem.
Interpretacja:: Rozbieżność zatrzymuje analizę do wyjaśnienia.
Ograniczenie:: Kopia manifestu również wymaga zaufanego źródła.

Najpierw oś czasu

UTC, strefy, przesunięcie i czas zebrania

Wspólną osią roboczą jest UTC. Zachowaj osobno surowy timestamp, przyjętą strefę, korektę, czas znormalizowany i czas odebrania przez kolektor.

Założenia normalizacji czasu w CYB-05
Źródło	Przykład surowy	Interpretacja	Transformacja	Dokumentacja
auth.log	Aug 18 10:05:11	Europe/Warsaw, rok z kontekstu	odjąć 2 h	jawnie zapisać założony rok i strefę
ufw.log	2026-08-18T08:20:02Z	UTC	bez korekty strefy	Z oznacza UTC
nginx-access.log	18/Aug/2026:10:20:04 +0200	offset +02:00	przeliczyć na UTC	zachować surową wartość
dhcp.log	2026-08-18 10:31:52	Europe/Warsaw z inwentarza	odjąć 2 h	format sam nie określa strefy
switch-syslog.log	czas urządzenia i received_at	jawny +02:00 oraz UTC	uwzględnić około +94 s	korekta jako osobne pole, nie edycja logu
alerty-siem.csv	event_time_utc i collected_at_utc	UTC	zachować oba	kolejność odbioru nie musi być kolejnością zdarzeń

NTP ogranicza rozbieżności, ale nie naprawia historii już zapisanej błędnym zegarem. Nie sortuj bezmyślnie surowych wierszy: log bez strefy, zegar przełącznika przesunięty o około 94 sekundy i opóźniona kolejka mogą odwrócić pozorną kolejność. Oryginału nie nadpisuj, ponieważ utraciłbyś dowód pierwotnej wartości i możliwość ponownej interpretacji.

received_at=2026-08-18T08:31:49Z |
device_time=2026-08-18T10:33:23+02:00
known_clock_offset=+00:01:34

Każdy sensor widzi fragment

Możliwości, ograniczenia i jakość źródeł

Ocena źródeł logów ALFA-LAB
Źródło	Może potwierdzić	Nie może potwierdzić	Ważne pola	Typowe braki	Kontrola jakości
Uwierzytelnianie	wynik próby, konto, adres i mechanizm	tożsamości człowieka ani celu działania	czas, host, username, source_ip, wynik	brak strefy, rotacja, konto współdzielone	właściciel, zakres czasu, SHA-256 i spójność z VPN
UFW	decyzję zapory dla zarejestrowanego pakietu	pełnego skanu ani intencji źródła	SRC, DST, SPT, DPT, PROTO, action	rate limiting, brak wpisów dla ruchu dozwolonego	reguły, poziom logowania, liczniki i kompletność
nginx	żądanie obsłużone przez serwer i kod odpowiedzi	treści odpowiedzi ani tożsamości bez dodatkowych danych	czas, adres, metoda, URI, status, user-agent	buforowanie, proxy, wyłączenia logowania	format, rotacja, proxy chain i korelacja aplikacyjna
DNS	zapytanie widoczne dla danego sensora	każdego rozwiązania nazwy ani późniejszego połączenia	czas, source_ip, qname, qtype, wynik	cache klienta, inny resolver, luka heartbeat	ciągłość, licznik sekwencji i stan forwardera
DHCP	przypisanie IP do MAC i hostname w danym czasie	faktycznego użytkownika ani użycia adresu	czas, IP, MAC, hostname, typ dzierżawy	adres statyczny, spoofing, brak strefy	baza dzierżaw, czas serwera i unikalność MAC
Syslog przełącznika	stan portu i komunikat wygenerowany przez urządzenie	przyczyny biznesowej ani gwarancji dostarczenia	czas urządzenia, received_at, interfejs, MAC, severity	przesunięcie zegara, UDP, kolejka i utrata	NTP, transport, kolejność i porównanie z DHCP
VPN	wynik MFA, konto, adres klienta i czas sesji	czynności wykonanych wewnątrz sesji	czas, username, source_ip, assigned_ip, change_id	NAT, współdzielone konto, brak logów aplikacji	właściciel zmiany, polityka MFA i spójność z auth
Alert SIEM	spełnienie warunku reguły na dostępnych danych	ataku ani incydentu bez walidacji	rule, severity, event_time, collected_at, correlation_id	błąd reguły, opóźnienie, brak kontekstu	wersja reguły, źródła wejściowe i historia dostrojenia

Integralność oznacza więcej niż obecność pliku. Sprawdź właściciela, zakres czasu, konfigurację logowania, rotację, kompletność, kanał transportu i zgodność z drugim źródłem. Brak wpisu może oznaczać brak aktywności, ale także utratę, filtrację albo brak widoczności sensora.

Wspólny język danych

Normalizacja nazw i identyfikatorów

Docelowe pola tabeli znormalizowanej
Pole	Znaczenie	Przykładowe nazwy źródłowe
timestamp	czas zdarzenia po przeliczeniu	event_time, time_local, znacznik Syslog
source_ip	adres inicjujący obserwowaną aktywność	SRC, remote_addr, client_ip
destination_ip	adres celu	DST, server_addr, asset_ip
source_port	port źródłowy, jeśli dostępny	SPT, remote_port
destination_port	port usługi docelowej	DPT, server_port
hostname	ujednolicona nazwa aktywa	host, device, node
username	konto związane ze zdarzeniem	user, account, principal
event_type	znormalizowany typ aktywności	sshd result, query, request, link state
action	wynik albo decyzja źródła	accepted, blocked, allowed, failed
severity	dotkliwość źródła lub analityka	PRI, level, severity
sensor	system, który dokonał obserwacji	logger, collector, appliance
event_id	identyfikator surowego zdarzenia	event_id, msgid, record_id
correlation_id	identyfikator grupy analitycznej	alert correlation_id lub własny wpis

Nie każde źródło zawiera wszystkie pola. Brak oznacz jako brak w źródle, zamiast zgadywać. Utwórz tabelę w raporcie lub kopii roboczej, zachowaj event_id i przypisz własny correlation_id dopiero podczas grupowania.

Od wpisów do sekwencji

Znormalizowana chronologia i korelacja

Znormalizuj czas każdego wybranego wpisu do UTC, zachowując surową wartość.
Ujednolić nazwy hostów, kont, adresów, typów zdarzeń i akcji.
Połącz wpisy najpierw po silnych identyfikatorach, a potem po czasie i kontekście.
Utwórz sekwencje, lecz nie wymuszaj związku tylko dlatego, że zdarzenia są blisko w czasie.
Dla każdej sekwencji zapisz hipotezę, dowody za i przeciw, braki, pewność i dalsze działanie.

Sekwencje robocze bez gotowej klasyfikacji
ID	Przedział	Źródła	Hipoteza	Dowody za	Dowody przeciw	Pewność	Działanie
CORR-LAB-A	08:19–08:30 UTC	VPN, DNS, UFW, nginx	do sformułowania	do wskazania	do wskazania	niski / średni / wysoki	do decyzji
CORR-LAB-B	08:31–08:33 UTC	nginx, UFW	do sformułowania	do wskazania	do wskazania	niski / średni / wysoki	do decyzji
CORR-LAB-C	08:33–08:34 UTC	auth, DHCP, VPN	do sformułowania	do wskazania	do wskazania	niski / średni / wysoki	do decyzji
CORR-LAB-D	08:05–08:06 UTC	auth, DHCP	do sformułowania	do wskazania	do wskazania	niski / średni / wysoki	do decyzji
CORR-LAB-E	od 08:35 UTC	DNS, alert SIEM, kolektor	do sformułowania	do wskazania	do wskazania	niski / średni / wysoki	do decyzji

Poziom niski oznacza istotne braki lub wiele alternatywnych wyjaśnień, średni — kilka zgodnych źródeł z pozostającą niepewnością, a wysoki — spójne, niezależne dowody i potwierdzony kontekst. Ważność alertu nie jest poziomem pewności.

Nie każdy alert jest incydentem

Log, zdarzenie, alert i incydent

Poziomy interpretacji danych
Pojęcie	Znaczenie	Przykład	Ograniczenie
Log	techniczny zapis w konkretnym źródle	wiersz auth.log albo nginx-access.log	sam nie rozstrzyga intencji
Zdarzenie	aktywność zaobserwowana i opisana przez analityka	udane logowanie z danego hosta	wymaga kontekstu aktywa i czasu
Alert	wynik reguły, progu lub analizy	reguła port_sequence została spełniona	może być false positive
Incydent	potwierdzone lub dostatecznie wiarygodne naruszenie wymagające obsługi	decyzja po triage i ocenie wpływu	nie wynika automatycznie z jednego alertu

Zaklasyfikuj wszystkie pięć pozycji z alerty-siem.csv. Dla każdej decyzji wskaż, czy pozostaje tylko logiem lub zdarzeniem, jest alertem do dalszego triage, możliwym false positive czy kandydatem do eskalacji jako incydent. Uzasadnij decyzję, nie używaj samej wartości severity.

Logika detekcyjna, nie kod ofensywny

Opisowe reguły korelacyjne i dostrajanie

Defensywne reguły korelacyjne CYB-05
Reguła	Cel	Wymagane dane	Warunek	Możliwy false positive	Priorytet	Dostrojenie
Nieudane, potem udane logowanie	wykrycie możliwego przejęcia albo błędu użytkownika	auth: konto, źródło, wynik, czas	kilka failure i success w krótkim oknie	literówka właściciela konta	niski–średni	baseline liczby prób, MFA i znane urządzenie
Sekwencja portów w oknie testowym	oddzielenie nieautoryzowanego rozpoznania od zmiany	UFW, nginx, VPN, rejestr zmian	wiele portów z jednego źródła	zatwierdzony test Nmap	średni	właściciel, host, zakres i dokładne okno
Blokady UFW i nietypowe URI	połączenie obserwacji sieciowej z aplikacyjną	UFW oraz nginx	to samo źródło i zbliżony czas	monitor dostępności albo test jakości	wysoki	proxy, user-agent, baseline i log aplikacji
Konto spoza inwentarza	wykrycie niezarządzanego konta	auth, katalog kont, zgłoszenia zmian	success dla konta nieobecnego w bieżącej liście	nieaktualny inwentarz lub konto techniczne	średni	właściciel konta, data eksportu i cel logowania
Zmiana L2 i dzierżawy	śledzenie tożsamości urządzenia mimo zmiany IP	DHCP i Syslog przełącznika	ten sam MAC, port i bliskie czasy	kontrolowane przepięcie interfejsu	niski–średni	korekta zegara, autoryzowana zmiana i historia portu
Brak oczekiwanego heartbeat	wykrycie utraty widoczności	DNS, kolektor, monitoring źródła	brak kolejnego wpisu po zdefiniowanym czasie	awaria, sieć, retencja lub kolektor	średni	osobne monitorowanie źródła i kanału transportu

Reguła tworzy alert, a nie werdykt. Dokumentuj jej wersję, okno czasu, źródła, wyjątki, próg i powód zmiany. Dostrojenie ma ograniczać szum bez wyciszania całej klasy istotnych zdarzeń.

Kontekst zmienia ocenę

Dwa przypadki możliwego false positive

Sekwencja A: alert o wielu portach pochodzi z 192.168.77.50. Porównaj host, konto, czas, zakres i spodziewany rezultat z CHG-LAB-042. Sama zgodność adresu nie wystarcza, jeżeli po zmianie DHCP ten adres mógł należeć do innego urządzenia.

Sekwencja D: dwa błędy logowania poprzedzają sukces konta u-nowak. Sprawdź właściciela, urządzenie, metodę logowania, odstęp czasu, DHCP i ewentualne potwierdzenie użytkownika. Nie zamykaj alertu tylko dlatego, że później nastąpił sukces.

Kontekst wymagany przed zamknięciem

zatwierdzone okno i identyfikator zmiany
właściciel działania oraz źródłowy host
zakres autoryzacji i zgodność czasu
spodziewany rezultat oraz dowody spoza samego alertu
udokumentowane ograniczenia i decyzja o dostrojeniu reguły

Brak danych nie jest dowodem manipulacji

Przerwanie logowania DNS

Inwentarz oczekuje heartbeat DNS co minutę, lecz ostatni dostarczony wpis ma czas 08:34:58 UTC. Ustal dokładny przedział braku, wpływ na analizowane sekwencje i bezpieczny plan weryfikacji.

Hipotezy dotyczące luki telemetrycznej
Możliwa przyczyna	Dane do sprawdzenia	Dlaczego sam brak nie rozstrzyga
awaria źródła	stan usługi, restart i zasoby hosta	kolektor może być sprawny mimo awarii DNS
problem sieciowy	łączność, kolejki i log transportu	źródło mogło nadal zapisywać lokalnie
błędna konfiguracja	adres kolektora, filtr i poziom logowania	zmiana może być przypadkowa lub zatwierdzona
przepełnienie lub retencja	pojemność, rotacja i drop counters	utrata może wynikać z limitów
manipulacja	audyt zmian, konta i spójność z innymi sensorami	to jedna z hipotez, nie automatyczny wniosek
różnica czasu	NTP i ostatni poprawny heartbeat	wpis może znajdować się poza oczekiwanym oknem
brak uprawnień kolektora	status agenta i błędy odczytu	plik źródłowy może istnieć bez eksportu

Od alertu do decyzji

Dwunastoetapowa procedura triage

Procedura triage alertu w CYB-05
Etap	Działanie	Dowód w raporcie
1	Zarejestruj alert	ID, reguła, źródło, odbiorca i czas przyjęcia
2	Zweryfikuj czas	strefa, korekta, event time i collection time
3	Zidentyfikuj aktywo	funkcja, krytyczność i właściciel
4	Oceń kompletność	dostępne źródła, luka i ograniczenia
5	Skoreluj źródła	chronologia, wspólne IP, MAC, konto i identyfikatory
6	Sprawdź zmiany	okno, właściciel, host i zakres autoryzacji
7	Oceń wpływ i zasięg	dotknięte systemy, dane i procesy
8	Określ pewność	niska, średnia albo wysoka wraz z argumentami
9	Sklasyfikuj	zdarzenie, false positive, obserwacja lub możliwy incydent
10	Eskaluj albo zamknij	odbiorca, priorytet, następny krok lub dowód zamknięcia
11	Udokumentuj	hipoteza, dowody wspierające i przeczące, braki
12	Zachowaj źródła	oryginały, hash, kontrola dostępu i rejestr eksportu

Jeżeli korelacja wskazuje możliwe naruszenie, przejdź do procesu z lekcji Reagowanie na incydenty. Nie wykonuj działań destrukcyjnych i nie izoluj systemu bez właściciela decyzji, oceny wpływu oraz procedury awaryjnej.

Poufność, integralność i dostępność

Ochrona logów i materiału analitycznego

Kontrole ochrony logów
Obszar	Praktyka	Przykładowy dowód
Kontrola dostępu	role i dostęp tylko dla osób wykonujących zadanie	lista uprawnień i przegląd
Minimalne uprawnienia	oddziel odczyt, administrację i eksport	konto tylko do odczytu
Integralność	hash, nośnik tylko do odczytu lub magazyn niezmienny	manifest i ponowna kontrola
Retencja	czas wynikający z ryzyka, prawa i potrzeb reakcji	polityka oraz kontrola usuwania
Centralizacja	kopie poza analizowanym hostem	monitoring dopływu i pojemności
Transmisja	uwierzytelniony i szyfrowany kanał	konfiguracja TLS i test dostarczenia
Czas	NTP, strefa i jakość zegara	monitor odchylenia oraz źródło czasu
Odporność	kopia, pojemność i procedura awarii kolektora	test odtworzenia i alert braku danych
Prywatność	minimalizacja danych i ograniczenie widoczności	maskowanie eksportu oraz uzasadnienie
Eksport	kto, co, kiedy, dlaczego i komu przekazał	rejestr operacji; hash nie zastępuje chain of custody

SHA-256 wykrywa zmianę względem manifestu, ale nie dowodzi, kto pozyskał plik ani komu go przekazano. Pełny łańcuch nadzoru wymaga udokumentowanego źródła, czasu, osoby, celu, przechowywania i każdego przekazania.

Bez gotowych odpowiedzi

Raport, pytania i zadanie samodzielne

Szablon raportu — CYB-05

Pytania kontrolne

Które formaty czasu można przeliczyć bez dodatkowych założeń, a które wymagają inwentarza?
Dlaczego czas odebrania komunikatu przełącznika może poprzedzać zapisany czas zdarzenia?
Jak DHCP pomaga połączyć dwa adresy IP z jednym urządzeniem i czego nadal nie potwierdza?
Które dane rozstrzygają, czy sekwencja portów mieściła się w autoryzacji CHG-LAB-042?
Dlaczego udane logowanie po błędach nie jest automatycznie incydentem?
Jak odróżnić brak zdarzenia od braku telemetrii?
Które źródło może potwierdzić żądanie HTTP, ale nie intencję klienta?
Kiedy poziom pewności powinien pozostać niski mimo alertu o wysokiej ważności?
Jak udokumentować zamknięcie false positive, aby regułę można było bezpiecznie dostroić?
Dlaczego SHA-256 nie stanowi samodzielnie pełnego łańcucha nadzoru?

Zadanie samodzielne

Wybierz jeden alert spoza sekwencji A i D. Zbuduj chronologię UTC, wskaż co najmniej trzy źródła lub uzasadnij ich brak, opisz dwie konkurencyjne hipotezy, przypisz poziom pewności i przygotuj defensywny następny krok. Nie uzupełniaj braków założeniami przedstawionymi jako fakty.

Kontrolowane zakończenie

Kryteria zakończenia i porządkowanie plików

Kryteria zakończenia

Zweryfikowano wszystkie pozycje manifestu SHA-256 przed analizą.
Zachowano oryginały, a transformacje wykonano wyłącznie w raporcie lub kopii roboczej.
Chronologia UTC zawiera surowy czas, założenie strefy, korektę i identyfikator źródła.
Każda sekwencja ma źródła, hipotezę, dowody za i przeciw, braki oraz poziom pewności.
Student odróżnił log, zdarzenie, alert i incydent bez automatycznego uznawania alertu za atak.
Opisano co najmniej dwa możliwe false positive oraz wpływ autoryzacji i właściciela działania.
Luka DNS została oceniona bez przedstawiania braku logu jako dowodu manipulacji.
Decyzje triage prowadzą do defensywnego następnego kroku i chronią materiał źródłowy.

Porządkowanie stanowiska

zapisz raport w lokalizacji wskazanej przez prowadzącego
sprawdź, że oryginały nadal odpowiadają manifestowi
usuń wyłącznie własne kopie robocze po akceptacji raportu
opróżnij kontrolowany katalog tymczasowy zgodnie z polityką
nie usuwaj ani nie modyfikuj materiału źródłowego prowadzącego
odnotuj każdy eksport lub przekazanie plików

Kontrola jakości

Najczęstsze błędy analizy

Gdy dane są sprzeczne, zachowaj obie obserwacje i obniż pewność zamiast dopasowywać wpisy do pierwszej hipotezy.

Sortowanie surowych timestampów bez strefy i korekty zegara.
Mylenie czasu zdarzenia z czasem odebrania przez kolektor.
Łączenie wpisów tylko po adresie IP, mimo zmiany DHCP.
Uznawanie severity alertu za dowód incydentu lub poziom pewności.
Zamykanie alertu jako false positive bez właściciela, okna i zakresu autoryzacji.
Interpretowanie braku logu wyłącznie jako manipulacji.
Nadpisywanie oryginału podczas normalizacji lub usuwanie niepasujących wpisów.
Udostępnianie pełnego zbioru, gdy odbiorca potrzebuje tylko zminimalizowanego wycinka.

Od telemetrii do decyzji

Podsumowanie i oficjalne źródła

Korelacja zwiększa kontekst, lecz nie usuwa ograniczeń źródeł. Dobra analiza zachowuje oryginał, normalizuje czas jawnie, testuje konkurencyjne hipotezy i kończy się uzasadnionym działaniem defensywnym.

Ćwiczenie kończy się raportem analitycznym, nie wdrożeniem platformy SIEM. Celem jest zrozumienie procesu, który później można automatyzować w narzędziu dobranym do wymagań organizacji.

Lista: Sieci komputerowe

CYB-04 — Podatności i ryzyko CYB-06 — Zabezpieczanie logów i PCAP