О программе Kaspersky Unified Monitoring and Analysis Platform

Kaspersky Unified Monitoring and Analysis Platform (далее KUMA или "программа") – это комплексное программное решение, сочетающее в себе следующие функциональные возможности:

• получение, обработка и хранение событий информационной безопасности;
• анализ и корреляция поступающих данных;
• поиск по полученным событиям;
• создание уведомлений о выявлении признаков угроз информационной безопасности.

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

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

Что нового

В Kaspersky Unified Monitoring and Analysis Platform появились следующие возможности и доработки:

• Добавлена поддержка следующих операционных систем:
  • Oracle Linux 9.2.
  • Astra Linux 1.7.4.
• Написание условий фильтров и корреляционных правил в виде кода.

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

  • Конструктор позволяет написать условия при помощи клавиатуры. Вы можете начать набирать условия фильтра и KUMA подскажет подходящие варианты из полей событий "e:", словарей "d:", активных листов "a:" и других, после чего вы можете выбрать подходящий вариант. Можно сократить диапазон вариантов, набрав соответствующий префикс, например "e:SourceAddress". При этом типы условий выделяются разными цветами.
  • Режим кода позволяет быстро редактировать условия, выделять, копировать блоки кода и таким образом переносить условия фильтров или селекторов между фильтрами и правилами корреляции. Для связанных ресурсов автоматически указывается идентификатор. Поля с наименованиями и идентификаторами связанных ресурсов недоступны для редактирования.
• Расширение схемы событий.

  В KUMA 3.0.3 основной технологией для схемы событий остается CEF, при этом появляется возможность создавать пользовательские поля. Использование этой функциональности позволяет реализовать произвольную таксономию. Привычные для пользователей наименования полей сокращают время на написания поисковых запросов. Пользовательские поля типизированы и должны начинаться с префикса, определяющего его тип: S – строковые, N – числовые, F – числа с плавающей точкой; а также массивы: SA – массив строк, NA – массив чисел, FA – массив чисел с плавающей точкой. Использование полей с массивами возможно только в нормализаторах типа JSON и KV.

• Автоматическое распознавание источника событий.

  Нормализация событий теперь доступна в следующих вариантах:

  • 1 коллектор – 1 нормализатор.

    Мы рекомендуем использовать этот способ, если у вас много событий одного типа или много IP-адресов, откуда могут приходить события одного типа. Можно настроить один коллектор только с одним нормализатором и это будет оптимально с точки зрения производительности.

  • 1 коллектор – несколько нормализаторов с привязкой к IP.

    Этот способ доступен для коллекторов с коннектором типа UDP, TCP, HTTP. Если в коллекторе на шаге Транспорт указан коннектор UDP, TCP, HTTP, на шаге Парсинг событий на вкладке Настройки парсинга вы можете задать несколько IP-адресов и указать, какой нормализатор использовать для событий, поступающих с заданных адресов. Доступны следующие типы нормализаторов: JSON, CEF, regexp, Syslog, CSV, KV, XML. Для нормализаторов типа Syslog и regexp вы можете задать дополнительные условия нормализации в зависимости от значения поля DeviceProcessName.

• Привязка коррелятора из раздела со списком правил.

  Публикация правил корреляции на корреляторах теперь доступна из меню правил корреляции. Реализована возможность выбрать одно или несколько правил и привязать их к одному или нескольким корреляторам. Список корреляторов представлен в виде древовидной структуры ресурсов-корреляторов. Работая с правилами корреляции Общего тенанта, аналитик может опубликовать правила на корреляторах сразу всех доступных ему тенантов.

• Использование контекстных таблиц.

  В коррелятор добавлена новая сущность – контекстные таблицы. Работа с контекстными таблицами аналогична работе с активными листами. Функциональные возможности контекстных таблиц:

  • список ключевых полей определяется пользователем;
  • данные в контекстных таблицах типизированы (целые числа, числа с плавающей точкой, строки, логический тип, timestamp, IP);
  • поддерживаются массивы для всех типов данных, перечисленных выше;
  • поля контекстных таблиц, содержащие массивы, можно использовать в правилах корреляции: возможен подсчет уникальных значений, вычисление длины массива, обращение к определенному элементу массива.
