Krytyczne Logi Do Monitorowania- Przewodnik Dla Analityków SOC

securitybeztabu.pl 4 tygodni temu

1. Wprowadzenie

Logi to cyfrowe ślady każdej aktywności – pełnią rolę chronologicznego zapisu zdarzeń zachodzących w systemach, sieciach i aplikacjach. W nowoczesnym Centrum Operacji Bezpieczeństwa (SOC) analitycy opierają się na logach, aby wykrywać zagrożenia, analizować incydenty oraz utrzymywać wysoki poziom bezpieczeństwa organizacji. Bez uporządkowanego i odpowiednio monitorowanego systemu logowania, choćby najbardziej zaawansowane rozwiązania ochronne mogą przeoczyć najważniejsze wskaźniki naruszeń (IoC) lub nie wychwycić podejrzanych zachowań występujących równolegle w różnych systemach.

Celem tego przewodnika jest wskazanie, które logi są najważniejsze, dlaczego mają najważniejsze znaczenie oraz jak podejść do ich monitorowania w sposób praktyczny – zarówno z perspektywy początkującego, jak i średniozaawansowanego analityka SOC.

1.1. Znaczenie monitorowania logów w SOC

W każdej większej infrastrukturze IT wolumen surowych danych potrafi być ogromny – same zapory sieciowe (firewalle) mogą generować tysiące wpisów logów na sekundę. Choć te linijki tekstu często wyglądają niepozornie, skrywają w sobie cenne informacje, które pozwalają wykrywać i neutralizować zagrożenia bezpieczeństwa. Skuteczne monitorowanie logów jest najważniejsze z kilku powodów:

Widoczność i kontekst

Logi dostarczają kontekstu – pokazują, co się wydarzyło, kiedy miało miejsce i w jaki sposób zostało wykonane. Taka przejrzystość jest niezbędna, aby odróżnić normalne zachowania od anomalii. Przykładowo, nieoczekiwane podniesienie uprawnień w logach systemu Windows może wskazywać na ruch lateralny wykonywany przez atakującego. Z kolei powtarzające się nieudane próby logowania w środowisku Linux mogą sygnalizować atak brute-force.

Wykrywanie incydentów i reagowanie na zagrożenia

Zautomatyzowane alerty generowane przez systemy SIEM (Security Information and Event Management) bardzo często bazują na podejrzanych wzorcach wykrytych w logach. Dzięki nim analitycy SOC mogą gwałtownie zidentyfikować potencjalny incydent i natychmiast zareagować. Przykładowo, reguły korelacyjne mogą wykryć logowanie użytkownika z dwóch odległych geograficznie lokalizacji w krótkim odstępie czasu, co sugeruje użycie skradzionych danych uwierzytelniających.

Audyt i zgodność z regulacjami

Wiele standardów regulacyjnych – takich jak PCI DSS, HIPAA czy ISO 27001 – wymaga przechowywania logów i ich regularnej analizy. Monitorowanie logów pozwala organizacjom spełniać wymogi zgodności oraz tworzyć pełną ścieżkę audytową, przydatną w trakcie kontroli lub dochodzeń. To właśnie logi są często pierwszym miejscem, które sprawdzają audytorzy, aby potwierdzić skuteczność wdrożonych mechanizmów bezpieczeństwa.

Threat hunting – aktywne poszukiwanie zagrożeń

Poza klasycznym wykrywaniem incydentów, logi stanowią podstawę do proaktywnych działań analitycznych, takich jak threat hunting. Analitycy poszukują nietypowych wzorców – na przykład uruchomienia skryptu PowerShell w środowisku, gdzie zwykle nie jest on używany – aby zidentyfikować ukryte ataki. Dzięki analizie logów w dłuższej perspektywie czasowej można odkryć trendy i techniki przeciwników, które umykają choćby zaawansowanym systemom automatycznym.

Analiza śledcza (forensics)

Gdy dojdzie do incydentu, dobrze ustrukturyzowane logi są nieocenionym źródłem w dochodzeniach cyfrowych. Pomagają odtworzyć linię czasu ataku, wskazać, które systemy zostały naruszone, oraz jakie dane mogły zostać wyprowadzone. Szczegółowe informacje o działaniach użytkowników, połączeniach sieciowych czy wywołaniach systemowych często decydują o tym, czy uda się przypisać incydent do konkretnego źródła, czy też atakujący pozostaną niewykryci.

Przykład z praktyki

Wyobraźmy sobie sytuację, w której analityk SOC zauważa nietypowy ruch wychodzący z krytycznego serwera. Po analizie logów zapory sieciowej, skorelowanych z logami zdarzeń systemu Windows, odkrywa złośliwy proces nawiązujący połączenie z zewnętrznym adresem IP. Szybka analiza ujawnia, iż komunikacja rozpoczęła się tuż po podejrzanym zdarzeniu związanym z podniesieniem uprawnień. Taka korelacja pozwala zespołowi ds. reagowania na incydenty gwałtownie odizolować serwer, powstrzymać zagrożenie i usunąć podatność, zanim dojdzie do wycieku danych.

Praktyczna wskazówka

W systemach Linux możesz skorzystać z polecenia:

journalctl -p warning -r

aby błyskawicznie odnaleźć zdarzenia o wyższym priorytecie w odwrotnej kolejności chronologicznej – co znacznie przyspiesza triage potencjalnych incydentów bezpieczeństwa.

W systemie Windows, przydatne może być użycie narzędzia:

wevtutil qe Security /rd:true /f:text /q:"*" | findstr /i "4624 4625 4634 4672"

które filtruje log zdarzeń bezpieczeństwa pod kątem określonych identyfikatorów zdarzeń (Event ID) związanych z logowaniem (np. udane logowanie, nieudane próby logowania, wylogowanie, nadane uprawnienia uprzywilejowane).

1.2. Zakres i cel przewodnika

Ten przewodnik jest skierowany do początkujących oraz średniozaawansowanych analityków SOC, którzy chcą rozwijać swoje umiejętności w zakresie monitorowania logów. Obejmuje on najczęstsze źródła logów – takie jak systemy operacyjne, sieci, aplikacje i narzędzia bezpieczeństwa – oraz podkreśla, na co warto zwracać uwagę w każdym z tych obszarów. Koncentrując się na najistotniejszych logach i pokazując ich znaczenie w strategii bezpieczeństwa organizacji, przewodnik ma na celu usprawnienie codziennej pracy analityków SOC. W szczególności skupiamy się na następujących zagadnieniach:

Identyfikacja kluczowych źródeł logów

Omówimy logi systemowe (Windows, Linux, macOS), sieciowe (zapory, routery, IDS/IPS), aplikacyjne i bazodanowe, logi związane z bezpieczeństwem (AV, EDR, XDR), logi z chmury (AWS, Azure, GCP), logi kontenerów (Docker, Kubernetes) oraz logi z urządzeń IoT, SCADA i OT. Skupimy się na tym, dlaczego każda z tych kategorii jest krytyczna, jak zbierać te dane oraz które zdarzenia są najbardziej charakterystyczne dla potencjalnych incydentów bezpieczeństwa.

Przedstawienie praktycznych technik monitorowania

Od reguł korelacyjnych po detekcję anomalii – omówimy metody, które pozwalają przekształcać surowe logi w użyteczne informacje. Zajmiemy się również takimi tematami jak retencja logów, ich zabezpieczenie czy najlepsze praktyki związane z klasyfikacją danych – tak, aby logi zawierające informacje wrażliwe były odpowiednio chronione.

Przykłady z życia wzięte

Każdy typ logów wiąże się z innym zestawem wyzwań i wektorów ataku. Przeanalizujemy realistyczne scenariusze – takie jak wykrywanie ruchu lateralnego, eskalacji uprawnień czy złośliwych przesyłek plików – i pokażemy, jak logi pełnią rolę kluczowego źródła dowodów w takich przypadkach.

Przegląd narzędzi wspierających analitykę

Narzędzia SIEM (Security Information and Event Management) oraz SOAR (Security Orchestration, Automation, and Response) stanowią serce nowoczesnych SOC. W przewodniku wyjaśnimy, jak platformy te integrują się z różnymi źródłami logów, jak automatyzują generowanie alertów oraz jak wspierają orkiestrację działań reakcyjnych.

Zachęta do ciągłego rozwoju

Zagrożenia cybernetyczne nieustannie ewoluują – podobnie jak dobre praktyki związane z logowaniem i monitorowaniem. Dlatego w przewodniku znajdziesz odniesienia do rzetelnych źródeł, takich jak dokument NIST SP 800-92 (Guide to Computer Security Log Management) czy oficjalna dokumentacja dostawców, np. Microsoft Windows Event Log – aby wspierać Cię w dalszym samokształceniu.

Dzięki skupieniu się na powyższych obszarach, przewodnik ma za zadanie wyposażyć analityków SOC w wiedzę i praktyczne umiejętności, które pozwolą skutecznie priorytetyzować logi i wykrywać potencjalne naruszenia bezpieczeństwa zanim eskalują. Poprzez połączenie teorii z realnymi przykładami, czytelnik nabierze pewności w budowaniu strategii logowania, konfigurowaniu alertów i prowadzeniu pogłębionych analiz incydentów.

2. najważniejsze typy logów

2.1. Logi systemowe (Windows, Linux, macOS)

