Сбор данных

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

Мы рекомендуем использовать данные за последние 2 месяца. Минимально возможный период анализа — 1 месяц, но при этом возрастет риск ложных срабатываний.

Если данных для анализа недостаточно, необходимо запустить сбор данных и подождать, пока накопится достаточный объем событий. Такой период называется «‎холодный старт» правила. Его длительность вы задаете в конфигурации правила корреляции.

Период холодного старта начинается с первого события, поступившего в правило. События, у которых временная метка (timestamp) меньше временной метки первого пришедшего в правило события, не учитываются.

Построение поведенческого профиля

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

Минимальное значение — один день. Каждое изменение в меньших отрезках времени становится весомее, что искажает показатели и повышает риск ложных срабатываний.

Счетчики формируют временные ряды, каждый из которых описывает поведение пользователя по своему признаку. Например, один из счетчиков подсчитывает количество новых IP‑адресов, которые сотрудник компании N использовал в течение дня, и составляет такой временной ряд: 1, 2, 0, 0, 3, 0, … . Временные ряды гораздо компактнее для хранения по сравнению с большим количеством сырых событий. В корреляторе хранятся только уникальные события за последний период группировки событий, которые прикрепляются к корреляционному событию при выявлении аномалии.

Анализ трафика и выявление аномалий

Когда подготовительные этапы пройдены, коррелятор может приступить к отслеживанию новых событий. Правило запускается с периодичностью, которую вы задаете в конфигурации, а не в момент поступления каждого нового события. Например, вы настроили периодичность запуска — 10 минут. В этом случае каждые 10 минут запускается анализ накопленных данных: действия пользователей сравниваются с поведенческим профилем. Принцип периодичности позволяет правилу работать стабильно при высоких нагрузках. Работа в режиме реального времени замедляет обработку потока и не дает значимых преимуществ в скорости реагирования.

Для анализа отклонений рассчитываются по формулам два показателя:

• Relative Score, или Относительный показатель, — во сколько раз текущая активность пользователя превышает его средний уровень активности.
• Z‑Score, или Стандартизированное отклонение, — насколько текущее значение отклоняется от среднего значения с учетом разброса данных.

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

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

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

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

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

Шаг 1. Создайте правило

1. Создайте коррелятор с помощью мастера установки по инструкции.
2. Установите коррелятор в вашей инфраструктуре с помощью команды по инструкции.
3. Остановите коррелятор.
4. Добавьте новое корреляционное правило в файл correlation‑rules.yaml, он находится в подкаталоге config рабочей директории коррелятора:
   • значения параметров;
   • пример конфигурации.
5. Запустите коррелятор.

Шаг 2. Запустите ретроспективное сканирование исторических данных

1. Создайте выборку событий из хранилища KUMA и экспортируйте ее в файл формата .tsv по инструкции.
2. Запустите ретроспективное сканирование по инструкции.

Шаг 3. Проверьте работу правила и настройте алерты

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

Пример вывода фрагмента журнала с сообщением об обнаруженной аномалии:

{"timestamp":"2025-10-24T06:59:43.664500130+00:00","level":"DEBG","message":"anomalies found: 1, detection took 2 ms", "version":"4.2.0","source":"kumang::components::correlation::periodical:410","thread":"correlation_rule_periodical/69df6a1b-262b-48f0-aab4-be15e822fc86/2"} 

1. Исследуйте найденные аномалии. При необходимости скорректируйте значения порогов zScore и relativeScore, чтобы минимизировать ложные срабатывания.
2. Включите алерты, когда работы по настройке правила будут закончены. Для этого установите значение false в параметре noAlert правила корреляции.

Вы можете реагировать на инцидент в интерфейсе KUMA. При обработке алертов выберите в разделе Реагирование через Active Directory действие с учетной записью:

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