System SIEM i centralna analiza zdarzeń
Systemy sieciowe, serwery, aplikacje i urządzenia końcowe generują logi dotyczące uwierzytelniania, zmian konfiguracji, połączeń i błędów. Każde źródło opisuje zdarzenia w swoim formacie, z inną szczegółowością i zegarem. Logi są materiałem do wykrywania incydentów, analizy operacyjnej i późniejszej rekonstrukcji zdarzeń.
Pojedynczy log rzadko opisuje pełny łańcuch ataku. Przykładowo wiadomość e-mail może zostać zarejestrowana przez bramę pocztową, połączenie z adresem URL przez proxy, a nieudane logowania przez serwer. Korelacja zdarzeń z wielu źródeł pozwala analitykowi zbudować jedną oś czasu i ocenić, czy pozornie rozdzielne zdarzenia dotyczą tego samego konta lub hosta.
System zbiera logi, normalizuje je, wzbogaca o kontekst i stosuje reguły korelacji. System może wspierać analizę w czasie zbliżonym do rzeczywistego, wyszukiwanie historyczne, raportowanie i obsługę incydentów. Zakres zależy od źródeł, jakości danych, retencji oraz reguł wdrożonych przez organizację.
Wartość analizy zależy od kompletności źródeł, synchronizacji zegarów i ochrony logów przed usunięciem lub zmianą. Transport, kolektor i magazyn powinny mieć określone uprawnienia, retencję oraz kontrolę integralności. Brak logu nie oznacza braku zdarzenia, dlatego pokrycie i stan źródeł trzeba monitorować.
Syslog jest jednym z możliwych formatów i sposobów transportu. Przekaźnik lub kolektor może przekazywać komunikaty do magazynu, a właściwości dostarczenia i integralności zależą od wybranego transportu oraz implementacji. Monitoring powinien wykrywać luki, wzrost kolejki i awarie źródeł.
SIM i SEM w historii SIEM
Nazwa SIEM wywodzi się z połączenia dwóch wcześniejszych obszarów. Współczesne produkty często udostępniają je w jednym systemie, lecz zakres funkcji zależy od implementacji:
1. Zarządzanie informacjami o bezpieczeństwie (SIM)
SIM obejmuje długoterminowe zbieranie, przechowywanie, wyszukiwanie i analizę logów. Organizacja ustala źródła, retencję, format, kontrolę dostępu oraz sposób ochrony archiwum. NIST SP 800-92 opisuje log jako zapis zdarzenia i log management jako generowanie, przesyłanie, przechowywanie, uzyskiwanie dostępu do danych logów oraz ich usuwanie.
SIM wspiera analizę historyczną i audyt. Przykładowe zapytanie brzmi: "Pokaż wszystkie połączenia sieciowe z komputera tego użytkownika w ciągu ostatnich sześciu miesięcy." Okres przechowywania wynika z potrzeb operacyjnych, oceny ryzyka, RODO, PCI DSS oraz innych wymagań właściwych dla organizacji. Sam produkt SIEM nie ustala retencji bez odpowiedniej polityki i konfiguracji.
Polityka retencji powinna określać klasy danych, magazyn podstawowy i archiwalny, uprawnienia wyszukiwania oraz sposób usuwania. Incydent może wymagać wstrzymania usuwania wybranych danych i zachowania informacji związanych ze sprawą. Dostęp do archiwum powinien być rejestrowany.
2. Zarządzanie zdarzeniami bezpieczeństwa (SEM)
SEM koncentruje się na zdarzeniach napływających, regułach korelacji i alertach. System może wykrywać zmiany konfiguracji, nietypowe logowania, eskalację uprawnień lub sekwencję zdarzeń z wielu źródeł. Opóźnienie zależy od źródła, transportu, przetwarzania i reguły.
Przykładowe pytania SEM to: "Czy na głównym serwerze trwa seria nieudanych prób logowania?" oraz "Czy stacja z alertem ochrony punktu końcowego rozpoczęła połączenie z podejrzanym adresem IP?". Alert rozpoczyna analizę i może uruchomić procedurę reagowania.
SIEM może łączyć retencję logów z korelacją zdarzeń i alertowaniem. Organizacja uzyskuje wtedy jedno miejsce wyszukiwania danych historycznych oraz reguł analizy bieżących zdarzeń, przy zachowaniu odrębnych wymagań retencji i uprawnień.
Potok przetwarzania SIEM
Przetwarzanie SIEM obejmuje zbieranie, normalizację, wzbogacanie, korelację oraz obsługę alertów i raportów. Kolejność i zakres etapów zależą od produktu oraz konfiguracji.
Etap 1: zbieranie danych
SIEM zbiera dane ze źródeł dobranych do celów monitorowania i ryzyka. Zakres logów powinien obejmować zdarzenia potrzebne do wykrywania, analizy i odtwarzania incydentów:
- Urządzenia sieciowe: Zapory sieciowe, routery, przełączniki i bezprzewodowe punkty dostępowe.
- Urządzenia zabezpieczające: Systemy Zapobiegania Włamaniom (IPS), bramy VPN, zapory aplikacji internetowych (WAF) i serwery proxy.
- Serwery: Dzienniki zdarzeń Windows, pliki syslog systemu Linux oraz logi baz danych, na przykład Microsoft SQL Server, i serwerów WWW, na przykład Apache.
- Punkty końcowe: Oprogramowanie antywirusowe i EDR, czyli wykrywanie i reagowanie na punktach końcowych, na laptopach i komputerach stacjonarnych.
- Aplikacje: Logi z aplikacji biznesowych, usług komercyjnych oraz systemów ERP i CRM, na przykład Salesforce lub SAP.
- Systemy zarządzania tożsamością i dostępem: Microsoft Active Directory, RADIUS i inne serwery uwierzytelniające.
- Usługi chmurowe: Logi z platform Amazon Web Services (AWS), Microsoft Azure i Google Cloud.
Etap 2: normalizacja i wzbogacanie
Źródła używają różnych formatów i nazw pól. Log z zapory Cisco może mieć inną strukturę niż log serwera Windows. Parser odczytuje wiadomość, rozdziela pola i mapuje je na wspólny model danych. Ten proces nazywa się normalizacją lub parsowaniem.
Kolektor powinien zachować czas źródłowy, czas przyjęcia oraz identyfikator źródła. Synchronizacja przez usługę czasu ogranicza błędy w osi czasu, lecz opóźnienia transportu nadal wymagają uwzględnienia w regułach. Błędy parsowania i odrzucone komunikaty powinny trafiać do osobnego monitorowania.
Parser SIEM mapuje surową wiadomość na pola, takie jak 'zrodlowy_ip', 'docelowy_ip', 'uzytkownik' i 'akcja_zdarzenia'. Po normalizacji system może dodać kontekst, na przykład dane geograficzne, właściciela adresu lub wynik analizy zagrożeń. Wartość może służyć jako przykład adresu wzbogaconego przykładowymi polami 'Kraj: USA', 'Właściciel: Google LLC' i 'Analityka zagrożeń: nieszkodliwy'. Są to wartości zależne od źródła wzbogacenia, a sam adres nie potwierdza oceny zagrożenia.
Etap 3: silnik korelacji
Silnik korelacji stosuje reguły do znormalizowanych i wzbogaconych zdarzeń. Reguła może łączyć konto, host, adres, czas, typ operacji i informacje o zagrożeniach, aby wykryć sekwencję obejmującą wiele systemów.
Analityk może zdefiniować przykładową regułę korelacyjną:
"ZAALERTUJ z wysokim priorytetem, JEŚLI (użytkownik otrzyma wiadomość phishingową) ORAZ (jego maszyna połączy się ze znanym złośliwym adresem URL w ciągu 5 minut), A NASTĘPNIE (jego konto odnotuje 10 nieudanych prób logowania na serwerze finansowym w ciągu kolejnych 10 minut)."
Brama pocztowa, proxy i serwer rejestrują odrębne zdarzenia. SIEM może połączyć je po identyfikatorze użytkownika, hoście i oknie czasowym, a następnie wygenerować jeden alert z kontekstem. Ten sam typ korelacji mogą realizować także inne narzędzia analizy logów, zależnie od konfiguracji.
Etap 4: analiza, raportowanie i alertowanie
Po uruchomieniu reguły SIEM generuje alert dla zespołu centrum operacji bezpieczeństwa (SOC) i może utworzyć sprawę lub incydent. Analitycy przeglądają surowe logi, dane o przepływach, oś czasu i kontekst wzbogacenia za pomocą wyszukiwania oraz pulpitów analitycznych.
SIEM może generować raporty dla zarządu, na przykład tygodniowe podsumowania zdarzeń, oraz dla audytorów, na przykład kwartalne zestawienia dostępu do danych objętych wymaganiami.
Zastosowania SIEM
SIEM wspiera widoczność, analizę incydentów, raportowanie i korelację zdarzeń. Zakres korzyści zależy od pokrycia źródeł, jakości logów, retencji i dostrojenia reguł.
Przed wdrożeniem organizacja powinna określić przypadki użycia, właścicieli alertów, czasy obsługi oraz wymagane dowody. Metryki mogą obejmować dostępność źródeł, odsetek komunikatów przetworzonych, liczbę alertów i czas od wykrycia do analizy.
- Scentralizowana widoczność: Jeden interfejs może udostępniać logi z urządzeń sieciowych, serwerów, aplikacji, punktów końcowych, tożsamości i usług chmurowych.
- Wykrywanie zagrożeń i reagowanie: Korelacja zdarzeń może skrócić analizę złożonych sekwencji i przekazać alert do SOC. Czas reakcji zależy od pokrycia źródeł, reguł i obsady zespołu.
- Analiza powłamaniowa: Scentralizowane archiwum logów pomaga odtworzyć oś czasu i zakres incydentu, jeśli dane zachowano z odpowiednią retencją i integralnością.
- Raportowanie zgodności: SIEM może tworzyć raporty i ślady audytowe dotyczące RODO, PCI DSS oraz innych wymagań. Raport jest dowodem działania procesu, którego skuteczność trzeba ocenić osobno.
- Ograniczenie liczby alertów: Korelacja może łączyć alerty niskiego poziomu w sprawę z kontekstem. Reguły wymagają dostrojenia, aby nie ukryć ważnych zdarzeń w nadmiarze danych.
Ograniczenia wdrożenia SIEM
Wdrożenie SIEM wymaga planowania źródeł, retencji, uprawnień, reguł detekcji i obsady analitycznej. Sam produkt nie zastępuje tych procesów.
- Złożoność i koszty: Platforma wymaga integracji źródeł, przestrzeni retencyjnej, uprawnień i utrzymania reguł. Koszt zależy między innymi od liczby źródeł, wolumenu logów i czasu przechowywania.
- Potrzeba dostrajania: Reguły ogólne mogą generować fałszywe alarmy. Dostrajanie obejmuje reguły korelacyjne dopasowane do środowiska i profilu ryzyka oraz wyjątki dla znanych, nieszkodliwych działań.
- Analiza ludzka: Analitycy tworzą reguły, badają alerty, oceniają kontekst i aktualizują procedury. SIEM dostarcza dane oraz automatyzację, lecz decyzja o klasyfikacji i reakcji wymaga odpowiedzialności zespołu.
Ochrona magazynu logów obejmuje kontrolę dostępu, kopie zapasowe, ograniczenie usuwania oraz sprawdzenie integralności. Plan powinien wskazywać, które źródła są krytyczne i jak postępować podczas niedostępności kolektora lub magazynu.
Procedury powinny określać eskalację, zastępstwo i sposób dokumentowania decyzji analityka. Przegląd zamkniętych spraw może wskazać brakujące dane, nieskuteczne reguły i potrzeby uzupełnienia źródeł.
Każda reguła korelacji powinna mieć właściciela, dane testowe, historię zmian i opis reakcji. Okresowy przegląd sprawdza, czy założenia dotyczące kont, hostów, adresów i okien czasowych nadal odpowiadają środowisku.