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

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

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

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

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

Что нового

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

Изменено место хранения самоподписанного CA-сертификата и механизм перевыпуска сертификата.
Сертификат хранится в СУБД. Недопустимо применять прежний метод перевыпуска внутренних сертификатов через удаление сертификатов из файловой системы Ядра и перезапуск Ядра. Такой способ приведет к невозможности запустить Ядра. До завершения процесса перевыпуска сертификатов не следует подключать к Ядру новые сервисы.
После того как вы перевыпустите внутренние CA-сертификаты в разделе веб-интерфейса KUMA Параметры → Общие → Перевыпустить внутренние CA-сертификаты, необходимо остановить сервисы, удалить прежние сертификаты из директорий сервисов и вручную перезапустить все сервисы. Перевыпускать внутренние CA-сертификаты могут только пользователи с ролью Главный администратор.

• Добавлена поддержка работы KUMA на следующих операционных системах:
  • Ubuntu 22.04 LTS.
  • Oracle Linux 9.4.
  • Astra Linux 1.7.5.
  • РЕД ОС 7, 8.
• Начиная с версии 3.2.x, обновлены требования к сложности пароля. Пароль должен быть длиной не менее 16 символов, содержать не менее одной буквы и цифры, и должен содержать не более двух одинаковых символов подряд. Новые требования применяются только к новым установкам. В существующих установках KUMA требования применяются только к новым пользователям. Для существующих пользователей требования будут применены только при смене пароля.
• В веб-консоли KUMA в разделе Активные сервисы сервис Ядра отображается как core-1. В операционной системе сервера Ядра сервис kuma-core.service теперь называется kuma-core 00000000-0000-0000-0000-000000000000.service.
• Добавлен сервис Маршрутизатор событий. Этот сервис позволяет принимать события от коллекторов и направлять события в заданные точки назначения в соответствии с настроенными на сервисе фильтрами. Использование такого промежуточного сервиса позволяет эффективно распределять нагрузку на каналы связи и использовать каналы связи с невысокой пропускной способностью. Например, как показано на схеме в раскрывающемся блоке, вместо нескольких потоков событий от коллектора 5 до точек назначения, вы можете отправлять события одним потоком: на схеме коллектор 1 + коллектор 2 + коллектор 3 отправляют события в маршрутизатор локального офиса, затем в маршрутизатор дата-центра, и в нем уже происходит передача событий в заданные точки назначения.

  Схема отправки событий с использованием маршрутизатора событий и без использования маршрутизатора

  

• Интеграция с НКЦКИ: обновлен список полей и типы инцидентов, добавлена возможность предоставления информации об утечке персональных данных. Экспортированые инциденты со старым типом, который больше не поддерживается, будут отображаться корректно.
• Выполнение группировки по произвольным полям, использование функций округления времени из интерфейса работы с событиями.

  При проведении расследования аналитику требуется находить выборки с событиями, строить агрегационные запросы. Теперь для выполнения запросов с агрегацией, достаточно выбрать одно или несколько полей, по которым следует выполнить группировку и запустить Выполнить запрос. Для полей типа Date доступны агрегационные запросы с округлением времени.

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

• Добавлена возможность преобразования исходного поля с использованием функции вычисления информационной энтропии. В коллекторе можно настроить правило обогащения для исходного поля типа event, выбрать тип преобразования entropy и указать целевое поле типа float, куда KUMA поместит результат преобразования. Результатом преобразования будет число. Показатель вычисления информационной энтропии позволяет выявлять DNS-туннели, компрометацию паролей, например, когда пользователь ввел пароль вместо логина и этот пароль записывается в журнал в открытом виде. Обычно логин содержит буквы, и функция преобразования вычислит информационную энтропию и запишет результат, например, 2,5416789. Если пользователь по ошибке ввел пароль в поле для логина и таким образом пароль оказался в журнале в открытом виде, KUMA вычислит информационную энтропию и запишет результат 4 - показатель энтропии будет выше, поскольку пароль содержит буквы, цифры и символы. Таким образом, можно искать события, где у имени пользователя показатель энтропии больше 3 и можно настроить правило реагирования "Требуется смена пароля". После настройки в коллекторе обогащения следует обновить параметры, чтобы применить изменения.
• Доступен поиск событий одновременно по нескольким выбранным хранилищам с помощью простого запроса. Например, таким образом вы можете выполнять поиск событий, чтобы определить, где учетная запись блокируется или на какой URL с каких IP-адресов был выполнен вход.

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

• Покрытие матрицы правил на MITRE ATT&CK.

  Разрабатывая детектирующую логику, аналитик может ориентироваться на соответствие контента реальным угрозам. С помощью матриц MITRE ATT&CK можно определить, к каким техникам уязвимы ресурсы организации. В помощь аналитикам создан механизм, который позволяет визуализировать покрытие матрицы MITRE ATT&CK разработанными правилами и таким образом оценить уровень защищенности.

  Функционал позволяет:

  • Импортировать в KUMA актуальный файл с перечнем техник и тактик.
  • Перечислить в свойствах правил техники и тактики, выявляемые этим правилом.
  • Экспортировать из KUMA список правил, размеченных по матрице в MITRE ATT&CK Navigator (можно указать отдельные папки с правилами).

  Файл со списком размеченных правил визуализируется в MITRE ATT&CK Navigator.

• Чтение файлов агентом Windows.

  Агент KUMA, устанавливаемый на системах c ОС Windows, теперь может читать текстовые файлы и передавать данные в коллектор KUMA. Один агент, установленный на сервере с ОС Windows, может передавать данные как из журналов Windows, так и из текстовых файлов с журналами. Например, больше не потребуется использовать сетевые папки для получения журналов транспорта Exchange Server, или журналов IIS.

• Получение журналов DNS Analytics с использованием коннектора etw.

  Использование Windows агентом нового транспорта ETW (сервис Event Tracing for Windows) для чтения подписки DNS Analytics обеспечивает получение расширенного журнала DNS, событий диагностики, аналитических данных о работе DNS-сервера – больше информации, чем в журнале отладки DNS, и с меньшим влиянием на производительность DNS-сервера.

  Рекомендуемая конфигурация для чтения журналов ETW:

  • Если на сервере, который является источником журналов DNS Analytics, не установлен никакой агент, создать новый коллектор и новый агент:
    1. Создать коннектор etw. Агент будет создан автоматически.
    2. Создать отдельный коллектор для журналов ETW. В мастере установки коллектора указать коннектор etw, указать нормализатор [OOTB] Microsoft DNS ETW logs json.
    3. Установить коллектор и агент.
  • Если на сервере, который является источником журналов DNS Analytics, уже установлен агент WEC, создать коллектор и отредактировать параметры созданного вручную агента:
    1. Создать коллектор с транспортом http и разделителем \0, и указать нормализатор [OOTB] Microsoft DNS ETW logs json.
    2. Сохранить параметры коллектора.
    3. Установить коллектор.
    4. В существующем агенте WEC добавить дополнительную конфигурацию ETW и в ней указать:
       • коннектор etw
       • в качестве точки назначения указать созданный в пункте a. коллектор
       • выбрать тип точки назначения http и разделитель \0.
    5. Сохранить параметры агента и запустить агент.
• Обогащение CyberTrace по API.

  Cybertrace-http — новый тип потокового обогащения событий в CyberTrace, который позволяет отправлять большое количество событий одним запросом на API-интерфейс CyberTrace. Мы рекомендуем применять этот тип обогащения в системах с большим потоком событий. Производительность cybertrace-http значительно превосходит показатели прежнего типа cybertrace, который по-прежнему доступен в KUMA для обеспечения обратной совместимости.

• Активация с помощью кода.

  Реализована возможность активировать KUMA при помощи кода активации. Такой метод позволяет не беспокоиться об импорте в KUMA новых ключей при продлении или при изменении состава лицензии. Для активации с помощью кода требуется доступ сервера Ядра к нескольким серверам в интернете. При этом вы можете использовать прежний метод активации - с использованием файла лицензии.

