Dostrajanie i wdrażanie

Sensor widzi tylko ruch, który do niego dociera. Miejsce rozmieszczenia sensorów IDS/IPS decyduje o tym, co można wykryć, dlatego rozmieszczenie sensorów jest pierwszą decyzją podczas wdrażania.

Rozmieszczenie należy planować wokół wąskich gardeł sieci i granic zaufania: na granicy internetu, między strefami bezpieczeństwa, przed najważniejszymi zasobami oraz w punktach wyjścia, przez które eksfiltracja opuszcza sieć.

Monitorowania wymagają dwie osie ruchu:

• Północ–południe — ruch przekraczający granicę sieci (do internetu lub z internetu). Klasyczne sensory brzegowe obejmują ten ruch.
• Wschód–zachód — ruch między hostami wewnętrznymi. To właśnie w tym obszarze odbywa się ruch boczny, który często nie jest monitorowany.

Napastnicy, którzy dostaną się do wnętrza sieci, poruszają się ze wschodu na zachód. Wdrożenie obejmujące wyłącznie brzeg sieci ich nie wykryje, dlatego wewnętrzne punkty przechwytywania i sensory segmentów są niezbędne we współczesnym wykrywaniu zagrożeń.

Wybór sposobu przechwytywania ruchu wpływa na jego wierność:

• Porty SPAN/mirror są bezpłatne, ale współdzielą zasoby przełącznika i gubią pakiety pod obciążeniem — dokładnie wtedy, gdy są najbardziej potrzebne.
• Sprzętowe urządzenia TAP kopiują ruch bez utraty pakietów i działają mimo awarii urządzenia, ale kosztują i zajmują porty.

W przypadku łączy o dużej przepustowości lub krytycznych ze względu na zgodność preferowane są TAP-y. Agregujące TAP-y i brokery pakietów sieciowych mogą zasilać kilka narzędzi z jednego punktu przechwytywania.

Przeciążony sensor po cichu gubi pakiety, tworząc luki w wykrywaniu, które wyglądają jak czysty ruch. Sensory należy dopasować do łącza.

Należy obserwować statystyki silnika pod kątem wartości capture.kernel_drops i utraty pakietów. Jeśli liczba utraconych pakietów rośnie, potrzebne mogą być dodatkowe zasoby CPU, dostrojenie RAFL/AF_PACKET, zmiana ustawień offloadingu karty sieciowej lub szybszy sensor. Należy sprawdzić, czy sensor obsługuje szczytową, a nie średnią przepustowość.

Uruchamianie każdej dostępnej reguły to przepis na szum i spadek wydajności. Należy starannie dobierać zestaw reguł.

• Należy włączyć kategorie reguł odpowiednie dla środowiska i zasobów
• Należy wyłączyć reguły dotyczące oprogramowania, które nie jest używane
• Należy użyć narzędzia do zarządzania, takiego jak suricata-update, aby pobierać, scalać i wersjonować źródła reguł
• Należy śledzić źródła reguł (ET Open, ET Pro, niestandardowe) i aktualizować je zgodnie z harmonogramem

Zamiast edytować reguły zewnętrznych dostawców, należy kontrolować szum za pomocą konfiguracji progów/tłumienia. Należy wyciszyć głośny sid dla sprawdzonego źródła, a dla pozostałych ustawić progi ograniczające częstotliwość alertów.

Dzięki temu reguły zewnętrznych dostawców można nadal aktualizować, a jednocześnie wyciszać fałszywe alarmy charakterystyczne dla danej sieci.

Nowej lub nieznanej reguły nigdy nie należy wdrażać od razu w trybie drop. Najpierw należy uruchomić ją w trybie alert (IDS), obserwować przez kilka dni lub tygodni, co wykrywa, i potwierdzić, że liczba fałszywych alarmów jest akceptowalna.

Dopiero gdy reguła okaże się godna zaufania, należy wdrożyć ją do blokowania inline. Takie etapowe podejście zapobiega awarii spowodowanej przez pojedynczą wadliwą regułę.

Prawidłowe zdefiniowanie $HOME_NET i innych zmiennych ma fundamentalne znaczenie. Wiele reguł reaguje na kierunek (z zewnętrznej sieci do wewnętrznej vs z wewnętrznej na zewnątrz), dlatego nieprawidłowe $HOME_NET po cichu zaburza logikę wykrywania.

Należy precyzyjnie definiować zakresy wewnętrzne, grupy serwerów i zaufane sieci. Trzeba je aktualizować wraz ze zmianami w sieci oraz przeglądać, gdy wykrywanie zaczyna działać nieoczekiwanie.

Sensory są użyteczne tylko wtedy, gdy ich dane wyjściowe docierają do analityków. Należy przesyłać alerty i metadane do SIEM-u w celu korelacji, wzbogacania i przechowywania danych.

EVE JSON w Suricacie emituje ustrukturyzowane zdarzenia (alerty, przepływy, HTTP, DNS, TLS, skróty plików), które można łatwo przesłać do SIEM-u. IDS należy połączyć z przechwytywaniem pełnych pakietów, aby podczas analizy analitycy mogli pobrać rzeczywisty ruch stojący za alertem.

IPS działający inline znajduje się na krytycznej ścieżce, więc jego awaria oznacza awarię sieci. Należy projektować rozwiązanie z myślą o odporności.

• Karty sieciowe ze sprzętowym obejściem / trybem fail-open zapewniają przepływ ruchu, jeśli silnik przestanie działać (gdy dostępność ma większe znaczenie niż bezpieczeństwo)
• Redundantne sensory w parach active/standby lub w klastrach
• Pozapasmowe sensory IDS również wymagają redundancji, w przeciwnym razie powstaną niezauważone luki w widoczności

Dla każdego łącza należy wybrać tryb fail-open lub fail-closed na podstawie ryzyka biznesowego i przetestować przełączanie awaryjne, zanim zacznie się na nim polegać.

Wdrożony sensor może po cichu przestać działać: zmiana konfiguracji, przekierowanie SPAN lub skok obciążenia może pozbawić go widoczności. Należy sprawdzać, czy nadal działa.

• Należy okresowo generować bezpieczny ruch testowy, który powinien zostać wykryty przez znane reguły
• Należy generować alerty, gdy oczekiwane wykrycia przestaną się pojawiać
• Należy monitorować stan sensora (utracone pakiety, CPU, czas działania) równie uważnie jak alerty
• Należy stosować emulację działań przeciwnika, aby potwierdzać pokrycie od początku do końca

Wykrywania, którego nigdy się nie testuje, nie można darzyć zaufaniem.

Skuteczne wdrożenie IDS/IPS opiera się na widoczności i dyscyplinie:

• Umiejscowienie decyduje o tym, co można zobaczyć; należy objąć ochroną obwód i segmenty wewnętrzne
• Należy monitorować ruch east-west, a nie tylko north-south, aby wykrywać ruch boczny
• Należy preferować TAP-y zamiast SPAN, aby zapewnić bezstratne przechwytywanie przy dużej przepustowości
• Należy dobrać sensory tak, aby liczba utraconych pakietów była bliska zeru
• Należy starannie dobierać zestawy reguł za pomocą suricata-update, a szum tłumić i progować w konfiguracji
• Należy najpierw dostrajać reguły w trybie alert, a następnie przełączać je na drop
• Należy prawidłowo zdefiniować HOME_NET
• Należy przesyłać EVE JSON do SIEM-u i zachować przechwytywanie pakietów na potrzeby analizy
• Należy ciągle weryfikować wykrywanie i stan sensorów

Ukończyli Państwo kurs monitorowania bezpieczeństwa sieci.