Podstawa

Trzonem każdego rozwiązania SIEM jest gromadzenie i korelacja informacji. W dzisiejszych czasach można powiedzieć, że jeśli to, co chcesz monitorować (system, aplikacja, urządzenie) udostępnia jakieś logi, to SIEM jest w stanie z nich skorzystać - do tego jeszcze wrócimy. Oczywiście sama obecność logów to tylko punkt wyjścia, ponieważ informacje takie mogą być zapisywane i przechowywane w bardzo zróżnicowanych formatach. Co więcej, ich odczyt przez komponent systemu SIEM może być również ograniczony do wybranego protokołu czy kanału dostępu. Elementami, które pozwalają na przekroczenie opisanych powyżej barier są różnego rodzaju oprogramowania agentowe pozwalające na czytanie danych źródłowych zdalnie i/lub lokalnie. Często wykorzystywane są jeszcze dodatkowe moduły lub wtyczki, tak jak kolektory, konektory, agregatory... Mnogość wykorzystywanych terminów może przytłaczać, jednak większość z nich pochodzi z konwencji nazewniczej danego producenta i tak naprawdę architektura większości dostępnych na rynku rozwiązań jest bardzo zbliżona. Wybór metody podłączenia systemów źródłowych, czyli oparcie implementacji SIEM na zdalnej lub lokalnej kolekcji zdarzeń, nie jest - wbrew pozorom - sprawą prostą. Niekiedy architektura systemu będącego źródłem danych wymaga lokalnej instalacji agenta, jako jedynej możliwej drogi dostępu do logów. Jednak wiele systemów, aplikacji lub urządzeń wręcz wymusza pobieranie zdarzeń przez zdalny komponent, gdyż charakterystyka ich platformy systemowej nie pozwala na instalację żadnego dodatkowego oprogramowania. W tym pierwszym przypadku z reguły agent odczytuje wskazany plik z logami, a następnie parsuje je i przekazuje dalej. W drugim logi przesyłane są poprzez sieć bezpośrednio. Do tego wykorzystywane są odpowiednie kanały komunikacyjne i interfejsy. Królem jest zdecydowanie SYSLOG - trudno znaleźć aplikację korporacyjną czy też zwłaszcza urządzenie sieciowe, które nie logują do sysloga. Ale nie zawsze należy z niego korzystać - wszystko zależy od źródła, a dokładniej od charakteru informacji, jakie mają być w ten sposób transmitowane.

Podajmy kilka przykładów:

• firewall Check Point - metoda pobrania danych OPSEC LEA (Log Export API)

• bazy danych - JDBC/ODBC

• systemy Windows Server (2003 i starsze) - czytanie bezpośrednio z dzienników zdarzeń poprzez Rejestr Zdalny i zapytania WMIC

• systemy Windows Server (2008 i nowsze) - wykorzystanie protokołu WS-Management

• urządzenia sieciowe - np. SNMP, Syslog

• systemy *nix - np. rsync, ssh, scp, syslog

Ciekawe jest również sięganie niektórych SIEM-ów (np. QRadar) bezpośrednio do warstwy sieciowej i natywna obsługa rekordów typu flow, z popularnym Cisco NetFlow (v5/v9) na czele. Mamy zatem do czynienia z łączeniem pewnych cech rozwiązań NBAD (Network Behavior Anomaly Detection) z SIEM. Rekordy dostarczają ciekawych informacji np. o charakterze wolumetrycznym związanym z danym ruchem (źródłowy i docelowy IP, port, protokół). Niektórzy idą dalej i wzbogacają informacje z flowów o warstwę aplikacyjną, co dodatkowo uławia wykrywanie konkretnych aplikacji niezależnie od portu.

Warto też przyjrzeć się, w jaki sposób jesteśmy w stanie obejmować monitoringiem nowe, nietypowe źródła informacji, np. aplikacje i systemy tworzone pod potrzeby konkretnych organizacji. Każdy z dostawców w jakiś sposób radzi sobie z tym problemem. Podstawową kwestią jest tutaj możliwość podłączania źródeł bez konieczności zwracania się do producenta. Czołowi gracze na rynku dają możliwość samodzielnego pisania tzw. kolektorów/konektorów. Z reguły jednak dostęp do narzędzi tego typu jest reglamentowany lub wymaga dodatkowej licencji. Takie podejście ma swoje logiczne uzasadnienie. Niewłaściwie napisany kolektor może mocno obciążyć system, dostarczać niewłaściwie znormalizowanych informacji i w rezultacie wpłynąć negatywnie na wszystkie procesy biznesowe, do których SIEM został włączony.