Добрый день, читатели нашего канала на Дзене. Сегодня мы обсудим возможности, которые можно реализовать специалисту по ИБ с использованием ELK Stack систем. Какие логи можно и нужно завести в elasticsearch. Рассмотрим, какую статистику можно получить, настраивая дашборды, и есть ли в этом профит. Каким образом можно внедрить автоматизацию процессов ИБ, используя стек ELK. Составим архитектуру работы системы. В сумме, реализация всего функционала—это очень большая и тяжелая задача, поэтому решение выделили в отдельное название — TS Total Sight.
В настоящее время усиленно набирают популярность решения, консолидирующие и анализирующие инциденты ИБ в одном логическом месте. В результате специалист получает статистику и фронт действий для улучшения состояния ИБ в организации. Такую задачу мы себе поставили в использовании стека ELK, в результате выделив основной функционал в 4 раздела:
- статистика и визуализация;
- обнаружение инцидентов ИБ;
- приоритизация инцидентов;
- автоматизация процессов ИБ.
Далее более подробно рассмотрим по отдельности.
Обнаружение инцидентов ИБ
Главная задача в использовании elasticsearch в нашем случае—это сбор только инцидентов ИБ. Собирать инциденты ИБ можно с любых средств защиты, если они поддерживают хоть какие-то режимы пересылки логов. Стандартное - это syslog или по scp сохранение в файл.
Можно привести базовые примеры средств защиты и не только, откуда следует настроить пересылку логов:
- Любые средства NGFW (Check Point, Fortinet);
- Любые сканеры уязвимостей (PT Scanner, OpenVas);
- Web Application Firewall (PT AF);
- Анализаторы netflow (Flowmon, Cisco StealthWatch);
- 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 => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
И, таким образом, можно сделать сохранение в индекс всех инцидентов, например, по IP адресу или по доменному имени машины. В данном случае сохраняем в индекс «smartdefense-%{dst}» по IP адресу назчения сигнатуры.
Однако, у различных продуктов будут разные поля для логов, что приведет к хаосу и лишнему употреблению памяти. И здесь надо будет внимательно в настройках конфига Logstash заменять поля на заранее задуманные, которые будут одинаковы для всех типов инцидентов.
Второй вариант реализации — это написание скрипта или процесса, которые будут в режиме реального времени обращаться к базе эластика, вырывать нужные инциденты и сохранять уже в новый индекс. Это является тяжелой задачей, но позволяет работать с логами как душе угодно и коррелировать напрямую с инцидентами с других средств безопасности. Данный вариант позволяет настроить работу с логами максимально полезно и с максимальной гибкостью, но здесь возникает проблема в поиске такого специалиста, который это сможет реализовать.
И, разумеется, самый главный вопрос: а что вообще можно скореллировать и обнаружить?
Здесь может быть несколько вариантов, и зависит от того, какие средства безопасности используются в вашей инфраструктуре. Парочка примеров:
- Самый очевидный и, с моей точки зрения, самый интересный вариант для тех у кого есть решение NGFW и сканер уязвимостей. Это сравнение логов по IPS и результатов сканирования уязвимостей. Если была задетектирована атака (не блокирована) системой IPS, и данная уязвимость не закрыта на конечной машине исходя из результатов сканирования, — необходимо трубить во все трубы, так как существует большая вероятность того, что уязвимость была проэксплуатирована.
- Много попыток логина с одной машины в разные места может символизировать о зловредной активности.
- Скачивание пользователем вирусных файлов ввиду посещения в огромном количестве потенциально опасных сайтов.
Статистика и визуализация
Самое очевидное и понятное для чего нужен ELK Stack — это хранение и визуализация логов. В прошлых статьях было показано, каким образом можно завести логи от различных устройств, используя Logstash. После того как логи идут в Elasticsearch, можно настроить дашборды, о которых тоже упоминали в прошлых статьях, с необходимой для вас информацией и статистикой посредством визуализации.
Примеры:
1. Дашборд по событиям Threat Prevention с наиболее критическими событиями. Здесь можно отразить, какие сигнатуры IPS были обнаружены, откуда территориально они исходят.
2. Дашборд по использованию наиболее критических приложений, по которым может сливаться информация.
3. Результаты сканирования с любого сканера безопасности.
4. Логи с Active Directory по пользователям.
5. Дашборд по подключению VPN.
В данном случае, если настроить дашборды на обновление каждые несколько секунд, можно получить довольно удобную систему для мониторинга событий в реальном времени, которую далее можно использовать для наиболее быстрого реагирования на инциденты ИБ, если поставить дашборды отдельным экраном.
Приоритизация инцидентов
В условиях большой инфраструктуры количество инцидентов может зашкаливать, и специалисты не будут успевать вовремя разбирать все инциденты. В данном случае необходимо в первую очередь выделять только те инциденты, которые несут большую угрозу. Поэтому система должна приоритизировать инциденты по их опасности по отношению к вашей инфраструктуре. Желательно настроить оповещение на почту или в телеграмм данных событий. Приоритизацию можно реализовать штатными средствами Kibana путем настройки визуализации. А вот с оповещением сложнее, т.к. по умолчанию данный функционал не включен в базовую версию Elasticsearch, он реализован только в платной. Поэтому либо покупать платную версию, либо, опять-таки, самому написать процесс, который будет в режиме реального времени уведомлять специалистов на почту или в телеграмм.
Автоматизация процессов ИБ
И одной из самых интересных частей является автоматизация действий на инциденты ИБ. Ранее данный функционал мы реализовывали для Splunk, чуть подробнее, можете прочитать в этой статье. Основная идея в том, что политика IPS никогда не проверяется и не оптимизируется, хотя в некоторых случаях является важнейшей частью процессов информационной безопасности. К примеру, через год после внедрения NGFW и отсутствия действий по оптимизации IPS, у вас скопится большое количество сигнатур с действием Detect, которые не будут блокироваться, что сильно снижает состояние ИБ в организации. Далее некоторые примеры того, что можно автоматизировать:
1. Перевод сигнатуры IPS с Detect на Prevent. Если на критические сигнатуры не работает Prevent, то это непорядок и серьезная брешь в системе защиты. Меняем действие в политике на такие сигнатуры. Реализовать данный функционал можно, если устройство NGFW обладает функционалом REST API. Это возможно, только обладая навыками программирования, надо выдергивать нужную информацию из Elastcisearch и выполнять 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) и не забудьте подписаться на наш канал ✅
Автор статьи: Глеб Ряскин. Инженер информационной безопасности.
#информационная безопасность #it #сетевые технологии #автоматизация #системное администрирование
