system SIEM

System SIEM centralnie analizuje zdarzenia bezpieczeństwa z wielu źródeł, w tym infrastruktury pocztowej.

Centralizacja zdarzeń bezpieczeństwa w systemie SIEM

System SIEM, czyli Security Information and Event Management, służy do gromadzenia, normalizowania, przechowywania i analizowania zdarzeń związanych z bezpieczeństwem. Zdarzeniem może być między innymi udane lub nieudane logowanie, zmiana uprawnień, uruchomienie procesu, modyfikacja reguły zapory, wykrycie złośliwego pliku albo odrzucenie wiadomości przez filtr antyspamowy. System nie ogranicza się do jednego komputera. Pobiera dane z wielu źródeł, takich jak stacje robocze, serwery, zapory sieciowe, urządzenia VPN, katalogi użytkowników, systemy antywirusowe, usługi chmurowe oraz infrastruktura pocztowa.

W przypadku poczty elektronicznej SIEM może otrzymywać informacje o logowaniach do skrzynek, zmianach haseł, próbach użycia nieistniejących kont, wysyłaniu dużej liczby wiadomości, odrzuceniach przez mechanizmy antyspamowe oraz wynikach kontroli SPF, DKIM i DMARC. Zwykle nie analizuje samej treści każdej wiadomości jako podstawowego źródła danych, lecz wykorzystuje metadane, nagłówki, identyfikatory wiadomości, adresy IP, nazwy kont i decyzje podjęte przez system pocztowy. Pozwala to połączyć zdarzenie pocztowe z aktywnością użytkownika, urządzenia lub adresu sieciowego.

Droga danych od urządzenia do reguły korelacyjnej

Dane trafiają do SIEM za pośrednictwem agentów instalowanych na systemach operacyjnych, kolektorów logów, integracji API albo standardowych mechanizmów przekazywania komunikatów. W środowiskach sieciowych często stosuje się syslog, natomiast systemy Windows mogą przekazywać zdarzenia z dziennika zdarzeń za pomocą wyspecjalizowanych konektorów. Integracja z usługą pocztową może korzystać z API dostawcy, eksportu logów lub centralnego systemu pośredniczącego. Sam sposób zbierania zależy od konkretnej platformy, dlatego konfiguracja musi uwzględniać format, częstotliwość, uwierzytelnianie i zakres dostępnych pól.

Po odebraniu komunikatu SIEM zazwyczaj rozpoznaje jego typ, wydobywa pola i zapisuje zdarzenie w ujednoliconym modelu. Istotne są między innymi czas wystąpienia, źródłowy adres IP, konto użytkownika, nazwa hosta, aplikacja, rodzaj czynności i wynik operacji. Normalizacja nie zmienia faktu, że źródłowe logi mogą mieć różną dokładność i różne znaczenie. Jeśli zegary urządzeń są niesynchronizowane, kolejność zdarzeń może zostać ustalona błędnie. Z tego powodu w infrastrukturze wykorzystuje się synchronizację czasu, zwykle za pomocą NTP, oraz przechowuje informację o źródle i czasie odebrania komunikatu.

Reguły korelacyjne wyszukują zależności pomiędzy zdarzeniami, które pojedynczo nie muszą oznaczać ataku. Przykładem jest seria nieudanych logowań do skrzynki, po której następuje udane logowanie z innego kraju lub z adresu niewystępującego wcześniej dla danego konta. Inny scenariusz może łączyć pobranie załącznika przez pocztę, wykrycie procesu skryptowego na stacji roboczej oraz połączenie wychodzące do adresu wskazanego w bazie reputacyjnej. Reguła może uwzględniać czas, liczbę zdarzeń, tożsamość użytkownika, krytyczność zasobu i wcześniejszą historię aktywności.

Alerty, triage i analiza śladu incydentu

