What is sigma rule

Что за мем «Советы для сигма-самцов». Бруталам рекомендуют покупать деньги и игнорировать женщин

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

Откуда пошёл мем про сигма-самцов

Понятие «сигма-самец» пришло из теории о социальной иерархии, где с помощью букв греческого алфавита (например, «альфа», «бета». — Прим. Medialeaks) обозначают положение мужчины в обществе. Этот термин используется по отношению к успешным и уверенным в себе парням, которые не признают социальное доминирование и не увлекаются тем, что интересует других популярных мужчин. В отличие от альфа-самцов настоящего сигму редко увидишь в окружении женщин.

Иногда сигма-самца называют одиноким волком, ведь он держится особняком, сохраняя флёр загадочности. Такой типаж легко найти в мужских персонажах фильмов и книг. Например, представителями сигмы могут быть главный герой франшизы «Звёздные войны», Хан Соло, персонаж одноимённого боевика Джон Уик или даже Нео из «Матрицы».

Джон Уик может быть круче, но Нео определённо больше сигма.

И хотя термин «сигма» существует уже давно, в Сети его популярность возросла в начале 2021 года, когда пользовательница твиттера опубликовала изображения, недоумевая от концепции социального доминирования.

Чёрт побери, что творится с мужчинами?

После поста девушки начали появляться шутки и мемы на тему сигма-самцов. Например, в декабре телеграм-канал Sad memes for horny people опубликовал забавную пикчу с популярными в интернет-героями и вымышленными персонажами, каждый из которых символизировал один из семи смертных грехов.

Семь смертных грехов сообщества сигма-самцов: Патрик Бейтман (к/ф «Американский психопат») — похоть, Райан Гослинг — обжорство, Джордан Белфорт (к/ф «Волк с Уолл-стрит») — жадность, Хасбик — лень.

Но некоторые интернет-пользователи пошли дальше и придумали правила жизни для настоящих сигма-парней.

Как правила жизни сигма-самцов завирусились в Сети

Мемоделы вдохновились таинственным типажом и придумали свои правила, по которым, по их мнению, должны жить настоящие сигмы.

Воспользуюсь возможностью, чтобы опубликовать несколько советов, как стать сигма-самцом. Вы можете сделать это, короли!

Убивай врачей, которые делают аборты.

Парни хотят стать сигма-самцами, а получается — лишь мемами. Люди открыли этот «тип» мужчин и троллят его

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

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

Но в конце января пользователи твиттера открыли для себя иной подтип в этом разделении, распространённый в Сети, — сигм. Судя по всему, благодарить за просвещение нужно пользователя с ником Lily Simpson. Автор (использует местоимения «они/их») 25 января показал скриншоты из соцсетей о «сигмах» и задался лишь одним вопросом.

Что, [чёрт возьми], творится с мужчинами?

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

Одинокий волк, полная противоположность альфе. Бросает вызов иерархии, но в то же время имеет успех у женщин.

Lily Simpson также приводит скриншот из видео на YouTube с названием «Как стать сигма-мужчиной. Редчайший мужской тип». А ещё — обложку книги «Сигма-самец. Что на самом деле хотят женщины» некоего Джона Т. Александра.

Публикация о сигмах собрала больше 220 тысяч лайков, и в комментариях пользователи с жаром принялись высмеивать создателей и последователей идеи (не хуже, чем парней, предпочитающих бороды в стиле «обезьяний хвост»).

Интеллектуальный даркнет наконец осознал, что они не альфа-самцы, так что им пришлось выдумать новый тип альфа-самцов, которым можно притворяться.

Комментаторы уверены: с фанатами подобных теорий явно что-то не так.

Такие увлечения парней, по их мнению, попросту забавны.

Господи, мужики такие смешные. ))))

И это «насилие» над греческим алфавитом людям уже надоело.

Греческий алфавит работает не так.

Да когда ж у вас кончится греческий алфавит.

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

Ипсилон-самцы ведут свой путь среди нас бесшумно — настолько, что их даже не включают в подобны списки. Лямбда-самцы существуют в альтернативных, недоступных планах бытия.

Троллинг всё продолжался и продолжался. Кажется, даже парню, объяснившему, почему бойфрендам нельзя наклоняться к девушкам, досталось меньше.

Мужчины: «Астрология — это фейк».
Также мужчины: «Я — сигма-бета-ипсилон-самец, это типа самый редкий тип мужчины, наверное, ты о таком не слышала».

Выступают ли сигма-мены в цирке?

Особенно смешно было геймерам, знакомым с видеоиграми Mega Man X, где главного антагониста как раз-таки зовут Сигма.

