Narzędzia SIEM (Security Information and Event Management)

Po ponad dziesięcioletniej obecności na rynku platformy SIEM - do zarządzania informacją związaną z bezpieczeństwem i zdarzeniami - nadal potrzebują ulepszeń w raportach i mechanizmach korelacji.

Po ponad dziesięcioletniej obecności na rynku platformy SIEM - do zarządzania informacją związaną z bezpieczeństwem i zdarzeniami - nadal potrzebują ulepszeń w raportach i mechanizmach korelacji.

W większości działów IT personel w praktyce zagląda do logów okazyjnie, zazwyczaj po tym, gdy wydarzy się już coś niedobrego w sieci. Stałe monitorowanie logów rzadko jest praktykowane. Pomocne w monitorowaniu zdarzeń w trybie non stop może być wdrożenie platformy SIEM (Security Information and Event Management). Pomaga ona w uzyskiwaniu danych zawartych w rozproszonych logach i następnie gromadzeniu ich w jednym centralnym miejscu, gdzie mogą być monitorowane, raportowane oraz oczyszczane. Taka centralizacja zapewnia pełną wiedzę o bieżącej sytuacji, niezbędną do efektywnego zarządzania ryzykiem operacyjnym IT.

Na rynku funkcjonuje wielu producentów dostarczających tego typu rozwiązania. Niestety, żaden z nich nie zapewnia produktu w pełni dojrzałego. Przedstawiamy wyniki testów narzędzi SIEM dostarczonych przez firmy: Check Point, eIQ Networks, Q1 Labs, NetIQ i TriGeo. W testach nie wzięły udziału m.in. Cisco i RSA.

Testowane produkty wdrożono w środowisku produkcyjnym i poddano kilkumiesięcznym testom. W tym okresie można było zaobserwować zarówno dojrzałość pewnych mechanizmów w niektórych z tych narzędzi, jak i niedostatki innych. Interfejsy użytkownika okazały się nieco zawikłane, raporty niekompletne, odnotowywano także nadal występowanie problemów z analizą składniową danych z logów.

Najbardziej użyteczne okazały się produkty Q1 Labs i TriGeo. Najlepsze oceny uzyskał QRadar firmy Q1 Labs, chociaż jego interfejs użytkownika wymaga jeszcze dopracowania. Łącząc narzędzia zarządzania zdarzeniami NetIQ, dodając do tego integrację Splunk TriGeo oraz silnik korelacji Q1 Labs, można otrzymać w miarę dobry i kompletny produkt. Jednak dostępne na rynku wersje tych narzędzi nadal wymagają dopracowania.

Dla małego i średniego biznesu łatwość wdrażania i użytkowania, prosty system opłat i bogaty zestaw mechanizmów zawarty w TriGeo SIM mogą być wystarczające. Ponadto narzędzie ma dobry mechanizm kwerend.

NetIQ Security Manager będzie prawdopodobnie atrakcyjny dla większych organizacji, które już używają produktu NetIQ AppManager. Modularne podejście pozwala zarówno na skalowanie, jak i dostosowywanie wdrożeń. Narzędzie to jednak dosyć trudno się wdraża, a także jego model cenowy - opłata za serwer - powoduje, że im większe środowisko, tym więcej trzeba zapłacić.

SecureVue firmy eIQ zapewnia dobry zestaw mechanizmów dla średniego biznesu i zawiera komponenty wizualizacyjne, które są bardzo użyteczne, a ponadto oferuje bardzo pomocną funkcję zbierania informacji o konfiguracji urządzeń - do monitorowania i sterowania zmianami. Interfejs użytkownika, możliwości redukcji zdarzeń i mechanizmy raportowania mogą wymagać jednak pewnego nakładu pracy, a ponadto to narzędzie nie jest tanie.

Narzędzie Check Point bez wątpienia będzie atrakcyjne dla klientów tej firmy, ale brak mu pewnych mechanizmów, takich jak ocena zasobów i raporty, charakterystycznych dla bardziej dojrzałych rozwiązań.

Ewolucja trwa

Narzędzia platform SIEM nie są czymś zupełnie nowym w standardach IT. Podstawowa analiza składniowa logów i alarmy są stosowane już od kilku dekad, a pierwsze komercyjne produkty SIEM udostępnione przez NetForensics Intellitacts i eSecurity (obecnie Novell) pojawiły się na rynku w późnych latach 90. Niestety, prawie dziesięć lat później narzędzia te nadal nie są jeszcze w pełni dojrzałe.

Patrząc na historię tych rozwiązań, można zauważyć, że wiele z nich startowało z podstawowymi komponentami. Niektóre wyposażano w silniki raportów bez interfejsu użytkownika działającego w czasie rzeczywistym; inne taki interfejs miały, ale bez silnika redukcji zdarzeń. Do tej pory większość rozwiązań obsługuje jedynie zapory ogniowe i IDS, podczas gdy część koncentruje się na zdarzeniach związanych z systemem operacyjnym.

Obecnie narzędzia SIEM ewoluują w kierunku zapewnienia dodatkowych komponentów funkcjonalnych.