Logi systemowe stanowią fundament działań związanych z wykrywaniem incydentów oraz reagowaniem na nie. To właśnie one dostarczają analitykom SOC podstawowych danych umożliwiających badanie nietypowych zdarzeń, śledzenie aktywności użytkowników i diagnozowanie zagrożeń bezpieczeństwa. Choć logi systemowe w systemach Windows, Linux i macOS różnią się strukturą i formatem, wszystkie mają wspólny cel – rejestrować najważniejsze zdarzenia związane z działaniem systemu operacyjnego. Zrozumienie, jak działają, co zawierają i jak je interpretować, jest najważniejsze dla wszystkich analityka SOC.

Logi Windows

Najczęstsze źródła logów

System Log (Log systemowy) – rejestruje zdarzenia generowane przez system operacyjny Windows i jego wbudowane usługi, takie jak problemy ze sterownikami, uruchamianie i zatrzymywanie usług oraz komunikaty jądra systemu.
Application Log (Log aplikacji) – zawiera zdarzenia generowane przez zainstalowane oprogramowanie, takie jak błędy, ostrzeżenia i informacje z baz danych czy narzędzi biurowych.
Security Log (Log zabezpieczeń) – skupia się na zdarzeniach związanych z bezpieczeństwem: próby logowania, blokady kont, przypisania uprawnień. Wykorzystywany w audytach i analizach śledczych.
Inne logi – system Windows generuje także logi dedykowane dla określonych usług, np. DFS Replication czy PowerShell. Znajdziesz je w „Applications and Services Logs” w Podglądzie zdarzeń (Event Viewer).

Praktyczne wskazówki monitorowania

Event Viewer (Podgląd zdarzeń) – wbudowane narzędzie do przeglądania i filtrowania logów według poziomu ważności (Critical, Error, Warning, Information) lub identyfikatora zdarzenia (Event ID).
Filtrowanie i wyszukiwanie – stosuj filtry XML w Event Viewerze lub używaj PowerShella do wyszukiwania konkretnych zdarzeń, np.:
- 4624 – pomyślne logowanie
- 4625 – nieudana próba logowania
- 4672 – przypisanie specjalnych uprawnień
- 4688 – utworzenie nowego procesu
- 4648 – logowanie przy użyciu jawnie podanych poświadczeń
Logowanie PowerShell – włącz Module Logging oraz Script Block Logging, aby rejestrować potencjalnie podejrzane polecenia lub ukrytą aktywność. Szczegóły znajdziesz w dokumentacji Microsoftu.
Przykład: filtrowanie logów zabezpieczeń w PowerShell
Get-WinEvent -LogName Security | Where-Object { $_.Id -in 4624, 4625 }
To polecenie pozwala wyciągnąć logi z udanymi i nieudanymi próbami logowania, co ułatwia szybkie wykrycie nietypowej aktywności.

Logi Linux

Syslog i Journald

Większość dystrybucji Linuksa wykorzystuje syslog lub systemd-journald do zbierania i zarządzania logami:

/var/log/syslog lub /var/log/messages – ogólne logi systemowe zawierające zdarzenia informacyjne i niekrytyczne.
/var/log/auth.log lub /var/log/secure – logi związane z uwierzytelnianiem: logowania SSH, użycie sudo, próby brute-force.
/var/log/kern.log – zdarzenia jądra systemu (kernel), przydatne przy diagnozie problemów sprzętowych lub aktywności rootkitów.
Journal Logs (dystrybucje oparte na systemd) – wszystkie logi zapisywane w formacie binarnym, dostępne przez journalctl.

Kluczowe obszary do monitorowania

Uwierzytelnianie – obserwuj nieudane próby logowania, nowe konta użytkowników w /etc/passwd, nagłe zmiany użycia sudo.
Zadania cron – przeglądaj /var/log/cron w poszukiwaniu nieautoryzowanych zadań – przeciwnicy często używają cron do utrzymywania dostępu.
Komunikaty kernela – powtarzające się ostrzeżenia lub błędy mogą wskazywać na problemy sprzętowe lub ukrytą aktywność malware.
Logi usług – monitoruj logi Apache, Nginx, SSH itp. (np. /var/log/apache2/access.log, /var/log/nginx/access.log, /var/log/secure) pod kątem nietypowego ruchu i prób logowania.

Przykład: użycie journalctl

# Wyświetlenie wszystkich logów związanych z SSH journalctl -u sshd # Filtrowanie logów w określonym zakresie czasu journalctl --since "2023-01-01" --until "2023-01-31"

Pozwala to gwałtownie przeszukiwać logi konkretnej usługi w zadanym przedziale czasowym.

Logi macOS

Unified Logging System (Ujednolicony system logowania)

Od wersji macOS Sierra (10.12), Apple wprowadziło jednolity system logowania zapisujący zdarzenia w ustrukturyzowanym formacie:

Aplikacja Console – pozwala przeglądać logi systemowe, raporty diagnostyczne i logi awarii.
Narzędzie log (Terminal) – potężne polecenie terminalowe do filtrowania, strumieniowania i wyszukiwania logów.

Przykłady:

# Strumieniowe podglądanie logów w czasie rzeczywistym log stream --level=info # Wyszukiwanie błędów procesu SSH log show --predicate 'process == "sshd" AND eventMessage CONTAINS "Failed password"'

Podsystemy i kategorie – logi klasyfikowane są wg. podsystemów (np. com.apple.networking) i kategorii (connection), co ułatwia ich filtrowanie.

Logi związane z bezpieczeństwem

/var/log/system.log – podstawowy plik logów systemowych, często pierwszy punkt analizy.
Apple System Log (ASL) – starszy system logowania, współistnieje z nowszym Unified Logging; przydatny w starszych wersjach macOS.
Logi uwierzytelnienia – logi z prób logowania lokalnego lub SSH mogą pojawić się w /var/log/asl/ lub w interfejsie Unified Logging.

Monitorowanie i detekcja

Powtarzające się błędy logowania – jak w Linuksie, nieudane próby logowania SSH lub niespodziewane uruchamianie procesów są sygnałami ostrzegawczymi.
Logi awarii – napastnicy mogą celowo powodować awarie narzędzi bezpieczeństwa – raporty z crashów mogą wskazać na próbę manipulacji.
Korzystaj z narzędzi systemowych – aplikacja Console umożliwia filtrowanie logów według procesu lub typu komunikatu. Dokumentacja Apple dotycząca Unified Logging zawiera zaawansowane informacje o analizie logów.

Rozważania międzyplatformowe

Aspekt	Windows	Linux	macOS
Pliki logów	Event Viewer (System, Security itd.)	/var/log/syslog, /var/log/auth.log itd.	Unified Logging System (log show, log stream)
Popularne narzędzia	PowerShell, Event Viewer, WMI	tail, grep, awk, journalctl	Aplikacja Console, narzędzie log w terminalu
Fokus alertów	Event ID (np. 4624, 4625), zmiany w politykach	błędy SSH, eskalacje uprawnień, błędy systemd	błędy SSH, awarie systemu, nietypowe komunikaty z podsystemów
Centralizacja	Windows Event Forwarding (WEF), Sysmon do SIEM	Rsyslog, Syslog-ng, systemd-journald do SIEM	Eksport logów przez log collect lub strumieniowanie do SIEM

Agenci logowania i centralizacja

Wiele organizacji decyduje się na przekazywanie logów z systemów Windows, Linux i macOS do centralnej platformy SIEM lub rozwiązania do zarządzania logami. Dzięki temu możliwe jest efektywne korelowanie zdarzeń, detekcja zagrożeń i spełnianie wymagań audytowych.

Windows:

Windows Event Forwarding (WEF) – do przesyłania logów zdarzeń z wielu maszyn do jednego hosta.
Sysmon – do szczegółowego logowania działań na poziomie procesów i połączeń sieciowych.
Agenci zewnętrzni – tacy jak NXLog czy Splunk Universal Forwarder, umożliwiają elastyczne formatowanie i przesyłanie logów do różnych systemów SIEM.

Linux:

Rsyslog i Syslog-ng – klasyczne usługi logowania, umożliwiające przesyłanie logów na zdalne serwery.
systemd-journald – w systemach opartych na systemd, można przesyłać logi dzięki wtyczek lub narzędzi pomocniczych.
Beats (Filebeat, Metricbeat) – lekkie agenty od Elastic do zbierania i przesyłania logów oraz metryk do Elastic Stack lub innych platform SIEM.

macOS:

Apple nie oferuje natywnego, scentralizowanego forwardowania logów – dlatego stosuje się rozwiązania zewnętrzne.
Osquery – umożliwia monitorowanie systemu i rejestrowanie aktywności na poziomie zapytań (query-based logging).
Agenci firm trzecich, tacy jak Splunk, Datadog, czy Elastic Agent, umożliwiają zbieranie logów i ich wysyłkę do centralnego systemu SIEM, tworząc „jedno okno widoku” (single pane of glass).

2.2. Logi sieciowe (Firewall, Router, IDS/IPS)

Logi pochodzące z urządzeń sieciowych oraz systemów bezpieczeństwa należą do najbardziej krytycznych źródeł danych w Centrum Operacji Bezpieczeństwa (SOC). Analizując logi z zapór sieciowych (firewalli), routerów oraz systemów IDS/IPS, analitycy SOC uzyskują wgląd w ruch sieciowy, zdarzenia bezpieczeństwa oraz potencjalne anomalie. Taka widoczność jest niezbędna, aby wcześnie wykryć złośliwe zachowania i odpowiednio zareagować, zanim zagrożenia rozprzestrzenią się w środowisku IT.

Poniżej przedstawiono najważniejsze pojęcia, dobre praktyki oraz scenariusze z życia wzięte, które pomagają efektywnie pracować z logami sieciowymi.

1. Logi z firewalli

