- PVSM.RU - https://www.pvsm.ru -
Добрый день, в прошлых статьях мы познакомились с работой ELK Stack. А теперь обсудим возможности, которые можно реализовать специалисту по ИБ в использовании данных систем. Какие логи можно и нужно завести в elasticsearch. Рассмотрим, какую статистику можно получить, настраивая дашборды и есть ли в этом профит. Каким образом можно внедрить автоматизацию процессов ИБ, используя стек ELK. Составим архитектуру работы системы. В сумме, реализация всего функционала это очень большая и тяжелая задача, поэтому решение выделили в отдельное название — TS Total Sight.
В настоящее время усиленно набирают популярность решения, консолидирующие и анализирующие инциденты ИБ в одном логическом месте, в результате специалист получает статистику и фронт действий для улучшения состояния ИБ в организации. Такую задачу мы себе поставили в использовании стека ELK, в результате выделили основной функционал в 4 раздела:
Далее более подробно рассмотрим по отдельности.
Главная задача в использовании elasticsearch в нашем случае это сбор только инцидентов ИБ. Собирать инциденты ИБ можно с любых средств защиты, если они поддерживают хоть какие-то режимы пересылки логов, стандартное это syslog или по scp сохранение в файл.
Можно привести стандартные примеры средств защиты и не только, откуда следует настроить пересылку логов:
Посте того, как настроили отправление логов и конфигурационные файлы в 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 заменять поля на заранее задуманные, которые будут одинаковы для всех типов инцидентов, что тоже является сложной задачей.
Второй вариант реализации — это написание скрипта или процесса, которые будут в режиме реального времени обращаться к базе эластика, вырывать нужные инциденты, и сохранять уже в новый индекс, это являются тяжелой задачей, но позволяет работать с логами как душе угодно, и коррелировать напрямую с инцидентами с других средств безопасности. Данный вариант позволяет настроить работу с логами максимально полезно для вашего случая с максимальной гибкостью, но здесь возникает проблема в поиске такого специалиста, который это сможет реализовать.
И разумеется, самый главный вопрос, а что вообще можно скореллировать и обнаружить?
Здесь может быть несколько вариантов, и зависит от того какие средства безопасности используются в вашей инфраструктуре, парочка примеров:
Самое очевидное и понятное, для чего нужен ELK Stack — это хранение и визуализация логов, в прошлых статьях [1] было показано, каким образом можно завести логи от различных устройств, используя Logstash. После того как логи идут в Elasticsearch, можно настроить дашборды, о которых тоже упоминали в прошлых статьях [2], с необходимой для вас информацией и статистикой посредством визуализации.
Примеры:
В данном случае, если настроить дашбоарды на обновление каждые несколько секунд, можно получить довольно удобную систему для мониторинга событий в реальном времени, которую далее можно использовать для наиболее быстрого реагирования на инциденты ИБ, если поставить дашборды отдельным экраном.
В условиях большой инфраструктуры количество инцидентов может зашкаливать, и специалисты не будут успевать вовремя разбирать все инциденты. В данном случае, необходимо в первую очередь выделять только те инциденты, которые несут большую угрозу. Поэтому система должна приоритизировать инциденты по их опасности по отношению к вашей инфраструктуре. Желательно настроить оповещение в почту или телеграмм данных событий. Приоритизацию можно реализовать штатными средствами Kibana, путем настройки визуализации. А вот с оповещением тяжелее, по умолчанию данный функционал не включен в базовую версию Elasticsearch, только в платной. Поэтому либо покупать платную версию, либо опять-таки, самому написать процесс который будет в режиме реального времени уведомлять специалистов на почту или в телеграмм.
И одной из самых интересных частей является автоматизация действий на инциденты ИБ. Ранее данный функционал мы реализовывали для Splunk, чуть подробнее, можете прочитать в этой статье [7]. Основная идея в том, что политика IPS никогда не проверяется и не оптимизируется, хотя в некоторых случаях является важнейшей частью процессов информационной безопасности. К примеру через год после внедрения NGFW и отсутствия действий по оптимизации IPS, у вас скопится большое количество сигнатур с действием Detect, которые не будут блокироваться, что сильно снижает состояние ИБ в организации. Далее некоторые примеры того, что можно автоматизировать:
В сумме реализация всего функционала это очень большая и тяжелая задача. Не обладая навыками программирования, можно настроить минимальный функционал, которого может быть достаточно для использования в продуктиве. Но если вас интересует весь функционал, вы можете обратить внимание на TS Total Sight. Более подробно вы можете ознакомиться на нашем сайте [9]. В результате вся схема работы и архитектура будет выглядеть подобным образом:
Мы рассмотрели, что можно реализовать, используя ELK Stack. В последующих статьях отдельно рассмотрим более детально функционал TS Total Sight!
Так что следите за обновлениями (Telegram [10], Facebook [11], VK [12], TS Solution Blog [13]), Яндекс.Дзен [14].
Автор: GlebRyaskin
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/avtomatizatsiya/351761
Ссылки в тексте:
[1] в прошлых статьях: https://habr.com/ru/company/tssolution/blog/481960/
[2] в прошлых статьях: https://habr.com/ru/company/tssolution/blog/482054/
[3] Image: https://habrastorage.org/webt/nm/0m/wn/nm0mwngtnjs-db8_6199sxqerze.png
[4] Image: https://habrastorage.org/webt/u7/_j/uv/u7_juvhviuwb8m8rzz1ueggcg28.png
[5] Image: https://habrastorage.org/webt/8z/v4/6o/8zv46okroywtqej_myiybzgr4us.png
[6] Image: https://habrastorage.org/webt/pj/ye/4a/pjye4andkxdupw_w7v7yxiupas4.png
[7] статье: https://habr.com/ru/company/tssolution/blog/354844/
[8] Image: https://habrastorage.org/webt/ia/cx/-s/iacx-skj-1bfyhxfkha2etwnaoc.png
[9] сайте: https://tssolution.ru/katalog/totalsight
[10] Telegram: https://t.me/tssolution
[11] Facebook: https://www.facebook.com/groups/tssolution.info/
[12] VK: https://vk.com/ts_solution
[13] TS Solution Blog: https://tssolution.ru/blog
[14] Яндекс.Дзен: https://zen.yandex.ru/id/5c7d2162fa818600ae386a52
[15] Источник: https://habr.com/ru/post/495644/?utm_campaign=495644&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.