Обзор SIEM-системы KUMA 1.5, центрального элемента единой платформы безопасности Kaspersky

1. Введение
2. Функциональные возможности Kaspersky Unified Monitoring and Analysis Platform
3. Архитектура Kaspersky Unified Monitoring and Analysis Platform
4. Системные требования Kaspersky Unified Monitoring and Analysis Platform
5. Сценарии использования Kaspersky Unified Monitoring and Analysis Platform
   1. 5.1. Первые шаги с Kaspersky Unified Monitoring and Analysis Platform
   2. 5.2. Интеграция с Kaspersky Security Center
   3. 5.3. Сбор данных с Windows-инфраструктуры
   4. 5.4. Сбор событий с Cisco WSA
   5. 5.5. Разнообразные источники: Netflow, Cisco ASA
6. Выводы

Введение

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

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

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

Помимо функциональности важна гибкость, достигаемая за счёт разделения на функциональные модули, которые в любой момент можно добавлять или убирать в случае необходимости. Стоит отметить, что рассматриваемая в обзоре система Kaspersky Unified Monitoring and Analysis Platform обладает необходимыми конечному заказчику функциональными возможностями, а также может дополняться различными модулями.

Например, KUMA в последней версии позволяет создавать карточки инцидентов, что помогает собрать в одном месте все относящиеся к одной атаке срабатывания. Такой подход позволяет улучшить процесс взаимодействия с НКЦКИ через встроенный модуль ГосСОПКА. А для поставщиков услуг безопасности (MSSP) и крупных организаций реализована поддержка мультиарендности (multitenancy).

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

Функциональные возможности Kaspersky Unified Monitoring and Analysis Platform

В качестве вступления хотелось бы отметить, что KUMA изначально поддерживала «из коробки» решения как самой «Лаборатории Касперского», так и сторонних поставщиков (рис. 1). С выходом новой версии список поддерживаемых источников только вырос, причём существенно. Стоит отметить возможность создания собственных парсеров с помощью встроенных средств визуального интерфейса и открытую архитектуру на уровне API.

Рисунок 1. Источники данных для KUMA

Также стоит упомянуть, что в новой версии KUMA 1.5 реализована поддержка новых коннекторов для приёма событий по следующим протоколам:

• WMI (через RPC) — позволяет получать события Windows с удалённых компьютеров с помощью методов на основе протокола дистанционного вызова процедур (RPC). WMI может работать с одним агентом (который будет передавать данные от остальных хостов), в отличие от WEC, который позволяет принимать события Windows только с локального компьютера или с WEC-сервера, на котором установлен агент.
• SNMP версий 1, 2 и 3 — позволяет в активном режиме запрашивать данные по одноимённому протоколу.
• NFS — позволяет вычитывать события из файлов в общей папке NFS.
• FTP — позволяет вычитывать события из файлов доступных по протоколу FTP.

Известно, что для более надёжного обнаружения и для уменьшения количества ложных срабатываний требуются обогащение событий и постоянная инвентаризация активов. В KUMA это достигается с помощью средств автоматизации (рис. 2). Так, в функциональных возможностях присутствуют автоматическое обогащение через сторонние базы данных и инвентаризация при помощи KSC + KES через API с KUMA. Обогащение можно делать и на коллекторах; также есть встроенные механизмы обогащения с использованием потоков TI, DNS, LDAP.

Кроме того, через KSC можно автоматизировать реагирование на выявленные вредоносные события в ИБ.

Рисунок 2. Автоматизация в KUMA

Ранее была отмечена важность поддержки сторонних источников, так как не все используют в качестве базы для своих защитных систем средства разработанные Kaspersky. Поэтому хотелось бы дополнительно показать, какие именно решения сторонних поставщиков могут быть подключены к KUMA (рис. 3).

Рисунок 3. Карта поддерживаемых сторонних источников

Вдобавок значительно расширены возможности управления инцидентами (рис. 4). Эта функция в KUMA помогает расследовать инциденты, определять их первопричины и координировать совместную работу нескольких аналитиков.

Рисунок 4. Карточка инцидента в KUMA 1.5

KUMA обладает REST API, что позволяет дописывать собственные интеграционные модули, а также поддерживает работу с событиями, уведомлениями и активами.

Архитектура Kaspersky Unified Monitoring and Analysis Platform

В основе KUMA лежит микросервисная архитектура, так что представленные на рисунке 5 компоненты могут гибко масштабироваться под нужды заказчика.

Рисунок 5. Архитектура KUMA