Zapory sieciowe to często pierwsza linia obrony – filtrują ruch na podstawie wcześniej zdefiniowanych reguł. Monitorowanie logów z firewalli dostarcza informacji zarówno o połączeniach dozwolonych, jak i blokowanych.

1.1. Typowe pola w logach firewalli

Standardowy log z firewalla zawiera następujące pola:

Timestamp – data i godzina rejestracji zdarzenia
Source IP / Destination IP – adresy IP klienta i serwera
Source Port / Destination Port – porty źródłowe i docelowe wykorzystywane przez usługi lub aplikacje
Protocol – używany protokół sieciowy (np. TCP, UDP, ICMP)
Action – informacja o decyzji firewalla: allowed, denied, dropped, rejected
Rule or Policy Name – nazwa reguły, która wygenerowała wpis w logu

Nowoczesne zapory (szczególnie klasy NGFW – Next Generation Firewall) mogą dodatkowo logować informacje o aplikacjach, użytkownikach (jeśli zintegrowane z systemami tożsamości), nazwach interfejsów (np. eth0, WAN, LAN), rozmiarze pakietów czy powodach odrzucenia.

PoleOpisPrzykładowa wartość

Timestamp	Data i godzina zdarzenia	2025-01-25 10:15:32
Source IP	IP źródłowy	192.168.10.5
Destination IP	IP docelowy	10.0.5.20
Source Port	Port źródłowy TCP/UDP	53452
Destination Port	Port docelowy TCP/UDP	443
Protocol	Protokół sieciowy	TCP
Action	Działanie zapory	Allowed
Rule Name	Nazwa reguły lub polityki	Block_Telnet

1.2. Praktyczne przypadki użycia

Zablokowane próby połączeń – monitorowanie wielokrotnych prób nawiązania połączenia do wrażliwych portów (np. 22 – SSH, 3389 – RDP) może ujawnić ataki typu brute-force lub skanowanie portów.
Nietypowy wolumen ruchu – nagły wzrost ruchu z jednego adresu IP lub podsieci może świadczyć o próbie ataku DoS lub DDoS.
Monitoring ruchu wychodzącego i przychodzącego – połączenia wychodzące do podejrzanych adresów IP lub do krajów, z którymi organizacja nie prowadzi działalności, mogą być sygnałem, iż host został przejęty (np. malware próbujące się skomunikować z C&C).

1.3. Przykład analizy logów z firewalla w SIEM (Splunk)

Poniżej znajduje się przykładowe zapytanie w Splunku, które filtruje zablokowane połączenia na porcie TCP 3389 (zdalny pulpit – RDP):

index=firewall_logs action=DENY dest_port=3389 | stats count by src_ip, dest_ip, action, rule_name

To zapytanie pozwala zidentyfikować adresy źródłowe (src_ip), które wielokrotnie próbują połączyć się z usługami RDP, mimo iż połączenia te są odrzucane. Może to świadczyć o próbie ataku lub skanowania usług zdalnych.

2. Logi z routerów

Routery pełnią kluczową rolę w infrastrukturze sieciowej – odpowiadają za przekazywanie pakietów pomiędzy różnymi sieciami oraz zarządzanie tablicami routingu. Generowane przez nie logi koncentrują się głównie na komunikatach systemowych, aktualizacjach routingu oraz błędach interfejsów, a nie na danych związanych z konkretnymi aplikacjami. Mimo to, są one niezwykle istotne z punktu widzenia ogólnej widoczności i diagnostyki, zwłaszcza w środowiskach o rozproszonej architekturze.

2.1. Typy logów z routerów

Logi systemowe i zdarzeń – zawierają informacje o restartach urządzenia, awariach oprogramowania, zmianach w konfiguracji
Logi protokołów routingu – obejmują dane związane z działaniem protokołów takich jak BGP, OSPF, EIGRP itp.
Logi interfejsów – rejestrują zmiany stanu interfejsów (up/down), błędy pakietów (np. błędy CRC, kolizje), oraz statystyki zużycia pasma
Logi uwierzytelniania – dokumentują udane i nieudane logowania przez SSH, Telnet lub dostęp lokalny przez konsolę

Logi routerów najczęściej wykorzystują standardowy format Syslog (np. urządzenia Cisco, które stosują poziomy ważności 0–7). Integracja tych logów z platformą SIEM pozwala na korelowanie zmian w topologii sieciowej z incydentami bezpieczeństwa – na przykład, gdy interfejs routera przestaje działać tuż przed wykryciem zagrożenia w danym segmencie.

2.2. Przykład: komunikaty Syslog z routera Cisco

Routery Cisco wysyłają komunikaty Syslog z określonym poziomem ważności. Przykładowy wpis może wyglądać tak:

<189>Jan 25 10:25:10 MY-ROUTER: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up

Interpretacja komunikatu:

189 – oznacza priorytet Syslog (łączący poziom ważności i obiekt)
%LINK-3-UPDOWN – informuje o zmianie stanu łącza; „3” oznacza poziom błędu (Error)
Treść komunikatu wskazuje, iż interfejs GigabitEthernet0/1 zmienił stan na up

W systemie SIEM warto filtrować komunikaty typu %LINK-3-UPDOWN, aby śledzić nieoczekiwane zmiany stanu interfejsów. Nagłe wyłączenie interfejsu może wskazywać na problem fizyczny, błędną konfigurację lub choćby celowe działanie mające na celu zakłócenie segmentów sieci.

3. Logi IDS/IPS

Systemy wykrywania włamań (IDS – Intrusion Detection System) oraz systemy zapobiegania włamaniom (IPS – Intrusion Prevention System) monitorują ruch sieciowy w poszukiwaniu oznak złośliwej aktywności, naruszeń polityk bezpieczeństwa lub znanych sygnatur ataków. Podczas gdy zapory sieciowe operują głównie na warstwie transportowej lub sieciowej (Layer 3/4), systemy IDS/IPS analizują ruch aż do warstwy aplikacji (Layer 7), dostarczając głębszego kontekstu na temat potencjalnych zagrożeń.

3.1. IDS vs IPS – podstawowe różnice

IDS (Intrusion Detection System) – wykrywa potencjalne zagrożenia i generuje alerty, ale nie blokuje automatycznie ruchu. Jest pasywnym systemem monitorującym.
IPS (Intrusion Prevention System) – również wykrywa zagrożenia, ale może podejmować działania zapobiegawcze, takie jak blokowanie pakietów, przerywanie sesji lub dynamiczne dodawanie reguł zapory. Działa aktywnie, w czasie rzeczywistym.

3.2. Typowe pola w logach IDS/IPS

Signature ID (SID) – unikalny identyfikator reguły lub sygnatury, która została aktywowana (np. w Snorcie każda reguła ma przypisany SID)
Komunikat alertu / zdarzenia – nazwa lub opis podejrzanej aktywności, np. „ET TROJAN Zeus Tracker”
Poziom ważności (Severity / Priority) – informuje o krytyczności zdarzenia
Source IP / Destination IP / Ports – informacje o przepływie ruchu sieciowego
Action (Działanie) – określa, czy ruch został wykryty, zablokowany, czy przepuszczony

3.3. Praktyczny przykład – Suricata

Suricata to popularny, otwartoźródłowy silnik IDS/IPS, który generuje logi w formacie JSON – gotowe do przetwarzania przez narzędzia SIEM, takie jak Elasticsearch czy Splunk. Przykładowy wpis alertu Suricata może wyglądać następująco:

{ "timestamp": "2025-01-25T10:30:45.123456+0000", "flow_id": 1234567890, "event_type": "alert", "src_ip": "192.168.1.100", "src_port": 53452, "dest_ip": "10.0.5.20", "dest_port": 80, "proto": "TCP", "alert": { "action": "blocked", "gid": 1, "signature_id": 2010935, "rev": 3, "signature": "ET TROJAN Known Malicious Domain", "category": "Trojan Activity", "severity": 2 } }

Co oznacza powyższy wpis?

signature_id: 2010935 – odnosi się do konkretnej reguły w bazie Suricaty, która identyfikuje znaną sygnaturę trojana
action: "blocked" – ruch został aktywnie zablokowany przez Suricatę działającą w trybie IPS
category: "Trojan Activity" – wskazuje na klasyfikację zagrożenia jako aktywność związaną z trojanem

Takie logi dostarczają nie tylko informacji o tym, co zostało zablokowane, ale również dlaczego, co jest nieocenione w kontekście analizy incydentu.

3.4. Scenariusze ataków z życia wzięte

Próby ataku SQL Injection – systemy IDS/IPS analizują ruch HTTP w poszukiwaniu wzorców typowych dla ataków SQLi, takich jak nietypowe znaki w zapytaniach lub manipulacje parametrami URL.
Exploit Kits – jeżeli host próbuje pobrać lub nawiązać połączenie z domeną powiązaną z pakietem exploita, IDS/IPS może wykryć nazwę tej domeny i dopasować ją do znanej sygnatury ataku.
Ruch lateralny (lateral movement) – atakujący mogą próbować przemieszczać się poziomo w sieci, np. dzięki SMB lub RDP. IDS/IPS potrafi wykryć niestandardowe wzorce ruchu, które mogą świadczyć o próbach eskalacji lub rekonesansu wewnętrznego.

4. Parsowanie i analiza logów sieciowych w praktyce

4.1. Zarządzanie logami i integracja z SIEM

Analitycy SOC najczęściej centralizują logi z firewalli, routerów oraz systemów IDS/IPS w systemie SIEM, aby umożliwić korelację i analizę zdarzeń z wielu źródeł. Pozwala to na efektywne łączenie danych i identyfikację powiązanych incydentów.
Przykład: jeżeli IDS wykryje sygnaturę trojana, a firewall zarejestruje ruch wychodzący do podejrzanego adresu IP – SIEM może automatycznie wygenerować alert o wyższym priorytecie.

