Nowości w świecie SIEM i XDR: jak rozsądnie inwestować w narzędzia, które obiecują pełną widoczność

Scenka z życia SOC: gdy obietnica „pełnej widoczności” zderza się z realiami

Średniej wielkości firma produkcyjna, kilka zakładów w kraju, mocno rosnący biznes. Zarząd kupił świeży system XDR u znanego producenta, zainstalowano agentów na stacjach roboczych i serwerach, odbyło się szkolenie „z pudełka”. Miesiąc później pojawił się incydent: wyciekł fragment kodu i część danych klientów – a w konsoli XDR panowała cisza.

Po krótkim dochodzeniu wyszło na jaw, że atakujący w ogóle nie dotknął stacji roboczych pracowników. Wszedł przez niewłaściwie zabezpieczone konto serwisowe w chmurze, wykorzystał token dostępowy, a dane wyprowadził przez niewielki serwer VPS w zewnętrznej chmurze. Tam nie było agentów XDR, nie było też sensownych logów w SIEM, bo „przecież wszystko mamy na endpointach”.

Ten typ historii powtarza się w różnych wariantach: ktoś kupił nowoczesny XDR, ktoś inny wdrożył SIEM klasy enterprise, a mimo tego najgroźniejszy incydent roku został wykryty dopiero przez księgową, która zauważyła podejrzane przelewy. Wspólny mianownik jest zwykle ten sam – przyjęto, że narzędzie „da pełną widoczność”, bez zastanowienia, co to oznacza w konkretnym środowisku.

Organizacje najczęściej orientują się, że samo wdrożenie narzędzia nie wystarczy, gdy:

• po pierwszej fali wdrożenia SIEM lub XDR dostają tysiące alertów dziennie i nikt nie wie, które są ważne,
• istotny incydent wychodzi na jaw z kanałów niebezpieczeństwa – przez dział prawny, reklamacje klientów, audyt – a nie z SOC,
• kolejne systemy obiecują „pełną widoczność”, ale każdy obejmuje inny wycinek: endpoint, sieć, chmurę, pocztę, tożsamości, OT – i nikt tego całościowo nie spina,
• licencjonowanie „za wolumen logów” powoduje, że część systemów wyłącza się z monitoringu, bo „za drogo”,
• dostawca pokazał świetne demo na danych laboratoryjnych, a w realnym środowisku detekcje trzeba mozolnie dopracowywać tygodniami.

Pierwsze zderzenie z ograniczeniami zwykle wygląda podobnie. Brakuje ludzi, którzy rozumieją zarówno technologię, jak i kontekst biznesowy. Brakuje procesu: kto reaguje, jak priorytetyzować, kiedy eskalować. SOC tonie w alertach, bo „jak już płacimy za licencję, to wszystko logujemy i wszystko włączamy”. Pojawiają się konflikty z IT i biznesem, bo reagowanie na incydenty blokuje wdrożenia, a nikt wcześniej tego nie zaplanował.

Z takiej perspektywy widać dość jasno: widoczność nie jest funkcją, którą się zaznacza w konfiguratorze produktu. Pełna widoczność to stan, w którym kluczowe ryzyka biznesowe można wykryć i obsłużyć z sensowną szybkością, na podstawie danych z różnych źródeł, powiązanych z kontekstem identyfikacji i procesów. To efekt wielu decyzji: jakich logów nie zbieramy, jak budujemy use case’y, jaki model licencjonowania wybieramy, kogo szkolimy i ile automatyzujemy.

Czym dziś naprawdę są SIEM i XDR – obecny stan rynku i definicje bez marketingu

SIEM 2024: od „logowiska” do platformy analityczno‑regulacyjnej

SIEM w swojej pierwotnej formie był głównie centralnym magazynem logów, z możliwością przeszukiwania i prostych korelacji. Duże firmy wdrażały go głównie z myślą o audytach i zgodności z regulacjami: PCI DSS, ISO 27001, SOX, lokalne przepisy sektorowe. Z czasem, wraz ze wzrostem liczby systemów i rosnącą presją na szybsze wykrywanie incydentów, SIEM zaczął pełnić rolę centralnego „centrum dowodzenia” dla SOC.

Współczesny SIEM to zwykle:

• centralizacja logów z wielu źródeł: systemy operacyjne, aplikacje biznesowe, firewalle, IDS/IPS, rozwiązania chmurowe, usługi SaaS, systemy uwierzytelniania,
• korelacja zdarzeń – od prostych reguł (np. 5 nieudanych logowań w 5 minut) po zaawansowane scenariusze,
• analityka i raporty – dashboardy ryzyka, raporty dla zarządu, raporty zgodności regulacyjnej,
• przetwarzanie na dużą skalę – obsługa ogromnych wolumenów danych, często z wykorzystaniem rozwiązań chmurowych i data lake’ów,
• integracja z innymi narzędziami – SOAR, systemy ticketowe, CMDB, platformy XDR, systemy klasy ITSM.

Największa zmiana względem „starego” SIEM to skala i różnorodność danych. Logi nie pochodzą już tylko z on-premise, ale z wielu chmur, usług zewnętrznych, rozwiązań mobilnych. Do tego dochodzi analityka behawioralna, mechanizmy Machine Learning, integracja z threat intelligence. SIEM stał się czymś więcej niż logowiskiem – jest platformą analityczno‑regulacyjną, która wspiera nie tylko SOC, lecz także compliance, audyt, a często i zespół architektury bezpieczeństwa.

