Ukryte wyzwania SIEM: Dlaczego problemy z logami podważają skuteczność działania SOC

Wnioski z raportu Picus Blue Report 2025

Najnowszy Picus Blue Report 2025, oparty na ponad 160 milionach symulacji realnych ataków, pokazuje ciekawą statystykę: tylko 1 na 7 symulowanych ataków jest skutecznie wykrywana. Statystyka ta pokazuje poważną lukę w zdolności wykrywania i reagowania na incydenty. Dużo organizacji działa w fałszywym poczuciu bezpieczeństwa, sądząc, że ich systemy działają skutecznie, podczas gdy w rzeczywistości krytyczne zdarzenia często umykają uwadze. Atakujący mogą uzyskać dostęp do wrażliwych systemów, eskalować uprawnienia, a nawet wykradać dane — nie generując przy tym żadnych alertów w systemach klasy SIEM.

Dlaczego więc, pomimo znaczących nakładów na narzędzia SIEM i infrastrukturę bezpieczeństwa organizacje mogą wciąż nie radzić sobie z wykrywaniem zagrożeń? Odpowiedź najczęściej tkwi w obszarze niezwykle często poruszanym podczas spotkań pre-sales z klientami czyli problemem z logami.

Według Blue Report 2025, aż 50% symulowanych ataków nie zostało w pełni odnotowanych w systemach SIEM, w postaci logów. Wynika to bezpośrednio z problemów z generowaniem, przesyłaniem, gromadzeniem i parsowaniem logów. Bez kompletnych i poprawnie przetworzonych danych, reguły nie będą odpowiednio działały.

Najczęstsze problemy z logami w SIEM — według Blue Report 2025

Raport wskazuje trzy główne problemy, które w największym stopniu wpływają na skuteczność reguł detekcji:

1. Nieprawidłowe łączenie logów — 21% problemów

Część organizacji łączy podobne logi w jeden rekord w celu poprawy wydajności systemu. Jednak w przypadku kluczowych źródeł, takich jak: dane z endpointów, logi serwerów proxy czy zdarzenia Windows, może to prowadzić do utraty krytycznych informacji.

2. Niedostępne lub uszkodzone źródła logów — 19% problemów

Brakujące logi mogą wynikać m.in. z problemów z przekazywaniem danych przez zapory sieciowe, błędnych konfiguracji agentów zbierających logi czy awarii serwerów logów.

3. Brak optymalnych filtrów i nieefektywne zapytania

Jeżeli reguły detekcji są zbyt ogólne, SIEM zbiera ogromne ilości niepotrzebnych danych. Powoduje to spadek wydajności systemu (wolniejsze alerty, opóźnienia w wykrywaniu), a w konsekwencji zmęczenie analityków bezpieczeństwa nadmiarem fałszywych alarmów.

Pozostałe kluczowe wyzwania związane z narzędziami klasy SIEM

Oprócz problemów z logami, raport wskazuje także na dwie inne istotne przyczyny awarii reguł tj. błędne konfiguracje reguł oraz problemy natury wydajnościowej. Złe progi wykrywania czy błędna logika korelacji powodują, że nawet przy kompletnych logachSIEM nie potrafi wykryć zagrożeń. Z kolei nadmiernie skomplikowane zapytania, szerokie definicje i niepotrzebnie złożone reguły potrafią spowolnić system na tyle, że detekcja następuje zbyt późno, aby skutecznie zareagować. Często również takie reguły są za bardzo szczegółowe, pozostawiając pole do manewru atakującym korzystającym z innych taktyk.

Innym wyzwaniem jest problem licencjonowania w momencie posiadanie coraz to większej liczby danych. Wiele platform SIEM jest licencjonowanych na podstawie objętości przyjmowanych danych lub liczby zdarzeń na sekundę (EPS). Prowadzi to do trudnego kompromisu między kosztami a kompleksowością monitoringu. Zespoły SOC są pod presją, by ograniczyć ilość logów, co zmusza je do redukcji często cennych źródeł, takich jak szczegółowe logi zapytań DNS czy logi debugowania z firewalli. Tworzy to martwe pola, które mogą być wykorzystane przez atakujących do ukrycia swojej aktywności.

Ciągła walidacja: jedyny sposób na utrzymanie skuteczności SIEM

Atakujący nieustannie zmieniają swoje taktyki, techniki i procedury (TTP). Oznacza to, że nawet dobrze skonfigurowane reguły SIEM mogą szybko stać się nieaktualne. Rozwiązaniem jest ciągła walidacja — regularne testowanie reguł i źródeł logów w oparciu osymulacje realnych ataków. Każdy rzeczywisty incydent powinien być analizowany pod kątem skuteczności detekcji. Pytania typu „dlaczego ten atak nie został wykryty wcześniej?” lub „które reguły zadziałały, a które nie?” powinny prowadzić do konkretnych ulepszeń w konfiguracji SIEM.

Regularne ćwiczenia łączące zespoły red team i blue team pozwalają na testowanie skuteczności detekcji w kontrolowanych warunkach. Purple team exercises ujawniają luki w pokryciu, które mogłyby pozostać niezauważone podczas rutynowej pracy.

Ponadto warto regularnie aktualizować reguły w oparciu o najnowsze dane z CTI (cyber threat intelligence) oraz TTPs z najnowszych raportów. Dzięki temu możemy lepiej reagować na nowe zagrożenia.

Czego oczekiwać od zespołu SOC?

Nowoczesny SOC nie może już działać wyłącznie w oparciu o domyślne reguły dostarczane przez producentów SIEM. Skuteczna detekcja wymaga pełnej kontroli nad telemetrią, własnych reguł detekcji oraz dedykowanych specjalistów. Organizacje, które opierają się wyłącznie na “out-of-the-box” konfiguracjach, narażają się na powstawanie krytycznych luk.

SOC powinien posiadać ekspertów od inżynierii telemetrii, którzy dbają o kompletność i jakość logów dostarczanych do SIEM oraz weryfikują parsery, pipeline’y danych i źródła logów.

Ponadto SOC musi tworzyć reguły szyte na miarę bazujące na realnych wzorcach logowania i zachowania użytkowników oraz typowych scenariuszach ataków w danej branży. Ważne jest rówież dostosowanie reguł bezpieczeństwa do organizacji oraz narzędzi w niej dostępnych. Każde narzędzie ma zróżnicowaną składnię swoich logów – SOC musi mieć pewność, że odpowiednie reguły będą działać na każdym z nich.

SOC powinien również współpracować z red team w celu testowania skuteczności detekcji oraz symulować realne ataki w celu walidacji reguł SIEM czy źródeł logów na podstawie aktualnych TTPs.