Правила Sigma - это файлы в формате YAML, которые содержат всю информацию, необходимую для обнаружения подозрительного, вредоносного или аномального поведения при анализе файлов журналов - обычно в контексте SIEM-системы (System Information and Event Management).
Чтобы максимально эффективно использовать правила Sigma, важно понимать, как они применяются для обнаружения, что означают различные поля и как начать создавать и делиться собственными правилами обнаружения Sigma.
Вы новичок в Sigma?
Если вы не знакомы с форматом обнаружения Sigma или не понимаете, чем он может быть полезен, посетите страницу «О Sigma», чтобы узнать больше о проекте и доступных наборах инструментов.
Начальный пример
Ниже приведен полный пример используемого правила Sigma. Этот пример обнаруживает событие "Блокировка учетной записи пользователя Okta".
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | # ./rules/cloud/okta/okta_user_account_locked_out.yml title: Блокировка учетной записи пользователя Okta id: 14701da0-4b0f-4ee6-9c95-2ffb4e73bb9a status: test description: Обнаруживает блокировку учетной записи пользователя. references: - https://developer.okta.com/docs/reference/api/system-log/ - https://developer.okta.com/docs/reference/api/event-types/ author: Austin Songer @austinsonger date: 2021-09-12 modified: 2022-10-09 tags: - attack.impact logsource: product: okta service: okta detection: selection: displaymessage: Max sign in attempts exceeded condition: selection falsepositives: - Неизвестны level: medium |
Компоненты
Чтобы понять, что делает приведенный выше фрагмент кода, это правило Sigma будет разделено на три основных компонента:
- Обнаружение (Detection): Какое вредоносное поведение ищет правило.
- Источник журналов (Logsource): Какие типы журналов следует анализировать этим правилом.
- Метаданные (Metadata): Другая информация об обнаружении.
Обнаружение (Detection)
Обязательный раздел
Раздел detection - самый важный компонент любого правила Sigma. Он точно определяет, что именно правило ищет в соответствующих журналах.
| 1 2 3 4 5 6 7 8 | product: okta service: okta detection: selection: displaymessage: Max sign in attempts exceeded condition: selection falsepositives: - Неизвестны |
Конкретное правило выше ищет случаи, когда учетная запись пользователя Okta была заблокирована из-за превышения максимального количества попыток входа.
Принципы
Формат обнаружения Sigma может быть довольно пугающим и запутанным для новичков, поскольку некоторые правила могут быть сложными в построении детектов. Важно понимать следующие руководящие принципы:
Выборки (Selections)
Каждое обнаружение Sigma категоризируется и разбивается на группы, называемые «выборками» (selections). Каждая «выборка» содержит определение самого обнаружения.
| 1 2 3 4 | detection: selection: displaymessage: Max sign in attempts exceeded condition: selection |
Sigma использует группы «выборок» для организации обнаружений для удобочитаемости и фильтрации, что становится важным при изучении Условий (Conditions).
И (AND) / Или (OR)
Другое важное соображение: Sigma выполняет операции «И» (AND) и «ИЛИ» (OR), используя Списки (Lists) и Словари (Dictionaries) YAML.
| 1 2 3 4 5 6 | detection: selection: field_name: - this # или - that condition: selection |
Синтаксис словаря/объекта представляет операцию «И» (AND):
| 1 2 3 4 5 | detection: selection: field_name: this # и other_field_name: that condition: selection |
Методы обнаружения
С учетом этих тем, рассмотрим, как Sigma составляет обнаружения с помощью 3 основных шаблонов.
- По Ключевому слову (by Keyword)
- По Значению поля (by Field Value)
- По Списку значений полей (by Multiple Field Values)
По Ключевому слову (by Keyword)
Один из самых базовых и простых для понимания способов обнаружения вредоносного поведения с помощью Sigma — использование ключевых слов. Поиск по ключевым словам просматривает заданный источник журналов на наличие любого текста, совпадающего с предоставленными ключевыми словами. Это соответствует поиску строки в необработанном журнале.
Каждый элемент в списке "keywords" фактически разделен логическим оператором "OR".
Пример правила Sigma ниже использует поиск по ключевым словам для обнаружения случаев, когда пользователи могут скрывать свои следы — путем очистки своего .bash_history.
| 1 2 3 4 5 6 7 8 9 10 11 12 | logsource: product: linux detection: keywords: - 'rm *bash_history' - 'echo "" > *bash_history' - 'truncate -s0 *bash_history' - 'history -c' - 'history -w' condition: keywords falsepositives: - Неизвестны |
Этот пример указывает Sigma сгенерировать запрос для SIEM, который ищет любое из следующих ключевых слов:
- rm *bash_history или
- echo "" > *bash_history или
- truncate -s0 *bash_history или
- history -c или
- history -w
Именование ключевых слов
Название поля "keywords" в разделах detection и selection в этом примере произвольно. Однако вам следует использовать его как стандарт при создании собственных правил Sigma.
Когда мы конвертируем правило в Splunk Query Language (например) с помощью инструмента sigma-cli, итоговый запрос после преобразования будет следующим:
| 1 | "rm *bash_history" OR "echo \"\" > *bash_history" OR "truncate -s0 *bash_history" OR "history -c" OR "history -w" |
Замечание об эффективности
Имейте в виду, что хотя поиск по ключевым словам легко писать, большинство SIEM-систем обычно работают значительно лучше при использовании поиска по полям.
По Полю (by Field)
Правила Sigma также могут использоваться для выполнения поиска по значению поля.
Чтобы сделать это, представьте поля как YAML-"объект" с их соответствующими именами и значениями.
| 1 2 3 4 | detection: selection: Username: "Administrator" condition: selection |
Вы также можете видеть, где несколько полей появляются вместе, добавляя дополнительные пары "поле-значение" в YAML-объект.
Например, чтобы обнаружить, когда USB-устройство вставляется в компьютер, вам может потребоваться учитывать следующие события, вызванные в системе ведения журналов событий Windows (Windows Event Logging):
- EventID: 6416 — новое внешнее устройство было распознано системой и
- где класс диска был "DiskDrive"
Чтобы найти, где происходят оба этих события, поместите их вместе в объект selection, как показано ниже.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | title: Внешний дисковод или USB-накопитель description: > Обнаруживает внешние дисководы или подключенные USB-устройства, EventID 6416 на Windows 10 и выше logsource: product: windows service: security detection: selection: EventID: 6416 # и где ClassName: 'DiskDrive' condition: selection falsepositives: - Легитивная административная активность |
Результирующий запрос после конвертации будет следующим (в качестве примера используется Splunk Query Language):
| 1 | source="WinEventLog:Security" EventCode=6416 ClassName="DiskDrive" |
По Списку полей (by Field List)
Метод обнаружения "По Списку полей" похож на метод "По Полю". Он полезен, когда вам нужно искать несколько значений одного поля.
Например, вы можете захотеть проверить логи Windows\Security и обнаружить, когда:
- EventID: 4728 - пользователь добавлен в группу безопасности (например, Administrators) или
- EventID: 4729 - пользователь удален из группы безопасности или
- EventID: 4730 - группа безопасности была удалена
Вы можете представить это в Sigma, используя список YAML, где каждое значение поля предваряется новой строкой и знаком "-".
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | title: Логирование изменений групп description: Срабатывает, когда учетная запись добавляется в любую группу с привилегиями администратора или удаляется из нее. logsource: product: windows service: system detection: selection: EventID: - 4728 # или где - 4729 # или где - 4730 condition: selection falsepositives: - Неизвестны |
Результирующий запрос после конвертации будет следующим (в качестве примера используется Splunk Query Language):
| 1 | source="WinEventLog:System" EventCode IN (4728, 4729, 4730) |
Условия (Conditions)
Раздел обнаружения Sigma может состоять из одного или нескольких обнаружений или групп «выборок» (selection groups). Каждая группа выборок должна присутствовать в поле condition внизу раздела detection.
Стандартное имя, данное этой группе - selection, но часто ему присваивается более описательная информация о том, что она пытается обнаружить.
| 1 2 3 4 | detection: selection: field: value condition: selection |
Стоит отметить, что условия можно использовать для организации различных групп выборок, а также для объединения или отрицания с другими группами выборок для выполнения мощных операций обнаружения в SIEM. Например:
| 1 | condition: (selection_one or selection_two) and not filter |
Источники журналов (Logsources)
Обязательный раздел
Раздел logsource в правилах Sigma используется для указания, какие данные журналов должны быть проанализированы правилом. Указывая соответствующий тип журнала в поле logsource, правила Sigma могут нацеливаться на конкретный вид журналов, вместо того чтобы искать по всем типам журналов в SIEM.
Он разделяет каждый определенный источник журналов на три отдельных поля: category, product и service.
- Категория (Category): Описывает категорию продуктов. (Напр., webserver, firewall или edr)
- Продукт (Product): Описывает конкретный продукт. (Напр., windows, linux, cisco)
- Сервис (Service): Описывает службу, работающую в рамках данного продукта. (Напр., kerberos, defender и т.д.).
| 1 2 3 4 5 6 7 | author: Austin Songer @austinsonger date: 2021-09-12 logsource: product: okta service: okta detection: selection: |
Правила Sigma обычно используют стандартную комбинацию этих полей для нацеливания на конкретный источник журналов.
Определение источника журналов (Logsource definition)
Поле definition внутри logsource также может предоставлять дополнительную информацию о том, как правильно интегрировать источник данных журналов.
| 1 2 3 4 5 6 7 8 9 10 | tags: - attack.privilege_escalation - attack.t1548 logsource: product: windows category: ps_script definition: Ведение журнала блоков сценариев (Script Block Logging) должно быть включено detection: selection: ScriptBlockText|contains: 'Invoke-Nightmare' |
Метаданные (Metadata)
Необязательный раздел
Все остальное, что вы видите вокруг разделов logsource и detection, Sigma называет «Метаданными», и оно может включать такие поля, как tags, level, references, description и другие.
Спецификация Sigma
Существует определенная Спецификация Sigma, в которой описывается, что Sigma считает «стандартными» полями, но важно отметить, что правила Sigma могут содержать любое количество полей метаданных на ваше усмотрение.
Доступные поля метаданных Sigma
Ниже приведен список стандартных полей метаданных Sigma.
- Заголовок (Title)
- ID
- Статус (Status)
- Описание (Description)
- Лицензия (License)
- Автор (Author)
- Дата / Изменено (Date / Modified)
- Ссылки (References)
- Теги (Tags)
- Ложные срабатывания (False Positives)
- Уровень (Level)
Заголовок (Title)
Обязательное поле
Поле title используется для очень краткого описания того, чего пытается достичь правило.
| 1 | title: Блокировка учетной записи пользователя Okta |
Подсказка по написанию хороших заголовков оповещений: Старайтесь делать заголовки оповещений как можно короче и избегайте префиксов вроде «Обнаруживает, когда...».
ID (Идентификатор)
Поле id должно генерироваться при создании правила Sigma и глобально идентифицировать правило Sigma среди всех остальных. По этой причине Sigma рекомендует использовать случайно сгенерированные UUID (версии 4).
| 1 | id: 12345678-bef0-4204-a928-ef5e620d6fcc |
Изменения идентификатора правила (Rule ID changes)
Идентификаторы правил должны изменяться только по следующим причинам:
- Крупные изменения в правиле (например, другая логика правила).
- Создание нового правила на основе существующего или уточнение правила таким образом, что оба остаются активными.
- Слияние правил.
Статус (Status)
Поле status отражает текущее состояние правила Sigma: в разработке, на тестировании или готово к использованию.
Значения: stable | test | experimental | deprecated | unsupported
| 1 | status: stable |
Описание (Description)
Поле description дает некоторое объяснение причин существования правила, как его лучше использовать и когда оно срабатывает.
| 1 | description: Это правило обнаруживает административный вход через RDP в Windows |
Написание хороших описаний
Описания часто используются другими продуктами и службами, чтобы помочь кратко объяснить, чего пытается достичь правило. Старайтесь избегать использования:
- «Обнаруживает, когда...» или «Обнаруживает, если...»
- «Это правило будет...»
Лицензия (License)
Необязательное поле
Поле license может содержать ссылку на идентификатор SPDX, описывающую, как правило Sigma может использоваться другими в сообществе.
| 1 2 3 | license: MIT # ИЛИ license: GPL-2.0-or-later |
Публикация правил Sigma
При внесении правил в сообщество, некоторые репозитории обычно имеют файл LICENSE, в котором описывается лицензия всего репозитория и всех содержащихся в нем правил обнаружения.
Помните, чтобы обсудить тему любых возможных конфликтующих лицензий с владельцем репозитория, прежде чем вносить какие-либо правила.
Автор (Author)
Поле author указывает единственного автора правила Sigma. Оно также может содержать handle в Twitter, email или другой способ связи с автором.
yaml
| 1 | author: CLOCK [[email protected]] |
Дата / Изменено (Date / Modified)
Поля date / modified указывают дату создания / последнего изменения правила.
| 1 2 | date: 2025-01-01 modified: 2025-01-02 |
Формат даты
Поля date и modified должны быть стандартизированы для использования даты ISO 8601 с разделителями: ГГГГ-ММ-ДД.
Когда менять дату изменения?
Вам следует изменять дату modified только когда вы:
- меняете заголовок,
- меняете раздел обнаружения (detection),
- меняете уровень (level) или
- меняете источник журналов (logsource).
Ссылки (References)
Поле references предоставляет URL-адрес, список URL-адресов или другие текстовые ссылки на то, как или почему правило Sigma было создано автором.
| 1 2 3 4 5 6 7 | references: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-6416 # ИЛИ references: - Простой текст (Напр., CVE-2025-22222) - https://www.trendmicro.com/vinfo/hk-en/security/news/cybercrime-and-digital-threats/malicious-spam-campaign-uses-iso-image-files-to-deliver-lokibot-and-nanocore - https://www.proofpoint.com/us/blog/threat-insight/threat-actor-profile-ta2719-uses-colorful-lures-deliver-rats-local-languages - https://twitter.com/MsftSecIntel/status/1257324139515269121 |
Теги (Tags)
Поле tags используется для категоризации или сопоставления правил Sigma с различными фреймворками безопасности и стандартами распространения информации. Они включают, но не ограничиваются:
- MITRE ATT&CK Framework
- MITRE Cyber Analytics Repository (CAR)
- Traffic Light Protocol (TLP)
- Common Vulnerabilities and Exposures (CVE)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | tags: # MITRE ATT&CK framework references - attack.discovery - attack.t1012 # MITRE Cyber Analytics Repository (CAR) - car.2016-04-005 - car-2016-04-005 # Traffic Light Protocol - tlp.amber - tlp.green # CVE - cve.2022-27925 |
Ложные срабатывания (False Positives)
Поле falsepositives описывает список возможных известных ложных срабатываний, которые могут возникнуть.
| 1 2 | falsepositives: - Это правило иногда может создавать ложные срабатывания, когда пользователь принудительно перезагружает свою рабочую станцию |
Ложные срабатывания против Фильтров (False Positives vs Filters)
Ложные срабатывания не обрабатываются конвертерами Sigma и просто существуют, чтобы помочь инженеру по обнаружению или аналитику классифицировать оповещение, чтобы понять, когда правило может сработать в незлонамеренном контексте.
Если вы хотите отфильтровать определенные события, вам следует использовать поле condition в комбинации с условием filter в разделе detection или использовать недавно опубликованную функцию Sigma Filters для настройки ваших оповещений.
Уровень (Level)
Поле level описывает критичность сработавшего правила.
В то время как события уровня low и medium носят информационный характер, события уровня high и critical должны приводить к немедленному просмотру аналитиками безопасности.
| 1 | level: low |
Значения: critical | high | medium | low | informational
Пять существующих уровней делятся на две категории.
- Правила, которые носят информационный характер и должны отображаться в виде списка или гистограммы (informational, low, medium)
- Правила, которые должны вызывать специальное оповещение (high, critical)
Применяйте следующие рекомендации при установке уровня:
- Правила уровня critical никогда не должны вызывать ложных срабатываний и иметь высокую релевантность.
- Правила уровня high срабатывают на угрозы высокой релевантности, которые должны быть проверены вручную (редкие ложные срабатывания > требуется базовое профилирование).
- Правила уровня high и critical указывают на инцидент (если это не ложное срабатывание).
- Правила уровня low и medium указывают на подозрительную активность и нарушения политик.
- Правила уровня informational носят информационный характер и часто используются для целей соответствия (compliance) или корреляции.