Najczęściej SIEM staje się docelowo „źródłem prawdy” o zdarzeniach bezpieczeństwa w organizacji. To on przechowuje historię, umożliwia dochodzenia po incydentach, pozwala budować use case’y bezpieczeństwa dopasowane do specyfiki biznesu. Równocześnie jednak wymaga znacznych nakładów – na infrastrukturę, licencje, integracje, a przede wszystkim na ludzi, którzy będą z niego realnie korzystać.

XDR: następca EDR czy raczej klej łączący telemetrię?

Pojęcie XDR pojawiło się jako odpowiedź na ograniczenia klasycznego EDR. EDR skupia się na endpointach: komputerach użytkowników, serwerach, czasem też urządzeniach mobilnych. XDR rozszerza ten zakres o inne obszary, mając ambicję stać się „jednym miejscem”, gdzie łączy się telemetrię z różnych domen bezpieczeństwa.

Zakres działania typowego XDR obejmuje co najmniej:

• endpoint – funkcje EDR: ochrona przed malware, analiza zachowań procesów, rollback zmian, izolacja hosta,
• poczta i komunikacja – analiza podejrzanych wiadomości, phishing, złośliwe załączniki, linki,
• sieć – przynajmniej na poziomie metadanych (NetFlow, DNS, proxy), czasem integracje z NDR,
• tożsamość – integracje z AD, AAD, IdP, analiza podejrzanych logowań i eskalacji uprawnień,
• chmura i SaaS – konektory do M365, Google Workspace, AWS, Azure, GCP i innych usług.

Na rynku funkcjonują dwie główne filozofie XDR:

• XDR otwarty – potrafi przyjmować dane z wielu źródeł różnych producentów, stara się pełnić rolę „kleju” łączącego rozproszoną telemetrię. Często ma API, konektory, możliwość wysyłania i przyjmowania zdarzeń z zewnętrznych SIEM/SOAR.
• XDR wiązany (vendor‑locked) – działa najlepiej (a czasem wyłącznie) z produktami jednego producenta: jego EDR, firewalle, bramy pocztowe, usługi chmurowe. W zamian oferuje mocno dopracowane korelacje, integracje „bez tarcia” i gotowe automatyzacje.

Przy wyborze strategii XDR trzeba uczciwie przyjrzeć się swojemu ekosystemowi. Jeżeli firma ma już ustandaryzowane rozwiązania jednego dostawcy, wiązany XDR może dać szybki efekt, prostsze wsparcie i przewidywalne koszty. Jeśli środowisko jest mocno heterogeniczne – integracje z różnych źródeł, wiele chmur, legacy – bardziej otwarty XDR może lepiej wpasować się w rzeczywistość, ale wymaga większego wysiłku integracyjnego.

SIEM vs XDR vs SOAR – porządek w pojęciach

SIEM, XDR, SOAR – te pojęcia bardzo często się mieszają, co sprzyja nadmiernym oczekiwaniom wobec jednego produktu. W uproszczeniu można przyjąć następujący podział ról:

• SIEM – centralne gromadzenie i analiza logów oraz zdarzeń z różnych systemów, z naciskiem na skalę, możliwość długoterminowej retencji, compliance i wszechstronne zapytania.
• XDR – wyspecjalizowana platforma detekcji i reakcji, która łączy telemetrię z kilku kluczowych domen (endpoint, poczta, sieć, tożsamość, chmura) i oferuje zaawansowane scenariusze ataków oraz mechanizmy reakcji.
• SOAR – automatyzacja i orkiestracja reakcji: playbooki, integracje z systemami zewnętrznymi (ITSM, katalogi użytkowników, firewalle, IAM), case management w SOC.

W praktyce granice się zacierają. Wiele nowoczesnych SIEM ma funkcje typowe dla SOAR („SOAR light”), a XDR nierzadko oferuje podstawową agregację logów i prostą korelację. Dlatego podczas planowania inwestycji lepiej myśleć o procesach, które muszą zaistnieć, niż o kategoriach produktów.

Przykładowy podział ról w jednej organizacji może wyglądać tak:

• XDR odpowiada za szybką detekcję typowych kampanii malware/phishing, ataków na endpointy, próby przejęcia kont w M365, izoluje hosty, blokuje złośliwe wiadomości i adresy URL.
• SIEM zbiera dane z XDR, systemów sieciowych, aplikacji biznesowych, systemów OT, chmury publicznej, a także logi systemów IAM. Służy do korelacji na poziomie całej organizacji, dochodzeń, analizy incydentów wieloetapowych.
• SOAR spina to w całość: w momencie poważnego alertu XDR tworzy ticket, SOAR uruchamia playbook (np. blokada konta w AD, powiadomienie właściciela systemu, zebranie dodatkowych logów z SIEM), a analityk SOC podejmuje ostateczne decyzje.

Wspólny wniosek z tego porządkowania jest prosty: definicje SIEM i XDR są płynne, bo producenci próbują objąć jak najszerszy kawałek rynku. Dlatego układając strategię inwestycji, trzeba wyjść od własnych procesów, ryzyk i zasobów, a dopiero później przypasowywać do nich kategorie narzędzi.

Obietnica „pełnej widoczności”: co technicznie oznacza i dlaczego rzadko się spełnia

