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

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

Стандартное правило (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. 

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

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

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

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

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

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

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

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

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

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

3.      В появившемся окне Создание правила корреляции на вкладке Общие укажите:

·         Название правила корреляции

·         Тенант

·         Тип (в нашем примере standard)

·         Группирующие поля (в нашем примере это поля DeviceAction, SourceAddress, SourceUserName и EventOutcome).

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

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

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

 

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

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

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

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

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

·         Политика хранения базовых событий (в нашем примере all)

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

·         Уровень важности (в нашем примере Высокий)

·         Сортировать по (в нашем примере Timestamp)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

 

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

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

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

 

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

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

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

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

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

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

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

·         DeviceAction

·         SourceAddress

·         SourceUserName

·         EventOutcome

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

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

Статья онлайн-справки «Правила корреляции»: https://support.kaspersky.ru/kuma/3.2/217783   KUMA Community правила корреляции в KUMA (CookBook): https://kb.kuma-community.ru/books/pravila-korreliacii-v-kuma-cookbook   Видео «Работа с правилами корреляции»: https://rutube.ru/video/cc57b965e06574165617b37ea1d8ac96/?playlist=891489