Jak wybierać?

Jakich zatem cech funkcjonalnych powinniśmy oczekiwać od dobrej klasy systemu SIEM? Można je zgrupować w kilku kategoriach: zbieranie zdarzeń i ich korelacja, zarządzanie zdarzeniami, zarządzanie i reagowanie na incydenty, mechanizmy raportowania, logowania oraz prezentacji danych.

Dokonując wyboru, należy więc, obok czystej strony funkcjonalnej, zwrócić uwagę na wiele innych czynników zarówno ściśle technicznych, jak i nietechnicznych. Do technicznych możemy zaliczyć np. ilość oraz rodzaj zasobów, z których informacje chcemy poddać przeglądowi.

Większość rozwiązań opiera się na tzw. kolektorach danych - dedykowanych modułach, napisanych na potrzeby zbierania informacji z określonych urządzeń, środowisk czy aplikacji. I tutaj szczególną uwagę należy zwrócić na "elastyczność" producenta systemu. Z reguły dostarcza on wraz z produktem pewną liczbę takich modułów; rzadko zdarza się, żeby wszystko, co chcemy monitorować, znajdowało się na liście.

Dlatego też nie mniej istotna jest możliwość budowania kolektorów niestandardowych, które będą w stanie przechwycić i przetworzyć zdarzenia np. z autorskich aplikacji bankowych. W przypadku wystąpienia takich niestandardowych źródeł funkcjonują dwie praktyki - albo należy zwracać się do producenta i czekać (przeważnie dość długo) na "dopisanie" modułu, albo sam producent "daje" środowisko, które pozwala na stworzenie modułu.

Z liczbą zasobów ściśle powiązana jest również ilość napływających z nich informacji. SIEM zatem musi gwarantować odpowiednią do potrzeb wydajność. Wydajność określa się poprzez zdolność do obsłużenia określonej ilości zdarzeń na sekundę wyrażoną w EPS (Events Per Second). W zależności od architektury systemu należy brać tutaj pod uwagę zarówno wydajność samego systemu przetwarzania, jak i wchodzących w jego skład modułów zbierających dane (kolektorów).

W niektórych systemach te dwie funkcje są rozdzielone, a w niektórych nie. Nic więc nie przyjdzie z superwydajnego kolektora, jeżeli system przetwarzania nie udźwignie takiego napływu danych. Z reguły SIEM radzą sobie z kilkoma lub kilkudziesięcioma tysiącami zdarzeń. W praktyce jednak te ilości są dużo mniejsze - rzadko sięgają tysiąca.

Z szeroko rozumianą wydajnością wiąże się również sposób przechowywania danych. Wiadomo, że w zależności od polityki organizacji - ale także wymogów prawnych - określone informacje muszą być bezpiecznie składowane przez dany okres. Warto postawić więc pytania o możliwości wbudowanej bazy danych, o współpracę z zewnętrznymi repozytoriami, o zasady wykonywania kopii danych oraz łatwość ich "wyciągania". Oprócz zdolności zebrania i obróbki informacji, SIEM musi potrafić przyzwoicie zaprezentować wynik swojej pracy w postaci chociażby czytelnych raportów i wizualizacji poziomu bezpieczeństwa. Uzupełnieniem dobrego SIEM powinien być dostęp do bazy wiedzy na temat zdarzeń bezpieczeństwa.

Kolejna sprawa to nadmiarowość. Wypadałoby, żeby systemy czasu rzeczywistego potrafiły obsłużyć tryb HA, czy może działać w architekturze rozproszonej.

W dużych organizacjach na porządku dziennym są systemy zarządzania obiegiem informacji czy zarządzania zadaniami (np. Remedy ARS). Ważna jest więc opcja sprzężenia SIEM z takim systemem. Najczęściej będzie ono polegało na możliwości automatycznego stworzenia tzw. ticketu serwisowego (czyli zadania wymagającego obsługi) bezpośrednio w podpiętym systemie HelpDesk, np. w momencie wygenerowania incydentu przez system SIEM.

Wśród czynników nietechnicznych na pierwszy plan wysuwają się wszelkie uwarunkowania natury organizacyjno-prawnej. Będą to więc określone procesy i procedury występujące w firmie, powiązane z nimi normy prawne i regulacje. Charaktery tych czynników i ich odwzorowanie w systemie będą sprawiały, że spektrum produktów branych pod uwagę ulegnie zawężeniu.