Hasło „pełna widoczność” dobrze wygląda w prezentacjach sprzedażowych, ale w praktyce technicznej oznacza konkretny zestaw elementów. Dopiero ich kombinacja decyduje, czy SOC jest w stanie naprawdę zobaczyć i zrozumieć kluczowe zdarzenia.

Elementy widoczności: dane, głębia, kontekst

Widoczność w kontekście SIEM i XDR można rozbić na kilka warstw:

• źródła logów i telemetry – systemy operacyjne, firewalle, zabezpieczenia brzegowe, serwisy chmurowe, poczta, aplikacje biznesowe, bazy danych, systemy IAM, usługowe API,
• głębia telemetry – nie tylko log „logowanie udane”, ale szczegół: z jakiego urządzenia, z jakiej aplikacji, z jakim tokenem, z jaką geolokalizacją, czy był MFA, jak wyglądały poprzednie logowania,
• kontekst biznesowy – wiedza, który system jest krytyczny, do jakiego procesu należy, kto jest właścicielem, jakie są godziny pracy, jaki jest dopuszczalny poziom ryzyka,
• dane o tożsamości i uprawnieniach – mapowanie kont technicznych na właścicieli, znajomość grup uprzywilejowanych, powiązanie wielu kont jednego użytkownika w różnych systemach,
• korelacja w czasie – możliwość powiązania ruchów atakującego z kilku dni czy tygodni, a nie tylko „tu i teraz” z ostatniej godziny.

Narzędzia SIEM i XDR dostarczają mechanizmów do gromadzenia i analizowania takich danych, ale same z siebie nie potrafią „zgadnąć”, co w Twojej organizacji jest krytyczne, a co mniej istotne. Tu zaczyna się rola architektury bezpieczeństwa i świadomego projektowania use case’ów, o czym dalej.

Typowe luki w widoczności: OT, IoT, shadow IT i środowiska poboczne

Nawet firmy z pozoru dobrze zabezpieczone mają obszary, w których widoczność jest cząstkowa albo żadna. Do najczęstszych należą:

• systemy OT/ICS – linie produkcyjne, sterowniki PLC, systemy SCADA. Często działają na starych systemach operacyjnych, bez agentów, z ograniczonym dostępem do logów. Integracje z SIEM bywają powierzchowne, a możliwości ingerencji – mocno ograniczone.
• IoT i urządzenia specjalistyczne – kamery, systemy HVAC, urządzenia medyczne, terminale POS. Wiele z nich nie ma standardowych mechanizmów logowania lub generuje logi w formacie trudnym do analizy.
• shadow IT – usługi SaaS i narzędzia chmurowe kupowane lub uruchamiane przez działy biznesowe bez udziału IT. Brak integracji z centralnym IAM i SIEM powoduje, że aktywność użytkowników w tych systemach jest niewidoczna dla SOC.

Ślepe plamy w chmurze, DevOps i środowiskach testowych

Podczas jednego z przeglądów incydentów zespół SOC odkrył, że pierwsze ślady włamania są widoczne tylko w logach z konta deweloperskiego w chmurze, o którym nikt z bezpieczeństwa wcześniej nie słyszał. Wszystkie sztandarowe integracje z SIEM i XDR działały poprawnie – tyle że w „oficjalnych” subskrypcjach i tenantach.

Do podobnych sytuacji dochodzi szczególnie tam, gdzie rozwój i utrzymanie środowisk chmurowych jest silnie zdecentralizowane. Typowe luki pojawiają się w kilku miejscach:

• subskrypcje i konta „eksperymentalne” – tymczasowe projekty, proof‑of‑concepty, inicjatywy R&D, które ruszają poza formalnym procesem i często nigdy nie są „wciągane” do centralnego nadzoru,
• środowiska testowe i staging – mniej restrykcyjne polityki, brak wymogu pełnego logowania, domyślne hasła w serwisach pomocniczych,
• automatyzacje DevOps – narzędzia CI/CD, pipeline’y, systemy do zarządzania konfiguracją, gdzie używa się uprzywilejowanych tokenów i kont serwisowych, ale logi trafiają co najwyżej do lokalnego sysloga.

W takich miejscach XDR często nie ma jak zainstalować agenta, a SIEM nie dostaje żadnej sensownej telemetry, bo nikt nie skonfigurował eksportu logów. W momencie incydentu SOC widzi dopiero „końcówkę ogona komety” – np. podejrzane logowanie do produkcyjnego tenant’a – bez wglądu w to, co działo się kilka kroków wcześniej w bocznym projekcie chmurowym.

Praktyczny wniosek: pełna widoczność bez operacyjnego porządku w chmurze i DevOps pozostaje teorią. Rejestr subskrypcji, obowiązkowe szablony IaC z ustawionym eksportem logów, standardowe integracje CI/CD z SIEM/XDR – to elementy, które robią więcej niż kolejna funkcja „AI” w narzędziu.

Dlaczego obietnica „360° visibility” rozpada się przy wdrożeniu

Wielu zespołom SOC obiecano już „widoczność 360°”. Na etapie POC wszystko wygląda przekonująco: lab, kilka serwerów, parę kont M365, przykładowe ataki – narzędzie wykrywa niemal wszystko. Zderzenie z produkcją bywa bolesne.

Najczęstsze przyczyny tego rozdźwięku są dość przyziemne:

