TS Total Sight. Narzędzie do zbierania zdarzeń, analizy incydentów i automatyzacji reakcji na zagrożenia

Dzień dobry, w poprzednich artykułach zapoznaliśmy się z działaniem ELK Stack. Teraz omówimy możliwości, które specjalista ds. bezpieczeństwa może zrealizować przy użyciu tych systemów. Jakie logi można i należy zbierać w Elasticsearch. Zastanowimy się, jaką statystykę można uzyskać, konfigurując pulpity nawigacyjne i czy wiąże się z tym jakiś zysk. W jaki sposób można wdrożyć automatyzację procesów bezpieczeństwa, korzystając z ELK Stack. Opracujemy architekturę działania systemu. W sumie, realizacja całej funkcjonalności to bardzo duże i trudne zadanie, dlatego to rozwiązanie wyróżniliśmy w osobną nazwę — TS Total Sight.

Obecnie zyskują na popularności rozwiązania, które konsolidują i analizują incydenty bezpieczeństwa w jednym logicznym miejscu, w wyniku czego specjalista otrzymuje statystykę i plan działań na rzecz poprawy stanu bezpieczeństwa w organizacji. Takie zadanie postawiliśmy sobie przy użyciu ELK Stack, w efekcie czego wyróżniliśmy główną funkcjonalność w 4 sekcje:

1. Statystyka i wizualizacja;
2. Wykrywanie incydentów bezpieczeństwa;
3. Priorytetyzacja incydentów;
4. Automatyzacja procesów bezpieczeństwa.

Następnie omówimy to bardziej szczegółowo po kolei.

Wykrywanie incydentów bezpieczeństwa

Głównym zadaniem w użyciu Elasticsearch w naszym przypadku jest zbieranie wyłącznie incydentów bezpieczeństwa. Incydenty bezpieczeństwa można zbierać z wszelkich środków ochrony, jeśli obsługują one jakiekolwiek tryby przesyłania logów, standardowo jest to syslog lub zapisywanie do pliku przez SCP.

Można podać standardowe przykłady środków ochrony i nie tylko, z których należy skonfigurować przesyłanie logów:

1. Wszelkie środki NGFW (Check Point, Fortinet);
2. Wszelkie skanery podatności (PT Scanner, OpenVas);
3. Web Application Firewall (PT AF);
4. Analizatory netflow (Flowmon, Cisco StealthWatch);
5. Serwer AD.

Po skonfigurowaniu wysyłania logów i plików konfiguracyjnych do Logstash, można skorelować i porównać incydenty napływające z różnych środków bezpieczeństwa. W tym celu wygodne jest użycie indeksów, w których przechowamy wszystkie incydenty dotyczące konkretnego urządzenia. Innymi słowy, jeden indeks to wszystkie incydenty dla jednego urządzenia. Takie rozdzielenie można zrealizować na 2 sposoby.

Pierwsza opcja to configure Logstash. To do this, it is necessary to duplicate the log by specific fields into a separate unit with a different type. Then, subsequently, use this type. In the example, logs are cloned based on the IPS blade of the Check Point firewall.

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

To save such events in a separate index depending on the log fields, for example, such as the Destination IP of the attack signature. You can use a construction like this:

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

And thus, you can save all incidents in an index, for example, by IP address or by the machine's domain name. In this case, we save in the index «smartdefense-%{dst}», by the IP address of the signature value.

However, different products will have different fields for logs, which will lead to chaos and excessive memory consumption. Here, either you need to carefully replace fields in the Logstash config settings with pre-designed ones that will be uniform for all types of incidents, which is also a challenging task.

The second implementation option — is writing a script or process that will in real time access the elastic database, extract the necessary incidents, and save them into a new index. This is a heavy task, but it allows for flexible log handling, directly correlating with incidents from other security tools. This option allows you to work with logs as needed, maximizing their usefulness for your case, but the challenge here is finding a specialist who can implement this.

And of course, the most important question, what can actually be correlated and detected?

There may be several options here, depending on what security tools are used in your infrastructure. A couple of examples:

1. Najbardziej oczywistą i z mojej perspektywy najciekawszą opcją dla tych, którzy mają rozwiązanie NGFW i skaner podatności, jest porównanie logów IPS z wynikami skanowania podatności. Jeśli system IPS wykrył atak (nie zablokowany), a dany typ podatności nie jest zabezpieczony na końcowej maszynie według wyników skanowania — należy to zgłosić wszędzie, ponieważ istnieje duże prawdopodobieństwo, że podatność została wykorzystana.
2. Wiele prób logowania z jednego komputera w różne miejsca może świadczyć o złośliwej aktywności.
3. Pobieranie przez użytkownika wirusowych plików na skutek odwiedzania wielu potencjalnie niebezpiecznych stron.

Statystyka i wizualizacja