Wynikiem działania SIEM jest między innymi alert, czyli uporządkowana informacja o spełnieniu warunków określonych w regule lub modelu analitycznym. Alert powinien zawierać zdarzenia źródłowe, czas ich wystąpienia, objęte konto, urządzenie, adresy sieciowe oraz powód podniesienia priorytetu. Sam alert nie jest jeszcze dowodem skutecznego włamania. Może wskazywać na rzeczywisty incydent, błędną konfigurację, legalną aktywność administratora albo nietypowe zachowanie użytkownika.

Podczas weryfikacji analityk porównuje dane z kilku źródeł. Dla podejrzanego logowania do poczty sprawdza między innymi wcześniejsze logowania tego konta, adres IP urządzenia, informacje z kontrolera tożsamości, zdarzenia z punktu końcowego i aktywność po zalogowaniu. Warto rozdzielać czas zdarzenia od czasu jego odebrania przez SIEM, ponieważ opóźnienie transportu może wynikać z niedostępności konektora, buforowania albo chwilowego przeciążenia. Brak logu nie oznacza automatycznie braku zdarzenia, jeżeli źródło nie rejestrowało danej operacji lub integracja utraciła połączenie.

W praktyce jakość analizy zależy od kompletności telemetrii, poprawnego mapowania pól i kontrolowania liczby fałszywych alarmów. Reguła wykrywająca wiele nieudanych logowań może generować alerty podczas awarii usługi, testu automatycznego lub błędnie skonfigurowanego klienta pocztowego. Dlatego progi i wyjątki powinny być powiązane z rzeczywistym sposobem pracy organizacji, a każda zmiana reguły powinna mieć opis, właściciela i możliwość odtworzenia poprzedniej konfiguracji. Retencja logów musi natomiast odpowiadać wymaganiom analizy, aby zdarzenia poprzedzające alert nie zostały usunięte zbyt wcześnie.

SIEM jako element diagnostyki bezpieczeństwa infrastruktury

Nieprawidłowo działający system SIEM może powodować luki w obserwowalności, nawet gdy monitorowane urządzenia pracują poprawnie. Podczas diagnostyki sprawdza się stan agentów i kolektorów, opóźnienie dostarczania komunikatów, odsetek odrzuconych zdarzeń, błędy uwierzytelniania integracji oraz zajętość magazynu. Należy także porównać log źródłowy z rekordem widocznym w SIEM, aby wykryć utratę pól, błędne mapowanie użytkownika lub nieprawidłową interpretację czasu. Szczególnej uwagi wymagają wyłączone reguły, nieaktualne konektory i źródła, które przestały wysyłać dane bez wygenerowania alarmu o awarii.

Przy ocenie incydentu przydatne jest zachowanie pełnego łańcucha zdarzeń: od pierwszej próby dostępu, przez uwierzytelnienie i użycie poczty, aż po działania wykonane na powiązanym urządzeniu. Pozwala to odróżnić pojedynczy błąd logowania od sekwencji wskazującej na przejęcie konta lub zautomatyzowane skanowanie. SIEM nie zastępuje zapory, systemu antywirusowego, kopii zapasowych ani procedur reagowania. Jego rolą jest zebranie sygnałów, nadanie im wspólnego kontekstu i umożliwienie szybszego ustalenia, co wydarzyło się w infrastrukturze.

W środowisku lokalnym można rozpocząć ocenę od sprawdzenia, czy komputer poprawnie zapisuje lokalne zdarzenia, czy jego czas jest zgodny z pozostałymi urządzeniami i czy połączenie z kolektorem nie jest blokowane. Należy też zweryfikować, czy alert odnosi się do właściwego hosta i konta, ponieważ błędne przypisanie zasobu prowadzi do nietrafnych wniosków. Diagnostyka komputera powinna obejmować stan systemu, procesy, połączenia sieciowe i konfigurację oprogramowania zabezpieczającego, bez traktowania samego wpisu w SIEM jako samodzielnej diagnozy sprzętu lub systemu operacyjnego.