Przykładowa konfiguracja Logstash do parsowania logów JSON z Suricaty:

input { file { path => "/var/log/suricata/eve.json" type => "suricata" codec => "json" } } filter { if [event_type] == "alert" { mutate { add_tag => ["suricata_alert"] } } } output { elasticsearch { hosts => ["localhost:9200"] index => "suricata-alerts-%{+YYYY.MM.dd}" } }

Powyższa konfiguracja odczytuje plik eve.json generowany przez Suricatę, filtruje zdarzenia typu „alert”, dodaje tag suricata_alert i przesyła dane do Elasticsearcha, indeksując je według daty.

4.2. Reguły korelacyjne

W systemie SIEM można tworzyć reguły korelacyjne, które wykrywają złożone warunki na podstawie danych z różnych źródeł. Przykładowe scenariusze:

Duża liczba zablokowanych połączeń
Jeśli z jednego adresu IP firewall odrzuca więcej niż 100 połączeń w ciągu 5 minut – wygeneruj alert.
Wiele alertów IDS z jednego hosta
Jeśli ten sam host wywołuje 3 różne sygnatury IDS w krótkim czasie – podnieś priorytet incydentu.
Interfejs routera przestaje działać + alerty IDS
Jeśli krytyczny interfejs sieciowy przestaje odpowiadać, a jednocześnie w sąsiednich segmentach sieci pojawia się wzmożona aktywność IDS – rozpocznij śledztwo w kierunku sabotażu lub szeroko zakrojonego naruszenia.

Dobrze zdefiniowane reguły korelacyjne, łączące różne typy logów, pozwalają na skuteczne wykrywanie skoordynowanych ataków oraz zmniejszenie liczby fałszywych alarmów.

5. Wyzwania i dobre praktyki

Wolumen logów
Urządzenia sieciowe mogą generować ogromne ilości danych. Konieczne może być stosowanie filtrów lub próbkowania (sampling), jednak trzeba uważać, aby nie odrzucić istotnych informacji.
Normalizacja
Różni producenci (Cisco, Palo Alto, Fortinet itd.) stosują odmienne formaty logów. Aby umożliwić skuteczną korelację danych, należy ujednolicać nazwy pól (np. src_ip, dest_ip, port, action), niezależnie od źródła.
Szyfrowanie i bezpieczny transport logów
Zapewnij, iż logi przesyłane są bezpiecznym kanałem – np. poprzez Syslog over TLS. Nieszyfrowane logi mogą zostać przechwycone lub zmanipulowane przez atakujących.
Regularne strojenie i aktualizacje
Zarówno reguły IDS/IPS, jak i polityki firewalli wymagają regularnych przeglądów i aktualizacji, aby odzwierciedlały zmieniające się środowisko sieciowe i nowe zagrożenia.
Synchronizacja czasu
Wszystkie urządzenia powinny mieć poprawnie skonfigurowany NTP (Network Time Protocol). Spójne znaczniki czasu są niezbędne do prawidłowej korelacji zdarzeń i rekonstrukcji chronologii incydentów.

2.3. Logi aplikacyjne i bazodanowe

Logi aplikacyjne rejestrują zdarzenia i zachowania bezpośrednio związane z funkcjonowaniem aplikacji. Mogą obejmować interakcje użytkowników, operacje systemowe, wyjątki, komunikaty debugowania oraz niestandardowe zdarzenia definiowane przez programistów.
Z kolei logi bazodanowe dokumentują wszystkie działania związane z transakcjami danych, zmianami w strukturze bazy (schemacie), uwierzytelnianiem, błędami oraz wąskimi gardłami wydajnościowymi.
W połączeniu, oba typy logów oferują pełny obraz działania systemu i dostępu do danych – co ma najważniejsze znaczenie przy wykrywaniu nieautoryzowanej aktywności, problemów wydajnościowych i wszelkich anomalii.

Poniżej znajdziesz najważniejsze zagadnienia, dobre praktyki i przykłady z życia, które pomogą Ci skutecznie monitorować oraz analizować logi aplikacyjne i bazodanowe.

Zrozumienie logów aplikacyjnych

Najczęstsze typy logów aplikacyjnych

Logi błędów i wyjątków (Error/Exception Logs)
Rejestrują nieoczekiwane zachowania oraz ślady stosu (stack trace). Generowane są zwykle przez frameworki takie jak Log4j i Logback w Javie, biblioteka logging w Pythonie, czy wbudowane mechanizmy w .NET.
Logi debugowania i diagnostyczne (Debug/Diagnostic Logs)
Zawierają szczegółowe informacje o wewnętrznych operacjach aplikacji – przydatne w trakcie rozwoju lub analizy problemów. Zwykle są bardzo obszerne, dlatego w środowisku produkcyjnym uruchamiane są tylko w razie potrzeby.
Logi transakcyjne lub zdarzeniowe (Transaction/Event Logs)
Aplikacje obsługujące transakcje użytkowników – np. systemy e-commerce – generują logi opisujące każdy etap przepływu użytkownika: dodanie do koszyka, płatność, potwierdzenie zamówienia itd.
Logi audytowe (Audit Logs)
Wytwarzane w celach zgodności lub bezpieczeństwa. Śledzą dostęp użytkowników, zmiany ról czy aktualizacje konfiguracji. Pomagają odpowiedzieć na pytanie: kto, co, kiedy i dlaczego zrobił.

Frameworki i formaty logowania

Nowoczesne aplikacje korzystają z ustandaryzowanych frameworków logowania:

Java: Log4j, Logback
.NET: Serilog, NLog
Python: logging
Node.js: winston, pino

Frameworki te pozwalają konfigurować poziomy logów (np. error, info, debug), ustalać format (np. JSON) i definiować cele wyjściowe – konsola, pliki, systemy agregujące logi.
Spójność formatu logów ma ogromne znaczenie dla ich późniejszego parsowania i korelacji w narzędziach SIEM.

Przykład konfiguracji – Log4j2 (Java)

Ten fragment konfiguruje plik application.log, logując znacznik czasu, nazwę wątku, poziom logu i samą wiadomość.
Dzięki ustawieniu poziomu info dla loggera aplikacyjnego oraz error dla loggera głównego, ogranicza się nadmiarowe logowanie.

Monitorowanie logów aplikacyjnych w praktyce

Zdefiniuj wzorzec normalnego działania
Znajomość normalnych wartości (np. średnie czasy odpowiedzi, typowe błędy) pomaga wykrywać anomalie – np. nagły wzrost liczby wyjątków może wskazywać na atak lub błędną konfigurację.
Wyszukuj wzorców ataków
Nieautoryzowane próby logowania, podejrzane parametry w URL (np. sondaże SQLi), nadużycia sesji – to wszystko może pojawiać się w logach aplikacyjnych. Zwiększona liczba błędów 404 lub użycie nietypowych metod HTTP również może być oznaką skanowania lub ataku.
Integracja z SIEM
Aby skorelować logi aplikacyjne z danymi systemowymi czy sieciowymi, należy przesyłać je do SIEM-a (np. Splunk, IBM QRadar, Elastic Security).
Przykład: zdarzenie „wiele nieudanych logowań” w aplikacji + wpis w logu firewalla o skanowaniu z danego IP = próba intruzji.
Alerty i progi
Definiowanie progów (np. liczba błędów w danym przedziale czasu, spadek liczby transakcji, wzrost wyjątków) umożliwia szybką reakcję.
Narzędzia z ML (np. Azure Sentinel, AWS Security Hub) potrafią wykrywać anomalie bez konieczności ustawiania reguł statycznych.
Polityka retencji
Logi aplikacyjne mogą gwałtownie rosnąć. Potrzebna jest przemyślana polityka retencji, uwzględniająca wymogi prawne i koszty przechowywania. Standardy zgodności (np. PCI DSS, HIPAA) często określają minimalny czas przechowywania określonych typów logów.

Zrozumienie logów bazodanowych

Logi bazodanowe dostarczają informacji o działaniach wykonywanych wewnątrz silnika bazy danych – od transakcji i zapytań po błędy i zmiany uprawnień. W połączeniu z logami aplikacyjnymi umożliwiają pełną analizę zachowania aplikacji oraz sposobu, w jaki dane są przetwarzane i wykorzystywane.

Kluczowe typy logów bazodanowych

Logi transakcyjne
Rejestrują każdą zmianę w danych – są niezbędne do odzyskiwania danych (recovery) oraz analizy śledczej. Przykładowo, w Microsoft SQL Server log transakcji śledzi wszystkie modyfikacje w kolejności ich wykonania, co umożliwia odzyskiwanie danych „point-in-time”.
Logi błędów
Zawierają informacje o krytycznych problemach – takich jak błędy uruchamiania serwera, uszkodzenia struktury bazy czy nieprawidłowości wpływające na dostępność. Przykład: error.log w MySQL czy alert.log w Oracle.
Logi zapytań ogólnych (MySQL) / Logi audytowe (różni dostawcy)
Rejestrują wszystkie zapytania wysłane do serwera lub aktywność kont. Są nieocenione w wykrywaniu prób SQL injection, podejrzanego eksportu danych czy eskalacji uprawnień.
Logi zapytań wolnych (Slow Query Logs)
Obecne w MySQL, PostgreSQL – rejestrują zapytania przekraczające określony czas wykonania. Mogą wskazywać problemy wydajnościowe lub celowe przeciążenie bazy (np. w ramach ataku DoS).

Praktyczne strategie monitorowania logów bazodanowych

