Wróćmy do warstwy agenta. Posiada on z reguły (a przynajmniej powinien) mechanizmy filtrowania oraz agregacji zdarzeń, co pozwala na odciążenie modułu korelującego, o którym za chwilę. Filtrowanie pozwoli na usunięcie ze strumienia zdarzeń najbardziej podstawowego, a jednocześnie zupełnie nieistotnego szumu informacyjnego. Agregacja pozwoli na przesłanie jednego zdarzenia zamiast kilku czy nawet kilkuset takich samych, a wyróżniać się będzie tylko zwiększonym licznikiem. Skoro jesteśmy przy źródłach danych, od razu warto wspomnieć o "jednostce rozliczeniowej". SIEM-y skalowane są w zależności od liczby przetwarzanych zdarzeń na sekundę - EPS (Events Per Second). I tutaj pojawia się pierwszy problem - realne oszacowanie tych wartości dla naszego środowiska (z rozbiciem na typy źródeł). Na szczęście producenci SIEM-ów idą z pomocą i podpowiadają, jakie zwykle spotka się wartości. Może to być na przykład kilka EPS per użytkownik albo kilkanaście EPS per standardowy serwer. Jest to istotne o tyle, że często wąskim gardłem systemu jest wspomniany agent, a nie sam element korelujący. Co za tym idzie, może zajść potrzeba instalacji od kilku do kilkunastu (duże lub rozproszone geograficznie organizacje) agentów, co należy wcześniej zaplanować (patrząc chociażby na to, czy mamy na czym tego agenta zainstalować). Oczywiście należy pamiętać, że zawsze to będą wartości przybliżone, ponieważ określenia typu "standardowy serwer" są umowne, zaś podane liczby to wypadkowa testów laboratoryjnych oraz wdrożeń pilotażowych i produkcyjnych.

Korelacje

Każdy z producentów wypracował swój własny algorytm, który wykorzystuje do realizacji celów stawianych przed systemem SIEM, więc naturalną konsekwencją będą różnice pomiędzy poszczególnymi produktami. Jednak niezależnie od rozwiązania, kolejność przetwarzania zbieranych informacji jest mniej więcej podobna. Zdarzenie, jako elementarna jednostka informacji, jest najpierw parsowane i normalizowane przez komponent zbierający. Tak przygotowane zdarzenie jest następnie analizowane pod kątem możliwości jego odfiltrowania lub agregacji. Po zakończeniu tego etapu, informacje są przesyłane do silnika korelującego lub archiwizującego. Często gotowe zdarzenie trafia do obu tych usług, gdzie dalsze czynności, takie jak korelacja i archiwizacja, są prowadzone już niezależnie.

Oryginalne, surowe zdarzenie pobrane bezpośrednio z systemu źródłowego wygląda następująco (przykład dla urządzenia sieciowego):

Mamy zatem dość przejrzyście zaprezentowane informacje, gdzie kluczowe elementy, jak nazwa użytkownika czy adres IP, zostały umieszczone w standardowych polach. W tym samym czasie inny agent lub kolektor przetworzy np. zdarzenie z kontrolera domeny i dokona wielu podobnych operacji. Rezultatem będzie zdarzenie zaprezentowane w analogiczny sposób, gdzie najważniejsze informacje umieszczone będą w tych samych polach. Dalsza praca z tak przetworzonymi zdarzeniami na każdym jej etapie - czy to budowania zapytań i raportów, czy też korelacji i obsługi incydentów - będzie nieporównywalnie prostsza i przede wszystkim efektywniejsza. Operator systemu nie musi nawet posiadać wiedzy na temat oryginalnej postaci takich zdarzeń.

Znormalizowane zdarzenia można łatwo filtrować oraz - dla wybranych typów informacji - włączyć ich deduplikację lub agregację. Jeżeli dla przykładu dwa źródła przesyłają dokładnie takie same dane do jednego agenta, wówczas dalej przekazywane jest tylko jedno wystąpienie.