[«Как стать сигмой. Редчайший тип мужчин» — прим. Medialeaks]

Не обошлось и без мемов.

— Какой твой знак Зодиака? Я Лев.
— Отстань, я не верю в эти выдуманные бредни.
…
— Так правдиво.

Странные и примечательные теории нередко становятся поводом для юмора. Так же было, когда пользователи твиттера узнали, что Бетховен якобы мог быть темнокожим. Их упоротые мемы переосмыслили жизнь легендарного композитора.

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

Все, что вы хотели знать о Sigma-правилах. Часть 2

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

Теперь необходимо научиться описывать логику, которая будет оперировать полученными данными и выдавать вердикт о том, сработает ли наше правило в той или иной ситуации. Именно этой секции правила и ее особенностям посвящена данная статья. Описание секции логики детектирования — это наиболее важная часть синтаксиса, знание которой необходимо для понимания существующих правил и написания собственных.

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

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

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

В общем случае содержимое поля detection состоит из двух логических частей:

Описание предположений о содержимом полей события осуществляется через задание идентификаторов поиска (search identifiers). Такой идентификатор может быть один (как тут) или же их может быть несколько (как тут).

Вторая часть может быть трех видов:

Идентификаторы поиска

Идентификатор поиска представляет из себя пару «ключ — значение», где ключом является название идентификатора поиска, а значением является список или словарь (он же ассоциативный массив). По аналогии с языками программирования — list или map. Формат задания списков и словарей определен стандартом на язык YAML, который можно найти тут. Стоит отметить, что формат Sigma-правил не фиксирует названия идентификаторов поиска, однако чаще всего можно встретить вариации со словом selection.

Есть общие требования, которые применяются и к элементам списка, и к элементам словаря:

Идентификатор поиска в виде словаря

Словари состоят из набора пар «ключ — значение», где ключом является название поля из события, а значение может быть строкой, целым числом или списком одного из этих типов (списки строк или чисел объединены логическим ИЛИ). Наборы словарей объединяются логическим И.

Рассмотрим несколько примеров.

Пример 1. Правило детектирования очистки журналов событий

Данное правило сработает, если событие удовлетворяет условию:

В правиле это выглядит следующим образом:

Здесь selection — название единственного идентификатора поиска, а остальные подполя являются его значением, причем это значение имеет тип «словарь». В этом словаре EventID — ключ, а числа 517 и 1102 образуют список, который являются значением этого ключа словаря.

Пример 2. Подозрительный запрос билета, скорее всего Kerberoasting

Данное правило сработает, если событие удовлетворяет условию:

EventID=4679 И TicketOptions=0x40810000 И TicketEncryption=0x17 И ServiceName не заканчивается на знак ‘$’

В правиле это выглядит следующим образом:

Специальные значения полей

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

Замечание: непустое значение не может быть задано через конструкцию not null

Применение этих значений зависит от целевой SIEM-системы. Чтобы описать условие not null, необходимо создать отдельный идентификатор поиска с пустым значением и взять от него отрицание в условии (поле condition, оно описывается в конце статьи). Рассмотрим далее примеры правил, в которых используется описание пустого поля.

Пример 3. Подозрительный запуск удаленного потока

Указанное правило сработает, если событие удовлетворяет условию:

EventID=8 И TargetImage=’C:\Windows\System32\lsass.exe’ И StartModule является пустым полем

В правиле это выглядит следующим образом:

Пример 4. Запись исполняемого файла в альтернативный файловый поток NTFS

Рассматриваемое правило является примером правильного обозначения непустого значения. Данное правило сработает, если событие удовлетворяет условию:

В правиле это выглядит следующим образом:

Как и было сказано выше, отрицание теперь необходимо ставить в условии (поле condition), а не в идентификаторах поиска.

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

Интерпретация значений полей в правиле может быть изменена посредством модификаторов. Модификаторы добавляются после названия поля, каждому модификатору предшествует вертикальная черта (пайп) — “|”. Их можно сцеплять для построения цепочек (конвейеров) модификаторов:

Значение поля модифицируется в соответствии с порядком следования модификаторов в цепочке. Модификаторы могут быть двух типов: трансформирующие и модификаторы типа.

Трансформирующие модификаторы — это такие, которые конвертируют исходное значение поля в некое другое значение или трансформируют логику обработки списков значений в идентификаторах поиска. Примером первого типа являются Base64-модификаторы, а второго — модификатор all. Обо всех модификаторах подробнее будет рассказано далее.

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

startswith

Модификатор startswith используется для сверки начала строки c искомым значением.

