Falcon Eyes – widzieć więcej – rzecz o wyborze i wdrożeniu systemu klasy SIEM

Wstęp 

Wiadomo, że zarządzanie zdarzeniami istotnymi z punktu widzenia bezpieczeństwa (Security Event Management) wychodzi daleko poza wyłącznie pozyskiwanie, przechowywanie i zabezpieczanie logów oraz dzienników zdarzeń aplikacji i systemów. Obejmuje dodatkowo przetwarzanie informacji o zdarzeniach (w tym interpretację, agregację, normalizację), detekcję i sygnalizację nieprawidłowości, śledzenie trendów zmian oraz – co najważniejsze – reagowanie na zdarzenia, a potem także ich dokumentowanie i raportowanie. Wszystko to pozwala finalnie wyjść z chaosu logów i wkroczyć do uporządkowanego świata korelacji zdarzeń.

Skuteczność tego przedsięwzięcia wymaga, by zarządzanie zdarzeniami bezpieczeństwa odbywało się w ramach dobrze wcześniej zaplanowanego procesu i zostało wsparte odpowiednimi narzędziami, wśród których najważniejszą rolę może odegrać system klasy SIEM (Security Information and Event Management). Wspomniany proces i wspierające go narzędzia, pod warunkiem wszakże, że są dobrze od samego początku zaprojektowane i wdrożone, stają się dla organizacji czymś więcej niż tylko sposobem monitorowania bezpieczeństwa systemów i detekcji incydentów. Dodatkowo mogą dostarczyć nieocenionych wartości w takich dziedzinach jak: zarządzanie ryzykiem, podatnościami systemów oraz incydentami bezpieczeństwa, a także przy przeprowadzaniu analiz materiałów dowodowych (forensic analysis) i monitorowaniu systemów, tym razem nie tylko pod kątem bezpieczeństwa, lecz także pod kątem sposobów wykorzystania, detekcji potencjalnych oszustw (e-fraudów), obciążenia oraz dostępności.

Wszyscy dobre wiemy, że w ogromnym morzu logów, bez odpowiednich narzędzi, trudno zaprowadzić ład. Jeśli weźmiemy pod uwagę dodatkowo fakt, iż prawdziwie istotne incydenty, jak choćby oszustwa w systemach transakcyjnych, na ogół mają złożony, wieloetapowy przebieg, stanowiąc de facto ciąg – mających miejsce w różnych systemach – rozproszonych w czasie zdarzeń, jakakolwiek manualna detekcja jawi się w tych warunkach rzeczą praktycznie niewykonalną. Tu z pomocą przychodzi jednak prawdziwa moc korelacji – podstawowej funkcjonalności narzędzi klasy SIEM, pozwalającej na wyjście poza chaos przysłowiowego „kosza z logami” i wejście do świata porządku, w którym zdarzenia nabierają nowych znaczeń.

O narzędziach klasy SIEM, a konkretnie o wyborze najwłaściwszego z nich, a także o wyzwaniach i uwarunkowaniach sukcesu ich wdrożenia i późniejszego zastosowania w organizacjach, traktuje ten właśnie artykuł.

Komu potrzebny jest Security Event Management i systemy klasy SIEM?

Odpowiedź na pierwszą część zadanego pytania jest dość prosta i raczej oczywista. Zarządzanie zdarzeniami bezpieczeństwa stanowi istotny element, a właściwie zasadniczy filar zarządzania bezpieczeństwem informacji i systemów w ogólności i jako takie jest potrzebne każdej organizacji. To swego rodzaju „sokole oko”, pozwalające patrzeć szerzej i głębiej oraz widzieć dużo więcej, przyglądając się baczniej bezpieczeństwu informacji i ryzyku jego naruszenia. Jednak nie każda organizacja musi zarządzać zdarzeniami bezpieczeństwa w ten sam sposób, w tym samym zakresie i – co z tego wynika – tymi samymi narzędziami. Sposób, zakres i narzędzia powinny być dostosowane do wielkości organizacji, poziomu dojrzałości jej procesów, w tym przede wszystkim procesów zarządzania bezpieczeństwem informacji, rodzaju prowadzonego biznesu oraz w dużym stopniu także wymagań prawnych. Zatem, nawiązując do drugiej części pytania: „komu potrzebne są systemy klasy SIEM?”, można stwierdzić, że potrzebne są one zwłaszcza dużym i średniej skali organizacjom, w tym instytucjom o zaostrzonym rygorze zarządzania ryzykiem i bezpieczeństwem, a do takich należą przede wszystkim instytucje finansowe, w tym głównie banki.

