Развернутые ответы на вопросы

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

Что такое SIEM и Приоритет подачи журналов в SIEM

Вводная SIEM

Security information and event management (SIEM) – решение для консолидации и анализа данных о событиях, создаваемые системами безопасности, сетевой инфраструктурой конечными точками, приложениями и облачными сервисами. 

Основной тип данных – логи/журналы, но SIEM может также обрабатывать иные типы данных, например, EDR-телеметрию или сетевую телеметрию (flows). 

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

Решение обеспечивает анализ событий в режиме близком к реальному времени для мониторинга безопасности, ретроспективного поиска, расследования инцидентов и других задач, например, проверки соответствия законодательству или отчётность.

Термин SIEM был впервые введён Gartner в 2005.

В 2015, был представлен концепт "next-gen SIEM" или SIEM 2.0. Основное отличие – введение user behavioral analytics (UBA). Next-gen SIEM ориентированы в первую очередь на применение в очень крупном бизнесе (команды SOC 10+ сотрудников).

В 2020 SIEM остаётся ключевым инструментом для работы команд SOC или ИБ. SIEM предоставляет:
Стандартные возможности SIEM:
Новые запросы к SIEM:

Сценарий применений SIEM

  1. Предпроектное обследование (сбор информации об источниках, инфраструктуре), составление модели угроз, разработка сценариев выявления
  2. Развёртывание и первоначальная настройка Подключение источников событий, интеграция с продуктами для реагирования и обогащения
  3. Доработка и адаптация правил корреляции, дашбордов, отчётов
  4. Инвентаризация и категоризация активов, групп пользователей
  5. Штатная работа с системой (мониторинг безопасности, реагирование на инциденты, Threat Hunting)
  6. [по мере необходимости]  Подключение новых источников, обновление коннекторов, правил корреляции
  7. [на регулярной основе] Оценка эффективности и актуализация сценариев выявления и правил корреляции
  8. Остальные юзкейсы будут на этой странице (в разработке)

Приоритет журналов систем к подаче в SIEM

Приоритет подачи событий от определенных систем, прежде всего зависит от модели нарушителя и его возможностей на основе рисков. Если такого документа нет, то можно руководствоваться базовым подходом и акцентировать внимание на события следующих источников (при наличии) данных в порядке приоритета:
  1. Периметровые/Пограничные решения (External facing Systems): VPN порталы, WEB сервера, терминалы, точки доступа, роутеры, СКУД и др.
  2. Системы информационной безопасности (Security Devices): МЭ, IPS/IDS, Email защита, NGFW, Антивирусная защита, EDR, WAF и др.
  3. Системы аутентификации (Authentication Systems): PAM, MFA, LDAP/FreeIPA, RADIUS, CA Systems, SAML, AD и др.
  4. SaaS приложения/ПО как услуга (SaaS Apps): Slack, Cloudflare, Microsoft Azure Active Directory, Zscaler и др.
  5. Системы под управлением ОС Windows (Windows Systems): Сервера (AD, MS SQL,Exchange, DNS, DHCP, SCCM, WSUS, и др.), Рабочие станции и др.
  6. Системы под управлением ОС Linux (Linux Systems): apache, nginx, mysql, fail2ban, bind, samba, exim, squid, postgres и др.
  7. Сетевые устройства (Network Devices): Маршрутизаторы (Netflow полезно), коммутаторы, мосты, Wi-Fi, модемы, концентраторы и др.
  8. Системы виртуализации (Virtualization Systems): VMware, Citrix, Hyper-V, KVM, ProxMox и др.
  9. Внутренние системы (Internal Systems): Процессинг, Бизнес-приложения и др.
  10. Управления и работа с мобильными устройствами (Mobile Devices): MDM, EMM, UEM и др.
  11. Системы хранения данных и СРК (Storage/Backup Systems): DELL EMC, HP 3PAR, NetApp, Veeam, CommVault и др.
  12. Узкоспециализированное ПО (COT: commercial off-the-shelf):  Собственные приложения, The Microsoft Office, Adobe Photoshop, SAP и др.

Схема сетевого взаимодействия KUMA (Архитектура)

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

Полная таблица доступов по портам KUMA: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/217770.htm 

Между шардами кластера хранилища необходимо также открывать порт 9000, несмотря на то, что это не указано в таблице документации

Схема (хранилище представлено с двумя репликами, т.е. с копией данных):

Схема сетевого взаимодействия KUMA.png

Файл для редактирования (draw.io): https://box.kaspersky.com/f/f8afd0cbda314109ad48/ 

Модель лицензирования KUMA

Проверить поддержку версии продукта https://support.kaspersky.com/corporate/lifecycle#b2b.block13.kuma 

Лицензирование продукта Kaspersky Unified Monitoring and Analysis Platform (KUMA) происходит по среднему количеству обрабатываемых событий в секунду (EPS) за 24 часа.

Минимально возможное количество EPS к приобретению = 500.

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

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

В случае, если среднее значение превышает ограничение по EPS, указанное в лицензионном ключе, KUMA уведомляет о данном событии в интерфейсе. А также, если за 7 дней работы KUMA среднее значение EPS превышало ограничение 30% времени и более, KUMA дополнительно отправляет на email-адрес администратора уведомление о превышении количества полученных событий и продолжает далее подсчёт среднего значения EPS, не блокируя функционал.

Лицензии срочные, выписываются на 1, 2 или 3 года, если необходимо больше, то цена складвается из цен за ранее указанные периоды.

По истечении лицензии + 7 дней блокируются все функции (создание и / или изменение контента SIEM, обработка новых событий, корреляция, а также создание или изменение правил корреляции, нормализации, дашбордов, отчетов и пр.), за исключением просмотра информации по ранее собранным событиям.

Описание модулей лицензирования

Решение класса SIEM (Security Information and Event Management), предназначенное для централизованного сбора, анализа и корреляции событий информационной безопасности с различных источников данных. Решение обеспечивает единую консоль мониторинга, анализа и реагирования на угрозы ИБ, объединяя как решения «Лаборатории Касперского», так и сторонних производителей. Начиная с версии 2.1 поддерживается развёртывание в режиме отказоустойчивости, при котором отказ одного или нескольких узлов не приводит к нарушению потоковой обработки событий и выявления инцидентов. Отказоустойчивость системы достигается за счёт встроенных механизмов маршрутизации данных. Дополнительных лицензии и лицензионного ключа для отказоуствойчивости не требуется. Отдельный модуль High Availability доступен только до версии 2.0 (включительно).

Каждый из модулей решения KUMA включает в себя возможность сделать 50 запросов в Kaspersky Threat Lookup для получения дополнительного контекста в ходе проведения расследования. Чтобы активировать эту функцию, отправьте запрос с указанием номера заказа на адрес intelligence@kaspersky.com.

Netflow Support (Netflow)

События телеметрии о трафике, которые помогают в обнаружении аномалий на сетевом уровне и расследовании инцидентов. KUMA выполняет приём и обработку Netflow событий без ограничений, при этом данные Netflow не учитываются в счётчике EPS.

GosSOPKA (ГосСОПКА)

Модуль, обеспечивающий возможность интеграции с технической инфраструктурой НКЦКИ (Национальный координационный центр по компьютерным инцидентам). Модуль ГосСОПКА позволит передавать инциденты, выявленные SIEM «по требованию» (т. е. по явному указанию пользователя), в техническую инфраструктуру НКЦКИ через API и получать рекомендации по реагированию на эти инциденты. Модуль ГосСОПКА регулирует только взаимодействие с НКЦКИ по инцидентам.

Threat Intelligence (TI)

В рамках данного модуля поставляются платформа для управления данными об угрозах Kaspersky CyberTrace и потоки данных об угрозах Kaspersky Threat Data Feeds. Наличие лицензии упрощает интеграцию потоков данных с KUMA для дальнейшего использования аналитики угроз в повседневной работе ИБ-служб. KUMA собирает журналы с различных устройств, ИТ-систем и ИБ-инструментов и отправляет данные о событиях с URL, IP-адресами и хешами в Kaspersky CyberTrace на анализ, который сопоставляет поступающие события с потоками данных об угрозах и отправляет данные об обнаруженных угрозах в обратно в KUMA и Kaspersky CyberTrace Web. Аналитик ИБ получает оповещения об обнаруженных угрозах с дополнительным контекстом и может провести первоначальное расследование и инициировать процесс реагирования на основе полученного контекста. Платформа взаимодействует с любыми типами потоков аналитических данных об угрозах («Лаборатории Касперского», других поставщиков, из открытых источников или иных каналов) в форматах JSON, STIX/TAXII, XML и CSV и поддерживает интеграции с рассылками НКЦКИ и бюллетенями ФинЦЕРТ. В рамках данного модуля доступны следующие потоки данных об угрозах: Malicious URL, BotnetCnC URL и Phishing URL, IP reputation и Ransomware URL.

