Elastic stack: анализ security логов

В прошлых статьях мы немного ознакомились со стеком elk и настройкой конфигурационного файла Logstash для парсера логов, в данной статье перейдем к самому важному с точки зрения аналитики, то, что вы хотите увидеть от системы, и ради чего все создавалось — это графики и таблицы объединенные в дашборды. Сегодня мы поближе ознакомимся с системой визуализации Kibana, рассмотрим, как создавать графики, таблицы, и в результате построим простенький дашборд на основе логов с межсетевого экрана Check Point.

Первым шагом работы с kibana — это создание index pattern. Логически, это база индексов единых по определенному принципу. Разумеется, это исключительно настройка для того, чтобы Kibana более удобно искала информацию по всем индексам одновременно. Задается она по сопоставлению строки, допустим, "checkpoint-*" и названия индекса. Например, «checkpoint-2019.12.05» подойдет под паттерн, а просто «checkpoint» уже нет. Отдельно стоит упомянуть, что в поиске искать информацию по разным паттернам индексов одновременно нельзя. Чуть позже в последующих статьях мы увидим, что API запросы делаются либо по названию индекса, либо как раз по одной строчке паттерну:

После этого проверяем в меню Discover, что все логи индексируются, и настроен правильный парсер. Если обнаружатся какие-либо несоответствия, например, поменять тип данных со строки на целое число, необходимо отредактировать конфигурационный файл Logstash. В результате новые логи будут записываться правильно. Для того, чтобы старые логи до изменения приняли нужный вид, помогает только процесс реиндексации, в последующих статьях эта операция будет рассмотрена более детально. Удостоверимся, что все в порядке:

Логи оказались на месте, значит, можно приступить к построению дашбордов. На основе аналитики дашбордов от security продуктов можно понять состояние ИБ в организации, наглядно увидеть уязвимые места в текущей политике, и в дальнейшем выработать способы по их устранению.

Построим небольшой дашборд, используя несколько средств визуализации. Дашборд будет состоять из 5 компонентов:

1. Таблицы для подсчета суммарного количества логов по блейдам.
2. Таблицы по критическим сигнатурам IPS.
3. Круговой диаграммы по событиям Threat Prevention.
4. Диаграммы по наиболее популярным посещаемым сайтам.
5. Диаграммы по использованию наиболее опасных приложений.

Для создания фигур визуализации, нужно перейти в меню Visualize, и выбрать нужную фигуру, которую хотим построить! Пойдем по порядку.

Для этого выберем фигуру Data Table, проваливаемся в оснастку для создания графиков. Слева проставляется настройки фигуры, справа то, как она будет выглядеть в текущих настройках. Сначала продемонстрирую, как будет выглядеть готовая таблица, после этого пройдем по настройкам:

Более детальные настройки фигуры:

Разберем настройки.

Первоначально настраивается метрика — это значение, по которому будут агрегировать все поля. Метрики вычисляются на основе значений, извлеченных тем или иным способом из документов. Значения обычно извлекаются из полей документа, но также могут быть сгенерированы с использованием скриптов. В данном случае ставим в Aggregation: Count (суммарное количество логов).

После этого делим таблицу по сегментам (полям), по которым будет считаться метрика. Эту функцию выполняет настройка Buckets, которая в свою очередь состоит из 2 вариантов настройки:

1. Split rows — добавление колонн и в последующем деление таблицы на строки.
2. Split table — деление на несколько таблиц по значениям определенного поля.

В buckets можно добавить несколько делений для создания нескольких столбцов или таблиц, ограничения тут скорее стоят логические. В aggregation можно выбрать по какому способу будет происходить деление на сегменты: ipv4 range, date range, Terms и т.д. Наиболее занятным выбором является именно Terms и Significant Terms, деление на сегменты производится по значениям определенного поля индекса, разница между ними заключается в количестве возвращаемых значений, и их отображение. Так как мы хотим поделить таблицу по названию блейдов, выбираем поле — product.keyword и задаем размер в количестве 25 возвращаемых значений.

Вместо строк в elasticsearch используется 2 типа данных — text и keyword. Если вы хотите выполнить полнотекстовый поиск, вы должны использовать тип text, очень удобная вещь при написании своего поискового сервиса, например, ищете упоминание слова в конкретном значении поля (тексте). Если вы хотите только точное совпадение, вы должны использовать тип keyword. Так же тип данных keyword следует использовать для полей, требующих сортировки или агрегации, то есть, в нашем случае.

В результате Elasticsearch считает количество логов за определенное время с агрегированием по значению в поле product. В Custom Label задаем название колонны, которое будет отображаться в таблице, задаем время за которое собираем логи, запускаем прорисовку — Kibana отправляет запрос в elasticsearch, ждет ответ и после визуализирует полученные данные. Таблица готова!

Определенный интерес представляет информация, а сколько вообще в процентном соотношении реакций detect и prevent на инциденты ИБ в текущей политике безопасности. Для такого случая хорошо подходит круговая диаграмма. Выбираем в Visualize — Pie chart. Также в метрике задаем агрегацию по количеству логов. В buckets ставим Terms => action.

Вроде все правильно, но в результате показываются значения по всем блейдам, нужно отфильтровать только по тем блейдам, которые работают в рамках Threat Prevention. Поэтому обязательно настраиваем фильтр для того, чтобы искать информацию только по блейдам отвечающие за инциденты ИБ — product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»).

И более детальные настройки:

Далее очень важным с точки зрения ИБ является просмотр и проверка событий по блейду 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 запросами, автоматизацией и много чего еще!

Автор: Глеб Ряскин, инженер TS Solution