3. Elastic stack: анализ security логов. Дашборды
Сегодня мы поближе ознакомимся с системой визуализации Kibana, рассмотрим как создавать графики, таблицы, и в результате построим простенький дашборд на основе логов с межсетевого экрана Check Point.
Первым шагом работы с kibana — это создание index pattern, логически, это база индексов единых по определенному принципу. В прошлых статьях мы немного ознакомились со стеком elk и настройкой конфигурационного файла Logstash для парсера логов, в данной статье перейдем к самому важному с точки зрения аналитики, то что вы хотите увидеть от системы и ради чего все создавалось — это графики и таблицы объединенные в дашборды. Задается она по сопоставлению строки, допустим “checkpoint-*” и названия индекса. Разумеется, это исключительно настройка для того, чтобы Kibana более удобно искала информацию по всем индексам одновременно. 12. Например, «checkpoint-2019. Отдельно стоит упоминания, что в поиске искать информацию по разным паттернам индексов одновременно нельзя, чуть позже в последующих статьях мы увидим что API запросы делаются либо по названию индекса, либо как раз по одной строчке паттерну, картинка кликабельна: 05 » подойдет под паттерн, а просто «checkpoint» уже нет.
Если обнаружатся какие либо несоответствия, например, поменять тип данных со строки на целое число, необходимо отредактировать конфигурационный файл Logstash, в результате новые логи будут записываться правильно. После этого проверяем в меню Discover, что все логи индексируются, и настроен правильный парсер. Удостоверимся, что все в порядке, картинка кликабельна: Для того, чтобы старые логи до изменения приняли нужный вид, помогает только процесс реиндексации, в последующих статьях эта операция будет рассмотрена более детально.
На основе аналитики дашбордов от security продуктов можно понять состояние ИБ в организации, наглядно увидеть уязвимые места в текущей политике, и в дальнейшем выработать способы по их устранению. Логи оказались на месте, значит, можно приступить к построению дашбордов. Дашборд будет состоять из 5 компонентов: Построим небольшой дашборд, используя несколько средств визуализации.
- таблица для подсчета суммарного количества логов по блейдам
- таблицу по критическим сигнатурам IPS
- круговую диаграмму по событиям Threat Prevention
- диаграмма по наиболее популярным посещаемым сайтам
- диаграмма по использованию наиболее опасных приложений
Для создания фигур визуализации, нужно перейти в меню Visualize, и выбрать нужную фигуру, которую хотим построить! Пойдем по порядку.
Таблица для подсчета суммарного количества логов по блейдам
Для этого выберем фигуру Data Table, проваливаемся в оснастку для создания графиков, слева проставляется настройки фигуры, справа то как она будет выглядеть в текущих настройках. Сначала продемонстрирую как будет выглядеть готовая таблица, после этого пройдем по настройкам, картинка кликабельна:
Более детальные настройки фигуры, картинка кликабельна:
Разберем настройки.
Метрики вычисляются на основе значений, извлеченных тем или иным способом из документов. Первоначально настраивается метрика, это значение, по которому будут агрегироваться все поля. В данном случае ставим в Aggregation: Count (суммарное количество логов). Значения обычно извлекаются из полей документа, но также могут быть сгенерированы с использованием скриптов.
Эту функцию выполняет настройка Buckets, которая в свою очередь состоит из 2 вариантов настройки: После этого делим таблицу по сегментам (полям), по которым будет считаться метрика.
- split rows — добавление колонн и в последующем деление таблицы на строки
- split table — деление на несколько таблиц по значениям определенного поля.
В buckets можно добавить несколько делений для создания нескольких столбцов или таблиц, ограничения тут скорее стоят логические. В aggregation можно выбрать по какому способу будет происходить деление на сегменты: ipv4 range, date range, Terms и т.д. Наиболее занятным выбором является именно Terms и Significant Terms, деление на сегменты производится по значениям определенного поля индекса, разница между ними заключается в количестве возвращаемых значений, и их отображение. Так как мы хотим поделить таблицу по названию блейдов, выбираем поле — product.keyword и задаем размер в количестве 25 возвращаемых значений.
Если вы хотите выполнить полнотекстовый поиск, вы должны использовать тип text, очень удобная вещь при написании своего поискового сервиса, например, ищете упоминание слова в конкретном значении поля (тексте). Вместо строк в elasticsearch используется 2 типа данных — text и keyword. Так же тип данных keyword следует использовать для полей, требующих сортировки или агрегации, то есть, в нашем случае. Если вы хотите только точное совпадение, вы должны использовать тип keyword.
В Custom Label задаем название колонны, которое будет отображаться в таблице, задаем время за которое собираем логи, запускаем прорисовку — Kibana отправляет запрос в elasticsearch, ждет ответ и после визуализирует полученные данные. В результате Elasticsearch считает количество логов за определенное время с агрегированием по значению в поле product. Таблица готова!
Круговая диаграмма по событиям Threat Prevention
Определенный интерес представляет информация, а сколько вообще в процентном соотношении реакций detect и prevent на инциденты ИБ в текущей политике безопасности. Для такого случая хорошо подходит круговая диаграмма. Выбираем в Visualize — Pie chart. Также в метрике задаем агрегацию по количеству логов. В buckets ставим Terms => action.
Поэтому обязательно настраиваем фильтр для того, чтобы искать информацию только по блейдам отвечающие за инциденты ИБ — product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»). Вроде все правильно, но в результате показываются значения по всем блейдам, нужно отфильтровать только по тем блейдам, которые работают в рамках Threat Prevention. Картинка кликабельна:
И более детальные настройки, картинка кликабельна:
Таблица по событиям IPS
Далее очень важным с точки зрения ИБ является просмотр и проверка событий по блейду IPS и Threat Emulation, которые не блокируются текущей политикой, для того чтобы в последующем либо перевести сигнатуру в prevent, либо если трафик валидный — не проверять сигнатуру. Таблицу создаем также как и для первого примера, только с тем отличием, что создаем несколько колонн: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Обязательно настраиваем фильтр для того, чтобы искать информацию только по блейдам отвечающие за инциденты ИБ — product: ( «SmartDefense» OR «Threat Emulation»). Картинка кликабельна:
Более детальные настройки, картинка кликабельна:
Диаграммы по наиболее популярным посещаемым сайтам
Для этого создаем фигуру — Vertical Bar. Метрику также используем count (ось Y), а на оси X в качестве значений будем использовать название посещенных сайтов — “appi_name”. Тут есть небольшая хитрость, если запустить настройки в текущем варианте, то все сайты будут отмечаться на графике одним цветом, для того чтобы сделать их разноцветными используем дополнительную настройку — “split series”, которая позволяет делить уже готовую колонну на еще несколько значений, в зависимости от выбранного поля конечно! Это самое деление можно либо использовать как одна разноцветная колонна по значениям в режиме stacked, либо в режиме normal для того чтобы создать несколько колонн по определенному значения с оси X. В данном случае здесь мы используем то же значение, что и по оси X, это дает возможность сделать все колонки разноцветными, справа сверху они будут обозначаться цветами. В фильтре задаем — product:«URL Filtering» для того, чтобы увидеть информацию только по посещенным сайтам, картинка кликабельна:
Настройки:
Диаграмма по использованию наиболее опасных приложений
Для этого создаем фигуру — Vertical Bar. Метрику также используем count (ось Y), а на оси X в качестве значений будем использовать название используемых приложений- “appi_name”. Наиболее важным является задание фильтра — product: «Application Control» AND app_risk: (4 OR 5 OR 3 ) AND action:«accept». Фильтруем логи по блэйду Application control, берем только те сайты которые категоризированы как сайты с риском Critical, High, Medium и только в том случае если на эти сайты доступ разрешен. Картинка кликабельна:
Настройки, кликабельно:
Дашборд
Просмотр и создание дашбордов находится в отдельном пункте меню — Dashboard. Здесь все просто, создается новый дашборд, в него добавляется визуализация, расставляется по местам и все!
Создаем дашборд, по которому можно будет понять базовую ситуацию состояния ИБ в организации, понятно, только на уровне Check Point, картинка кликабельна:
На основе этих графиков мы можем понять какие критические сигнатуры не блокируются на межсетевом экране, куда ходят пользователи, какие наиболее опасные приложения они используют.
Заключение
Мы рассмотрели возможности базовой визуализации в Kibana и построили дашборд, но это лишь малая часть. Далее в курсе отдельно рассмотрим настройку карт, работу с системой elasticsearch, познакомимся с API запросами, автоматизацией и много чего еще!
Так что следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog), Яндекс.Дзен.