Использовать фиды и Kaspersky CyberTrace, приобретённые в рамках данного модуля, можно только для обогащения событий, получаемых KUMA (использовать с другими SIEM системами, а также для интеграции с системами других классов недопустимо).

При приобретении KUMA (любых модулей) также предоставляется доступ к Kaspersky Threat Intelligence Portal (до 100 запросов в Kaspersky Threat Lookup и до 10 запросов в Kaspersky Threat Analysis) в период действия лицензии. Портал позволяет получить дополнительный контекст в ходе проведения расследований. Чтобы активировать эту функцию,
отправьте запрос с указанием номера заказа на адрес intelligence@kaspersky.com 

Предлагаемая техническая поддержка

Каналы связи


 Premium Premium Plus
Company account (веб-портал, уведомления через почту) ✔ ✔
Телефон ✔ ✔
Время реакции в зависимости от уровня критичности

 Premium Premium Plus
Критический (24 / 7) 2 часа 0,5 часа
Высокий (в рабочие часы) 6 часов 4 часа
Средний (в рабочие часы) 8 часов 6 часов
Низкий (в рабочие часы) 10 часов 8 часов
Доступные услуги
Программные исправления Premium Premium Plus
Удаленное подключение для диагностики проблем ✔ ✔
Постпроектная поддержка* ✔ ✔
Частные исправления ✔ ✔
Рекомендации по оптимизации ✔ ✔
Персональный технический аккаунт менеджер (ТАМ) ❌ ✔
Регулярные статус-встречи с ТАМ для анализа зарегистрированных инцидентов, связанных с ТП ❌ Ежеквартальный отчет
Разработка нормализаторов для нестандартных источников событий 10 шт. 20 шт.

* Консультации по донастройке в среде заказчика проводятся только по нашему продукту KUMA и при наличии информации о инфраструктуре и схеме развёртывания продукта.

Типы хранения данных в KUMA

В KUMA существует три типа пространства для хранения событий:

Для оптимизации использования дискового пространства и ускорения выполнения запросов в KUMA введено несколько уровней устройств хранения:

Основная идея разделения хранилищ на "горячие" и "холодные" состоит в том, что доступ к данным сохраняется, но при этом увеличиваются задержки. Используется сочетание настроек политики хранения ClickHouse и механизма переноса разделов таблиц между дисками. Плюсом подхода является возможность использовать в качестве хранилища любое примонтированное в качестве каталога Linux устройство, а также хранилища HDFS.

Подробнее про холодное хранение - https://support.kaspersky.com/help/KUMA/3.0.3/ru-RU/243503.htm 

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

Холодное пространство монтируется на сами хранилища (в случае локального типа холодного хранения) в нужном объеме, на рисунке ниже схематично показано, как это выглядит для двух реплик (R) и одного шарда (S):

image.png

Владельцем папки по точке монтирования холодного хранения должна быть УЗ kuma, команда: chown -R kuma:kuma /mnt/cold_stor/

Первичный Траблшут в KUMA (Troubleshoot)

Проверка статуса основных компонентов

Основные службы KUMA:

systemctl status kuma-collector-ID_СЕРВИСА.service
systemctl status kuma-correlator-ID_СЕРВИСА.service
systemctl status kuma-storage-ID_СЕРВИСА.service
systemctl status kuma-core.service
systemctl status kuma-clickhouse.service
systemctl status kuma-mongodb.service 
systemctl status kuma-victoria-metrics.service
systemctl status kuma-grafana.service

В версии KUMA 3.2 сервис ядра изменил название на kuma-core-00000000-0000-0000-0000-000000000000.service

ID_СЕРВИСА можно скопировать в веб-интерфейсе системы, в разделе Активные сервисы, выделив в checkbox нужный сервис, затем нажав кнопку скопировать ID.

image.png

Проверка журнала ошибок KUMA

/opt/kaspersky/kuma/<Компонент>/<ID_компонента>/log/<Компонент>

Пример:

/opt/kaspersky/kuma/storage/<ID хранилища>/log/storage

Для неактуальных версий (2.0 и ниже):

Вывод ошибок сервиса в консоль

В случае отсутствия информации в журналах целесообразно вывести информацию в консоль. Проверяем статус сервиса и копируем его параметры запуска:

image.png

Останавливаем сервис и запускаем следующим образом, пример команды ниже:

sudo -u kuma /opt/kaspersky/kuma/kuma collector --id cef0527c-25ad-4490-a8ce-bf9ab2af71ee --core https://test-kuma.sales.lab:7210 --api.port 7276

Пустые метрики

В случае если раздел метрик пустой (отсутствуют значения на дашбордах), то проверьте указан ли IP и hostname сервера KUMA в файле /etc/hosts, если нет то добавьте.

Перезапустите службы:

systemctl restart kuma-victoria-metrics.service
systemctl restart kuma-grafana.service

Либо присутствует конфликт со службой Cockpit на Oracle Linux.

Она слушает тот же порт 9090, что и Victoria Metrics. Останови Cockpit и посмотри, поднимутся ли метрики.

Либо проблема из-за наличия прокси между ядром и АРМом, с которого к вебке подключались.

Проверка прослушивания порта, например, 5144

netstat –antplu | grep 5144

Работа с портами на МЭ (firewall-cmd)

Проверка открытых портов на МЭ:

firewall-cmd --list-ports

Добавление порта 7210 на МЭ:

firewall-cmd --add-port=7210/tcp --permanent

Применение настроек:

firewall-cmd --reload

Проверка получения событий на порту 5144 в ASCII

tcpdump -i any port 5144 -A

Отправка тестового события на порт 5144, для проверки работы коллектора

Для TCP:

nc 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"'

Для UDP:

nc -u 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"'

В случае наличия в сыром событии двух типов кавычек ' и ", то целесообразно отпралять событие из файла (для этого тестовое событие запишите в файл 1 строку).

cat test.txt | nc -u 127.0.0.1 5144

Статус службы красный / Ошибка на компоненте

Переписать / перепроверить учетные данные (если используются) используемые в коннекторе на коллекторе. Проверить владельца папки службы, должно быть kuma:kuma

Посмотреть статус сервиса через консоль ssh. В случае если он запущен остановить:

systemctl stop kuma-collector-ID_СЕРВИСА.service

запустить вручную (--api.port выбирайте любой свободный), и посмотреть есть ли ошибки при запуске:

/opt/kaspersky/kuma/kuma collector --id ID_СЕРВИСА --core https://FQDN_KUMA:7210 --api.port 7225

Если будут ошибки, они явно отразятся в консоли.

Для сервисов без ID, сначала смотрим параметры запуска службы, например:

image.png

Затем делаем стоп службы и запускаем строку запуска от пользователя KUMA:

sudo -u kuma /opt/kaspersky/kuma/kuma core --external :7220 --internal :7210 --mongo mongodb://localhost:27017

Ручная очистка пространства хранилища

Если место на сервере хренения заканчивается, но еще не закончилось.

Выберите в активных сервисах - сервис хранилища (storage) и нажмите на кнопку смотреть разделы. Удаляйте наиболее старые партиции.

Далее (чтобы в будущем не заполнялось):

  1. Resources/Storage - уменьшаем ретеншен период
  2. после этого рестарт сервисов KUMA Storage. Изменения применятся примерно в течение часа и место освободится.

Закончилось дисковое пространство

Если место уже закончилось.

Далее (чтобы в будущем не заполнялось) в KUMA с версии 3.2:

В Параметры - Мониторинг сервисов - Хранилище, выставьте нужные значения по оповещениям.

Создание сервисов в случае их отсутствия

Если в разделе Ресурсы – Активные сервисы отсутствуют что-либо, то необходимо создать необходимые службы.

Создаем сервис хранилища