Komponenty te obejmują następujące mechanizmy: pozyskiwanie danych, przechowywanie danych i system archiwizacji, analizy składniowe zdarzeń i normalizacji oraz mechanizm raportowania, mechanizm kwerend, a także zazwyczaj pewien rodzaj modułu analizy w czasie rzeczywistym. Testy pokazały, że dojrzałość poszczególnych modułów w różnych produktach jest mocno zróżnicowana, a przyszły nabywca musi dobrze przemyśleć, jakie mechanizmy są najważniejsze dla jego organizacji.

W zakresie mechanizmu pozyskiwania danych wszystkie produkty zapewniają (jako minimum) nasłuch syslogu w celu odbioru zapisywanych w nim zdarzeń. Aczkolwiek dojrzałość takiego nasłuchu i towarzyszących mechanizmów, które wykonują analizę składniową wchodzącego strumienia zdarzeń, jest bardzo różna. I tak np. narzędzie NetIQ jest mało elastyczne w obsłudze zdarzeń Windows. Podczas testów ustawiano NetIQ na nasłuch urządzeń Cisco ASA na jednym z systemów, a na innym nasłuch Snort IDS na różnych systemach, ponieważ narzędzie nie obsługiwało strumieni danych z wielu typów urządzeń. Takie podejście jest bardzo niewygodne w sieci z tuzinami typów urządzeń opartych na syslogu. Producent zapowiedział usunięcie tej niedogodności w nowej wersji produktu, zapowiadanej jeszcze na ten rok.

Dla porównania, bardziej dojrzałe nasłuchy i parsery (analizatory składniowe) z Check Point i Q1 Labs pozwalają na proste wskazanie urządzenia (dowolnego urządzenia), a platforma SIEM automatycznie akceptuje dane wejściowe, identyfikuje format i określa: jakie zdarzenie występuje, z którego urządzenia pochodzi i jakiego jest typu.

Inne mechanizmy pozyskiwania danych w tych produktach obejmują wsparcie protokołów, takich jak OPSEC LEA (Check Point), mechanizm scrapingu bazy danych dla produktów określonych dostawców środków bezpieczeństwa, np. ISS czy McAfee, a także własnego agenta, który może pracować na hoście i przejmować dane o zdarzeniach nie rejestrowanych w syslog (m.in. pochodzące ze skanowania podatności i logów zdarzeń Windows). Produkty Q1 Labs i eIQ obsługują najszerszy asortyment urządzeń bezpieczeństwa i platformy wprost z pudełka.

Wszystkie testowane produkty SIEM oferują także mechanizm przechowywania danych. Większość zawiera relacyjną bazę danych ogólnego użytku, taką jak Microsoft Server czy Oracle, ale coraz popularniejsze staje się korzystanie z uproszczonej, własnej bazy danych dla dużych wolumenów zdarzeń. Argumentem przemawiającym za takim rozwiązaniem jest fakt, że nie wszystkie mechanizmy dostępnych relacyjnych baz danych są tu potrzebne, dlatego z punktu widzenia wydajności i wielkości kodu, celowe jest budowanie takiej bazy. Własną bazę danych wykorzystuje np. Q1 Labs, podczas gdy NetIQ korzysta z połączenia MS SQL i prostych plików. Prawdopodobnie zwycięży tendencja własnych rozwiązań w zakresie magazynu zdarzeń.

Czy SIEM i zarządzanie logami to to samo?

Wobec SIEM, podobnie jak w przypadku wielu produktów z branży IT, na rynku pojawia się wiele określeń ich funkcjonalności. I tak, pierwotna nazwa brzmiała SIM (Security Information Management), kolejny termin marketingowy to SEM (Security Event Management), i wreszcie najnowsze połączenie tych obu - SIEM. Jak to wszystko ma się do znanych od dawna procesów zarządzania logiem?

Podstawy zarządzania logiem nie są nowe. Systemy operacyjne, urządzenia i aplikacje generują pewne rodzaje logów, które zawierają specyficzne dla danego systemu zdarzenia i powiadamiania. Informacje w logach mogą być różne w sensie ich ogólnej przydatności, ale zanim ktoś wyciągnie z nich wartościową informację, to po pierwsze muszą być udostępnione, następnie przetransportowane i ewentualnie przechowane. I tu pojawia się pierwsze wyzwanie związane z zarządzaniem logiem: jak zbierać dane z rozproszonych systemów i gromadzić je w scentralizowanej lokalizacji? Istnieje wiele technik wykonania takiej centralizacji - od standaryzacji mechanizmów syslogów i wdrożenia centralnego serwera Syslog, po wykorzystanie komercyjnych produktów do przechwytywania zapisów logów oraz ich transportu i przechowywania. Inne problemy w zarządzaniu logiem obejmują wąskie gardła sieci, czyli zapewnienie niezawodnego transportu zdarzeń, ustawianie wymagań wobec szyfrowania i zarządzania pamięcią danych.

Pierwszym krokiem w tym procesie jest określenie, jakiego typu logi i informacje o zdarzeniach chce się zbierać, jak je transportować i gdzie zapamiętać. Gdy te kwestie są przesądzone, powstaje kolejny problem: co należy z tym zrobić? W tym punkcie kończy się bazowe zarządzanie logami i zaczynają się funkcje wyższego poziomu związane z SIEM.

Platformy SIEM zazwyczaj zapewniają wiele mechanizmów wymaganych przy zarządzaniu logami, ale dokładają do tego redukcję zdarzeń, alarmy i możliwość analizy w czasie rzeczywistym.


TOP 200