SIEM w firmie — dlaczego samo wdrożenie nie zwiększa bezpieczeństwa

Firma wdrożyła nowoczesny system SIEM (Security Information and Event Management). Logi z firewalli, serwerów i Microsoft 365 spływały do jednej konsoli z kilkuset alertami dziennie. Po kilku miesiącach doszło do ataku: SIEM wygenerował poprawny alert, którego nikt nie przeanalizował, bo firma nie miała zespołu SOC (Security Operations Center). To odpowiedź na pytanie, dlaczego SIEM w firmie bez SOC nie działa: narzędzia zbierają dane, a o bezpieczeństwie przesądzają ludzie, proces i czas reakcji.

Najważniejsze informacje:

• Skuteczność tworzą ludzie, proces i szybka reakcja – narzędzie dostarcza sygnał, resztę robi zespół, który na niego odpowiada.
• Sam alert niczego nie zatrzymuje – potrzebny jest zespół, który go przeczyta, sklasyfikuje i uruchomi reakcję.
• SIEM i SOC uzupełniają się – system dostarcza sygnał, ludzie nadają mu kontekst i podejmują działanie.
• Bez procesu i monitoringu 24/7 nawet najlepszy system przepuści atak poza godzinami pracy.
• NIS2 (dyrektywa UE 2022/2555) nie nakazuje SIEM – wymaga zarządzania ryzykiem i obsługi incydentów.

Czym jest SIEM?

SIEM to system, który zbiera logi z wielu źródeł, normalizuje je do wspólnego formatu, koreluje zdarzenia i generuje alerty o podejrzanej aktywności. Dla zarządu oznacza to jedno miejsce, w którym widać, co dzieje się w całej infrastrukturze IT, zamiast dziesiątek osobnych konsol. Odpowiedź na pytanie, co to jest SIEM, sprowadza się do roli centralnego rejestratora i analizatora zdarzeń bezpieczeństwa.

Do najważniejszych funkcji SIEM należą: zbieranie i zarządzanie logami z całego środowiska, korelacja zdarzeń, wykrywanie anomalii oraz raportowanie na potrzeby audytu. Ciągły monitoring logów daje jedno spójne źródło wiedzy o tym, co dzieje się w firmie. System SIEM nie zastępuje przy tym zabezpieczeń, które już masz, tylko porządkuje to, co one raportują. Sam w sobie jest źródłem wiedzy, nie decyzji.

Jak działa SIEM?

Zanim alert trafi do człowieka, dane przechodzą przez kilka etapów przetwarzania. Najłatwiej pokazać, jak działa SIEM, jako sekwencję kroków od surowego logu do gotowego ostrzeżenia.

1. Zbieranie logów – system pobiera zdarzenia z firewalli, serwerów, stacji roboczych, aplikacji i usług chmurowych.
2. Normalizacja – różne formaty logów sprowadza do wspólnej struktury, żeby dało się je porównywać.
3. Korelacja zdarzeń – łączy pojedyncze wpisy w łańcuchy; korelacja logów zamienia szum w potencjalny incydent.
4. Wykrywanie anomalii – porównuje bieżącą aktywność z regułami i profilem normalnego zachowania.
5. Generowanie alertów – oznacza zdarzenie wymagające uwagi i przekazuje je dalej.

Cały ten proces to analiza logów bezpieczeństwa prowadzona automatycznie, w tempie, którego żaden człowiek nie osiągnie. Efektem jest jednak alert wymagający rozstrzygnięcia – maszyna kończy pracę tam, gdzie zaczyna się praca zespołu.

Czego SIEM nie zrobi samodzielnie?

Najważniejsze ograniczenie SIEM bywa najczęściej pomijane przy planowaniu budżetu. System wykrywa i sygnalizuje, ale nie działa, a to działanie decyduje, czy atak zostanie zatrzymany.

1. Nie podejmie decyzji – nie oceni, czy alert wymaga reakcji, czy jest szumem.
2. Nie oceni wpływu biznesowego – nie wie, że jeden serwer obsługuje produkcję, a inny jest testowy.
3. Nie odizoluje stacji – nie odłączy zainfekowanego urządzenia od sieci.
4. Nie przeprowadzi reakcji – nie poprowadzi procesu Incident Response (reakcja na incydent) od wykrycia po odtworzenie usług.