Стандартная установка программы основана на следующих компонентах:

• один или несколько сборщиков, которые получают сообщения из источников событий, анализируют эти сообщения, нормализуют и при необходимости фильтруют и / или агрегируют, при этом обогащение возможно в режиме реального времени;
• коррелятор, который анализирует нормализованные события, поступающие от коллекторов, выполняет необходимые действия с активными списками и создаёт оповещения в соответствии с правилами корреляции;
• ядро, которое отвечает за централизованное управление всеми компонентами системы, а также предоставляет графический интерфейс администрирования и доступ к RESTful API;
• СУБД ClickHouse, в которой содержатся нормализованные и «сырые» события.

Стоит отметить, что все ключевые элементы KUMA являются собственной разработкой «Лаборатории Касперского».

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

Системные требования Kaspersky Unified Monitoring and Analysis Platform

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

Минимальные рекомендуемые системные требования — «всё в одном», 8 vCPU / 12 ГБ ОЗУ / 500 ГБ на жёстком диске — подойдут для тестовых инсталляций. Для полноценных развёртываний понадобится более мощное оборудование.

Так, описанные ниже (табл. 1) аппаратные ресурсы обеспечат обработку 10 000 событий в секунду, 180 дней хранения логов («горячее» хранение), конфигурацию без отказоустойчивости (кроме БД). Цифры зависят от типа анализируемых событий и эффективности парсера. Кроме того, иметь больше ядер более эффективно, чем меньше ядер с более высокой частотой процессора.

Таблица 1. Системные требования под 10 000 событий в секунду

Стоит отметить, что системы класса SIEM никогда не были легковесными, поэтому даже несмотря на все возможные оптимизации в KUMA потребуется выделить достаточное количество ресурсов, учитывая количество событий и возможный рост на перспективу для возможности легко масштабировать платформу. Однако в сравнении с другими SIEM KUMA вполне легковесна.

Не менее важно учесть и другие требования — к ПО, сети и рабочим местам, с которых будет подключаться оператор платформы KUMA (табл. 2).

Таблица 2. Дополнительные системные требования и рекомендации

На этом теоретическая часть завершена. Самое время перейти к практическим сценариям.

Сценарии использования Kaspersky Unified Monitoring and Analysis Platform

Первые шаги с Kaspersky Unified Monitoring and Analysis Platform

В обзоре мы рассматриваем KUMA в установке «всё в одном» (рис. 6). Для «боевых» установок предлагается разносить компоненты платформы на разные серверы, что позволит улучшить масштабируемость. Однако и вариант «всё в одном» тоже можно использовать — для низконагруженных сред.

Рисунок 6. Развёртывание KUMA

После установки переходим в раздел сервисов, на рисунке 7 показано уже полностью готовое развёрнутое и настроенное решение. В разделе «Сервисы» нам доступны сведения о подключённых ресурсах: их адрес, статус, время создания и т. п.

Рисунок 7. Обзор сервисов в KUMA (часть 1)

Попробуем найти события, собранные с подключённых источников. Выберем пункт «Find in events» (рис. 8).

Рисунок 8. Обзор сервисов в KUMA (часть 2). Поиск событий

В результате достаточно зайти на вкладку «События» и с помощью гибкого языка запросов (визуального мастера) выполнить поиск (рис. 9). Поскольку была выбрана определённая строка в разделе «Сервисы», в результате запроса мы видим примеры собранных событий из Kaspersky Security Center, который является одним из логичных источников данных для SIEM.

Рисунок 9. Пример собранных событий из KSC

Чтобы добиться такого результата, нужно знать, как настроить интеграцию с различными источниками событий, и опробовать варианты агрегации и нормализации событий. Займёмся этим.

Интеграция с Kaspersky Security Center

В качестве одного из основных источников событий на стенде выступает Kaspersky Security Center. Для подключения требуется лицензия уровня «KESB Расширенный» и выше (рис. 10).

Рисунок 10. Настройка интеграции с KSC. Расширенный лицензионный ключ

Далее переходим в раздел «Экспорт событий» в KSC, выбираем формат CEF и порт KUMA (в нашем случае — 5140).

Рисунок 11. Экспорт в SIEM в формате CEF из KSC

После произведённых настроек в KUMA будут отображаться получаемые из KSC события.

Кроме KSC рассмотрим несколько других источников событий. Например, весьма часто офисная инфраструктура заказчика построена на Windows.

Сбор данных с Windows-инфраструктуры

