🥇TS Całkowity wzrok. Narzędzie do zbierania zdarzeń, analizy incydentów i automatyzacji reakcji na zagrożenia

Dzień dobry, w poprzednich artykułach zapoznawaliśmy się z twórczością ELK Stack. Omówmy teraz możliwości, jakie może zrealizować specjalista ds. bezpieczeństwa informacji przy wykorzystaniu tych systemów. Jakie logi można i należy wprowadzać do Elasticsearch. Zastanówmy się, jakie statystyki można uzyskać zakładając dashboardy i czy jest z tego jakiś zysk. Jak można wdrożyć automatyzację procesów bezpieczeństwa informacji przy wykorzystaniu stosu ELK. Narysujmy architekturę systemu. W sumie wdrożenie wszystkich funkcjonalności to bardzo duże i trudne zadanie, dlatego rozwiązanie otrzymało osobną nazwę – TS Total Sight.

Obecnie rozwiązania konsolidujące i analizujące zdarzenia związane z bezpieczeństwem informacji w jednym logicznym miejscu szybko zyskują na popularności, w efekcie specjalista otrzymuje statystyki i pole do działania mające na celu poprawę stanu bezpieczeństwa informacji w organizacji. Postawiliśmy sobie to zadanie przy wykorzystaniu stosu ELK i w efekcie podzieliliśmy główną funkcjonalność na 4 sekcje:

Statystyka i wizualizacja;
Wykrywanie incydentów związanych z bezpieczeństwem informacji;
priorytetyzacja incydentów;
Automatyzacja procesów bezpieczeństwa informacji.

Następnie przyjrzymy się bliżej każdemu z osobna.

Wykrywanie incydentów związanych z bezpieczeństwem informacji

Głównym zadaniem Elasticsearch w naszym przypadku jest zbieranie wyłącznie incydentów związanych z bezpieczeństwem informacji. Zdarzenia związane z bezpieczeństwem informacji można zbierać z dowolnych środków bezpieczeństwa, jeśli obsługują one przynajmniej niektóre tryby wysyłania logów, standardem jest zapisywanie do pliku syslog lub scp.

Możesz podać standardowe przykłady narzędzi bezpieczeństwa i nie tylko, skąd powinieneś skonfigurować przekazywanie logów:

Dowolne narzędzia NGFW (Check Point, Fortinet);
Wszelkie skanery podatności (PT Scanner, OpenVas);
Zapora sieciowa aplikacji internetowych (PT AF);
analizatory przepływu sieci (Flowmon, Cisco StealthWatch);
Serwer AD.

Po skonfigurowaniu wysyłania dzienników i plików konfiguracyjnych w Logstash możesz korelować i porównywać zdarzenia pochodzące z różnych narzędzi bezpieczeństwa. W tym celu wygodnie jest skorzystać z indeksów, w których będziemy przechowywać wszystkie zdarzenia związane z konkretnym urządzeniem. Innymi słowy, jeden indeks obejmuje wszystkie zdarzenia dotyczące jednego urządzenia. Dystrybucję tę można wdrożyć na 2 sposoby.

Pierwsza opcja Ma to na celu skonfigurowanie konfiguracji Logstash. Aby to zrobić, musisz zduplikować logi dla niektórych pól w osobnej jednostce innego typu. A następnie użyj tego typu w przyszłości. W tym przykładzie dzienniki są klonowane z modułu IPS zapory sieciowej Check Point.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

W celu zapisania takich zdarzeń do osobnego indeksu w zależności od pól dziennika, np. sygnatur ataków na docelowy adres IP. Możesz użyć podobnej konstrukcji:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

W ten sposób możesz zapisać wszystkie zdarzenia w indeksie, na przykład według adresu IP lub nazwy domeny komputera. W tym przypadku zapisujemy go do indeksu „smartdefense-%{dst}”, według adresu IP miejsca docelowego podpisu.

Jednak różne produkty będą miały różne pola dziennika, co doprowadzi do chaosu i niepotrzebnego zużycia pamięci. I tutaj będziesz musiał albo ostrożnie zastąpić pola w ustawieniach konfiguracyjnych Logstash wstępnie zaprojektowanymi, które będą takie same dla wszystkich typów incydentów, co również jest trudnym zadaniem.

Druga opcja realizacji - to napisanie skryptu lub procesu, który w czasie rzeczywistym uzyska dostęp do elastycznej bazy danych, wyciągnie niezbędne zdarzenia i zapisze je w nowym indeksie, jest to trudne zadanie, ale pozwala pracować z logami według własnego uznania, i bezpośrednio korelują z incydentami wywołanymi przez inny sprzęt bezpieczeństwa. Ta opcja pozwala skonfigurować pracę z logami tak, aby była jak najbardziej użyteczna w Twoim przypadku z maksymalną elastycznością, jednak tutaj pojawia się problem ze znalezieniem specjalisty, który może to wdrożyć.

I oczywiście najważniejsze pytanie, i co można skorelować i wykryć??

Może być tutaj kilka opcji i zależy to od tego, jakie narzędzia bezpieczeństwa są używane w Twojej infrastrukturze, kilka przykładów:

Najbardziej oczywista i z mojego punktu widzenia najciekawsza opcja dla tych, którzy posiadają rozwiązanie NGFW i skaner podatności. Jest to porównanie dzienników IPS i wyników skanowania podatności. Jeżeli system IPS wykrył (nie zablokował) atak, a luka ta nie zostanie zamknięta na komputerze końcowym w oparciu o wyniki skanowania, należy dać znać o sobie, ponieważ istnieje duże prawdopodobieństwo, że luka została wykorzystana .
Wiele prób logowania z jednego komputera do różnych miejsc może symbolizować złośliwą aktywność.
Użytkownik pobierający pliki wirusów w wyniku odwiedzania ogromnej liczby potencjalnie niebezpiecznych witryn.

Statystyka i wizualizacja

Najbardziej oczywistą i zrozumiałą rzeczą do czego potrzebny jest ELK Stack to przechowywanie i wizualizacja logów, w poprzednich artykułach pokazano, w jaki sposób można tworzyć logi z różnych urządzeń za pomocą Logstash. Po tym jak logi trafią do Elasticsearch, można skonfigurować dashboardy, o których też wspominaliśmy w poprzednich artykułach, z potrzebnymi informacjami i statystykami poprzez wizualizację.

Przykłady:

Panel zdarzeń modułu Zapobieganie zagrożeniom z najbardziej krytycznymi zdarzeniami. Tutaj możesz sprawdzić, które sygnatury IPS zostały wykryte i skąd pochodzą geograficznie.
Pulpit nawigacyjny dotyczący korzystania z najbardziej krytycznych aplikacji, w przypadku których mogą nastąpić wycieki informacji.
Zeskanuj wyniki dowolnym skanerem bezpieczeństwa.
Dzienniki usługi Active Directory według użytkownika.
Panel połączenia VPN.

W tym przypadku, jeśli skonfigurujesz dashboardy tak, aby aktualizowały się co kilka sekund, możesz otrzymać w miarę wygodny system monitorowania zdarzeń w czasie rzeczywistym, który będzie można następnie wykorzystać do możliwie najszybszej reakcji na incydenty związane z bezpieczeństwem informacji, jeśli umieścisz dashboardy na osobny ekran.

Priorytetyzacja incydentów

W warunkach dużej infrastruktury liczba incydentów może przekroczyć skalę, a specjaliści nie będą mieli czasu, aby uporać się ze wszystkimi incydentami na czas. W tym przypadku należy przede wszystkim wyróżnić tylko te zdarzenia, które stwarzają duże zagrożenie. Dlatego system musi ustalać priorytety incydentów na podstawie ich wagi w odniesieniu do infrastruktury. Zaleca się ustawienie powiadomienia e-mailowego lub telegramowego o tych zdarzeniach. Priorytety można wdrożyć przy użyciu standardowych narzędzi Kibana, konfigurując wizualizację. Z powiadomieniami jest już trudniej, domyślnie ta funkcjonalność nie jest zawarta w podstawowej wersji Elasticsearch, tylko w wersji płatnej. Dlatego albo kup wersję płatną, albo ponownie napisz samodzielnie proces, który powiadomi specjalistów w czasie rzeczywistym e-mailem lub telegramem.

Automatyzacja procesów bezpieczeństwa informacji

Jedną z najciekawszych części jest automatyzacja działań w przypadku incydentów związanych z bezpieczeństwem informacji. Wcześniej wdrożyliśmy tę funkcjonalność dla Splunk, możesz przeczytać w tym trochę więcej Artykuł. Główną ideą jest to, że polityka IPS nigdy nie jest testowana ani optymalizowana, chociaż w niektórych przypadkach stanowi kluczową część procesów bezpieczeństwa informacji. Przykładowo rok po wdrożeniu NGFW i braku działań optymalizujących IPS, za pomocą akcji Wykryj zgromadzisz dużą liczbę podpisów, które nie zostaną zablokowane, co znacznie obniża stan bezpieczeństwa informacji w organizacji. Poniżej znajduje się kilka przykładów tego, co można zautomatyzować:

Przeniesienie sygnatury IPS z Detect do Prevent. Jeśli Zapobieganie nie działa w przypadku podpisów krytycznych, oznacza to, że jest to niesprawne i stanowi poważną lukę w systemie ochrony. Zmieniamy działanie w polityce na takie podpisy. Funkcjonalność tę można wdrożyć, jeśli urządzenie NGFW posiada funkcjonalność REST API. Jest to możliwe tylko wtedy, gdy masz umiejętności programowania; musisz wyodrębnić niezbędne informacje z Elastcisearch i wysłać żądania API do serwera zarządzającego NGFW.
Jeśli w ruchu sieciowym z jednego adresu IP wykryto lub zablokowano wiele sygnatur, warto na jakiś czas zablokować ten adres IP w polityce Zapory sieciowej. Wdrożenie polega również na wykorzystaniu REST API.
Uruchom skanowanie hosta za pomocą skanera podatności, jeśli ten host ma dużą liczbę sygnatur IPS lub innych narzędzi bezpieczeństwa; jeśli jest to OpenVas, możesz napisać skrypt, który połączy się przez ssh ze skanerem bezpieczeństwa i rozpocznie skanowanie.