analiza zdarzeń SIEM

Analiza zdarzeń SIEM to badanie danych zgromadzonych przez system zarządzania informacjami i zdarzeniami bezpieczeństwa.

Zakres danych analizowanych przez SIEM

Analiza zdarzeń SIEM polega na uporządkowanym badaniu informacji rejestrowanych przez różne elementy infrastruktury informatycznej. Do systemu mogą trafiać logi z systemów operacyjnych, urządzeń sieciowych, zapór sieciowych, serwerów aplikacyjnych, usług katalogowych, baz danych, narzędzi antywirusowych oraz platform chmurowych. Pojedynczy wpis opisuje zwykle określone zdarzenie, na przykład udane logowanie, odrzuconą próbę dostępu, uruchomienie procesu, zmianę uprawnień, modyfikację pliku albo nawiązanie połączenia sieciowego.

Surowe logi pochodzące z różnych źródeł mają odmienne formaty i nazwy pól. SIEM normalizuje je, czyli sprowadza do wspólnego modelu zawierającego między innymi czas zdarzenia, adres źródłowy, adres docelowy, nazwę użytkownika, typ działania, wynik operacji i identyfikator urządzenia. Ważne jest także ujednolicenie stref czasowych oraz sprawdzenie synchronizacji zegarów. Bez poprawnych znaczników czasu kolejność zdarzeń może zostać ustalona błędnie, co utrudnia odtworzenie przebiegu incydentu.

Korelacja zdarzeń i rozpoznawanie wzorców

Największa wartość analizy SIEM wynika z łączenia wielu pozornie niezależnych wpisów. Jedno nieudane logowanie nie musi oznaczać zagrożenia, ale seria takich prób z jednego adresu, a następnie udane logowanie i dostęp do nietypowych zasobów tworzą wzorzec wymagający sprawdzenia. Reguła korelacyjna może łączyć zdarzenia na podstawie czasu, użytkownika, adresu IP, identyfikatora hosta lub rodzaju wykonanej operacji. System może wtedy utworzyć pojedyncze zdarzenie alarmowe zamiast prezentować operatorowi dużą liczbę rozproszonych logów.

Analiza obejmuje również porównanie zachowania z ustalonymi wartościami bazowymi. Nietypowe może być logowanie użytkownika o porze, w której wcześniej nie pracował, nagłe użycie konta uprzywilejowanego, zmiana konfiguracji zabezpieczeń albo transfer dużej liczby danych. Takie odstępstwo nie jest automatycznie dowodem ataku. Może wynikać z prac administracyjnych, zmiany urządzenia lub błędnej konfiguracji. Dlatego alarm powinien być oceniany razem z kontekstem: właścicielem konta, rolą urządzenia, planowanymi pracami i historią podobnych operacji.

Od alarmu do rekonstrukcji incydentu

Po wykryciu podejrzanego wzorca analityk przegląda zdarzenia poprzedzające i następujące po alarmie. Celem jest ustalenie punktu początkowego, zakresu działań oraz możliwych skutków. Przydatne może być zestawienie czasu pierwszego logowania, uruchomionych procesów, zmian uprawnień, połączeń z innymi hostami i prób uzyskania dostępu do plików. Istotne jest rozróżnienie czasu zapisania logu od czasu wystąpienia operacji, ponieważ niektóre źródła przekazują wpisy z opóźnieniem.

Wynik analizy powinien zawierać konkretne wskaźniki i ustalenia, a nie tylko ogólną ocenę typu „aktywność podejrzana”. Wskaźnikiem może być adres IP, nazwa hosta, identyfikator procesu, skrót pliku, nazwa konta, domena lub charakterystyczny ciąg w komunikacie. Trzeba jednak zweryfikować wiarygodność każdego pola. Adres źródłowy może należeć do serwera pośredniczącego, nazwa użytkownika może być używana przez usługę, a skrót pliku może zmienić się po legalnej aktualizacji. Analiza SIEM wspiera ustalenia, lecz nie zastępuje sprawdzenia systemu źródłowego i zapisów konfiguracyjnych.

Jakość logów, retencja i ograniczenia wnioskowania

Poprawne wnioski zależą od kompletności danych. Brak logów z określonego hosta, wyłączone audytowanie, zbyt krótki okres przechowywania albo utrata komunikatów podczas przeciążenia mogą stworzyć fałszywy obraz sytuacji. Należy kontrolować stan źródeł, opóźnienia przesyłania, odrzucane komunikaty i błędy parserów. Warto również ograniczać powielanie tego samego zdarzenia przez kilka warstw infrastruktury, ponieważ duplikaty zwiększają liczbę alarmów i utrudniają ocenę częstotliwości zdarzeń.

Analiza powinna uwzględniać zarówno czułość reguł, jak i liczbę fałszywych alarmów. Reguła zbyt ogólna będzie generowała sygnały przy każdej zwykłej czynności, natomiast reguła zbyt wąska może pominąć wariant tego samego ataku. Praktyczne podejście obejmuje dokumentowanie założeń, okresowe przeglądy reguł, testowanie przykładowych scenariuszy oraz oznaczanie zdarzeń potwierdzonych i odrzuconych. Samo pojawienie się alertu nie dowodzi incydentu; dowód powstaje dopiero po powiązaniu danych z kilku źródeł, sprawdzeniu ich chronologii i potwierdzeniu, że obserwowane działania są rzeczywiście nieautoryzowane.