[Информационная безопасность] Все, что вы хотели знать о Sigma-правилах. Часть 3
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Эта статья — завершение цикла материалов (первая часть, вторая часть), посвященного синтаксису Sigma-правил. Ранее мы рассмотрели пример простого Sigma-правила и подробно описали самые важные части правила — секцию описания источников событий и секцию описания логики детектирования. Теперь у нас есть почти все знания, которые могут понадобиться при написании и разборе Sigma-правил любой сложности. Нам осталось лишь рассмотреть атрибуты, содержащие метаинформацию, и разобраться, что такое коллекции правил и как с ними работать. Именно этим вопросам посвящена заключительная часть цикла.
Атрибуты с метаинформацией
Заголовок (атрибут title)
В заголовке кратко описывается суть правила. Это текстовое поле длиной не более 256 символов. Тут следует давать максимально короткое и емкое описание. Придерживайтесь следующих рекомендаций:
- Не используйте в качестве заголовка конструкции вроде «Detects…». И без этого понятно, что правило что-то детектирует.
- Используйте емкие заголовки длиной не больше 50 символов.
- Любые пояснения и важные комментарии пишите в поле description (рассмотрим его далее).
Подробное описание и дополнительные пояснения к правилу (атрибут description)
Если в заголовке указано краткое описание правила для общего понимания его назначения, то в поле description можно указать все нюансы и особенности, которые автор закладывает в данное правило. Также тут кратко описывается та атака, которую предлагается выявлять при помощи данного правила. Максимальная длина данного поля составляет 65 535 символов.
Уникальный идентификатор правила и идентификаторы связанных правил (id, relative)
Поскольку конкретные значения атрибутов title и description могут быть произвольными, в том числе одинаковыми для двух разных правил (никогда так не делайте), то они не подходят для однозначной идентификации правила. Нужен более формальный, уникальный идентификатор. Universally unique identifier (UUID) используется в подавляющем большинстве продуктов для решения подобной задачи. Авторы Sigma советуют разработчиками правил следовать тем же путем, однако для приватных правил можно использовать любую схему создания идентификаторов. В публичном репозитории в качестве схемы создания идентификаторов выбран упомянутый выше UUID. Такого же подхода мы придерживались в примере правила в первой части статьи. Если вы хотите в дальнейшем опубликовать свое правило или отправить запрос на его добавление в официальный репозиторий, то советуем вам придерживаться той же схемы создания идентификатора правила.
Уникальный идентификатор можно сгенерировать разными способами, в среде Windows проще всего запустить следующий PowerShell-код:
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f
В операционной системе на базе ядра Linux можно использовать утилиту uuidgen:
$ echo “id: `uuidgen`”
id: b2ddd389-f676-4ac4-845a-e00781a48e5f
При внесении значительных изменений в правило его идентификатор должен быть изменен. Ситуации, в которых следует создавать новый идентификатор:
- изменение логики правила;
- наследование правила из существующего с сохранением исходного (справедливо и для ситуации усовершенствования правила);
- слияние правил.
Для случаев наследования и слияния правил есть специальный идентификатор related с четырьмя возможными значениями типа (атрибут type).
Рассмотрим гипотетические ситуации, в которых нам может оказаться полезным использование идентификатора related. Для наглядности вместо длинных идентификаторов в формате UUID будем писать просто X, Y, Z.
В первом случае новое правило (id: X) получено (derived) из существующего (id: Y). Это может случиться, если мы улучшили логику работы в новом правиле, но по какой-то причине старое правило хотим сохранить. Таким образом, у нашего правила есть родительское правило, которое сохраняется и может использоваться в дальнейшем:
Второй случай похож на первый за исключением одного факта: старое правило не сохраняется. То есть мы переписали правило кардинально, и потребовалось присвоение нового идентификатора, а старое устарело (obsoletes) и более использоваться не будет. Итак, у нас было правило (id: Y), которое мы переписали, и мы решили, что оно нам больше не нужно. Новое правило получило идентификатор (id: X). В Sigma-правиле подобная ситуация будет выглядеть примерно так:
В третьем случае рассмотрим ситуацию, когда новое правило появилось как результат слияния (merge) двух или более существующих правил. Новое правило (id: X) является результатом слияния двух правил (id: Y, Z). Важно отметить, что оба родительских правила, которые участвовали в слиянии, сохраняются и могут использоваться дальше. В Sigma-правиле подобная ситуация могла бы выглядеть так:
Хотя при слиянии порядок правил и не определен, в комментариях мы их пронумеровали для наглядности.
Четвертым типом является rename. Как следует из названия, применяется данный тип связи между идентификаторами при переименовании старого правила. По факту данный тип не применяется на практике. В качестве примера использования авторы приводят случай изменения схемы создания идентификаторов (мы помним, что UUID — не единственно возможная схема именования).
Статус готовности правила (атрибут status)
Согласно спецификации, правило может быть в одном из трех состояний:
- stable — правило можно использовать в реальной инфраструктуре для детектирования атак, доработка не требуется;
- test — правило почти стабильное, но требуется небольшая подстройка;
- experimental — такое правило может порождать большое количество ложных срабатываний, но при этом выявляет интересные события.
Обычно до обкатки правила на реальной инфраструктуре правило имеет статус experimental, поскольку еще точно не известно, как часто оно будет порождать ошибки. Далее, после нескольких месяцев проверки, если правило написано хорошо и не порождает ошибок (или их пренебрежимо мало), его переводят в разряд stable. Если иначе — вносят исправления и снова проверяют. В официальном репозитории Sigma нет ни одного правила со статусом test.
Лицензия, по которой распространяется правило (атрибут license)
Лицензия, согласно которой происходит распространение правила. Данное поле пришло из мира свободно распространяемого ПО. Задается крайне редко, но если задано, то должна соответствовать формату SPDX ID specification.
Создатели правила (атрибут author)
В данном поле перечисляются все авторы правила. Хорошим тоном считается указать не только человека, который написал само правило, но и автора оригинальной идеи детектирования.
Ссылки на исследования, которые помогли в разработке правила (атрибут references)
При написании Sigma-правил принято указывать ссылки на оригинальные статьи, твиты и исследования, которые помогли или вдохновили на создание правила. Помимо выражения уважения к чужому труду, такие ссылки помогают впоследствии разобраться, как именно работает правило.
Поля события, которые полезно показать аналитику при срабатывании правила (атрибут fields)
Поскольку автор правила глубоко разобрался в алгоритме атаки и тех событиях, которые порождаются при ее проведении, то он может выбрать список полей из событий, которые помогут оператору SOC или другому сотруднику команды ИБ разобраться в инциденте.
Случаи ошибочного срабатывания правила (атрибут falsepositives)
Поле falsepositives достаточно необычное для правил детектирования. Оно никак не влияет на ход валидации событий, однако выполняет две полезные задачи:
- Помочь пользователю определить, является ли данная сработка правила ошибкой.
- Напомнить лишний раз разработчику правила о том, что его правило может ложно срабатывать. Такие мысли могут помочь разработчику написать более точное правило.
Различные теги и метки (атрибут tags)
Обычно данное поле используется для проставления меток по классификации MITRE ATT&CK и меток CAR. Крайне рекомендуем сразу классифицировать свое правило, поскольку такая разметка позволяет интегрировать правила Sigma с другими проектами по ИБ. Однако формат не ограничивает авторов правил только такими метками, можно проставить любые.
Коллекции правил
Согласно стандарту YAML, один файл (в их терминологии stream) может содержать в себе несколько YAML-документов. Обеспечивается это благодаря метке YAML-документа — три дефиса (“---"). Для формата Sigma эти документы могут быть самостоятельными Sigma-правилами или action-документами.
С первым случаем все просто: в одном файле содержатся полноценные Sigma-правила, которые отделены друг от друга меткой YAML-документа (пример rules/proxy/proxy_ursnif_malware.yml).
Со вторым случаем сложнее. YAML-документ обрабатывается как action-документ, если верхнеуровневый атрибут action имеет одно из трех следующих значений:
- global — задает содержимое, которое будет сливаться со всеми дальнейшими YAML-документами в этом файле. Несколько глобальных action-документов накапливаются в единый буфер. Варианты использования: задание метаинформации и частей правила, которые являются общими для всех Sigma-правил в коллекции;
- reset — сбрасывает содержимое, накопленное из глобальных action-документов;
- repeat — документ с меткой repeat берет содержимое предыдущего правила и сливает его со своим.
Замечание: атрибут action может находиться в любом месте правила.
Наиболее распространенный случай использования коллекции правил — определение нескольких Sigma-правил для схожих событий, таких как Windows Security EventID 4688 и Sysmon EventID 1. Оба события появляются в результате создания процесса, просто у них разные источники. Коллекция Sigma-правил для данного сценария может содержать три action-документа:
- Глобальный action-документ, который определяет общие поля метаданных и индикаторы детектирования.
- Правило, которое определяет источник Windows Security Event Log и событие EventID=4688.
- Правило, которое определяет источник Windows Sysmon Event Log и событие EventID=1.
Альтернативным решением может быть:
- Глобальный action-документ, который определяет общие поля метаданных.
- Правило на Windows Security Event Log (для события EventID=4688) со всеми деталями события.
- Action-документ типа repeat, который заменяет значение атрибута logsource и EventID из правила, определенного в п. 2.
Обработка типов action-документов
В данном разделе мы подробно опишем, как именно Sigma формирует итоговые правила на основе значений атрибута action. YAML-документы, которые содержат атрибут action со значением global, считаются глобальными документами в рамках данного файла, и их поля будут добавлены во все остальные документы.
Замечание: если текущий документ содержит атрибут action со значением reset, то поля глобального документа в него добавлены не будут.
Логика работы с глобальными документами следующая: как только парсер встречает глобальный документ (документ, который содержит атрибут action со значением global), он добавляет его поля в специальный буфер и переходит к следующему документу. Назовем этот специальный буфер GLOBALYAML, это поможет в дальнейшем ссылаться на него на схемах.
Важно: поскольку границы документов задаются меткой “---”, то важно правильно расставить эти метки в файле.
В примере ниже первый YAML-документ содержит атрибут action со значением global. Границы этого документа простираются до первой метки документа. Таким образом, весь первый документ заносится в глобальный буфер. Поля этого буфера затем добавляются к каждому последующему документу. В итоге получаем на выходе два правила.
Схема 1. Обработка простого правила с правильным заданием меток YAML-документа
Но если удалить или забыть первую метку, то все поля YAML DOCUMENT 2 войдут в состав глобального документа. В итоге на выходе получаем только одно правило с некорректным набором идентификаторов поиска. Поэтому очень важно правильно расставлять метки YAML-документов в таких составных правилах.
Схема 2. Обработка предыдущего правила — если забыть проставить первую метку YAML-документа
Стоит отметить, что глобальный документ не обязательно идет в начале. Если смотреть на две предыдущие схемы, то он не всегда является YAML DOCUMENT 1. Более того, он не обязан быть в единственном числе. Следующая схема наглядно показывает это.
Схема 3. Обработка правила, содержащего различные варианты задания глобального YAML-документа
Итак, мы рассмотрели вопросы, связанные с правильной расстановкой меток YAML-документа. А также увидели, что можно по-разному задавать глобальный YAML-документ при помощи атрибута action со значением global. Далее рассмотрим схему преобразования правила при использовании в нем двух оставшихся значений атрибута action — reset и repeat.
Схема 4. Обработка правила, содержащего атрибуты action со значением reset и repeat
Что еще нужно сказать про проект Sigma
Sigma — это не только набор правил с форматом, который мы рассмотрели в данном цикле
В своих публикациях мы сосредоточились на описании формата и синтаксиса правил. Но правила — это только одна половина проекта, вторую составляют бэкенды, которые используются конвертером sigmac. Условно данные конвертеры можно представлять себе как «переходники» с универсальным входом и специфичным выходом. Именно наличие таких «переходников» делает универсальный формат описания таким полезным. В этой ситуации неважно, какой из поддерживаемых систем ты пользуешься, Sigma позволяет описывать идею и алгоритм детектирования, в то время как за конкретный синтаксис целевой системы и маппинг полей отвечает тот или иной бэкенд для конвертера sigmac.
Однако не стоит считать, что, скачав правила и сконвертировав их в синтаксис необходимой целевой системы, вы решите все проблемы, связанные с наполнением вашей системы экспертизой. О том, почему Sigma не является на данный момент «решением из коробки», а также почему необходимо понимание синтаксиса правил, коротко мы поговорим ниже.
Существующие на данный момент вызовы Sigma
Sigma — активно развивающийся проект, и как у любого растущего проекта, у Sigma есть свои вызовы. Лично я их воспринимаю как точки развития и области роста. Ну а поскольку это проект с открытым исходным кодом, то объединив усилия можно внести весомый вклад в развитие тех или иных частей проекта. Перечислю, что на данный момент я отношу к основным вызовам фреймворка:
- Отсутствие возможности корреляции событий. Поскольку агрегатные функции очень трудно назвать механизмом корреляции.
- Правила не сбалансированы, превалируют правила для Windows-инфраструктур (см. диаграммы из первой статьи). Более того, среди части правил есть пересечения по логике и назначению.
- Wiki не структурирована, спецификация описана на одной большой странице. При этом на соседних страницах описаны сущности разного уровня.
- Подавляющее большинство правил находятся в статусе experimental — в основном потому, что слишком мало обратной связи по практике их применения.
- Многие правила требуют верификации или обновления синтаксиса.
- Текущие метки значимости правил выставляются авторами на свое усмотрение, нет единой методики определения опасности той или иной атаки.
По своему опыту скажу, что при знакомстве с проектом Sigma и участии в OSCD наиболее весомым оказался первый пункт списка. Оказалось, что различия между синтаксисом в MaxPatrol SIEM и в Sigma не заканчиваются только семантикой ключевых слов и оформлением правил корреляции. Некоторые наши идеи невозможно описать в рамках синтаксиса Sigma, поскольку на данном этапе не предусмотрена возможность корреляции событий. Механизм корреляции позволяет производить поиск общих значений полей событий и связывать между собой такие события. Это бывает полезно, когда мы хотим точно установить связь между событиями. Например — отслеживать события в рамках одной пользовательской сессии. Для этого нужно связывать события по значению поля LogonID или его аналога.
При этом стоит отметить, что точечные детекты или детекты, основанные на не связанных напрямую событиях, с помощью Sigma описываются весьма успешно.
Один из способов помочь в решении этих и других вопросов — принять активное участие в одном из спринтов OSCD. А поскольку задач много, каждый сможет найти то, что интересно именно ему.
Скоро новый спринт, присоединяйтесь!
Выражаем благодарность организаторам первого спринта за качественное проведение мероприятия и внимательное отношение к участникам. Чего стоят только именные открытки, заполненные от руки и высланные каждому участнику! Со своей стороны мы планируем продолжить участие в новых спринтах и внести посильный вклад в репозиторий Sigma.
Прочитав наш цикл статей и познакомившись поближе с форматом правил, вы вполне сможете применять свою экспертизу во благо всего комьюнити ИБ.
Обязательно присоединяйтесь ко второму спринту. Участвуйте индивидуально и собирайте команды, давайте делать мир безопаснее вместе!
Контакты инициативы OSCD:
Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность] Security Week 34: расшифровка переговоров через VoLTE
- [Информационная безопасность] Спутниковую связь по-прежнему легко прослушать. Перехват трафика кораблей и самолётов
- [Информационная безопасность, IT-компании] Konica Minolta подверглась атаке вируса-вымогателя
- [Информационная безопасность, Python, Программирование, Робототехника, Научно-популярное] pyOpenRPA туториал. Управление WEB приложениями
- [Информационная безопасность, Lua, CTF] HackTheBox. Прохождение Traceback. Бэкдор, LUA, SSH
- [Информационная безопасность, Разработка под Windows] Автоматизация обнаружения возможных путей перехвата DLL (DLL Hijacks) (перевод)
- [Информационная безопасность, Реверс-инжиниринг] Руткиты на основе BIOS. Часть 2 (перевод)
- [Информационная безопасность, Криптография] Какова оптимальная длина пароля? (перевод)
- [Информационная безопасность, Старое железо, Транспорт] Pen Test Partners: обновления ПО самолётов Boeing 747 поставлялись на дискетах
- [Информационная безопасность] Вы просили подсказку? Мы ее вам дадим
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_sigma, #_elasticsearch_query, #_sigmapravila (Sigma-правила), #_blog_kompanii_positive_technologies (
Блог компании Positive Technologies
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 03:42
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Эта статья — завершение цикла материалов (первая часть, вторая часть), посвященного синтаксису Sigma-правил. Ранее мы рассмотрели пример простого Sigma-правила и подробно описали самые важные части правила — секцию описания источников событий и секцию описания логики детектирования. Теперь у нас есть почти все знания, которые могут понадобиться при написании и разборе Sigma-правил любой сложности. Нам осталось лишь рассмотреть атрибуты, содержащие метаинформацию, и разобраться, что такое коллекции правил и как с ними работать. Именно этим вопросам посвящена заключительная часть цикла. Атрибуты с метаинформацией Заголовок (атрибут title) В заголовке кратко описывается суть правила. Это текстовое поле длиной не более 256 символов. Тут следует давать максимально короткое и емкое описание. Придерживайтесь следующих рекомендаций:
Подробное описание и дополнительные пояснения к правилу (атрибут description) Если в заголовке указано краткое описание правила для общего понимания его назначения, то в поле description можно указать все нюансы и особенности, которые автор закладывает в данное правило. Также тут кратко описывается та атака, которую предлагается выявлять при помощи данного правила. Максимальная длина данного поля составляет 65 535 символов. Уникальный идентификатор правила и идентификаторы связанных правил (id, relative) Поскольку конкретные значения атрибутов title и description могут быть произвольными, в том числе одинаковыми для двух разных правил (никогда так не делайте), то они не подходят для однозначной идентификации правила. Нужен более формальный, уникальный идентификатор. Universally unique identifier (UUID) используется в подавляющем большинстве продуктов для решения подобной задачи. Авторы Sigma советуют разработчиками правил следовать тем же путем, однако для приватных правил можно использовать любую схему создания идентификаторов. В публичном репозитории в качестве схемы создания идентификаторов выбран упомянутый выше UUID. Такого же подхода мы придерживались в примере правила в первой части статьи. Если вы хотите в дальнейшем опубликовать свое правило или отправить запрос на его добавление в официальный репозиторий, то советуем вам придерживаться той же схемы создания идентификатора правила. Уникальный идентификатор можно сгенерировать разными способами, в среде Windows проще всего запустить следующий PowerShell-код: PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f В операционной системе на базе ядра Linux можно использовать утилиту uuidgen: $ echo “id: `uuidgen`”
id: b2ddd389-f676-4ac4-845a-e00781a48e5f При внесении значительных изменений в правило его идентификатор должен быть изменен. Ситуации, в которых следует создавать новый идентификатор:
Для случаев наследования и слияния правил есть специальный идентификатор related с четырьмя возможными значениями типа (атрибут type). Рассмотрим гипотетические ситуации, в которых нам может оказаться полезным использование идентификатора related. Для наглядности вместо длинных идентификаторов в формате UUID будем писать просто X, Y, Z. В первом случае новое правило (id: X) получено (derived) из существующего (id: Y). Это может случиться, если мы улучшили логику работы в новом правиле, но по какой-то причине старое правило хотим сохранить. Таким образом, у нашего правила есть родительское правило, которое сохраняется и может использоваться в дальнейшем:  Второй случай похож на первый за исключением одного факта: старое правило не сохраняется. То есть мы переписали правило кардинально, и потребовалось присвоение нового идентификатора, а старое устарело (obsoletes) и более использоваться не будет. Итак, у нас было правило (id: Y), которое мы переписали, и мы решили, что оно нам больше не нужно. Новое правило получило идентификатор (id: X). В Sigma-правиле подобная ситуация будет выглядеть примерно так:  В третьем случае рассмотрим ситуацию, когда новое правило появилось как результат слияния (merge) двух или более существующих правил. Новое правило (id: X) является результатом слияния двух правил (id: Y, Z). Важно отметить, что оба родительских правила, которые участвовали в слиянии, сохраняются и могут использоваться дальше. В Sigma-правиле подобная ситуация могла бы выглядеть так:  Хотя при слиянии порядок правил и не определен, в комментариях мы их пронумеровали для наглядности. Четвертым типом является rename. Как следует из названия, применяется данный тип связи между идентификаторами при переименовании старого правила. По факту данный тип не применяется на практике. В качестве примера использования авторы приводят случай изменения схемы создания идентификаторов (мы помним, что UUID — не единственно возможная схема именования). Статус готовности правила (атрибут status) Согласно спецификации, правило может быть в одном из трех состояний:
Обычно до обкатки правила на реальной инфраструктуре правило имеет статус experimental, поскольку еще точно не известно, как часто оно будет порождать ошибки. Далее, после нескольких месяцев проверки, если правило написано хорошо и не порождает ошибок (или их пренебрежимо мало), его переводят в разряд stable. Если иначе — вносят исправления и снова проверяют. В официальном репозитории Sigma нет ни одного правила со статусом test. Лицензия, по которой распространяется правило (атрибут license) Лицензия, согласно которой происходит распространение правила. Данное поле пришло из мира свободно распространяемого ПО. Задается крайне редко, но если задано, то должна соответствовать формату SPDX ID specification. Создатели правила (атрибут author) В данном поле перечисляются все авторы правила. Хорошим тоном считается указать не только человека, который написал само правило, но и автора оригинальной идеи детектирования. Ссылки на исследования, которые помогли в разработке правила (атрибут references) При написании Sigma-правил принято указывать ссылки на оригинальные статьи, твиты и исследования, которые помогли или вдохновили на создание правила. Помимо выражения уважения к чужому труду, такие ссылки помогают впоследствии разобраться, как именно работает правило. Поля события, которые полезно показать аналитику при срабатывании правила (атрибут fields) Поскольку автор правила глубоко разобрался в алгоритме атаки и тех событиях, которые порождаются при ее проведении, то он может выбрать список полей из событий, которые помогут оператору SOC или другому сотруднику команды ИБ разобраться в инциденте. Случаи ошибочного срабатывания правила (атрибут falsepositives) Поле falsepositives достаточно необычное для правил детектирования. Оно никак не влияет на ход валидации событий, однако выполняет две полезные задачи:
Различные теги и метки (атрибут tags) Обычно данное поле используется для проставления меток по классификации MITRE ATT&CK и меток CAR. Крайне рекомендуем сразу классифицировать свое правило, поскольку такая разметка позволяет интегрировать правила Sigma с другими проектами по ИБ. Однако формат не ограничивает авторов правил только такими метками, можно проставить любые. Коллекции правил Согласно стандарту YAML, один файл (в их терминологии stream) может содержать в себе несколько YAML-документов. Обеспечивается это благодаря метке YAML-документа — три дефиса (“---"). Для формата Sigma эти документы могут быть самостоятельными Sigma-правилами или action-документами. С первым случаем все просто: в одном файле содержатся полноценные Sigma-правила, которые отделены друг от друга меткой YAML-документа (пример rules/proxy/proxy_ursnif_malware.yml). Со вторым случаем сложнее. YAML-документ обрабатывается как action-документ, если верхнеуровневый атрибут action имеет одно из трех следующих значений:
Замечание: атрибут action может находиться в любом месте правила. Наиболее распространенный случай использования коллекции правил — определение нескольких Sigma-правил для схожих событий, таких как Windows Security EventID 4688 и Sysmon EventID 1. Оба события появляются в результате создания процесса, просто у них разные источники. Коллекция Sigma-правил для данного сценария может содержать три action-документа:
Альтернативным решением может быть:
Обработка типов action-документов В данном разделе мы подробно опишем, как именно Sigma формирует итоговые правила на основе значений атрибута action. YAML-документы, которые содержат атрибут action со значением global, считаются глобальными документами в рамках данного файла, и их поля будут добавлены во все остальные документы. Замечание: если текущий документ содержит атрибут action со значением reset, то поля глобального документа в него добавлены не будут. Логика работы с глобальными документами следующая: как только парсер встречает глобальный документ (документ, который содержит атрибут action со значением global), он добавляет его поля в специальный буфер и переходит к следующему документу. Назовем этот специальный буфер GLOBALYAML, это поможет в дальнейшем ссылаться на него на схемах. Важно: поскольку границы документов задаются меткой “---”, то важно правильно расставить эти метки в файле. В примере ниже первый YAML-документ содержит атрибут action со значением global. Границы этого документа простираются до первой метки документа. Таким образом, весь первый документ заносится в глобальный буфер. Поля этого буфера затем добавляются к каждому последующему документу. В итоге получаем на выходе два правила.  Схема 1. Обработка простого правила с правильным заданием меток YAML-документа Но если удалить или забыть первую метку, то все поля YAML DOCUMENT 2 войдут в состав глобального документа. В итоге на выходе получаем только одно правило с некорректным набором идентификаторов поиска. Поэтому очень важно правильно расставлять метки YAML-документов в таких составных правилах.  Схема 2. Обработка предыдущего правила — если забыть проставить первую метку YAML-документа Стоит отметить, что глобальный документ не обязательно идет в начале. Если смотреть на две предыдущие схемы, то он не всегда является YAML DOCUMENT 1. Более того, он не обязан быть в единственном числе. Следующая схема наглядно показывает это.  Схема 3. Обработка правила, содержащего различные варианты задания глобального YAML-документа Итак, мы рассмотрели вопросы, связанные с правильной расстановкой меток YAML-документа. А также увидели, что можно по-разному задавать глобальный YAML-документ при помощи атрибута action со значением global. Далее рассмотрим схему преобразования правила при использовании в нем двух оставшихся значений атрибута action — reset и repeat.  Схема 4. Обработка правила, содержащего атрибуты action со значением reset и repeat Что еще нужно сказать про проект Sigma Sigma — это не только набор правил с форматом, который мы рассмотрели в данном цикле В своих публикациях мы сосредоточились на описании формата и синтаксиса правил. Но правила — это только одна половина проекта, вторую составляют бэкенды, которые используются конвертером sigmac. Условно данные конвертеры можно представлять себе как «переходники» с универсальным входом и специфичным выходом. Именно наличие таких «переходников» делает универсальный формат описания таким полезным. В этой ситуации неважно, какой из поддерживаемых систем ты пользуешься, Sigma позволяет описывать идею и алгоритм детектирования, в то время как за конкретный синтаксис целевой системы и маппинг полей отвечает тот или иной бэкенд для конвертера sigmac. Однако не стоит считать, что, скачав правила и сконвертировав их в синтаксис необходимой целевой системы, вы решите все проблемы, связанные с наполнением вашей системы экспертизой. О том, почему Sigma не является на данный момент «решением из коробки», а также почему необходимо понимание синтаксиса правил, коротко мы поговорим ниже. Существующие на данный момент вызовы Sigma Sigma — активно развивающийся проект, и как у любого растущего проекта, у Sigma есть свои вызовы. Лично я их воспринимаю как точки развития и области роста. Ну а поскольку это проект с открытым исходным кодом, то объединив усилия можно внести весомый вклад в развитие тех или иных частей проекта. Перечислю, что на данный момент я отношу к основным вызовам фреймворка:
По своему опыту скажу, что при знакомстве с проектом Sigma и участии в OSCD наиболее весомым оказался первый пункт списка. Оказалось, что различия между синтаксисом в MaxPatrol SIEM и в Sigma не заканчиваются только семантикой ключевых слов и оформлением правил корреляции. Некоторые наши идеи невозможно описать в рамках синтаксиса Sigma, поскольку на данном этапе не предусмотрена возможность корреляции событий. Механизм корреляции позволяет производить поиск общих значений полей событий и связывать между собой такие события. Это бывает полезно, когда мы хотим точно установить связь между событиями. Например — отслеживать события в рамках одной пользовательской сессии. Для этого нужно связывать события по значению поля LogonID или его аналога. При этом стоит отметить, что точечные детекты или детекты, основанные на не связанных напрямую событиях, с помощью Sigma описываются весьма успешно. Один из способов помочь в решении этих и других вопросов — принять активное участие в одном из спринтов OSCD. А поскольку задач много, каждый сможет найти то, что интересно именно ему. Скоро новый спринт, присоединяйтесь! Выражаем благодарность организаторам первого спринта за качественное проведение мероприятия и внимательное отношение к участникам. Чего стоят только именные открытки, заполненные от руки и высланные каждому участнику! Со своей стороны мы планируем продолжить участие в новых спринтах и внести посильный вклад в репозиторий Sigma. Прочитав наш цикл статей и познакомившись поближе с форматом правил, вы вполне сможете применять свою экспертизу во благо всего комьюнити ИБ. Обязательно присоединяйтесь ко второму спринту. Участвуйте индивидуально и собирайте команды, давайте делать мир безопаснее вместе! Контакты инициативы OSCD: Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center) =========== Источник: habr.com =========== Похожие новости:
Блог компании Positive Technologies ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 03:42
Часовой пояс: UTC + 5