Данная статья является завершением серии материалов ( Первая часть , Вторая часть ), посвященный синтаксису правил Sigma. Ранее мы рассмотрели пример простого правила Сигмы и подробно описали наиболее важные части правила — раздел, описывающий источники событий, и раздел, описывающий логику обнаружения.
Теперь у нас есть практически все знания, которые могут понадобиться при написании и разборе правил Сигмы любой сложности.
Все, что нам нужно сделать, это посмотреть на атрибуты, содержащие метаинформацию, и разобраться, что такое коллекции правил и как с ними работать.
Этим вопросам посвящена заключительная часть серии.
Атрибуты с метаинформацией
Название (атрибут заголовка)
Название кратко описывает суть правила.Это текстовое поле длиной не более 256 символов.
Здесь вы должны дать как можно более краткое и ёмкое описание.
Следуйте этим рекомендациям:
- Не используйте в заголовке конструкции типа «Обнаруживает.».
Даже без этого понятно, что правило что-то обнаруживает.
- Используйте краткие заголовки длиной не более 50 символов.
- Пожалуйста, пишите любые уточнения или важные комментарии в поле описания (мы рассмотрим это позже).
Подробное описание и дополнительные пояснения к правилу (атрибут описания)
Если в заголовке содержится краткое описание правила для общего понимания его назначения, то в поле описания можно указать все нюансы и особенности, которые вкладывает в это правило автор.Также кратко описывается атака, которую предлагается обнаруживать с помощью этого правила.
Максимальная длина этого поля — 65 535 символов.
Уникальный идентификатор правила и идентификаторы связанных правил (id, относительный)
Поскольку конкретные значения атрибутов title иdescription могут быть произвольными, в том числе одинаковыми для двух разных правил (никогда этого не делайте), они не подходят для однозначной идентификации правила.Необходим более формальный уникальный идентификатор.
Для решения этой проблемы в подавляющем большинстве продуктов используется универсальный уникальный идентификатор (UUID).
Авторы Sigma советуют разработчикам правил идти по тому же пути, однако для частных правил можно использовать любую схему создания идентификаторов.
В публичном репозитории в качестве схемы создания идентификатора выбран упомянутый выше UUID. Мы использовали тот же подход в примере с правилом в первой части статьи.
Если вы захотите в будущем опубликовать свое правило или отправить запрос на его добавление в официальный репозиторий, советуем вам следовать той же схеме создания идентификатора правила.
Уникальный идентификатор может быть сгенерирован разными способами; в среде Windows проще всего запустить следующий код PowerShell:
В операционной системе на базе ядра Linux можно использовать утилиту uuidgen:PS C:\> "id: $(New-Guid)" id: b2ddd389-f676-4ac4-845a-e00781a48e5f
$ echo “id: `uuidgen`”
id: b2ddd389-f676-4ac4-845a-e00781a48e5fЕсли в правило вносятся существенные изменения, его идентификатор необходимо изменить.
Ситуации, в которых следует создать новый идентификатор:
- изменение логики правил;
- наследование правила от существующего с сохранением исходного (это справедливо и для ситуации улучшения правила);
- объединение правил.
Давайте рассмотрим гипотетические ситуации, в которых нам может быть полезно использовать связанный идентификатор.
Для наглядности вместо длинных идентификаторов в формате UUID будем писать просто X, Y, Z. В первом случае новое правило (id: X) создается на основе существующего (id: Y).
Такое может произойти, если мы улучшили логику нового правила, но по какой-то причине хотим сохранить старое правило.
Таким образом, у нашего правила есть родительское правило, которое сохраняется и может быть использовано позже: 
Второй случай аналогичен первому, за исключением одного факта: старое правило не применяется.
То есть мы кардинально переписали правило, и нужно было присвоить новый идентификатор, а старый устарел (устарел) и больше использоваться не будет. Итак, у нас было правило (id: Y), которое мы переписали и решили, что оно нам больше не нужно.
Новое правило получило идентификатор (id: X).
В правиле Сигмы аналогичная ситуация выглядела бы примерно так: 
В третьем случае рассмотрим ситуацию, когда новое правило появилось в результате слияния двух и более существующих правил.
Новое правило (id: X) является результатом слияния двух правил (id: Y, Z).
Важно отметить, что оба родительских правила, участвовавшие в слиянии, сохраняются и могут использоваться дальше.
В правиле Сигмы аналогичная ситуация может выглядеть так: 
Хотя порядок правил при слиянии не определен, мы для ясности пронумеровали их в комментариях.
Четвертый тип — переименование.
Как следует из названия, этот тип связи между идентификаторами используется при переименовании старого правила.
На самом деле этот тип на практике не используется.
В качестве примера использования авторы приводят случай изменения схемы создания идентификатора (мы помним, что UUID — не единственно возможная схема именования).
Статус готовности правила (атрибут status)
Согласно спецификации правило может находиться в одном из трёх состояний:- стабильный — правило можно использовать в реальной инфраструктуре для обнаружения атак, модификация не требуется;
- тест — правило практически стабильно, но требуется небольшая корректировка;
- экспериментальный — такое правило может генерировать большое количество ложных срабатываний, но при этом выявляет интересные события.
Далее, после нескольких месяцев тестирования, если правило написано хорошо и не генерирует ошибок (или есть незначительные ошибки), оно переводится в категорию стабильных.
В противном случае вносят исправления и проверяют еще раз.
В официальном репозитории Sigma нет ни одного правила со статусом test.
Лицензия, по которой распространяется правило (атрибут лицензии).
Лицензия, по которой распространяется правило.
Эта область пришла из мира свободного программного обеспечения.
Указывается крайне редко, но если указывается, то должно соответствовать формату спецификации SPDX ID.
Создатели правил (атрибут автора)
В этом поле перечислены все авторы правила.Считается хорошим тоном указывать не только человека, написавшего само правило, но и автора оригинальной идеи обнаружения.
Ссылки на исследования, которые помогли разработать правило (атрибут «ссылки»).
При написании правил Sigma обычно включают ссылки на оригинальные статьи, твиты и исследования, которые помогли или вдохновили создание правила.
Такие упоминания не только демонстрируют уважение к труду других, но и помогают позже понять, как именно работает правило.
Поля событий, которые удобно показывать аналитику при срабатывании правила (атрибут полей).
Поскольку автор правила имеет глубокое понимание алгоритма атаки и событий, которые генерируются при ее выполнении, он может выбрать из событий список полей, которые помогут оператору SOC или другому члену группы ИБ понять суть происходящего.
инцидент.
Случаи ошибочного срабатывания правил (признак falsepositives)
Поле ложных срабатываний довольно необычно для правил обнаружения.Он никак не влияет на ход проверки событий, но выполняет две полезные задачи:
- Помогите пользователю определить, является ли данный триггер правила ошибкой.
- Еще раз напомните разработчику правила, что его правило может сработать ложно.
Такие мысли могут помочь разработчику написать более точное правило.
Различные теги и метки (атрибут tags)
Это поле обычно используется для маркировки классификаций MITRE ATT&CK и знаков CAR. Мы настоятельно рекомендуем сразу засекретить ваше правило, поскольку такая маркировка позволяет интегрировать правила Sigma с другими проектами по информационной безопасности.Однако формат не ограничивает авторов правил только такими метками; вы можете добавить любой.
Коллекции правил
Согласно стандарту YAML, один файл (в их терминологическом потоке) может содержать несколько документов YAML. Это обеспечивается благодаря метке документа YAML — трем дефисам («---»).Для формата Sigma эти документы могут быть независимыми правилами Sigma или документами действий.
В первом случае все просто: один файл содержит полноценные правила Sigma, которые отделены друг от друга меткой YAML-документа (пример правила/прокси/proxy_ursnif_malware.yml ).
Второй случай сложнее.
Документ YAML обрабатывается как документ действия, если атрибут действия верхнего уровня имеет одно из следующих трех значений:
- Глобальный — указывает содержимое, которое будет объединено со всеми последующими документами YAML в этом файле.
Несколько документов глобальных действий аккумулируются в едином буфере.
Варианты использования: указание метаинформации и частей правил, общих для всех правил Sigma в коллекции;
- перезагрузить — сбрасывает контент, накопленный из документов глобальных действий;
- повторить — документ, помеченный как повтор, берет содержимое предыдущего правила и объединяет его со своим собственным.
Наиболее распространенным вариантом использования коллекции правил является определение нескольких правил Sigma для аналогичных событий, таких как Windows Security EventID 4688 и Sysmon EventID 1. Оба события являются результатом создания процесса, просто они имеют разные источники.
Сборник правил Сигмы для данного сценария может содержать три документа действий:
- Документ глобального действия, определяющий общие поля метаданных и индикаторы обнаружения.
- Правило, определяющее источник журнала событий безопасности Windows и события EventID=4688.
- Правило, определяющее источник журнала событий Windows Sysmon и события EventID=1.
- Документ глобального действия, определяющий общие поля метаданных.
- Правило для журнала событий безопасности Windows (для события EventID=4688) со всеми подробностями события.
- Документ действия типа повтор, который заменяет значение атрибута logsource и EventID из правила, определенного в пункте 2.
Типы документов действий по обработке
В этом разделе мы подробно опишем, как именно Sigma генерирует результирующие правила на основе значений атрибута action. Документы YAML, содержащие атрибут действия со значением global, считаются глобальными документами в файле, и их поля будут добавлены ко всем остальным документам.Комментарий : если текущий документ содержит атрибут действия со значением сброса, то поля глобального документа в него добавляться не будут. Логика работы с глобальными документами следующая: как только парсер встречает глобальный документ (документ, содержащий атрибут действия со значением global), он добавляет его поля в специальный буфер и переходит к следующему документу.
Назовем этот специальный буфер GLOBALYAML, это поможет в дальнейшем обращаться к нему в диаграммах.
Важный : Поскольку границы документа обозначаются знаком «---», важно правильно разместить эти отметки в файле.
В приведенном ниже примере первый документ YAML содержит атрибут действия со значением global. Границы этого документа простираются до первой метки документа.
Таким образом, весь первый документ записывается в глобальный буфер.
Поля этого буфера затем добавляются в каждый последующий документ. В результате мы получаем на выходе два правила.
Схема 1. Обработка простого правила с правильной разметкой YAML-документа
Но если вы удалите или забудете первую метку, то все поля YAML-ДОКУМЕНТА 2 станут частью глобального документа.
В результате на выходе получается только одно правило с неверным набором поисковых идентификаторов.
Поэтому очень важно правильно маркировать YAML-документы в таких составных правилах.
Схема 2. Обработка предыдущего правила — если вы забыли поставить первую метку YAML-документа
Стоит отметить, что глобальный документ не обязательно идет в начале.
Если вы посмотрите на две предыдущие диаграммы, то это не всегда YAML-ДОКУМЕНТ 1. Более того, он не обязательно должен быть единственным.
Следующая диаграмма наглядно это показывает. 
Схема 3. Обработка правила, содержащего различные варианты указания глобального YAML-документа
Итак, мы рассмотрели вопросы, связанные с правильным размещением меток в YAML-документе.
Мы также увидели, что вы можете установить глобальный документ YAML разными способами, используя атрибут действия со значением global. Далее мы рассмотрим схему трансформации правила при использовании в нем двух оставшихся значений атрибута действия — сброса и повтора.
Схема 4. Обработка правила, содержащего атрибуты действия со сбросом и повторением значений
Что еще нужно сказать о проекте «Сигма»
Сигма — это не только набор правил в том формате, который мы рассмотрели в этой серии.
В наших публикациях мы сосредоточились на описании формата и синтаксиса правил.
Но правила — это только одна половина проекта, другая — бэкенды, которые использует конвертер sigmac. Условно эти преобразователи можно представить как «переходники» с универсальным входом и конкретным выходом.
Именно наличие таких «переходников» делает универсальный формат описания таким полезным.
В этой ситуации не имеет значения, какую из поддерживаемых систем вы используете, Sigma позволяет описать идею и алгоритм обнаружения, а за конкретный синтаксис целевой системы и отображение полей отвечает тот или иной бэкенд для конвертера sigmac. .
Однако не стоит рассчитывать, что, скачав правила и преобразуя их в синтаксис необходимой целевой системы, вы решите все проблемы, связанные с наполнением вашей системы экспертизой.
Ниже мы кратко поговорим о том, почему Sigma на данный момент не является «готовым решением», а также почему необходимо понимание синтаксиса правил.
Текущие проблемы Сигмы
Sigma — активно развивающийся проект, и, как и любой растущий проект, у Sigma есть свои проблемы.Лично я воспринимаю их как точки развития и зоны роста.
Что ж, поскольку это проект с открытым исходным кодом, объединив усилия, вы сможете внести существенный вклад в развитие отдельных частей проекта.
Я перечислю то, что я на данный момент считаю основными вызовами фреймворка:
- Отсутствие умения соотносить события.
Потому что агрегатные функции очень сложно назвать корреляционным механизмом.
- Правила не сбалансированы; преобладают правила для инфраструктур Windows (см.
схемы из первой статьи).
Более того, среди некоторых правил есть совпадения по логике и целям.
- Вики не структурирована, спецификация описана на одной большой странице.
При этом на соседних страницах описаны сущности разных уровней.
- Подавляющее большинство правил находится в экспериментальном статусе, главным образом потому, что имеется слишком мало отзывов о практике их применения.
- Многие правила требуют проверки или обновления синтаксиса.
- Текущие метки значимости правил устанавливаются авторами по своему усмотрению; не существует единого метода определения опасности того или иного нападения.
Оказалось, что различия между синтаксисом в МаксПатрол SIEM и Sigma не ограничивается только семантикой ключевых слов и разработкой правил корреляции.
Некоторые наши идеи невозможно описать в рамках синтаксиса Сигмы, поскольку на этом этапе нет возможности корреляции событий.
Механизм корреляции позволяет искать общие значения полей событий и связывать такие события друг с другом.
Это полезно, когда мы хотим точно установить связь между событиями.
Например, для отслеживания событий внутри одной пользовательской сессии.
Для этого вам необходимо связать события по значению поля LogonID или его эквивалента.
Стоит отметить, что с помощью Sigma очень успешно описываются точечные обнаружения или обнаружения на основе не связанных напрямую событий.
Один из способов помочь решить эти и другие проблемы — активно участвовать в одном из спринтов OSCD. А поскольку задач много, каждый сможет найти то, что ему интересно.
Скоро новый спринт, присоединяйтесь!
Хотим выразить благодарность организаторам первого спринта за качество мероприятия и внимательное отношение к участникам.Только задумайтесь о стоимости именной открытки, заполненной вручную и отправленной каждому участнику! Со своей стороны, мы планируем продолжать участвовать в новых спринтах и вносить любой возможный вклад в репозиторий Sigma. Прочитав нашу серию статей и поближе познакомившись с форматом правил, вы сможете использовать свой опыт на благо всего сообщества информационной безопасности.
Обязательно присоединитесь ко второму спринту.
Участвуйте индивидуально и собирайте команды, сделаем мир безопаснее вместе! Контакты инициативы OSCD:
Автор : Антон Кутепов, специалист отдела экспертных услуг и развития Positive Technologies (Центр безопасности PT Expert) Теги: #информационная безопасность #elasticsearch запрос #Sigma #правила Sigma #правила Sigma-
Суперкомпьютер За $1256
19 Oct, 24 -
Тихий Щелчок Мышкой
19 Oct, 24
