Правила сегментации

В данном разделе представлен обзор структуры, принципов работы и процесса создания правил сегментации в R-Vision SIEM. Управление правилами сегментации в системе осуществляется в разделе Экспертиза.

О правилах сегментации

Правило сегментации в системе R-Vision SIEM представляет собой структурированный объект данных, определяющий логику для классификации и обработки корреляционных событий, на основе которых правило сегментации создает оповещения. Каждое правило сегментации, оформленное в формате RObject (.ro), содержит набор параметров для группировки событий по определенным критериям, таким как тип события, источник или другие атрибуты.

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

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

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

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

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

Применение правил сегментации

В системе R-Vision SIEM, правила сегментации задают логику разделения и классификации корреляционных событий для формирования оповещений на основе анализа, выполненного правилами корреляции. Правила сегментации применяются к потоку событий на конвейере обработки в рамках элемента сервис оповещений, который использует эти правила для дополнительной обработки и группировки корреляционных событий, позволяя задавать многоуровневые условия для создания оповещений.

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

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

Работа с правилом сегментации

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

Создание правила сегментации

Чтобы добавить правило сегментации:

  1. Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы.

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

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

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

  4. Нажмите на кнопку Опубликовать версию. Система создаст правило сегментации и отобразит соответствующее уведомление. Новое правило появится в таблице раздела Экспертиза.

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

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

Изменение правила сегментации

Чтобы изменить правило сегментации:

  1. Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы.

  2. Нажмите на строку правила сегментации в списке. Система отобразит в правой части экрана карточку этого правила с подробной информацией о нем.

  3. Нажмите на кнопку действий (more vertical) в верхнем правом углу карточки и выберите опцию Изменить. Отобразится окно настроек правила.

    Вы также можете открыть окно настроек с помощью кнопки в нижней части карточки:

    • Для опубликованной версии: нажмите на кнопку Просмотр в нижней части карточки. Система отобразит окно просмотра настроек элемента экспертизы. Нажмите на кнопку Изменить в правом нижнем углу окна.

    • Для черновика: нажмите на кнопку Изменить в нижней части карточки.

  4. Внесите требуемые изменения в конфигурацию правила сегментации.

  5. Нажмите на кнопку Обновить версию. Система опубликует новую версию правила сегментации с измененной конфигурацией и отобразит соответствующее уведомление.

    При публикации новой версии элемента экспертизы требуется увеличить его текущую версию в поле version.

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

Удаление правила сегментации

Удаление доступно только для элементов экспертизы с типом создания Пользовательский.

Удаление недоступно для элементов экспертизы, используемых в других сущностях системы.

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

  1. Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы.

  2. Нажмите на строку правила сегментации в списке. Система отобразит в правой части экрана карточку этого правила с подробной информацией о нем.

  3. Нажмите на кнопку действий (more vertical) в верхнем правом углу карточки и выберите опцию Удалить. Отобразится окно подтверждения удаления правила.

  4. Нажмите на кнопку Удалить. Система удалит правило сегментации и отобразит соответствующее уведомление. Удаленное правило будет исключено из списка элементов экспертизы.

Вы также можете удалить группу элементов экспертизы. Для этого:

  1. Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы.

  2. Установите флажки напротив тех элементов, которые вы хотите удалить, в левом столбце таблицы.

  3. Нажмите на кнопку trash на панели инструментов. Отобразится окно удаления.

  4. Нажмите на кнопку Удалить. Система удалит выбранные элементы и отобразит соответствующее уведомление. Удаленные элементы будет исключены из списка элементов экспертизы.

Структура правила сегментации

Правило сегментации в системе R-Vision SIEM представляет собой структурированный объект данных в формате RObject (.ro), который включает в себя ряд обязательных и опциональных полей для определения процесса сегментации.

Поле Описание Тип данных Обязательное поле

id

Уникальный идентификатор правила сегментации.

строка

да

name

Название правила сегментации.

строка

да

type

Тип элемента. Всегда имеет значение segmentation_rule для элементов экспертизы этого типа.

строка

да

version