• Добавлены функции "index_of" и "last_index_of".

  Функции возвращают позицию искомого символа в строке. Использований функции "index_of" и "last_index_of" вместе с функцией "substring" позволяет отказаться от использования регулярных выражений в правилах корреляции для получения подстроки. Использование этих функций вместо регулярных выражений позволяет снизить нагрузку на коррелятор.

• Коннектор kata/edr для телеметрии с хостов KEDR.

  В KUMA доступно получение событий KEDR с помощью коннектора kata/edr. Отличие от коннектора kafka заключается в том, что коннектор kata/edr позволяет интегрироваться с KATA версии 5.1, настройка происходит быстрее и удобнее. C помощью параметров коллектора и фильтра вы можете уточнить запрос: сколько событий в одном запросе вы хотите получать, какие события и с какой периодичностью вы хотите получать.

• Архивирование и удаление активов.

  Активы, импортированные из KSC или KICS for Networks, но агенты которых более не подключаются к KSC или KICS, в KUMA отмечаются как архивные и по истечении заданного пользователем периода, могут быть удалены.

• В активах в поле FQDN может быть представлен массив значений.
• Для отправки событий во внешний источник добавлен формат CEF.
• Импорт данных об активах из MaxPatrol VM.

  В поставку KUMA входит утилита kuma-ptvm, которая состоит из исполняемого файла и файла конфигурации. Поддерживается работа под управлением ОС Windows и Linux. Утилита позволяет выполнить подключение к API MaxPatrol VM и получить данные об устройствах и их атрибутах, включая уязвимости, а также позволяет отредактировать данные об активах и импортировать данные с использованием API KUMA.

• Предустановленные макеты для основных B2B-продуктов "Лаборатории Касперского" (KATA, KSС, KSMG, KWTS) позволяют визуализировать данные, как только подключены соответствующие источники событий.
• Иерархическая структура больше не поддерживается. При обновлении с версии 2.1.3 до 3.0.x все хосты с KUMA становятся независимыми.
• Доступна отправка тестовых событий.
• Реализована поддержка интеграции с Telegram, UserGate, KWTS, KSMG, RedCheck.
• Журналы: при обновлении с 2.1.3 до 3.0.3 старые журналы Ядра будут сохранены и появятся новые журналы Ядра. После обновления список журналов будет выглядеть следующим образом:
  • /opt/kaspersky/kuma/core/log/core – журналы 2.1.3.
  • /opt/kaspersky/kuma/core/log/stdout.log – журналы 3.0.3, перенаправляется стандартный вывод сервиса.
  • /opt/kaspersky/kuma/core/log/stderr.log – журналы 3.0.3, перенаправляется стандартный вывод сервиса об ошибках.
• Изменена ролевая модель доступа.

  В KUMA 3.0.3 добавлены следующие изменения:

  • Администратор → Администратор тенанта: теперь может удалять предустановленные шаблоны отчетов и предустановленные макеты панели мониторинга.
  • Аналитик → Аналитик второго уровня: теперь может просматривать и формировать все отчеты, свои и других пользователей, при условии что для этой роли доступны все тенанты, указанные в шаблоне отчета. Может изменять предустановленные шаблоны, может изменять параметры формирования предустановленных отчетов, может удалять предустановленные шаблоны отчетов и предустановленные макеты панели мониторинга.
  • Аналитик первой линии → Аналитик первого уровня: теперь может просматривать и формировать все отчеты, свои и других пользователей, при условии что для этой роли доступны все тенанты, указанные в шаблоне отчета.
  • Оператор → Младший аналитик.
  • Добавлены роли Доступ к общим ресурсам, Работа с НКЦКИ и Работа с КИИ.
  • При перезапуске сервиса kuma-core.service предустановленные шаблоны отчетов и макетов панели мониторинга будут восстановлены в исходном виде, если прежде были удалены.
  • Указание адреса электронной почты пользователя в шаблоне больше не является основанием для предоставления доступа к отчету, сформированному из шаблона. Отчет будет доступен пользователю для просмотра, если для роли пользователя доступны все тенанты, указанные в шаблоне.
