Rozwiązania SIEM nie działały idealnie, gdy zostały po raz pierwszy wprowadzone na początku XXI wieku, częściowo ze względu na ich architekturę i funkcjonalność w tamtym czasie, ale także z powodu błędów w danych i źródłach danych, które były do nich wprowadzane.

W tym okresie dane wejściowe były często szczątkowe, brakowało skalowalnościi wymagały rozległej ręcznej interwencji na wszystkich etapach operacyjnych. Trzy z tych źródeł danych wyróżniały się.

1. Ręcznie kodowane zabezpieczenia warstwy aplikacji

Przypadkowo, bezpieczeństwo warstwy aplikacji pojawiło się, gdy po raz pierwszy wprowadzono rozwiązania SIEM. Mniej więcej w tym czasie stało się oczywiste, że ochrona obwodu, hostów i punktów końcowych nie jest wystarczającym zabezpieczeniem dla aplikacji.

Niektórzy deweloperzy eksperymentowali z ręcznym kodowaniem warstw bezpieczeństwa aplikacji w celu wzmocnienia ochrony przed atakami specyficznymi dla danej funkcjonalności. Chociaż podejście to zapewniało dodatkową warstwę bezpieczeństwa, nie zapewniało ono rozwiązaniom SIEM dokładnych danych ze względu na skupienie się programistów na obsłudze przypadków użycia, a nie przypadków nadużyć.

Wynikało to z faktu, że programiści byli przyzwyczajeni do pisania kodu do obsługi przypadków użycia, a nie przypadków nadużyć. Nie byli więc doświadczeni i nie mieli doświadczenia ani wiedzy, aby przewidzieć wszystkie prawdopodobne ataki i napisać złożone kody do zbierania lub autoryzowania dostępu do danych związanych z tymi atakami. Co więcej, wiele wyrafinowanych ataków wymagało korelacji zdarzeń w wielu aplikacjach i źródłach danych, co wykraczało poza monitorowanie poszczególnych aplikacji i ich możliwości kodowania.

2. Porty SPAN i TAP

Porty SPAN, znane również jako porty lustrzane lub porty monitorujące, zostały skonfigurowane na przełącznikach sieciowych lub routerach w celu kopiowania i przekazywania ruchu z jednego lub więcej portów źródłowych do wyznaczonego portu monitorującego. Działały one w ramach infrastruktury sieciowej i umożliwiały administratorom monitorowanie ruchu sieciowego bez zakłócania przepływu danych do zamierzonego miejsca docelowego.

Z drugiej strony, porty TAP były urządzeniami sprzętowymi, które pasywnie przechwytywały i przesyłały ruch sieciowy z jednego segmentu sieci do drugiego. TAP działał niezależnie od przełączników sieciowych i routerów, ale nadal zapewniał pełny wgląd w ruch sieciowy niezależnie od topologii lub konfiguracji sieci.

Pomimo oferowania pełnego wglądu w ruch sieciowy, porty te wypadły z łask w integracji SIEM ze względu na ich niedobór informacji kontekstowych. Nieprzetworzone dane pakietów gromadzone przez porty SPAN i TAP nie posiadały kontekstu niezbędnego do skutecznego działania. wykrywania zagrożeń i analizy, wraz z wyzwaniami, takimi jak ograniczona widoczność sieci, złożona konfiguracja i niewystarczające przechwytywanie zaszyfrowanego ruchu.

3. REST API z 2000 roku

Jako następca SOAP API, REST API zrewolucjonizowało wymianę danych dzięki swojej prostocie, szybkości, wydajności i bezstanowości. Wraz z rozwojem rozwiązań chmurowych, REST API stał się idealnym łącznikiem pomiędzy SIEM i środowiskami chmurowymi, oferując ustandaryzowany dostęp do różnych źródeł danych.

Miało to jednak swoje wady: jedną z nich były problemy z wydajnością sieci.