• ograniczenia licencyjne i kosztowe – w labie podłączone są wszystkie logi „bez limitu”, w realnym świecie nagle okazuje się, że pełny eksport z firewalli, proxy i serwerów aplikacyjnych przekracza budżet licencji o rząd wielkości,
• niedoszacowanie złożoności integracji – „mamy konektor” w prezentacji nie oznacza, że dział IT będzie w stanie go samodzielnie wdrożyć, utrzymywać i debugować, gdy zmieni się wersja aplikacji albo format logów,
• brak czasu na tuning – reguły detekcji i playbooki są dostarczane w wersji ogólnej, a ich dopasowanie do realnego ruchu, aplikacji wewnętrznych i procesów biznesowych wymaga tygodni lub miesięcy pracy, których nikt nie wliczył do projektu,
• niewidzialna infrastruktura – systemy „czyjeś”, bez właściciela, stare aplikacje, których nikt nie chce dotykać, łącza MPLS, oddziały zagraniczne z własnym IT – to elementy, które trudno ująć w modelu „podłącz wszystko i gotowe”.

Do tego dochodzi czynnik ludzki: zespół SOC często jest już przeciążony bieżącą operatyką. Na papierze „wzrost liczby alertów” jest zaletą, w praktyce bywa kolejnym źródłem szumu, jeśli nie towarzyszy mu realne wsparcie w postaci automatyzacji i odciążenia analityków.

Morał z tego prosty: realna widoczność rodzi się w procesach wdrożenia i utrzymania, a nie na slajdach. Narzędzie może ją wspierać, ale nie zastąpi żmudnej pracy porządkowania źródeł danych, kontraktowania odpowiedzialności i optymalizowania zakresu logowania.

Nowości funkcjonalne w SIEM i XDR, które mają realny wpływ na bezpieczeństwo

Podczas jednego z ćwiczeń symulujących ransomware zespół zauważył, że ich „stary” SIEM na bazie reguł korelacji prawie w ogóle nie reaguje, dopóki szyfrowanie nie uderzy w udziały sieciowe. Dopiero dołożony XDR z analityką behawioralną na endpointach wychwycił nietypowe operacje na plikach i skoki uprawnień na wczesnym etapie. Ten kontrast dobrze pokazuje, gdzie nowe funkcje faktycznie zmieniają obraz gry.

Analityka behawioralna i UEBA zamiast samych reguł korelacji

Klasyczny model SIEM opiera się na regułach typu „if/then”: jeśli zobaczysz pięć nieudanych logowań w 10 minut, zgłoś alert. Dzisiejsze środowiska, rozproszone i hybrydowe, generują taką ilość zdarzeń, że ręczne pisanie i utrzymywanie reguł nie wystarcza. Tu wchodzi UEBA (User and Entity Behavior Analytics) oraz szeroko rozumiana analityka behawioralna.

Nowoczesne platformy potrafią budować modele typowego zachowania użytkowników, hostów i kont serwisowych: z jakich lokalizacji zwykle się logują, do jakich systemów, o jakich porach, jakie wolumeny danych przesyłają. Odchylenia od tego profilu są punktowane ryzykiem, a na tej podstawie generowane są alerty.

Przykład z praktyki: inżynier działu utrzymania łączy się raz w tygodniu z konkretnymi serwerami aplikacyjnymi z Polski. Nagle pojawia się logowanie z innego kontynentu do kilku nietypowych systemów, a po nim zrzut dużej liczby rekordów z bazy. Reguła typu „logowanie udane” niczego tu nie wychwyci, ale model behawioralny potraktuje to jako wysokie odchylenie i np. zainicjuje wymuszoną weryfikację MFA lub blokadę sesji.

Klucz w tym, by UEBA nie było traktowane jako „magiczna czarna skrzynka”. Warto, by SOC rozumiał, skąd biorą się wyniki, potrafił korygować modele (whitelisty, wyjątki) i łączyć sygnały behawioralne z klasycznymi regułami korelacji. Dopiero połączenie tych dwóch światów znacząco zmniejsza liczbę fałszywych alarmów i podnosi skuteczność detekcji ataków niestandardowych.

Automatyzacja reakcji: od „SOAR light” do pełnych playbooków

Podczas incydentu liczą się minuty. W wielu organizacjach blokada konta, odcięcie hosta od sieci czy zainicjowanie resetu haseł nadal wymaga kilku telefonów i ręcznego wypełniania zgłoszeń. W międzyczasie malware rozprzestrzenia się dalej.

Nowa generacja narzędzi SIEM i XDR coraz częściej zawiera wbudowane funkcje automatyzacji – od prostych akcji po rozbudowane playbooki:

• akcje natychmiastowe na endpointach – izolacja hosta, wstrzymanie procesu, wymuszenie skanu, usunięcie pliku,
• interakcja z systemami tożsamości – blokada konta w AD/AAD, wymuszenie resetu hasła, wylogowanie z aktywnych sesji,
• działania sieciowe – dodanie IOC (IP, domena, URL) do list blokujących na firewallach lub proxy, modyfikacja reguł segmentacji,
• integracje z ITSM – automatyczne zakładanie zgłoszeń, aktualizacja statusów, powiadomienia do właścicieli systemów i managerów.

Największy zysk pojawia się wtedy, gdy automatyzacja jest stopniowana. Przykładowo:

