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

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

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

1. Статистика и визуализация;
2. IS откриване на инциденти;
3. Приоритизиране на инциденти;
4. Автоматизация на процесите по информационна сигурност.

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

Откриване на инциденти в информационната сигурност

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

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

1. Всякакви средства от NGFW (Check Point, Fortinet);
2. Всякакви скенери за уязвимости (PT Scanner, OpenVas);
3. Защитна стена за уеб приложения (PTAF);
4. Netflow анализатори (Flowmon, Cisco StealthWatch);
5. AD сървър.

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

Първият вариант е да конфигурирате Logstash config. За да направите това, трябва да дублирате дневника за определени полета в отделна единица с различен тип. И след това по-късно използвайте този тип. Примерът клонира регистрационни файлове от IPS блейд на защитната стена на Check Point.

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

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

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

И по този начин можете да запазите всички инциденти в индекса, например по IP адрес или по името на домейна на машината. В този случай съхраняваме в индекса "smartdefense-%{dst}", по IP адреса на местоназначението на подписа.

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

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

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

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

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

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

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

Примери:

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

   

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

   

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

   

4. Регистрации от Active Directory от потребители.

   

5. Табло за управление на VPN връзка.

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

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

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

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

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

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

TS Total Sight

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

Заключение

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

Така че останете на линияTelegram, Facebook, VK, Блог за TS Solution), Yandex Zen.

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