Jak wykorzystać Splunk Enterprise Security w SOC?

Splunk Enterprise Security jest wdrażany w organizacjach najczęściej z dwóch powodów. Po pierwsze, jako odpowiedź na potrzebę wykorzystania dojrzałej platformy klasy SIEM, należącej do najczęściej wybieranych rozwiązań w tym segmencie. Po drugie, jako naturalne rozszerzenie funkcjonującej już w organizacji platformy Splunk, wykorzystywanej do gromadzenia, przetwarzania i analizy danych.

Obie przesłanki są uzasadnione. Jednocześnie doświadczenia z projektów wdrożeniowych pokazują, że pomiędzy samym posiadaniem licencji Splunk Enterprise Security a skutecznym prowadzeniem operacji SOC z wykorzystaniem tej platformy istnieje istotna różnica. O efektywności wdrożenia przesądzają bowiem nie wyłącznie możliwości technologiczne rozwiązania, lecz również jakość przyjętej architektury, sposób organizacji procesów operacyjnych oraz poziom kompetencji zespołu odpowiedzialnego za utrzymanie i rozwój środowiska.

Celem niniejszego opracowania jest przedstawienie Splunk Enterprise Security z perspektywy praktycznego zastosowania w operacjach Security Operations Center. Analiza koncentruje się na rzeczywistym wykorzystaniu platformy w codziennej pracy zespołów bezpieczeństwa, z uwzględnieniem aspektów architektonicznych, operacyjnych i organizacyjnych.

1. Splunk Enterprise Security — charakterystyka platformy

W pierwszej kolejności należy rozróżnić dwa pojęcia, które w praktyce rynkowej bywają stosowane zamiennie. Splunk Enterprise jest platformą danych przeznaczoną do zbierania, indeksowania oraz analizy danych ustrukturyzowanych i nieustrukturyzowanych. Splunk Enterprise Security (Splunk ES) stanowi natomiast rozszerzenie tej platformy o wyspecjalizowaną warstwę bezpieczeństwa, obejmującą między innymi mechanizmy Notable Events, Risk-Based Alerting, Investigations, Glass Tables, integrację z frameworkiem MITRE ATT&CK, obsługę threat intelligence oraz Adaptive Response Framework.

Rozróżnienie to ma istotne znaczenie z punktu widzenia operacyjnego. Splunk Enterprise może pełnić funkcję centralnej platformy analitycznej dla wielu obszarów organizacji, w tym IT operations, zespołów aplikacyjnych, obszarów zgodności czy analityki biznesowej. Splunk ES wykorzystuje te same dane jako telemetrię bezpieczeństwa, nadając im kontekst niezbędny do wykrywania zagrożeń, prowadzenia analiz oraz obsługi incydentów.

W organizacjach wykorzystujących platformę Splunk również poza obszarem bezpieczeństwa wdrożenie Splunk ES może przyspieszyć osiągnięcie wartości operacyjnej, ponieważ zespół SOC uzyskuje dostęp do już istniejących i zaindeksowanych źródeł danych. W modelu, w którym platforma jest wdrażana wyłącznie na potrzeby bezpieczeństwa, warunkiem powodzenia staje się odpowiednio zaplanowana strategia pozyskiwania i normalizacji danych. Samo wdrożenie warstwy ES, bez właściwie zaprojektowanego zaplecza danych, nie prowadzi automatycznie do osiągnięcia dojrzałości operacyjnej SOC.

W praktyce zestaw obejmujący Splunk Enterprise oraz Splunk ES należy traktować nie jako zamknięte narzędzie, lecz jako środowisko operacyjne i analityczne, które wymaga rozwijania zgodnie z potrzebami organizacji. Zespoły SOC nie ograniczają się w takim modelu do korzystania z gotowych treści detekcyjnych i mechanizmów analitycznych, lecz projektują i utrzymują własne scenariusze detekcyjne, dashboardy, reguły korelacyjne oraz mechanizmy automatyzacji reakcji.

2. Architektura Splunk ES: indexery, search heads i forwardery

Skuteczność wykorzystania Splunk Enterprise Security jest bezpośrednio zależna od jakości architektury wdrożenia. Zanim platforma zacznie realizować funkcje detekcyjne, musi zapewniać stabilne, skalowalne i przewidywalne przetwarzanie danych z odpowiednich źródeł.