Możliwości i ograniczenia SIEM:

Sprowadza się to do jednej granicy: SIEM widzi zdarzenie, ale nie rozumie jego znaczenia dla firmy. Ocena kontekstu, ryzyka i reakcja to zadania dla zespołu, nie dla oprogramowania.

SIEM vs SOC

Porównanie SIEM i SOC często prowadzi do błędnego wniosku, że trzeba wybrać jedno z dwóch. SIEM i SOC działają jako dwie warstwy tego samego systemu obronnego: jedna dostarcza dane, druga podejmuje na ich podstawie decyzje.

Zestawienie pokazuje, że każda warstwa ma inne zadanie. SIEM i SOC uzupełniają się: system dostarcza sygnał, a ludzie, proces i czas reakcji zamieniają go w powstrzymany incydent.

Sam alert nie ma wartości, dopóki ktoś go nie przeczyta, nie sklasyfikuje i nie zdecyduje, co dalej. W VigilHorizon analizą alertów zajmuje się zespół pracujący w trybie ciągłym, a nie skrzynka, do której nikt nie zagląda. To proces analizy odróżnia monitoring od realnej ochrony.

Dlaczego SIEM bez SOC nie działa?

Wróćmy do firmy z początku tekstu. Miała nowoczesny system, ten poprawnie wykrył atak, a incydent i tak trwał godzinami. To jest odpowiedź na pytanie, dlaczego SIEM bez SOC nie działa: między alertem a reakcją jest luka, którą wypełnia dopiero człowiek.

1. SIEM zbiera i koreluje logi z całego środowiska.
2. Generuje alert o podejrzanej aktywności.
3. Analityk SOC odbiera alert i ocenia jego wagę.
4. Klasyfikacja i triage – odsianie fałszywych alarmów od realnych zagrożeń.
5. Incident Response – zespół uruchamia reakcję na incydent.
6. Recovery – przywrócenie usług i wnioski wyciągnięte po zdarzeniu.

Przerwij ten łańcuch na trzecim kroku, a wszystko poniżej się nie wydarzy. Alert bez analityka zostaje tylko wpisem w bazie danych. Pytanie, czy SIEM wystarczy, ma więc jedną odpowiedź: wystarcza jako narzędzie, a realną ochronę tworzą dopiero ludzie i proces.

Jak wygląda nowoczesny model monitoringu bezpieczeństwa?

Skuteczny monitoring nie opiera się na jednym narzędziu, tylko na warstwach, które się uzupełniają. Dane płyną od zabezpieczeń brzegowych, przez stacje robocze, po chmurę, a na końcu trafiają do ludzi. Dobrze zaprojektowany monitoring bezpieczeństwa SIEM spina w jeden obraz, ale to dopiero początek łańcucha.

1. Firewall – filtruje ruch sieciowy na granicy organizacji.
2. EDR (Endpoint Detection and Response) – monitoruje stacje robocze i serwery pod kątem złośliwej aktywności.
3. Microsoft 365 – dostarcza zdarzenia o tożsamości, poczcie i dostępie do danych.
4. SIEM – zbiera i koreluje sygnały ze wszystkich warstw.
5. SOC – analizuje, klasyfikuje i decyduje.
6. Incident Response – reaguje, ogranicza skutki i przywraca działanie.

W tym modelu SIEM monitoring środowiska prowadzi nieprzerwanie, a każde ogniwo ma inne zadanie. Wypadnięcie któregokolwiek osłabia całość, a najczęściej brakuje dwóch ostatnich: ludzi i procesu.

Te dwa brakujące ogniwa bierze na siebie VigilHorizon. Sygnał z SIEM trafia do analityka, który klasyfikuje go według playbooka i reguł triage, zamiast przesuwać na później. Łańcuch domyka się dopiero tam, gdzie alert kończy się decyzją i działaniem, a nie kolejnym wpisem w konsoli.

Najczęstsze błędy organizacji

Większość nieudanych wdrożeń nie wynika ze złego narzędzia, tylko z założenia, że narzędzie wystarczy. Skutki widać dopiero podczas realnego incydentu, gdy okazuje się, że alerty od miesięcy nikt nie czytał.

