Спецификация - grikos/sigma GitHub Wiki

Структура Sigma-правила

Правила состоят из небольшого числа обязательных секций и нескольких опциональных.

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]

Схема

Rx YAML

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

Изображение

sigma_schema

Компоненты

Заголовок

Атрибут: 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-правил может содержать три документа:

  1. Глобальный action-документ, который задаёт общую метаинформацию и индикаторы обнаружения.
  2. Правило, которое строит детект на событиях из журнала Windows Security с идентификатором события, равным 4688.
  3. Правило, которое строит детект на событиях из журнала Windows Sysmon с идентификатором события, равным 1.

Альтернативным решением может быть:

  1. Глобальный action-документ, который задаёт общую метаинформацию.
  2. Правило, основанное на Security/4688 со всеми подробностями детекта и индикаторами обнаружения.
  3. Повторный action-документ, который заменяет источник логов и идентификатор события, определённые в п.2.
⚠️ **GitHub.com Fallback** ⚠️