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

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

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

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

Реагирование на KES через KSC:
Реагирование KEDR:
Реагирование KICS Networks:
Реагирование AD (с версии KUMA 2.1):
Реагирование Kaspersky Automated Security Awareness Platform (KASAP) – это платформа для онлайн-обучения:

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

Telegram Response:
Telegram Response Advanced: 
  • Оповещения об алерте в телеграм канале
  • Бот позволяет закрывать алерты по кнопке, создавать резервную копию и выполнять команды ssh на KUMA.
UserGate Response:
KEDR Response (script):
AD Response:
KWTS Response:
KSMG Response (по запросу):
KUMA:
  • Защита от брутфорса интерфейса KUMA
Cisco ASA Firewall:
BIFIT Mitigator:

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

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

Для того чтобы коррелятор мог запускать скрипты.  Зайти по 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.

image.png

В правиле реагирования рекомендуется добавить в условие (если необходимо) правило корреляции, на основе которого реагирование будет срабатывать:

image.png

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

Настройка автоматического реагирования KUMA с помощью задач KSC

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

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

Сценарий демонстрации

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


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

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

Создать задачу поиска вирусов для KES либо обновления баз. В KUMA механизм автоматического реагирования работает только для KES.

image.png

В целях тестирования можно уменьшить область поиска. В дальнейшем эту настройку можно изменить.

image.png

Выполнить настройки задачи, как на рисунке ниже:

image.png

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

Затем нужно выбрать учетную запись и Настроить запуск задачи вручную.

image.png

Важно в названии задачи сделать префикс «KUMA». Задачи для KES с этим префиксом будут доступны в интерфейсе KUMA. В нашем случае создаем задачу «KUMA Поиск вирусов».

image.png

Завершить создание задачи.


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

Настроить интеграцию с KSC. При настройке «секрета» использовать учетную запись KSC, созданную на предыдущем шаге.

image.png

Далее можно убедиться, что поступают новые события аудита от KSC - подключен пользователь с адреса KUMA.

image.png

акже на этом шаге важно убедится, что значение в поле DestinationHostName записывается в виде полного доменного имени FQDN.

image.png

Если это не так и значение записывается в виде hostname без доменной части, то необходимо настроить нормализацию.
Для этого открыть нормализатор KSC.

image.png

Настроить преобразование для поля DestinationHostName перед сохранением события

image.png

image.png

Сохранить нормализатор и обновить параметры коллектора.
Проверить, что значение DestinationHostName в новых событиях сохраняются в виде FQDN.


Подготовка ресурсов KUMA

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

Файл ресурсов можно скачать по ссылке: https://box.kaspersky.com/f/a84686dbb6b3404987ff/ Пароль: KLaapt-M1 (вводится в интерфейсе KUMA при импортировании)

Для сработки правила реагирования необходимо добавить в наследуеме поля правила корреляции поле DestinationAssetID

image.png

image.png

Привязать правило корреляции к коррелятору:

image.png

Привязать правило реагирования к коррелятору.

image.png

Сохранить настройки и перезапустить коррелятор.

image.png


Проверка автоматического реагирования

На защищаемом устройстве эмулировать вирусное заражение с помощью eicar. Получено событие от KSC «Обнаружен вредоносный объект».

image.png

Создано корреляционное событие «[KES] Обнаружен вредоносный объект».

image.png

Получены события подключения KUMA к KSC – события аудита.

image.png

Получены события о выполнении задачи поиска вирусов на KSC.

image.png

В KSC присутствуют события обнаружения вируса, подключения KUMA, выполнения задачи поиска вирусов.

image.png

Блокировка адресов при помощи 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. В группирующем поле правила корреляции должны находиться целевые поля, которые используются в правилах реагирования, в нашем примере это sourceAddressimage.png
  2. В "селекторы" и "действия" задаём необходимые в данном кейсе параметры.
    Обязательно добавить обогащение событие EventOutcome (как указано на скриншоте), это ключ (триггер) для следующего этапа по запуску правила реагирования.

    image.png

  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)

    image.png

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

    image.png


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

    image.png

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

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

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