Версия правила сегментации, представленная в формате Semantic Versioning.

строка

да

author

Имя и контактные данные автора правила сегментации.

строка

нет

description

Описание правила сегментации, содержащее дополнительную информацию о его назначении и функциональности.

строка

нет

data_source

Список источников данных, с которыми совместимо правило сегментации. Используется для классификации и быстрого поиска элементов экспертизы в системе.

массив строк

массив объектов

нет

tags

Список тегов, присвоенных правилу сегментации для классификации и быстрого поиска.

массив строк

нет

group_by

Поля для группировки событий в рамках процесса сегментации. Каждая группа агрегируется независимо. Если ничего не указано — все поступающие события будут объединяться в одну группу.

массив строк

нет

threshold

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

число

нет

timeout

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

число

нет

alert_name

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

строка

нет

tests

Блок тестирования правила сегментации, содержащий массив тестовых сценариев и условия для проверки логики сегментации.

объект

нет

Структура data_source

Поле data_source, представленное массивом строк, имеет структуру:

data_source:
- <platform> # Платформа или информационная система
- <source> # Источник событий.
# События (EventId) или путь к журналу событий:
- <EventID_1>
- <EventID_2>

Поле data_source, представленное массивом объектов, имеет следующую структуру:

Поле Описание Тип данных Обязательное поле

platform

Платформа или информационная система.

строка

нет

source

Источник событий.

строка

нет

events

События (EventId) или путь к журналу событий.

массив строк

нет

Структура tests:

Поле Описание Тип данных Обязательное поле

name

Название теста, позволяющее идентифицировать его в тестовой выдаче.

строка

да

events

Поток тестовых событий, обрабатываемых тестовым блоком.

массив

да

assertion

VRL-программа для тестирования условий после обработки тестовых событий правилом сегментации.

строка

да

Составление правила

Для составления правила сегментации в системе R-Vision SIEM, необходимо определить ключевые элементы структуры правила. Эти элементы включают поля метаданных и поля, управляющие логикой работы правила.

  1. Определите метаданные правила:

    • id: задайте уникальный идентификатор правила.

    • name: задайте название правила.

    • version: укажите версию правила, следуя стандартам Semantic Versioning.

    • type: определите тип правила как segmentation_rule.

    • author (опциональное): укажите имя и контактные данные автора.

    • description (опциональное): предоставьте краткое описание назначения и функциональности правила.

    • data_source (опциональное): укажите список совместимых с правилом источников данных для классификации правила в системе.

    • tags (опциональное): добавьте теги для классификации и поиска правила.

  2. Разработайте логику работы правила:

    Для корректной работы, в конфигурации правила сегментации необходимо задать минимум одно из полей: group_by, threshold, или timeout.

    • group_by (опциональное): определите поля для группировки событий.

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

    • timeout(опциональное): установите максимальное время в секундах для группы событий, после чего создается новое оповещение.

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

  3. Разработайте тесты для правила (опциональное):

    • tests: создайте тесты, включая сценарии и условия, для проверки работы правила. Это включает определение потока тестовых событий и использование VRL-выражений для проверки результатов сегментации.

Поля метаданных

Метаданные являются основой для идентификации и описания правила сегментации в системе. Они должны быть заполнены следующим образом:

  • id: установите уникальный идентификатор правила. Этот идентификатор должен быть уникальным в рамках системы.

  • name: укажите название правила.

  • version: задайте версию правила, следуя принципам Semantic Versioning (например, 1.0.0).

  • type: установите тип правила segmentation_rule.

  • author (опциональное): укажите имя и контактные данные создателя правила.

  • description (опциональное): предоставьте краткое описание назначения и функциональности правила.

  • data_source (опциональное): укажите список совместимых с правилом источников данных для классификации правила в системе.

  • tags (опциональное): добавьте теги для классификации правила в системе.

Поле group_by

Для корректной работы, в конфигурации правила сегментации необходимо задать минимум одно из полей: group_by, threshold, или timeout.

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

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

Если поле не определено, все поступающие события будут объединяться в одну группу.