Forwardery odpowiadają za pozyskiwanie danych u źródła. Universal Forwarder jest lekkim komponentem przeznaczonym do szerokiego zastosowania w środowiskach serwerowych i końcowych. Heavy Forwarder może realizować parsowanie, filtrowanie oraz wzbogacanie danych przed ich przekazaniem do warstwy indeksowania. W praktyce bywa wykorzystywany również jako element pośredniczący w strefach o podwyższonych wymaganiach bezpieczeństwa, w tym w segmentach DMZ.

Indexery stanowią warstwę odpowiedzialną za przyjmowanie danych, ich zapis w indeksach oraz udostępnianie do wyszukiwania i analizy. W większych środowiskach działają najczęściej w architekturze klastrowej, zapewniającej wysoką dostępność, odporność na awarie oraz możliwość równoległego przetwarzania dużych wolumenów danych. Parametry tej warstwy mają bezpośrednie przełożenie na wydajność środowiska, model kosztowy oraz możliwości dalszej rozbudowy.

Search Heads tworzą warstwę analityczną i prezentacyjną. To w jej ramach realizowane są interakcje użytkowników z platformą, wykonywane są zapytania SPL, obsługiwane są dashboardy, mechanizmy alertowania oraz sama aplikacja Splunk ES. W rozbudowanych środowiskach Search Heads funkcjonują w modelu klastrowym, zapewniającym równoważenie obciążenia i spójność artefaktów konfiguracyjnych.

Architekturę uzupełniają komponenty zarządcze, takie jak Deployment Server, Cluster Manager, License Manager oraz Monitoring Console. Ich rola jest szczególnie istotna w środowiskach on-premises, gdzie organizacja samodzielnie odpowiada za utrzymanie infrastruktury bazowej. W modelu Splunk Cloud część tych obowiązków przejmuje dostawca usługi, co zmienia zakres odpowiedzialności zespołu klienta, ale nie eliminuje potrzeby właściwego zaprojektowania modelu operacyjnego.

W praktyce wdrożeniowej organizacje rozważające Splunk ES najczęściej wybierają jeden z trzech modeli: wdrożenie w Splunk Cloud Platform, wdrożenie on-premises w oparciu o Splunk Enterprise lub model hybrydowy. Każdy z nich wiąże się z odmiennymi konsekwencjami w obszarze kosztów, zgodności regulacyjnej, wymagań sieciowych oraz odpowiedzialności za utrzymanie środowiska.

Niezależnie od wybranego modelu należy podkreślić, że rzeczywista użyteczność Splunk ES zależy od normalizacji danych do Common Information Model (CIM). CIM zapewnia wspólny model semantyczny dla pól pochodzących z różnych źródeł danych. Jest to warunek poprawnego działania znacznej części wbudowanych mechanizmów detekcyjnych, dashboardów oraz treści bezpieczeństwa dostarczanych przez producenta. Brak właściwej normalizacji ogranicza zdolność platformy do generowania wartości operacyjnej, nawet przy poprawnie zaprojektowanej infrastrukturze.

3. Kluczowe funkcje Splunk ES: Notable Events, Risk-Based Alerting, Investigations

Z perspektywy operacji SOC podstawowe znaczenie mają trzy mechanizmy: Notable Events, Risk-Based Alerting oraz Investigations. To one w największym stopniu kształtują sposób pracy analityków i organizację procesu obsługi incydentów.

Notable Events stanowią podstawową jednostkę operacyjną w Splunk ES. Są generowane przez reguły korelacyjne analizujące dane i identyfikujące wzorce odpowiadające określonym scenariuszom zagrożeń. Notable Event jest ustrukturyzowanym obiektem zawierającym między innymi kontekst analityczny, priorytet, informacje o przypisaniu, statusie oraz historii obsługi. Zdarzenia tego typu trafiają do widoku Incident Review, pełniącego funkcję centralnego interfejsu obsługi incydentów dla zespołu SOC. Istotną cechą tego modelu jest pełna rejestracja działań podejmowanych przez analityków, co wspiera zarówno zarządzanie procesem operacyjnym, jak i wymagania audytowe.

