Kolejną warstwą logiczną rozwiązań SIEM jest warstwa korelacyjna, która tak naprawdę stanowi kluczowy element każdego wdrożenia tego typu systemu. To właśnie wokół tej warstwy materializują się postawione wcześniej wymagania, a przygotowane scenariusze korelacyjne są przenoszone do systemu w postaci reguł korelacyjnych, których wynikiem mają być incydenty lub alerty. Pierwszy etap implementacji reguł korelacyjnych często wiąże się z dużą liczbą incydentów, będących w istocie fałszywymi alarmami. Jednakże to nie na zmniejszaniu liczby incydentów należy się skupiać, ale na dokładnym doprecyzowaniu kryteriów i warunków logicznych każdej z reguł, tak aby jakość generowanych incydentów (z uwzględnieniem False Positives i False Negatives) przełożyła się zarówno na wydajność samego rozwiązania, jak i rzeczywistą korzyść z wdrożenia. Dlatego warto przyjrzeć się, na ile elastyczne jest rozwiązanie w tym względzie, i jak dokładnie jesteśmy w stanie opisać w nim złożone scenariusze. Warto zwrócić tutaj uwagę na możliwość implementowania scenariuszy kaskadowych, tj. wiązanie kilku reguł korelacyjnych w jeden incydent. Dla niektórych scenariuszy istnienie takiej możliwości będzie konieczne, a w innych wystarczą pojedyncze, ale rozbudowane reguły.

Dodatkowa wiedza

Niezwykle istotne są również dodatkowe źródła, które zasilają system w informacje kontekstowe. Tutaj jako przykład można przytoczyć integracje z systemami IAM (Identity and Access Management) jako źródło wiedzy o użytkownikach. Ciekawa jest również możliwość pobierania informacji o zagrożeniach identyfikowanych na świecie i ich wpływu/miejsc występowania w naszej organizacji. Ważna jest także możliwość budowania wiedzy o tzw. aktywach organizacji (stacjach roboczych, serwerach) wykraczającej poza adres IP, typ systemu operacyjnego czy rodzaj zainstalowanej aplikacji. Można to osiągnąć poprzez integrację chociażby ze skanerami podatności, a dzięki temu przypisać pewne mierniki (najczęściej C-I-A) do danego zasobu, co z kolei będzie miało wpływ na określanie wagi w scenariuszu korelacyjnym.

Architektura

Jednym z wyzwań, którym przyjdzie stawić czoła podczas wdrożenia systemu SIEM jest retencja danych i szybki dostęp do składowanej informacji. Z punktu widzenia architektury jest to jedno z najpoważniejszych wyzwań. Jeżeli założymy, że pojedyncze zdarzenie może mieć około 800 bajtów, a EPS naszego środowiska to 1000 zdarzeń na sekundę, to będziemy musieli przechować ok. 3 GB danych na godzinę, co w ciągu dnia da wartości rzędu kilkudziesięciu gigabajtów. Mówimy oczywiście o zajętości przed kompresją, a dane tekstowe kompresują się całkiem nieźle. Niemniej jednak z EPS 1000 będziemy mieli do czynienia dość rzadko. W dużych środowiskach wartość ta może być wielokrotnie wyższa. Szybki dostęp do informacji również stanowi wyzwanie. Producenci różnie podchodzą do tego zagadnienia. Niektórzy korzystają z typowych relacyjnych baz danych, inni budują swoje własne silniki bazodanowe, a jeszcze inni stosują pliki płaskie lub połączenie kilku technologii w ramach pojedynczego systemu. Tak czy inaczej, po osiągnięciu pewnego progu czas potrzebny na uzyskanie poszukiwanej informacji może być znaczny. Dlatego też często stosuje się zasadę przechowywania danych krótkoterminowych w systemie na szybkich nośnikach, a resztę przenosi się do archiwów, z których w razie potrzeby sięgnięcia do danych historycznych można łatwo je przywrócić. A skoro mowa o cofaniu się w czasie, to wybierając SIEM-a warto sprawdzić, czy uzyskamy możliwość porównania zdarzeń z przeszłości z aktualnie stosowanymi scenariuszami korelacyjnymi. W ten sposób będziemy mogli sprawdzić, czy kiedyś wystąpiły incydenty, z których wówczas nie zdawaliśmy sobie sprawy.