Типы правил корреляции

• Простое правило (simple)
• Стандартное правило (standard)
• Операционное правило (operational)

Простое правило (simple)

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

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

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

Простое правило (simple) — срабатывает при обнаружении каждого события, удовлетворяющего условиям в одном селекторе.

Типовой пример правила:

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

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

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

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

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

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

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

• Не создавать алерт - флажок, ВЫключающий создание алертов при срабатывании правила корреляции. По умолчанию этот флажок снят.

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

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

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

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

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

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

• Перейдите в раздел Ресурсы →  Правила корреляции.
• Опционально слева нажмите Добавить папку для создания отдельной папки под пользовательские правила.
• В окне Новая папка укажите Название и нажмите Сохранить.

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

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

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

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

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

• •  Уровень важности (в нашем примере Средний)
  • Опционально Описание

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

 

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

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

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

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

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

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

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

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

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

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

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

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

• Перейдите в Ресурсы →  Активные сервисы.
• Нажмите ПКМ на сервис Коррелятора и выберите Обновить параметры.

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

• Перейдите в Алерты.
• Убедитесь, что в списке алертов присутствует алерт Неудачная попытка входа в веб-интерфейс KUMA

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

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

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

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

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.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). Он не является обязательным, но он позволяет считать в группах только события с уникальными значениями выбранных полей. При добавлении событий в группу правило будет сравнивать значение уникальных полей нового события со значениями уникальных полей событий, которые уже есть в группе. Если комбинация значений уникальных полей нового событий уже встречается у одного из событий в группе, новое событие отбрасывается и в группу не попадает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

• Перейдите в Ресурсы →  Активные сервисы.
• Нажмите ПКМ на сервис Коррелятора и выберите Обновить параметры.

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

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

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

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

• Убедитесь, что в окне Информация о корреляционном событии присутствуют поля, которые при создании правила корреляции были добавлены в Группирующие поля:
  • DeviceAction
  • SourceAddress
  • SourceUserName
  • EventOutcome
• Убедитесь, что в окне Информация о корреляционном событии в поле Message добавлен текст согласно ранее настроенному обогащению для информирования аналитика какое потенциально вредоносное действие было совершено.
• Убедитесь, что при раскрытии корреляционного события отображается 3 события неудачной попытки входа, которые стали триггером для срабатывания правила корреляции

Операционное правило (operational)

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

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

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

Обучающее видео по правилам корреляции в KUMA: https://rutube.ru/video/a37c939ed992377b38a592503ef4d983/?playlist=891489

Операционное правило (operational) — наполняет активные листы или контекстные таблицы без создания корреляционного события, механика работы аналогична простому правилу корреляции. С помощью списков можно отслеживать закономерности на длительных промежутках времени. Активный лист и контектсные таблицы хранятся в памяти коррелятора (и кешируются на диск), так что состояние листа/таблицы не теряется при перезагрузке службы или сбое.

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

В операционном правиле доступны следующие операции над листами и таблицами: Сложить, Установить, Удалить и Объединить (только для таблиц). 

Пример правила:

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

При записи в активный лист, в качестве ключевого поля могут выступать несколько занчений полей события, для составления комбинированного ключа, при этом в значении ключа это быдет выглядеть так: поле1|поле2|поле3 сравнивать с этим впоследствии можно будет только с целым ключом, а не с какой-то его частью.

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

Если используется несколько сервисов коррелятора, использующих один и тот же ресурс активного листа/списка, у каждого коррелятора будет свое состояние этого листа.

Чтобы просмотреть содержимое активного списка/таблицы необходимо перейти в раздел Ресурсы →  Активные листы или Контекстные таблицы и далее открыть лист/таблицу. В секции Контент будут отображаться данные записанные в лист/таблицу.

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