endswith

Модификатор endswith используется для сверки конца строки с искомым значением.

contains

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

То есть, если рассматривать результаты применения рассмотренных модификаторов, можно написать следующую формулу:

startswith + endswith = contains

Обычно элементы листов объединяются логическим ИЛИ. Модификатор all меняет логическое ИЛИ на логическое И. То есть должны присутствовать все элементы списка. Посмотрим, как изменились бы условия в общей схеме, которая была в начале раздела:

Как видим, при применении модификатора all логическая связь между элементами списка стала И. Обычно модификатор all используется в связке с модификатором contains. Такая связка может служить заменой паттерну с метасимволами подстановки в случае, если неизвестен порядок следования статических частей.

Примеры использования модификатора all:

base64

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

Данный модификатор предполагает точное соответствие поля закодированной строке. Обычно полезнее выявлять признаки подозрительной активности в исходных данных, чем искать точное соответствие закодированному результату. Поэтому примеров применения модификатора base64 пока нет.

base64offset

Из-за особенностей кодирования алгоритмом Base64 для поиска закодированной подстроки нельзя использовать конвейер из base64 и contains. Именно для этой цели создан модификатор base64offset. Он применяется, когда строка кодируется алгоритмом Base64, а мы хотим найти подстроку закодированной строки. Более того, заранее неизвестны символы, которые окружают искомую подстроку, и неизвестно смещение подстроки относительно начала строки. Наглядно посмотреть, о чем идет речь, можно тут.

Почти всегда данный модификатор применяется вместе с модификатором contains:

Важно! Следующие три модификатора трансформации кодировки используются только вместе с Base64-модификаторами.

utf16le или wide

utf16be

utf16

Модификатор типа на данный момент только один — re.

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

Временной интервал (атрибут timeframe)

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

Описание условий срабатывания правила (атрибут condition)

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

Логические операции И, ИЛИ

Обозначаются ключевыми словами and и or соответственно. Данные выражения являются основными элементами выстраивания логической взаимосвязи между идентификаторами поиска.

Один из идентификаторов поиска, подходящих под паттерн имени / все идентификаторы поиска, подходящие под паттерн имени (1/all of search-identifier-pattern)

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

Логическое отрицание

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

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

Скобки

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

Выражения на основе агрегатной функции

Агрегатные выражения (или выражения на основе агрегатной функции) используются для оценки количественных характеристик произошедших событий.

Схема агрегатного выражения:

Все агрегатные функции, за исключением count, требуют указания имени поля в качестве параметра. Функция count подсчитывает все совпадающие события, если имя поля не указано. Если имя поля указано, то функция считает различные значения в этом поле. Например, следующее выражение подсчитывает количество различных портов, на которые происходили подключения с одного IP-адреса, и если это количество превышает 10, то правило срабатывает:

Агрегатное выражение near

Ключевое слово near используется для генерации запроса (если такая функциональность поддерживается целевой системой и бэкендом), который распознает появление всех указанных идентификаторов поиска в пределах заданного временного интервала после нахождения первого идентификатора.

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

Замечание: если задано несколько полей condition, то итоговое значение получается применением логического ИЛИ ко всем значениям выражений.

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

Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)

Sigma rules. Поделка или новый стандарт для SOC

Я Сергей Рублев, руководитель SOC (Security Operations Center) в компании «Инфосекьюрити».
В этой статье подробно рассмотрю амбициозный проект Sigma Rules, девиз которого: «Sigma для логов — это как Snort для трафика и Yara для файлов».

Речь пойдет про три аспекта:

Давным-давно, в далекой-далекой галактике

Началось все несколько лет назад, когда деревья были большими, а команда нашего мониторинга — еще маленькой. Мы столкнулись с большим количеством вопросов, через это проходит практически любая команда, перерастающая рубеж в три человека.

Причины появления вопросов различны:

Библиотека Use Case

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

Состав знаний, закладываемый в каждый кейс, может разниться, мы отталкиваемся от следующего набора:

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

В тот момент, когда количество кейсов перевалило за несколько десятков, мы начали искать готовые средства для ведения подобной базы знаний, желательно имеющие, помимо human friendly, еще и какой-то machine friendly интерфейс для работы.

Проект Sigma

Проект Sigma безусловно заслуживает рассмотрения в разрезе базы знаний по правилам выявления инцидентов. Стартовал он в 2016 году, и я за ним слежу практически с самого основания.

Фактически проект состоит из

Синтаксис правил

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

Метаинформация

Описательная часть для структуризации и упрощения поиска нужных правил.

