Правила сегментации
В данном разделе представлен обзор структуры, принципов работы и процесса создания правил сегментации в R-Vision SIEM. Управление правилами сегментации в системе осуществляется в разделе Экспертиза.
О правилах сегментации
Правило сегментации в системе R-Vision SIEM представляет собой структурированный объект данных, определяющий логику для классификации и обработки корреляционных событий, на основе которых правило сегментации создает оповещения. Каждое правило сегментации, оформленное в формате RObject (.ro), содержит набор параметров для группировки событий по определенным критериям, таким как тип события, источник или другие атрибуты.
Основная функция правил сегментации заключается в управлении потоком корреляционных событий, обеспечивая их агрегацию, классификацию и преобразование в оповещения согласно заданным условиям.
Параметры сегментации позволяют задать условия, по которым события будут собираться в оповещении до достижения определенного количества или до истечения заданного временного интервала. Например:
-
Можно задать условия для определения количества событий от конкретного источника, которые должны будут собираться в оповещении в течение установленного временного интервала. По истечении этого временного интервала, окно сегментации будет закрыто и последующие корреляционные события будут отправляться в новое оповещение.
-
Можно задать условия для накопления в оповещении определенного количества событий от конкретного источника. По достижении этого количества, окно сегментации будет закрыто и последующие корреляционные события будут отправляться в новое оповещение.
В системе правила сегментации используются в рамках сервиса оповещений конвейера обработки событий.
Применение правил сегментации
В системе R-Vision SIEM, правила сегментации задают логику разделения и классификации корреляционных событий для формирования оповещений на основе анализа, выполненного правилами корреляции. Правила сегментации применяются к потоку событий на конвейере обработки в рамках элемента сервис оповещений, который использует эти правила для дополнительной обработки и группировки корреляционных событий, позволяя задавать многоуровневые условия для создания оповещений.
Особенностью сервиса оповещений является его способность ассоциировать одно правило сегментации с несколькими правилами корреляции, что позволяет агрегировать разнородные корреляционные события в рамках единой логики сегментации. Такая модель обеспечивает унифицированную обработку событий, исходящих от различных источников. Вместе с тем, правило корреляции, уже связанное с определенным правилом сегментации, не может быть ассоциировано с другим правилом сегментации, что исключает возможность перекрестных или конфликтующих связей между правилами.
Система поддерживает одновременное использование множества правил сегментации в рамках сервиса оповещений, что позволяет создавать многоуровневую логику сегментации и обработки событий.
Работа с правилом сегментации
Доступные операции над правилом сегментации:
Создание правила сегментации
Чтобы добавить правило сегментации:
-
Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы, в том числе их текущий статус (включен/выключен).
-
Нажмите на кнопку Создать и выберите из выпадающего списка опцию Правило сегментации. Система отобразит окно создания правила сегментации.
При создании элемента экспертизы поля его структуры заполняются значениями по умолчанию. Для быстрой настройки структуры в системе доступны предустановленные примеры. Чтобы заполнить поля элемента экспертизы с помощью примера, нажмите на кнопку Примеры и выберите требуемый пример из выпадающего списка. -
Заполните поля правила сегментации, чтобы определить логику его работы.
Строки, начинающиеся с символа $
($foo
), интерпретируются в VRL-блоках элементов экспертизы как переменные окружения. Чтобы избежать этого, экранируйте такие строки символом$
($$foo
). -
Нажмите на кнопку Опубликовать версию, чтобы сохранить изменения и опубликовать созданное правило сегментации. Система отобразит уведомление об успешном создании правила сегментации. Новое правило сегментации отобразится в таблице раздела Экспертиза.
Чтобы правило сегментации стало доступно в конвейерах событий, его необходимо включить. Вы можете создать правило сегментации без его публикации (в виде черновика) с помощью кнопки Сохранить черновик. Система отобразит уведомление об успешном создании черновика правила. Черновик отобразится в таблице раздела Экспертиза.
Изменение правила сегментации
Чтобы изменить правило сегментации:
-
Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы, в том числе их текущий статус (включен/выключен).
-
Нажмите на строку правила сегментации в списке. Система отобразит в правой части экрана карточку этого правила с подробной информацией о нем.
-
Выберите опцию Изменить в выпадающем меню Действия () в верхней части карточки правила сегментации. Отобразится окно настроек правила.
Вы также можете открыть окно настроек с помощью кнопки в нижней части карточки:
-
Для опубликованной версии: нажмите на кнопку Просмотр в нижней части карточки. Система отобразит окно просмотра настроек элемента экспертизы. Нажмите на кнопку Изменить в правом нижнем углу окна.
-
Для черновика: нажмите на кнопку Изменить в нижней части карточки.
-
-
Внесите требуемые изменения в конфигурацию правила сегментации.
-
Нажмите на кнопку Обновить версию. Новая версия правила сегментации с измененной конфигурацией будет опубликована.
При публикации новой версии элемента экспертизы требуется увеличить его текущую версию в поле version
.Вы можете сохранить измененную конфигурацию правила сегментации без публикации (в виде черновика) с помощью кнопки Сохранить черновик. Конфигурация будет сохранена для дальнейшего редактирования. В этом случае в верхней части карточки правила будет отображаться предупреждение о наличии неопубликованных изменений.
Удаление правила сегментации
Удаление доступно только для элементов экспертизы с типом создания Пользовательский. |
Удаление недоступно для элементов экспертизы, используемых в других сущностях системы.
Чтобы удалить правило сегментации:
-
Перейдите в раздел Экспертиза. Система отобразит сведения об имеющихся элементах экспертизы, в том числе их текущий статус (включен/выключен).
-
Нажмите на строку правила сегментации в списке. Система отобразит в правой части экрана карточку этого правила с подробной информацией о нем.
-
Выберите опцию Удалить в выпадающем меню Действия () в верхней части карточки правила сегментации. Отобразится окно подтверждения удаления правила.
-
Нажмите на кнопку Удалить. Система отобразит уведомление об удалении правила сегментации, и правило будет удалено из списка элементов экспертизы.
Вы также можете удалить группу элементов экспертизы. Для этого:
|
Структура правила сегментации
Правило сегментации в системе R-Vision SIEM представляет собой структурированный объект данных в формате RObject (.ro), который включает в себя ряд обязательных и опциональных полей для определения процесса сегментации.
Строки, начинающиеся с символа $ ($foo ), интерпретируются в VRL-блоках элементов экспертизы как переменные окружения. Чтобы избежать этого, экранируйте такие строки символом $ ($$foo ).
|
Поле | Описание | Тип данных | Обязательное поле |
---|---|---|---|
|
Уникальный идентификатор правила сегментации. |
строка |
да |
|
Название правила сегментации. |
строка |
да |
|
Тип элемента. Всегда имеет значение |
строка |
да |
|
Версия правила сегментации, представленная в формате Semantic Versioning. |
строка |
да |
|
Имя и контактные данные автора правила сегментации. |
строка |
нет |
|
Описание правила сегментации, содержащее дополнительную информацию о его назначении и функциональности. |
строка |
нет |
|
Список источников данных, с которыми совместимо правило сегментации. Используется для классификации и быстрого поиска элементов экспертизы в системе. |
массив строк массив объектов |
нет |
|
Список тегов, присвоенных правилу сегментации для классификации и быстрого поиска. |
массив строк |
нет |
|
Поля для группировки событий в рамках процесса сегментации. Каждая группа агрегируется независимо. Если ничего не указано — все поступающие события будут объединяться в одну группу. |
массив строк |
нет |
|
Числовое значение, задающее максимальное количество событий в группе. Достижение этого количества инициирует создание нового оповещения. Если указано вместе с полем |
число |
нет |
|
Числовое значение, задающее максимальный временной интервал (в секундах) для группы. По истечении этого времени создается новое оповещение, даже если количество событий не достигло |
число |
нет |
|
VRL-выражение для определения логики формирования имени оповещения (например из частей имён событий). Если поле не определено, оповещению будет автоматически присвоено название правила корреляции, которое первым привело к его срабатыванию. Выполняется только при создании оповещения (при обновлении существующего оповещения не выполняется). |
строка |
нет |
|
Блок тестирования правила сегментации, содержащий массив тестовых сценариев и условия для проверки логики сегментации. |
объект |
нет |
Структура data_source
Поле data_source
, представленное массивом строк, имеет структуру:
data_source:
- <platform> # Платформа или информационная система
- <source> # Источник событий.
# События (EventId) или путь к журналу событий:
- <EventID_1>
- <EventID_2>
Поле data_source
, представленное массивом объектов, имеет следующую структуру:
Поле | Описание | Тип данных | Обязательное поле |
---|---|---|---|
|
Платформа или информационная система. |
строка |
нет |
|
Источник событий. |
строка |
нет |
|
События (EventId) или путь к журналу событий. |
массив строк |
нет |
Структура tests
:
Поле | Описание | Тип данных | Обязательное поле |
---|---|---|---|
|
Название теста, позволяющее идентифицировать его в тестовой выдаче. |
строка |
да |
|
Поток тестовых событий, обрабатываемых тестовым блоком. |
массив |
да |
|
VRL-программа для тестирования условий после обработки тестовых событий правилом сегментации. |
строка |
да |
Составление правила
Управление правилами сегментации в системе R-Vision SIEM осуществляется в разделе Экспертиза. |
Для составления правила сегментации в системе R-Vision SIEM, необходимо определить ключевые элементы структуры правила. Эти элементы включают поля метаданных и поля, управляющие логикой работы правила.
-
Определите метаданные правила:
-
id
: задайте уникальный идентификатор правила. -
name
: задайте название правила. -
version
: укажите версию правила, следуя стандартам Semantic Versioning. -
type
: определите тип правила какsegmentation_rule
. -
author
(опциональное): укажите имя и контактные данные автора. -
description
(опциональное): предоставьте краткое описание назначения и функциональности правила. -
data_source
(опциональное): укажите список совместимых с правилом источников данных для классификации правила в системе. -
tags
(опциональное): добавьте теги для классификации и поиска правила.
-
-
Разработайте логику работы правила:
Для корректной работы, в конфигурации правила сегментации необходимо задать минимум одно из полей: group_by
,threshold
, илиtimeout
.-
group_by
(опциональное): определите поля для группировки событий. -
threshold
(опциональное): установите максимальное количество событий в группе оповещения. По достижении порогового значения, система создаст новое оповещение. -
timeout
(опциональное): установите максимальное время (в секундах) для группы событий, после чего создается новое оповещение. -
alert_name
(опциональное): используйте VRL-выражение, чтобы определить логику формирования имени оповещения, которое будет присвоено при создании нового оповещения на основе сегментации. Если поле не определено, оповещению будет автоматически присвоено название правила корреляции, которое первым привело к его срабатыванию. Выполняется только при создании оповещения (при обновлении существующего оповещения не выполняется).
-
-
Разработайте тесты для правила (опциональное):
-
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 (Vector Remap Language), это поле позволяет динамически строить имя оповещения, основываясь на атрибутах анализируемых событий. Выполняется только при создании оповещения (при обновлении существующего оповещения не выполняется).
Если поле 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.
Пример правила сегментации
# Уникальный идентификатор правила сегментации. 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-атаками, и соответственно генерировать оповещения для дальнейшего анализа и реагирования.