Sigma rule что это
Все, что вы хотели знать о Sigma-правилах. Часть 1
Каково же было наше удивление, когда с нами связались организаторы и предложили команде 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. Схема правила представлена ниже:
Практически любое правило можно условно разбить на три части:
Есть еще одна особенность строения правила, про которую стоит рассказать. Поскольку правила описываются на языке разметки YAML, разработчики Sigma нашли применение некоторым особенностям этого ело в том, что формат YAML позволяет разместить в одном файле несколько YAML-документов. А для Sigma — несколько правил объединить в одном файле, то есть создавать «коллекции правил» (rule collections). Такой подход удобен, когда есть несколько способов детектирования атаки и не хочется дублировать описательную часть (как будет описано в соответствующем разделе, дублировать можно не только описательную часть правила).
В таком случае правило условно разбивается на две части:
Далее мы рассмотрим пример гипотетического правила. Стоит отметить, что комментарии в таком виде в правилах обычно не используют, здесь они только для описания полей.
Описание типового правила
Пример создания Sigma-правила
Прежде чем описывать подробности синтаксиса и рассказывать про возможности Sigma-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая статья на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов).
Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:
Проведение атаки
Описание детекта в виде Sigma-правила
На этом шаге возможны два подхода: найти наиболее близкое по логике детектирования существующее правило и модифицировать его под свои нужды или написать правило с нуля. На начальных этапах рекомендуется придерживаться первого подхода. Мы же для наглядности будем писать правило, используя второй подход.
Остальные поля говорят сами за себя, отмечу лишь, что желательно указать ссылки на источники, которые помогли разобраться в атаке. Это поможет людям, которые будут в дальнейшем разбираться в этом правиле, а также это дань уважения тем усилиям, которые приложил автор оригинального исследования для описания атаки.
Наше правило на данном этапе имеет следующий вид:
Далее необходимо описать источники логов. Как уже было сказано выше, мы будем опираться на логи Sysmon, однако с появлением обобщенных категорий, для создания процессов принято использовать категорию process_creation. Про обобщенные категории подробнее будет рассказано ниже. Отметим, что в поле definition принято писать комментарии и советы по настройке источников, такие как особенности конфигурации Sysmon:
Теперь необходимо описать логику детектирования. Это наиболее трудоемкая часть. Данную атаку можно выявить по многим признакам, наш пример не претендует на полноту покрытия всех возможных путей выявления, поэтому опишем один из возможных вариантов.
Отметим, что текущая рабочая директория процесса — пользовательский каталог TEMP.
Далее запущенный процесс создает пакетный файл и запускает его исполнение.
Процесс выполнения инструкций пакетного файла получил идентификатор 7076. При дальнейшем анализе событий видим запуск файла ipconfig.exe, который не содержит присущую системным файлам метаинформацию и плюс ко всему расположен в папке с временными файлами:
Предлагается считать признаком атаки запуск процессов, исполняемые файлы которых не лежат в системной директории (C:WindowsSystem32), а также если в строке запуска родительского процесса содержатся подстроки «cmd.exe /c», «RoamDiag.cmd» и «-outputpath». Опишем это в синтаксисе Sigma и получим итоговое правило (детальный разбор конструкций, которые можно использовать для описания логики детектирования, будет дан в следующей части нашего цикла статей про Sigma):
Проверка работоспособности правила
Запускаем конвертер в запрос на языке PowerShell:
Для нашего случая этот запрос не даст нужного результата, поскольку исключающий фильтр также находит и путь до образа исполняемого файла родительского процесса. Поэтому просто укажем, что перед словом Image не должно стоять буквы t — окончание слова Parent:
Видим, что наше событие нашлось. Правило работает.
Так на практике создаются Sigma-правила. Далее подробно опишем поля, отвечающие за детект, а именно за описание источников логов.
Описание детекта
Главная часть правила — описание детекта, поскольку именно здесь содержится информация о том, где и как искать признаки атаки. Эта информация содержится в полях атрибутов logsource (где) и detection (как). В данной статье мы подробно рассмотрим секцию logsource, а секцию detection опишем в следующей части нашего цикла.
Описание секции источников событий (атрибут logsource)
Описание источников событий содержится в значении поля logsource. Эта секция описывает источники данных, из которых будут поставляться события для секции детектирования (атрибут detection рассматривается в следующей части). Секция описывает сам источник, платформу и приложение, которые необходимы для детектирования. Тут могут содержаться три атрибута, которые обрабатываются конвертерами автоматически, и произвольное число необязательных элементов. Основные поля:
На официальной wiki на GitHub определен набор полей, которые необходимо использовать для того, чтобы правила были кросс-продуктовыми. Эти поля сведены в таблицу ниже.
| Category | Product | Service |
|---|---|---|
| windows | security | |
| system | ||
| sysmon | ||
| taskscheduler | ||
| wmi | ||
| application | ||
| dns-server | ||
| driver-framework | ||
| powershell | ||
| powershell-classic | ||
| linux | auth | |
| auditd | ||
| clamav | ||
| apache | access | |
| error | ||
| process_creation | windows | |
| proxy | ||
| firewall | ||
| webserver | ||
| dns |
Далее опишем подробнее некоторые источники логов с указанием используемых полей событий и приведем примеры правил, в которых данные поля используются.
Поля событий категории Proxy
| Category | Product/Service | Fields | Examples |
|---|---|---|---|
| proxy | c-uri | proxy_ursnif_malware.yml | |
| c-uri-extension | proxy_download_susp_tlds_blacklist.yml | ||
| c-uri-query | proxy_susp_flash_download_loc.yml | ||
| c-uri-stem | proxy_susp_flash_download_loc.yml | ||
| c-useragent | proxy_powershell_ua.yml | ||
| cs-bytes | — | ||
| cs-cookie | proxy_cobalt_amazon.yml | ||
| cs-host | proxy_cobalt_ocsp.yml | ||
| cs-method | proxy_downloadcradle_webdav.yml | ||
| r-dns | proxy_apt40.yml | ||
| cs-referrer | — | ||
| cs-version | — | ||
| sc-bytes | — | ||
| sc-status | proxy_ursnif_malware.yml | ||
| src_ip | — | ||
| dst_ip | — |
Поля событий категории Firewall
| Category | Product/Service | Fields | Examples |
|---|---|---|---|
| firewall | src_ip | — | |
| src_port | — | ||
| dst_ip | — | ||
| dst_port | net_high_dns_bytes_out.yml | ||
| username | — |
Поля событий категории Web server
| Category | Product/Service | Fields | Examples |
|---|---|---|---|
| webserver | c-uri | web_cve_2020_0688_msexchange.yml | |
| c-uri-extension | — | ||
| c-uri-query | — | ||
| c-uri-stem | — | ||
| c-useragent | — | ||
| cs-bytes | — | ||
| cs-cookie | — | ||
| cs-host | — | ||
| cs-method | web_cve_2020_0688_msexchange.yml | ||
| r-dns | — | ||
| cs-referrer | — | ||
| cs-version | — | ||
| sc-bytes | — | ||
| sc-status | — | ||
| src_ip | — | ||
| dst_ip | — |
Обобщенные категории
Поля событий обобщенной категории process_creation
| Category | Product | Fields | Examples |
|---|---|---|---|
| process_creation | windows | UtcTime | — |
| ProcessGuid | — | ||
| ProcessId | sysmon_raw_disk_access_using_illegitimate_tools.yml | ||
| Image | win_susp_regsvr32_anomalies.yml | ||
| FileVersion | sysmon_susp_file_characteristics.yml | ||
| Description | sysmon_susp_file_characteristics.yml | ||
| Product | sysmon_susp_file_characteristics.yml | ||
| Company | sysmon_susp_file_characteristics.yml | ||
| CommandLine | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| CurrentDirectory | win_susp_powershell_parent_combo.yml | ||
| User | win_susp_schtask_creation.yml | ||
| LogonGuid | — | ||
| LogonId | — | ||
| TerminalSessionId | — | ||
| IntegrityLevel | — | ||
| imphash | win_renamed_paexec.yml | ||
| md5 | — | ||
| sha256 | — | ||
| ParentProcessGuid | — | ||
| ParentProcessId | — | ||
| ParentImage | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| ParentCommandLine | win_cmstp_com_object_access.yml |
Статистика использования источников событий в существующих правилах
Ниже в таблице приведены наиболее часто встречающиеся конструкции для описания источников логов. Скорее всего, вы найдете среди них ту, которая подходит для вашего правила.
Статистика по использованию комбинации полей описания некоторых наиболее распространенных источников (прочерк означает отсутствие данного поля):
| Кол-во правил | Category | Product | Service | Пример синтаксиса | Комментарий |
|---|---|---|---|---|---|
| 197 | process_creation | windows | — | logsource: category: process_creation product: windows | Обобщенная категория логов создания процессов на Windows-системах. Включает события Sysmon EventID=1 и события Windows Security Event Log EventID=4688 |
| 68 | — | windows | sysmon | logsource: product: windows service: sysmon | События sysmon |
| 48 | — | windows | security | logsource: product: windows service: security | События из журнала Windows Security Event Log |
| 24 | proxy | — | — | logsource: category: proxy | События из логов прокси-сервера |
| 15 | — | windows | system | logsource: product: windows service: system | События из журнала Windows System Event Log |
| 12 | accounting | cisco | aaa | logsource: category: accounting product: cisco service: aaa | События из журнала Cisco AAA Security Services |
| 10 | — | windows | powershell | logsource: product: windows service: powershell | События из журнала Microsoft Windows PowerShell Event Log |
| 9 | — | linux | — | logsource: product: linux | События аудита в Linux |
| 8 | — | linux | auditd | logsource: product: linux service: auditd | События Linux, уточнение до логов конкретного сервиса (подсистема AuditD) |
Советы по написанию правил
При написании нового правила возможны такие ситуации:
Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости.
Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:
Распределение источников логов
Статистика использования комбинаций подполей атрибута logsource
В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования.
Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
Все, что вы хотели знать о 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 определен набор полей, которые необходимо использовать для того, чтобы правила были кросс-продуктовыми. Эти поля сведены в таблицу ниже.
| Category | Product | Service |
|---|---|---|
| windows | security | |
| system | ||
| sysmon | ||
| taskscheduler | ||
| wmi | ||
| application | ||
| dns-server | ||
| driver-framework | ||
| powershell | ||
| powershell-classic | ||
| linux | auth | |
| auditd | ||
| clamav | ||
| apache | access | |
| error | ||
| process_creation | windows | |
| proxy | ||
| firewall | ||
| webserver | ||
| dns |
Далее опишем подробнее некоторые источники логов с указанием используемых полей событий и приведем примеры правил, в которых данные поля используются.