Biorąc pod uwagę ogromny wolumen informacji o zdarzeniach w systemach nawet średniej skali organizacji, manualny przegląd logów i dzienników zdarzeń nie tyle staje się anachronizmem, co wręcz zadaniem niemożliwym do wykonania nawet dla sztabu ludzi, których jedynym zadaniem byłoby „patrzenie w logi”.

Wcześniej posłużyłem się porównaniem systemu SIEM do „oka sokoła”. System SIEM to jednak nie tylko wzrok (detekcja), to także, a może przede wszystkim, mózg (przetwarzanie), a to za sprawą logiki korelacyjnej, stanowiącej przecież istotę zarządzania zdarzeniami. Wyjście poza chaos logów do uporządkowanej rzeczywistości korelacji, to kolejny, ogromnie istotny argument przemawiający za wdrożeniem w firmie systemu klasy SIEM.

Reasumując: Każda organizacja potrzebuje zarządzać zdarzeniami bezpieczeństwa lecz nie każda powinna to robić tak samo i identycznymi narzędziami. Każda natomiast, bez wyjątku, musi być w pełni świadoma, czemu zarządzanie zdarzeniami bezpieczeństwa ma służyć i w jaki sposób ma funkcjonować w całokształcie operacji.

Jaki system wspomagający zarządzanie zdarzeniami bezpieczeństwa jest najlepszy?

Odpowiedź na tak postawione pytanie jest prosta: należy wybrać takie rozwiązanie, które będzie w największym stopniu spełniać potrzeby organizacji. Tu dochodzimy do sedna sprawy – te potrzeby należy dokładnie rozpoznać, a zakup systemu musi być poprzedzony przygotowaniem pełnej specyfikacji wymagań funkcjonalnych. Niby to takie oczywiste, ale rzeczywistość pokazuje, że bywa z tym różnie w praktyce.

Czym należy kierować się dokonując wyboru?

Na początek najważniejsza rzecz: wybór narzędzi musi być podporządkowany procesowi, któremu mają służyć. Innymi słowy, przed dokonaniem wyboru narzędzi, musimy bardzo dokładnie wiedzieć, czego od nich oczekujemy i to nie tylko tu i teraz lecz także w dającej się przewidzieć bliższej i dalszej przyszłości. Przewidywanie przyszłości jest co prawda domeną magików, ale planując pozyskanie i wdrożenie rozwiązania, które może niemało kosztować, trzeba antycypować dającą się ogarnąć przyszłość na tyle, na ile jest to możliwe. Z jednej strony bowiem, system musi rosnąć i rozwijać się razem z organizacją, której służy, a z drugiej, trzeba pamiętać o tym, by nie wdrożyć rozwiązania, które za rok lub dwa będzie już niewydolne i nieużyteczne. Nie mogą też być pozostawione bez odpowiedzi między innymi następujące pytania:

  • Czy stać mnie na system SIEM z prawdziwego zdarzenia?

Pytanie to nabiera szczególnego znaczenia w dobie pokryzysowych obostrzeń i cięć budżetowych.

Choć nie ulega wątpliwości, że nie powinno się oszczędzać na czymś tak ważnym jak bezpieczeństwo, to jednak realia ekonomiczne są jakie są i takimi należy je postrzegać, nie zaś takimi, jakimi chcielibyśmy, żeby były. Mówiąc o kosztach, trzeba wziąć pod uwagę nie tylko koszty zakupu, wdrożenia i utrzymania lecz także koszty skalowania i rozwoju systemu. Ważnym elementem w strukturze kosztów jest także pamięć dyskowa na przechowywanie danych operacyjnych i być może także archiwalnych. O tym także trzeba koniecznie pamiętać przy wycenie.

  • Czy system, którego wybór rozważamy, będzie potrafił nas wspierać na każdym etapie naszego procesu zarządzania zdarzeniami bezpieczeństwa?

Chodzi tutaj o takie funkcje jak klasyfikacja zdarzeń, normalizacja, korelacja, ocena ryzyka, monitoring on-line, wykrywanie nieprawidłowości, detekcja złożonych incydentów bezpieczeństwa o wieloetapowym i wielowątkowym przebiegu, diagnostyka przyczyn zdarzeń, analizy forensicowe, zabezpieczenie dowodów po incydentach, raportowanie, współdziałanie z systemami helpdeskowymi, notyfikacja różnymi kanałami o wystąpieniu zdarzeń (poczta, pop-up, SMS itp).

  • Czego dokładnie spodziewamy się po procesie zarządzania zdarzeniami bezpieczeństwa w naszej organizacji oraz jego interakcjach z innymi procesami?
  • Czy źródłami danych o zdarzeniach będą jedynie systemy standardowe, to znaczy takie, dla których system SIEM dysponuje predefiniowanymi mechanizmami pozyskiwania i przetwarzania logów (na przykład urządzenia sieciowe, urządzenia i systemy zabezpieczeń, systemy operacyjne itp.), czy też rozważamy podłączenie jako źródeł zdarzeń także systemów niestandardowych, w tym aplikacji i systemów transakcyjnych?