Interfejsy API REST czasami nadmiernie lub niedostatecznie pobierały dane, co skutkowało nieefektywnym transferem danych między interfejsem API a rozwiązaniem SIEM. Pojawiły się również kwestie ewolucji schematów w interfejsach API REST. Bez silnie typowanego schematu, rozwiązania SIEM miały trudności z dokładnym mapowaniem przychodzących pól danych do predefiniowanego schematu, co prowadziło do błędów parsowania lub niezgodności danych.

Następnie pojawiła się kwestia złożoności i krzywej uczenia się. Wiadomo, że implementacja REST API jest złożona, zwłaszcza w zakresie zarządzania uwierzytelnianiem, paginacją, ograniczaniem szybkości i obsługą błędów. Ze względu na tę złożoność, analitycy bezpieczeństwa i administratorzy odpowiedzialni za konfigurację źródeł danych SIEM mieli trudności lub nawet wymagali dodatkowego szkolenia, aby skutecznie obsługiwać integracje. Prowadziło to również do błędów w konfiguracji, które następnie wpływały na gromadzenie i analizę danych.

Podczas gdy niektóre z powyższych źródeł danych nie zostały całkowicie wycofane z użycia, ich technologie zostały znacznie ulepszone i mają teraz płynną integrację.

Ostatnio używane źródła danych SIEM

1. Logi w chmurze

Chmura została wprowadzona w 2006 roku, kiedy Amazon uruchomił AWS EC2, a następnie rozwiązanie chmury usługowej Salesforce w 2009 roku. Oferuje niezrównaną skalowalność, umożliwiając organizacjom łatwe zarządzanie ogromnymi ilościami danych dziennika. Ponadto zapewnia scentralizowane możliwości rejestrowania i monitorowania, usprawniając gromadzenie i analizę danych dla rozwiązań SIEM. Dzięki wbudowanym funkcjom bezpieczeństwa i kontroli zgodności, logi w chmurze umożliwiają rozwiązaniom SIEM szybkie wykrywanie i reagowanie na zagrożenia bezpieczeństwa.

Zaletom tym towarzyszą jednak pewne wyzwania.

Według Adama Prakscha, administratora SIEM w IBM, rozwiązania SIEM często nie nadążają za szybką ewolucją rozwiązań chmurowych, co skutkuje gromadzeniem nieistotnych zdarzeń lub niedokładnych danych.

Co więcej, integracja rozwiązań SIEM zarówno z systemami lokalnymi, jak i opartymi na chmurze zwiększa złożoność i koszty, jak zauważył Mohamed El Bagory, instruktor techniczny SIEM w LogRhythm.

Niezależnie od tego, El Bagory potwierdził ogromny potencjał danych w chmurze dla rozwiązań SIEM, podkreślając potrzebę eksploracji wykraczającej poza podstawowe informacje z logowań SSH i kart Chrome w celu uwzględnienia danych z wierszy poleceń i statystyk procesów.

2. Logi urządzeń IoT

Jak słusznie zauważył Praksch, każda technologia IT lub OT, która tworzy dzienniki lub raporty dotyczące jej działania, jest już wykorzystywana do celów bezpieczeństwa. Wynika to z faktu, że urządzenia IoT generują mnóstwo bogatych danych na temat swoich operacji, interakcji i środowisk.

Urządzenia IoT, znane z generowania różnych typów danych, takich jak dzienniki, dane telemetryczne i alerty, są uważane za ulubione źródło danych rozwiązań SIEM. Ta różnorodność danych pozwala rozwiązaniom SIEM analizować różne aspekty sieci i identyfikować anomalie lub podejrzane zachowania.

Podsumowanie

Podsumowując, jak słusznie zauważył Praksch, “im więcej danych może przetwarzać rozwiązanie SIEM, tym większe są jego szanse na skuteczne monitorowanie środowiska organizacji pod kątem cyberzagrożeń”.

Tak więc, chociaż większość źródeł danych SIEM pochodzi z początków tej technologii, przeszły one kilka etapów ewolucji, aby upewnić się, że wyodrębniają dokładne i znaczące dane do wykrywania zagrożeń.