Risk-Based Alerting (RBA) stanowi rozwinięcie klasycznego modelu alertowania. Zamiast generować odrębny alert dla każdego pojedynczego dopasowania reguły, mechanizm ten pozwala akumulować wynik ryzyka przypisany do określonej encji, takiej jak użytkownik, host lub urządzenie. Dopiero po osiągnięciu określonego poziomu skumulowanego ryzyka generowany jest sygnał operacyjny wymagający dalszej analizy. Taki model umożliwia ograniczenie liczby alertów, zwiększenie ich jakości oraz lepsze odzwierciedlenie rzeczywistego poziomu ryzyka. Ma to szczególne znaczenie w środowiskach generujących dużą liczbę zdarzeń o niskiej wartości analitycznej, które w modelu klasycznym prowadziłyby do istotnego obciążenia zespołu SOC.

Investigations zapewniają ramy do prowadzenia ustrukturyzowanych analiz incydentów. Umożliwiają powiązanie w jednym kontekście zdarzeń typu notable, artefaktów, zapytań SPL, notatek operacyjnych oraz czynności podejmowanych przez analityków. Funkcja ta zwiększa powtarzalność procesu dochodzeniowego, wspiera dokumentowanie przebiegu obsługi incydentu oraz ułatwia prowadzenie analiz retrospektywnych i działań doskonalących.

Uzupełnieniem wskazanych mechanizmów jest Adaptive Response Framework, który łączy warstwę detekcyjną z reakcją operacyjną. Pozwala on na inicjowanie działań bezpośrednio z poziomu Splunk ES, w tym uruchamianie integracji z systemami zewnętrznymi, wywoływanie playbooków w Splunk SOAR czy przekazywanie informacji do narzędzi klasy ticketing i case management.

4. Integracja z MITRE ATT&CK oraz rola Splunk Security Essentials

MITRE ATT&CK jest obecnie jednym z najważniejszych standardów wykorzystywanych do opisu technik stosowanych przez przeciwników oraz do oceny pokrycia detekcyjnego organizacji. Splunk Enterprise Security umożliwia wykorzystanie tego modelu w sposób natywny, a ważnym elementem wspierającym budowę dojrzałych use case’ów jest Splunk Security Essentials (SSE).

SSE jest aplikacją udostępniającą bibliotekę gotowych scenariuszy detekcyjnych, powiązanych z technikami MITRE ATT&CK. Poszczególne treści zawierają informacje o wymaganych źródłach danych, poziomie złożoności wdrożenia oraz zależnościach względem dodatkowych mechanizmów, takich jak threat intelligence. Z tego względu SSE może pełnić funkcję narzędzia wspierającego planowanie rozwoju zdolności detekcyjnych, identyfikację luk oraz porządkowanie priorytetów wdrożeniowych.

W samym Splunk ES correlation searches i powiązane z nimi zdarzenia mogą być mapowane do taktyk i technik ATT&CK. Dzięki temu organizacja uzyskuje możliwość oceny pokrycia z perspektywy uznanego modelu referencyjnego, a także lepszego komunikowania poziomu dojrzałości detekcyjnej wobec interesariuszy biznesowych, zespołów red team, procesów threat huntingowych oraz audytu.

Dla bardziej dojrzałych zespołów istotną wartość przedstawia również ES Content Update (ESCU), czyli utrzymywana przez producenta biblioteka detekcji i treści bezpieczeństwa, rozwijana w oparciu o aktualne ustalenia badawcze i obserwacje dotyczące nowych technik ataków. ESCU nie zastępuje własnej inżynierii detekcji, ale może znacząco przyspieszyć jej rozwój.

Integracja z MITRE ATT&CK ma znaczenie nie tylko porządkujące, lecz również zarządcze. Pozwala bowiem przedstawiać stan pokrycia detekcyjnego w jednolitym standardzie, wskazywać obszary wymagające rozwoju oraz lepiej uzasadniać priorytety inwestycyjne.

5. Tworzenie korelacji i dashboardów w środowisku Splunk

Jednym z kluczowych atutów platformy Splunk jest wysoki poziom elastyczności w zakresie budowy mechanizmów detekcyjnych i analitycznych. Reguły korelacyjne tworzone są z wykorzystaniem SPL (Search Processing Language), będącego językiem zapytań i przetwarzania danych platformy Splunk.

Correlation searches są podstawowym mechanizmem detekcji w Splunk ES. Ich zadaniem jest cykliczna analiza danych w poszukiwaniu wzorców odpowiadających określonym scenariuszom ryzyka. Skuteczna reguła korelacyjna powinna opierać się na danych znormalizowanych do CIM, wykorzystywać wydajne konstrukcje analityczne, takie jak tstats lub data models, oraz zawierać komplet informacji operacyjnych, w tym opis scenariusza, powiązanie z MITRE ATT&CK, kontekst ryzyka, zakres wymaganych źródeł danych i rekomendowany sposób dalszego postępowania.

