TS Total Sight. Инструмент за събиране на събития, анализ на инциденти и автоматизация на реакциите на заплахи

Добър ден, в предишните статии се запознахме с работата на ELK Stack. Сега ще обсъдим възможностите, които специалистът по ИБ може да реализира при използването на тези системи. Какви логове могат и трябва да се записват в Elasticsearch. Ще разгледаме каква статистика можем да получим, настройвайки дашбордове и дали това носи ползи. Как можем да внедрим автоматизация на ИБ процесите, използвайки ELK стека. Ще съставим архитектура на работата на системата. В крайна сметка, реализирането на всичките функционалности е много голяма и сложна задача, затова решението е отделено под специално име — TS Total Sight.

В момента решенията, които консолидират и анализират инциденти по ИБ на едно логично място, печелят все по-голяма популярност, в резултат на което специалистът получава статистика и план за действие за подобряване на състоянието на ИБ в организацията. Тази задача си поставихме при използването на ELK стека, в резултат на което выделихме основния функционал в 4 раздела:

1. Статистика и визуализация;
2. Обнаружение на инциденти по ИБ;
3. Приоритизиране на инциденти;
4. Автоматизация на ИБ процеси.

Нека разгледаме по-подробно поотделно.

Откритие на инциденти по ИБ

Основната задача при използването на Elasticsearch в нашия случай е събирането само на инциденти по ИБ. Инциденти по ИБ могат да се събират от всякакви средства за защита, стига да поддържат някакви режими за изпращане на логове, стандартно това е syslog или чрез SCP запазване в файл.

Могат да се дадат стандартни примери за средства за защита и не само, от които трябва да се настрои изпращането на логове:

1. Каквито и да било средства NGFW (Check Point, Fortinet);
2. Каквито и да било скенери за уязвимости (PT Scanner, OpenVas);
3. Web Application Firewall (PT AF);
4. Анализатори на netflow (Flowmon, Cisco StealthWatch);
5. AD сървър.

След като настроим изпращането на логове и конфигурационните файлове в Logstash, можем да корелираме и сравним инцидентите, постъпващи от различни средства за сигурност. За целта е удобно да се използват индекси, в които ще съхраняваме всички инциденти, свързани с конкретно устройство. С други думи, един индекс съдържа всички инциденти за едно устройство. Такова разпределение може да бъде реализирано по 2 начина.

Първият вариант Това е настройка на конфигурацията на Logstash. Необходимо е да се дублира лог по определени полета в отделна единица с различен тип. След това може да се използва този тип. В примера се клонират логовете по блейда IPS на защитната стена Check Point.

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

За да запазите такива събития в отделен индекс в зависимост от полетата на логовете, например такова като Destination IP на атакуващата сигнатура. Можете да използвате подобна конструкция:

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

По този начин можете да запазите в индекс всички инциденти, например, по IP адрес или по домейн име на машината. В този случай запазваме в индекс «smartdefense-%{dst}», по IP адреса на атакуващата сигнатура.

Обаче, различните продукти ще имат различни полета за логовете, което ще доведе до хаос и излишна употреба на памет. В този случай ще трябва внимателно да замените полетата в настройките на конфигурацията на Logstash с предварително замислени полета, които ще бъдат еднакви за всички типове инциденти, което също е сложна задача.

Вторият вариант за реализация е написването на скрипт или процеси, които в реално време ще се свързват с базата данни на Elasticsearch, ще извлекат необходимите инциденти и ще ги запазят в нов индекс. Това е трудна задача, но позволява работа с логовете по начин, по който желаете, и корелация директно с инцидентите от други средства за сигурност. Този вариант позволява работа с логовете по максимално полезен начин за вашия случай с максимална гъвкавост, но тук възниква проблем в намирането на такъв специалист, който може да го реализира.

И разбира се, най-важният въпрос, какво всъщност може да се корелира и открие?

Тук могат да има няколко варианта и зависи от това какви средства за сигурност се използват в вашата инфраструктура. Ето два примера:

1. Най-очевидният и според мен най-интересен вариант за тези, които имат решение NGFW и скенер за уязвимости, е сравнението на логовете от IPS и резултатите от сканирането за уязвимости. Ако системата IPS е засекла атака (не е блокирана) и тази уязвимост не е поправена на крайното устройство, въз основа на резултатите от сканирането, трябва да се сигнализира, тъй като съществува голяма вероятност уязвимостта да е била експлоатирана.
2. Много опити за вход от едно устройство на различни места могат да символизират злонамерена активност.
3. Сваляне на вирусни файлове от потребителя в следствие на посещение на огромен брой потенциално опасни сайтове.

