[Информационная безопасность] Все, что вы хотели знать о Sigma-правилах. Часть 1
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в Twitter детекты громких сетевых атак, поставляем правила анализа трафика в сервис ANY.RUN и пополняем набор правил ETOpen. Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки.
И тут мы узнали, что группа энтузиастов решила устроить двухнедельный спринт по написанию правил для проекта Sigma, который создан ради выработки единого формата описания правил для SIEM-систем и поддерживается 110 участниками. Новость о событии нас заинтересовала, поскольку как вендор SIEM мы внимательно следим за развитием комьюнити.
Каково же было наше удивление, когда с нами связались организаторы и предложили команде PT Expert Security Center поучаствовать в спринте! Участники мероприятия образовали Open Security Collaborative Development (OSCD) — международную инициативу специалистов по ИБ, направленную на распространение знаний и улучшение компьютерной безопасности в целом. Мы с радостью согласились принять участие, чтобы применить свой опыт во благо общей безопасности.
Как появилась эта статья
Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний — GitHub и личный опыт. Есть несколько хороших статей (на русском и на английском), но в них фокус смещен с синтаксиса правил на анализ области применимости 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-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая статья на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов).
Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:
- проведение атаки и сбор необходимых логов,
- описание детекта в виде правила,
- проверка созданного правила.
Проведение атаки
Идея для правила хорошо описана в блоге Hexacorn. После внимательного прочтения становится ясно, какие шаги нужно проделать, чтобы повторить описанный в статье результат:
- Скопировать программу, которую вы хотите запустить, в любой каталог, доступный для записи. В статье предлагается выбрать %TEMP%, однако вы можете выбрать путь на свое усмотрение. Стоит учесть, что в данном каталоге создастся подкаталог с названием, которое вы укажете в п. 4.
- Назовите программу, которую вы хотите запустить, одним из имен, указанных в статье (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). В ходе анализа логов выяснилось, что в дополнение к этому списку можно использовать название findstr.exe. Называть файлы нужно именно так, поскольку SettingSyncHost.exe уязвим к атаке Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
- Сделать выбранную директорию текущей рабочей директорией для всех процессов, которые вы будете далее запускать (в случае если вы запускаете settingsynchost.exe через cmd или PowerShell, достаточно просто выполнить команду cd <выбранный путь>).
- Запустить команду: c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <любое_название_для_подпапки>
- Исполняемый файл был запущен легитимной программой SettingSyncHost.exe.
В системе установлен Sysmon с файлом конфигурации из проекта sysmon-modular. Таким образом сбор логов осуществился автоматически. Какие именно логи полезны для написания детекта, будет видно по ходу написания правила.
Описание детекта в виде 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 — дополнительное поле для описания особенностей источника, например требования по настройке аудита (используется редко, пример правила с данным полем можно найти на GitHub). Рекомендуется использовать этот атрибут, если у источника есть какие-либо особенности.
На официальной 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
—
Описание полей событий данного источника:
---------------------------------------------------------------
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
net_high_dns_bytes_out.yml
username
—
Описание полей событий данного источника:
---------------------------------------------------------------
src_ip - IP-адрес клиента
src_port - Порт, с которого происходит подключение
dst_ip - IP-адрес сервера
dst_port - Порт, на который происходит подключение
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
—
Описание полей событий данного источника:
---------------------------------------------------------------
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. Подробнее об этом можно почитать в блоге patzke.org. Список полей данной категории можно найти на странице с таксономией (на этой странице также описаны другие поддерживаемые категории).
Поля событий обобщенной категории 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
Описание полей событий данного источника:
---------------------------------------------------------------
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
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)
Советы по написанию правил
При написании нового правила возможны такие ситуации:
- Нужный источник событий уже использовался в существующих правилах.
- В репозитории нет ни одного правила, которое использовало бы данный источник событий.
Если вы столкнулись с первым случаем, то используйте одно из существующих правил в качестве шаблона. Возможно, нужный источник логов уже используется в других правилах, тогда это значит, что авторы плагинов (бэкенд-конвертеры) под разные SIEM-системы, скорее всего, учли его в своем маппинге и ваше правило должно сразу корректно обрабатываться.
Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости.
Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:
Распределение источников логов
Статистика использования комбинаций подполей атрибута logsource
В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования.
Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
===========
Источник:
habr.com
===========
Похожие новости:
- [Алгоритмы, Информационная безопасность, Криптография, Математика] AES — АМЕРИКАНСКИЙ СТАНДАРТ ШИФРОВАНИЯ. ЧАСТЬ III
- [Информационная безопасность, Исследования и прогнозы в IT, Статистика в IT] Подборка интересных инцидентов в области ИБ за июнь 2020
- [Видеоконференцсвязь, Информационная безопасность] Эксперты обнаружили уязвимость нулевого дня в клиенте Zoom для старых версий Windows
- [Информационная безопасность] Что такое threat hunting, и как правильно охотиться на киберпреступников
- [Информационная безопасность] Медуза: власти выложили в открытый доступ персональные данные всех интернет-избирателей (на самом деле нет)
- [Администрирование баз данных, Информационная безопасность, Облачные сервисы, Урбанизм] В даркнете продают доступ к московским камерам наблюдения
- [Информационная безопасность, Контекстная реклама] Возможные утечки персональных данных или как Дом.ru даёт полный доступ к личному кабинету по ссылке из http
- [Информационная безопасность, Законодательство в IT] Установлена личность хакера Fxmsp, укравшего информацию из 135 компаний — это 37-летний житель Казахстана
- [IT-компании, Информационная безопасность] Mozilla временно отключила сервис отправки файлов Firefox Send: через него передавали зловреды
- [Информационная безопасность, Социальные сети и сообщества] TikTok могут заблокировать в США и Австралии из-за угрозы национальной безопасности
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_elasticsearch_query, #_sigmapravila (Sigma-правила), #_blog_kompanii_positive_technologies (
Блог компании Positive Technologies
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:32
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в Twitter детекты громких сетевых атак, поставляем правила анализа трафика в сервис ANY.RUN и пополняем набор правил ETOpen. Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки. И тут мы узнали, что группа энтузиастов решила устроить двухнедельный спринт по написанию правил для проекта Sigma, который создан ради выработки единого формата описания правил для SIEM-систем и поддерживается 110 участниками. Новость о событии нас заинтересовала, поскольку как вендор SIEM мы внимательно следим за развитием комьюнити. Каково же было наше удивление, когда с нами связались организаторы и предложили команде PT Expert Security Center поучаствовать в спринте! Участники мероприятия образовали Open Security Collaborative Development (OSCD) — международную инициативу специалистов по ИБ, направленную на распространение знаний и улучшение компьютерной безопасности в целом. Мы с радостью согласились принять участие, чтобы применить свой опыт во благо общей безопасности. Как появилась эта статья Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний — GitHub и личный опыт. Есть несколько хороших статей (на русском и на английском), но в них фокус смещен с синтаксиса правил на анализ области применимости Sigma-правил или создание конкретного правила. Мы решили облегчить новичкам знакомство с проектом Sigma, поделиться собственным опытом, собрать в одном месте информацию о синтаксисе и особенностях его применения. Ну и конечно, мы надеемся, что это поспособствует расширению инициативы OSCD и позволит в будущем образовать крупное сообщество. Поскольку материала получилось очень много, мы решили выпустить описание в цикле из трех статей:
Что такое формат 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-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая статья на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов). Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:
Проведение атаки Идея для правила хорошо описана в блоге Hexacorn. После внимательного прочтения становится ясно, какие шаги нужно проделать, чтобы повторить описанный в статье результат:
 В системе установлен Sysmon с файлом конфигурации из проекта sysmon-modular. Таким образом сбор логов осуществился автоматически. Какие именно логи полезны для написания детекта, будет видно по ходу написания правила. Описание детекта в виде 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 на 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 — Описание полей событий данного источника: --------------------------------------------------------------- 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 net_high_dns_bytes_out.yml username — Описание полей событий данного источника: --------------------------------------------------------------- src_ip - IP-адрес клиента src_port - Порт, с которого происходит подключение dst_ip - IP-адрес сервера dst_port - Порт, на который происходит подключение 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 — Описание полей событий данного источника: --------------------------------------------------------------- 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. Подробнее об этом можно почитать в блоге patzke.org. Список полей данной категории можно найти на странице с таксономией (на этой странице также описаны другие поддерживаемые категории). Поля событий обобщенной категории 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 Описание полей событий данного источника: --------------------------------------------------------------- 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 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) Советы по написанию правил При написании нового правила возможны такие ситуации:
Если вы столкнулись с первым случаем, то используйте одно из существующих правил в качестве шаблона. Возможно, нужный источник логов уже используется в других правилах, тогда это значит, что авторы плагинов (бэкенд-конвертеры) под разные SIEM-системы, скорее всего, учли его в своем маппинге и ваше правило должно сразу корректно обрабатываться. Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости. Мы создали визуализацию сочетания полей описания источников логов в существующих правилах: Распределение источников логов  Статистика использования комбинаций подполей атрибута logsource  В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования. Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center) =========== Источник: habr.com =========== Похожие новости:
Блог компании Positive Technologies ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:32
Часовой пояс: UTC + 5