Dashboardy stanowią istotny element pracy operacyjnej i zarządczej. Splunk ES dostarcza zestaw gotowych widoków analitycznych obejmujących obszary takie jak dostęp, tożsamość, endpoint, sieć, threat intelligence czy audyt. W praktyce dojrzałe organizacje rozwijają również dashboardy własne, projektowane z uwzględnieniem konkretnych ról organizacyjnych, takich jak analityk pierwszej linii, zespół threat huntingu, kierownictwo SOC czy funkcje compliance i zarządzania ryzykiem.

Szczególną kategorią są Glass Tables — interaktywne widoki prezentujące stan bezpieczeństwa w kontekście usług biznesowych lub komponentów architektury. Odpowiednio zaprojektowane widoki tego rodzaju wspierają komunikację z odbiorcami nietechnicznymi, umożliwiając prezentację poziomu ryzyka w odniesieniu do usług krytycznych, lokalizacji, obszarów biznesowych lub elementów architektury.

Należy jednak podkreślić, że elastyczność platformy Splunk wymaga dyscypliny inżynieryjnej. Nieoptymalnie zaprojektowane zapytania mogą istotnie obciążać środowisko i ograniczać jego wydajność operacyjną. W praktyce dojrzałe wdrożenia obejmują formalny proces przeglądu i optymalizacji SPL, który należy traktować nie jako dodatkowe obciążenie administracyjne, lecz jako element niezbędny do zachowania jakości i stabilności platformy.

6. Splunk SOAR jako element automatyzacji reakcji

W środowiskach o większej skali operacyjnej sama zdolność do detekcji nie jest wystarczająca. Wraz ze wzrostem liczby źródeł danych, zdarzeń i scenariuszy analitycznych konieczne staje się wdrożenie mechanizmów automatyzacji reakcji. Tę funkcję pełni Splunk SOAR.

Splunk SOAR, wcześniej rozwijany pod nazwą Phantom, jest odrębną platformą służącą do orkiestracji i automatyzacji działań operacyjnych. Integruje się ze Splunk ES za pośrednictwem Adaptive Response Framework, umożliwiając płynne przejście od detekcji do reakcji.

Podstawą działania Splunk SOAR są playbooki (scenariusze automatyzacji), czyli zdefiniowane sekwencje działań uruchamianych w odpowiedzi na określone zdarzenia lub klasy incydentów. Mogą one obejmować zarówno proste czynności związane z enrichmentem i wzbogacaniem kontekstu analitycznego, jak i bardziej złożone scenariusze wymagające komunikacji z wieloma systemami, akceptacji użytkowników lub wykonania działań ochronnych.

Z operacyjnego punktu widzenia Splunk SOAR pełni trzy podstawowe funkcje. Po pierwsze, ogranicza nakład pracy manualnej związanej z wykonywaniem rutynowych czynności. Po drugie, zwiększa powtarzalność i standaryzację procesu reagowania. Po trzecie, umożliwia skuteczniejsze łączenie procesów bezpieczeństwa z innymi obszarami organizacji, takimi jak IT, zarządzanie tożsamością, infrastruktura chmurowa czy zgodność regulacyjna.

Należy jednak zaznaczyć, że wdrożenie Splunk SOAR powinno być traktowane jako odrębny program organizacyjno-techniczny. Wymaga ono opisanych procesów reagowania, odpowiednio dobranych integracji oraz modelu utrzymania i rozwoju playbooków. W przeciwnym razie potencjał automatyzacji pozostaje niewykorzystany.

7. Model licencjonowania i sizing środowiska

Właściwe zrozumienie modelu licencjonowania oraz poprawny sizing środowiska mają kluczowe znaczenie dla ekonomiki wdrożenia. W praktyce najczęściej spotykane są trzy zasadnicze podejścia do licencjonowania.

Ingest Pricing opiera się na wolumenie indeksowanych danych. Jest to model prosty i relatywnie łatwy do prognozowania, pod warunkiem że środowisko charakteryzuje się stabilnym profilem ingestii. Wymaga jednak świadomego zarządzania zakresem podłączanych źródeł danych oraz eliminowania telemetrii o niskiej wartości analitycznej.