Отдельно хочется отметить, что многие правила уже снабжаются ссылками на технику атаки по методологии MITRE ATT&CK.

Декларация источника данных

Описание источника, на базе событий которого реализована логика обнаружения.

Синтаксически возможно описать как конечный сервис определенного продукта, так и целую категорию систем.

Декларация логики обработки

На уровне логики обнаружения описываются:

так и достаточно сложной:

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

Средства разработки правил

Помимо вашего любимого текстового редактора для YAML доступен еще WEB UI от компании SOC Prime, позволяющий как валидировать синтаксис уже написанного правила, так и создавать правила вручную из графических блоков.

Sigma как средство ведения базы знаний

Подведем краткое резюме.

На текущий момент синтаксис правил в основном концентрируется на описании логики обнаружения угрозы и не предназначен для всестороннего описания use case, соответственно вести полноценную библиотеку только с помощью Sigma Rules не получится.

Для той структуры use case, которую мы выбрали, Sigma закрывает только половину (Objective, Data requirements, Logic и Priority).

Конвертация в различные SIEM

Поскольку мы являемся сервис-провайдером услуг SOC, для нас очень заманчивой выглядела идея держать все наши наработки по правилам корреляции в некотором универсальном формате и на этапе внедрения преобразовывать в формат нужного SIEM.

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

Преобразование происходит в 3 этапа:

В качестве параметров передаются:

Для функции конвертации у SOC Prime также существует готовый UI (uncoder.io)

Подводные камни конвертации

База правил

Посмотрим, что несет в себе публично доступная база правил Sigma. На текущий момент контент активно добавляется в два репозитория:

Для аналитики нам потребуется библиотека sigmatools для Python и немного скиллов программирования.

Для парсинга и загрузки правил из каталога в словарь можно воспользоваться таким кодом:

Дедуплицируя одинаковые правила, выходит следующая картина:

В рамках уникального перечня правил получаем следующие распределения:

По типу источника событий:

Немного укрупняя статистику

4 %

В основном текущий контент ориентируется на систему Windows и Sysmon, в частности, правил по остальным системам считанные единицы.

По степени готовности контента:

Выходит, что разработчики Sigma-правил пометили как стабильные менее 20% всех существующих правил.

Подведем итоги

В публично доступных источниках присутствует большое количество правил. Они регулярно обновляются, и оперативно появляются правила обнаружения индикаторов, а иногда даже и техник по наиболее громким APT-компаниям.

Для применения правил в реальной жизни есть большое количество ограничений:

Все, что вы хотели знать о Sigma-правилах. Часть 1

Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в Twitter детекты громких сетевых атак, поставляем правила анализа трафика в сервис ANY.RUN и пополняем набор правил ETOpen. Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки.

И тут мы узнали, что группа энтузиастов решила устроить двухнедельный спринт по написанию правил для проекта Sigma, который создан ради выработки единого формата описания правил для SIEM-систем и поддерживается более чем 140 участниками. Новость о событии нас заинтересовала, поскольку как вендор SIEM мы внимательно следим за развитием комьюнити.

Каково же было наше удивление, когда с нами связались организаторы и предложили команде PT Expert Security Center поучаствовать в спринте! Участники мероприятия образовали Open Security Collaborative Development (OSCD) — международную инициативу специалистов по ИБ, направленную на распространение знаний и улучшение компьютерной безопасности в целом. Мы с радостью согласились принять участие, чтобы применить свой опыт во благо общей безопасности. [Вторая часть], [Третья часть]

Как появилась эта статья

Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний — GitHub и личный опыт. Есть несколько хороших статей (на русском и на английском), но в них фокус смещен с синтаксиса правил на анализ области применимости Sigma-правил или создание конкретного правила. Мы решили облегчить новичкам знакомство с проектом Sigma, поделиться собственным опытом, собрать в одном месте информацию о синтаксисе и особенностях его применения. Ну и конечно, мы надеемся, что это поспособствует расширению инициативы OSCD и позволит в будущем образовать крупное сообщество.

Поскольку материала получилось очень много, мы решили выпустить описание в цикле из трех статей:

Что такое формат Sigma и зачем он нужен

Sigma — это унифицированный формат описания правил детектирования, основанных на данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Помимо синтаксиса запросов различных SIEM-систем, поддерживается создание запросов следующих видов:

Существование единого формата описания детектов, основанных на логах, позволяет легче обмениваться знаниями, развивать open-source security и помогать сообществу по ИБ бороться с возникающими угрозами.

Общий синтаксис