Najbardziej oczywistym i zrozumiałym zastosowaniem ELK Stack jest przechowywanie i wizualizacja logów, w poprzednich artykułach pokazano, w jaki sposób można gromadzić logi z różnych urządzeń, używając Logstash. Po przesłaniu logów do Elasticsearch, można skonfigurować panele kontrolne, o których również wspomniano, w poprzednich artykułach, z niezbędnymi informacjami i statystyką za pomocą wizualizacji.

Przykłady:

1. Panel kontrolny dotyczący zdarzeń Threat Prevention z najważniejszymi zdarzeniami. Można tu odzwierciedlić, które sygnatury IPS zostały wykryte oraz skąd geograficznie one pochodzą.

   

2. Panel kontrolny dotyczący użycia najbardziej krytycznych aplikacji, przez które mogą wyciekać dane.

   

3. Wyniki skanowania z dowolnego skanera bezpieczeństwa.

   

4. Logi z Active Directory dotyczące użytkowników.

   

5. Panel kontrolny połączeń VPN.

W tym przypadku, jeśli skonfigurujesz panele kontrolne do aktualizacji co kilka sekund, można uzyskać dość wygodny system monitorowania zdarzeń w czasie rzeczywistym, który następnie może być użyty do najszybszej reakcji na incydenty bezpieczeństwa IT, jeśli wyświetlisz panele kontrolne na oddzielnym ekranie.

Priorytetyzacja incydentów

W przypadku dużej infrastruktury liczba incydentów może być znaczna, co może uniemożliwić specjalistom terminowe ich rozwiązywanie. W takim przypadku konieczne jest przede wszystkim wyodrębnienie tylko tych incydentów, które niosą ze sobą największe zagrożenie. System powinien więc priorytetyzować incydenty według ich niebezpieczeństwa wobec Twojej infrastruktury. Zaleca się ustawienie powiadomień o tych zdarzeniach w e-mailu lub Telegramie. Priorytetyzację można zrealizować za pomocą standardowych funkcji Kibana poprzez dostosowanie wizualizacji. Z powiadomieniami jest trudniej, ponieważ domyślnie ta funkcjonalność nie jest dostępna w wersji podstawowej Elasticsearch, a jedynie w płatnej. Dlatego należy albo zakupić wersję płatną, albo samodzielnie napisać proces, który będzie w czasie rzeczywistym powiadamiał specjalistów na e-mail lub Telegram.

Automatyzacja procesów bezpieczeństwa informacji

Jedną z najciekawszych części jest automatyzacja działań w przypadku incydentów bezpieczeństwa informacji. Wcześniej tę funkcjonalność realizowaliśmy dla Splunk, a bardziej szczegółowe informacje można znaleźć w tym artykule. artykułGłównym pomysłem jest to, że polityka IPS nigdy nie jest sprawdzana ani optymalizowana, chociaż w niektórych przypadkach jest najważniejszą częścią procesów bezpieczeństwa informacji. Na przykład, po roku od wdrożenia NGFW i braku działań optymalizacyjnych IPS, zgromadzi się wiele sygnatur o działaniu Detekcja, które nie będą blokowane, co poważnie obniża stan bezpieczeństwa informacji w organizacji. Oto kilka przykładów tego, co można zautomatyzować:

1. Zmiana sygnatur IPS z Detekcji na Zapobieganie. Jeśli na krytyczne sygnatury nie działa Zapobieganie, to jest to nieporządek i poważna luka w systemie ochrony. Zmiana działania w polityce dla takich sygnatur. Można zrealizować tę funkcjonalność, jeśli urządzenie NGFW ma funkcjonalność REST API. Jest to możliwe jedynie posiadając umiejętności programistyczne, należy wyciągnąć potrzebne informacje z Elasticsearch i wykonać zapytania API do serwera zarządzającego NGFW.
2. Jeśli z jednego adresu IP w ruchu sieciowym wykryto lub zablokowano wiele sygnatur, to warto na chwilę zablokować ten adres IP w polityce zapory sieciowej. Realizacja również polega na wykorzystaniu REST API.
3. Uruchom skanowanie hosta skanerem podatności, jeśli na ten host przypada dużo sygnatur IPS lub innych środków bezpieczeństwa. W przypadku OpenVas można napisać skrypt, który będzie łączył się przez ssh ze skanerem bezpieczeństwa i uruchamiał skanowanie.

TS Total Sight

W sumie wdrożenie całej funkcjonalności to bardzo duże i skomplikowane zadanie. Nie mając umiejętności programowania, można skonfigurować minimalną funkcjonalność, która może być wystarczająca do produkcyjnego użytku. Jeśli jednak interesuje Cię pełna funkcjonalność, możesz zwrócić uwagę na TS Total Sight. Możesz przeczytać więcej na naszej stronie. W rezultacie cała schemat pracy i architektura będą wyglądać w ten sposób:

Podsumowanie

Rozważyliśmy, co można wdrożyć, korzystając z ELK Stack. W następnych artykułach omówimy bardziej szczegółowo funkcjonalność TS Total Sight!

Więc śledźcie aktualizacje (Telegram, Facebook, VK, Blog TS Solution), Yandex.Zen.

Źródło: habr.com