Перейдите в Ресурсы – Хранилища затем нажать на кнопку Добавить хранилище придумайте название и затем укажите количество дней хранения событий и событий аудита (от 365 дней срок хранения аудита), затем нажмите Сохранить.

Публикуем созданный сервис Ресурсы – Активные сервисы затем выбрать созданный ранее сервис и нажать на кнопку Создать сервис.

Скопируйте идентификатор сервиса:

image.png

Выполните команду в консоли:

/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://<FQDN/ИМЯ_ХОСТА_СЕРВЕРА_ЯДРА>:7210 --api.port 7230 --install

В разделе Ресурсы – Активные сервисы убедитесь, что служба работает более 30 секунд с «зеленым» статусом индикатора:

image.png

Далее создадим точку назначения, которая используется в маршрутизации событий, перейдите в Ресурсы – Точки назначения, затем нажмите на кнопку Добавить точку назначения. Придумайте название и затем в поле URL укажите FQDN и порт службы хранилища, например: kuma-1-5-1.sales.lab:7230, затем нажмите Сохранить.

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

Создаем сервис коррелятора

Развернем коррелятор, перейдите в Ресурсы – Корреляторы, нажмите на кнопку Добавить коррелятор и затем пройдите по мастеру настроек, на шаге добавления маршрутизации добавьте точку назначения ранее созданного хранилища:

image.png

На последнем шаге нажмите кнопку Сохранить и создать сервис, в случае отсутствия ошибок появится командная строка для установки службы, скопируйте ее и выполните по ssh.

image.png

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

Ошибка скрипта при установке - ipaddr

Если при установке возникает следующая ошибка (пишется в конце исполнения скрипта):

image.png

То попробуйте установить нужную библиотеку для python, это было в требованиях https://support.kaspersky.com/KUMA/1.6/ru-RU/231034.htm, в случае отсутствия возможности это сделать то закомментируйте (вставьте # перед строками) следующие строки в файле kuma-ansible-installer/tasks/validate-inventory.yml:

#- name: Ensure there is no IP as hostname
# loop: "{{ groups.all }}"
# when: item | ansible.netcommon.ipaddr
# fail:
# msg: |
# host: {{ item }}
# error: Hostname expected

Слушать на 514 порту (порты < 1024)

По умолчанию это невозможно, так работает Linux. Для обхода этого в описании сервиса:

/usr/lib/systemd/system/kuma-collector-<ID>

Добавьте значение ниже тега [Service]

AmbientCapabilities=CAP_NET_BIND_SERVICE

Затем запустите команду ниже для обновления параметров сервиса

systemctl daemon-reload

Не запускается хранилище после перезагрузки в версии от 2.1

Прописать следующую команду в SSH консоли:

sudo -u kuma touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data

Ошибка БД ClickHouse Table read only replicas

Ошибка в логах хранилища выглядит так:

Зайдите в клиент ClickHouse:

/opt/kaspersky/kuma/clickhouse/bin/client.sh

Выполните команду:

system restart replica on cluster kuma kuma.events_local_v2

Для выхода из клиента нажмите Ctrl+D.

Ошибка ZooKeeper - KEEPER_EXCEPTION

Убедиться, что ipv6 включен:

ping ::1

Убедиться, что у вас корректное содержимое в /etc/hosts, смотрите этап подготовки п. 8 

Очистить Coordination Zookeeper и наработки хранилища (удаляет все события):