Прежде всего стоит сказать, что есть обязательные и опциональные части правила. Это описано в официальной wiki на GitHub. Схема правила (источник: официальная Wiki) представлена ниже:

Практически любое правило можно условно разбить на три части:

Есть еще одна особенность строения правила, про которую стоит рассказать. Поскольку правила описываются на языке разметки YAML, разработчики Sigma нашли применение некоторым особенностям этого языка. Дело в том, что формат YAML позволяет разместить в одном файле несколько YAML-документов. А для Sigma — несколько правил объединить в одном файле, то есть создавать «коллекции правил» (rule collections). Такой подход удобен, когда есть несколько способов детектирования атаки и не хочется дублировать описательную часть (как будет описано в соответствующем разделе, дублировать можно не только описательную часть правила).

В таком случае правило условно разбивается на две части:

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

Описание типового правила

Пример создания Sigma-правила

Прежде чем описывать подробности синтаксиса и рассказывать про возможности Sigma-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая статья на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов).

Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:

Проведение атаки

Идея для правила хорошо описана в блоге Hexacorn. После внимательного прочтения становится ясно, какие шаги нужно проделать, чтобы повторить описанный в статье результат:

В системе установлен Sysmon с файлом конфигурации из проекта sysmon-modular. Таким образом сбор логов осуществился автоматически. Какие именно логи полезны для написания детекта, будет видно по ходу написания правила.

Описание детекта в виде Sigma-правила

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

Остальные поля говорят сами за себя, отмечу лишь, что желательно указать ссылки на источники, которые помогли разобраться в атаке. Это поможет людям, которые будут в дальнейшем разбираться в этом правиле, а также это дань уважения тем усилиям, которые приложил автор оригинального исследования для описания атаки.

Наше правило на данном этапе имеет следующий вид:

Далее необходимо описать источники логов. Как уже было сказано выше, мы будем опираться на логи Sysmon, однако с появлением обобщенных категорий, для создания процессов принято использовать категорию process_creation. Про обобщенные категории подробнее будет рассказано ниже. Отметим, что в поле definition принято писать комментарии и советы по настройке источников, такие как особенности конфигурации Sysmon:

Теперь необходимо описать логику детектирования. Это наиболее трудоемкая часть. Данную атаку можно выявить по многим признакам, наш пример не претендует на полноту покрытия всех возможных путей выявления, поэтому опишем один из возможных вариантов.

Отметим, что текущая рабочая директория процесса — пользовательский каталог TEMP.

Далее запущенный процесс создает пакетный файл и запускает его исполнение.

Процесс выполнения инструкций пакетного файла получил идентификатор 7076. При дальнейшем анализе событий видим запуск файла ipconfig.exe, который не содержит присущую системным файлам метаинформацию и плюс ко всему расположен в папке с временными файлами:

Предлагается считать признаком атаки запуск процессов, исполняемые файлы которых не лежат в системной директории (C:\Windows\System32), а также если в строке запуска родительского процесса содержатся подстроки «cmd.exe /c», «RoamDiag.cmd» и «-outputpath». Опишем это в синтаксисе Sigma и получим итоговое правило (детальный разбор конструкций, которые можно использовать для описания логики детектирования, будет дан в следующей части нашего цикла статей про Sigma):

Проверка работоспособности правила

Запускаем конвертер в запрос на языке PowerShell:

Для нашего случая этот запрос не даст нужного результата, поскольку исключающий фильтр также находит и путь до образа исполняемого файла родительского процесса. Поэтому просто укажем, что перед словом Image не должно стоять буквы t — окончание слова Parent:

Видим, что наше событие нашлось. Правило работает.

Так на практике создаются Sigma-правила. Далее подробно опишем поля, отвечающие за детект, а именно за описание источников логов.

Описание детекта

Главная часть правила — описание детекта, поскольку именно здесь содержится информация о том, где и как искать признаки атаки. Эта информация содержится в полях атрибутов logsource (где) и detection (как). В данной статье мы подробно рассмотрим секцию logsource, а секцию detection опишем в следующей части нашего цикла.

Описание секции источников событий (атрибут logsource)

Описание источников событий содержится в значении поля logsource. Эта секция описывает источники данных, из которых будут поставляться события для секции детектирования (атрибут detection рассматривается в следующей части). Секция описывает сам источник, платформу и приложение, которые необходимы для детектирования. Тут могут содержаться три атрибута, которые обрабатываются конвертерами автоматически, и произвольное число необязательных элементов. Основные поля:

На официальной wiki на GitHub определен набор полей, которые необходимо использовать для того, чтобы правила были кросс-продуктовыми. Эти поля сведены в таблицу ниже.

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