Regularne przeglądanie zapytań podejrzanych
Analizuj zapytania, które usuwają lub zmieniają najważniejsze tabele bez powiązania z procesem zatwierdzania zmian. Zwracaj uwagę na zapytania typu SELECT * lub masowe eksporty wykonywane poza godzinami pracy.
Wykrywanie nadużyć uprawnień
Jeśli użytkownik z ograniczonymi uprawnieniami zaczyna wykonywać zapytania typowe dla administratora, może to wskazywać na przejęcie konta lub eskalację przywilejów. Wdrożenie zasady minimalnych uprawnień i korelacja logów pomaga wychwycić takie anomalie.
Analiza wzorców błędów
Powtarzające się błędy typu „invalid column name” lub „syntax error” mogą świadczyć o próbach ataków SQL injection. SIEM powinien zawierać reguły korelacyjne wykrywające takie powtarzalne błędy z jednego źródła IP.
Wskaźniki wydajnościowe
Logi informujące o dużym zużyciu zasobów lub timeoutach mogą sygnalizować próby ataku typu brute-force lub DoS na warstwę bazy danych.

Przykładowe konfiguracje i zapytania

MySQL

Włączenie logu zapytań ogólnych:

SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/log/mysql/general.log';

Włączenie logu zapytań wolnych:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2; -- zapytania > 2 sekundy będą logowane

Uwaga: pełne logowanie wszystkich zapytań może obciążyć bazę, dlatego warto je włączać tymczasowo lub przesyłać logi do zewnętrznego systemu logowania (np. ELK).

PostgreSQL

Konfiguracja logowania w pliku postgresql.conf:

logging_collector = on log_directory = 'pg_log' log_filename = 'postgresql-%a.log' log_statement = 'all' log_min_duration_statement = 2000 # zapytania dłuższe niż 2 ms

Ustawienie log_statement = all generuje bardzo duży wolumen danych – zwykle zbyt obszerny dla środowisk produkcyjnych.

Scenariusze z życia wzięte

Wykrycie wycieku danych (data exfiltration)
Analityk SOC zauważa podejrzane parametry w logach aplikacji REST API. Po korelacji z logami bazy danych wykrywa dużą liczbę zapytań SELECT pobierających dane klientów. Dodatkowa analiza logów sieciowych pokazuje transfer danych na zewnętrzny adres IP. Wszystkie źródła wskazują na trwający incydent.
Audyt zgodności (compliance)
W aplikacji bankowej wymagane jest pełne audytowanie każdej transakcji. Przegląd logów aplikacji (warstwa logiki) oraz logów transakcyjnych bazy danych (ostateczne zmiany danych) pozwala potwierdzić zgodność każdego wpłaty i wypłaty z procedurami.
Identyfikacja ataków na wydajność (resource exhaustion)
Seria wolnych zapytań początkowo wygląda jak zwykły problem wydajności. Jednak korelacja logów ujawnia, iż zapytania były celowo złożone i generowane przez atakującego. Alerty SIEM wskazują na jednoczesne błędy 503 w warstwie aplikacji, co potwierdza atak typu DoS.

Porównanie typów logów i ich znaczenia

Typ loguPrzykładyTypowe zastosowaniePotencjalny wgląd bezpieczeństwa

Błędy / wyjątki	Ślady stosu, odwołania do linii kodu	Debugowanie awarii, analiza błędnych modułów	Częste wyjątki mogą świadczyć o próbach ataku lub manipulacji wejścia
Transakcje	Logi e-commerce, transakcje bankowe	Audyt poprawności operacji biznesowych	Wykrywanie fałszywych lub nieautoryzowanych transakcji
Audyt (app & DB)	Działania użytkownika, zmiany ról	Zgodność z przepisami, analiza odpowiedzialności	Identyfikacja nadużyć administracyjnych, eskalacji przywilejów
Zapytania wolne	Zapytania przekraczające próg czasowy	Optymalizacja wydajności	Detekcja ataków typu DoS, przeciążenie systemu

Pamiętaj: przy zbieraniu i analizie logów warto je normalizować – ujednolicić nazwy pól (np. timestamp, user_id, hostname) – tak, by można je było skutecznie korelować między różnymi źródłami.
Systemy takie jak ELK Stack umożliwiają tworzenie ujednoliconych dashboardów, które łączą wgląd w logi aplikacyjne, systemowe i bazodanowe.

2.4. Logi bezpieczeństwa (AV, EDR, XDR)

Logi generowane przez rozwiązania antywirusowe (AV), systemy wykrywania i reagowania na zagrożenia na poziomie końcówek (EDR) oraz systemy rozszerzonego wykrywania i reagowania (XDR) stanowią najważniejsze źródło informacji w nowoczesnych operacjach SOC. Zapewniają one granularną widoczność zagrożeń dotyczących zarówno pojedynczych stacji roboczych, jak i całego środowiska organizacji.

Poniżej omawiamy podstawy logowania w tych systemach, przykłady z praktyki oraz rekomendacje dotyczące monitorowania logów.

Zrozumienie komponentów

Logi Antywirusowe (AV)

Systemy AV skupiają się na wykrywaniu znanych sygnatur złośliwego systemu oraz blokowaniu podejrzanych plików. Typowe logi AV zawierają:

Wykrycia malware – alerty uruchamiane, gdy plik pasuje do znanej sygnatury lub wykazuje podejrzane zachowanie
Kwarantanna i akcje naprawcze – informacje o plikach, które zostały poddane kwarantannie, usunięte lub unieszkodliwione
Aktualizacje i skany – dane o aktualizacjach sygnatur, wynikach skanów okresowych i skanów na żądanie

Przykład z życia
Tradycyjne narzędzie AV, takie jak Microsoft Defender Antivirus (część Windows Security), generuje wpisy w logach systemu Windows (Event Log):

Event ID 1116 – wykrycie zagrożenia malware
Event ID 5001 – uruchomienie silnika skanowania

Agregacja tych ID w systemie SIEM umożliwia szybkie wykrywanie wzorców infekcji oraz potwierdzenie aktualizacji silnika.

Logi EDR (Endpoint Detection and Response)

Systemy EDR rozbudowują funkcjonalność antywirusa, dostarczając szczegółową telemetrię z urządzeń końcowych, wykrywanie w czasie rzeczywistym i możliwość reagowania na incydenty.

Typowe dane logowane przez EDR:

Tworzenie i kończenie procesów – śledzenie parametrów linii poleceń, kontekstu użytkownika, ścieżek plików
Wskaźniki behawioralne – aktywności takie jak wstrzykiwanie kodu, eskalacja uprawnień, modyfikacje rejestru
Akcje reakcyjne – informacje o izolowaniu hosta, blokowaniu połączeń sieciowych, automatycznych skryptach naprawczych

EDR-y często korelują ciągi zdarzeń, co ułatwia odtworzenie osi czasu ataku. Narzędzia takie jak CrowdStrike Falcon, SentinelOne czy Carbon Black oferują pulpity wyświetlające reguły detekcji (np. zgodne z MITRE ATT&CK) i podejmowane działania.

Przykład analizy logów EDR w Splunku:

index=edr_logs parent_process=PowerShell.exe | stats count by child_process, user, host | where count > 3

To zapytanie wyszukuje procesy potomne uruchamiane przez PowerShell i flaguje te, które pojawiają się zbyt często – co może sugerować użycie technik „living-off-the-land” lub złośliwe skrypty.

Logi XDR (Extended Detection and Response)

XDR rozszerza podejście znane z EDR, obejmując dane z wielu warstw środowiska IT – od punktów końcowych po sieć, chmurę i aplikacje. Celem jest pełna korelacja wykrywania, analizy i reakcji w jednym, zunifikowanym systemie.

Korelacja międzyźródłowa – XDR łączy logi z urządzeń końcowych, bramek pocztowych, dostawców tożsamości i innych, stosując zaawansowaną analitykę
Integracja z chmurą i kontenerami – zbiera telemetrię z platform chmurowych oraz konteneryzowanych środowisk (np. Kubernetes)
Odpowiedź adaptacyjna – dzięki regułom korelacyjnym i uczeniu maszynowemu, XDR może uruchamiać automatyczne playbooki – np. blokować użytkownika, izolować host, dodać regułę na firewallu

Architektury referencyjne XDR

Microsoft 365 Defender – integruje dane z Defender for Endpoint (punkty końcowe), Defender for Office 365 (poczta), Azure AD (tożsamości) i Defender for Cloud Apps
Palo Alto Cortex XDR – przetwarza dane z urządzeń końcowych oraz integruje je z sensorami sieciowymi i firewallami, zapewniając zaawansowaną korelację

Dobre praktyki zbierania logów bezpieczeństwa

Centralizacja logów w SIEM
Agreguj wszystkie logi AV, EDR i XDR w jednej platformie (np. Splunk, Elastic Stack, IBM QRadar), aby zapewnić pełen widok i kontekst przy threat huntingu i analizie alertów.
Ujednolicenie formatu logów
Standaryzuj format logów (np. JSON, Syslog), co ułatwia parsowanie, korelację i długoterminowe przechowywanie.
Odpowiednia retencja logów
Zależnie od wymagań regulacyjnych i modeli zagrożeń, przechowuj logi wystarczająco długo, aby umożliwić analizę APT i ataków wolno rozwijających się.
Korelacja między źródłami
Logi AV często dają ograniczony kontekst – dopiero połączenie z telemetrią z EDR i wzorcami logowań użytkowników pozwala zrozumieć pełen obraz ataku.
Automatyzacja reguł detekcji
Wykorzystuj wbudowane reguły detekcji oraz twórz własne – np. alert, gdy znany, zaufany proces (np. outlook.exe) uruchamia nietypowy proces potomny (np. cmd.exe).
Wzbogacenie o Threat Intelligence
Zasilaj logi źródłami inteligencji zagrożeń (np. VirusTotal, AlienVault OTX), aby potwierdzić, czy wykryty domena lub hash pliku jest znanym zagrożeniem.

