KUMA
Введение: обзор архитектуры

Kaspersky Unified Monitoring and Analysis Platform – решение класса SIEM для мониторинга и анализа инцидентов ИБ. Оно обеспечивает гибкий комплексный подход к противодействию сложным угрозам и целевым атакам.

KUMA поддерживает все основные задачи SIEM-систем:

Дополнительным функционалом продукта является реализация автоматизации процессов защиты, а именно реагирование на возникающие инциденты ИБ вручную или при срабатывании правил корреляции.

KUMA дает возможность запуска задач Kaspersky Security Center, Kaspersky Endpoint Detection and Response или Kaspersky Industrial CyberSecurity for Networks, а также запуска пользовательского скрипта. В последующих обновлениях планируется добавление нового продукта по написанию полноценных сценариев при возникновении инцидентов, что объединит KUMA и новый продукт в полноценную SOAR-систему. Впрочем, это уже совсем другая история.

В основе решения лежит микросервисная архитектура: можно развернуть систему в отказоустойчивой и распределенной архитектуре с пропускной способностью 500 000 событий в секунду и выше.

Настройка всех компонентов/микросервисов выполняется в простом графическом интерфейсе, и не требует никаких специальных знаний в программировании (хотя этот процесс может стать полезным навыком для написания пользовательских скриптов по реагированию на инциденты). Знание SQL запросов может пригодиться в процессе настройки, но это не обязательно.

Давайте рассмотрим архитектуру системы и примерные этапы ее работы.

На изображении представлена упрощенная схема взаимодействия модулей с точки зрения обработки события:

Сначала логи от информационных систем попадают на коллектор, который разбирает (парсит) и нормализует события. На коллекторе можно также отсечь ненужные события и агрегировать или обогатить события из других источников (например, с DNS или геоданными).

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

Пример настройки коллектора вы можете увидеть ниже:

На изображении видно, что интерфейс выглядит довольно просто, и удобно. Чем-то он поминает Apache Nifi: там схожим образом реализованы парсинг и нормализация.
Хранилище служит местом для размещения события, построено оно на базе данных ClickHouse.

Также все поисковые запросы обрабатываются в хранилище. Данную систему можно как развернуть на одном сервере, так и создать распределенную структуру хранения для обеспечения отказоустойчивости и доступности информации. Состоять она будет из нод хранения и ClickHouse Keeper для взаимодействия всех компонентов системы.

Выбор построения хранилища зависит от ваших задач и требований. Выбранная схема прописывается в конфиге перед установкой KUMA. Устанавливается все автономно и вам самим разворачивать сервис не понадобится. Вашей задачей будет только указание сервера, на который будет ставиться тот или иной сервис. Об этом мы более подробно поговорим в следующей статье.

В идеале требуется создание нескольких нод хранения для обеспечения отказоустойчивости.

Помимо хранилища лог попадает в коррелятор, служба проверяет события и создает корреляционные события, если логи удовлетворяют определенным паттернам (правилам). В результате аналитик получает информацию о потенциальном инциденте ИБ.
Корреляционные события могут создаваться как на основе единичного события, так и нескольких групп событий, идущих друг за другом.

Пример правила представлен далее:

Данное правило обнаруживает перебор различных портов (30 штук) по одному хосту в течение 60 сек, если хост не состоит в списке исключений. Также в корреляторе можно настроить оповещение специалистов о новом инциденте (например в Телеграм) и настроить автоматизацию на сработку через скрипт, KSC или агент KEDR.

На компоненте ядра системы работает отдельная база данных MongoDB. В ней лежат все настройки системы, включая конфиги для остальных служб.
Во время запуска, службы обращаются к MongoDB на ядре, получают оттуда и применяют настройки. Также в MongoDB сохраняются алерты, инциденты и связанные с ними копии событий, активы и учетные записи.

По сути — это ключевая служба системы.

Вторая база на ядре — база временных рядов VictoriaMetrics, в которой хранятся метрики мониторинга системы. Реализовано это решение с помощью Prometheus.
Эти метрики визуализируются в интерфейсе KUMA с помощью известной службы Grafana.

На скриншоте вы можете увидеть, как выглядят графики:

Эти данные могут быть очень полезными: на них показывается текущее потребление EPS и отображается потребление системных ресурсов, можно также посмотреть были ли ошибки парсинга и нормализации от конкретного источника.

А еще ядро — это точка входа для специалистов работающих с этой системой. В одном веб-интерфейсе можно смотреть: события, дашборды и настраивать систему.

Пример дашборда:

Для специалиста в первую очередь всегда стоит задача того, какие события отправлять в SIEM.

В KUMA поддерживается множество различных источников:

• события межсетевых экранов (CheckPoint, Fortinet, Usergate, Континент и т.д.)
• события Windows (AD сервера, рабочие ПК)
• события Linux (аутентификация, логи аудита, команды)
• события от сетевых устройств(Cisco, Huawei)
• и многие другие средства защиты информации (KSC, KSMG, PT WAF)

Дополнительно можно настраивать свои источники информации, считывать события из файла и делать запросы в базу данных SQL. Далее настраивается парсинг, нормализация, правила корреляции и дашборды для заведенных событий от нового источника данных. Что-то предоставляется по умолчанию в системе, а что-то необходимо настраивать с нуля. Также можно настроить систему оповещения о новом алерте и автоматизацию при сработке.

Все настройки напрямую зависят от ваших задач.

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

До встречи во второй статье!

Автор статьи: Глеб Ряскин, Инженер отдела интеграций TS Solution