• dla zdarzeń niskiego ryzyka system tylko wzbogaca alert o dane kontekstowe (dodatkowe logi, historię działań użytkownika),
• dla średniego ryzyka uruchamia półautomatyczny playbook – analityk zatwierdza proponowane akcje jednym kliknięciem,
• dla wysokiego ryzyka i dobrze zdefiniowanych scenariuszy (np. wykryty ransomware) pewien zestaw działań wykonywany jest od razu bez zgody człowieka.

Dzięki takiemu podejściu SOC nie traci kontroli, a jednocześnie zyskuje realne skrócenie czasu reakcji. Zespół może skupić się na analizie i dochodzeniach, a nie na ręcznym wykonywaniu powtarzalnych czynności operacyjnych.

Threat intelligence „pod korelacją”, a nie w PDF-ie

W wielu organizacjach feedy threat intelligence kończą swój żywot w raportach PDF albo w osobnym portalu, do którego analityk zagląda sporadycznie. Tymczasem sens ma tylko taka TI, która faktycznie zasila mechanizmy detekcji i reakcji w SIEM i XDR.

Nowsze platformy idą w stronę głębokiej integracji TI z pipeline’em analitycznym:

• IOC z wielu źródeł (komercyjnych, community, własnych) są normalizowane, deduplikowane i wersjonowane,
• informacje o kampaniach, TTP (taktyki, techniki, procedury) i powiązanych grupach APT są mapowane do MITRE ATT&CK,
• korelacja w SIEM/XDR wykorzystuje te dane w czasie rzeczywistym, np. podbijając scoring alertu, jeśli dany IP lub domena pojawia się w aktualnej kampanii wymierzonej w daną branżę.

Coraz częściej narzędzia pozwalają także na wzbogacanie wewnętrznych danych o prywatne IOC i wiedzę z poprzednich incydentów. Przykładowo, po wykrytym ataku SOC może dodać hash’y plików i domeny C2 do własnego feedu, który od tej pory jest traktowany tak samo jak zewnętrzne źródła. W ten sposób organizacja buduje własny, żywy kontekst, zamiast bazować wyłącznie na ogólnych listach.

Nowe możliwości w zakresie obserwowalności aplikacyjnej

Coraz więcej ataków „chowa się” wewnątrz aplikacji biznesowych – szczególnie webowych i mikroserwisowych. Klasyczne logi systemowe i sieciowe dają zbyt mało informacji, by wykryć nadużycia logiki biznesowej czy subtelne manipulacje danymi.

W odpowiedzi na to część dostawców SIEM i XDR integruje się ściślej z narzędziami APM/observability (traces, metrics, logs), a także z mechanizmami RASP/WAF na poziomie aplikacji. Pozwala to na:

• śledzenie konkretnej transakcji użytkownika przez wiele mikroserwisów,
• korelowanie wyjątków w kodzie, spike’ów opóźnień i błędów z podejrzanymi żądaniami HTTP lub anomaliami autoryzacji,
• wykrywanie nietypowych sekwencji wywołań API, które mogą świadczyć o próbach enumeracji lub eksfiltracji danych.

Nie chodzi o to, by SOC analizował każdy trace. Istotne jest to, że przy poważnym incydencie analityk ma możliwość „zejścia” z poziomu ogólnego alertu na konkretny request HTTP, payload czy transakcję biznesową, bez konieczności ręcznego zbierania danych z kilku innych systemów monitoringu.

Wsparcie „as a service”: MDR/MXDR jako rozszerzenie zespołu

W wielu firmach jest tak: narzędzia są kupione, integracje częściowo zrobione, ale brakuje ludzi, którzy „dociągną” temat. Rekrutacja do SOC jest trudna, utrzymanie doświadczonych analityków – jeszcze trudniejsze. Z tego powodu rośnie rola usług typu MDR/MXDR (Managed Detection and Response).

Kluczowa zmiana polega na tym, że dostawca nie tylko hostuje narzędzie, ale również aktywnie uczestniczy w procesie detekcji i reakcji:

• monitoruje alerty 24/7,
• tuninguję reguły i playbooki na podstawie globalnego doświadczenia,
• przeprowadza wstępną triage i proponuje konkretne działania,
• w niektórych modelach – podejmuje wybrane akcje w Twoim imieniu (np. izolacja hosta, blokada konta).

To rozwiązanie ma sens szczególnie wtedy, gdy organizacja nie planuje budować pełnego SOC-u in‑house lub chce go odciążyć w godzinach nocnych. Warunkiem powodzenia jest jednak jasny podział ról: kto podejmuje ostateczne decyzje biznesowe, jak szybko dostawca ma reagować, do jakich systemów ma dostęp i jakie dane może przetwarzać.

Bez takiego „kontraktu operacyjnego” łatwo skończyć z sytuacją, w której MDR generuje setki powiadomień i raportów, ale nikt po stronie klienta nie jest odpowiedzialny za ich domknięcie. Z punktu widzenia widoczności to wciąż krok naprzód, ale z perspektywy bezpieczeństwa – jedynie połowa drogi.

Jak zdiagnozować swoje potrzeby: od mapy ryzyka do wymagań wobec narzędzia

Podczas jednego z warsztatów z klientem CFO zapytał prosto: „Czy jeśli kupimy ten XDR, to będziemy bezpieczni?”. Sala zamilkła. Po chwili architekt bezpieczeństwa wyświetlił diagram kluczowych procesów biznesowych i pokazał kilka czerwonych pól, gdzie nie ma ani logów, ani sensownej kontroli. „Jeśli nic z tym nie zrobimy, żaden XDR nam nie pomoże” – skwitował. Ta scena dobrze oddaje, od czego w ogóle wypada zacząć rozmowę o inwestycjach.