W tym drugim przypadku będziemy musieli zmierzyć się być może z ogromnym wyzwaniem. Trzeba będzie opracować specjalnych agentów, zdolnych do czytania i poprawnej interpretacji nieraz bardzo specyficznych logów aplikacji. Specyficznych w sensie struktury, wielkości, miejsca i sposobu deponowania, mechanizmów transportowych itp. Problem staje się tym poważniejszy, że – zwłaszcza w już istniejących i produkcyjnie działających systemach – logi nie zawsze pozostają zgodne ze standardami. Musimy być przygotowani na wykonanie ogromnej pracy na etapie kontroli jakości logów i korygowania zidentyfikowanych nieprawidłowości, które często – pod bliższym zapoznaniu się – okazują się być prawdziwym bałaganem, niełatwym do ogarnięcia. Z nowo budowanymi aplikacjami rzecz jest oczywiście dużo prostsza, bo w tym przypadku specyfikacja wymagań bezpieczeństwa powinna wymusza odpowiedni standard logów od samego początku cyklu ich rozwoju.

  • Czy potrzebny jest nam system oparty na agentach, czy system ‚bezagentowy’?

System oparty na agentach posiada wiele zalet, z których najistotniejsze to: (1) możliwość bezprzerwowego działania bez utraty zdarzeń (w trybie off-line) kolektora danych, w sytuacji chwilowego braku połączenia z sercem systemu czyli z serwerem zarządzającym i repozytorium zdarzeń; (2) możliwość wstępnego parsowania, normalizacji, zabezpieczania integralności i znakowania znacznikiem czasowym logów już po stronie agenta; (3) szyfrowanie transmisji do managera (serwera zarządzającego) i repozytorium logów.  Oczywistą wadą systemu ‘agentowego’ jest potrzeba instalacji agentów dla niestandardowych źródeł zdarzeń, ale jest to wada o marginalnym znaczeniu, jeśli weźmie się pod uwagę ewidentne, znacznie poważniejsze korzyści, jak choćby te wcześniej wyszczególnione.

  • Czy potrzebujemy systemu działającego w architekturze podwyższonej dostępności i niezawodności, czy system ma działać w strukturach hierarchicznych?
  • Czy potrzebujemy systemu potrafiącego przetwarzać logi o rozmiarach przekraczających maksymalny rozmiar logów Sysloga, wynoszący 1024 bajty?
  • Czy planujemy deponowanie logów w bazie danych czy w płaskich plikach? Jak zamierzamy zapewnić logom integralność i poświadczyć ich autentyczność, a co za tym idzie wartość dowodową w ewentualnych postępowaniach sądowych i dyscyplinarnych po incydentach bezpieczeństwa?
  • Jak będziemy archiwizować logi?
  • Gdzie znajduje się granica skalowalności naszego systemu SIEM?
  • Kto ma być beneficjentem wiedzy zgromadzonej w systemie SIEM?

Tutaj chodzi w szczególności o bezpieczną dystrybucję wiedzy do jej odbiorców i zapewnienie im dostępu do systemu w zgodzie z zasadą wiedzy koniecznej w oparciu o paradygmat Role Based Access Control.

  • Jakich narzędzi wizualizacji i prezentacji treści (raporty, dashboardy etc.) będziemy potrzebować?
  • Czy i jakie aplikacje chcemy budować na bazie systemu SIEM?

To tylko niektóre z ważnych pytań, które należy zadać i uczciwie na nie odpowiedzieć przed wyborem takiego czy innego rozwiązania. Pełną listę pytań i matrycę oceny każda organizacja musi opracować sama, biorąc pod uwagę lokalne uwarunkowania, potrzeby, założenia projektowe czy wreszcie preferencje.

Konkludując: wybieramy system SIEM nie tylko dlatego że dobrze wypadł w analizie Gartnera lecz przede wszystkim pod kątem możliwie jak najściślejszego jego dopasowania do specyfikacji naszych wymagań. Specyfikacja wymagań zaś powinna powstać na bazie wiedzy o naszym procesie zarządzania zdarzeniami bezpieczeństwa i procesach powiązanych, o których była już tutaj mowa.

Jak przebiega „typowe” wdrożenie systemu SIEM?

