Стандартное правило (standard)

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

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.2/0/217783

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

актуальные

Обучающее изменениявидео по правилам корреляции в правилахKUMA: в коррелятор.

https://rutube.ru/video/a37c939ed992377b38a592503ef4d983/?playlist=891489

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

Если частота срабатывания (Rate limiting) явна не указана, то устанавливается лимит умолчанию - 100 срабатываний в секунду. При превышении лимита правило ничего не делает. 

Политика хранения базовых событий (Base events keep policy) - указание, какие из базовых событий должны сохраняться в корреляционном. Возможно указать одно из значений:

• first (по умолчанию) - сохранять только первое базовое событие от каждого селектора в корреляционном событии
• last - сохранять только последнее базовое событие от каждого селектора в корреляционном событии
• all - сохранять все базовые события в корреляционном событии

Типовой пример правила (обнаружение сканирования портов, перебор портов >30 назначения, от одного адреса источника и назначения в течение 60 секунд):

Другие подходящие примеры для стандартных правил:

• просто много обращений к опасным URL: с разных компьютеров и к разным URL
• много обращений к одному и тому же опасному URL с разных компьютеров
• много обращений к опасным URL, в том числе разным, с одного компьютера
• много обращений с одного и того же компьютера к одному и тому же опасному URL
  

Стандартные правила разбивают все анализируемые события на группы (так называемые «корзины», buckets) с совпадающими значениями полей, перечисленных в параметре Группируемые поля (Identical fields) и затем обрабатывает каждую группу независимо от других. Критерии срабатывания применяются отдельно в каждой такой группе. Состояние всех групп хранится в памяти коррелятора.

Те поля, которые указываются в группирующих для ВСЕХ селекторов должны иметь одинаковое значение, чтобы правило сработало.

Бакет (Окно корреляции):

1. Бакет открывается на событие из любого селектора, не важно в каком они порядке в правиле, порядок проверяется после наполнения бакета!
2. Для каждого набора Identical Fields создается свой бакет.
3. Когда событие подпадает под селектор, коррелятор смотрит, есть ли уже бакет с нужным набором полей Identical Fields, если нет - создает, если есть - событие отправляется в существующий.
4. Когда под селектор с Unique fields подпадает событие, то проверяется, есть ли уже в бакете события с таким же набором значений для Unique Fields, если есть, то событие не учитывается.

Пример для Identical Fields с полями RequestUrl и SourceAddress:

В более общем смысле параметр Время жизни контейнера (Window) определяет время жизни группы. Принцип такой:

• identical fields определяет, на какие группы разбивать события
• селекторы определяют, какие событие будут включены в группы (если событие не соответствует ни одному селектору, оно не попадет ни в одну группу)
• если событие соответствует селектору и уже есть группа с таким же набором значений идентичных полей, как в событии, событие добавляется в эту группу
• если событие соответствует селектору, но его значения идентичных полей не соответствуют ни одной группе, создается новая группа с временем жизни, заданным параметром Window
• по истечении времени жизни группы, группа удаляется
• если позже поступает новое событие с набором значений идентичных параметров группы, которой больше нет, создается новая группа и отсчет времени жизни начинается заново

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

Правило срабатывает, если группа за время жизни накапливает число событий, указанное в параметре Порог срабатывания (Threshold) селектора. 

В общих настройках стандартного правила есть еще параметр Уникальные поля (Unique fields). Он не является обязательным, но он позволяет считать в группах только события с уникальными значениями выбранных полей. При добавлении событий в группу правило будет сравнивать значение уникальных полей нового события со значениями уникальных полей событий, которые уже есть в группе. Если комбинация значений уникальных полей нового событий уже встречается у одного из событий в группе, новое событие отбрасывается и в группу не попадает.

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

• OnНа firstпервом thresholdсрабатывании правила  — создавать корреляционное событие только после первого превышения порога, а двукратное, трехкратное и т.д. превышение порога за время жизни группы игнорировать. Например, если при пороге 3 за 30 секунд группа накопит 10 событий, корреляционное событие все равно будет одно - после третьего накопленного события
• OnНа everyкаждом thresholdсрабатывании правила — создавать корреляционное событие после каждого превышения порога за время жизни группы. Если группа накопит 10 событий при пороге 3, будет создано 3 корреляционных события: после 3-го, 6-го и 9-го события в группе
• OnНа subsequentпоследующих thresholdсрабатываниях правила — создавать корреляционные событие при всех превышениях порога, кроме первого. Например, при пороге 3 после 6-го, 9-го и т.д. события. Так можно по-разному реагировать на первое переполнение порога и последующие. Например, можно настроить отправлять на вход коррелятора только первое корреляционное событие, но в хранилище писать все. Или пополнять активный список только данными из первого события, а при последующих превышениях порога этого не делать, так как в последующих событиях нет новых артефактов для списка
• OnПо timeoutистечении времени жизни контейнера — в стандартных правилах есть еще возможность настройки действий по окончании времени жизни группы. Это действие используется в связке с опцией Recovery (Обнуление) в настройках селектора, в каких случаях это уместно и как именно это работает рассматривается ниже. Обнуляющие селекторы можно использовать и не только с действием onTimeout. 

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