Mapa ryzyka i krytycznych procesów zamiast listy systemów

Naturalnym odruchem jest sporządzenie listy systemów, które „trzeba podłączyć” do SIEM/XDR. To podejście techniczne, ale niekoniecznie prowadzi do najlepszych decyzji inwestycyjnych. Skuteczniejszym punktem wyjścia jest perspektywa procesów i ryzyka.

Praktyczny sposób pracy:

Od ryzyka do wymagań: konkretne kroki warsztatowe

Na jednym z projektów CISO przyjechał na warsztat z gotową „wishlistą” funkcji XDR. Po godzinie pracy na mapie procesów połowę pozycji sam skreślił – okazało się, że nie ma sensu inwestować w zaawansowaną analitykę dla obszaru, który i tak wkrótce będzie outsourcowany do dostawcy chmurowego.

Dobra mapa ryzyka to dopiero początek. Trzeba ją przekuć na konkretne wymagania wobec narzędzia i integracji. Sprawdza się prosty schemat warsztatu:

1. Zidentyfikuj scenariusze, a nie tylko aktywa – dla każdego krytycznego procesu zapisz 2–3 scenariusze, które naprawdę cię bolą (np. „nieuprawniony przelew”, „masowy wyciek rekordu klienta”, „podmiana danych w zamówieniach”).
2. Dla scenariusza wypisz pytania detekcyjne – „po czym to zobaczymy?”, „jakie logi są do tego potrzebne?”, „gdzie widać pierwsze symptomy?”.
3. Oceń, co już masz – które z tych danych istnieją, gdzie są zbierane, jaką mają jakość, co realnie jest dziś monitorowane.
4. Na tej podstawie definiuj wymagania – „narzędzie musi korelować to z tym”, „musi obsłużyć dzienny wolumen logów z systemu X”, „musi mieć gotowe integracje z Y/Z”.

Zamiast abstrakcyjnego „pełnej widoczności”, pojawiają się konkretne zdania: „chcemy być w stanie w ciągu 5 minut wykryć próbę wycieku danych z CRM przez nietypowe zapytania SQL i ruch wychodzący”. Tak zdefiniowane cele łatwiej później zmierzyć.

Priorytetyzacja: gdzie pełna widoczność ma być „naprawdę pełna”

Na spotkaniu z zarządem jedna z firm pokazała heatmapę widoczności: od zielonego (dobra telemetria) do czerwonego (prawie zero danych). Największe zaskoczenie: na czerwono świecił system fakturowania, bo „zawsze działał i nigdy nie było z nim problemu”. Właśnie tam podjęto decyzję o największej inwestycji w logowanie.

Nie da się mieć takiego samego poziomu widoczności wszędzie – brakłoby budżetu i ludzi do obsługi. Trzeba świadomie zadecydować, gdzie celujemy w maksymalnie szczegółową obserwowalność, a gdzie wystarczy poziom „kontrolowany minimalizm”. Pomaga prosty podział:

• Strefa A – procesy krytyczne biznesowo i regulacyjnie (np. systemy finansowe, dane klientów, OT w produkcji). Tu dążymy do:
  • szerokiego zakresu logów (aplikacyjne, systemowe, sieciowe, bezpieczeństwa),
  • głębokiej korelacji z UEBA/TI,
  • automatyzacji reakcji przynajmniej na część scenariuszy.
• Strefa B – systemy ważne operacyjnie, ale o niższym profilu ryzyka. Tu celem jest:
  • detekcja „głośnych” ataków i nadużyć,
  • agregacja logów głównie do potrzeb dochodzeniowych,
  • mniejsza liczba customowych reguł.
• Strefa C – obszary pomocnicze (np. fragmenty zaplecza biurowego, systemy pomocnicze bez danych wrażliwych). Tutaj:
  • zbieramy rzeczy podstawowe (logi bezpieczeństwa z AD, poczty, endpointów),
  • odkładamy zaawansowaną analitykę na później lub wcale.

Takie rozróżnienie pomaga później rozmawiać z dostawcami: „pełna widoczność” ma obowiązywać np. tylko w Strefie A, a nie w całej infrastrukturze.

Wymagania funkcjonalne vs. niefunkcjonalne: dwa różne światy

Na etapie wyboru rozwiązania dyskusja często krąży wokół listy checkboxów: ma UEBA, ma SOAR, ma integrację z chmurą. Tymczasem projekty rozbijają się zwykle nie o funkcje, ale o rzeczy pozornie „nudne”: wydajność, skalowalność, model licencjonowania, ergonomię pracy SOC.

Warto rozdzielić wymagania na dwie kategorie i podejść do nich równie poważnie:

• Funkcjonalne – czyli co narzędzie potrafi:
  • jakie źródła logów i typy telemetryczne są wspierane out-of-the-box,
  • jakie są gotowe reguły, playbooki, integracje z TI,
  • jak wygląda wsparcie dla chmury (IaaS/PaaS/SaaS) i środowisk hybrydowych.