Wdrożenie systemu SIEM jest na ogół podzielone na kilka faz. Pierwsza z nich polega na integracji ze standardowymi źródłami danych. Z perspektywy określonego rozwiązania, standardowymi źródłami zdarzeń są wszelkie te systemy, dla których system SIEM dysponuje predefiniowanymi mechanizmami pobierania, transportu, gromadzenia i przetwarzania logów. Chodzi tu na przykład o wszystkie systemy stosujące typowe  mechanizmy Sysloga, Check Point LEA, ODBC etc. Przeważnie w tej fazie z systemem SIEM są integrowane wszystkie urządzenie sieciowe, systemy IPS, firewalle, content switche, acceleratory SSL, serwery proxy, webowe serwery aplikacyjne, systemy operacyjne, viruswall-e, serwery domenowe Windows oraz inne w miarę „proste” w sensie logów systemy, na przykład systemy poczty elektronicznej.

Druga faza na ogół polega na integracji systemu SIEM z niestandardowymi źródłami danych, na przykład z systemami transakcyjnymi. Stanowi ona przeważnie dużej skali przedsięwzięcie z uwagi na potrzebę opracowania agentów, dostosowanych do specyfiki aplikacji, potrafiących czytać, poprawnie interpretować oraz przetwarzać nieraz bardzo duże i skomplikowane logi.

W kolejnych fazach system jest zasilany wciąż doskonaloną logiką korelacji zdarzeń oraz tzw. aktywną treścią, która umożliwia wizualizowanie i prezentację wyników jego działania w postaci różnego rodzaju dashboardów, kwerend, wzorców raportowych, aktywnych list itp.

Z jakimi wyzwaniami będzie trzeba się zmierzyć?

Największym wyzwaniem bywa integracja systemu SIEM z niestandardowymi źródłami zdarzeń. Przedtem zawsze wymagana jest dokładna analiza logów pod kątem ich struktury, poziomów istotności komunikatów, dostępnych podsystemów logowania (facilities), możliwych poziomów szczegółowości, mechanizmów generowania, transportu i przechowywania, no i oczywiście treści. Wszak nie od dziś znana jest zasada „garbage in – garbage out”, zatem jakość logów jest jednym z absolutnie najważniejszych kryteriów powodzenia przedsięwzięcia. Nie jest bowiem możliwe opracowanie jakichkolwiek wartościowych reguł korelacyjnych, jeśli dane źródłowe, na których mają one bazować są kiepskiej jakości. Trzeba mieć to na uwadze, przyjmując zasadę, że nie wolno „chodzić na skróty” na tym etapie prac. Nie jest wykluczone, że będziemy musieli stawić czoła wielu – delikatnie rzecz ujmując – niedoskonałościom i rzeczom wymagającym poprawy. Efektem analizy jakości logów muszą stać się raporty rozbieżności pomiędzy stanem faktycznym, a pożądanym stanem docelowym. Raporty powinny zostać przekazane dostawcom aplikacji do wdrożenia zmian, jeśli jest to możliwe.

Po uporządkowaniu logów przychodzi czas na opracowywanie interpreterów (parserów) logów i opracowywanie agentów. Potem, kiedy już z radością stwierdzimy, że do naszego systemu SIEM spływają poprawnie zinterpretowane logi bardzo dobrej jakości, nadchodzi czas na zmierzenie się z kolejnym wyzwaniem – tworzeniem reguł korelacyjnych oraz treści do prezentacji wyników i wzorców raportów. Nawet kiedy możemy już pochwalić się sporymi sukcesami na tym polu i konkretnymi efektami pracy, to ten etap praktycznie nigdy się nie kończy, a raczej nie powinien się kończyć, bo pomysłów na ogół wciąż przybywa (szkoda, że z zasobami nie jest analogicznie). Ważne jest, aby wybrane i wdrożone rozwiązanie dotrzymywało kroku naszym pomysłom i planom, dostarczając zawsze odpowiednich narzędzi do ich realizacji.

Informacje Janusz Nawrat
Just ordinary man who likes thinking...

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

TOMASZ WEŁNA

artysta grafik | wykładowca

PRACOWNIA OKO

Szkoła Rysunku Malarstwa i Grafiki DR TOMASZA WEŁNY | KRAKÓW | Plac Matejki 10 | tel 691 81 75 74

Piękno neurobiologii

Blog Jerzego Vetulaniego

Teoria muzyki, zasady muzyki, podstawy muzyki

Teoria muzyki, zasady muzyki, podstawy muzyki - czyli to co każdy amator muzyki wiedzieć powinien :)

Personal Development & Inspirations

Przemyślenia i refleksje, którymi warto się podzielić (blog by Janusz Nawrat)

Business IT Cooperation Platform

Biznes i IT - dwa światy, które muszą współdziałać

%d bloggers like this: