Интеграции

• Обогащение
• LDAP-обогащение
• GeoIP-обогащение (Геоданными)
• Интеграция CyberTrace с KUMA
• DNS-обогащение
• Обогащение событий информацией об Активах
• Обогащение произвольного поля с утилитой Tracer
• Реагирование
• Описание готовых интеграций по реагированию
• Запуск скрипта коррелятором
• Настройка автоматического реагирования KUMA с помощью задач KSC
• Блокировка адресов при помощи Cisco ASA Firewall на основе сработок алертов
• Отправка уведомления в телеграм-бот
• Реагирование на BIFIT Mitigator
• Отправка уведомления в телеграм-бот со ссылкой на KATA и KUMA
• Интеграция по реагированию KUMA и KEDR
• Реагирование на KICS Networks с помощью скрипта
• Сканеры уязвимостей
• Nessus и OWASP ZAP
• Импорт информации об активах RedCheck
• Импорт данных из отчетов MaxPatrol в KUMA 3.2
• Импорт данных об активах из MaxPatrol VM
• KSC
• Интеграция KUMA с KSC
• KSC: увеличение лимита экспорта событий в SIEM (Syslog/CEF)
• Монтирование папки в KUMA
• Интеграция с Kaspersky MDR
• Интеграция Grafana c ClickHouse в KUMA
• Интеграция KUMA с Active Directory (AD)
• Выгрузка LDAP информации в словарь KUMA
• Интеграция с ГосСОПКА
• Автоматическое добавление активов
• Создание TAA-алертов в KUMA с KATA

Обогащение

LDAP-обогащение

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217926.htm 

Настройка параметров подключения к LDAP-серверу

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

Перейдите на вкладку Параметры – LDAP-сервер и нажмите на кнопку Добавить параметры для нового тенанта.

В открывшемся окне выберите Тенант, укажите Интервал обновления в часах и задайте Время хранения данных. Затем нажмите на кнопку Добавить подключение.

В открывшейся вкладке задайте параметры подключения к LDAP-серверу:

1. Укажите Название подключения
2. В поле Секрет добавьте учетную запись пользователя для подключения к серверу Active Directory. Имя пользователя может быть указано в одном из двух форматов: <user>@<domain> или <domain>\<user>
3. В поле URL укажите адрес одного или нескольких серверов LDAP (через запятую) в формате <hostname или IP-адрес сервера>:<порт>. Для незащищенного и startTLS подключения порт по умолчанию 389, для ssl – 636. В случае использования startTLS или ssl необходимо указывать hostname сервера, если сертификат сервера в поле SAN не содержит IP-адреса сервера.
4. Выберите Тип подключения.
5. Если на прошлом шаге был выбран тип ssl или startTLS, добавьте сертификат для проверки подлинности сервера в поле Сертификат. В случае, если для DC используется не самоподписанный сертификат, необходимо импортировать сертификат корневого центра сертификации.
6. Важно! Сертификат самого DC должен содержать параметр DNS Name в поле SAN, соответствующий доменному имени данного сервера (если в URL был указан hostname сервера) или параметр IP Address в поле SAN, соответствующий IP-адресу данного сервера (если в URL был указан IP-адрес сервера).
7. Задайте Время ожидания в секундах – период, в течение которого KUMA будет ожидать ответа от сервера контроллера домена.
8. В поле База поиска (Base DN) укажите базовое отличительное имя каталога, в котором должен выполняться поисковой запрос.
9. При необходимости укажите Пользовательские атрибуты учетных записей AD, на основе которых вы хотите обогащать события учетными записями.
10. Убедитесь, что галочка для пункта Выключено снята и нажмите на кнопку Сохранить для сохранения параметров подключения к 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})"

В результате выполнения команды будет выведен домен:

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-имя домена в формате ^<NetBIOS-имя>$. В правой части, в графе чем заменить укажите DNS-имя домена. Нажмите кнопку ОК.