• Niefunkcjonalne – czyli czy to da się utrzymać:
  • koszt przechowywania i przetwarzania logów w czasie (nie tylko licencja startowa),
  • wymagania wydajnościowe przy prognozowanym wolumenie i retencji,
  • łatwość tuningu reguł i budowania własnych korelacji,
  • czy interfejs i workflow realnie wspierają analityków (mniej kliknięć do decyzji),
  • dostępność lokalnego wsparcia i kompetencji na rynku.

Rozwiązanie, które na papierze wygląda imponująco, ale wymaga trzech pełnoetatowych inżynierów tylko do administracji, w praktyce może obniżyć poziom bezpieczeństwa – bo nie będzie dobrze utrzymane.

Warsztaty z SOC i właścicielami biznesowymi zamiast zakupów „w bańce IT”

W jednej organizacji sprzedaż twierdziła, że „nie da się” wysłać logów z kluczowej aplikacji CRM, bo to system od zewnętrznego dostawcy. Po wspólnej sesji z biznesem okazało się, że ten sam dostawca oferuje moduł audit logów w wyższej wersji abonamentu – nikt wcześniej o to po prostu nie zapytał.

Projekt SIEM/XDR nie może być jedynie inicjatywą IT czy cyber. Żeby realnie odzwierciedlał procesy i ryzyko, potrzebne jest zaangażowanie kilku grup:

• SOC/CSIRT – znają ból alert fatigue, wiedzą, co jest dziś niewidoczne, gdzie brakuje danych w dochodzeniach.
• Właściciele biznesowi procesów – potrafią nazwać, które scenariusze są naprawdę krytyczne i jakie są skutki ich materializacji.
• IT/DevOps – wiedzą, jakimi danymi dysponują systemy, co można łatwo wyeksportować, jakie są ograniczenia techniczne.
• Zarządzanie ryzykiem/zgodność – pilnują, by mapowanie na regulacje (RODO, DORA, NIS2) było spójne z resztą organizacji.

Jeśli te perspektywy spotkają się przy jednym stole, wymagania wobec narzędzia stają się prostsze, precyzyjniejsze i przede wszystkim – powiązane z realnymi potrzebami, a nie z modą na konkretne hasła marketingowe.

Projektowanie zakresu logowania: więcej nie zawsze znaczy lepiej

W pewnej instytucji finansowej pierwsza wersja SIEM zebrała „wszystko, co się dało”. Po kilku miesiącach indeks był przepełniony, koszty przechowywania wystrzeliły, a analitycy i tak nie korzystali z 80% danych. Druga iteracja zaczęła się od pytania: „Do jakich pytań dochodzeniowych i scenariuszy detekcji te logi są nam potrzebne?”.

Rozsądne projektowanie logowania to klucz do opłacalności inwestycji. Zamiast masowego onboardingu wszystkich źródeł, sensownie jest przejść przez kilka filtrów:

1. Cel – czy log ma służyć głównie do:
   • detekcji w czasie zbliżonym do rzeczywistego,
   • analizy powłamaniowej i dochodzeń,
   • spełnienia wymogów regulacyjnych,
   • wsparcia obserwowalności (APM, performance).
2. Minimalny zestaw pól – czytelne zdefiniowanie, które pola są wymagane dla korelacji (np. user, host, IP, session ID, request ID) i pilnowanie ich spójności.
3. Sampling / agregacja – w niektórych obszarach (np. logi techniczne serwera www) wystarczy próbka lub agregaty metryczne, a nie każdy pojedynczy event.
4. Retencja różnicowana – inne okresy przechowywania dla danych krytycznych (np. 1–2 lata pełnych logów) i innych – skrócone, za to dostępne w ujęciu statystycznym.

Dzięki temu „pełna widoczność” nie oznacza zalewu nieużytecznych eventów, tylko przemyślany zestaw danych odpowiadający na konkretne pytania obronne.

Jak testować obietnice dostawców na żywym organizmie

Na prezentacjach sprzedażowych każdy produkt „wykrywa lateral movement i ataki typu zero-day”. Dopiero gdy klient uruchomił pilota i odpalił kilka kontrolowanych symulacji ataku, wyszło na jaw, że spora część obietnic wymaga żmudnego ręcznego tuningu, którego nikt wcześniej nie wkalkulował.

Zamiast wierzyć w dema na danych demo, lepiej zaplanować pilota na realistycznym wycinku środowiska i z kilkoma jasno zdefiniowanymi testami. Pomaga takie podejście:

• Wybierz fragment Strefy A – np. jeden kluczowy proces (kanał bankowości internetowej, system sprzedaży online, krytyczny system OT).
• Zdefiniuj 5–10 scenariuszy testowych – od prostych (brute-force, malware na stacji roboczej) po bardziej złożone (powolna eksfiltracja danych, nadużycie uprawnień admina).
• Przeprowadź symulacje – może to być red teaming, narzędzia typu breach & attack simulation, a nawet ręcznie odegrane scenariusze w środowisku testowym.
• Mierz czas i jakość – ile czasu upłynęło od zdarzenia do alertu, jak szczegółowy jest kontekst, ile było fałszywych alarmów, ile ręcznej pracy wymaga dojście do przyczyny.

Takie ćwiczenie często brutalnie weryfikuje marketingowe obietnice. Z drugiej strony pozwala wyłapać narzędzia, które może nie błyszczą na slajdach, ale dobrze sprawdzają się w prawdziwym SOC.

Licencjonowanie i TCO: jak nie utopić budżetu w „tani” SIEM/XDR

