Онлайн
Ветеран- Регистрация
- 14.05.16
- Сообщения
- 21.461
- Реакции
- 102
- Репутация
- 204
Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в
И тут мы узнали, что группа энтузиастов решила устроить
Каково же было наше удивление, когда с нами связались организаторы и предложили команде
Как появилась эта статья
Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний —
Поскольку материала получилось очень много, мы решили выпустить описание в цикле из трех статей:
Что такое формат Sigma и зачем он нужен
Sigma — это унифицированный формат описания правил детектирования, основанных на данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Помимо синтаксиса запросов различных SIEM-систем, поддерживается создание запросов следующих видов:
Два последних вида примечательны тем, что не требуют дополнительного ПО для анализа логов. Утилита grep и интерпретатор PowerShell поддерживаются «из коробки» в ОС Linux и Windows соответственно.
Существование единого формата описания детектов, основанных на логах, позволяет легче обмениваться знаниями, развивать open-source security и помогать сообществу по ИБ бороться с возникающими угрозами.
Общий синтаксис
Прежде всего стоит сказать, что есть обязательные и опциональные части правила. Это описано в официальной wiki на GitHub. Схема правила представлена ниже:
Практически любое правило можно условно разбить на три части:
Каждой из частей соответствуют обязательные высокоуровневые атрибуты title (помимо title, в последнюю группу входят остальные необязательные высокоуровневые атрибуты), logsource и detection.
Есть еще одна особенность строения правила, про которую стоит рассказать. Поскольку правила описываются на языке разметки YAML, разработчики Sigma нашли применение некоторым особенностям этого ело в том, что формат YAML позволяет разместить в одном файле несколько YAML-документов. А для Sigma — несколько правил объединить в одном файле, то есть создавать «коллекции правил» (rule collections). Такой подход удобен, когда есть несколько способов детектирования атаки и не хочется дублировать описательную часть (как будет описано в соответствующем разделе, дублировать можно не только описательную часть правила).
В таком случае правило условно разбивается на две части:
Если файл содержит единственное правило, данное утверждение тоже истинно, поскольку мы получаем вырожденную коллекцию из одного правила. Коллекции правил будут подробно рассмотрены в третьей части цикла статей.
Далее мы рассмотрим пример гипотетического правила. Стоит отметить, что комментарии в таком виде в правилах обычно не используют, здесь они только для описания полей.
Описание типового правила
Пример создания Sigma-правила
Прежде чем описывать подробности синтаксиса и рассказывать про возможности Sigma-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая
Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:
Проведение атаки
Идея для правила хорошо описана в
В системе установлен
Описание детекта в виде Sigma-правила
На этом шаге возможны два подхода: найти наиболее близкое по логике детектирования существующее правило и модифицировать его под свои нужды или написать правило с нуля. На начальных этапах рекомендуется придерживаться первого подхода. Мы же для наглядности будем писать правило, используя второй подход.
Создаем новый файл и стараемся кратко и емко описать его суть в названии. Тут следует придерживаться стиля существующих правил. В нашем случае мы выбрали название win_using_settingsynchost_to_run_hijacked_binary.yml. Далее начинаем заполнять его содержимым. Начнем с заполнения метаинформации в начале правила. Все данные, необходимые для этого, у нас уже есть.
Описываем кратко, какую атаку выявляет правило, в поле title, более подробные пояснения — в поле description, для новых правил принято ставить status: experimental. Уникальный идентификатор можно сгенерировать разными способами, в среде Windows проще всего запустить следующий код в интерпретаторе PowerShell:
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f
Остальные поля говорят сами за себя, отмечу лишь, что желательно указать ссылки на источники, которые помогли разобраться в атаке. Это поможет людям, которые будут в дальнейшем разбираться в этом правиле, а также это дань уважения тем усилиям, которые приложил автор оригинального исследования для описания атаки.
Наше правило на данном этапе имеет следующий вид:
Далее необходимо описать источники логов. Как уже было сказано выше, мы будем опираться на логи Sysmon, однако с появлением обобщенных категорий, для создания процессов принято использовать категорию process_creation. Про обобщенные категории подробнее будет рассказано ниже. Отметим, что в поле definition принято писать комментарии и советы по настройке источников, такие как особенности конфигурации Sysmon:
Теперь необходимо описать логику детектирования. Это наиболее трудоемкая часть. Данную атаку можно выявить по многим признакам, наш пример не претендует на полноту покрытия всех возможных путей выявления, поэтому опишем один из возможных вариантов.
Если посмотреть на события, которые произошли, можно выстроить следующую цепочку.
Сначала запустили процесс (PID: 4712) со строкой запуска c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript join_oscd
Отметим, что текущая рабочая директория процесса — пользовательский каталог 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 на
Далее опишем подробнее некоторые источники логов с указанием используемых полей событий и приведем примеры правил, в которых данные поля используются.
Поля событий категории Proxy
Описание полей событий данного источника
---------------------------------------------------------------
c-uri - URI, запрошенный клиентом
c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла
c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу
c-uri-stem - Обычно это часть URL от хоста (или хост:порт) и до строки запроса. Чаще всего в URIstem содержится путь до ресурса относительно корневой директории веб-сервера
c-useragent - Заголовок UserAgent в HTTP-запросе клиента
cs-bytes - Количество байтов, отправленных от клиента к серверу
cs-cookie - Значения cookie, которые передает клиент на сервер
cs-host - Заголовок Host в HTTP-запросе клиента
cs-method - Метод HTTP-запроса клиента
r-dns - DNS-имя запрашиваемого сервера
cs-referrer - Заголовок Referrer в HTTP-запросе клиента
cs-version - Версия протокола HTTP, которую использует клиент
sc-bytes - Количество байтов, отправленных от сервера к клиенту
sc-status - Код HTTP-ответа
src_ip - IP-адрес клиента
dst_ip - IP-адрес сервера
Поля событий категории Firewall
Описание полей событий данного источника
---------------------------------------------------------------
src_ip - IP-адрес клиента
src_port - Порт, с которого происходит подключение
dst_ip - IP-адрес сервера
dst_port - Порт, на который происходит подключение
username - Имя пользователя, который осуществляет подключение
Поля событий категории Web server
Описание полей событий данного источника
---------------------------------------------------------------
c-uri - URI, запрошенный клиентом
c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла
c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу
c-uri-stem - Обычно это часть URI от хоста (или хост:порт) и до строки запроса. Чаще всего в URI stem содержится путь до ресурса относительно корневой директории веб-сервера
c-useragent - Заголовок UserAgent в HTTP-запросе клиента
cs-bytes - Количество байтов, отправленных от клиента к серверу
cs-cookie - Значения cookie, которые передает клиент на сервер
cs-host - Заголовок Host в HTTP-запросе клиента
cs-method - Метод HTTP-запроса клиента
r-dns - DNS-имя запрашиваемого сервера
cs-referrer - Заголовок Referrer в HTTP-запросе клиента
cs-version - Версия протокола HTTP, которую использует клиент
sc-bytes - Количество байтов, отправленных от сервера к клиенту
sc-status - Код HTTP-ответа
src_ip - IP-адрес клиента
dst_ip - IP-адрес сервера
Обобщенные категории
Поскольку Sigma — это обобщенный формат описания правил детектирования, основанных на логах, синтаксис таких правил должен уметь описать логику детектирования для разных систем. Некоторые системы используют таблицы с агрегированными данными вместо событий, а для описания одной и той же ситуации могут поступать данные из разных источников. Для унификации синтаксиса и решения подобных проблем был введен механизм обобщенных источников событий (generic logsources). На данный момент создана одна такая категория — process_creation. Подробнее об этом можно почитать в
Поля событий обобщенной категории process_creation
Описание полей событий данного источника
---------------------------------------------------------------
UtcTime -Время события в формате UTC
ProcessGuid - GUID созданного процесса
ProcessId - PID созданного процесса
Image - Путь к запущенному исполняемому файлу
FileVersion - Версия программы, взятая из ресурсов исполняемого файла
Description - Описание программы, взятое из ресурсов исполняемого файла
Product - Название программы, взятое из ресурсов исполняемого файла
Company - Название компании — разработчика программы, взятое из ресурсов исполняемого файла
CommandLine - Строка запуска создаваемого процесса
CurrentDirectory - Текущая директория созданного процесса
User - Пользователь, от имени которого запускается процесс
LogonGuid - GUID текущей пользовательской сессии
LogonId - Идентификатор текущей пользовательской сессии
TerminalSessionId - Идентификатор текущей терминальной сессии
IntegrityLevel - Уровень целостности, с которым запускается процесс
imphash - Хеш-сумма на основе данных из таблицы импорта исполняемого файла
md5 - MD5-хеш исполняемого файла, на основе которого создается процесс
sha256 - SHA256-хеш исполняемого файла, на основе которого создается процесс
ParentProcessGuid - GUID родительского процесса
ParentProcessId - PID родительского процесса
ParentImage - Путь к исполняемому файлу родительского процесса
ParentCommandLine - Строка запуска родительского процесс
Статистика использования источников событий в существующих правилах
Ниже в таблице приведены наиболее часто встречающиеся конструкции для описания источников логов. Скорее всего, вы найдете среди них ту, которая подходит для вашего правила.
Статистика по использованию комбинации полей описания некоторых наиболее распространенных источников (прочерк означает отсутствие данного поля):
Советы по написанию правил
При написании нового правила возможны такие ситуации:
Если вы столкнулись с первым случаем, то используйте одно из существующих правил в качестве шаблона. Возможно, нужный источник логов уже используется в других правилах, тогда это значит, что авторы плагинов (бэкенд-конвертеры) под разные SIEM-системы, скорее всего, учли его в своем маппинге и ваше правило должно сразу корректно обрабатываться.
Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости.
Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:
Распределение источников логов
Статистика использования комбинаций подполей атрибута logsource
В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования.
Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
You must be registered for see links
детекты громких сетевых атак, поставляем правила анализа трафика в
You must be registered for see links
и пополняем набор
You must be registered for see links
. Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки. И тут мы узнали, что группа энтузиастов решила устроить
You must be registered for see links
по написанию правил для
You must be registered for see links
, который создан ради выработки единого формата описания правил для SIEM-систем и поддерживается 140 участниками. Новость о событии нас заинтересовала, поскольку как
You must be registered for see links
мы внимательно следим за развитием комьюнити.Каково же было наше удивление, когда с нами связались организаторы и предложили команде
You must be registered for see links
поучаствовать в спринте! Участники мероприятия образовали Open Security Collaborative Development (OSCD) — международную инициативу специалистов по ИБ, направленную на распространение знаний и улучшение компьютерной безопасности в целом. Мы с радостью согласились принять участие, чтобы применить свой опыт во благо общей безопасности. Как появилась эта статья
Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний —
You must be registered for see links
и личный опыт. Есть несколько хороших статей (на
You must be registered for see links
и на
You must be registered for see links
), но в них фокус смещен с синтаксиса правил на анализ области применимости Sigma-правил или создание конкретного правила. Мы решили облегчить новичкам знакомство с проектом Sigma, поделиться собственным опытом, собрать в одном месте информацию о синтаксисе и особенностях его применения. Ну и конечно, мы надеемся, что это поспособствует расширению инициативы OSCD и позволит в будущем образовать крупное сообщество.Поскольку материала получилось очень много, мы решили выпустить описание в цикле из трех статей:
- Небольшое введение, пример создания простого правила и описание источников событий (и эту статью вы читаете сейчас).
- Описание логики детектирования. Это наиболее важная часть синтаксиса, знание которой необходимо для понимания существующих правил и написания собственных.
- Описание метаинформации (атрибуты, которые имеют информативный или инфраструктурный характер, такие, например, как описание или идентификатор) и коллекций правил.
Что такое формат Sigma и зачем он нужен
Sigma — это унифицированный формат описания правил детектирования, основанных на данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Помимо синтаксиса запросов различных SIEM-систем, поддерживается создание запросов следующих видов:
- Elasticsearch Query,
- строка запуска утилиты grep с нужными параметрами,
- строка обращения к журналам аудита Windows на языке PowerShell.
Два последних вида примечательны тем, что не требуют дополнительного ПО для анализа логов. Утилита grep и интерпретатор PowerShell поддерживаются «из коробки» в ОС Linux и Windows соответственно.
Существование единого формата описания детектов, основанных на логах, позволяет легче обмениваться знаниями, развивать open-source security и помогать сообществу по ИБ бороться с возникающими угрозами.
Общий синтаксис
Прежде всего стоит сказать, что есть обязательные и опциональные части правила. Это описано в официальной wiki на GitHub. Схема правила представлена ниже:
Практически любое правило можно условно разбить на три части:
- атрибуты, описывающие правило (метаинформация);
- атрибуты, описывающие источники данных;
- атрибуты, описывающие условия срабатывания правила.
Каждой из частей соответствуют обязательные высокоуровневые атрибуты title (помимо title, в последнюю группу входят остальные необязательные высокоуровневые атрибуты), logsource и detection.
Есть еще одна особенность строения правила, про которую стоит рассказать. Поскольку правила описываются на языке разметки YAML, разработчики Sigma нашли применение некоторым особенностям этого ело в том, что формат YAML позволяет разместить в одном файле несколько YAML-документов. А для Sigma — несколько правил объединить в одном файле, то есть создавать «коллекции правил» (rule collections). Такой подход удобен, когда есть несколько способов детектирования атаки и не хочется дублировать описательную часть (как будет описано в соответствующем разделе, дублировать можно не только описательную часть правила).
В таком случае правило условно разбивается на две части:
- часть с общими атрибутами для элементов коллекций (обычно все поля, кроме разделов logsource и detection),
- одна или несколько частей с описанием детекта (разделы logsource и detection).
Если файл содержит единственное правило, данное утверждение тоже истинно, поскольку мы получаем вырожденную коллекцию из одного правила. Коллекции правил будут подробно рассмотрены в третьей части цикла статей.
Далее мы рассмотрим пример гипотетического правила. Стоит отметить, что комментарии в таком виде в правилах обычно не используют, здесь они только для описания полей.
Описание типового правила
Пример создания Sigma-правила
Прежде чем описывать подробности синтаксиса и рассказывать про возможности Sigma-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая
You must be registered for see links
на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов).Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:
- проведение атаки и сбор необходимых логов,
- описание детекта в виде правила,
- проверка созданного правила.
Проведение атаки
Идея для правила хорошо описана в
You must be registered for see links
. После внимательного прочтения становится ясно, какие шаги нужно проделать, чтобы повторить описанный в статье результат:- Скопировать программу, которую вы хотите запустить, в любой каталог, доступный для записи. В статье предлагается выбрать %TEMP%, однако вы можете выбрать путь на свое усмотрение. Стоит учесть, что в данном каталоге создастся подкаталог с названием, которое вы укажете в п. 4.
- Назовите программу, которую вы хотите запустить, одним из имен, указанных в статье (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). В ходе анализа логов выяснилось, что в дополнение к этому списку можно использовать название findstr.exe. Называть файлы нужно именно так, поскольку SettingSyncHost.exe уязвим к атаке
You must be registered for see links(MITRE ATT&CK ID: T1574.008).
- Сделать выбранную директорию текущей рабочей директорией для всех процессов, которые вы будете далее запускать (в случае если вы запускаете settingsynchost.exe через cmd или PowerShell, достаточно просто выполнить команду cd ).
- Запустить команду: c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript
- Исполняемый файл был запущен легитимной программой SettingSyncHost.exe.
В системе установлен
You must be registered for see links
с файлом конфигурации из проекта
You must be registered for see links
. Таким образом сбор логов осуществился автоматически. Какие именно логи полезны для написания детекта, будет видно по ходу написания правила.Описание детекта в виде Sigma-правила
На этом шаге возможны два подхода: найти наиболее близкое по логике детектирования существующее правило и модифицировать его под свои нужды или написать правило с нуля. На начальных этапах рекомендуется придерживаться первого подхода. Мы же для наглядности будем писать правило, используя второй подход.
Создаем новый файл и стараемся кратко и емко описать его суть в названии. Тут следует придерживаться стиля существующих правил. В нашем случае мы выбрали название win_using_settingsynchost_to_run_hijacked_binary.yml. Далее начинаем заполнять его содержимым. Начнем с заполнения метаинформации в начале правила. Все данные, необходимые для этого, у нас уже есть.
Описываем кратко, какую атаку выявляет правило, в поле title, более подробные пояснения — в поле description, для новых правил принято ставить status: experimental. Уникальный идентификатор можно сгенерировать разными способами, в среде Windows проще всего запустить следующий код в интерпретаторе PowerShell:
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f
Остальные поля говорят сами за себя, отмечу лишь, что желательно указать ссылки на источники, которые помогли разобраться в атаке. Это поможет людям, которые будут в дальнейшем разбираться в этом правиле, а также это дань уважения тем усилиям, которые приложил автор оригинального исследования для описания атаки.
Наше правило на данном этапе имеет следующий вид:
Далее необходимо описать источники логов. Как уже было сказано выше, мы будем опираться на логи Sysmon, однако с появлением обобщенных категорий, для создания процессов принято использовать категорию process_creation. Про обобщенные категории подробнее будет рассказано ниже. Отметим, что в поле definition принято писать комментарии и советы по настройке источников, такие как особенности конфигурации Sysmon:
Теперь необходимо описать логику детектирования. Это наиболее трудоемкая часть. Данную атаку можно выявить по многим признакам, наш пример не претендует на полноту покрытия всех возможных путей выявления, поэтому опишем один из возможных вариантов.
Если посмотреть на события, которые произошли, можно выстроить следующую цепочку.
Сначала запустили процесс (PID: 4712) со строкой запуска c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript join_oscd
Отметим, что текущая рабочая директория процесса — пользовательский каталог 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 рассматривается в следующей части). Секция описывает сам источник, платформу и приложение, которые необходимы для детектирования. Тут могут содержаться три атрибута, которые обрабатываются конвертерами автоматически, и произвольное число необязательных элементов. Основные поля:
- Category — описывает классы продуктов. Примеры значений данного поля: firewall, web, antivirus. Также поле может содержать обобщенные категории, о которых будет рассказано ниже.
- Product — программный продукт или операционная система, которая создаёт логи.
- Service — ограничение логов на определенное подмножество сервисов, например «sshd» для Linux или «Security» для Windows.
- Definition — дополнительное поле для описания особенностей источника, например требования по настройке аудита (используется редко, пример правила с данным полем можно найти на
You must be registered for see links). Рекомендуется использовать этот атрибут, если у источника есть какие-либо особенности.
На официальной wiki на
You must be registered for see links
определен набор полей, которые необходимо использовать для того, чтобы правила были кросс-продуктовыми. Эти поля сведены в таблицу ниже.| 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 |
You must be registered for see links
| |
c-uri-extension |
You must be registered for see links
| ||
c-uri-query |
You must be registered for see links
| ||
c-uri-stem |
You must be registered for see links
| ||
c-useragent |
You must be registered for see links
| ||
cs-bytes | — | ||
cs-cookie |
You must be registered for see links
| ||
cs-host |
You must be registered for see links
| ||
cs-method |
You must be registered for see links
| ||
r-dns |
You must be registered for see links
| ||
cs-referrer | — | ||
cs-version | — | ||
sc-bytes | — | ||
sc-status |
You must be registered for see links
| ||
src_ip | — | ||
dst_ip | — |
Описание полей событий данного источника
---------------------------------------------------------------
c-uri - URI, запрошенный клиентом
c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла
c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу
c-uri-stem - Обычно это часть URL от хоста (или хост:порт) и до строки запроса. Чаще всего в URIstem содержится путь до ресурса относительно корневой директории веб-сервера
c-useragent - Заголовок UserAgent в HTTP-запросе клиента
cs-bytes - Количество байтов, отправленных от клиента к серверу
cs-cookie - Значения cookie, которые передает клиент на сервер
cs-host - Заголовок Host в HTTP-запросе клиента
cs-method - Метод HTTP-запроса клиента
r-dns - DNS-имя запрашиваемого сервера
cs-referrer - Заголовок Referrer в HTTP-запросе клиента
cs-version - Версия протокола HTTP, которую использует клиент
sc-bytes - Количество байтов, отправленных от сервера к клиенту
sc-status - Код HTTP-ответа
src_ip - IP-адрес клиента
dst_ip - IP-адрес сервера
Поля событий категории Firewall
| Category | Product/Service | Fields | Examples |
|---|---|---|---|
firewall | src_ip | — | |
src_port | — | ||
dst_ip | — | ||
dst_port |
You must be registered for see links
| ||
username | — |
Описание полей событий данного источника
---------------------------------------------------------------
src_ip - IP-адрес клиента
src_port - Порт, с которого происходит подключение
dst_ip - IP-адрес сервера
dst_port - Порт, на который происходит подключение
username - Имя пользователя, который осуществляет подключение
Поля событий категории Web server
| Category | Product/Service | Fields | Examples |
|---|---|---|---|
webserver | c-uri |
You must be registered for see links
| |
c-uri-extension | — | ||
c-uri-query | — | ||
c-uri-stem | — | ||
c-useragent | — | ||
cs-bytes | — | ||
cs-cookie | — | ||
cs-host | — | ||
cs-method |
You must be registered for see links
| ||
r-dns | — | ||
cs-referrer | — | ||
cs-version | — | ||
sc-bytes | — | ||
sc-status | — | ||
src_ip | — | ||
dst_ip | — |
Описание полей событий данного источника
---------------------------------------------------------------
c-uri - URI, запрошенный клиентом
c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла
c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу
c-uri-stem - Обычно это часть URI от хоста (или хост:порт) и до строки запроса. Чаще всего в URI stem содержится путь до ресурса относительно корневой директории веб-сервера
c-useragent - Заголовок UserAgent в HTTP-запросе клиента
cs-bytes - Количество байтов, отправленных от клиента к серверу
cs-cookie - Значения cookie, которые передает клиент на сервер
cs-host - Заголовок Host в HTTP-запросе клиента
cs-method - Метод HTTP-запроса клиента
r-dns - DNS-имя запрашиваемого сервера
cs-referrer - Заголовок Referrer в HTTP-запросе клиента
cs-version - Версия протокола HTTP, которую использует клиент
sc-bytes - Количество байтов, отправленных от сервера к клиенту
sc-status - Код HTTP-ответа
src_ip - IP-адрес клиента
dst_ip - IP-адрес сервера
Обобщенные категории
Поскольку Sigma — это обобщенный формат описания правил детектирования, основанных на логах, синтаксис таких правил должен уметь описать логику детектирования для разных систем. Некоторые системы используют таблицы с агрегированными данными вместо событий, а для описания одной и той же ситуации могут поступать данные из разных источников. Для унификации синтаксиса и решения подобных проблем был введен механизм обобщенных источников событий (generic logsources). На данный момент создана одна такая категория — process_creation. Подробнее об этом можно почитать в
You must be registered for see links
. Список полей данной категории можно найти на
You must be registered for see links
(на этой странице также описаны другие поддерживаемые категории).Поля событий обобщенной категории process_creation
| Category | Product | Fields | Examples |
|---|---|---|---|
process_creation | windows | UtcTime | - |
ProcessGuid | - | ||
ProcessId |
You must be registered for see links
| ||
Image |
You must be registered for see links
| ||
FileVersion |
You must be registered for see links
| ||
Description |
You must be registered for see links
| ||
Product |
You must be registered for see links
| ||
Company |
You must be registered for see links
| ||
CommandLine |
You must be registered for see links
| ||
CurrentDirectory |
You must be registered for see links
| ||
User |
You must be registered for see links
| ||
LogonGuid | - | ||
LogonId | - | ||
TerminalSessionId | - | ||
IntegrityLevel | - | ||
imphash |
You must be registered for see links
| ||
md5 | - | ||
sha256 | - | ||
ParentProcessGuid | - | ||
ParentProcessId | - | ||
ParentImage |
You must be registered for see links
| ||
ParentCommandLine |
You must be registered for see links
|
Описание полей событий данного источника
---------------------------------------------------------------
UtcTime -Время события в формате UTC
ProcessGuid - GUID созданного процесса
ProcessId - PID созданного процесса
Image - Путь к запущенному исполняемому файлу
FileVersion - Версия программы, взятая из ресурсов исполняемого файла
Description - Описание программы, взятое из ресурсов исполняемого файла
Product - Название программы, взятое из ресурсов исполняемого файла
Company - Название компании — разработчика программы, взятое из ресурсов исполняемого файла
CommandLine - Строка запуска создаваемого процесса
CurrentDirectory - Текущая директория созданного процесса
User - Пользователь, от имени которого запускается процесс
LogonGuid - GUID текущей пользовательской сессии
LogonId - Идентификатор текущей пользовательской сессии
TerminalSessionId - Идентификатор текущей терминальной сессии
IntegrityLevel - Уровень целостности, с которым запускается процесс
imphash - Хеш-сумма на основе данных из таблицы импорта исполняемого файла
md5 - MD5-хеш исполняемого файла, на основе которого создается процесс
sha256 - SHA256-хеш исполняемого файла, на основе которого создается процесс
ParentProcessGuid - GUID родительского процесса
ParentProcessId - PID родительского процесса
ParentImage - Путь к исполняемому файлу родительского процесса
ParentCommandLine - Строка запуска родительского процесс
Статистика использования источников событий в существующих правилах
Ниже в таблице приведены наиболее часто встречающиеся конструкции для описания источников логов. Скорее всего, вы найдете среди них ту, которая подходит для вашего правила.
Статистика по использованию комбинации полей описания некоторых наиболее распространенных источников (прочерк означает отсутствие данного поля):
| Кол-во правил | Category | Product | Service | Пример синтаксиса | Комментарий |
|---|---|---|---|---|---|
197 | process_creation | windows | — | logsource: category: process_creation product: windows | Обобщенная категория логов создания процессов на Windows-системах. Включает события Sysmon
You must be registered for see links
и события Windows Security Event Log
You must be registered for see links
|
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) |
Советы по написанию правил
При написании нового правила возможны такие ситуации:
- Нужный источник событий уже использовался в существующих правилах.
- В репозитории нет ни одного правила, которое использовало бы данный источник событий.
Если вы столкнулись с первым случаем, то используйте одно из существующих правил в качестве шаблона. Возможно, нужный источник логов уже используется в других правилах, тогда это значит, что авторы плагинов (бэкенд-конвертеры) под разные SIEM-системы, скорее всего, учли его в своем маппинге и ваше правило должно сразу корректно обрабатываться.
Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости.
Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:
Распределение источников логов
Статистика использования комбинаций подполей атрибута logsource
В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования.
Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