Пример:

group_by:
  - source_ip
  - event_type

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

Поле threshold

Для корректной работы, в конфигурации правила сегментации необходимо задать минимум одно из полей: group_by, threshold, или timeout.

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

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

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

Пример:

threshold: 100

В данном примере, система создает новое оповещение, если в группе накапливается 100 событий.

Поле timeout

Для корректной работы, в конфигурации правила сегментации необходимо задать минимум одно из полей: group_by, threshold, или timeout.

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

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

Пример:

timeout: 3600

В этом примере, если события, относящиеся к одной группе по критериям поля group_by, поступают в течение часа (3600 секунд), система создает оповещение.

Поле alert_name

Поле alert_name позволяет задать правило на языке VRL для формирования имени оповещения на основе атрибутов анализируемых событий. Выполняется только при создании оповещения, при обновлении существующего оповещения не выполняется.

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

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

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

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

Пример:

alert_name: !vrl |
    "ALERT_" + to_uppercase!(.event_type) + "_" + to_string!(.source_ip)

В данном примере имя оповещения будет составлено из префикса ALERT_, типа события в верхнем регистре, и IP-адреса источника события.

Тестирование правила

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

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

Поле tests

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

Чтобы создать тестовый сценарий, в поле tests определите следующие параметры:

  • В name укажите название теста.

  • В events создайте массив событий, которые будут использоваться для тестирования. Эти события должны имитировать поток реальных исходных событий, которые поступают в сервис сегментации.

  • В assertion установите условие или набор условий, которые должны быть выполнены в результате обработки тестовых событий правилом. Это может включать проверку конкретных полей в итоговых сегментированных событиях или подсчет количества таких событий.

Тестовые события

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

Условия проверки

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

Пример:

tests:
  - name: "Тестирование сегментации для DDoS атак"
    events:
      - { source_ip: "192.168.1.1", event_type: "DDoS Detection", datetime: "2023-09-28T12:45:00Z" }
      - { source_ip: "192.168.1.1", event_type: "DDoS Detection", datetime: "2023-09-28T12:46:00Z" }
      - { source_ip: "192.168.1.2", event_type: "DDoS Detection", datetime: "2023-09-28T12:47:00Z" }
    assertion: !vrl |
      assert_eq!(length(.), 2)
      assert_eq!(.[0].group_by.source_ip, "192.168.1.1")
      assert_eq!(.[0].alert_name, "DDoS_ALERT_192.168.1.1")
      assert_eq!(.[1].group_by.source_ip, "192.168.1.2")
      assert_eq!(.[1].alert_name, "DDoS_ALERT_192.168.1.2")

В данном тестовом сценарии проверяется работа правила сегментации "DDoSAlertsSegmentation", направленного на выявление и классификацию корреляционных событий по IP-адресам источника. Тест включает имитацию трех событий, два из которых имеют одинаковый IP-адрес. Ожидается, что правило сегментации сгруппирует эти события и сформирует два оповещения: одно для событий с IP-адресом 192.168.1.1 и второе для события с IP-адресом 192.168.1.2.

Пример правила сегментации

Пример 1. Правило сегментации, схема RObject
# Уникальный идентификатор правила сегментации.
id: segmentation/ddos_alerts

# Название правила сегментации.
name: DDoSAlertsSegmentation.

# Тип элемента экспертизы.
type: segmentation_rule

# Версия правила сегментации.
version: 1.0.0

# Описание назначения правила сегментации.
description: Сегментация и классификация оповещений для атак типа DDoS.

# Имя и контактные данные автора правила сегментации.
author: John Doe <johndoe@example.com>

# Список совместимых с правилом источников данных.
data_source:
  - platform: Windows
  - source: Sysmon
  - events:
    - logs/default.log
    - logs/somelog.log

# Теги, связанные с правилом сегментации.
tags:
  - ddos
  - alert
  - segmentation

# Группирует корреляционные события по указанным полям. Если не указано, все события помещаются в единую группу.
group_by:
  - source_ip

