Niedawno Splunk dodał kolejny model licencjonowania - licencjonowanie oparte na infrastrukturze (
Wygląda to przerażająco, ale czasami ta architektura sprawdza się w produkcji. Złożoność zabija bezpieczeństwo i, ogólnie rzecz biorąc, zabija wszystko. Tak naprawdę w takich przypadkach (mówię o obniżeniu kosztów posiadania) istnieje cała klasa systemów - Central Log Management (CLM). O tym
- Korzystaj z możliwości i narzędzi CLM, gdy istnieją ograniczenia budżetowe i kadrowe, wymagania dotyczące monitorowania bezpieczeństwa i specyficzne wymagania dotyczące przypadków użycia.
- Wdróż CLM, aby zwiększyć możliwości gromadzenia i analizy logów, gdy rozwiązanie SIEM okaże się zbyt drogie lub złożone.
- Zainwestuj w narzędzia CLM oferujące wydajne przechowywanie, szybkie wyszukiwanie i elastyczną wizualizację, aby usprawnić badanie/analizę incydentów związanych z bezpieczeństwem i wspierać wykrywanie zagrożeń.
- Przed wdrożeniem rozwiązania CLM należy upewnić się, że odpowiednie czynniki i rozważania zostały wzięte pod uwagę.
W tym artykule porozmawiamy o różnicach w podejściu do licencjonowania, zrozumiemy CLM i porozmawiamy o konkretnym systemie tej klasy -
Na początku tego artykułu mówiłem o nowym podejściu do licencjonowania Splunk. Rodzaje licencji można porównać do stawek za wynajem samochodu. Wyobraźmy sobie, że model pod względem liczby procesorów jest ekonomicznym samochodem z nieograniczonym przebiegiem i benzyną. Możesz jechać gdziekolwiek bez ograniczeń odległości, ale nie możesz jechać bardzo szybko i odpowiednio pokonywać wiele kilometrów dziennie. Licencjonowanie danych jest podobne do samochodu sportowego z modelem dziennego przebiegu. Możesz bezmyślnie jeździć na długich dystansach, ale za przekroczenie dziennego limitu kilometrów będziesz musiał zapłacić więcej.
Aby skorzystać z licencjonowania opartego na obciążeniu, musisz mieć najniższy możliwy stosunek rdzeni procesora do GB załadowanych danych. W praktyce oznacza to coś takiego:
- Najmniejsza możliwa liczba zapytań do załadowanych danych.
- Najmniejsza liczba możliwych użytkowników rozwiązania.
- Tak proste i znormalizowane dane, jak to możliwe (aby nie było potrzeby marnowania cykli procesora na późniejsze przetwarzanie i analizę danych).
Najbardziej problematyczną rzeczą są tutaj znormalizowane dane. Jeśli chcesz, aby SIEM był agregatorem wszystkich logów w organizacji, wymaga to ogromnego wysiłku w zakresie analizy i przetwarzania końcowego. Nie zapominaj, że trzeba też pomyśleć o architekturze, która nie rozpadnie się pod obciążeniem, czyli np. dodatkowe serwery i dlatego wymagane będą dodatkowe procesory.
Licencjonowanie zbiorcze danych opiera się na ilości danych przesyłanych do paszczy SIEM. Dodatkowe źródła danych podlegają karze w rublu (lub innej walucie), co sprawia, że zaczynasz myśleć o tym, czego tak naprawdę nie chciałeś zbierać. Aby przechytrzyć ten model licencjonowania, możesz przejąć dane przed ich wstrzyknięciem do systemu SIEM. Jednym z przykładów takiej normalizacji przed wstrzyknięciem jest Elastic Stack i kilka innych komercyjnych SIEM.
W rezultacie mamy to, że licencjonowanie według infrastruktury jest skuteczne, gdy trzeba zebrać tylko określone dane przy minimalnym przetwarzaniu wstępnym, a licencjonowanie zbiorcze nie pozwoli w ogóle zebrać wszystkiego. Poszukiwanie rozwiązania pośredniego prowadzi do następujących kryteriów:
- Uprość agregację i normalizację danych.
- Filtrowanie zaszumionych i najmniej ważnych danych.
- Zapewnienie możliwości analizy.
- Wysyłaj przefiltrowane i znormalizowane dane do SIEM
W rezultacie docelowe systemy SIEM nie będą musiały marnować dodatkowej mocy procesora na przetwarzanie i mogą czerpać korzyści z identyfikowania tylko najważniejszych zdarzeń bez ograniczania widoczności tego, co się dzieje.
W idealnym przypadku takie rozwiązanie oprogramowania pośredniego powinno zapewniać także możliwości wykrywania i reagowania w czasie rzeczywistym, które można wykorzystać do ograniczenia wpływu potencjalnie niebezpiecznych działań i agregowania całego strumienia zdarzeń w użyteczny i prosty kwant danych przekazywanych do SIEM. Cóż, wówczas SIEM można wykorzystać do tworzenia dodatkowych agregacji, korelacji i procesów ostrzegawczych.
Tym samym tajemniczym rozwiązaniem pośrednim jest nikt inny jak CLM, o którym wspomniałem na początku artykułu. Gartner widzi to tak:
Teraz możesz spróbować dowiedzieć się, w jaki sposób InTrust spełnia zalecenia Gartnera:
- Efektywne przechowywanie woluminów i typów danych, które należy przechowywać.
- Wysoka prędkość wyszukiwania.
- Możliwości wizualizacji nie są tym, czego wymaga podstawowy CLM, ale wykrywanie zagrożeń przypomina system BI do analizy bezpieczeństwa i danych.
- Wzbogacanie danych w celu wzbogacenia surowych danych o przydatne dane kontekstowe (takie jak geolokalizacja i inne).
Quest InTrust korzysta z własnego systemu pamięci masowej z kompresją danych do 40:1 i szybką deduplikacją, co zmniejsza obciążenie pamięci masowej w systemach CLM i SIEM.
Konsola wyszukiwania zabezpieczeń IT z wyszukiwarką podobną do Google
Specjalistyczny, internetowy moduł IT Security Search (ITSS) może łączyć się z danymi o zdarzeniach w repozytorium InTrust i zapewnia prosty interfejs do wyszukiwania zagrożeń. Interfejs jest uproszczony do tego stopnia, że działa jak Google w przypadku danych dziennika zdarzeń. ITSS wykorzystuje osie czasu dla wyników zapytań, może łączyć i grupować pola zdarzeń oraz skutecznie pomaga w polowaniu na zagrożenia.
InTrust wzbogaca zdarzenia systemu Windows o identyfikatory bezpieczeństwa, nazwy plików i bezpieczne identyfikatory logowania. InTrust normalizuje również zdarzenia do prostego schematu W6 (kto, co, gdzie, kiedy, kto i skąd), dzięki czemu dane z różnych źródeł (zdarzenia natywne w systemie Windows, dzienniki systemu Linux lub dziennik syslog) mogą być widoczne w jednym formacie i na jednym konsola wyszukiwania.
InTrust obsługuje funkcje ostrzegania, wykrywania i reagowania w czasie rzeczywistym, które można wykorzystać jako system podobny do EDR w celu zminimalizowania szkód spowodowanych podejrzaną aktywnością. Wbudowane reguły bezpieczeństwa wykrywają między innymi następujące zagrożenia:
- Rozpylanie haseł.
- Kerberoast.
- Podejrzana aktywność programu PowerShell, taka jak wykonanie Mimikatza.
- Podejrzane procesy, na przykład ransomware LokerGoga.
- Szyfrowanie przy użyciu logów CA4FS.
- Loguje się za pomocą konta uprzywilejowanego na stacjach roboczych.
- Ataki polegające na zgadywaniu hasła.
- Podejrzane korzystanie z lokalnych grup użytkowników.
Teraz pokażę Ci kilka zrzutów ekranu samego InTrust, abyś mógł zapoznać się z jego możliwościami.
Predefiniowane filtry do wyszukiwania potencjalnych luk w zabezpieczeniach
Przykład zestawu filtrów do zbierania surowych danych
Przykład użycia wyrażeń regularnych do utworzenia odpowiedzi na zdarzenie
Przykład z regułą wyszukiwania luk w zabezpieczeniach programu PowerShell
Wbudowana baza wiedzy z opisami podatności
InTrust to potężne narzędzie, które może być używane jako samodzielne rozwiązanie lub jako część systemu SIEM, jak opisałem powyżej. Prawdopodobnie główną zaletą tego rozwiązania jest to, że można zacząć z niego korzystać od razu po instalacji, gdyż InTrust posiada dużą bibliotekę reguł umożliwiających wykrywanie zagrożeń i reagowanie na nie (np. blokowanie użytkownika).
W artykule nie mówiłem o integracjach pudełkowych. Ale zaraz po instalacji możesz skonfigurować wysyłanie zdarzeń do Splunk, IBM QRadar, Microfocus Arcsight lub poprzez webhook do dowolnego innego systemu. Poniżej znajduje się przykład interfejsu Kibana ze zdarzeniami z InTrust. Istnieje już integracja z Elastic Stack, a jeśli korzystasz z darmowej wersji Elastic, InTrust może służyć jako narzędzie do identyfikacji zagrożeń, wykonywania proaktywnych alertów i wysyłania powiadomień.
Mam nadzieję, że artykuł dał minimalne pojęcie o tym produkcie. Jesteśmy gotowi oddać Ci InTrust do testów lub przeprowadzić projekt pilotażowy. Zgłoszenie można zostawić w godz
Przeczytaj nasze inne artykuły na temat bezpieczeństwa informacji:
Źródło: www.habr.com