• Добавлены нормализаторы для источников событий.
• В разделе справки Приложения представлен перечень устаревших ресурсов KUMA и вариант их замены.
• Устранены ошибки прошлых версий.

Комплект поставки

В комплект поставки входят следующие файлы:

• kuma-ansible-installer-<номер сборки>.tar.gz – используется для установки компонентов KUMA без возможности развертывания в отказоустойчивой конфигурации;
• kuma-ansible-installer-ha-<номер сборки>.tar.gz – используется для установки компонентов KUMA с возможностью развертывания в отказоустойчивой конфигурации;
• файлы с информацией о версии (примечания к выпуску) на русском и английском языках.

Аппаратные и программные требования

Рекомендуемые требования к оборудованию

В этом разделе приведены требования к оборудованию для обработки различных вариантов потока событий в секунду (Events per Second, далее EPS), поступающих в KUMA.

В таблице ниже приведены аппаратные и программные требования к оборудованию для установки компонентов KUMA. Конфигурацию оборудования необходимо подбирать исходя из профиля нагрузки системы. Допустимо использовать конфигурацию типа «All-in-one» при обрабатываемом потоке событий до 10 000 EPS и при использовании графических панелей, поставляемых с системой.

KUMA поддерживает работу с процессорами Intel или AMD с поддержкой набора инструкций SSE 4.2.

В зависимости от количества и сложности запросов к БД, выполняемых пользователями, отчётами, панелями мониторинга объём необходимых ресурсов может быть увеличен.

На каждые 50 000 (сверх 50 000) активов необходимо добавить к ресурсам компонента Ядро 2 дополнительных потока или vCPU и 4 ГБ оперативной памяти.

На каждые 100 (сверх 100) сервисов, которыми управляет компонент Ядро необходимо добавить к ресурсам компонента Ядро 2 дополнительных потока или vCPU.

Необходимо размещать ClickHouse на твердотельных накопителях (англ. solid state drive, далее - SSD). Использование SSD позволяет повысить скорость доступа к данным.

* - если профиль использования системы не предполагает выполнения агрегационных SQL-запросов с большой глубиной к Хранилищу, допускается использовать дисковые массивы на базе HDD.

Для размещения данных с использованием технологии HDFS могут быть использованы жесткие диски.

Экспорт событий записывается на диск компонента Ядро во временную папку /opt/kaspersky/kuma/core/tmp/. Экспортированные данные хранятся в течение 10 суток, затем автоматически удаляются. Если вы планируете экспортировать большой объём событий, необходимо выделить дополнительное место.

Работа в виртуальных средах

Поддерживается установка KUMA в следующих виртуальных средах:

• VMware 6.5 и выше.
• Hyper-V для Windows Server 2012 R2 и выше.
• QEMU-KVM 4.2 и выше.
• ПК СВ "Брест" РДЦП.10001-02.

Рекомендации касательно ресурсов для компонента Коллектор

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

Также необходимо иметь в виду, что количество потребляемой коллектором оперативной памяти зависит от настроенных методов обогащения (DNS, учетные записи, активы, обогащение данными из Kaspersky CyberTrace) и использования агрегации (на потребление оперативной памяти влияет параметр окна агрегации данных, количество полей, по которым выполняется агрегация данных, объём данных в агрегируемых полях). Показатели использования KUMA вычислительных ресурсов зависят от типа анализируемых событий и от эффективности нормализатора.

Например, при потоке событий 1000 EPS и выключенном обогащении событий (обогащение событий выключено, агрегация событий выключена, 5000 учетных записей, 5000 активов в тенанте) одному коллектору требуются следующие ресурсы:

• 1 процессорное ядро или 1 виртуальный процессор;

• 512 МБ оперативной памяти;

• 1 ГБ дискового пространства (без учёта кэша событий).

Например, для 5 коллекторов, которые не выполняют обогащение событий потребуется выделить следующие ресурсы: 5 процессорных ядер, 2,5 ГБ оперативной памяти и 5 ГБ свободного дискового пространства.

Рекомендации экспертов "Лаборатории Касперского" для серверов хранилищ