Статистика и визуализация

Най-очевидното и разбираемо, за какво служи ELK Stack, е съхранението и визуализацията на логовете, в предишните статии беше показано как да се принесат логове от различни устройства, използвайки Logstash. След като логовете отидат в Elasticsearch, можете да настроите табла, за които също беше споменато, в предишните статии, с необходимата за вас информация и статистика чрез визуализация.

Примери:

1. Табло за събития Threat Prevention с най-критичните събития. Тук може да отразите кои подписки на IPS са били открити и откъде географски произтичат.

   

2. Табло за употребата на най-критичните приложения, по които може да изтича информация.

   

3. Резултати от сканиране с всякакъв скенер за сигурност.

   

4. Логове от Active Directory по потребители.

   

5. Табло за свързване на VPN.

В този случай, ако настроите таблата да се обновяват на всеки няколко секунди, можете да получите доста удобна система за мониторинг на събития в реално време, която след това може да се използва за най-бързо реагиране на инциденти в киберсигурността, ако поставите таблата на отделен екран.

Приоритизиране на инцидентите

В условия на голяма инфраструктура броят на инцидентите може да нарасне значително и специалистите няма да успяват да се справят с всички инциденти навреме. В такъв случай трябва първо да се отделят само тези инциденти, които представляват най-голяма заплаха. Затова системата трябва да приоритизира инцидентите по тяхната опасност за вашата инфраструктура. Препоръчително е да се настрои уведомление по имейл или Telegram за тези събития. Приоритизацията може да се реализира с вградените средства на Kibana, чрез настройване на визуализация. Но уведомленията са по-трудни, по подразбиране тази функция не е включена в основната версия на Elasticsearch, само в платената. Затова или трябва да купите платената версия, или отново да напишете процес, който да уведомява специалистите в реално време по имейл или Telegram.

Автоматизация на процесите за информационна сигурност

И една от най-интересните части е автоматизацията на действията при инциденти за информационна сигурност. По-рано реализирахме тази функция за Splunk, можете да прочетете повече за това тук статии. Основната идея е, че политиката IPS никога не се проверява и не се оптимизира, въпреки че в някои случаи е най-важната част от процесите на информационната сигурност. Например, една година след внедряване на NGFW и липса на действия за оптимизация на IPS, ще се натрупа голямо количество подписки с действие Detect, които няма да бъдат блокирани, което значително понижава състоянието на информационната сигурност в организацията. По-долу са дадени някои примери за автоматизация:

1. Промяна на подписката IPS от Detect на Prevent. Ако критичните подписки не работят с Prevent, това е недопустимо и представлява сериозна уязвимост в системата за защита. Променете действието в политиката за тези подписки. Реализирането на тази функция е възможно, ако устройството NGFW притежава функционалност REST API. Това е възможно единствено с програмистки умения, като трябва да извлечете необходимата информация от Elasticsearch и да изпълните API заявки към сървъра за управление на NGFW.
2. Ако от един IP адрес в мрежовия трафик е открито или блокирано множество подписки, е разумно временно да блокирате този IP адрес в политиката на Firewall. Реализацията също включва използването на REST API.
3. Стартирайте проверка на хост с уязвимости сканер, ако на този хост се отнасят много сигнатури от IPS или други средства за сигурност. Ако е OpenVas, можете да напишете скрипт, който да се свързва по ssh с скенера за сигурност и да стартира сканиране.

TS Total Sight

Общото реализиране на цялата функционалност е много голяма и сложна задача. Без умения за програмиране, можете да настроите минималната функционалност, която може да е достатъчна за продуктивна работа. Но ако се интересувате от цялата функционалност, можете да се обърнете към TS Total Sight. По-подробно можете да се запознаете на нашия сайта. В резултат на това цялата схема на работа и архитектура ще изглеждат подобно на следното:

Заключение

Разгледахме какво може да бъде реализирано, използвайки ELK Stack. В следващите статии ще обсъдим по-подробно функционалността на TS Total Sight!

Така че следете обновленията (Телеграм, Facebook, VK, TS Solution Blog), Яндекс.Дзен.

Източник: habr.com