Jeden z klientów po roku od wdrożenia SIEM stanął przed dylematem: albo drastycznie ograniczyć wolumen danych, albo podwoić budżet. Okazało się, że model licencjonowania „per GB przetworzonych danych” przy dynamicznym rozwoju biznesu był tykającą bombą, której nikt wcześniej nie policzył.

W dyskusji o inwestycjach w SIEM/XDR rzadko z przodu pojawia się temat całkowitego kosztu posiadania (TCO). Tymczasem to on decyduje, czy po kilku latach narzędzie będzie rozwijane, czy „zamrożone” w minimalnej konfiguracji. W kalkulacji warto uwzględnić:

• Koszty licencji – nie tylko początkowe, ale też prognozowany wzrost przy:
  • skalowaniu wolumenu logów,
  • dołączaniu nowych źródeł (szczególnie chmurowych),
  • rozszerzaniu funkcji (dodatkowe moduły, UEBA, SOAR).
• Koszty infrastruktury – serwery, storage, sieć (w modelu on-prem) lub koszty usług chmurowych (compute, storage, egress).
• Koszty operacyjne – liczba osób potrzebnych do:
  • utrzymania platformy,
  • tuningu reguł,
  • obsługi alertów.
• Ukryte koszty integracji – pisanie konektorów, normalizacja niespójnych logów, prace po stronie systemów źródłowych.

Narzędzie, które na starcie wydaje się tańsze, może po trzech latach okazać się znacznie droższe niż konkurencja, jeśli model rozliczeń jest źle dopasowany do profilu organizacji. Dlatego podczas wyboru warto przeprowadzić choćby zgrubną symulację TCO w horyzoncie 3–5 lat, przyjmując kilka scenariuszy wzrostu.

Mierniki sukcesu: jak sprawdzić, czy inwestycja faktycznie działa

Po wdrożeniu nowego XDR w jednej firmie liczba alertów… wzrosła. Pierwsza reakcja zarządu: „czyli jest gorzej niż było?”. Dopiero wspólne przejście przez dane pokazało, że choć alertów jest więcej, to czas od zdarzenia do decyzji skrócił się kilkukrotnie, a liczba incydentów eskalowanych do biznesu spadła – bo SOC lepiej je filtrował.

Bez mierników łatwo ulec wrażeniu, że „coś działa” tylko dlatego, że mamy nowy panel. Kilka praktycznych KPI, które pomagają ocenić sens inwestycji:

• Mean Time to Detect (MTTD) – czas od pierwszego śladu technicznego do wygenerowania sensownego alertu.
• Mean Time to Respond (MTTR) – czas od alertu do podjęcia decyzji i wykonania kluczowych akcji (np. blokady konta, izolacji hosta).



Najważniejsze punkty

• Sam zakup SIEM/XDR i „odhaczenie wdrożenia” nie gwarantuje wykrywania incydentów – bez przemyślanego zakresu monitoringu zawsze pozostaną martwe strefy, tak jak w przypadku ataku omijającego endpointy i uderzającego w chmurę.
• „Pełna widoczność” to nie funkcja produktu, lecz stan organizacji: umiejętność wykrycia kluczowych ryzyk biznesowych z rozsądnie dobranych źródeł danych, połączonych z kontekstem tożsamości i procesów.
• Nadmiar nieskalibrowanych alertów paraliżuje SOC – jeśli po wdrożeniu pojawiają się tysiące zgłoszeń dziennie, a żaden nie prowadzi do realnej reakcji, problemem jest brak priorytetyzacji i dobrze zdefiniowanych use case’ów, a nie „za mało narzędzi”.
• Model licencjonowania oparty na wolumenie logów wymusza trudne decyzje: gdy koszty rosną, organizacje wyłączają część źródeł z monitoringu, co bezpośrednio obniża szansę wychwycenia istotnych incydentów.
• Nowoczesny SIEM przekształcił się z „logowiska” w centralną platformę analityczno‑regulacyjną, która służy nie tylko SOC, lecz także compliance, audytowi i architekturze bezpieczeństwa – ale wymaga dojrzałych procesów i kompetentnego zespołu.
• XDR nie jest magicznym następcą EDR, który „załatwi wszystko”, lecz spoiwem łączącym telemetrię z różnych domen (endpoint, poczta, sieć, tożsamości), którego skuteczność zależy od integracji z resztą ekosystemu bezpieczeństwa.

Źródła

• NIST Special Publication 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. National Institute of Standards and Technology (2011) – Ramy monitoringu bezpieczeństwa, logów i widoczności ryzyk
• NIST Special Publication 800-92: Guide to Computer Security Log Management. National Institute of Standards and Technology (2006) – Zarządzanie logami, rola centralizacji i korelacji zdarzeń
• ISO/IEC 27035-1: Information security incident management – Part 1: Principles of incident management. International Organization for Standardization (2023) – Procesy obsługi incydentów, rola SOC i priorytetyzacji
• MITRE ATT&CK Enterprise Matrix. MITRE Corporation – Modelowanie technik ataków, potrzeby telemetrii z różnych domen
• Gartner Market Guide for Security Information and Event Management. Gartner – Charakterystyka współczesnych platform SIEM i trendów rynkowych
• ENISA Threat Landscape. European Union Agency for Cybersecurity – Przegląd zagrożeń, znaczenie korelacji logów i widoczności w SOC