Настройка Telegram

1. В Telegram находим бота: https://t.me/BotFather

2. Запускаем командой /start

image.png

3. Создаем нового бота командой /newbot

4. Вводим желаемое имя и логин бота (должен заканчиваться словом bot). В данном примере имя бота "KUMA DEMO" и логин бота "kumademo_bot".

image.png

5. По завершении получаем токен для обращения к боту и ссылку на него

image.png

6. Если планируется использовать бота в группе, а не в личных сообщениях, то необходимо изменить настройки приватности. Для этого вводим /mybots, выбираем своего бота из списка, выбираем Bot Settings, Group Privacy и выбираем Turn off. После этого бот сможет отправлять сообщения в группах.

7. Далее переходим в своего бота по ссылке полученной от BotFather и выполняем команду /start для запуска бота.

8. Для отправки сообщения отдельному пользователю необходимо начать диалог с ботом, а также узнать chat_id этого пользователя. Чтобы узнать chat_id пользователя заходим в бота https://t.me/getmyid_bot и вводим команду /start. Полученное значение chat_id потребуется в дальнейшем для отправки сообщений ботом

image.png

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 не должен содержать ошибок.

image.png

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"

Получаем алерт вида:

image.png

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. Задайте параметры правила реагирования

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

image.png

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

5. Результат работы скрипта представлен ниже

image.png

Реагирование на 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 Протокол для блокировки


Правило реагирования

image.png


Скрипт

Скрипт на языке 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

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

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


Настройка KUMA

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

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

Состав и пароль от пакета ресурсов

Пароль для импорта: Qwerty123!

Состав пакета:

image.png

2. На коллекторе для сбора событий KATA применить правило обогащения из пакета KATA alert (или коробочный аналог [OOTB] Kata Alert)

3. На коррелятор привязать правило корреляции [KATA] Обнаружен TAA-детект

4. На коррелятор привязать правило реагирования [DEMO] Telegram -2

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


Результат работы скрипта

1. Когда КАТА возводит алерт по ТАА-правилам, в KUMA срабатывает правило корреляции. 
2. Корреляционное событие этого правила триггерит правило реагирования. 
3. По правилу реагирования запускается скрипт отправки уведомлений в Телеграм.

Уведомление в телеграм содержит наименование TAA-детекта, FQDN-хоста, на котором была обнаружена активность (со ссылкой на активы KUMA), ссылку на соответствующий алерт в KATA.

Пример уведомления

image.png


Интеграция по реагированию KUMA и KEDR

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

На стороне KUMA. Если мы не хотим делать отдельные интеграции разделенные по Тенантам (подходит для MSSP), а одну общую интеграцию с KEDR, то нужно убрать галочку Распределенное решение:

image.png

Задаем Адрес сервера и Порт, затем создаем Секрет для подключения к KEDR:

image.png

Придумайте название Секрета и сгенерируйте закрытый ключ нажав на значок Загрузки.

image.png

Распакуйте архив, затем загрузите Открытый ключ (cert.pem) и Закрытый ключ (key.pem).

image.png

Нажмите кнопку Сохранить для сохранения Секрета.

Затем снова на кнопку Сохранить для сохранения настроек Интеграции с KEDR.

image.png

Настройки на KEDR

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

image.png

Для удобства можно задать имя внешней системы в KEDR:

image.png

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

image.png

Логирование работы с 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.

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

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

image.png

Далее необходимо создать правило корреляции, которое будет менять статус KICS for Networks на неразрешенное при добавлении в категорию, например Main/Categorized assets/KICS-NET/unwanted. Оно будет выглядеть так (необходимо пробросить поле DeviceExternalID в групирующие поля):

image.png

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

image.png

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

image.png

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

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