
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 -raby 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.
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_nameTo 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 upInterpretacja 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)
<Configuration status="warn"> <Appenders> <File name="FileLogger" fileName="logs/application.log"> <PatternLayout pattern="%d{ISO8601} [%t] %-5level %logger{36} - %msg%n" /> </File> </Appenders> <Loggers> <Logger name="com.example.app" level="info" additivity="false"> <AppenderRef ref="FileLogger"/> </Logger> <Root level="error"> <AppenderRef ref="FileLogger"/> </Root> </Loggers> </Configuration>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ą logowaneUwaga: 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 msUstawienie 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
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 > 3To 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ę:
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-eventsPrzechowywanie 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 $trueLogi 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_imageKubernetes
- 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:514Jeś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
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.
Dziękujemy!
Witamy w sołeczności SBT!
Bibliografia
- AlienVault OTX – https://otx.alienvault.com/
- AWS CloudTrail Documentation – https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
- Azure Monitor Documentation – https://learn.microsoft.com/en-us/azure/azure-monitor/
- Cisco Syslog Guide – https://www.cisco.com/c/en/us/support/docs/security-vpn/syslog/
- Cloud Logging (GCP) – https://cloud.google.com/logging/docs
- Docker Logging Documentation – https://docs.docker.com/config/containers/logging/
- Elastic Documentation – https://www.elastic.co/guide/index.html
- Firewall Best Practices (NIST) – https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf
- Graylog Documentation – https://docs.graylog.org/
- HIPAA Security Rule – https://www.hhs.gov/hipaa/for-professionals/security/index.html
- IBM QRadar Documentation – https://www.ibm.com/docs/en/qradar
- ISO/IEC 27001 – https://www.iso.org/isoiec-27001-information-security.html
- Kubernetes Auditing Documentation – https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
- Mandiant (FireEye) Threat Intelligence – https://www.mandiant.com/
- Microsoft Defender Documentation – https://learn.microsoft.com/en-us/microsoft-365/security/defender/
- Microsoft Sentinel Documentation – https://learn.microsoft.com/en-us/azure/sentinel/
- Microsoft SQL Server Docs – https://docs.microsoft.com/en-us/sql/
- MITRE ATT&CK Framework – https://attack.mitre.org/
- MySQL Official Docs – https://dev.mysql.com/doc/
- NIST SP 800-61r2: Computer Security Incident Handling Guide – https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
- NIST SP 800-92: Guide to Computer Security Log Management – https://csrc.nist.gov/publications/detail/sp/800-92/final
- NIST SP 800-137: Information Security Continuous Monitoring (ISCM) – https://csrc.nist.gov/publications/detail/sp/800-137/final
- Oracle Database Docs – https://docs.oracle.com/en/database/
- OSSEC Documentation – https://www.ossec.net/docs/
- OWASP Cheat Sheet Series – https://cheatsheetseries.owasp.org/
- PCI DSS – https://www.pcisecuritystandards.org/
- PostgreSQL Documentation – https://www.postgresql.org/docs/
- Snort (IDS/IPS) Documentation – https://www.snort.org/
- Splunk Documentation – https://docs.splunk.com/
- Suricata Documentation – https://suricata-ids.org/docs/
- Sysinternals Documentation – https://learn.microsoft.com/en-us/sysinternals/
- VirusTotal – https://www.virustotal.com/
- Wazuh Documentation – https://documentation.wazuh.com/