Реагирование
- Описание готовых интеграций по реагированию
- Запуск скрипта коррелятором
- Настройка автоматического реагирования KUMA с помощью задач KSC
- Блокировка адресов при помощи Cisco ASA Firewall на основе сработок алертов
- Отправка уведомления в телеграм-бот
- Реагирование на BIFIT Mitigator
- Отправка уведомления в телеграм-бот со ссылкой на KATA и KUMA
- Интеграция по реагированию KUMA и KEDR
- Реагирование на KICS Networks с помощью скрипта
Описание готовых интеграций по реагированию
Весь актуальный и новый контент с описанием добавляется в GitHub - https://github.com/KUMA-Community
Реагирование из коробки KUMA
- Запуск задачи обновления баз KES
- Запуск задачи сканирования KES
- Изоляция хоста и снятие с изоляции
- Блокировка хеша по md5 и sha256 на хосте
- Запуск исполняемого файла на хосте по полному пути
- Изменение статуса актива на Разрешенное
- Изменение статуса актива на Неразрешенное
- Блокировка УЗ
- Сброс пароля УЗ
- Добавление УЗ в группу и исключение из группы
- Изменять группы обучения пользователей
- Просматривать информацию о курсах, пройденных пользователями, и полученных ими сертификатах
Готовые скрипты (описание)
- Оповещения об алерте в телеграм канале
- Оповещения об алерте в телеграм канале
- Бот позволяет закрывать алерты по кнопке, создавать резервную копию и выполнять команды ssh на KUMA.
- Блокировка по IP
- Блокировка по URL
- Блокировка по Домену
- Изоляция хоста и снятие с изоляции
- Блокировка хеша по md5 и sha256 на хосте
- Запуск исполняемого файла на хосте по полному пути
- Логирование реагирования в системном журнале
- Блокировка УЗ и разблокировка
- Выход пользователя из активных сессий
- Добавление УЗ в группу и исключение из группы
- Блокировка по URL
- Блокировка по IP
- Блокировка по DOMAIN
- Блокировка по EMAIL
- Блокировка по IP
- Защита от брутфорса интерфейса KUMA
- Блокировка по IP
- Временная блокировка трафика по src_ip, dst_ip, src_port, dst_port, protocol
Запуск скрипта коррелятором
Интерпретатор скрипта должен поддерживаться ОС на которой находится скрипт.
Для того чтобы коррелятор мог запускать скрипты. Зайти по 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) необходимо:
- Авторизоваться на 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/<id>/scripts/
и предоставляем права пользователю kuma, чтобы служба имела достаточные права для запуска скрипта, командами:chown kuma:kuma /opt/kaspersky/kuma/correlator/<id>/scripts/asa.py
chmod +x /opt/kaspersky/kuma/correlator/<id>/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<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
Еще один вариант скрипта
Еще один вариант скрипта, когда в качестве аргумента передаем следующие поля "{{.Timestamp}} | {{.Name}} | {{.DeviceHostName}}":
#!/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 доступен под спойлером
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=<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 в групирующие поля):
Пример сработки правила корреляции:
Далее нужно создать (либо загрузить из Пресейл-Пака) правило реагирование которое будет запускать скрипт из Пресейл-Пака, правило должно выглядеть следующим образом:
Скрипт необходимо загрузить и выгрузить на коррелятор и выполнить действия по этой статье.
В результате правило корреляции и реагирование нужно добавить в коррелятор и обновить его параметры. ТАким образом получим, что при перемещении актива в определенную категорию (например Активным способом по подсети), автоматом эти активы будут помечаться недоверенными.