Руководство По Написанию Правил - grikos/sigma GitHub Wiki

Создание правила

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

Шаблон правила

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

Если вы хотите отправить запрос на добавление вашего правила в наш публичный репозиторий, убедитесь, что представленные ниже поля присутствуют и заполнены:

title: короткий заголовок менее 50 символов (слова начинаются с заглавной буквы).
id: создать можно тут https://www.uuidgenerator.net/version4
status: experimental
description: Описание того, что предполагается обнаруживать данным правилом. 
references:
    - Список всех ссылок, которые могут помочь читателю или аналитику понять назначение сработавшего правила.
tags:
    - attack.execution  # пример тактики MITRE ATT&CK
    - attack.t1059      # пример техники MITRE ATT&CK
    - car.2014-04-003   # пример указания идентификатора CAR
author: Michael Haag, Florian Roth, Markus Neis  # пример списка авторов
date: 2018/04/06  # дата создания правила
logsource:                      # важно для маппинга полей в дефолтном или дополнительном конфигурационном файле
    category: process_creation  # в данном примере выбрана категория 'process_creation'
    product: windows            # соответствующий продукт
detection:
    selection:
        FieldName: 'СтроковоеЗначение'
        FieldName: ЧелочисленноеЗначение
        FieldName|modifier: 'значение'
    condition: selection
fields:
    - поля в логах, которые важнны для дальнейшего расследования
falsepositives:
    - опишите условия при которых возможны ложные срабатывания правила, для того чтобы помочь аналитикам в их расследовании
level: один из четырёх уровней (low, medium, high, critical)

Частые ошибки

Поле title

  • Не используйте в качестве заголовка конструкции вроде "Detects .."
  • Используйте короткие и ёмкие заголовки длиной менее 50 символов
  • Любые пояснения и важные комментарии пишите в поле description

Примеры неудачных заголовков:

  • Detects a process execution in a Windows folder that shouldn't contain executables
    (что тут плохо: бесполезный префикс, слишком много символов, всё в нижнем регистре, содержит пояснения)
  • Detects process injection
    (что тут плохо: бесполезный префикс, слишком общее описание, первые символы в нижнем регистре)

Примеры удачных заголовков:

  • Process Injection Using Iexplore.exe
  • Suspicious PowerShell Cmdline with JAB
  • Certutil Lolbin Decode Use

Поле id

Нет известных ошибок применения данного атрибута. Мы используем опциональное поле id в нашем репоитории для того, чтобы у правила бул уникальный идентификатор, который никогда не изменится, в то время как значения всех остальных полей могут меняться с течением времени.

Поле status

Каждому новому правилу присваивается статус experimental. Только после нескольких месяцев использования его в production и при отсутствии проблем в его работе или при большом количестве позитивных отзывов от комьюнити, статус правила может быть изменён stable.

Поле description

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

Поле references

Значения должны быть указаны в формате списка.

Используйте ссылки только на веб-страницы или документы. Не ссылайтесь на EVTX-, PCAP-файлы или любые другие файлы, которые не содержат непосредственно описание.

Поле author

  • Значение поля author должно быть строкой, а не списком.
  • Если вы хотите указать несколько значений, перечислите их через запятую.
  • Если Вы используете специальные символы (например @ для ссылки на twitter-аккаунт), то необходимо взять такую запись в одинарные кавычки.
    Например author: '@cyb3rops'

Поле date

Мы используем опциональное поле date в наших публичных правилах, для того чтобы указать дату создания правила. Это избавляет от необходимости искать эту информацию через git-log. Как только ранее опубликованное правило первый раз изменяется в ветке master, оно получает дополнительное поле modified для того чтобы указать дату последнего изменения данного правила.

Мы используем формат YYYY/MM/DD. Если говорить о шаблоне в функции strftime языка Python, то нужно использовать %Y/%m/%d.

Поле tags

В нашем публичном наборе правил, мы используем тэги из MITRE ATT&CK и CAR. Вы можете ознакомиться с данными проектами, перейдя по соответствующим ссылкам.

  • Используйте тэги только в нижнем регистре
  • Вместо пробелов и дефисов - используйте символ нижнего подчёркивания _

Секция источника логов (подполя атрибута logsource)

Это более сложная секция. Возможны два два случая:

  1. Подходящий источник логов уже описан и используется другими правилами
  2. Нет ни одного правила, которое использует нужный источник логов

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

  • product (н.р. linux, windows, cisco)
  • service (н.р. sysmon, ldapd, dhcp)
  • category (н.р. process_creation)

Учтите, что данные идентификаторы используются в конфигурационных файлах из папки ./tools/config и используются утилитой sigmac для маппинга специфичных полей события из источника логов на поля, которые Вы используете в своём правиле. Если Вы создаёте новый источник логов, было бы замечательно, если Вы добавите соответствующий маппинг во все текущие конфигурации различных бэкендов (qradar, helk, Splunk-windows и т.д.). Иначе, другие участники комьюнити или разработчики должны это сделать.

Секция описания логики детектирования (подполя атрибута detection)

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

