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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. В окне Новая папка укажите Название и нажмите Сохранить.

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

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

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

· Тенант

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

· Наследуемые поля (в нашем примере это поля DeviceAction, SourceAddress, SourceUserName и EventOutcome).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· DeviceAction

· SourceAddress

· SourceUserName

· EventOutcome

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

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

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

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

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

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

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

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

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

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

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

Бакет открывается на событие из любого селектора, не важно в каком они порядке в правиле, порядок проверяется после наполнения бакета!
Для каждого набора Identical Fields создается свой бакет.
Когда событие подпадает под селектор, коррелятор смотрит, есть ли уже бакет с нужным набором полей Identical Fields, если нет - создает, если есть - событие отправляется в существующий.
Когда под селектор с 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 селектор (Обнуление):

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

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

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

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

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

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

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

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

· Тенант

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В операционном правиле доступны только две операции над списком: set и del. Операция get не имеет смысла, поскольку она призвана обогащать корреляционное событие, а операционное правило не создает таких событий.

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

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

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

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

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

Чтобы просмотреть содержимое списка нужно открыть список активных сервисов (Active services), выбрать службу типа Correlator (поставить галочку слева) и у нее появится активная кнопка Go to active lists (Перейти в активные листы).

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