# Задает максимальное количество корреляционных событий в группе оповещения.
# При достижении максимального значения создается новое оповещение.
threshold: 1

# Задает максимальное время жизни корреляционных событий в группе.
# При достижении максимального значения создается новое оповещение.
timeout: 60

# Код VRL для формирования имени оповещения (например из частей имен событий).
# Выполняется только при создании оповещения (при обновлении существующего оповещения не выполняется).
# Если поле не определено, оповещению будет автоматически присвоено название правила корреляции, которое первым привело к его срабатыванию.
alert_name: !vrl |
  "DDoS_ALERT_" + to_string!(.source_ip)

# Тесты для проверки работы правила сегментации.
tests:
  - name: High traffic from single source IP
    events:
      - { type: "correlation_rule", severity: "high", event_type: "DDoS Detection", source_ip: "198.51.100.1", datetime: "2023-09-28T12:45:00Z" }
      - { type: "correlation_rule", severity: "high", event_type: "DDoS Detection", source_ip: "198.51.100.2", datetime: "2023-09-28T12:47:00Z" }
      - { type: "correlation_rule", severity: "high", event_type: "DDoS Detection", source_ip: "198.51.100.1", datetime: "2023-09-28T12:49:00Z" }
    assertion: !vrl |
      assert_eq!(length(.), 3)
      assert_eq!(.[0].group_by.source_ip, "198.51.100.1")
      assert_eq!(.[0].name, "DDoS_ALERT_198.51.100.1")
      assert_eq!(.[1].group_by.source_ip, "198.51.100.2")
      assert_eq!(.[1].name, "DDoS_ALERT_198.51.100.2")

Интерпретация

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

Метаданные правила сегментации:

  • id: уникальный идентификатор правила сегментации в системе.

  • name: название правила сегментации, отражающее его назначение, — сегментация оповещений, связанных с DDoS-атаками.

  • type: тип элемента экспертизы указывает, что это правило относится к категории правил сегментации.

  • version: версия правила сегментации, позволяющая отслеживать его итерации и обновления.

  • description: краткое описание назначения правила сегментации — классификация и сегментация оповещений для атак DDoS.

  • author: автор правила сегментации и его контактные данные.

  • tags: метки, связанные с правилом, такие как ddos, alert, segmentation, помогающие в классификации и поиске правила.

Параметры сегментации:

  • group_by: указывает на поля событий, которые используются для группировки корреляционных событий. В данном случае, это source_ip, что позволяет сегментировать события по уникальным источникам IP.

  • threshold: количество событий от одного источника, при достижении которого будет сгенерировано новое оповещение.

  • timeout: временной интервал в секундах, в течение которого агрегируются события для сегментации.

  • alert_name: код VRL для формирования имени оповещения на основе атрибутов события. В данном случае, IP-адреса источника. Если поле не определено, оповещению будет автоматически присвоено название правила корреляции, которое привело к его срабатыванию.

Тестирование правила сегментации "DDoSAlertsSegmentation":

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

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

  • name: имя теста, в данном случае "High traffic from single source IP", что указывает на цель теста — проверить способность правила сегментации агрегировать и классифицировать события, характерные для DDoS-атак.

  • events: перечисление событий, которые имитируют корреляционные события, сгенерированные правилом обнаружения DDoS. Эти события содержат различные source_ip и метаданные, характерные для событий обнаружения DDoS, такие, как тип события "DDoS Detection", уровень серьезности "high", и временная метка.

  • assertion: содержит скрипт на языке VRL, предназначенный для дополнительной валидации атрибутов каждого сгенерированного оповещения. В частности, проверяется, что имя оповещения соответствует ожидаемому формату, основанному на IP-адресе источника события.

Таким образом, поле tests обеспечивает комплексную проверку правила сегментации "DDoSAlertsSegmentation", демонстрируя его способность идентифицировать и классифицировать события, ассоциированные с DDoS-атаками, и соответственно генерировать оповещения для дальнейшего анализа и реагирования.

+7 (499) 322 80 40 sales@rvision.ru

О компании Политика конфиденциальности Пользовательское соглашение