Выполните аналогичные действия для поля DestinationNtDomain.

Сохраните нормализатор и выполните Обновление параметров сервиса для сервиса коллектора Windows.

Проверка работы LDAP-обогащения

Для проверки работы обогащения перейдите на вкладку События и выполните поисковой запрос:

SELECT * FROM `events` WHERE SourceAccountID !='' OR DestinationAccountID!='' ORDER BY Timestamp DESC LIMIT 250

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

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

GeoIP-обогащение (Геоданными)

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/233257.htm 

Скачанная и конвертированная база (IP2Location) - https://box.kaspersky.com/f/b961a874400a4a0ab66b/ 

Российская база (требуется регистрация) - https://geoip.noc.gov.ru/ 

Скачивание БД

IP2Location

MAXMIND

Конвертация БД

python converter.py --type ip2location --input IP2LOCATION-LITE-DB11.CSV.ZIP --out geoip_ip2location.csv

Загрузка БД в KUMA

При импорте нового файла с данными GeoIP ранее добавленные данные перезапишутся (с созданием события аудита). Поэтому если нужно внести незначительные изменения для кастомизации сопоставления рекомендуется скачать текущую БД из интерфейса KUMA, после чего внести туда изменения и подгрузить обратно.

Обогащение GeoIP

Формат файла 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://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://<IP_or_Hostname>, УЗ по умолчанию admin / CyberTrace!1

Отключите фаервол на ОС или откройте доступ до нужных портов для работы CyberTrace 

Настройка на стороне CyberTrace

Вход в CyberTrace по: https://<IP_or_Hostname>, пароль по умолчанию: admin / CyberTrace!1

При первом входе после установки CyberTrace появится окно мастера первоначальной настройки (Initial Setup Wizard), в котором необходимо:

• Выбрать используемую SIEM-систему: в данном примере это KUMA
• Указать параметры подключения для используемой SIEM-системы: IP-адрес интерфейса сервера CyberTrace. В последнем поле указать IP-адрес интерфейса или Hostname сервера CyberTrace.

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

Для завершения первоначальной настройки нажать Close.

После завершения первоначальной настройки рекомендуется изменить пароль администратора, используемый по умолчанию.

Проверить успешность загрузки индикаторов компрометации можно следующим способом:

1. Перейдите во вкладку Indicators и убедитесь в наличии индикаторов компрометации
2. Перейдите во вкладку Dashboard -> виджет Supplier statistics и проверьте, что столбец Indicators для каждого фида отличен от 0.

Настройка на стороне KUMA

Начиная с версии 3.2 в KUMA доступно 2 метода интеграции с CyberTrace для потокового обогащения событий данными об индикаторах компрометации:

1. С использованием API CyberTrace
2. С помощью Kaspersky CyberTrace Service

Интеграция с использованием API CyberTrace

Данный метод позволяет отправлять большое количество объектов одним запросом на API-интерфейс CyberTrace. Рекомендуется применять в системах с большим потоком событий. Производительность С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 - <IP-адрес/FQDN сервера CyberTrace>: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 рекомендуется использовать фильтр на правиле обогащении, пример фильтра из пресейл пака: https://box.kaspersky.com/f/39a48398202543dbb9c9/ 

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

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

Проверка работы интеграции CyberTrace с KUMA

Подразумевается, что настроена интеграция событий с KSC на KUMA, на хосте, где будет проводиться тест установлен KES с последними обновлениями. Иначе используйте другие системы, с которыми осуществлена интеграция по событиям.

В CyberTrace в разделе Индикаторы, скопируйте любой URL из списка содержимых.

С хоста, где установлен KES осуществите переход в браузере по ссылке, например - http://www.kasprsky.com/test/wmuf и получите "отбивку" от KES. Через некоторое время появится событие от KSC. В событии будет обращение по вредоносной ссылке с дополнительным контекстом от CyberTrace, пример ниже:

Количество обнаружений на основе объектов, полученных от KUMA, можно увидеть в дашборде статистики на CyberTrace:

В качестве упрощенного варианта проверки корректной работы обогащения CyberTrace можно отправить тестовое событие в коллектор с помощью утилиты netcat или утилиты kuma. В примере ниже используется тестовое событие в формате CEF, отправленное средствами netcat.

Для коллектора с транспортом TCP:
nc <IP-адрес> <порт> <<< 'CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|request=<любой URL из вкладки Indicators CyberTrace>'

Для коллектора с транспортом UDP:
nc -u <IP-адрес> <порт> <<< '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/2.1/ru-RU/217863.htm

Обогащение DNS

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

• DestinationAddress -> DestinationHostName
• DeviceAddress -> DeviceHostName
• SourceAddress -> SourceHostName

Важный момент, DNS обогащение работает только для серых сетей

Поле настройки URL - не обязательно. Если оставить пустым, то при обогащении будут использоваться системные настройки сервера. Соответственно, если DNS в ОС серверов коллекторов разные - то и обогащение будет разное

Настройка на стороне KUMA

Для повышения прозводительности, можно изменять число рабочих процессов коллектора (1 шаг настройки) / самого правила обогащения (для асинхронных задач эффективнее работа)

В разделе Ресурсы - Правила Обогащения создаем новое правило, ниже пример типового обогащения для DNS:

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

Обогащение событий информацией об Активах

Активы могут попасть в KUMA следующими способами:

• От KSC (FQDN, IP, MAC, Имя ассета (в KSC, Владелец [Principal name], Информация об уязвимостях, Информация об установленном ПО, Информация о hardware)
• От KICS
• От Vulnerability Scanner: Из коробки: MP8 Scanner, RedCheck.  Через новые PreSalesPack скрипты: Nessus, OWASP ZAP;
• От CMDB выгрузка в виде CSV, затем скриптом через API добавление в KUMA (скрипт в PreSalesPack);
• Вручную

Коллекторы 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.
  

После чего события, обогащенные информацией об ассетах направляются в коррелятор и/или хранилище.

Пример обогащенного события (при нажатии открывается карточка актива):

Правила обогащения информацией об активах

Обогащение произвольного поля с утилитой Tracer

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Утилита (скрипт) была написана для получения возможности обогощать событие по значению поля со сторонних систем с использованием языка программирования Python3. Tracer.py мимикрирует под механизм обогащения аналогично CyberTrace, с обогащенными данными можно работать подобно обогащению Threat Intelligence. Утилита может работать как на Linux (рекомендуется), так и Windows платформах (ОС).

Для продвинутых пользователей! Для работы с Tracer.py требуются навыки программирования Python3

Скрипт можно загрузить по ссылке в Пресейл-Паке контенте.

Необходимые библиотеки для работы Tracer.py:

Для использования TCP_FASTOPEN (рекомендуется) на ОС Linux выполните команду ниже:

echo 3 > /proc/sys/net/ipv4/tcp_fastopen

Предварительные правки для Tracer.py:

На стороне KUMA нужно прописать следующее обогащение:

По картинке выше, обогащается значение поля Code и сопоставляется с полем Tracer - url. Производительность скрипта состовляет ~ 50 EPS, при рекомендуемой настройке Enrichment: 50 connections и 100 RPS.

Возможно использовать только поле url в сопоставлении, но туда можно поместить произвольные данные

При обогащении события получаем следующие обогащенные данные:

Так как используется "нелегальный" механизм обогащения в логах коллектора копятся (периодически очищайте) ошибки следующего вида:

Реагирование

Описание готовых интеграций по реагированию

Весь актуальный и новый контент с описанием добавляется в GitHub - https://github.com/KUMA-Community 

Реагирование из коробки KUMA

Готовые скрипты (описание)

Запуск скрипта коррелятором

Интерпретатор скрипта должен поддерживаться ОС на которой находится скрипт.

Для того чтобы коррелятор мог запускать скрипты.  Зайти по ssh на сервер где находится служба коррелятора и поместите скрипт (можно сделать с помощью WinSCP или любым другим инструментом) в следующую папку коррелятора:

/opt/kaspersky/kuma/correlator/<id>/scripts/

<id> - идентификатор коррелятора, можно найти в веб-интерфейсе (подробнее как это сделать ссылка)

Назначьте пользователя kuma владельцем файла и дайте файлу права на выполнение:

chown kuma:kuma /opt/kaspersky/kuma/correlator/<id>/scripts/my_script.sh
chmod +x /opt/kaspersky/kuma/correlator/<id>/scripts/my_script.sh

В группирующем поле правила корреляции должны находиться целевые поля, которые используются в правилах реагирования, в нашем примере это 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) необходимо:

1. Авторизоваться на ASA с привилегиями, позволяющими переходить в режим конфигурирования, отправить команду
   conf t
2. Создать объект, в который наш скрипт будет добавлять адреса (черный список), назовём его BLACKLIST. Создаём командой 
   object network BLACKLIST
3. На ASA создаём access-list, который будет блокировать входящие сетевые соединения из интернета от IP находящихся в нашем объекте. Пример:
   access-list INTERNET extended deny ip object-group BLACKLIST any
   

Настройка на стороне KUMA

1. В группирующем поле правила корреляции должны находиться целевые поля, которые используются в правилах реагирования, в нашем примере это sourceAddress
2. В "селекторы" и "действия" задаём необходимые в данном кейсе параметры.
   Обязательно добавить обогащение событие EventOutcome (как указано на скриншоте), это ключ (триггер) для следующего этапа по запуску правила реагирования.
   

   

3. Размещаем скрипт (находится в папке пресейл-пака) предварительно заменив ключевые данные в скрипте, а именно:ip asa, login, password с правами, необходимыми для добавления в объект BLACK (см. выше, этап настройки ASA)
4. Скрипт помещаем на сервере(-ах) по пути 
   /opt/kaspersky/kuma/correlator/<id>/scripts/ и предоставляем права пользователю kuma, чтобы служба имела достаточные права для запуска скрипта, командами:
   chown kuma:kuma /opt/kaspersky/kuma/correlator/<id>/scripts/asa.py
chmod +x /opt/kaspersky/kuma/correlator/<id>/scripts/asa.py
   
   

5. Данный этап индивидуален и зависит конкретно от Вашего экземпляра ОС, возможно будут дополнительные ошибки при запуске скрипта, для проверки скрипт можно запускать вручную с сервера и проверять работоспособность

   Также на сервер коррелятора в pip3 необходимо до установить следующие библиотеки, для возможности запуска python3.*
   
   threading
   paramiko
   sys
   argparse
   subprocess
   
   команда:
   pip3 install threading paramiko sys argparse subprocess
   
6. Создаём правило реагирования, которое будет непосредственно запускать скрипт на коллекторе (шаг 4)
   

   

   ключевое, задаём Название скрипта, который мы перенесли на сервер коррелятора (шаг 4), также аргументы скрипта, как на скриншоте и ключевое поле EventOutcome = BLOCK (добавляется при срабатывании алерта, при помощи обогащения) (указано как пример, можно задать списком и другими полями).
7. Осталось привязать новое правило корреляции. Привязываем к коррелятору. 
   Ресурсы -> Корреляторы -> Выбираем наш -> Корреляция, привязать (на скриншоте)
   

   
   

   
   
8. Также необходимо здесь же добавить правило реагирования
   

   

9. Готово, сохраняем и рестартуем коррелятор (ы)

Отправка уведомления в телеграм-бот

Информация, приведенная на данной странице, является разработкой команды 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<token>/sendMessage?chat_id=<chat_id>&text=test