Typowe zdarzenia bezpieczeństwa warte monitorowania

Skuteczne monitorowanie bezpieczeństwa polega na wychwytywaniu określonych typów zdarzeń, które mogą świadczyć o trwającym ataku lub naruszeniu polityk bezpieczeństwa. Poniższa tabela przedstawia najważniejsze kategorie zdarzeń, wskaźniki, które warto śledzić, oraz narzędzia wspierające ich analizę:

Typ zdarzeniaKluczowe wskaźnikiPrzykładowe narzędzia

Wykrycia malware	Hashe plików, znane sygnatury, podejrzane zachowanie pliku	Microsoft Defender, McAfee, Symantec
Anomalie behawioralne	Nietypowe modyfikacje rejestru, nietypowe drzewa procesów	CrowdStrike Falcon, SentinelOne
Eskalacje uprawnień	Próby uruchomienia procesów jako administrator	Sysmon + korelacja z logami EDR
Próby eksfiltracji danych	Połączenia do podejrzanych domen, duże transfery danych	Palo Alto Cortex XDR, logi w Splunk
Mechanizmy trwałości	Tworzenie usług, elementów autostartu, zadań cron/scheduler	Sysmon + reguły detekcji EDR

Monitorowanie tych zdarzeń w czasie bliskim rzeczywistemu pozwala analitykom SOC szybciej klasyfikować alerty wysokiego ryzyka i natychmiast inicjować działania izolacyjne.

Praktyczne wskazówki dotyczące monitorowania

Śledź próby remediacji – udane i nieudane
Jeśli antywirus kilkukrotnie próbuje poddać plik kwarantannie, ale bezskutecznie – może to wskazywać na zaawansowane malware lub próby manipulacji ze strony użytkownika.
Monitoruj stan agentów EDR
Upewnij się, iż agenty EDR działają na wszystkich stacjach roboczych. Nagłe przerwanie działania agenta może świadczyć o próbie dezaktywacji zabezpieczeń przez atakującego.
Analizuj skuteczność automatycznych reakcji
Systemy XDR często uruchamiają automatyczne działania (playbooki). Weryfikuj, czy reakcje te są skuteczne i zgodne z procedurami IR obowiązującymi w organizacji.
Korzystaj z dokumentacji producentów
Każdy dostawca AV/EDR/XDR publikuje własne zalecenia dot. zbierania i interpretacji logów. Przykład: Microsoft Defender for Endpoint posiada szczegółowe wytyczne dostępne w dokumentacji Microsoft Docs.

Przykład przebiegu incydentu z użyciem AV, EDR i XDR

Alert AV
Antywirus wykrywa podejrzany plik wykonywalny, którego hash pasuje do znanego malware.
Korelacja w EDR
EDR analizuje drzewo procesów i wskazuje, iż plik został uruchomiony przez nietypowy skrypt PowerShell.
Widoczność XDR
System XDR identyfikuje, iż skrypt został pobrany z niezaufanej domeny, a dzięki integracji z Threat Intelligence wiąże tę domenę z aktywnością znanej grupy APT.
Automatyczna reakcja
XDR lub zintegrowana platforma SOAR podejmuje działania: izoluje stację roboczą, blokuje domenę na firewallu, otwiera zgłoszenie w systemie zarządzania incydentami.
Działania analityka SOC
Analityk bada cały łańcuch zdarzeń, potwierdza usunięcie zagrożenia i aktualizuje reguły detekcji, aby zapobiec podobnym atakom w przyszłości.

Podsumowanie:
Połączenie możliwości logów AV, EDR i XDR w ramach dobrze zaprojektowanej strategii monitorowania bezpieczeństwa umożliwia analitykom SOC szybką reakcję zarówno na typowe zagrożenia (np. malware masowy), jak i na zaawansowane, wieloetapowe ataki (APT). Kluczem jest nie tylko zbieranie logów, ale także ich kontekstowa analiza, korelacja i szybkie podejmowanie decyzji.

2.5. Logi chmurowe (AWS, Azure, GCP) i logi kontenerowe (Docker, Kubernetes)

Platformy chmurowe oraz systemy do orkiestracji kontenerów stały się nieodłącznym elementem nowoczesnych środowisk IT. W kontekście SOC, monitorowanie logów z tych źródeł jest najważniejsze nie tylko dla detekcji zagrożeń, ale również dla zapewnienia zgodności i skutecznego rozwiązywania problemów.

Poniżej znajdziesz przegląd najważniejszych źródeł logów oraz praktyczne wskazówki dotyczące monitorowania środowisk AWS, Azure, Google Cloud Platform (GCP), Docker oraz Kubernetes.

Logi AWS

Typowe źródła logów

CloudTrail Logs
- Cel: Rejestrowanie wywołań API i aktywności konta w usługach AWS.
- Kluczowe pola: eventName, eventSource, awsRegion, sourceIPAddress, userAgent, requestParameters, responseElements.
- Zastosowanie w bezpieczeństwie: Wykrywanie nieautoryzowanych działań – np. nieoczekiwane zmiany w politykach IAM, tworzenie/usuwanie zasobów, logowania z nietypowych lokalizacji.
CloudWatch Logs
- Cel: Centralne logowanie zdarzeń z usług AWS (np. logi systemowe EC2, funkcje Lambda).
- Kluczowe pola: różne w zależności od usługi, zwykle zawierają znacznik czasu, poziom logu (ERROR, WARNING, INFO), wiadomości aplikacyjne.
- Zastosowanie: Korelacja logów systemowych z logami z CloudTrail. Np. awaria instancji EC2 powiązana z próbą nieautoryzowanego dostępu.
VPC Flow Logs
- Cel: Rejestrowanie przepływu ruchu sieciowego (adresy IP, porty, akcje ACCEPT/REJECT).
- Kluczowe pola: srcaddr, dstaddr, srcport, dstport, protocol, action, log-status.
- Zastosowanie: Wykrywanie nietypowego ruchu sieciowego, prób eksfiltracji danych, komunikacji z zewnętrznymi adresami IP.

Praktyczny przykład (AWS CLI)

bashCopyEditaws cloudtrail create-trail \ --name MySecurityTrail \ --s3-bucket-name my-security-logs \ --include-global-service-events

Przechowywanie logów w S3 i dalsze przetwarzanie przez Amazon Kinesis lub narzędzia zewnętrzne (np. Logstash) umożliwia ich analizę w SIEM.

Logi Azure

Typowe źródła logów

Azure Activity Logs
- Cel: Śledzenie operacji zarządzających zasobami (tworzenie, modyfikacje, usuwanie).
- Kluczowe pola: authorization, caller, operationName, resourceId, status.
- Zastosowanie: Detekcja nieautoryzowanego tworzenia zasobów, zmian w grupach zabezpieczeń, prób podniesienia uprawnień.
Azure Monitor Logs (Log Analytics)
- Cel: Zbieranie logów z maszyn wirtualnych, kontenerów, aplikacji i zasobów.
- Kluczowe pola: timestamp, operationId, user, inne pola kontekstowe.
- Zastosowanie: Korelacja sygnałów z różnych źródeł i wykrywanie anomalii.
Diagnostics Logs
- Cel: Szczegółowe logi z usług takich jak Azure Key Vault, App Service czy Azure Storage.
- Zastosowanie: Wykrywanie nadużyć dostępu, nieautoryzowanych działań na danych, nieprawidłowych zachowań aplikacji.

Przykład (PowerShell – Set-AzDiagnosticSetting)