• Оптимизирована передача событий в формате CEF. Отправляемые события содержат заголовок CEF и только непустые поля. При передаче событий в сторонние системы в формате CEF поля, не содержащие данных, не передаются.
• Добавлена возможность получения событий из ClickHouse с помощью коннектора SQL. В параметрах коннектора SQL вы можете выбрать Тип базы данных для соединения. При этом в поле URL будет автоматически указан префикс, соответствующий протоколу взаимодействия.
• В коннекторы file, 1c-log и 1c-xml добавлен параметр Интервал запросов, мс, отвечающий за интервал чтения файлов из директории. Настройка этого параметра позволяет снизить потребление CPU и RAM.
• Параметр airgap исключен из файла инвентаря. Если в вашем файле инвентаря остался параметр airgap, установщик его проигнорирует при выполнении установки или обновления.
• Логин и пароль вынесены из секрета типа URL и Proxy. Добавлена возможность преобразования пароля.
• В служебные события о выпадении записи из активного листа и контекстной таблицы добавлены поля, которые содержат не только ключ, но и значение. Поля со значениями дают больше гибкости в написании правил корреляции для обработки таких служебных событий.

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

  Когда запись устаревает, внутри коррелятора формируется событие, которое "заворачивается" на вход коррелятора. Это событие не отправляется в хранилище.

  Если настроено соответствующее правило корреляции, то по этому событию можно создать корреляционное событие и алерт. Такое корреляционное событие уже отправляется в хранилище и отображается в разделе События.

• Добавлена возможность мониторинга сервисов.

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

• Обновлен перечень статусов для сервисов: добавлен фиолетовый статус, расширено пременение желтого статуса.
• Теперь вы можете перейти из раздела Состояние источников к событиям выбранного источника событий. Уточняющие условия в строке поискового запроса формируются автоматически после перехода по ссылке. По умолчанию отображаются события за последние 5 минут. При необходимости вы можете изменить интервал и снова выполнить запрос.
• Сбор метрик с агента.

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

• Добавлена поддержка компактной встраиваемой СУБД SQLite версии 3.37.2.
• Добавлен коннектор elastic для получения событий из Elasticsearch версии 7 и 8. Для коннектора добавлен секрет fingerprint.
• Для коннекторов с типами tcp, udp и file добавлены следующие параметры обработки событий auditd:
  • Переключатель Auditd позволяет группировать полученные от коннектора строки событий auditd в одно событие auditd.
  • Поле TTL буфера событий позволяет указать время жизни буфера для строк событий auditd в миллисекундах.
• Добавлена возможность настраивать список полей для определения источников событий. DeviceProduct, DeviceHostName, DeviceAddress, DeviceProcessName – используемый по умолчанию набор полей для определения источников событий. Теперь перечень полей и их последовательность можно переопределить. Допускается указать максимум 9 полей в значимой для пользователей последовательности. После сохранения изменений в наборе полей ранее определенные источники событий будут удалены из веб-интерфейса KUMA и из базы данных. Сохраняется возможность использовать набор полей для определения источников событий по умолчанию.
• В графический конструктор поисковых запросов для событий добавлен оператор iLike.
• Обновлен перечень методов REST API. Описание методов v2.1 доступно в формате OpenAPI.
• В параметрах коннектора snmp-trap появился дополнительный параметр, позволяющий обозначить OID, являющийся MAC-адресом.
• Установщик KUMA проверяет состояние SELinux.
• Прекращена поддержка создания резервной копии Ядра при помощи утилиты командной строки /opt/kaspersky/kuma/kuma tools backup.
• Прекращена поддержка и поставка устаревших нормализаторов:
  • [Deprecated][OOTB] Microsoft SQL Server xml.
  • [Deprecated][OOTB] Windows Basic.
  • [Deprecated][OOTB] Windows Extended v.0.3.
  • [Deprecated][OOTB] Cisco ASA Extended v 0.1.
  • [Deprecated][OOTB] Cisco Basic.

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

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

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

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

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

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

В таблице ниже приведены аппаратные и программные требования к оборудованию для установки компонентов KUMA, исходя из представления, что кластер ClickHouse принимает только запросы INSERT. Требования к оборудованию для удовлетворения потребностей по запросам SELECT рассчитывается отдельно под конкретный профиль использования СУБД заказчика.

Рекомендуемые требования к оборудованию для хранилищ кластера ClickHouse

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

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

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

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

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

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

* - если профиль использования системы не предполагает выполнения агрегационных SQL-запросов к Хранилищу с глубиной больше 24 часов, допускается использовать дисковые массивы на базе HDD (HDD 15 000 RPM, интерфейс SAS, объединенные в RAID-10).

Для размещения данных с использованием технологии 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.