Для подключения системы хранения данных (далее СХД) к серверам хранилища следует использовать высокоскоростные протоколы, например Fibre Channel или iSCSI 10G. Для подключения СХД не рекомендуется использовать протоколы прикладного уровня, такие как NFS и SMB.

На серверах кластера ClickHouse рекомендуется использовать файловую систему ext4.

При использовании RAID-массивов рекомендуется использовать RAID 0 для достижения высокой производительности, а RAID 10 для обеспечения высокой производительности и отказоустойчивости.

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

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

Для высоконагруженных инсталляций KUMA рекомендуется устанавливать ClickHouse на аппаратных серверах.

Требования к устройствам для установки агентов

Для передачи данных в коллектор KUMA на устройствах сетевой инфраструктуры требуется установить агенты. Требования к устройствам приведены в таблице ниже.

Требования к клиентским устройствам для работы с веб-интерфейсом KUMA

Процессор: Intel Core i3 8-го поколения.

ОЗУ: 8 ГБ.

Поддерживаемые браузеры:

• Google Chrome 110 и выше.
• Mozilla Firefox 110 и выше.

Требования к устройствам для установки KUMA в Kubernetes

Кластер Kubernetes для развертывания KUMA в отказоустойчивом варианте включает в минимальной конфигурации:

• 1 узел балансировщика – не входит в кластер;
• 3 узла-контроллера;
• 2 рабочих узла.

Минимальные аппаратные требования к устройствам для установки KUMA в Kubernetes представлены в таблице ниже.

Интерфейс KUMA

Работа с программой осуществляется через веб-интерфейс.

Окно веб-интерфейса программы содержит следующие элементы:

• разделы в левой части окна веб-интерфейса программы;
• вкладки в верхней части окна веб-интерфейса программы для некоторых разделов программы;
• рабочую область в нижней части окна веб-интерфейса программы.

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

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

• во всех разделах: закрывать окно, открывающееся в правой боковой панели – Esc;
• в разделе События:
  • переключаться между событиями в правой боковой панели – ↑ и ↓;
  • запускать поиск (при фокусе на поле запроса) – Ctrl/Command + Enter;
  • сохранять поисковый запрос – Ctrl/Command + S.

Совместимость с другими программами

Kaspersky Endpoint Security для Linux

При установке на одном сервере компонентов KUMA и программы Kaspersky Endpoint Security для Linux каталог report.db может достигать больших размеров и занимать все дисковое пространство. Кроме того, Kaspersky Endpoint Security для Linux по умолчанию сканирует все файлы KUMA, включая служебные, что может влиять на производительность. Чтобы избежать этих проблем, выполните следующие действия:

• Обновите программу Kaspersky Endpoint Security для Linux до версии 12.0 или выше.
• Мы не рекомендуем включать сетевые компоненты Kaspersky Endpoint Security для Linux.
• Добавьте в общие исключения и в исключения для проверки по требованию следующие директории:
  1. На сервере Ядра KUMA:
     • /opt/kaspersky/kuma/victoria-metrics/ - папка с данными Victoria Metrics.
     • /opt/kaspersky/kuma/mongodb - папка с данными MongoDB.
  2. На сервере хранилища:
     • /opt/kaspersky/kuma/clickhouse/ - папка ClickHouse.
     • /opt/kaspersky/kuma/storage/<идентификатор хранилища>/buffers/ - папка с буферами хранилища.
  3. На сервере коррелятора:
     • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/data/ - папки со словарями.
     • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/lists - папки с активными листами.
     • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/ctxtables - папки с контекстными таблицами.
     • /opt/kaspersky/kuma/correlator/<идентификатор коррелятора>/buffers - папка с буферами.
  4. На сервере коллекторов:
     • /opt/kaspersky/kuma/collector/<идентификатор коллектора>/buffets - папка с буферами.
     • /opt/kaspersky/kuma/collector/<идентификатор коллектора>/data/ - папка со словарями.
  5. Папки с журналами для каждого сервиса.

Подробнее об исключениях из проверки см. онлайн-справку Kaspersky Endpoint Security для Linux.