Спецификация - grikos/sigma GitHub Wiki
Правила состоят из небольшого числа обязательных секций и нескольких опциональных.
title
id [optional]
related [optional]
- type {type-identifier}
id {rule-id}
status [optional]
description [optional]
author [optional]
references [optional]
logsource
category [optional]
product [optional]
service [optional]
definition [optional]
...
detection
{search-identifier} [optional]
{string-list} [optional]
{field: value} [optional]
...
timeframe [optional]
condition
fields [optional]
falsepositives [optional]
level [optional]
tags [optional]
...
[arbitrary custom fields]
type: //rec
required:
title:
type: //str
length:
min: 1
max: 256
logsource:
type: //rec
optional:
category: //str
product: //str
service: //str
definition: //str
detection:
type: //rec
required:
condition:
type: //any
of:
- type: //str
- type: //arr
contents: //str
length:
min: 2
optional:
timeframe: //str
rest:
type: //any
of:
- type: //arr
contents: //str
- type: //map
values:
type: //any
of:
- type: //str
- type: //arr
contents: //str
length:
min: 2
optional:
id:
type: //any
of:
- type: //str
length:
min: 1
max: 64
related:
type: //arr
contents:
type: //rec
required:
type:
type: //any
of:
- type: //str
value: derived
- type: //str
value: obsoletes
- type: //str
value: merged
- type: //str
value: renamed
id:
type: //any
of:
- type: //str
length:
min: 1
max: 64
- type: //arr
contents: //str
length:
min: 1
max: 64
status:
type: //any
of:
- type: //str
value: stable
- type: //str
value: testing
- type: //str
value: experimental
description: //str
author: //str
license: //str
references:
type: //arr
contents: //str
fields:
type: //arr
contents: //str
falsepositives:
type: //any
of:
- type: //str
- type: //arr
contents: //str
length:
min: 2
level:
type: //any
of:
- type: //str
value: low
- type: //str
value: medium
- type: //str
value: high
- type: //str
value: critical
tags:
type: //arr
contents: //str
rest: //any
Атрибут: title
В поле «заголовок» описывается суть и назначение правила. Это текстовое поле длиной не более 256 символов. Тут следует давать максимально короткое и ёмкое описание.
Атрибуты: id, related
Sigma-правила должны идентифицироваться глобально уникальным идентификатором в атрибуте id. Для этих целей рекомендуется (но это не обязательное требование) использовать случайно сгенерированные UUID-ы (версии 4).
Пример:
title: Test rule
id: 929a690e-bef0-4204-a928-ef5e620d6fcc
Идентификаторы правил могут и должны быть изменены в следующих случаях:
- Глобальные изменения в правиле. Например, изменение логики правила.
- Наследование правила от существующего или усовершенствование правила с сохранением исходного.
- Слияние правил.
Для того чтобы иметь возможность отследить взаимосвязь между идеями обнаружения атак, Sigma-правила могут также содержать ссылки на идентификаторы связанных правил в атрибуте related. Это позволяет указать взаимосвязь с существующими правилами следующим образом:
related:
- id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
type: derived
- id: 929a690e-bef0-4204-a928-ef5e620d6fcc
type: obsoletes
В настоящее время определены следующие типы взаимосвязей между правилами:
-
derived
: Текущее правило получено из указанного правила или правил, которые могут оставаться в репозитории и активно использоваться. -
obsoletes
: Текущее правило заменяет указанное правило, которое больше не используется. -
merged
: Текущее правило является результатом слияния указанных правил. Исходные правила могут оставаться в репозитории и активно использоваться. -
renamed
: Текущее правило получено путём переименования. Это может возникнуть в ситуациях, когда происходит переход с собственной схемы создания индикаторов на UUID-ы, выборе нового названия из-за коллизий и т.д. Правило с исходным id более не обязано существовать.
Атрибут: status
Отражает статус правила:
-
stable
: такое правило считается стабильным и может быть использовано в реальных инфраструктурах для выявления атак и отображения на дашбордах. -
test
: почти стабильное правило, для которого, вероятно, может потребоваться более тонкая настройка. -
experimental
: экспериментальное правило, которое может приводить к неверным роезультатам или порождать много срабатываний. Однако, также может выявлять интересные события.
Атрибут: description Короткое описание правила и той вредоносной активности, которая может быть обнаружена. Максимальная длина данного поля составляет 65535 символов.
Атрибут: license
Лицензия, под которой распространяется правило согласно спецификации SPDX ID.
Атрибут: author
Создатель или создатели правила.
Атрибут: reference
Ссылки на источники, которые помогли в создании правила. Это могут быть статьи в блогах, технические документы, презентации или даже твиты.
Атрибут: logsource
Данная секция описывает данные из логов, основываясь на которых будет проводиться обнаружение подозрительной активности. В данной секции описываются источник логов, платформа, приложение и тип, которые необходимы для детекта.
Она состоит из трёх атрибутов, которые обрабатываются конвертерами автоматически, и определённого числа необязательных элементов. Рекомендуется использовать поле definition
в случаях, когда необходимы дополнительные пояснения и рекомендации.
-
category
- примеры: firewall, web, antivirus -
product
- примеры: windows, apache, check point fw1 -
service
- примеры: sshd, applocker
Значение поля category
используется для выбора всех логов, которые создаются определённой группой продуктов, таких как межсетевые экраны или веб-серверы. Автоматическое преобразование будет использовать данное ключевое слово в качестве селектора для нескольких индексов.
Значение поля product
используется для выбора всех логов, которые создаются определённым продуктом. Например, все журналы событий Windows, включая "Security", "System", "Application", а также новые журналы, такие как "AppLocker" и "Windows Defender".
Значение поля service
используется для выбора подмножества логов определённого продукта. Например, sshd
для выборки только событий демона sshd на Linux-системах или security
для выборки только событий из журнала событий "Security" на Windows-системах.
Значение поля definition
может быть использовано для описания источника логов, включая некоторую информацию о необходимой степени подробности сообщений или требованиях к конфигурации, которые должны быть применены. Данное поле не обрабатывается конвертерами автоматически, но обеспечивает читателей полезной информацией. Такая информация показывает как настроить источник для предоставления событий, необходимых для детекта.
Можно использовать значения полей 'category', 'product' и 'service' для указания конвертерам какой именно индекс использовать. В конфигурационных файлах можно указать, что категория 'firewall' преобразуется в ( index=fw1* OR index=asa* )
в ходе конвертации в поисковые запросы для Splunk или продукт 'windows' преобразуется в "_index":"logstash-windows*"
для запросов ElasticSearch.
Вместо того, чтобы ссылаться на конкретные сервисы, могут использоваться обобщённые категории источников логов, например:
category: process_creation
product: windows
Такая запись используется вместо описания нескольких правил на создание процессов отдельно для логов Sysmon, событий журнала аудита Windows "Security" и, возможно, некоторых специфичных для конкретных продуктов правил.
Атрибут: detection
Набор идентификаторов поиска, которые представляют из себя поисковые запросы к данным из логов.
Сущность, которая может являться одной из двух структур данных - списком или словарем.
- Все значения интерпретируются как регистронезависимые строки
- В строках можно использовать метасимволы подстановки '*' and '?'
- Метасимволы подстановки экранируются при помощи символа
\
, напривер\*
. Если нужно найти метасимвол подстановки после бэкслеша, то нужно заэкранировать бэкслэш:\\*
. - Регулярные выражения регистрозависимы по умолчанию.
- Нет необходимости экранировать символы, за исключением одинарных кавычек
'
Списки содержат строки, которые ищутся во всём сообщении события, а результаты поиска объединяются при помощи логического ИЛИ.
Пример:
Фрагмент правила, которое находит событие, в котором встречается строка 'EvilService' ИЛИ строка 'svchost.exe -n evil'
detection:
keywords:
- EVILSERVICE
- svchost.exe -n evil
Словари (или ассоциативные массивы) состоят из пар типа "ключ/значение", в которых ключом является название поля в событии, а значение это строка или целое число. Списки словарей объединяются при помощи логического ИЛИ. Все элементы словаря объединяются при помощи логического И.
Примеры:
Фрагмент правила, которое находит событие из журнала "Security" И ( идентификатор события равен 517 ИЛИ идентификатор события равен 1102 )
detection:
selection:
- EventLog: Security
EventID:
- 517
- 1102
condition: selection
Фрагмент правила, которое находит событие из журнала "Security" И идентификатор события равен 4679 И поле опций билета содержит значение 0x40810000 И поле типа шифрования равно 0x17
detection:
selection:
- EventLog: Security
EventID: 4769
TicketOptions: '0x40810000'
TicketEncryption: '0x17'
condition: selection
Существуют специальные значения полей, которые могут использоваться в правилах.
- Пустое значение - задаётся через две одинарные кавычки
''
- Значение null - задаётся через ключевое слово
null
УСТАРЕЛО: Для определения произвольного значения, не являющегося null или пустым значением, конструкция not null
не может более использоваться.
Применение данных значений зависит от целевой SIEM.
Для того чтобы правильно выразить конструкцию типа not null
, необходимо создать специальный идентификатор поиска и в поле condition
взять от него отрицание.
Пример:
detection:
selection:
EventID: 4738
filter:
PasswordLastSet: null
condition:
selection and not filter
Значения, содержащиеся в Sigma-правилах, могут быть изменены при помощи модификаторов значений. Модификаторы значений добавляются после названия поля и отделяются от него символом пайпа |
. Также модификаторы значений могут идти подряд, образуя цепочки (или конвейер) модификации, при этом модификаторы отделяются друг от друга так же символом пайпа, например, fieldname|mod1|mod2: value
. Модификаторы значений применяются к исходному значению в соответствии с порядком указания в цепочке.
Существует два типа модификаторов значений:
- Трансформирующие модификаторы - преобразуют исходное значение в некое другое, как два модификатора Base64, упомянутые выше. Более того, такой тип модификаторов способен также менять логическую операцию, применяемую к значениям. Трансформирующие модификаторы обычно независимы от бэкенда. Это значит, что их можно использовать при преобразовании правила для любой целевой системы.
- Модификаторы типа - изменяют тип значения. Само значение также может быть изменено модификатором такого типа, но основное назначение данного типа модификаторов - сообщить бэкэнду, что значение должно быть обработано бэкендом иначе, например, при использовании модфификатора re значение должно интерпретироваться как шаблон регулярного выражения. Модификаторы типов должны поддерживаться бэкэндом.
Вообще говоря, модификаторы значений работают как с одиночными значениями, так и со списками. Значение также может расширяться до нескольких значений.
-
contains
: добавляет метасимволы подстановки*
вокруг значений. Таким образом, значение будет искаться в любом месте поля (поиск подстроки в строке). -
all
: обычно списки значений в результирующем запросе объединяются логическим оператором ИЛИ. Данный модификатор изменяет этот оператор на логическое И. Это полезно, если нужно описать строку запуска процесса с различными параметрами, при этом порядок искомых параметров может изменяться. Такой подход избавляет от необходимости писать громоздкие выражения для достижения того же результата. -
base64
: значение кодируется алгоритмом Base64. -
base64offset
: если значение может встретиться где-то посреди закодированной Base64-строки, то представление такого участка может быть различным в зависимости от позиции подстроки в исходной строке. Существует три варианта сдвига: на ноль, два или три байта. Во всех трёх случаях в закодированном значении существует статичная часть, за исключением первого и последнего байта. Такие статичные части можно исать в закодированном представлении исходной строки. -
endswith
: значение ожидается в конце содержимого указанного поля события. (замена выражениям наподобие '*\cmd.exe'). -
startswith
: значение ожидается в начале содержимого указанного поля события. (замена выражениям наподобие 'adm*'). -
utf16le
: преобразует значение в кодировку UTF16-LE (причём на выходе получается массив байт), например,cmd
>63 00 6d 00 64 00
(используется только в сочетании с модификаторами base64). -
utf16be
: преобразует значение в кодировку UTF16-BE (причём на выходе получается массив байт), например,cmd
>00 63 00 6d 00 64
(используется только в сочетании с модификаторами base64). -
wide
: синоним для модификатораutf16le
. -
utf16
: добавляет метку порядка байтов и кодирует в UTF16, например,cmd
>FF FE 63 00 6d 00 64 00
(используется только в сочетании с модификаторами base64).
- re: значение обрабатывается бэкендами как шаблон регулярного выражения. На данный момент, этот модификатор поддерживается только бэкендом преобразования в строку запроса Elasticsearch (es-qs). В будущем планируется реализация поддержки для других бэкендов (например для Splunk).
Временной интервал, в течение которого должны появиться идентификаторы поиска. Для обозначения единиц измерения времени используются стандартные сокращения:
15s (15 секунд)
30m (30 минут)
12h (12 часов)
7d (7 дней)
3M (3 месяца)
Временной интервал задаётся в атрибуте timeframe
секции описания логики выявления атаки (атрибут detection
).
Замечание: временной интервал часто является параметром, задаваемым в системах SIEM вручную, поэтому он не является частью сгенерированного запроса.
Атрибут: condition
Описание условия срабатывания правила является наиболее сложной частью спецификации и будет изменяться с течением времени, а также при возникновении новых требований. В первом релизе будут поддерживаться следующие выражения.
-
Логические И/ИЛИ
keywords1 or keywords2
-
1/all of <идентификатор_поиска>
Тоже самое, что просто набор ключевых слов, если данный набор задан в формате списка. X может быть:
- 1 (логическое ИЛИ среди альтернатив)
- all (логическое И среди альтернатив)
Пример:
all of keywords
значит, что все элементы списка 'keywords' должны появится в событии, вместо поведения по умолчанию, когда достаточно присутствия только одного элемента. -
1/all of them
Логическое ИЛИ (
1 of them
) или логическое И (all of them
) среди всех объявленных идентификаторов поиска. По умолчанию связь между идентификаторами поиска зависит от формата их объявления для словарей (логическое И), для списков (логическое ИЛИ).Пример:
1 of them
означает, что хотя бы один из объявленных идентификаторов поиска должен появиться. -
1/all of <шаблон_идентификатора_поиска>
Тоже самое, что 1/all of them, но применяется не ко всем идентификаторам поиска, а только к тем, которые соответствуют указанному шаблону. Шаблон задаётся с использованием метасимвола подстановки
*
на определённых позициях в шаблоне. Метасимвол подстановки заменяет любое количество символов.Примеры:
1 of selection* and keywords
any of selection* and not filters
-
Отрицание с использованием ключевого слова
not
keywords and not filters
-
Пайп
search_expression | aggregation_expression
Пайп означает, что результат search_expression агрегируется при помощи aggregation_expression и, возможно, сравнивается с каким-либо значением.
Первое выражение должно быть выражением поиска, которое записывается перед агрегатным выражением с условием.
-
Скобки
selection1 and (keywords1 or keywords2)
-
Агрегатное выражение
<агрегатная_функция>(<агрегируемое_поле>) [by <группируемое_поле>] <операция_сравнения> <значение_для_сравнения>
<агрегатная_функция> может быть одной из следующих:
- count
- min
- max
- avg
- sum
Все агрегатные функции, за исключением
count
, требуют указания названия поля в качестве параметра. Функция "count" считает количество всех подходящих событий, если не указано имя поля. При указании имени поля в качестве аргумента функции count, она возвращает количество различных значений данного поля.Пример:
count(UserName) by SourceWorkstation > 3
В данном сравнении подсчитывается количество различных имён пользователей (значений поля UserName), сгруппированных по полю SourceWorkstations.
-
Агрегатное выражение near
near search-id-1 [ [ and search-id-2 | and not search-id-3 ] ... ]
Данное выражение создаёт (если поддерживается целевой системой и бэкэндом) запрос, который распознаёт search_expression (первичное событие) если заданные условия находятся или не находятся во временнoм контексте первичного события в заданном временнoм интервале.
Приоритет операторов (от наименьшего к наибольшему):
- |
- or
- and
- not
- x of <идентификатор_поиска>
- ( <выражение> )
Если задано несколько условий, то они объединяются логическим оператором ИЛИ.
Атрибут: fields
Список полей лога, которые могут быть интересны для дальнейшего анализа произошедшего события и должны быть показаны аналитику.
Атрибут: falsepositives
Список известных ситуаций, в которых могут произойти ложные срабатывания.
Атрибут: level
Поле level
принимает одно из четырёх строковых значений. Оно описывает уровень критичности сработавшего правила. В то время как значения low
и medium
присваиваются событиям, несущим информационный характер, события с уровнем критичности high
и critical
требуют немедленного рассмотрения аналитиками.
-
low
: интересное событие, при этом редко являющееся инцидентом. События с низким уровнем критичности могут представлять интетерес в больших количествах или в сочетании с другими событиями. Аналитик должен проанализировать события и выявить аномалии и подозрительные индикаторы. Используйте такие события на дашбордах, например, в виде диаграмм. -
medium
: релевантное событие, которое чаще всего должно быть проанализировано вручную. Аналитик должен проанализировать события и выявить аномалии и подозрительные индикаторы. Такие события удобно выводить списком или таблицей на дашбордах для дальнейшего ручного анализа. -
high
: релевантное событие, которое должно вызвать оповещение безопасности. Такое событие должно быть незамедлительно рассмотрено. -
critical
: высокорелевантное событие, которое свидетельствует об инциденте. Рекомендуется проведение немедленного реагирования на инцидент и отправка внешних уведомлений (отправка письма, заведение тикета).
Атрибут: tags
Sigma-правило может быть проклассифицировано при помощи тэгов. Тэги обычно должны следовать следующему синтаксису:
- Используемые символоы: строчные буквы (нижний регистр), символ нижнего подчёркивания и дефис.
- Пробелы отсутствуют.
- У тэгов есть пространства имён, точка используется как разделитель. Например тэг attack.t1234 ссылается на технику 1234 в пространстве имён attack; Пространства имён могут быть вложенными.
- Используйте короткие тэги, например, числовые идентификаторы вместо длинных предложений.
- Если применимо, то используйте предопределённые тэги. Не стесняйтесь отправлять pull request или создавать issue с предложениями новых тэгов.
Заполнители могут использоваться для указания набора элементов, которые могут быть расширены во время преобразования. Заполнители сопоставляют идентификатору определённое пользователем значение, которое может быть задано в конфигурационных файлах. Это используется для автоматической замены участков правила во время выполнения преобразования. Заполнители - это весьма выразительные идентификаторы (подставляемое значение понятно из названия), которые пользователи могут легко понять самостоятельно.
-
%Administrators%
- административные учётные записи -
%JumpServers%
- серверы, используемые в качестве серверов доступа
Некоторые системы SIEM позволяют использовать в запросах так называемые "тэги" или "поисковые макросы", благодаря чему могут напрямую интегрировать Sigma-правила с заполнителями. Другие системы расширяют значения заполнителей до шаблонных строк или регулярных выражений.
Splunk
-
AccountName: %Administrators%
преобразуется вtag=Administrators
Elastic Search
-
SourceWorkstation: %JumpServers%
преобразуется в"SourceWorkstation": SRV110[12]
Файл может содержать несколько YAML-документов. Это могут быть полные Sigma-правила или action-документы. YAML-документ обрабатывается как action-документ, если задан высокоуровневый атрибут action
. Возможные значения данного атрибута:
-
global
: определяет содержимое, с которым будет происходить слияние всех YAML-документов в этом файле. Несколько глобальных action-документов объединяются в процессе обработки файла.
Использование: для описания метаинформации и общих частей для всех правил в коллекции. -
reset
: сбрасывает глобальное содержимое, заданное глобальными action-документами. -
repeat
: повторяет создание предыдущего правила, однако слияние происходит с данными из текущего YAML-документа. Использование: небольшие модификации ранее созданного правила.
Чаще всего коллекции правил используются для описания нескольких Sigma-правил для схожих событий, таких как событие создания процесса из журнала аудита "Security" (EventID 4688) и событие создания процесса из журнала Sysmon (EventID 1). Оба события создаются в случае запуска процесса. Для такого случая коллекция Sigma-правил может содержать три документа:
- Глобальный action-документ, который задаёт общую метаинформацию и индикаторы обнаружения.
- Правило, которое строит детект на событиях из журнала Windows Security с идентификатором события, равным 4688.
- Правило, которое строит детект на событиях из журнала Windows Sysmon с идентификатором события, равным 1.
Альтернативным решением может быть:
- Глобальный action-документ, который задаёт общую метаинформацию.
- Правило, основанное на Security/4688 со всеми подробностями детекта и индикаторами обнаружения.
- Повторный action-документ, который заменяет источник логов и идентификатор события, определённые в п.2.