Miliardy złotych

To zaledwie muśnięcie rozległego tematu zarządzania incydentami. Powinno jednak rozbudzić apetyt na dalsze poszukiwania i zgłębianie tematu. Nie ulega bowiem wątpliwości, że zagadnienie to będzie coraz częściej nieodłącznym elementem innych procesów wdrożonych w organizacjach. Jednocześnie producenci rozwiązań SIM/SEM/SIEM dokładają wszelkich starań, aby ich "zabawki" były w tym procesie coraz bardziej pożyteczne. Analitycy z firmy Forrester szacują, że rynek tej grupy produktów cechuje się ok. 50-proc. wzrostem. Przy czym tak duży wzrost ma utrzymywać się co najmniej jeszcze przez cały rok 2008.

<hr>

Incident Management w Polsce A.D. 2008

Marcin Kobyliński członek zarządu ISSA Polska

Zarządzanie incydentami bezpieczeństwa informacji jest jednym z elementów większego i kompleksowego procesu zarządzania bezpieczeństwem informacji w organizacji. Problematyka ta jest dość nowa, jednakże znalazła już swoje odzwierciedlenie w aktach normatywnych oraz zbiorach zasad dotyczących bezpieczeństwa informacji. Zarządzanie incydentami bezpieczeństwa informacji zostało np. ujęte w zapisach Pkt 13.x Załącznika normatywnego A do najnowszej edycji normy PN-ISO/IEC 27001:2007 (ISMS), Raporcie Technicznym ISO/IEC TR 18044:2004 (Incident Management), jak również metodykach CoBIT 4.1 (m.in. proces DS5) czy też ITIL. Szczególnie interesujący jest Raport Techniczny ISO/IEC TR 18044:2004, wprowadzający zarządzanie incydentami zgodnie z zasadami i podziałem zastosowanym w cyklu Deminga (tzw. model PDCA).

Rosnący stopień złożoności rozwiązań technicznych stosowanych w IT często wymusza zastosowanie systemu wspierającego proces zarządzania incydentami (zazwyczaj systemu monitorującego zdarzenia i incydenty - SIEM, czy też wykrywającego nadużycia - FD). Wybór takiego systemu wymaga przeanalizowania wielu czynników, takich jak: aktualne wymagania biznesowe i prawne, wyniki analizy ryzyka, dotychczasowe doświadczenia organizacji z incydentami, wewnętrzne procesy i procedury, techniczna specyfika systemów przetwarzania wykorzystywanych w firmie itd. Czynniki te przełożą się na konkretne wymagania techniczne. Systemy SIEM oraz FD mogą być wsparte zewnętrznymi bazami wiedzy i dodatkowymi modułami wykorzystującymi metody sztucznej inteligencji. W ostatecznym rozrachunku krytycznym czynnikiem pozostaje jednak człowiek - administrator lub też analityk bezpieczeństwa.

Efektywne zarządzanie incydentami bezpieczeństwa informacji wymaga również - prócz odpowiedniego zaplanowania, wdrożenia i monitorowania - zadbania o odpowiednio wysoki poziom świadomości nt. bezpieczeństwa (security awareness) wśród kadry zarządzającej oraz pracowników. W przypadku organizacji większych, lub też cechujących się skomplikowaną strukturą organizacyjną, wskazane jest przeprowadzenie symulacji (tj. próbnych incydentów) tak, aby móc zweryfikować sprawność działania organizacji w razie wystąpienia incydentu bezpieczeństwa informacji. Warto jest również - zgodnie z zasadą "lessons learnt" - usprawniać działanie organizacji. Nauka na prawdziwych incydentach może być bowiem dość kosztowna.

Z uwagi na złożoną oraz unikalną naturę incydentu, precyzyjne oszacowania BIA mogą być w tym przypadku niezmiernie trudne. Generalnie w razie zaistnienia incydentu bezpieczeństwa informacji obowiązuje zasada "cięcia siekierą po kablach", jednakże praktyka wykazuje, iż czasami warto jest zaryzykować - tj. "odciąć kable" nieco później, i móc precyzyjniej określić przyczynę wystąpienia incydentu oraz zabezpieczyć materiał dowodowy. Wymaga to jednak odpowiedniego zespołu pracowników, co wskazuje na konieczność zastosowania znaczącego uprawomocnienia (empowerment) dla osób biorących udział w zarządzaniu incydentami bezpieczeństwa informacji.