Set-AzDiagnosticSetting -ResourceId /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME> ` -WorkspaceId <AZURE_MONITOR_WORKSPACE_ID> ` -StorageAccountId /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME> ` -Enabled $true

Logi GCP (Google Cloud Platform)

Typowe źródła logów

Cloud Audit Logs
- Cel: Rejestracja zdarzeń administracyjnych i dostępu do danych (odpowiednik AWS CloudTrail).
- Kluczowe pola: protoPayload.serviceName, methodName, resourceName, authenticationInfo.
- Zastosowanie: Wykrywanie eskalacji uprawnień, nieautoryzowanych zmian w konfiguracji usług.
VPC Flow Logs
- Cel: Informacje o przepływie ruchu w sieci VPC.
- Kluczowe pola: srcIP, destIP, srcPort, bytesSent, connectionEstablished.
- Zastosowanie: Analiza aktywności rozpoznawczej, prób eksfiltracji danych.
Cloud Logging
- Cel: Centralna usługa logowania dla GCP, kontenerów, aplikacji niestandardowych.
- Zastosowanie: Korelacja logów z warstwy aplikacyjnej i infrastrukturalnej.

Przykład (gcloud CLI – log sink)

gcloud logging sinks create my-security-sink \ storage.googleapis.com/<BUCKET_NAME> \ --log-filter="resource.type=gce_instance AND severity>=WARNING"

Logi kontenerowe (Docker, Kubernetes)

Środowiska kontenerowe są szczególnie wrażliwe ze względu na ich dynamiczny, efemeryczny charakter. Standaryzacja i centralizacja logów to klucz do efektywnego monitoringu.

Docker

Docker Engine Logs
- Lokalizacja: /var/log/docker.log
- Zastosowanie: Wykrywanie nieautoryzowanego uruchamiania kontenerów, pobierania obrazów z niezaufanych rejestrów.
STDOUT/STDERR logi kontenerów
- Lokalizacja: /var/lib/docker/containers/<container_id>/<container_id>-json.log
- Zastosowanie: Analiza błędów aplikacji, detekcja ataków (np. brute-force, wykorzystanie błędów logiki).
Sterowniki logowania Docker (logging drivers)
- Typy: json-file, syslog, fluentd, gelf, awslogs itd.
- Zastosowanie: Integracja z centralnymi systemami logowania, odporność na manipulacje logami po przejęciu kontenera.

Przykład (uruchomienie kontenera z logowaniem do syslog):

docker run --log-driver=syslog --log-opt syslog-address=tcp://192.168.1.10:514 \ --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" \ my_secure_image

Kubernetes

Logi kontenerów – domyślnie zbierane przez kubelet (/var/log/containers/).
Audit Logs – zapisują akcje użytkowników i systemów w API Kubernetes.
Etcd Logs – rejestrują operacje na kluczach danych klastra.
Logi kontrolerów (Controller Manager, Scheduler) – niezbędne do analizy zachowania klastra i identyfikacji błędów.

W środowiskach Kubernetes warto wdrożyć narzędzia typu Fluentd, Filebeat lub Loki do scentralizowanego zbierania logów.

Logi Kubernetes

Środowiska oparte na Kubernetes oferują elastyczność i skalowalność, ale z punktu widzenia bezpieczeństwa wymagają szczególnego nadzoru. Ze względu na swoją złożoność, Kubernetes generuje wiele typów logów, które – jeżeli są odpowiednio zbierane i analizowane – dostarczają kluczowych informacji o stanie klastra, aktywności użytkowników i potencjalnych zagrożeniach.

1. Logi kontenerów

Zbieranie: Standardowo przy pomocy polecenia kubectl logs <nazwa_poda>, albo z wykorzystaniem agenta logowania (np. Fluentd, Logstash) lub wzorca sidecar.
Zastosowanie w bezpieczeństwie: Wykrywanie podejrzanych błędów aplikacyjnych, np. powtarzające się odpowiedzi 401/403, które mogą wskazywać na próbę ataku brute-force na mechanizm uwierzytelniania.

2. Logi kubelet

Lokalizacja: Ścieżka zależy od dystrybucji systemu operacyjnego – przykładowo /var/log/kubelet.log.
Zastosowanie w bezpieczeństwie: Monitorowanie problemów z harmonogramowaniem kontenerów, prób uruchamiania uprzywilejowanych podów, interakcji wskazujących na możliwe przejęcie węzła.

3. Logi płaszczyzny kontrolnej (Control Plane) – API Server, Scheduler, Controller Manager

Lokalizacja: Zwykle pod /var/log/ na węźle kontrolnym, lub agregowane dzięki centralnego systemu logowania.
Zastosowanie w bezpieczeństwie: Detekcja nieautoryzowanych wywołań API, podejrzanych tworzeń podów lub prób eskalacji uprawnień poprzez role Kubernetes (RBAC).

4. Logi audytowe

Cel: Rejestracja każdego zapytania do serwera API Kubernetes.
Konfiguracja: Włączenie audytu poprzez flagi --audit-log-path oraz --audit-policy-file przy uruchamianiu API Servera.
Zastosowanie w bezpieczeństwie: najważniejsze źródło w śledztwach bezpieczeństwa – umożliwia śledzenie zmian w RBAC, uruchamiania uprzywilejowanych kontenerów itp.

Przykład – plik polityki audytowej (audit-policy.yaml)

apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata resources: - group: "" resources: ["secrets"] - level: RequestResponse resources: - group: "" resources: ["pods/exec"]

Dla zaawansowanej konfiguracji odsyłam do oficjalnej dokumentacji Kubernetes Auditing.

Praktyczne aspekty monitorowania i wskazówki z życia wzięte

Centralizacja logów
Niezależnie od tego, czy korzystasz z AWS CloudWatch, Azure Monitor, Google Cloud Logging, czy samodzielnie hostowanego stosu (np. ELK), centralne zbieranie logów z wielu dostawców chmury i środowisk kontenerowych to podstawa skutecznej korelacji zdarzeń.
Kontrola dostępu do logów
Upewnij się, iż logi – zwłaszcza te zawierające dane wrażliwe (np. poświadczenia, dane osobowe) – są przechowywane w bezpieczny sposób. Skonfiguruj role IAM (lub ich odpowiedniki), aby ograniczyć dostęp tylko do autoryzowanych osób.
Alerty i dashboardy
Buduj precyzyjne alerty. Przykład: alarm w przypadku utworzenia nowego clusterrolebinding, który nadaje uprawnienia cluster-admin.
Polityki retencji logów
Dostosuj czas przechowywania logów do wymagań prawnych i regulacyjnych (np. RODO, PCI DSS). W niektórych branżach wymagane są długie okresy przechowywania, w innych można optymalizować koszty.
Wolumen vs. użyteczność
Redukuj „szum” informacyjny – stosuj filtrowanie, poziomy logowania i próbkowanie (log sampling) dla zdarzeń wysokiego wolumenu, takich jak logi debugowania kontenerów.
Korelacja międzyplatformowa
Podczas analizy incydentu warto łączyć logi kontenerów z logami infrastruktury chmurowej. Przykład: jeżeli wykryto złośliwy kontener, analiza logów z AWS CloudTrail lub GCP Cloud Audit Logs może ujawnić, kto i kiedy go wdrożył.

Wniosek
Dzięki monitorowaniu logów Kubernetes (kontenerów, komponentów klastra i logów audytowych), zespoły SOC uzyskują pełną widoczność w środowiskach opartych na chmurze i kontenerach. Każda platforma udostępnia różne typy logów i możliwości konfiguracji, ale podstawowa zasada pozostaje niezmienna:
potrzebujesz scentralizowanego, niezawodnego i dobrze zorganizowanego systemu logowania, aby skutecznie wykrywać zagrożenia i na nie reagować.

2.6. Logi IoT / SCADA / OT

Urządzenia IoT (Internet of Things), systemy SCADA (Supervisory Control and Data Acquisition) oraz infrastruktura OT (Operational Technology) odgrywają kluczową rolę w nowoczesnym przemyśle – od linii produkcyjnych po sieci energetyczne. Logi generowane przez te systemy dostarczają cennych informacji o stanie operacyjnym, metrykach wydajności oraz potencjalnych zagrożeniach bezpieczeństwa.

Efektywne monitorowanie logów w środowiskach przemysłowych bywa wyzwaniem – ze względu na różnorodność protokołów, niejednolitą architekturę urządzeń, ograniczoną pojemność lokalnych zasobów i wysoką dostępność wymaganą w środowiskach OT.

Zrozumienie środowisk IoT, SCADA i OT

IoT – krótkie wprowadzenie

Urządzenia IoT to zwykle systemy wbudowane, wykorzystywane w różnych branżach: domach inteligentnych, przemyśle, opiece zdrowotnej i logistyce.
Typowe cechy:

Ograniczone zasoby (CPU, RAM), co utrudnia lokalne logowanie
Niestandardowe firmware, które często nie generuje logów w standardowych formatach
Ograniczona przepustowość lub przerywana łączność sieciowa

SCADA i OT

Systemy SCADA i OT nadzorują procesy przemysłowe w sektorach takich jak energetyka, produkcja, transport czy infrastruktura krytyczna.
Kluczowe cechy:

Przetwarzanie danych w czasie rzeczywistym (lub bliskim) z rygorystycznymi wymaganiami dostępności
Wykorzystanie specjalistycznych protokołów (Modbus, DNP3, OPC-UA), które mogą nie mieć wbudowanych mechanizmów logowania
Obecność komponentów legacy, często nieobsługujących współczesnych standardów bezpieczeństwa czy nowoczesnych formatów logów

Typy logów do monitorowania

Logi systemowe
Urządzenia z systemami wbudowanymi (np. PLC, RTU, HMI) mogą generować logi jądra lub klasyczne wpisy syslog – o ile są dostępne.
Logi ruchu sieciowego
Protokolarne logi Modbus/DNP3 mogą być zbierane przez czujniki sieciowe lub dedykowane bramki. Np. nieoczekiwane funkcje Modbus mogą wskazywać na atak lub błędną konfigurację.
Logi aplikacyjne SCADA
Rejestrują działania operatorów, przekroczenia progów procesowych, stany alarmowe, problemy z łącznością. Mogą ujawnić nieautoryzowane zmiany w kluczowych parametrach.
Logi firmware / urządzeń
Wskazują na integralność firmware, aktualizacje, próby przeładowania urządzenia. Są ważnym wskaźnikiem prób instalacji nieautoryzowanego oprogramowania.
Logi urządzeń bezpieczeństwa
Zapory przemysłowe, IDS/IPS oraz wyspecjalizowane urządzenia OT generują logi dotyczące prób włamań, zablokowanego ruchu i wykrytych anomalii.

Wyzwania w zbieraniu logów OT/SCADA

Złożoność protokołów
Wiele protokołów przemysłowych ma charakter zamknięty lub niepełną dokumentację. Interpretacja logów wymaga znajomości konkretnej wersji i implementacji producenta.
Ograniczone zasoby urządzeń
Ze względu na brak przestrzeni dyskowej logi mogą być rotowane bardzo szybko. Konieczne jest przekazywanie ich w czasie rzeczywistym do centralnego systemu.
Wysoka dostępność systemów
Zatrzymanie lub rekonfiguracja urządzeń przemysłowych może być niemożliwa bez przerwy produkcyjnej – konfiguracja logowania musi być zaplanowana z wyprzedzeniem.
Segmentacja i air-gap
Sieci przemysłowe bywają odseparowane od IT. Do bezpiecznego przekazywania logów potrzebne są kontrolowane mechanizmy: np. data diode, jump-host.

Dobre praktyki monitorowania

1. Standaryzuj i normalizuj logi

Jeśli to możliwe, konfiguruj urządzenia tak, by przesyłały logi w formacie syslog lub JSON, co ułatwia ich przetwarzanie w SIEM.

Przykład (Linux-based PLC):

sudo apt-get install rsyslog sudo systemctl enable rsyslog # Edycja pliku /etc/rsyslog.conf: *.* @192.168.100.10:514

Jeśli syslog nie jest obsługiwany, warto zastosować bramki przemysłowe (protocol gateway) konwertujące logi do formatu rozpoznawanego przez SIEM.

2. Korelacja z danymi procesowymi

Systemy SCADA śledzą zmienne procesowe (np. temperatura, ciśnienie, przepływ). Korelacja tych danych z próbami logowania lub zmianami konfiguracji może ujawnić incydent:

Niespodziewane zmiany wartości zadanych + potwierdzenie alarmu
Utworzenie nowego konta użytkownika tuż przed zatrzymaniem krytycznego urządzenia
Skany sieci równolegle z podniesieniem temperatury odczytywanej przez czujnik IoT

3. Stosuj zasadę najmniejszych uprawnień i kontroluj dostęp

Współczesne rozwiązania przemysłowe wspierają RBAC i MFA:

Rejestruj wszystkie logowania i zmiany ról
Wymuś MFA dla zdalnych połączeń z interfejsem SCADA lub konsolą OT

4. Monitoruj aktualizacje firmware i jego integralność

Nieautoryzowane aktualizacje firmware to częsty sygnał kompromitacji:

Rejestruj nieoczekiwane zmiany wersji, ponowne uruchomienia urządzenia
Wykorzystuj mechanizmy sprawdzania integralności (SHA256, TPM, etc.)
Przesyłaj alerty do SIEM w razie niespójności

5. Korzystaj z dedykowanej Threat Intelligence

Źródła TI dotyczące ICS/SCADA – jak MITRE ATT&CK for ICS
https://collaborate.mitre.org/attackics/index.php/Main_Page
– zawierają taktyki i techniki wykorzystywane przez aktorów zagrożeń OT. Integracja wskaźników (IoC, TTPs) z regułami detekcji znacząco zwiększa skuteczność SOC.

Przykłady z życia wzięte

Próba manipulacji siecią energetyczną

W logach SCADA widoczne wielokrotne nieudane logowania RDP z zewnętrznego IP
Udane logowanie na konto administratora – podejrzenie użycia skradzionych danych
Polecenia otwarcia/zamknięcia wyłączników wykonywane poza standardowymi godzinami

Korelacja z logami firewalli ujawniła obejście standardowego kanału VPN i wskazała kompromitację na brzegu sieci – pozwoliło to zapobiec awarii regionalnej sieci energetycznej.

Zainfekowana sieć czujników IoT w zakładzie produkcyjnym

Rejestrowane nieregularne dane temperaturowe z klastrów czujników
W logach zarządzania urządzeniami – próby manipulacji firmware i nietypowe połączenia sieciowe
Wyjście danych do adresów IP spoza zakresu zaufanych

Śledztwo wykazało, iż czujniki miały niezałatane firmware z CVE. Po aktualizacji i zablokowaniu adresów na firewallu udało się powstrzymać eksfiltrację i możliwe uszkodzenia systemu.

3.2. Retencja logów i ich bezpieczeństwo

Polityki retencji logów

Logi powinny być przechowywane przez określony czas – zgodnie z politykami organizacyjnymi, wymogami prawnymi i normami zgodności (np. PCI DSS, HIPAA).
Typowe okresy retencji wahają się od 90 dni do kilku lat, w zależności od wrażliwości danych i branży.
Analitycy SOC powinni upewnić się, iż polityki retencji spełniają zarówno potrzeby związane z threat huntingiem, jak i wymagania prawne lub audytowe.

Zagadnienia związane z przechowywaniem logów

Centralizacja – Przechowywanie logów w jednym repozytorium (np. SIEM lub system zarządzania logami) ułatwia wyszukiwanie, korelację i tworzenie kopii zapasowych.
Redundancja – Użycie klastrów lub wielu lokalizacji przechowywania gwarantuje dostępność logów choćby w przypadku awarii sprzętu.
Szyfrowanie – Stosuj szyfrowanie danych „w spoczynku” (np. szyfrowanie na poziomie dysku) oraz „w tranzycie” (np. TLS przy forwardowaniu logów).
Kontrola dostępu – Wdróż kontrolę dostępu opartą na rolach (RBAC), aby tylko upoważnieni użytkownicy mogli przeglądać, edytować lub eksportować logi.

Zabezpieczanie integralności logów

Aby logi mogły służyć jako dowód (np. w przypadku postępowania sądowego), muszą być odporne na manipulację. Praktyki:

Haszowanie – Generuj sumy kontrolne (np. SHA-256) dla plików logów i przechowuj je oddzielnie, aby móc wykryć wszelkie nieautoryzowane zmiany.
Pamięć typu WORM (Write Once Read Many) – Niektóre systemy wspierają tryb WORM, gdzie logi można zapisać tylko raz, ale nie można ich zmodyfikować.
Ślady audytowe – Zbieraj informacje o tym, kto miał dostęp do repozytorium logów, kiedy i jakie działania zostały wykonane.

Przykład bezpiecznego przechowywania logów

Organizacja może archiwizować logi z systemów on-premise w Amazon S3, z włączonym versioningiem i szyfrowaniem po stronie serwera (SSE).
Klucze szyfrowania mogą być przechowywane w AWS Key Management Service (KMS), a uprawnienia zarządzane dzięki AWS IAM.
Szczegóły konfiguracji dostępne są w oficjalnej dokumentacji AWS.

3.3. Narzędzia wspierające: SIEM i SOAR

SIEM – Security Information and Event Management

Platformy SIEM zbierają, parsują i normalizują logi z różnych źródeł, umożliwiając ich przeszukiwanie, korelowanie oraz generowanie alertów w czasie zbliżonym do rzeczywistego.
Popularne rozwiązania SIEM to: Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel.

Kluczowe funkcje:

Agregacja i normalizacja logów – Ujednolicanie formatów zdarzeń z różnych źródeł
Reguły korelacyjne – Tworzenie alertów na podstawie sekwencji zdarzeń
Dashboardy i raporty – Graficzne interfejsy do monitorowania sytuacji bezpieczeństwa i raportowania zarządczego

SOAR – Security Orchestration, Automation, and Response

Platformy SOAR automatyzują zadania, które wcześniej wykonywali manualnie analitycy.
Popularne rozwiązania: Cortex XSOAR (Palo Alto Networks), Splunk Phantom.

Funkcje SOAR:

Wzbogacanie alertów – Automatyczne zbieranie informacji o hostach, użytkownikach i ruchu sieciowym z użyciem threat intelligence.
Izolacja i reakcja – Automatyczne wyłączenie konta, odcięcie hosta od sieci, blokowanie domen w firewallu.
Orkiestracja działań – Wyzwalanie przepływów pracy (workflow), które angażują wiele systemów IT i bezpieczeństwa.

Automatyzacja i playbooki

Standardową praktyką w SOAR jest budowa playbooków – zautomatyzowanych scenariuszy reakcji na konkretne incydenty.
Przykład playbooka – podejrzany skrypt PowerShell:

Pobierz logi z hosta
Sprawdź hash skryptu w bazie threat intelligence
Jeśli złośliwy – odizoluj host
Utwórz zgłoszenie w systemie zarządzania incydentami

Porównanie SIEM vs SOAR

FunkcjaSIEMSOAR

Główne zastosowanie	Centralizacja logów, korelacja, alerty	Automatyzacja reakcji i orkiestracja działań
Przetwarzanie danych	Analiza dużych zbiorów danych dzienników	Integracja z narzędziami bezpieczeństwa i systemami IT
Efekt końcowy	Alerty, raporty, dashboardy	Playbooki, akcje izolacji, zgłoszenia incydentów
Złożoność wdrożenia	Średnia do wysokiej	Średnia do wysokiej (zależnie od poziomu automatyzacji)

W praktyce większość SOC-ów integruje SIEM i SOAR dla pełnego pokrycia:

SIEM obsługuje masowe przetwarzanie i korelację logów
SOAR automatyzuje działania związane z dochodzeniem i odpowiedzią

To połączenie pozwala znacząco skrócić MTTD (Mean Time to Detect) i MTTR (Mean Time to Respond), zwiększając ogólną odporność organizacji na zagrożenia.

Newsletter – zero spamu

Dołącz by otrzymać aktualizacje bloga, akademii oraz ukryte materiały, zniżki i dodatkową wartość.

Administratorem danych jest Security Bez Tabu Wojciech Ciemski . Dane osobowe są przetwarzane w celu marketingu bezpośredniego (wysyłka newslettera – podstawa art. 6 ust. 1 lit. a) rodo). Mają Państwo prawo dostępu do danych i uzyskania kopii danych, usunięcia i modyfikacji danych osobowych, złożenia sprzeciwu, przeniesienia danych lub ograniczenia przetwarzania, wycofania zgody oraz do złożenia skargi do UODO. Więcej informacje na temat ochrony danych osobowych znajdą Państwo w naszej Polityce Prywatności.

Zapisz Loading…