• SIEM bez procedur – system działa, ale nikt nie ustalił, kto i jak reaguje na alert.
• Brak analizy alertów – zdarzenia spływają do konsoli i tam zostają.
• Brak monitoringu 24/7 – atak w nocy lub w weekend przechodzi niezauważony.
• Brak playbooków – każdy incydent obsługiwany jest od zera, wolno i chaotycznie.
• Alert fatigue – zmęczenie natłokiem powiadomień sprawia, że ważny alert ginie wśród fałszywych.

Osobnym błędem jest traktowanie zgodności jak listy zakupów. Relacja SIEM NIS2 bywa rozumiana opacznie: dyrektywa wymaga zarządzania ryzykiem i obsługi incydentów, ale nie nakazuje kupić konkretnego narzędzia. SIEM może wspierać te obowiązki, jeśli stoją za nim ludzie i proces.

Czy Twój SIEM naprawdę zwiększa bezpieczeństwo?

Twój SIEM zwiększa bezpieczeństwo tylko wtedy, gdy za jego alertami stoi proces analizy i reakcji. Sam fakt posiadania systemu niczego nie przesądza. Pięć pytań pozwala sprawdzić, po której stronie granicy jest Twoja organizacja.

• Kto analizuje alerty? – jeśli odpowiedź brzmi „nikt na bieżąco”, masz rejestrator, nie ochronę.
• Czy monitoring działa 24/7? – atakujący nie pracują w godzinach biurowych.
• Czy znasz swój MTTD? – średni czas wykrycia (MTTD, Mean Time To Detect) pokazuje, jak szybko widzisz incydent.
• Czy alerty są klasyfikowane? – bez priorytetów ważne ostrzeżenie ginie w tłumie.
• Czy istnieją playbooki reakcji? – spisane scenariusze skracają czas reakcji i ograniczają chaos.

Im więcej odpowiedzi „nie”, tym bliżej jesteś scenariusza z początku tekstu. Każdą z tych luk da się jednak zamknąć i żadna nie wymaga zaczynania od zera.

Koszt niezauważonego alertu ponosi organizacja i jej klienci, długo po tym, jak zgasła lampka w konsoli. Dlatego w VigilHorizon miarą dobrze obsłużonego alertu jest zatrzymany incydent, a nie liczba zamkniętych zgłoszeń. Za każdym sygnałem stoi konkretna osoba, która bierze na siebie doprowadzenie go do działania.

Najczęściej nie brakuje nam danych, tylko kogoś, kto przeczyta je w porę. Za każdym razem widać to samo: alert był, tylko nie miał kto na niego zareagować.

VigilHorizon, analityk SOC

Podsumowanie

Sprowadźmy to do wniosku dla decydenta. SIEM jest jednym z najważniejszych elementów nowoczesnego cyberbezpieczeństwa, ale żadne narzędzie nie tworzy bezpieczeństwa samo. Decyduje o nim to, czy stoją za nim ludzie, proces i czas, w jakim zapada decyzja o reakcji. Bez zespołu analizującego alerty i bez procedur Incident Response system pozostaje zaawansowaną platformą do analizy logów, która pokaże atak, ale go nie zatrzyma.

Jeśli masz już SIEM, najważniejszym kolejnym krokiem jest sprawdzenie, kto i jak reaguje na jego alerty. Proponujemy zacząć od analizy obecnej architektury i tego, czy alerty mają w ogóle odbiorcę. W VigilHorizon łączymy monitoring z zespołem i procesem w ramach usługi SOC 24/7, tak aby wykryty incydent kończył się reakcją, a nie kolejnym niezauważonym wpisem w konsoli.

Najczęściej zadawane pytania (FAQ)

Dowiedz się więcej

• Czym jest SOC 24/7 i jak działa monitoring bezpieczeństwa
• Incident Response – jak wygląda reakcja na incydent krok po kroku
• EDR, XDR i MDR – różnice między technologiami ochrony
• NIS2 a monitoring bezpieczeństwa – obowiązki organizacji
• MTTD i MTTR – jak mierzyć skuteczność wykrywania i reakcji