systemctl stop kuma-storage-<ID>.service
rm -rf /opt/kaspersky/kuma/storage/<ID>/data/*
rm -rf /opt/kaspersky/kuma/storage/<ID>/tmp/*
rm -rf /opt/kaspersky/kuma/clickhouse/coordination/*
systemctl start kuma-storage-<ID>.service

Иногда требуется (в случае если ошибка остаеся):

sudo -u kuma touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data

Либо:

/opt/kaspersky/kuma/clickhouse/bin/client.sh
system restore replica on cluster kuma kuma.events_local_v2

Признаки нехватки выделенных ресурсов

Описание метрик доступно тут: https://kb.kuma-community.ru/books/kuma-how-to/page/opisanie-metrik-v-kuma 

Универсальный показатель Load

image.png

Мощностей не хвататет, если на нодах высокий LA (Load average), утилизация CPU доходит до 100%, нагрузка зависит не только от потока (EPS) зависит, но и от профиля использования (количество обогащений, интеграций, используемых правил и т.д.). Средние значения нагрузки (Load averages):

Проблема с производительностью диска на хранилище по метрикам

Накапливается буфер в точках назначения, на рисунке ниже хранилище не справляется с потоком, в норме буфер не накапливается при доступности хранилища:

image.png

Загрузка CPU и RAM доходит до 100% или близко к этому значению:

image.png

В случае использования кластера хранилищ растут очереди распределенных запросов и мерджи:

image.png

Хранилища выпадают в режим только для чтения:

image.png

 Может быть полезно для хранилища при нагрузках:

Также оценить нагрузку на диск можно командой top в ОС Linux, отслеживая параметр wa (wa: io wait cpu time (or) % CPU time spent in wait on disk) — показывает процент операций, готовых быть выполненных процессором, но находящихся в состоянии ожидания от диска. Допустимое значение < 0.5, в идеале 0.

Требования к хранилищу - тут

Устройство кластера хранилищ - тут

Проблема с производительностью сервисов (особенно коррелятор), большой Output Latency

Если CPU заняты не полностью (не на 100%), а Latency существенный (более 1-2 сек) — проблема в сети. Ниже пример допустимого Output Latency.

image.png

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

Проблема с производительностью сервисов (особенно коррелятор), большьшая нагрузка на CPU, памяти и периодические перезапуски службы

Большое кол-во коллекторов (> 100 шт.) перенаправляют события на коррелятор. Высокая загрузка CPU на серверах и большое количество отправляемых пакетов с коллекторов приводит к общей деградации серверов со службой коррелятора по CPU и памяти (корреляторы перезапускаются каждые 5 минут). Пример поведения по метрикам:

image.png

Для решения проблемы были внесены изменения в точку назначения коррелятора, увеличив время ожидания соединения до 300 сек. Утилизация памяти на серверах со службой коррелятора выше 50% в течение для не поднималась. 

image.png

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

Мониторинг работы ядра в кластере Kubernetes

Посмотреть логи сервисов KUMA:

k0s kubectl logs -f -l app=core --all-containers -n kuma

На хосте контроллера можно посмотреть какие сервисы запущены:

k0s kubectl get pods --all-namespaces

По команде выше, в столбце NAMESPACE нам интересна строка kuma, в этой строке берем значение столбца NAME для просмотра конфигурации используем команду:

k0s kubectl get pod core-deployment-984fd44df-5cfk5 -n kuma -o yaml | less

Получить список рабочих узлов:

k0s kubectl get nodes

Получить расширенную инфу по рабочему узлу, в т.ч. потребление:

k0s kubectl describe nodes kuma-4.local

Зайти в командную строчку пода core-*:

k0s kubectl exec --stdin --tty core-deployment-984fd44df-gqzlx -n kuma -- /bin/sh

Потребление ресурсов контейнеров внутри пода:

k0s kubectl top pod core-deployment-984fd44df-gqzlx -n kuma --containers

Для более удобного управления кластером используйте утилиту k9s - https://github.com/derailed/k9s

После установки ядра в кластере в папке установки прописывается конфиг, например, /root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml. Его надо “скормить” k9s командой: export KUBECONFIG=/root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml

Для персистентности переменной KUBECONFIG, необходимо выполнить команду:

echo "KUBECONFIG=/root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml" >> /etc/environment

Проверить переменные окружения можно командой:

export -p

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

Небольшие подсказки по горячим клавишам k9s:

Общий подход по траблшутингу k8s:

image.png

Описание процесса работы c инцидентами в KUMA

Ниже приведено описание основного функционала KUMA задействованного в управлении инцидентами. 

image.png

Алерты

Создание алерта

Алерт создается в результате сработки корреляционного правила на основе поступивших событий, он является подозрением на инцидент. Чтобы создать алерт, необходимо настроить корреляционное правило и в секции Actions не включать опцию Do not create alert, в таком случае при срабатывании этого правила, создастся новый алерт.

Оповещение об алерте

При появлении алерта есть возможность настроить оповещение на почту. Для этого необходимо перейти в Settings -> Alerts -> Notification rules. При создании нового правила оповещения можно указать свой шаблон для письма. С помощью правил оповещения есть возможность настроить разные сценарии в зависимости от того какое корреляционное правило сработало, и исходя из этого оповещение уйдет разным получателям. 

Назначение ответственного на алерт

Обнаружив новый алерт, аналитик может взять его в обработку, назначив на себя, для этого в окне алерта необходимо на верхней панели в поле Assigned to выбрать Me, либо выбрать другого пользователя, чтобы назначить алерт на него.

image.png

Связанные активы

В рамках алерта в зависимости от событий могут быть связанные активы (хосты или аккаунты). Для автоматической актуализации активов можно настроить интеграцию, например, с Active Directory и Kaspersky Security Center. Если в событии встречается актив, то система автоматически связывает само событие с активом, а затем и алерт с активом. Список связанных активов находится в карточке алерта в полях Related endpoints и Related users.

image.png

История изменений и ведение журнала

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

image.png

Связанные события

При срабатывании одного и того же правила новых алертов не создается, а наполняется существующий до тех пор, пока он не будет закрыт, либо если не создано правло сегментации для этого првила корреляции. В одном алерте может быть несколько вложенных событий, которые указаны в поле Related events. Для удобства расследования связанные события раскрываются в иерархическое дерево в зависимости от цепочки сработавших правил. Детали каждого события можно просмотреть прямо из карточки алерта, нажав на само событие.

image.png

Детализированный анализ

При необходимости детального анализа и изучения событий, которые произошли до и после инцидента, можно перейти ко всем событиям из алерта, нажав кнопку Find in events в разделе Related events. Перейдя во вкладку Events в результатах поиска, будут отображены все связанные события. Для отображения всех событий, которые были в данные промежуток времени, нужно сменить выбор с Related to alert, на All events. В результате отобразятся все события, среди которых можно выполнить поиск новых связанных событий и привязать их к алерту. Для этого выберете событие и в появившемся окне с детальной информацией нажмите Link to alert. Таким образом можно обогатить алерт новыми связанными событиями.

image.png

Закрытие алерта

В случае ложного срабатывания или, если нет необходимости создавать инцидент, есть возможность закрыть алерт. При закрытии алерта необходимо указать одну из трех причин: Отработан, Неверные данные, Неверное правило корреляции.

image.png

Создание инцидента

В случае необходимости повышения алерта до уровня инцидента, это можно сделать с помощью кнопки Create incident.

image.png

Привязка алерта к инциденту

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

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

image.png

Инциденты

Создание инцидента

Инцидент можно создать на основе алерта или вручную с помощью кнопки Create incident во вкладке Incidents. При создании вручную необходимо заполнить обязательные поля, также при необходимости, есть возможность прикрепить к инциденту алерты или связанные активы.

Объединение инцидентов

Если в ходе расследования потребовалось объединить несколько инцидентов в один – это можно сделать с помощью функционала объединения. Для этого в окне инцидента нужно на верхней панели нажать на Merge и выбрать инцидент, с которым необходимо выполнить объединение.

Назначение ответственного на инцидент

При создании нового инцидента, аналитик может взять его в обработку, назначив на себя, для этого в окне инцидента необходимо на верхней панели в поле Assigned to выбрать «Me», либо выбрать другого пользователя, чтобы назначить инцидент на него.

Пример процесса реагирования на инциденты

Рассмотрим пример плана реагирования на инцидент, в рамках которого можно выделить стадии: 

image.png

Пример реагирования на инцидент с помощью KUMA

Рассмотрим пример реагирования на инцидент с помощью Kaspersky Unified Monitoring and Analysis Platform. Для примера будет взят стенд со следующими параметрами:

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

Процесс мониторинга

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

image.png

Каждый алерт имеет название правила корреляции, которое его породило. При повторном срабатывании правила в поле First seen будет время первого события, а в Last seen последнего.

Triage

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

Аналитики из L1 переходит по ссылке из письма и попадает сразу на карточку первого алерта:

image.png

Взятие в работу L1

Аналитик берет в работу алерт, назначая его на себя.

Анализ алерта

При анализе алерта аналитик обращает внимание на то какое правило сработало и соответствуют ли данные из событий с самим правилом. Как видно из названия правила алерт сработал на изменение какой-то критичной ветки реестра, в поле Related events в событии присутствуют путь до ключа реестра, есть старое и новое значение ключа реестра, отсюда можно сделать вывод, что правило соответствует произошедшему событию и аналитик обладает достаточной экспертизой, чтобы продолжить реагирование. Иначе же аналитик может перевести алерт на L2, назначив его на другого аналитика.

Проверка достаточности данных

На данном этапе аналитик должен определить каких данных ему будет достаточно для дальнейшего расследования. Чтобы продолжить расследование в рамках алерта по несанкционированному изменению ветки реестра, необходимо точно знать какой ключ был изменен и на каком хосте это было сделано. Дополнительными полезными данными будет информация о том, кто это сделал и новое значение ключа реестра. Раскрыв дерево событий от верхнеуровневого правила до самого события, можно увидеть детали, нажав на интересующее событие.

image.png

Проверка на False Positive

В рамках проверки на ложное срабатывание аналитик должен проверить верно ли сработало правило, может ли быть такая активность легитимной в связи с нормальной работой системы (например, обновление). Проанализировав детали события, видно, что персональная учетная запись talankin выполнила создание ключа реестра с помощью утилиты reg.exe, а также ключ реестра был создан в ветке \Microsoft\Windows\CurrentVersion\Run, отвечающей за автозапуск программ при входе пользователя в систему. Эти данные дают понять, что алерт скорее всего является True Positive и можно продолжить анализ дальше.

Определение критичности

На стадии определения критичности нужно валидировать критичность, которая была проставлена автоматически либо скорректировать её. Исходя из данных алерта имеет смысл выставить высокую критичность для данного алерта:

image.png

Создание инцидента

Проведя действия в рамках триажа, аналитик может эскалировать алерт до инцидента, чтобы начать расследование. Для этого в карточке инцидента необходимо нажать Create incident, в появившемся окне заполнить необходимые поля и нажать Save:

image.png

Расследование

Сбор информации о затронутых активах

Информация о затронутых активах автоматически выделяется в поля инцидента Related endpoints и Related users в том случае, если данные об этих активах загружены в KUMA с помощью интеграции с KSC, AD или внесены вручную. В изображении ниже видно, что в рамках инцидента были затронуты хост windows-kedr и учетная запись пользователя igor talankin.

Сразу можно отметить, что хост находится в категориях Business impact/HIGH и Device type/Workstation, то есть мы имеем дело с рабочей станцией, которая является критичной для нашей инфраструктуры (по легенде рабочая станция принадлежит администратору).

image.png

Если нажать на хост, то появятся детали актива. Детали содержат довольно подробную информацию, куда входит:  

image.png

image.png

image.png

Если нажать на связанную учетную запись, то можно изучить данные о ней по информации из Active Directory:

Как видно из списка групп, учетная запись состоит в группе доменных администраторов, что подтверждает высокую критичность инцидента.

image.png

Определение скоупа

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

Поиск связанных алертов

Первым делом имеет смысл проверить другие алерты, которые происходили с затронутыми активами. 
Для этого достаточно выбрать актив и в разделе со связанными алертами нажать Find in alerts.

image.png

В окне с алертами можно сделать фильтрацию по времени или статусу, чтобы исключит уже обработанные алерта или устаревшие:

image.png

Как видно, с данным активом связаны и другие алерты. Судя по времени, в которое сработали алерты, мы можем сделать вывод, что все они так или иначе связаны друг с другом. Чтобы связать алерты с инцидентом, отмечаем интересующие алерты и нажимаем в нижней части панели Link, в появившемся окне отмечаем инцидент, с которым мы хотим связать алерты и снова нажимаем Link:

image.png

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

image.png

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

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

Threat hunting

После поиска связанных активов и алертов, можно приступить к более детальному расследованию и углубиться в поиск связанных c инцидентом IOC по всей инфраструктуре.

Для поиска связанных событий можно воспользоваться вкладкой Events и произвести поиск вручную или выбрать любой из связанных алертов и в его карточке нажать Find in events. Данный функционал называется Drilldown analysis:

image.png

В появившемся окне с событиями мы можем искать события и сразу же связывать их с выбранным алертом (для привязки алерта он должен быть отвязан от инцидента). Для этого необходимо в верхней части выбрать Search events -> All events:

image.png

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

image.png

Из этого события появляется информация о некотором файле ChromeUpdate.bat. Чтобы узнать происхождение этого файла, мы можем продолжить процесс поиска, выполнив поиск по FileName = ‘C:\\Users\\talankin\\Downloads\\ChromeUpdate.bat’ и по маске доступа %%4417 (тип доступа WriteData (or AddFile)). В результате поиска мы найдем, что файл был создан процессом msedge.exe, чтобы говорит о том, что файл был скачен из внешнего источника, для дальнейшего анализа уже потребуются события с proxy сервера или NGFW. Это событие мы также привязываем к нашему алерту.

image.png

В ходе расследования мы можем выявить новые индикаторы компрометации такие как имя файла, URL, IP адрес и т.д., по этим данным также стоит выполнить поиск ретроспективный анализ, в результате которого можно выявить новые затронутые активы и обнаружить новые следы присутствия злоумышленника. В данном инциденте имеет смысл выполнить поиск файла ChromeUpdate.bat в событиях за последние пару недель.

Произведя Threat hunting для каждого алерта, мы должны выявить всю цепочку атаки.

Определение причин инцидента

По результатам поиска связанных событий мы выявили причины инцидента и можем записать результаты нашего анализа в журнал в карточке инцидента, чтобы передать информацию другим аналитикам или для полноты описания всего процесса реагирования. В разделе Change log мы можем указать важную информацию:

image.png

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

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

Антивирусной сканирование

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

image.png

Сетевая изоляция хоста

Для изоляции хоста, необходимо повторить действия для выбранного хоста, но выбрать KEDR Response, затем в Task type выбрать Enable network isolation и заполнить дополнительный параметры при необходимости, например, уточнить время изоляции или исключения в случае необходимости иметь доступ к хосту во время изоляции.

image.png

Предотвращение запуска вредоносного файла

Для добавления файла в карантин и создания превентивного правила с запретом запуска данного файла (в случае, если файл исполняемый) нужно повторить действия и выбрать KEDR Response -> Task type: Add preventive rule, в поле File hash указать хэш файла. В поле Asset имеет смысл указать All assets, так как нам необходимо застраховаться от дальнейшего распространения вредоносного файла.

image.png

Восстановление

После выполнения всех действий по расследованию и сдерживанию инцидента, а также после очистки инфраструктуры от следов злоумышленника, можно приступить к восстановлению нормальной работоспособности всех систем. Для это может понадобиться отключить какие превентивные правила на EDR или убрать сетевую изоляцию, если она не отключится автоматически. Чтобы выполнить эти действия, необходимо повторить действия подобные тем, что были произведены на предыдущем этапе, только выбрать задачи Disable network isolation и Delete prevention rule. 

Закрытие инцидента

В конце процесса реагирования мы можем закрыть инцидент, выбрав один из вариантов заключения: approved или not approved. Чтобы закрыть инцидент, необходимо в верхней части карточки инцидента выбрать Close incident, в появившемся окне отметить нужный вариант и выбрать Close:

image.png

Закрытый инцидент нельзя «пере»-открыть. 

Пошаговое руководство по разработке сценариев реагирования

Как использовать MITRE ATT&CK в SOC

image.png

Использование MITRE ATT&CK в Центре управления безопасностью (SOC) может значительно расширить возможности обнаружения угроз и реагирования на них. 

Правила корреляции из коробки в KUMA (SOC Package и Community-Pack) покрываются техниками и тактиками из матрицы MITRE ATT&CK, для обогащения корреляционных событий используйте в корреляторе на шаге обогащение соответсвующие правила обогащения идущие в комплекте: MITRE Tactics и MITRE Technique

Обогащение Техниками и Тактиками на корреляторе

image.png

Ниже шаги для эффективного использования в SOC:

Ознакомьтесь с MITRE ATT&CK

Сопоставьте ATT&CK с вашей средой

Создайте правила обнаружения

Реализуйте поиск угроз (Threat Hunting)

Улучшайте реагирование на инциденты

Работайте с Threat Intelligence

Пример работы

Находим технику

Например, нам интересен вектор атаки через планировщик задач, для этого можно воспользоваться поиском вверху справа на сайте https://attack.mitre.org/:

image.png

Переходим на интересующую тематику:

image.png

Изучаем материал

Изучаем меры защиты

image.png

Преобразуйте TTP (Техники, Тактики и Процедуры) в правила в SIEM

image.png

Например, такое правило MITRE CAR - Scheduled Task Creation or Modification Containing Suspicious Scripts, Extensions or User Writable Paths (https://car.mitre.org/analytics/CAR-2021-12-001/). В нем можно увидеть множество вариаций правил, как в псевдокоде, так и в популярных зарубежных SIEM системах.

image.png

ATT&CK Navigator

ATT&CK Navigator — это веб-инструмент для разметки и изучения матриц ATT&CK. Его можно использовать для визуализации покрытия средств защиты, планирования красно-синих команд, частоты обнаруженных приемов и многого другого. Сайт - https://mitre-attack.github.io/attack-navigator/  

Как слушать коллектором порты меньше 1024

Редактирование файла сервиса

В связи с особенностью функционирования Unix-систем для прослушивания портов с номерами ниже 1024 нужны дополнителльные права.

Для того, чтобы дать сервису соответствующие права выполните следующие действия:

1. Остановите выполнение сервиса коллектора командой 

systemctl stop kuma-collector-<id>

2. Откройте на редактирование файл службы коллектора

systemctl edit --full kuma-collector-<id>.service

3. В разделе [Service] добавьте следующую строку

AmbientCapabilities=CAP_NET_BIND_SERVICE

4. Сохраните полученный файл

5. Обновите параметры сервисов следующей командой 

systemctl daemon-reload

6. Запустите службу коллектора следующей командой

systemctl start kuma-collector-<id>

Где брать SOC Package и другой официальный контент?

Начиная с версии KUMA 2.1 контент от Лаборатории Касперского (правила корреляции, нормализаторы, коннекторы и т.п.) публикуются в репозитории ЛК: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/242817.htm 

Как получить SOC Package и другой коробочный контент?

1. В Web-интерфейсе KUMA нужно настроить интеграцию с репозиторием

image.png

Список серверов, до которых нужно предоставить доступ с KUMA представлен в официальной документации: https://support.kaspersky.ru/common/start/6105 

Для обновления напрямую с репозитория НЕЛЬЗЯ использовать Proxy. Если для доступа к репозиторию требуется использование Proxy или у KUMA нет доступа в Интернет напрямую, то следует использовать Kaspersky Update Utility (KUU). Подробнее в статье: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/obnovlenie-resursov-s-pomoshhiu-kaspersky-update-utility-kuu 

2. После настройки интеграции с репозиторием и Запуска обновления перейдите в Ресурсы и выберите Импортировать ресурсы

image.png

3. Далее выберите Репозиторий в качестве источника

image.png

4. Нажав на имя конкретного пакета, вы увидите информацию о пакете, журнал изменений и перечень импортируемых ресурсов.

Информация о пакете

image.png

5. Для импорта интересующих ресурсов выберите один или несколько пакетов галочкой слева от имени пакета и нажмите Импортировать внизу окна

image.png

6. Выбранные ресурсы будут импортированы.

Где взять описание правил из SOC Package?

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

image.png

Где взять мапинг коробочных нормализаторов?

Сопоставление полей коробочных нормализаторов можно скачать из официальной документации: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/267237.htm 

image.png

Форматы времени, которые понимает KUMA

May 8, 2009 5:57:51 PM
oct 7, 1970
oct 7, '70
oct. 7, 1970
oct. 7, 70
Mon Jan  2 15:04:05 2006
Mon Jan  2 15:04:05 MST 2006
Mon Jan 02 15:04:05 -0700 2006
Monday, 02-Jan-06 15:04:05 MST
Mon, 02 Jan 2006 15:04:05 MST
Tue, 11 Jul 2017 16:28:13 +0200 (CEST)
Mon, 02 Jan 2006 15:04:05 -0700
Mon 30 Sep 2018 09:09:09 PM UTC
Mon Aug 10 15:44:11 UTC+0100 2015
Thu, 4 Jan 2018 17:53:36 +0000
Fri Jul 03 2015 18:04:07 GMT+0100 (GMT Daylight Time)
Sun, 3 Jan 2021 00:12:23 +0800 (GMT+08:00)
September 17, 2012 10:09am
September 17, 2012 at 10:09am PST-08
September 17, 2012, 10:10:09
October 7, 1970
October 7th, 1970
12 Feb 2006, 19:17
12 Feb 2006 19:17
14 May 2019 19:11:40.164
7 oct 70
7 oct 1970
03 February 2013
1 July 2013
2013-Feb-03
// dd/Mon/yyy  alpha Months
06/Jan/2008:15:04:05 -0700
06/Jan/2008 15:04:05 -0700
//   mm/dd/yy
3/31/2014
03/31/2014
08/21/71
8/1/71
4/8/2014 22:05
04/08/2014 22:05
4/8/14 22:05
04/2/2014 03:00:51
8/8/1965 12:00:00 AM
8/8/1965 01:00:01 PM
8/8/1965 01:00 PM
8/8/1965 1:00 PM
8/8/1965 12:00 AM
4/02/2014 03:00:51
03/19/2012 10:11:59
03/19/2012 10:11:59.3186369
// yyyy/mm/dd
2014/3/31
2014/03/31
2014/4/8 22:05
2014/04/08 22:05
2014/04/2 03:00:51
2014/4/02 03:00:51
2012/03/19 10:11:59
2012/03/19 10:11:59.3186369
// yyyy:mm:dd
2014:3:31
2014:03:31
2014:4:8 22:05
2014:04:08 22:05
2014:04:2 03:00:51
2014:4:02 03:00:51
2012:03:19 10:11:59
2012:03:19 10:11:59.3186369
// Chinese
2014年04月08日
//   yyyy-mm-ddThh
2006-01-02T15:04:05+0000
2009-08-12T22:15:09-07:00
2009-08-12T22:15:09
2009-08-12T22:15:09.988
2009-08-12T22:15:09Z
2017-07-19T03:21:51:897+0100
2019-05-29T08:41-04 // no seconds, 2 digit TZ offset
//   yyyy-mm-dd hh:mm:ss
2014-04-26 17:24:37.3186369
2012-08-03 18:31:59.257000000
2014-04-26 17:24:37.123
2013-04-01 22:43
2013-04-01 22:43:22
2014-12-16 06:20:00 UTC
2014-12-16 06:20:00 GMT
2014-04-26 05:24:37 PM
2014-04-26 13:13:43 +0800
2014-04-26 13:13:43 +0800 +08
2014-04-26 13:13:44 +09:00
2012-08-03 18:31:59.257000000 +0000 UTC
2015-09-30 18:48:56.35272715 +0000 UTC
2015-02-18 00:12:00 +0000 GMT
2015-02-18 00:12:00 +0000 UTC
2015-02-08 03:02:00 +0300 MSK m=+0.000000001
2015-02-08 03:02:00.001 +0300 MSK m=+0.000000001
2017-07-19 03:21:51+00:00
2014-04-26
2014-04
2014
2014-05-11 08:20:13,787
// yyyy-mm-dd-07:00
2020-07-20+08:00
// mm.dd.yy
3.31.2014
03.31.2014
08.21.71
2014.03
2014.03.30
//  yyyymmdd and similar
20140601
20140722105203
// yymmdd hh:mm:yy  mysql log
// 080313 05:21:55 mysqld started
171113 14:14:20
// unix seconds, ms, micro, nano
1332151919
1384216367189
1384216367111222
1384216367111222333

Как перенести KUMA на другой диск

Кейс 1. Диск смонтирован в неверный раздел

Предположим, при подготовке сервера диск, предназначенный для хранения примонтировали не верно, например в папку /var/data. KUMA установлена в папку  /opt

Запись в /etc/fstab выглядит примерно следующим образом

/dev/sdb1               /var/data                    xfs     defaults        0 0

Последовательность действий будет следующая

1. Останавливаем сервисы kuma-*

systmctl stop kuma-*

2. Переносим данные из /opt/kaspersky/kuma в /var/data/kaspersky/kuma

3. Отмонтируем папку /var/data

umount /var/data

4. Редактируем /etc/fstab, что бы там была такая запись

/dev/sdb1               /opt                    xfs     defaults        0 0

5. Выполняем команду 

mount -a

6. Проверяем, что файловая структура /opt/kaspersky/kuma корректна, проверяем, что на всех папках owner kuma:kuma, если нет, то можно запустить команду

chown -R kuma:kuma /opt/kaspersky/kuma

7. Стартуем сервисы kuma-*

systemctl start kuma-*

Кейс 2. Появилась возможность подключить большой диск

Предположим, при подготовке сервера, для папки /opt был выделен диск sdb размером 1 ТБ, но теперь есть возможность подключить диск sdc размером 12 Тб

Запись в /etc/fstab выглядит примерно следующим образом

/dev/sdb1               /opt                  xfs     defaults        0 0

Последовательность действий будет следующая

1. Останавливаем сервисы kuma-*

systmctl stop kuma-*

2. Отмонтируем диск /dev/sdb1 из /opt и монтируем в какой-то иной раздел, например в /mnt/old_opt

mkdir /mnt/old_opt && umount /opt && mnt /dev/sdb1 /mnt/old_opt

3. Редактируем /etc/fstab, что бы там была такая запись

/dev/sdc1               /opt                    xfs     defaults        0 0

4. Запускаем команду монтирования

mount -a

5. Создаем структуру папок /opt/kaspersky/kuma

6. Переносим данные из /mnt/old_opt/kaspersky/kuma в папку /opt/kaspersky/kuma. Проверяем иерархию папок, убеждаемся, что на всех папках owner kuma:kuma, если нет, то можно запустить команду:

chown -R kuma:kuma /opt/kaspersky/kuma

7. Стартуем сервисы kuma-*

systemctl start kuma-*

8. Отмонтируем старый не нужный диск

Лайфхаки для шаблонов

В KUMA во многих местах можно использовать шаблоны для обогащения. Но мало кто знает, что в template можно использовать не только значения полей, например, {{.DeviceAddress}}, но и другой функционал шаблонов GO (ссылка).

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

Простое обогащение

Обогащать события можно не только классическими полями, например, {{.DeviceAddress}}, но и полями Extra, а также переменными.

Шаблон с обычными полем:

{{.DeviceAddress}}

Шаблон с Extra полем:

{{index .Extra "myField"}}

Шаблон с переменными (в функциях переменных):

template('Значения локальных переменных {{index . 0}} и {{index . 1}} а также {{index . 2}}', $var1, $var2, $var10)

Обогащение с условиями

Чтобы в message вставить текст "Пользователь user1 на хосте user1-pc.local (10.10.10.10) выполнил команду 'whoami'", а hostname и address не всегда могут быть указаны, но хочется красивую надпись без пустых скобок или лишних пробелов, то можно использовать условия:

Пользователь {{.DestinationNtDomain}}\{{.DestinationUserName}} на хосте {{if and .DeviceAddress .DeviceHostName}} {{.DeviceHostName}} ({{.DeviceAddress}}) {{else if .DeviceAddress}} {{.DeviceAddress}} {{ else }} {{.DeviceHostName}} {{ end }} выполнил команду "{{.DeviceCustomString4}}"

Такой же шаблон можно создать и с Extra-полями. Например, в поле события DeviceProcessName нужно записать значение из Extra-поля myField1, а в случае его отсутствия - myField2:

{{if index .Extra "myField1"}}{{index .Extra "myField1"}}{{else}}{{index .Extra "myField2"}}{{end}}

Также пример с использованием логических операторов and и or:

{{if and (eq .DeviceEventCategory "Application") ((or (eq .DeviceCustomString4 "MSSQL") (eq .DeviceCustomString4 "SQLISPackage")))}}{{.DestinationUserName}}{{end}}

Полезные ссылки

Другие варианты работы с шаблонами GO в KUMA:


Замена сертификата (веб - интерфейсе) KUMA

Процесс перевыпуска сертификата ядра в версии KUMA 3.2 был изменен! Актуальная информация приведена в онлайн-справке: https://support.kaspersky.ru/help/KUMA/3.2/ru-RU/275543.htm и https://support.kaspersky.ru/kuma/3.2/217747

Общая информация

После установки Ядра KUMA установщик создает следующие сертификаты в папке /opt/kaspersky/kuma/core/certificates:

Между взаимодействием компонентов KUMA не должно быть SSL-инспекции


Запрос сертификата от центра сертификации CA

Создаем файл openssl.cnf:

=====это пример, вписываем свои значения======
[ req ]
default_bits = 4096 # RSA key size
encrypt_key = no # Protect private key
default_md = sha256 # MD to use
utf8 = yes # Input is UTF-8
string_mask = utf8only # Emit UTF-8 strings
prompt = no # Prompt for DN
distinguished_name = server_dn # DN template
req_extensions = server_reqext # Desired extensions
[ server_dn ]
countryName = RU # ISO 3166
localityName = Moscow
organizationName = MYCOMPANY
organizationalUnitName = SOC
commonName = kuma.mycompany.ru # Should match a SAN under alt_names

[ server_reqext ]
basicConstraints = CA:FALSE
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth
subjectKeyIdentifier = hash
subjectAltName = @alt_names
[alt_names]
DNS.1 = kuma.mycompany.ru
IP.1 = 1.2.3.4

Делаем запрос на сертификат:

openssl req -new -nodes -sha256 -out external.csr -config /root/cert/openssl.cnf -keyout external.key

В текущем каталоге будут созданы файлы external.key (файл с закрытым ключом ) и external.csr (файл запроса на сертификат)

Отдаем запрос на сертификат в центр сертификации. От центра сертификации должны получить сертификат сервера и корневой сертификат центра сертификации и все сертификаты промежуточных центров сертификации если они есть.

Полученные сертификаты необходимо объединить в одну полную цепочку сертификатов в правильном порядке.

openssl x509 -inform PEM -in server.pem > external.cert
openssl x509 -inform PEM -in subca.pem >> external.cert
openssl x509 -inform PEM -in root.pem >> external.cert

Полученный файл external.cert необходимо проверить на корректность (должен быть вывод списка цепочки сертификатов):

openssl crl2pkcs7 -nocrl -certfile  external.cert  | openssl pkcs7 -print_certs -noout

openssl verify external.cert
#external.cert: OK

Проверяем корректность полученного сертификата и ключа (результат должен совпадать):

openssl x509 -noout -modulus -in external.cert | openssl md5
#(stdin)= 239994c3bd2a90507a548bf373127e18
openssl rsa -noout -modulus -in external.key | openssl md5
#(stdin)= 239994c3bd2a90507a548bf373127e18

Замена в обычной инсталляции (не кластер ядра)

Перед заменой пары external.cert external.key создайте их резервную копию.

Взять сертификат компании (вероятно это будет pfx), но может и другие форматы - например DER.
Сконвертировать его в ключ и сертификат в формате PEM (BASE64) и положить в папку например, для конвертации из PFX это будут команды ниже.
Получение ключа из kumaWebIssuedByCorporateCA.pfx:
openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nocerts -out external.key
Получение сертификата из kumaWebIssuedByCorporateCA.pfx:
openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nokeys -out external.cert
(Опционально) если ключ версии PKCS#1 то его нужно сконвертировать в PKCS#8, это можно сделать соедующей командой:
openssl pkcs8 -in private.key -topk8 -nocrypt -out new_private.key
Полученные файлы надо положить в папку: 
/opt/kaspersky/kuma/core/certificates/
Выполнить смену владельца этих файлов: 
chown kuma:kuma external.cert external.key

Перезапустить ядро: 

systemctl restart kuma-core


Замена в оказоустойчивом ядре

1. На контрольной машине или Control Plane Master получить список подов и найти кору

k0s kubectl get pod -A

2. Зайти в шел пода коры и выполнить бэкап сертификатов. (название core-deployment в каждой инсталяции уникально)

k0s kubectl exec -n kuma --stdin --tty core-deployment-779f8bf646-djszw -- /bin/bash

3. Скопировать новый сертификат с файловой системы Control Plane Master на под коры, выгрузить сертификат и ключ

k0s kubectl cp kuma-poc.pfx -n kuma core-deployment-779f8bf646-djszw:/opt/kaspersky/kuma/core/certificates

4. Найти деплоймент коры

k0s kubectl get deployments

5. Выполнить рестарт деплоймента коры

k0s kubectl rollout restart deployment -n kuma core-deployment


Настройка мониторинга источников с алертом

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

На системы приходят следующие события:

image.png

Имеем следующий источник событий (перейдите (в меню слева) на вкладку Состояние источников):

image.png

Собятия на этом источнике поступают с потоком 1 EPS.

Создание источников событий происходит один раз в минуту с именем следующего формата после парсинга: "DeviceProduct|DeviceHostname|DeviceAddress|DeviceProcessName".

Настроим политику мониторинга для этого источника: хотя бы 1 событие в течение 1 минуты. Перейдите на вкладку Политики мониторинга и наша политика будет выглядеть следующим образом:

image.png

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

image.png

Флажок статуса источника после добавления станет зеленым (означает - соответствие политике).

Убедимся, что правило корреляции мониторинга источников (в стоставе Pre-Sales-Pack) добавлено в коррелятор:

image.png

Отключаем подачу событий и получаем следующее:

image.png

В событиях:

image.png

Алерт:

image.png

Аудит изменений по активам

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

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

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

Перейдите в раздел Параметры - Аудит активов веб-интерфейсе KUMA. Щелкните (или добавьте) на тенант и выберите по каким параметрам вести аудит (чтобы производить корреляцию по изменениям необходимо добавить коррелятор):

image.png

Событие формируется на каждое изменение: по одному событию на каждое изменение (например, добавлено 5 уязвимостей - значит будет 5 событий аудита ассетов с типом "Добавление уязвимости ассета").

В событиях информацию можно найти следующим запросом:

SELECT * FROM `events` WHERE DeviceEventCategory = 'Audit assets' ORDER BY Timestamp DESC LIMIT 250

image.png

Типы событий по которым ведется аудит:

В наборе правил корреляции ПресейлПак есть пример правила корреляции по обнаружению новой уязвимости на Ассете по событию аудита в KUMA.

image.png

Тенанты в KUMA (Multitenancy)

Термины

Права на создание нового и редактирование существующего тенанта — только у пользователя с ролью General admin.

Отключить General тенант нельзя (можно переименовать), так как некоторые разделы в KUMA доступны только ему, например, Audit события KUMA складваются только в нем.

Принцип работы

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

Разделение по тенантам позволяет регулировать доступ пользователей KUMA к тем или иным событиям, правилам корреляции и т.п. Например, может быть такая архитектура – тенанты, изолированные друг от друга на уровне событий и сетевого взаимодействия.

В этом случае в Core  находятся только конфиги для всех микросервисов и алерты со всех тенантов. Пользователи подключаются к Core и отправляют поисковые запросы к хранилищам своих тенантов. Но при этом в Core летят не все события, а только результаты поиска пользователей. Трафик в этом случае минимальный. Одна Core обеспечивает единую точку администрирования всей инфраструктуры KUMA.

image.png

Кросс-тенантный коррелятор

События разных тенантов могут быть собраны разными коллекторами, но направляться в один коррелятор, где уже будет обработка событий разных тенантов. Корреляционные события и алерты будут помечены тенантом коррелятора.
 image.png

Ресурсы, используемые в корреляторе, должны принадлежать тому же тенанту, что и сам коррелятор. Иначе при сохранении система будет выдавать ошибку. Исключение Shared тенант, ресурсы общего тенанта могут быть использованы в любом корреляторе.

Отправка уведомлений по метрикам (vmalerts)

Информация преведенная в данной статье расчитана исключительно на опытных пользователей KUMA и не является официально поддерживаемым сценарием.

Описание

С помощью встроенного в продукт модуля vmalerts есть возможность отправки уведомлений по достижении метриками, определенных пользователем, пороговых значений. Уведомления отправляются пользователю, как стандартные уведомления мониторинга. Используются настройки SMTP-сервера в KUMA (https://support.kaspersky.com/KUMA/2.1/ru-RU/217936.htm), а у пользователя должна быть включена возможность получения уведомлений KUMA.

Настройка Core вне кластера k0s

Настройка vmalerts осуществляется с помощью правил, которые должны быть помещены в директорию 

/opt/kasperksy/kuma/victoria-metrics/cfg/rules/

Настройка Core в кластере k0s

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

1. На любом контроллере, используя k0s:

export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")
k0s kubectl cp --no-preserve rule.yml kuma/$POD:/opt/kaspersky/kuma/victoria-metrics/cfg/rules/ -c core

Где rule.yml - заранее созданное правило для vmalert

2. С контрольной машины, если каталог с инсталлятором, в котором сохранен сертификат для kubectl, доступен. Используя kubectl:

export KUBECONFIG=/<some_path>/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml
export POD=$(kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")
kubectl cp --no-preserve rule.yml kuma/$POD:/opt/kaspersky/kuma/victoria-metrics/cfg/rules/ -c core

Где rule.yml - заранее созданное правило для vmalert, а <some_path> - директория, из которой производилась инсталляция KUMA

Пример правила для vmalert

Пример ниже отправляет уведомление в случае, если диск был заполнен более 80% в течение 2 минут

groups:
- name: Disk space greater than 80%
  rules:
  - alert: HighDiskSpaceUsageNewAlert
    expr: max(kuma_diskOS{job="kuma"}) > 0.8
    for: 2m

Название собираемых метрик для их использования в правилах vmalert можно посмотреть в веб-интерфейсе в разделе Метрики, если перейти в режим редактирования соответствующих дашбордов grafana:

image.png

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

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

image.png

Полезные ссылки

Подробнее про vmalert и создание правил: https://docs.victoriametrics.com/vmalert.html 

Описание метрик в KUMA

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

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

В KUMA роль системы мониторинга выполняет Victoria Metrics. Информация по всем микросервисам обновляется каждые 5 секунд по HTTP-интерфейсу. А Grafana отвечает за отображение метрик, собранных с помощью Victoria Metrics.

Для просмотра всех наборов графиков щелкните сюда (на имя подсвеченное зеленым) в разделе KUMA "Метрики":

image.png

Общие метрики

Следующие метрики извлекаются из всех микросервисов KUMA

OS (Общие метрки операционной системы)

Метрики Collectors

IO (Input-Output)
Normalization
Filtration
Aggregation
Enrichment

Метрики Correlator

IO (Input-Output)
Correlation
Enrichment
Response

Метрики Storage

Clickhouse / General
Clickhouse / Insert
Clickhouse / Select
Clickhouse / Replication
Clickhouse / Networking

Метрики Core

IO (Input-Output)
Notification Feed
Schedulers

С KUMA версии 3.2:

Raft
API

С KUMA версии 3.2

Метрики KUMA Agent

Для сбора доступ в ядро по порту 8429/tcp

IO (Input-Output)

Метрики EventRouter

IO (Input-Output)

Как узнать связи между ресурсами KUMA

Данный способ является workaround, в будущих релизах будет добавлен штатный механизм отображения зависимостей.

Шаг 0. Предварительно создаем копию нужного ресурса.

image.png

Шаг 1. Выбираем ресурс и нажимаем "Удалить"

image.png

Шаг 2.

image.png

Шаг 3. Подтверждаем удаление.

image.png

Шаг 4. В случае, если от ресурса зависят другие ресурсы KUMA, удаление не произойдет и будет выведен список зависимых ресурсов. Если зависимостей не было найдено, то ресурс будет безвозвратно удален (поэтому на шаге 0 был сделан дубликат ресурса).

image.png

Устройство кластера хранилища

Кластер - логическая группа машин, обладающих всеми накопленными нормализованными событиями KUMA. Подразумевает наличие одного или нескольких логических шардов.

Shard (шард) - логическая группа машин, обладающих некоторой частью всех накопленных в кластере нормализованных событий. Подразумевает наличие одной или нескольких реплик. Если обьяснить на пальцах, механика работы кластера с несколькими шардами - это работа дисков в RAID0.

Увеличение количества шардов позволяет:

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

Replica (реплика) - машина, являющаяся членом логического шарда и обладающая одной копией данных этого шарда. Если реплик несколько - копий тоже несколько (репликация данных). Если обьяснить на пальцах, механика работы кластера с несколькими репликами - это работа дисков в RAID1.

Увеличение количества реплик позволяет:

Keeper - машина участвующая в репликации и координации (распределенные Data Definition Language (DDL) запросы) данных на уровне всего кластера хранилищ, позволяющее иметь линеаризуемую запись и нелинейное чтение данных. На весь кластер минимально требуется хотя бы 1 реплика с данной ролью. Рекомендуемое и отказоустойчивое количество таких реплик - 3. Число реплик, участвующих в координации репликации, должно быть нечетным. 

При работе keeper машины испольют RAFT алгоритм для определения лидера среди нескольких keeper машин. Лидер выполняет все операции записи и запускает автоматическое восстановление при отказе любого из подключенных серверов. Остальные узлы — подписчики или последователи, реплицируют данные с лидера и используются клиентскими приложениями для чтения. Подробнее можно почитать тут.

Описание конфигурации хранилища в инвентаре ansible

image.png

Если указаны параметры shard и replica, то машина является частью кластера и принимает участие в накоплении и поиске нормализованных событий KUMA. Если дополнительно указан параметр keeper, то машина также принимает участие в координации репликации данных на уровне всего кластера. Если keeper на хранилище не нужен, то указывается keeper: 0

Если указан только параметр keeper (отдельная машина с этой ролью), то машина не будет накапливать нормализованные события, но будет участвовать в координации репликации данных на уровне всего кластера. Значения параметра keeper должны быть уникальными, а значения shard и replica равны 0.

"Номера" реплик, шардов и киперов роли не играют. Например, конфиг с номерами реплик 1-2-3 работает так же хорошо как и с номерами 1-23-777, по смыслу это скорее айдишник, а не порядковый номер.

Если в рамках одного шарда определено несколько реплик, то значение параметра replica должно быть уникальным в рамках этого шарда. Пример для четырех серверов хранилища и трех отдельных киперов на рисунке ниже:

image.png

В точке назначения в KUMA прописываются URL всех хранилищ, кроме тех, где отдельно установлено ТОЛЬКО роль keeper.

Смотри также статью про схему взаимодействия KUMA - https://kb.kuma-community.ru/books/kuma-how-to/page/sxema-setevogo-vzaimodeistviia-kuma 

Как расширить диск с данными KUMA в случае с lvm

Кейс 1. Увеличивается объем диска

В данном примере расширяется размер диска sda и раздел sda3

  1. Расширяем диск средствами гипервизора
  2. Проверяем текущее состояние дисков

    lsblk

    image.png


  3. Проверяем свободное место

    parted /dev/sda unit MB print free

    image.png


  4. Изменяем целевой раздел (под номером 3)

    parted /dev/sda resizepart 3

    image.png



  5.  (опционально) Проверяем свободное место, чтобы убедиться, что изменения применились

    parted /dev/sda unit MB print free

    image.png



  6. (опционально) Проверяем размер физического тома

    pvdisplay

    image.png


  7. Расширяем физический том

    pvresize /dev/sda3

    image.png

  8. (опционально) Проверяем логический раздел

    lvscan

    image.png


  9. Расширяем логический раздел

    lvextend /dev/ubuntu-vg/ubuntu-lv -l +100%FREE -r

    image.png


  10. (опционально) Проверяем, что все изменения применены

    lsblk

    image.png

Кейс 2. Добавляется новый диск

В данном примере добавляется новый диск sdb

  1. Подключаем новый диск средствами гипервизора или к железному серверу
  2. Проверяем текущее состояние дисков

    lsblk

    image.png


  3. Создаем физический том

    pvcreate /dev/sdb

    image.png


  4. (опционально) Проверяем том (должны увидеть старый и новый)

    pvdisplay

    image.png

  5. Расширяем группу томов новым томом

    vgextend ubuntu-vg /dev/sdb

    image.png


  6. (опционально) Проверяем, что группа томов увеличилась в размере

    vgdisplay

    image.png


  7. Расширяем логический раздел

    lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

    image.png

  8. (опционально) Проверяем, что раздел был успешно расширен

    lvdisplay

    image.png


  9. Увеличиваем раздел файловой системы (ext4)

    resize2fs /dev/ubuntu-vg/ubuntu-lv

    image.png


    Если файловая система xfs используйте следующую команду

    xfs_growfs /dev/ubuntu-vg/ubuntu-lv

  10. (опционально) Проверяем, что все изменения применены

    df -h

    image.png