Workload-based pricing, wykorzystywany między innymi w modelach opartych o Splunk Virtual Compute (SVC), uzależnia koszt od wykorzystania zasobów obliczeniowych. Model ten może być korzystny w środowiskach, w których relacja pomiędzy wolumenem danych a intensywnością ich analizy odbiega od klasycznego modelu ingestowego.

W wybranych modelach komercyjnych spotykane są również warianty licencjonowania oparte na liczbie encji, użytkowników lub elastycznych modelach konsumpcyjnych.

Niezależnie od wybranego modelu, sizing środowiska powinien uwzględniać dzienny wolumen ingestii, charakter i liczbę źródeł danych, okresy retencji, liczbę użytkowników, profil obciążenia analitycznego oraz wymagania w zakresie wysokiej dostępności. Choć producent udostępnia referencyjne architektury dla różnych skal wdrożenia, doświadczenie pokazuje, że rzeczywiste parametry środowiska wymagają weryfikacji po uruchomieniu produkcyjnym.

Z perspektywy zakupowej należy również pamiętać, że Splunk Enterprise Security jest rozszerzeniem wymagającym bazowej licencji Splunk Enterprise, a w ofertach chmurowych zakres poszczególnych komponentów może być ujmowany w różny sposób. W praktyce porównanie ofert wymaga precyzyjnego rozdzielenia kosztów platformy bazowej, warstwy ES oraz ewentualnych komponentów automatyzacji, takich jak Splunk SOAR.

8. Profil organizacji i typowe scenariusze zastosowania

Splunk Enterprise Security jest rozwiązaniem najlepiej odpowiadającym potrzebom organizacji, które oczekują wysokiej elastyczności, szerokich możliwości integracyjnych oraz zaawansowanych funkcji analitycznych, a jednocześnie dysponują zasobami pozwalającymi na rozwój kompetencji i procesów operacyjnych.

Szczególnie istotne korzyści z wdrożenia Splunk ES obserwuje się w organizacjach, które:

• przetwarzają duże lub zmienne wolumeny danych,
• funkcjonują w środowiskach hybrydowych, wielochmurowych lub obejmujących złożone architektury infrastrukturalne,
• rozwijają własne mechanizmy detekcji,
• wykorzystują te same dane w wielu obszarach działalności,
• wymagają integracji z niestandardowymi źródłami oraz aplikacjami.

Do najczęściej wskazywanych scenariuszy zastosowania należą: detekcja ataków wieloetapowych, monitorowanie aktywności uprzywilejowanej, wykrywanie eksfiltracji danych, nadzór nad środowiskami chmurowymi, wsparcie procesów compliance, threat hunting oraz współpraca z zespołami threat intelligence i red team.

W przypadku organizacji o ograniczonych zasobach wewnętrznych zasadne może być rozważenie modelu współzarządzanego lub usługowego, opartego na współpracy z partnerem posiadającym doświadczenie w projektowaniu i utrzymaniu środowisk Splunk. Tego rodzaju podejście może skrócić czas osiągnięcia dojrzałości operacyjnej oraz ograniczyć ryzyko błędów wdrożeniowych.

Podsumowanie

Splunk Enterprise Security jest rozwiązaniem przeznaczonym dla organizacji, które postrzegają SIEM nie jako zamknięte narzędzie, lecz jako platformę operacyjną wspierającą realizację procesów bezpieczeństwa. Jego wartość ujawnia się przede wszystkim tam, gdzie wdrożeniu towarzyszy właściwie zaprojektowana architektura, przemyślany model operacyjny, dojrzałe procesy oraz kompetentny zespół odpowiedzialny za rozwój i utrzymanie środowiska.

Z tego względu ocena zasadności wdrożenia Splunk ES nie powinna ograniczać się do analizy listy funkcji. Znacznie większe znaczenie ma określenie rzeczywistych potrzeb organizacji, jakości dostępnych danych, dojrzałości zespołu oraz priorytetowych scenariuszy użycia. Dopiero w takim ujęciu możliwa jest rzetelna ocena, czy i w jakim zakresie Splunk Enterprise Security będzie właściwym rozwiązaniem dla operacji SOC.

---

Aleksander Bronowski – GTM Manager z ponad sześcioletnim doświadczeniem w doradztwie transakcyjnym i technologicznym. Na co dzień wspiera klientów w doborze i projektowaniu rozwiązań z obszaru cyberbezpieczeństwa. Specjalizuje się w obszarze zarządzania incydentami, podatnościami i ryzykiem, a także NIS 2.