Подставив вместо <token> и <chat_id> значения полученные ранее. В результате в личном чате или группе (в зависимости от выбранного способа) должно появиться уведомление, а в ответе браузера JSON не должен содержать ошибок.

11. После проверки работоспособности бота можно переходить к настройке отправки уведомлений.

Скрипт уведомления

1. Создайте скрипт уведомления

В простейшем виде скрипт отправки уведомления выглядит следующим образом:

#!/bin/bash
set -eu
CHAT_ID=<chat_id из п.8-9 предыдущего раздела>
TG_TOKEN=<token из п.5 предыдущего раздела>
RULE=$1
TEXT="Произошла сработка правила <b>$RULE</b>"
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=<chat_id из п.8-9 предыдущего раздела>
TG_TOKEN=<token из п.5 предыдущего раздела>
RULE=$1
TEXT="Произошла сработка правила <b>$RULE</b>"
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

#!/bin/bash

set -eu

CHAT_ID=<chat_id из п.8-9 предыдущего раздела>
TG_TOKEN=<token из п.5 предыдущего раздела>

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Правило: <b>$NAME</b> %0AВремя: $TIME %0AХост: $HOST"
} || {
#else if can't beautify
    TEXT="⚠️Алерт %0AПравило: <b>$NAME</b> %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/<id>/scripts/

<id> - идентификатор коррелятора, можно найти в веб-интерфейсе (ссылка)

3. Назначьте пользователя kuma владельцем файла и дайте файлу права на выполнение

chown kuma:kuma /opt/kaspersky/kuma/correlator/<id>/scripts/bot.sh
chmod +x /opt/kaspersky/kuma/correlator/<id>/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 доступен под спойлером

#!/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=<id чата>
TG_TOKEN=<токен>
KUMA_ASSETS="https://<KUMA_ADDR>:7220/assets/all?asset="
TEXT="В KATA обнаружен TAA-детект <b>$1</b> на хосте <a href='$KUMA_ASSETS$3'>$2</a>.%0AАлерт KATA доступен по <a href='$4'>ссылке</a>"

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 чата или группы с ботом вместо <id чата>
• TG_TOKEN - токен бота вместо <token>
• KUMA_ASSETS - указать адрес KUMA (FQDN или IP) вместо <KUMA_ADDR>

Поместите скрипт в папку коррелятора, уведомления о сработках которого необходимо отправлять через телеграм-бот

Настройка KUMA

Для реализации предложенного сценария необходимо:

1. Импортировать в систему пакет ресурсов по ссылке

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:

Интеграция завершена.

Логирование работы с 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 в групирующие поля):

Пример сработки правила корреляции:

Далее нужно создать (либо загрузить из Пресейл-Пака) правило реагирование которое будет запускать скрипт из Пресейл-Пака, правило должно выглядеть следующим образом:

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

В результате правило корреляции и реагирование нужно добавить в коррелятор и обновить его параметры. ТАким образом получим, что при перемещении актива в определенную категорию (например Активным способом по подсети), автоматом эти активы будут помечаться недоверенными.

Сканеры уязвимостей

Nessus и OWASP ZAP