Рассмотрим подключение Windows в интерфейсе KUMA, тип созданного сервиса — «коллектор», то есть сборщик событий (рис. 12).

Рисунок 12. Установка и настройка Windows-агента

При настройке параметров подключения указываются имя агента, URL (адрес), порт, по которому будет происходить подключение, и — самое главное — тип журналов (логов), которые мы планируем собирать для дальнейшей агрегации и корреляции (рис. 13).

Рисунок 13. Настройка параметров подключения Windows-агента (адрес и порт)

Выше мы произвели настройки на стороне KUMA; теперь необходимо использовать URL ядра KUMA (в формате «адрес:порт») и идентификатор конфигурационного файла для предварительной настройки агента на Windows-хосте (рис. 14).

Рисунок 14. Настройка подключения к ядру KUMA на Windows-сервере (ID конфигурационного файла)

Ещё одним популярным источником событий, который поддерживает KUMA, является оборудование Cisco.

Сбор событий с Cisco WSA

Установка нового коллектора для Cisco WSA производится с небольшими отличиями, но в целом подход совпадает, при этом нужно правильно указать API-порт (см. рис. 15).

Рисунок 15. Установка микросервиса, настройка подключения через API-порт

При подключении производится проверка доверия и подлинности на основе сертификатов.

После успешного подключения убедимся, что события начали поступать в коллектор (рис. 16). Поиск событий производится при помощи встроенного языка запросов по синтаксису похожему на SQL. В деталях событий мы видим, что они поступают в «сыром» виде (raw).

Рисунок 16. Проверка получения событий. Raw-событие

Такие события необходимо разобрать и нормализовать; для этого воспользуемся регулярными выражениями (рис. 17). Для отладки регулярного выражения можно использовать встроенный редактор или любой доступный сервис, способный проверить корректность их синтаксиса. Изучив структуру события, можно выделить типовые паттерны поиска.

Рисунок 17. Нормализация при помощи регулярных выражений

Для лучшей нормализации событий необходимо оперировать именованными группами (например, «timestamp», «elapsedtime»). Такие именованные группы добавляются в нормализованное событие.

Рисунок 18. Событие из Cisco WSA после нормализации

После нормализации события приобретают более чёткий и понятный для оператора KUMA вид.

Разнообразные источники: Netflow, Cisco ASA

Помимо перечисленных возможностей KUMA поддерживает анализ сетевых потоков, больший эффект достигается за счёт DNS-обогащения (рис. 19).

Рисунок 19. События в Netflow с DNS-обогащением

Также можно осуществлять гибкую фильтрацию по типу ресурсов, такой подход применяется для агрегации событий (рис. 20).

Рисунок 20. Фильтрация событий, которые должны подпадать под агрегацию (Cisco ASA)

После агрегации можно увидеть, что общее входное количество событий осталось неизменным, но количество событий после агрегации значительно снизилось (рис. 21).

Рисунок 21. Замер количества входных событий в консоли KUMA

В целом KUMA имеет ряд особенностей в реализации архитектуры. Это отличает её от других решений подобного класса.

Выводы

Создано весьма много различных систем управления событиями по информационной безопасности, международных и отечественных. Подходы в таких системах в целом одинаковы. Общая концепция заключается в сборе, агрегации, корреляции и хранении результатов для ретроспективного анализа, а также возможности автоматизировать многие трудозатратные действия — реагирование на инциденты, сбор инвентаризационной информации, анализ инцидентов и обогащение контекстом. Поэтому важна сама реализация подхода; оптимизированные и легко масштабируемые решения, такие как KUMA, будут отвоёвывать рынок.

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

Достоинства:

• RESTful API, возможность интеграции с IRP и SOAR.
• Интеграция с ГосСОПКА.
• Поддержка мультиарендности.
• Экосистемность: функциональные интеграции с другими решениями Kaspersky.
• Автоматизация рутинных действий по реагированию, инвентаризации хостов, обогащению ИБ-событий контекстом.
• Производительность, горизонтальная масштабируемость, управление из единой консоли, поддержка географически распределённой инсталляции и режим высокой доступности (high availability).
• Нативная поддержка Linux всеми компонентами KUMA.
• Сертификация ФСТЭК России.

Недостатки:

• Нет возможности создавать PDF-отчёты (только HTML) — добавление запланировано на первую половину 2022 года.
• Нет интеграции с Hadoop (поддержка запланирована на вторую половину 2022 года).
• Обновление контента (правил корреляции, коннекторов к источникам логов) производится вручную — поддержка автообновления запланирована на вторую половину 2022 года.