Пример правила с несколькими селекторами:

Можно также создать рекавериRecovery правило. Например, когда событие типа «Вредоносное ПО удалено» не обнаружено в течение 5 минут после получения события «Вредоносное ПО обнаружено».

Recovery селектор (Обнуление):

1. Бакет открывается только на событие из обычного селектора, на событие из recovery-селектора бакет не открывается никогда!
2. Место нахождения селектора с recovery не имеет значения, как только в бакет попадут все нужные recovery-события бакет будет закрыт!
3. На recovery-селектор не влияет настройка фильтра Order By.
4. Если нужно, чтобы произошло событие А, и не произошло событие Б, при этом событие Б может произойти раньше А, нужно использовать активные листы, т.к. с помощью recovery-селектора такой логики не достичь (см п.1).

Создание правила корреляции типа Standard

В качестве примера создадим стандартное правило корреляции для обнаружения 3 (трех) неудачных попыток входа в веб-интерфейс KUMA.

Чтобы настроить правило корреляции типа Standard:

1.

• Перейдите в раздел Ресурсы →  Правила корреляции.

2.

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

3.

• В появившемся окне Создание правила корреляции на вкладке Общие укажите:
  • Название правила корреляции
  • Тенант
  • Тип (в нашем примере standard)
  • Группирующие поля (в нашем примере это поля DeviceAction, SourceAddress, SourceUserName и EventOutcome).

Стандартные правила разбивают все поступающие события на группы («бакеты»), с совпадающими значениями полей из Группирующих полей. Затем каждая сформировавшаяся группа обрабатывается независимо от других. Критерии срабатывания применяются отдельно в каждой такой группе.

По аналогии с Наследуемыми полями правил Simple значения полей, перечисленных в Группирующих полях, будут скопированы в корреляционное событие.

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

• Время жизни контейнера (в нашем примере «в течение какого периода времени мы ожидаем 3 неудачные попытки входа»)

Время жизни контейнера («бакета») в секундах. Отсчет времени начинается при создании контейнера, когда контейнер получает первое событие.

• Уникальные поля

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

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

• Политика хранения базовых событий (в нашем примере all)all). Позволяет определить, какие базовые события требуется поместить в корреляционное событие.
• Уровень важности (в нашем примере Высокий)Высокий)
• Сортировать по (в нашем примере Timestamp)Timestamp)

Поле события, на основании которого события будут отсортированы в группе («бакете»).

• Опционально Описание

4.

• Перейдите на вкладку Селекторы,Селекторы, укажите Название селектора,селектора, Порог срабатывания селектора (количество событий; в нашем примере мы ожидаем 3 события неудачной попытки входа) и добавьте условия (Добавить условие)условие) согласно скриншоту ниже. На вкладке Селекторы с помощью условий определяется какие события будут включены в группы (если событие не соответствует ни одному селектору, оно не попадет ни в одну группу).

Условия можно задавать как в виде конструктора, так и в виде кода.

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

Для повышения производительности более специфичные условия рекомендуется размещать выше, например, условие DeviceAction = ‘user login’ является более специфичным, чем условие DeviceProduct = ‘KUMA’.

В стандартном правиле можно добавить несколько селекторов.

5.

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

6.     

Добавьте обогащение, нажав Добавить обогащение:

·

Укажите Исходный тип – Шаблон

·        

В поле Шаблон добавьте следующий текст:

Обнаружено 3 (три) неудачные попытки входа в веб-интерфейс KUMA под учетной записью {{.SourceUserName}} c IP-адреса {{.SourceAddress}} в течение 60 секунд

·

В поле Целевое поле укажите Message

Данное обогащение является опциональным и используется для информирования аналитика какое потенциально вредоносное действие было совершено

7.

Нажмите Создать.

 

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

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

2.

В окне Корреляторы выберите сервис Коррелятора, к которому будет привязано правило и нажмите ОК.

 

Чтобы коррелятор применил изменения конфигурации необходимо обновить параметры сервиса:

3.

Перейдите в Ресурсы →  Активные сервисы.

4.     

Нажмите ПКМ на сервис Коррелятора и выберите Обновить параметры.

Чтобы проверить корректность работы созданного правила корреляции выполните 3 неудачных попытки входа в веб-интерфейс KUMA в течение 60 секунд.

Для проверки, что созданное правило сработало:

1.

Перейдите в Алерты.

2.     

Убедитесь, что в списке алертов присутствует алерт Обнаружено 3 (три) неудачных попытки входа в веб-интерфейс KUMA

3.

Откройте карточку алерта, нажав на алерт.

4.     

В карточке алерта в секции Связанные события раскройте созданное корреляционное событие и далее нажмите на корреляционное событие.

5.

Убедитесь, что в окне Информация о корреляционном событии присутствуют поля, которые при создании правила корреляции были добавлены в Группирующие поля:

• DeviceAction
• SourceAddress
• SourceUserName
• EventOutcome

6.

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

7.     

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

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

KUMA Community правила корреляции в KUMA (CookBook): https://kb.kuma-community.ru/books/pravilakorreliacii-v-kuma cookbook Видео «Работа с правилами корреляции»: https://rutube.ru/video/cc57b965e06574165617b37ea1d8ac96/ playlist=891489