В KUMA можно импортировать сведения об активах из отчетов о результатах сканирования устройств с помощью Nessus, OWASPZAP, системы контроля защищенности и соответствия стандартам. Импорт происходит через API с помощью утилиты import_asset_Nessus_OWASP.py (скрипт находится в Пресейл-Пак в папке 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": "<p>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 <API-токен> --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

Возможные ошибки

Импорт данных из отчетов 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

Для импорта необходимо выполнить следующие шаги:

1. Сформировать отчет сканирования сетевых активов в формате XML file
   
2. Поместить отчет и скрипт в одной директории (можно выполнить на ядре KUMA)
3. Подготовить API права для утилиты:
   1. В KUMA создать пользователя kuma-mp
   2. Дать права на GET /users/whoami и POST /assets/import
   3. Сгенерировать токен (его сохранить в файл на сервере, где будет выполнятся команда
4. Далее в веб-консоли KUMA нужно будет скачать REST API CA
5. Этот сертификат нужно перенести на сервер, где будет выполнятся скрипт
6.  Выполнить команду:

   ./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

7. Для автоматизации добавления активов из папки по отчетам - можно воспользоваться скриптом.

Импорт данных об активах из MaxPatrol VM

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Данная статья является дополнением к основной статье официальной документации https://support.kaspersky.com/help/KUMA/3.2/ru-RU/265427.htm 

Протестирована работоспособность c MaxPatrol VM 2.1

Подготовительные действия в 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 выглядит согласно скриншоту ниже.

KSC

Интеграция KUMA с KSC

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217923.htm 

Интеграция KUMA с KSC позволяет получить активы и данные по ним, которыми управляет KSC, возможность запуска задач реагирования, перемещение активов между группами KSC, закрытие уязвимостей (при наличии лицензии от Kaspersky Endpoint Security для бизнеса Расширенный и выше) из интерфейса KUMA.

Для интеграции необходимо заранее создать учетную запись (внутреннего пользователя) в KSC:

Допускается также использовать доменную учетную запись пользователя для интеграции KUMA с KSC. Учетная запись пользователя в секрете KUMA указывается в формате: username@domain

Если на KSC включено MFA, то нужно сделать исключение для учетки KUMA. Согласно этой инструкции: https://support.kaspersky.com/help/KSC/14.2/ru-RU/211462.htm 

В дополнение к исключению MFA для интеграционной УЗ KUMA можно настроить список адресов, с которых разрешено подключение к KSC: https://support.kaspersky.com/KSC/14.2/ru-RU/231374.htm 

Созданной учетной записи необходимо назначить определенный набор прав доступа к функциям Kaspersky Security Center. Это можно сделать одним из следующих способов:

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

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

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

Права пользователю нужно выдавать не только в свойствах KSC, но и в свойствах групп управляемых устройств, убедитесь, что не отключено наследование, чтобы права корректно распространялись на подгруппы

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

При нажатии в KUMA на кнопку "Сохранить", не должно всплавать сообщений об ошибке.

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, так и за его СУБД.

Монтирование папки в KUMA

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

Для чтения файла логов коллектором 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 аналогии с этой статьей.

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

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Предварительные требования

• На пограничном МСЭ создайте правило доступа к mdr.kaspersky.com по порту TCP/443 (https://mdr.kaspersky.com)
• В KUMA добавьте пользователя с ролью Администратор и доступом к API (права POST /events)
• В консоли MDR сгенерируйте токен для доступа к API:

1. • • Перейдите в Settings -> API
     • Нажмите Add и укажите Connection Name (данное имя будет использоваться, как имя пользователя при создании инцидентов/комментариев/вложений и т.д., так как токен доступа не привязан к конкретному пользователю)
     • Укажите Role, чтобы определить права доступа для токена
     • Укажите Tenant при необходимости
   •  

     Если для создаваемых в консоли MDR инцидентов в поле "Тенант" отсутствует значение, добавьте значение "Корень без тенанта", чтобы скрипт при подключении обнаружил данные инциденты

   •  

     

     • Нажмите Generate
     • После завершения процесса генерации будут получены:
       • JWT Token - он же refresh_token, который требуется активировать, чтобы получить новую пару refresh_token и access_token
       • ClientID - ID-клиента для подключения к API (требуется указывать при каждом запросе к API MDR)
         

• Загрузите архив kuma_mdr_integration.tar.gz со скриптом отсюда - https://box.kaspersky.com/f/11a58e42f63e4cef8741/ 
• Загрузите актуальную цепочку сертификатов для консоли mdr.kaspersky.com в формате pem. После загрузки файлов выполните объединение сертификатов в один файл mdr.pem (см. скриншот ниже). 

Описание интеграции

Описанная в данной статье интеграция с Kaspersky Managed Detection and Response позволяет автоматически импортировать инциденты из консоли MDR в KUMA.

Настройка

• Перейдите в папку /opt/mdr/conf и отредактируйте файл config.yml:
  • В секции General settings укажите актуальный путь до папок (по умолчанию, указан /opt/mdr/*), а также client_id
  • В секции Modules settings  -> kuma укажите:
    • api_url (FQDN/IP:порт API-интерфейса KUMA)
    • username (ранее созданный пользователь с доступом к API)
    • password (пароль ранее созданного пользователя с доступом к API)
    • tenantId (тенант, в котором будут создаваться инциденты)

TenantID можно получить из события аудита KUMA

• • В секции Modules settings  -> logging также укажите актуальный путь до папки со скриптом (по умолчанию, указан /opt/mdr/log)
    
• Перейдите в папку /opt/mdr/conf и добавьте в файл .refresh_token ранее сгенерированный токен для доступа к API MDR 

После добавления токена в файл .refresh_token проверьте, что в конце файла отсутствует символ новой строки \n , из-за которого попытка аутентификации будет неуспешной. См. команды ниже:

# проверяем наличие символа новой строки
wc -l /opt/mdr/conf/.refresh_token
# если вывод "1 .refresh_token", то удаляем символ
perl -p -i -e 'chomp if eof' /opt/mdr/conf/.refresh_token
# проверяем, что символ новой строки успешно удален
wc -l /opt/mdr/conf/.refresh_token
# должен быть вывод "0 .refresh_token"

• Перейдите в папку /opt/mdr/conf и в файле .last_check укажите время, начиная с которого необходимо начать собирать инциденты. Для теста можно указать время до появления последнего инцидента. Формат в милисекундах, то есть должно быть 13 цифр (пример, 1672520400000)
  
• Замените существующий файл /opt/mdr/conf/mdr.pem на актуальный (см. этап "Предварительные требования")
• Запустите скрипт main.py с помощью команды:

python3 ./main.py

Если при запуске скрипта появляются сообщения об отсутствии необходимых пакетов - выполните их установку

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

Лог работы скрипта пишется в /opt/mdr/log/app.log

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

  

• Остановите выполнение скритпа main.py
• Запустите скрипт main.py в фоновом режиме с помощью команды:

nohup python3 /opt/mdr/main.py &

• Настройте автоматический запуск скрипта после перезагрузки сервера:

sudo crontab -e
@reboot sleep 300 && python3 /opt/mdr/main.py & # sleep в 5 минут добавлен, чтобы сервис kuma-core успел стартовать

Интеграция Grafana c ClickHouse в KUMA

Интеграция является не официальной (не поддерживается)

Скачиваем и устанавливаем плагин:

Далее настраиваем в Connections (в старых версиях: Home - Administration - Data sources) по этому плагину:

Предварительно проверьте доступ к порту 8123, если доступа нет, обеспечьте его, например, проборосом портов.

URL: https://10.68.85.126:8123?allowMultiQueries=true    (можете также указать хостнейм, в случае иcпользования плагина Altinity)

Копируем содержимое ключевой информации в нужные секции:

Создаем дашборд со своими панелями (виджетами), пример:

Пример запроса:

SELECT  count(ID), DestinationUserName FROM kuma.events_local_v2 WHERE $__timeFilter_ms(Timestamp) AND DeviceEventClassID='4624'GROUP BY DestinationUserName

Переменная $__timeFilter_ms(Timestamp) обеспечивает проброс промежутка времени из графаны в запрос:

Чтобы поменять тип отображения можно выбрать другое представление тут:

Сохраняем и применяем панель/представление, далее подобным образом можно создать другие панели.

Интеграция KUMA с Active Directory (AD)

При интеграции с AD/ADFS важно иметь единое время на системах, настоятельно рекомендуется настроить NTP

В дочернем домене созданы:

Пользователи являются членами соответствующих групп: 

Настройки 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

Полезные команды

Выгрузка LDAP информации в словарь KUMA

Предварительно нужно выполнить настройку обогащение по этой статье https://kb.kuma-community.ru/books/integracii/page/ldap-obogashhenie

Шаг 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=<SIZE>; 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://<KUMA_IP>:7223/api/v1/dictionaries/update?dictionaryID=<DICTIONARY_ID>' --header 'Content-Type: multipart/form-data' --header 'Authorization: Bearer <TOKEN>' --form 'file=@"/tmp/accounts.csv"'; rm -rf /tmp/accounts.csv

• где <SIZE> - число записей в выводе, нужно ставить значение кол-во пользователей*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}"
• <KUMA_IP> - ip-адрес ядра KUMA
• <DICTIONARY_ID> - id словаря, можно скопировать из строки браузера, если зайти в словарь
• <TOKEN> - токен для доступа к API, скопированный на Шаге 2.

После выполнения скрипта, в словарь запишутся логины и их электронная почта, импортированные из AD.

Более продвинутый заполненный запрос c автоподсчетом <SIZE>:

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

Интеграция с ГосСОПКА

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/221777.htm  

Настройка интерации

Для возможности отправки инцидентов в ГосСОПКА должна быть выполнена настройка, в разделе Параметры - НКЦКИ нужно указать параметры подключения:

• Укажите URL, по которому доступен НКЦКИ.
• Токен, который был выдан Заказчику для подключения к НКЦКИ.

Далее укажите сферу деятельности, местоположение и название компании.

Значение токена сохраняется в Секркте в KUMA:

Работа с инцидентом

После настройки взаимодействие с НКЦКИ и работа с инцидентом выполняется в разделе Инциденты. Для нового инцидента должны быть заполнены минимально необходимые поля:

• категория инцидента;
• тип инцидента;
• описание инцидента.

Описание взаимодействия с НКЦКИ в онлайн-справке: https://support.kaspersky.com/KUMA/2.1/ru-RU/221855.htm 

После нажатия кнопки Экспорт открывается вкладка для заполнения карточки инцидента в формате, который требует НКЦКИ. При необходимости может быть выбран чек-бокс «Затронутая система имеет подключение к Интернету», это подразумевает заполнение дополнительных сведений на вкладке Технические данные.

Вкладки Технические данные и Дополнительно не обязательно заполнять для запуска экспорта, но информация будет запрошена со стороны ГосСОПКА позже.

Вся информация отображается в ЛК Заказчика. При этом в связи с особенностями работы портала перейти из интерфейса KUMA сразу в нужный инцидент в ГосСОПКА нельзя, придется искать в списке всех инцидентов. 

В интерфейсе KUMA можно отслеживать статус  инцидента и изменения содержимого (если изменения были выполнены на портале, а не из KUMA).

При получении обратной связи статус инцидента изменяется, при необходимости инцидент можно дополнить данными
Есть чат с НКЦКИ (не онлайн, примерно раз в 10 минут – особенности на стороне НКЦКИ). 

Есть возможность оповещений по почте о необходимости доработки инцидента.

Автоматическое добавление активов

Описание

Данный скрипт и набор ресурсов позволяют автоматически на основании информации из событий (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

1. Импортируйте все ресурсы из файла auto_asset_add (Пароль импорта: Qwerty123!)

2. Если нужно, внесите изменения в фильтры org address filter и org hostname filter, указав домены и подсети вашей организации, по ним отбираются активы из событий для импорта.

3. Привяжите все правила корреляции Auto import asset info (src/dst/dvc) к коррелятору

4. Привяжите правило реагирования Auto asset import

5. Обновите параметры сервиса коррелятора

Результат

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

Файлы

Все ресурсы доступны по ссылке: https://box.kaspersky.com/d/1eb25f174a3e44e2a1be/ 

Создание 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

И связанные с ним события телеметрии