SIEM (Security Information and Event Management)

SIEM (Security Information and Event Management) to system, który zbiera logi i zdarzenia z wielu źródeł, sprowadza je do wspólnej postaci, koreluje regułami i na tej podstawie generuje alerty dla analityków. NIST opisuje oprogramowanie SIEM jako rodzaj scentralizowanego oprogramowania do logowania, złożony z serwerów analizujących logi i serwerów baz danych, które je przechowują ^[1]. Serwer SIEM analizuje dane z różnych źródeł, koreluje zdarzenia między wpisami, wskazuje i priorytetyzuje zdarzenia istotne, a w razie potrzeby uruchamia reakcję ^[1]. SIEM jest podstawowym narzędziem pracy SOC (Security Operations Center).

Jak działa

Przetwarzanie logów w SIEM-ie przebiega etapami, pokazanymi na schemacie poniżej.

RYS. 1Droga zdarzenia przez SIEM

Zbieranie. NIST wyróżnia dwa sposoby pozyskiwania logów ^[1].

Produkty SIEM obsługują zwykle kilkadziesiąt typów źródeł: systemy operacyjne, oprogramowanie zabezpieczające, serwery aplikacyjne, a nawet czytniki identyfikatorów w kontroli dostępu fizycznego ^[1]. Dla każdego obsługiwanego typu produkt wie, co oznaczają najważniejsze pola, na przykład które pole zawiera źródłowy adres IP, co według NIST znacznie poprawia normalizację, analizę i korelację ^[1]. SIEM może też odrzucać pola bez znaczenia dla bezpieczeństwa, zmniejszając obciążenie sieci i pamięci masowej ^[1].

Normalizacja. Każde pole logu zostaje przekształcone do określonej reprezentacji i spójnie skategoryzowane ^[1]. Szczególnie trudne jest ujednolicenie czasu: systemy w różnych strefach czasowych trzeba sprowadzić do jednej strefy, a zegary źródeł synchronizować, na przykład przez serwery NTP ^[1]. Bez tego kolejność zdarzeń z serwera WWW i zapory bywa błędna.

Korelacja. NIST definiuje korelację zdarzeń jako znajdowanie związków między dwoma lub więcej wpisami w logach; najczęstsza jest korelacja oparta na regułach ^[1]. Przykładową regułę opisał CERT Polska przy podatności Log4Shell (CVE-2021-44228) w grudniu 2021 roku: domenę widoczną w próbie ataku zestawia się z zapytaniami DNS, a zapytanie o nią tuż po ataku może wskazywać podatną aplikację ^[3]. Według CERT Polska taka korelacja jest możliwa w większości rozwiązań klasy SIEM, jeśli organizacja ma odpowiednie logi ^[3].

Alert i obsługa. Produkty SIEM zwykle oferują interfejs dla analityków, bazę wiedzy o podatnościach i znaczeniu komunikatów, śledzenie incydentów oraz korelację z informacją o zasobach, na przykład wyższy priorytet dla ataku na podatny system ^[1]. Dalsza obsługa alertu to triaż (triage) i reagowanie na incydent.

Pokrewne systemy

NIST wyjaśnia, że SIEM łączy dwie starsze kategorie: SEM, nastawione głównie na reagowanie na incydenty, i SIM, nastawione na audyt ^[1]. Ta sama publikacja z września 2006 roku nazywała SIEM stosunkowo nowym rodzajem oprogramowania i zauważała, że nie ma standardów specyficznych dla SIEM, więc każdy produkt przechowuje dane we własnym formacie ^[1].

Obok SIEM-a działają systemy o innym zakresie. SOAR (Security Orchestration, Automation and Response) automatyzuje reakcję na alerty według zdefiniowanych kroków. EDR (Endpoint Detection and Response) zbiera telemetrię ze stacji końcowych, a XDR (Extended Detection and Response) łączy dane z wielu warstw. W maju 2025 roku CISA wraz z australijskim ASD's ACSC i partnerami opublikowała wytyczne wdrażania SIEM i SOAR, w tym osobny dokument o priorytetach logów do wprowadzenia do SIEM-a ^[2]. Przykładem otwartego oprogramowania jest Wazuh, który według dokumentacji łączy funkcje XDR i SIEM oraz używa uniwersalnego agenta na hostach ^[5].

W WordPressie

Pojedyncza strona WordPress rzadko ma własny SIEM, ale bywa jednym ze źródeł w SIEM-ie firmy albo agencji. NIST wymienia serwery aplikacyjne, w tym serwery WWW, wśród typowych źródeł logów obsługiwanych przez produkty SIEM ^[1]. Dla WordPressa są to przede wszystkim:

• logi dostępu i błędów serwera HTTP, w których widać ataki siłowe na wp-login.php i xmlrpc.php oraz żądania do podejrzanych plików;
• zdarzenia aplikacji, na przykład nieudane logowania: WordPress udostępnia akcję wp_login_failed, wywoływaną po nieudanej próbie logowania, z nazwą użytkownika lub adresem e-mail i obiektem błędu ^[4];
• zmiany plików wykryte przez monitorowanie integralności plików albo wtyczkę bezpieczeństwa.

Logi serwera WWW, zdarzenia aplikacji i wyniki skanowania plików pochodzą z różnych mechanizmów i mogą zapisywać czas w różnych strefach, dlatego przy stronach WordPress szczególne znaczenie ma opisana wyżej normalizacja czasu i synchronizacja zegarów ^[1]. Przykład reguły korelacyjnej dla WordPressa: wiele nieudanych logowań z jednego adresu, a zaraz potem udane logowanie administratora z tego samego adresu. Pojedynczo oba zdarzenia są codzienne, razem wskazują możliwe przejęcie konta.

Ograniczenia

SIEM wykrywa tylko to, co widzi w logach i co opisują jego reguły. NIST w katalogu zabezpieczeń SP 800-53 wymienia technologie SIEM wśród tradycyjnych środków ochrony, obok zapór i systemów wykrywania włamań, i przeciwstawia im aktywne polowanie na zagrożenia (threat hunting) ^[6]. Źle dostrojone reguły dają fałszywe alarmy, a ich nadmiar prowadzi do zmęczenia alertami. Wartość systemu zależy też od retencji logów: zdarzenie usunięte przed przesłaniem albo przed analizą nie pomoże w dochodzeniu. NIST zaznacza, że produkty SIEM zwykle chronią poufność, integralność i dostępność logów, na przykład przez szyfrowaną transmisję między agentami a serwerem i wzajemne uwierzytelnianie ^[1].