Советы:

  1. Если ваш список состоит из одного элемента, то не используйте для значений данного поля формат списков (см. пример ниже)
  2. Используйте идентификаторы записанные только в нижнем регистре
  3. Если вы используете комментарии, то пишите их на той же строке (используйте 2 пробела для отступа от выражения, которое вы комментируете).
  4. Не используйте регулярные выражения, пока в них не будет действительной необходимости (н.р. вместо Filename|re: '.*\\.exe' используйте Filename|endswith: '\.exe').
  5. В новых источниках используйте названия полей такими, какие они присутствуют в источнике логов, удалите пробелы и оставьте дефисы (н.р. SAM User Account станет SAMUserAccount)
  6. Не используйте в поле condition логику специфичную для какой-то конкретной SIEM.
  7. Проверяйте свои правила прежде чем коммитить их (мы часто видим невалидные выражения в поле condition)

Бэкслэши и экранирование

Бэкслэши выполняют две основные функции в Sigma:

  • Бэкслэш как символ в строке (н.р. в пути к файлу)
  • Бэкслэш как префикс для экранирования служебных символов: сам бэкслэш \, а также метасимволы подстановки (wildcards) * и ?.

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

  • Значения, которые содержат один бэкслеш подряд могут быть записаны в изначальном виде: C:\Windows\System32\cmd.exe
  • Не экранируйте одиночные слэши, пишите исходное значение в предыдущем примере вместо C:\\Windows\\System32\\cmd.exe.
  • Если нужно записать значение в котором присутствуют два бэкслеша подряд , то используйте четыре: из \\\\foo\bar получится значение \\foo\bar.
  • Пишите \\\\ если Вы хотите в итоге получить два символа бэкслеша подряд.
  • Пишите \* если Вы хотите в итоге получить символ *, а не метасимвол подстановки.
  • Пишите \\* если Вы хотите в итоге получить символ бэкслеша перед метасимволом подстановки *.
  • Пишите \\\* если вы хотите в итоге получить символ бэкслэша \ перед символом *.

Модификаторы значений

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

  • Модификаторы, которые добавляют метасимволы подстановки (startswith, endswith и contains) должны следовать после кодирующих модификаторов (base64, base64offset) поскольку иначе кодирующие модификаторы воспримут добавленные символы * как часть изначального значения и закодируют его, что приведёт к потере их специальной функциональности и правило не будет работать как ожидается.
  • Цепочка модификаторов значений не должна оканчиваться модификатором преобразования кодировки символов (utf16, utf16le, utf16be и wide). Поскольку данные модификаторы представляют значение как последовательность байт, вместо строк и содержат нулевые байты, которые обычно сложно обработать в запросах. Поэтому за ними должен следовать кодирующий модификатор (base64, base64offset)
  • Обычно использование модификатора re в цепочке с другими модификаторами не имеет смысла.
  • Вообще говоря, модификатор all может быть помещён в произвольное место цепочки модификаторов, поскольку все модификаторы могут обрабатывать как одиночные значения, так и списки, однако по соглашению, данный модификатор должен быть расположен в конце цепочки.

Наиболее частые сочетания модификаторов:

  • |contains|all: Все значения в списке содержатся в анализируемом поле. Это полезно, когда необходимо описать наличие параметров командной строки без учёта порядка их следования.
  • |utf16|base64offset|contains: значение в кодировке UTF16 закодировано алгоритмом Base64 и может встретиться в любом месте анализируемого значения (н.р. как часть большой Base64-строки).

Поле fields

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

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

Описание случаев ложных срабатываний правила (поле falsepositives)

Во время написания правила, продумайте при каких условиях Ваше правило может сработать ложно. Этот список должен содержать полезные подсказки для аналитика. Например, пояснение "часто используется при анализе защищённости" ("often used in penetration tests"), может подсказать аналитику, что следует сначала узнать у соответствующего департамента про плановые проверки систем безопасности прежде чем бить тревогу.

Поле level

Четыре существующих уровня критичности могут быть в дальнейшем разбиты на две категории.
The four existing levels could further be divided into two categories.

  1. Правила, которые носят информативный характер и должны быть представлены в списках или диаграммах (low, medium)
  2. Правила, о которых нужно сигнализировать и сработки которых необходимо анализировать (high, critical)

Когда выбираете уровень критичности правила, следуйте рекомендациям:

  • Правила уровня критичности critical никогда не должны порождать ложных срабатываний.
  • Правила уровня критичности high порождают сработки, которые должны быть проанализированы вручную.
  • Правила уровня критичности high и critical указывают на то что случился инцидент (если не произошло ложное срабатывание)
  • Правила уровня критичности low и medium указывают на подозрительную активность и нарушения политик.
  • Правила уровня критичности low носят информативный характер и используются для верификации соответствия регуляторным нормам (compliance) или для корреляций с более критичными событиями.

Внешние руководства

Следующие ссылки ведут к веб-страницам, которые описывают процесс создания правил со скриншотами или статьям о конкретных аспектах синтаксиса Sigma-правил.