Repository navigation
Rule Creation Guide RU
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)- Не используйте в качестве заголовка конструкции вроде "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 в нашем репоитории для того, чтобы у правила бул уникальный идентификатор, который никогда не изменится, в то время как значения всех остальных полей могут меняться с течением времени.
Каждому новому правилу присваивается статус experimental. Статус правила может быть изменён на stable после нескольких месяцев использования его в production. При этом использовании у него не должно быть выявлено явных изъянов в работе или о данном правиле много положительных отзывов от участников комьюнити.
Нет известных ошибок применения данного атрибута. Постарайтесь описать настолько полно и лаконично, насколько это возможно, в каких ситуациях отрабатывает правило и о чём такая активность может свидетельствовать.
Значения должны быть указаны в формате списка.
Используйте ссылки только на веб-страницы или документы. Не ссылайтесь на EVTX-, PCAP-файлы или любые другие файлы, содержащие сырые данные.
- Значение поля author должно быть строкой, а не списком.
- Если вы хотите указать несколько значений, перечислите их через запятую.
- Если Вы используете специальные символы (например,
@для ссылки на twitter-аккаунт), то необходимо взять такую запись в одинарные кавычки.
Напримерauthor: '@cyb3rops'
Мы используем опциональное поле date в наших публичных правилах, для того чтобы указать дату создания правила. Это избавляет от необходимости искать эту информацию через git-log. Как только ранее опубликованное правило первый раз изменяется в ветке master, оно получает дополнительное поле modified для того чтобы указать дату последнего изменения данного правила.
Мы используем формат YYYY/MM/DD. Если говорить о шаблоне в функции strftime языка Python, то нужно использовать %Y/%m/%d.
В нашем публичном наборе правил, мы используем тэги из MITRE ATT&CK и CAR. Вы можете ознакомиться с данными проектами, перейдя по соответствующим ссылкам.
- Используйте тэги только в нижнем регистре
- Вместо пробелов
-используйте символ нижнего подчёркивания_
Это более сложная секция. Возможны два два случая:
- Подходящий источник логов уже описан и используется другими правилами
- Нет ни одного правила, которое использует нужный источник логов
В первом случае, используйте одно из существующих правил в качестве шаблона. Во втором случае, посмотрите на правила из разных директорий для того чтобы понять как использовать три основных атрибута данной секции:
-
product(н.р. linux, windows, cisco) -
service(н.р. sysmon, ldapd, dhcp) -
category(н.р. process_creation)
Учтите, что данные идентификаторы используются в конфигурационных файлах из папки ./tools/config и используются утилитой sigmac для маппинга между специфичными полями события из источника логов и полями, используемым в правиле. При создании нового источника логов, было бы замечательно добавить соответствующий маппинг во все текущие конфигурации различных бэкендов (qradar, helk, Splunk-windows и т.д.). Иначе, другие участники комьюнити или разработчики должны будут это сделать.
Секция описания логики детектирования имеет весьма гибкий синтаксис, но мы часто сталкиваемся с ошибками или отступлением от общего стиля формирования данной секции, что требует от разработчиков внесения соответствующих корректив в такие правила.
Советы:
- Если ваш список состоит из одного элемента, то не используйте для значений данного поля формат списков (см. пример ниже)
- Используйте идентификаторы, записанные только в нижнем регистре
- Если вы используете комментарии, то пишите их на той же строке (используйте 2 пробела для отступа от выражения, которое вы комментируете).
- Не используйте регулярные выражения, пока в них не будет действительной необходимости (например, вместо
Filename|re: '.*\\.exe'используйтеFilename|endswith: '\.exe'). - В новых источниках используйте названия полей так, как они присутствуют в источнике логов, при этом удаляя пробелы и оставляя дефисы (например,
SAM User AccountстанетSAMUserAccount) - Не используйте в поле
conditionлогику специфичную для какой-то конкретной SIEM-системы. - Проверяйте свои правила прежде чем коммитить их (мы часто видим невалидные выражения в поле
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-строки).
В данном поле указываются названия полей из источника логов, которые помогут аналитику разобраться в случившемся. Например, полезно знать родительский процесс для процесса, в строке запуска которого выявлены подозрительные строки.
Данные поля могут быть извлечены автоматически и представлены аналитику для ускорения процесса анализа.
Во время написания правила, продумайте при каких условиях правило может сработать ложно. Этот список должен содержать полезные подсказки для аналитика. Например, пояснение "часто используется при пентесте", может подсказать аналитику, что следует сначала узнать у соответствующего департамента про плановые проверки систем безопасности прежде чем бить тревогу.
Четыре существующих уровня критичности могут быть в дальнейшем разбиты на две категории.
- Правила, которые носят информативный характер и должны быть представлены в списках или диаграммах (low, medium)
- Правила, о которых нужно сигнализировать и сработки которых необходимо анализировать (high, critical)
При выборе уровня критичности правила следуйте рекомендациям:
- Правила уровня критичности
criticalникогда не должны порождать ложных срабатываний. - Правила уровня критичности
highпорождают сработки, которые должны быть проанализированы вручную. - Правила уровня критичности
highиcriticalуказывают на то, что случился инцидент (если не произошло ложное срабатывание) - Правила уровня критичности
lowиmediumуказывают на подозрительную активность и нарушения политик. - Правила уровня критичности
lowносят информативный характер и используются для верификации соответствия регуляторным нормам (compliance) или для корреляций с более критичными событиями.
Следующие ссылки ведут к веб-страницам, которые описывают процесс создания правил со скриншотами или статьям о конкретных аспектах синтаксиса Sigma-правил.
 |
 |
|---|