07 февраля 2024
KUMA
Установка системы. Подключение активов.
Цикл "Kaspersky Symphony XDR"
Вводная статья
Блок KUMA
Блок KATA
Блок KEDR
Блок KUMA
- KUMA. Введение: обзор архитектуры
- Установка системы. Подключение активов
- Парсинг логов. Подключение логов CheckPoint, KSC, KSMG, Microsoft AD
- Написание своего парсера и нормализации
- Обогащение логов в коллекторе
- Работа с простыми алертами и инцидентами. Создание простых корреляционных правил
- Работа с тяжелыми алертами. Создание тяжелых корреляционных правил
- Оповещения в телеграмм
- Построение дашбордов
- Symphony XDR, автоматическое реагирование через агенты
Блок KATA
- Защита периметра. Теория
- Защита периметра. Развертывание системы
- Защита периметра. Развертывание центрального узла
- Защита периметра. Настройка платформы
- Защита периметра. Подключение источника
- Защита периметра. Тестирование
Блок KEDR
Введение
Приветствуем читателей во второй статье блока KUMA из цикла «Kaspersky Symphony XDR»! От введения и базового знакомства с решением мы переходим к непосредственному началу работы с системой. В рамках данной статьи мы опишем различные требования, предъявляемые к системе (например, к железу).
SIEM — это большой вычислительный сервис, которой всегда требует множество ресурсов:
Закупка оборудования под SIEM-систему является значимым пунктом расходов, который стоит иметь в виду, особенно в современных реалиях.
Основной плюс решения KUMA состоит в том, что для него не требуется такого большого количества ресурсов, как для других схожих продуктов, что может значительно сэкономить ваш бюджет.
После описания основных требований мы с вами перейдем непосредственно к установке системы (это довольно простой процесс). А в конце статьи вместе настроим интеграцию c KSC-сервером, с которого система возьмет все данные по активам вашей организации. В последующем это очень поможет при работе с инцидентами.
SIEM — это большой вычислительный сервис, которой всегда требует множество ресурсов:
- диск на хранение информации;
- оперативная память;
- процессоры для обработки данных
Закупка оборудования под SIEM-систему является значимым пунктом расходов, который стоит иметь в виду, особенно в современных реалиях.
Основной плюс решения KUMA состоит в том, что для него не требуется такого большого количества ресурсов, как для других схожих продуктов, что может значительно сэкономить ваш бюджет.
После описания основных требований мы с вами перейдем непосредственно к установке системы (это довольно простой процесс). А в конце статьи вместе настроим интеграцию c KSC-сервером, с которого система возьмет все данные по активам вашей организации. В последующем это очень поможет при работе с инцидентами.
Требования
Сначала давайте разберемся, какие существуют способы развертывания KUMA SIEM. Здесь все стандартно: можно установить все на одном сервере (all-in-one), либо построить полноценный кластер (распределенная установка), в котором разные ноды будут выполнять отдельные функции.
Системные требования для распределенной установки лучше оценивать по результатам пилотного тестирования и исходя из рекомендаций продуктовой команды (в зависимости от интенсивности входящего потока).
Как упоминалось раньше: KUMA является высокопроизводительной системой.
В качестве примера в таблице представлены требования для обработки 40 000 EPS:
Системные требования для распределенной установки лучше оценивать по результатам пилотного тестирования и исходя из рекомендаций продуктовой команды (в зависимости от интенсивности входящего потока).
Как упоминалось раньше: KUMA является высокопроизводительной системой.
В качестве примера в таблице представлены требования для обработки 40 000 EPS:
Эти показатели зависят от типа анализируемых событий и от эффективности парсера. Следует также учитывать, что большее количество ядер эффективнее, чем меньшее, но с более высокой частотой процессора.
Можно заметить, что в таблице представлены довольно небольшие системные требования, если сравнивать их со многими другими SIEM-системами. Это достигается путем использования ClickHouse в качестве базы данных для всех событий, а также высокой оптимизацией всего функционала.
Для установки в режиме «все в одном», предназначенном для демонстрационных целей, а также пригодным для небольших организаций, рекомендуется следующая конфигурация:
— Процессор с 4 вычислительными ядрами (каждый поток Hyperthreading считается отдельным ядром);
— 16 GB оперативной памяти;
— 100 GB дискового пространства минимум
В данном документе можно посмотреть актуальные аппаратные и программные требования.
Службы Kaspersky Unified Monitoring and Analysis Platform можно установить, как на физические, так и на виртуальные сервера.
Поддерживается установка в виртуальных средах:
Функционал устанавливается на следующие операционные системы:
— Oracle Linux 8.6 и выше
— Astra Linux Special Edition 1.7 и выше
При подготовке сервера рекомендуется использовать файловую систему XFS. Kaspersky Unified Monitoring and Analysis Platform размещает свои файлы в папке /opt, поэтому рекомендуется делать /opt отдельным разделом и выделять под него все дисковое пространство (за исключением 16 ГБ, требуемых для операционной системы).
Можно заметить, что в таблице представлены довольно небольшие системные требования, если сравнивать их со многими другими SIEM-системами. Это достигается путем использования ClickHouse в качестве базы данных для всех событий, а также высокой оптимизацией всего функционала.
Для установки в режиме «все в одном», предназначенном для демонстрационных целей, а также пригодным для небольших организаций, рекомендуется следующая конфигурация:
— Процессор с 4 вычислительными ядрами (каждый поток Hyperthreading считается отдельным ядром);
— 16 GB оперативной памяти;
— 100 GB дискового пространства минимум
В данном документе можно посмотреть актуальные аппаратные и программные требования.
Службы Kaspersky Unified Monitoring and Analysis Platform можно установить, как на физические, так и на виртуальные сервера.
Поддерживается установка в виртуальных средах:
- VMWare 6.5 и выше.
- Hyper-V для Windows Server 2012 R2 и выше.
- KVM Qumu version 4.2 и выше.
- ПК СВ «Брест» РДЦП.10 001−02
Функционал устанавливается на следующие операционные системы:
— Oracle Linux 8.6 и выше
— Astra Linux Special Edition 1.7 и выше
При подготовке сервера рекомендуется использовать файловую систему XFS. Kaspersky Unified Monitoring and Analysis Platform размещает свои файлы в папке /opt, поэтому рекомендуется делать /opt отдельным разделом и выделять под него все дисковое пространство (за исключением 16 ГБ, требуемых для операционной системы).
Подготовка установки
Процесс установки операционной системы пропустим в рамках этого курса, устанавливать будем Oracle Linux версии 8.6.
Ссылка на образ - https://yum.oracle.com/ISOS/OracleLinux/OL8/u5/x86_64/OracleLinux-R8-U5-x86_64-dvd.iso.
При установке KUMA к операционной системе существует перечень определенных требований:
1 ) Во-первых, нужно проверить, что версия python не ниже 3.6.
Ссылка на образ - https://yum.oracle.com/ISOS/OracleLinux/OL8/u5/x86_64/OracleLinux-R8-U5-x86_64-dvd.iso.
При установке KUMA к операционной системе существует перечень определенных требований:
1 ) Во-первых, нужно проверить, что версия python не ниже 3.6.
2) Выключить модуль SELinux.
Для этого открываем файл конфигурации
$ vi /etc/selinux/config
и изменяем параметр SELINUX на disabled:
SELINUX=disabled
После чего перезагружаем систему.
3) Убедиться, что в операционной системе установлена система управления пакетами pip3.
4)Установить пакеты netaddr, firewalld
pip3 install netaddr
yum install firewalld
5) Полное наименование сервера, состоящее из имени сервера и, как минимум, домена первого уровня, на котором запускается установщик, должно отличаться от localhost или localhost.<домен> . Можно проверить через команду hostnamectl имя сервера и если оно не соответствует требованиям, переименовать через эту же команду.
Для этого открываем файл конфигурации
$ vi /etc/selinux/config
и изменяем параметр SELINUX на disabled:
SELINUX=disabled
После чего перезагружаем систему.
3) Убедиться, что в операционной системе установлена система управления пакетами pip3.
4)Установить пакеты netaddr, firewalld
pip3 install netaddr
yum install firewalld
5) Полное наименование сервера, состоящее из имени сервера и, как минимум, домена первого уровня, на котором запускается установщик, должно отличаться от localhost или localhost.<домен> . Можно проверить через команду hostnamectl имя сервера и если оно не соответствует требованиям, переименовать через эту же команду.
Установка системы
Так как в рамках статей мы проводим установку в режиме «все в одном», нам с вами потребуется проделать несколько простых действий.
Сначала установочный пакет переносим на сервер через winscp или любой другой удобный для вас инструмент.
Сначала установочный пакет переносим на сервер через winscp или любой другой удобный для вас инструмент.
Установочный пакет не находится в открытом доступе, поэтому его необходимо запрашивать отдельно. Также вам потребуется тестовая лицензия, за которой тоже нужно будет обратиться к вашему интегратору.
Далее подготавливаем файл конфигурации: single.inventory.yml, в котором будем задавать параметры для установки системы.
Изначально он содержит в себе такие настройки:
Далее подготавливаем файл конфигурации: single.inventory.yml, в котором будем задавать параметры для установки системы.
Изначально он содержит в себе такие настройки:
А после всех изменений он будет выглядеть вот так:
Основные отличие в двух конфигах это название системы, на которой будет устанавливаться тот или иной компонент.
Так как у нас «все в одном», мы везде указываем «kuma.tssolution.local» вместо «kuma.example.com».
Также мы увеличили параметр размера лог файла для базы данных mongo в настройках kuma_core.
Устанавливаем систему от учетки root. В настройках kuma_storage указаны параметры для хранения всех событий: выставляем сколько шардов в индексе у нас будет настроено, количество реплик (дубликатов события) и роль keeper. Если бы у нас была распределенная настройка с несколькими базами хранения, то можно было бы настроить отказоустойчивость через настройки количества шардов и реплик.
Из других настроек мы указываем параметр deploy_example_services в true. Этот параметр указывает на необходимость автоматически при установке развернуть сервисы доступные из коробки, а именно предустановленные коллекторы, службу коррелятора и службу хранилища. В любой момент ненужные сервисы можно будет удалить.
И теперь последний шаг перед началом непосредственного процесса установки сервера: подкидываем лицензию.
Переносим файл ключа на сервер и копируем его в директорию /kuma-ansible-installer/roles/kuma/files/, затем переименовываем в license. key
Далее запускаем скрипт установки сервера из корневой директории пакета kuma siem.
./install.sh single.inventory.yml
Затем нужно принять лицензионное соглашение, после чего скрипт устанавливает все компоненты продукта, в соответствии с заданными в yml-файле параметрами.
Выглядит установка следующим образом.
Принимаем лицензионное соглашение:
Так как у нас «все в одном», мы везде указываем «kuma.tssolution.local» вместо «kuma.example.com».
Также мы увеличили параметр размера лог файла для базы данных mongo в настройках kuma_core.
Устанавливаем систему от учетки root. В настройках kuma_storage указаны параметры для хранения всех событий: выставляем сколько шардов в индексе у нас будет настроено, количество реплик (дубликатов события) и роль keeper. Если бы у нас была распределенная настройка с несколькими базами хранения, то можно было бы настроить отказоустойчивость через настройки количества шардов и реплик.
Из других настроек мы указываем параметр deploy_example_services в true. Этот параметр указывает на необходимость автоматически при установке развернуть сервисы доступные из коробки, а именно предустановленные коллекторы, службу коррелятора и службу хранилища. В любой момент ненужные сервисы можно будет удалить.
И теперь последний шаг перед началом непосредственного процесса установки сервера: подкидываем лицензию.
Переносим файл ключа на сервер и копируем его в директорию /kuma-ansible-installer/roles/kuma/files/, затем переименовываем в license. key
Далее запускаем скрипт установки сервера из корневой директории пакета kuma siem.
./install.sh single.inventory.yml
Затем нужно принять лицензионное соглашение, после чего скрипт устанавливает все компоненты продукта, в соответствии с заданными в yml-файле параметрами.
Выглядит установка следующим образом.
Принимаем лицензионное соглашение:
Идет процесс установки:
Идёт процесс:
Установка завершена:
Заходим в веб по адресу :7220/">https://<IP_address_core>:7220/ (в моем случае IP_address_core - 10.10.30.195) и проверяем что все работает, учетка для входа admin, пароль mustB3Ch@ng3d! . Все сервисы подсвечены зеленым цветом. В cледующих статьях мы более детально затронем эти настройки.
Активы
Одной из первых задач, с которым при работе с решением сталкивается инженер ИБ — это наполнение активов в SIEM.
По-сути это карточки всех ИТ объектов, которые у вас есть в инфраструктуре. Они помогают при расследовании инцидентов и дополняют информацию о хосте на котором произошел инцидент ИБ. А также в KUMA SIEM можно использовать значения из активов для корреляции инцидентов.
Основной способ импорта — интеграция с Kaspersky Security Center.
Для этого заходим в настройки Settings -> Kaspersky Security Center -> Add Connection. Вписываем адрес: порт сервера KSC (10.10.30.48:13 299) и учетку администратора KSC.
По-сути это карточки всех ИТ объектов, которые у вас есть в инфраструктуре. Они помогают при расследовании инцидентов и дополняют информацию о хосте на котором произошел инцидент ИБ. А также в KUMA SIEM можно использовать значения из активов для корреляции инцидентов.
Основной способ импорта — интеграция с Kaspersky Security Center.
Для этого заходим в настройки Settings -> Kaspersky Security Center -> Add Connection. Вписываем адрес: порт сервера KSC (10.10.30.48:13 299) и учетку администратора KSC.
И если все проходит успешно, то подтягивание активов автоматически начнется в виде нового TASK. Все таски можно посмотреть в Task Manager. Там же можно проверить их статус, и результат работы. В настройке KSC вы увидите ваш connection, как на картинке ниже.
Продолжим и посмотрим на список активов, который импортировался с KSC:
Как видно: практически все активы исходно попадают в группу Uncategorized assets. Активы, которые не были импортированы можно добавить вручную. Также все атрибуты придется указать вручную. Есть и возможность с помощью скриптов загрузить результат сканирования активов, например, с PT VM для будущей версии KUMA 3.
Дальнейшая работа специалиста заключается в том, чтобы разбить все активы по категориям. Причем в каждой категории необходимо указывать не просто название, а еще и уровень критичности.
Существующие уровни критичности: Low, Medium, High, Critical.
Давайте попробуем создать категорию и наполнить ее активами.
Дальнейшая работа специалиста заключается в том, чтобы разбить все активы по категориям. Причем в каждой категории необходимо указывать не просто название, а еще и уровень критичности.
Существующие уровни критичности: Low, Medium, High, Critical.
Давайте попробуем создать категорию и наполнить ее активами.
Во-первых, видим, что наполнять категорию можно тремя способами:
Попробуем создать динамическое категорирование на основе операционной системы:
- Manually: вручную переносим актив;
- Active: динамически, если удовлетворяют определенным условиям, в зависимости от атрибутов актива;
- Reactive: с помощью правил корреляции, попозже более детально рассмотрим этот тип
Попробуем создать динамическое категорирование на основе операционной системы:
В условиях указываем, что если в имени OS есть значение Windows Server, то хосты добавляются в категорию Windows Servers.
И создадим категорию Windows hosts в который добавим все активы с установленной виндой.
И создадим категорию Windows hosts в который добавим все активы с установленной виндой.
Смотрим результат заполнения категорий. Категория Windows Hosts:
Категория Windows servers:
Как видим сервер WIN-DSRGNOAI07T присутствует в обоих списках, так как подпадает под условия обоих категорий. Теперь посмотрим из чего состоит актив.
Здесь собрана вся информация об активе: включая базовые атрибуты, список установленного ПО, характеристики по ресурсам и список имеющихся уязвимостей.
Зачем же нужны активы?
Коллекторы используют базу активов для неявного обогащения событий идентификаторами активов. Такое обогащение позволит аналитику изучить сведения о компьютерах при анализе событий.
Событие дополняется только внутренними полями: DeviceAssetID, SourceAccountID, DestinationAssetID.
При анализе инцидента специалисту нужно быстро получить информацию о том:
Поэтому наполнение активов это очень важная задача с точки зрения расследования инцидентов.
Коллектор получает информацию об активах от ядра и заполняет в событиях поле с идентификатором актива в следующих случаях:
Также можно настроить событие аудита, например, создаем корреляционное событие при появлении новой уязвимости на активе.
После того как мы с вами наполнили базу активов, можно переходить к следующей важной задаче: заведение событий в KUMA SIEM.
Этому и будут посвящены следующие главы курса. Оставайтесь с нами!
Автор статьи: Глеб Ряскин, Инженер отдела интеграций TS Solution
Зачем же нужны активы?
Коллекторы используют базу активов для неявного обогащения событий идентификаторами активов. Такое обогащение позволит аналитику изучить сведения о компьютерах при анализе событий.
Событие дополняется только внутренними полями: DeviceAssetID, SourceAccountID, DestinationAssetID.
При анализе инцидента специалисту нужно быстро получить информацию о том:
- где произошел инцидент;
- есть ли у него существующие уязвимости;
- какое ПО установлено, на основе этой информации
- понятно ли, насколько критичен инцидент и как быстро его надо взять в работу и разрешить
Поэтому наполнение активов это очень важная задача с точки зрения расследования инцидентов.
Коллектор получает информацию об активах от ядра и заполняет в событиях поле с идентификатором актива в следующих случаях:
- Если соответствующее поле с именем содержит FQDN актива;
- Если соответствующее поле с адресом содержит адрес актива, а поле с именем не заполнено
Также можно настроить событие аудита, например, создаем корреляционное событие при появлении новой уязвимости на активе.
После того как мы с вами наполнили базу активов, можно переходить к следующей важной задаче: заведение событий в KUMA SIEM.
Этому и будут посвящены следующие главы курса. Оставайтесь с нами!
Автор статьи: Глеб Ряскин, Инженер отдела интеграций TS Solution