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, можем да корелираме и сравняваме инцидентите, постъпващи от различни средства за сигурност. За целта е удобно да се използват индекси, в които ще съхраняваме всички инциденти, свързани с конкретно устройство. С други думи, един индекс е всичките инциденти за едно устройство. Такова разпределение може да се реализира по два начина.

Първият вариант това е конфигурирането на 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 да заменяте полетата с предварително замислени, които ще бъдат еднакви за всички типове инциденти, което също е сложна задача.

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

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

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

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

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

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

Примери:

1. Табло за събития за предотвратяване на заплахи с най-критичните събития. Тук можете да отразите кои сигнатури 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!

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

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