użycie SIEM

Użycie SIEM pozwala centralnie analizować zdarzenia bezpieczeństwa z wielu źródeł, w tym infrastruktury pocztowej.

Użycie SIEM jako centralnego punktu analizy zdarzeń

SIEM, czyli Security Information and Event Management, służy do zbierania, normalizowania, wyszukiwania i korelowania zdarzeń pochodzących z wielu systemów. Zamiast analizować osobno logi zapory sieciowej, stacji roboczych, serwerów, urządzeń sieciowych i infrastruktury pocztowej, operator otrzymuje wspólny widok zdarzeń bezpieczeństwa. Do systemu SIEM mogą trafiać między innymi informacje o udanych i nieudanych logowaniach, zmianach uprawnień, uruchamianiu procesów, połączeniach sieciowych, odrzuceniach wiadomości oraz wykryciach złośliwych załączników.

Podstawą działania jest kolektor lub agent odbierający dane z określonego źródła. W zależności od produktu i konfiguracji mogą być używane mechanizmy takie jak syslog, pliki logów, interfejs API, agent systemowy albo komunikaty przesyłane przez brokera zdarzeń. Po odebraniu wpisy są zwykle wzbogacane o informacje o źródle, czasie, użytkowniku, adresie IP, urządzeniu i rodzaju zdarzenia. Następnie dane są zapisywane w repozytorium umożliwiającym wyszukiwanie oraz dalszą korelację.

Normalizacja logów z poczty i innych źródeł

Infrastruktura pocztowa dostarcza zdarzeń o innej strukturze niż system operacyjny lub zapora sieciowa. Log pocztowy może zawierać adres nadawcy, odbiorcy, identyfikator wiadomości, wynik uwierzytelnienia SMTP, kod odpowiedzi, nazwę hosta, adres IP oraz informacje o skanowaniu treści. System SIEM musi rozpoznać te pola i przypisać je do wspólnego modelu danych. Dzięki temu możliwe jest porównanie zdarzenia z poczty z logowaniem do konta, zapytaniem DNS albo ruchem sieciowym.

Przykładem korelacji jest wykrywanie nietypowej aktywności konta. Pojedyncze nieudane logowanie może być zwykłą pomyłką użytkownika. Jeżeli jednak w krótkim przedziale czasu pojawia się wiele nieudanych prób z różnych adresów IP, a następnie udane uwierzytelnienie i wysłanie dużej liczby wiadomości, reguła SIEM może połączyć te zdarzenia w jeden incydent. Znaczenie takiej korelacji zależy od poprawnego mapowania użytkownika, spójnych znaczników czasu oraz wiarygodnych danych o adresach źródłowych.

Korelacja zdarzeń, reguły i ocena alarmów

Reguły korelacyjne określają, jakie zdarzenia mają zostać połączone i jaki warunek powinien spowodować utworzenie alarmu. Reguła może uwzględniać kolejność zdarzeń, ich liczbę, przedział czasowy, typ urządzenia, konto, adres sieciowy albo poziom ryzyka przypisany do źródła. SIEM może także tworzyć alarm na podstawie list reputacyjnych, znanych wskaźników kompromitacji lub nietypowego zachowania względem wcześniejszej aktywności.

Alarm nie jest automatycznie dowodem skutecznego ataku. Wymaga sprawdzenia kontekstu: czy adres IP należy do użytkownika, czy logowanie było związane z zaplanowaną pracą, czy wiadomość została odrzucona przez filtr oraz czy na danej stacji wystąpiły dodatkowe objawy. Ważna jest również synchronizacja czasu. Różnica kilku minut między zegarem serwera pocztowego, kontrolera domeny i urządzenia sieciowego może zmienić kolejność zdarzeń, utrudnić rekonstrukcję incydentu i prowadzić do błędnej interpretacji reguły korelacyjnej.

W praktyce konieczne jest dostrajanie reguł. Zbyt ogólne warunki generują dużą liczbę alarmów niskiej wartości, natomiast zbyt restrykcyjne mogą pominąć nietypowe zachowanie. Przydatne są grupowanie powtarzalnych zdarzeń, wykluczenia dla znanych procesów administracyjnych, oznaczanie krytycznych zasobów oraz rozdzielenie alarmów informacyjnych od tych, które wymagają natychmiastowej analizy. Każde wykluczenie powinno mieć uzasadnienie i okresowy przegląd, ponieważ nieaktualna reguła może ukrywać realne zdarzenia.

Wymagania techniczne i diagnostyka działania SIEM

Ocena poprawnego działania SIEM obejmuje nie tylko sam interfejs alarmów. Należy sprawdzić, czy wszystkie oczekiwane źródła faktycznie wysyłają dane, czy kolektory nie odrzucają komunikatów, czy parsery prawidłowo rozpoznają pola oraz czy repozytorium zachowuje zdarzenia przez wymagany okres konfiguracji. Istotne są także opóźnienia ingestu, obciążenie procesora i pamięci, zajętość przestrzeni dyskowej oraz status certyfikatów lub połączeń szyfrowanych używanych przez konektory.

Diagnostyka może rozpocząć się od porównania zdarzeń widocznych bezpośrednio na urządzeniu źródłowym z tymi, które pojawiły się w SIEM. Jeżeli wpis istnieje w systemie pocztowym, ale nie ma go w repozytorium SIEM, przyczyną może być przerwane połączenie, filtr kolektora, błędny format komunikatu, przepełnienie bufora albo nieprawidłowe uprawnienia. Jeżeli zdarzenie jest zapisane, lecz nie uruchamia reguły, należy sprawdzić mapowanie pól, strefę czasową, warunki korelacji i aktualność parsera. Naprawa takiego problemu może wymagać odtworzenia konfiguracji źródła, korekty routingu logów, ponownego skonfigurowania agenta lub usunięcia błędów w samej regule.

Przy diagnostyce komputera, na którym działa konsola SIEM albo agent zbierający zdarzenia, analizuje się również dostępność sieci, stan usług, błędy systemowe, certyfikaty, zaporę lokalną i wolne miejsce na dysku. Nie należy usuwać logów ani wyłączać kolektora bez ustalenia wpływu takiej czynności na ciągłość rejestrowania zdarzeń. Prawidłowa analiza powinna zakończyć się wskazaniem źródła problemu, zakresu utraconych lub opóźnionych danych oraz sposobu potwierdzenia, że kolejne zdarzenia są już odbierane i poprawnie przetwarzane.