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

Alvaros
Онлайн

Alvaros

Ветеран
.
Регистрация
14.05.16
Сообщения
21.461
Реакции
102
Репутация
204
Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в детекты громких сетевых атак, поставляем правила анализа трафика в и пополняем набор . Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки.

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

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

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


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

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

  1. Небольшое введение, пример создания простого правила и описание источников событий (и эту статью вы читаете сейчас).
  2. Описание логики детектирования. Это наиболее важная часть синтаксиса, знание которой необходимо для понимания существующих правил и написания собственных.
  3. Описание метаинформации (атрибуты, которые имеют информативный или инфраструктурный характер, такие, например, как описание или идентификатор) и коллекций правил.

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


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

  • Elasticsearch Query,
  • строка запуска утилиты grep с нужными параметрами,
  • строка обращения к журналам аудита Windows на языке PowerShell.

Два последних вида примечательны тем, что не требуют дополнительного ПО для анализа логов. Утилита grep и интерпретатор PowerShell поддерживаются «из коробки» в ОС Linux и Windows соответственно.

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

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


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

b6uuvcs2r435gqqrmwc4x4jhrc0.png


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

  1. атрибуты, описывающие правило (метаинформация);
  2. атрибуты, описывающие источники данных;
  3. атрибуты, описывающие условия срабатывания правила.

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

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

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

  • часть с общими атрибутами для элементов коллекций (обычно все поля, кроме разделов logsource и detection),
  • одна или несколько частей с описанием детекта (разделы logsource и detection).

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

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

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


y11wvu884xkqajmmvtr9us-oydg.png

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


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

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

  1. проведение атаки и сбор необходимых логов,
  2. описание детекта в виде правила,
  3. проверка созданного правила.

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


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

  1. Скопировать программу, которую вы хотите запустить, в любой каталог, доступный для записи. В статье предлагается выбрать %TEMP%, однако вы можете выбрать путь на свое усмотрение. Стоит учесть, что в данном каталоге создастся подкаталог с названием, которое вы укажете в п. 4.
  2. Назовите программу, которую вы хотите запустить, одним из имен, указанных в статье (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). В ходе анализа логов выяснилось, что в дополнение к этому списку можно использовать название findstr.exe. Называть файлы нужно именно так, поскольку SettingSyncHost.exe уязвим к атаке (MITRE ATT&CK ID: T1574.008).
  3. Сделать выбранную директорию текущей рабочей директорией для всех процессов, которые вы будете далее запускать (в случае если вы запускаете settingsynchost.exe через cmd или PowerShell, достаточно просто выполнить команду cd ).
    • Запустить команду: c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript
    • Исполняемый файл был запущен легитимной программой SettingSyncHost.exe.

bxbe8ezk0yzrfhevlypfarly5x8.png


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

Описание детекта в виде 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

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

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

qlb-h2wv3r-lydkduus13c-skua.png


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

vnmnbpnoxdqbdguxwtpt4vzcthk.png


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

Если посмотреть на события, которые произошли, можно выстроить следующую цепочку.
Сначала запустили процесс (PID: 4712) со строкой запуска c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript join_oscd

adntagiqjgrf0n_ojxfk0c_dtvi.png


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

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

tlf0elx8pwyz062tsidqh8ogfhs.png


5ckyznlc8murayubjgxc7uomfue.png


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

ixi39_vjnjeawiq1mtirlxzltv8.png


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

_ju7hzqbmiptcz-fyoj07kmokxc.png


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


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

a0fcqpu5fkyxdl0rntmyhx9t5y0.png


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

ujgbk4caq3k8wwxz1siayds-op0.png


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

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

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


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

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


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

  • Category — описывает классы продуктов. Примеры значений данного поля: firewall, web, antivirus. Также поле может содержать обобщенные категории, о которых будет рассказано ниже.
  • Product — программный продукт или операционная система, которая создаёт логи.
  • Service — ограничение логов на определенное подмножество сервисов, например «sshd» для Linux или «Security» для Windows.
  • Definition — дополнительное поле для описания особенностей источника, например требования по настройке аудита (используется редко, пример правила с данным полем можно найти на ). Рекомендуется использовать этот атрибут, если у источника есть какие-либо особенности.


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

CategoryProductService

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


CategoryProduct/ServiceFieldsExamples

proxy

c-uri



c-uri-extension



c-uri-query



c-uri-stem



c-useragent



cs-bytes



cs-cookie



cs-host



cs-method



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 - Обычно это часть 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


CategoryProduct/ServiceFieldsExamples

firewall

src_ip



src_port



dst_ip



dst_port



username



Описание полей событий данного источника

---------------------------------------------------------------
src_ip - IP-адрес клиента
src_port - Порт, с которого происходит подключение
dst_ip - IP-адрес сервера
dst_port - Порт, на который происходит подключение
username - Имя пользователя, который осуществляет подключение


Поля событий категории Web server


CategoryProduct/ServiceFieldsExamples

webserver

c-uri



c-uri-extension



c-uri-query



c-uri-stem



c-useragent



cs-bytes



cs-cookie



cs-host



cs-method



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. Подробнее об этом можно почитать в . Список полей данной категории можно найти на (на этой странице также описаны другие поддерживаемые категории).

Поля событий обобщенной категории process_creation


CategoryProductFieldsExamples

process_creation

windows

UtcTime

-

ProcessGuid

-

ProcessId



Image



FileVersion



Description



Product



Company



CommandLine



CurrentDirectory



User



LogonGuid

-

LogonId

-

TerminalSessionId

-

IntegrityLevel

-

imphash



md5

-

sha256

-

ParentProcessGuid

-

ParentProcessId

-

ParentImage



ParentCommandLine



Описание полей событий данного источника

---------------------------------------------------------------
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 - Строка запуска родительского процесс


Статистика использования источников событий в существующих правилах


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

Статистика по использованию комбинации полей описания некоторых наиболее распространенных источников (прочерк означает отсутствие данного поля):
Кол-во правилCategoryProductServiceПример синтаксисаКомментарий

197

process_creation

windows



logsource:
category: process_creation
product: windows

Обобщенная категория логов создания процессов на Windows-системах. Включает события Sysmon

и события Windows Security Event Log


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)

Советы по написанию правил


При написании нового правила возможны такие ситуации:

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

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

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

Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:

Распределение источников логов


txsq8abx8lji-v70cqso1q6x6su.png


Статистика использования комбинаций подполей атрибута logsource


tjoviknbfjenrhvh4sngo6vqyuq.png


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

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