Плагин sigma
Введение
Плагин sigma
входит в состав YAML плагинов processors
и позволяет проводить предварительную фильтрацию на коллекторах, используя правила Sigma.
Немного о правилах Sigma: это open-source формат правил для SIEM, конвертируемый в различные представления (elasticsearch, splunk и т.д.). Преимуществами этих правил является богатый набор открытых правил и активное сообщество, покрывающее правилами появляющиеся уязвимости. Поэтому данный плагин удобен для своевременного реагирования на тенденции в сфере ИБ, поскольку новые правила достаточно загрузить в плагин, после чего новая уязвимость сразу отслеживается нашей SIEM.
Конфигурация
Не считая поля module
, обыкновенного для плагинов processors
и позволяющего определить тип плагина, в конфигурацию плагина sigma
входит 3 поля:
rules
- массив правил Sigma. Структура каждого правила полностью соответствует указанному в документации и спецификацииcase-sensitive
- по умолчанию плагинsigma
игнорирует регистр в тексте события и его полей. Данное поле позволяет управлять этим поведением, определяя, чувствителен ли плагин к регистру (case-sensitive: true
) или нет (case-sensitive: false
).deny
- отклонять событие, если оно не соответствует ни одному из правил. По умолчанию события не отклоняются.
Пример конфигурации:
processors:
- module: sigma
case-sensitive: false
deny: true
rules:
# Источник - https://github.com/SigmaHQ/sigma/blob/master/rules/linux/builtin/lnx_buffer_overflows.yml
- title: Buffer Overflow Attempts
id: 18b042f0-2ecd-4b6e-9f8d-aa7a7e7de781
status: stable
description: Detects buffer overflow attempts in Unix system log files
references:
- https://github.com/ossec/ossec-hids/blob/1ecffb1b884607cb12e619f9ab3c04f530801083/etc/rules/attack_rules.xml
author: Florian Roth (Nextron Systems)
date: 2017/03/01
tags:
- attack.t1068
- attack.privilege_escalation
logsource:
product: linux
detection:
keywords:
- 'attempt to execute code on stack by'
- 'FTP LOGIN FROM .* 0bin0sh'
- 'rpc.statd[\d+]: gethostbyname error for'
- 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
condition: keywords
falsepositives:
- Unknown
level: high
В данном примере используется правило, детектирующее попытку переполнения буфера в Linux. Более подробно о том, как плагин обрабатывает блок detection
будет рассказано далее. Если событие не будет соответствовать правилу (причем, независимо от регистра, т.к. case-sensitive
равен false
), то оно не будет отправлено на дальнейшую обработку, поскольку оно будет отклонено - deny
равен true
.
Обработка события с помощью блока detection правила
Согласно документации, каждая группа (т.н. selection
) может производить фильтрацию тремя различными способами:
-
По ключевым словам - идет проверка вхождения заданных ключевых слов в исходный текст события. Если говорить в контексте YAML, то для применения этого способа в блоках
selection
необходимо указать ключевые слова в виде списка, например:detection:
my_keywords:
- первое слово
- второе слово
- третье слово
condition: my_keywords -
По полю - идет проверка соответствия поля заданному значению. Для применения этого способа необходимо реализовать
selection
как словарь, а для конкретного поля запись словаря должна иметь тип "строка-строка". Например:detection:
field_selection:
field: value
second_field: second_value
condition: field_selection -
Множественная проверка по полю - идет проверка соответствия поля одному из заданных значений. Для применения этого способа необходимо реализовать
selection
как словарь, а для конкретного поля запись словаря должна иметь тип "строка-список строк". Например:detection:
field_list_selection:
field:
- first_value
- second_value
- third_value
condition: field_list_selection
Реализация плагина Sigma в KOMRAD интерпретирует эти способы фильтрации следующим образом:
- Способ фильтрации по ключевым словам представляет собой поиск любого из ключевых слов в исходном тексте события, т.е в поле
Raw
. - Способ фильтрации по полю представляет собой соответствие значения поля (нормализованного, например
field
превратится вField
) заданному. - Способ множественной фильтрации по полю представляет собой соответствие значения поля (также нормализованного) любому из заданных.
Результатом применения каждого блока selection
является логическое значение - подходит событие под этот блок или нет. Чтобы на основе результатов блоков сделать вывод о том, подходит событие под все правило или нет, необходимо использовать поле condition
. Более подробно о нем можно прочитать в документации. Если описать его вкратце: можно задать возможные комбинации результатов блоков (с помощью И, ИЛИ и НЕ).
Также полезной фишкой в правилах Sigma являются модификаторы, позволяющие как-либо обработать анализируемый текст, либо поменять семантику правил. Например, с их помощью можно использовать регулярные выражения, анализировать текст в base64 и многое другое. Плагин Sigma поддерживает модификаторы startswith
, endswith
, re
, contains
и all
.
Результат применения плагина к событию
После того, как плагин полностью обработал событие, если событие соответствует хотя бы одному правилу, то в это событие будет добавлено новое поле - Sigma.MatchedRules
. Это поле будет содержать массив имен правил, под которые подходит событие. Поле можно использовать для дальнейшей фильтрации и корреляции.
Если ни одно правило не подошло под событие, и параметр deny
имеет значение true
, то событие будет отклонено и не будет проходить дальнейшую обработку.
Примеры использования плагина
Анализ логов аудита организации в GitHub
В репозитории правил Sigma есть правило для анализа логов аудита GitHub на предмет удаления сущностей (окружений, репозиториев, проектов и т.д.). Попробуем адаптировать это правило под KOMRAD и плагин Sigma в частности. Для этого я создал свою организацию на GitHub, затем создал и удалил репозиторий в ней. После (с помощью этой статьи) я экспортировал логи аудита в формате JSON. Там много записей, но нас интересует одна конкретная:
{"@timestamp":1715693058818,"_document_id":"ouNIxhZhxGrFPavsK0IMzA","action":"repo.destroy","actor":"KSpaceer","actor_id":101411067,"actor_is_bot":false,"actor_location":{"country_code":"RU"},"created_at":1715693058818,"operation_type":"remove","org":"KSpaceerTestOrganization","org_id":169812859,"public_repo":false,"repo":"KSpaceerTestOrganization/KSpaceerTestRepoToDelete","repo_id":800510383,"request_category":"other","user_agent":"Mozilla/5.0 (X11 Ubuntu Linux x86_64 rv:125.0) Gecko/20100101 Firefox/125.0","visibility":"private"}
Это событие можно распарсить с помощью, например, плагина json. Попробуем объединить два плагина в блоке processors
:
processors:
- module: json
patterns:
- expr: "@timestamp"
to: ECS.Event.Start
- expr: "action"
to: Action
- expr: Actor
to: Actor
- expr: repo
to: Repository
- module: sigma
rules:
- title: Github Delete Action Invoked
id: 16a71777-0b2e-4db7-9888-9d59cb75200b
status: test
description: Detects delete action in the Github audit logs for codespaces, environment, project and repo.
author: Muhammad Faisal (@faisalusuf)
date: 2023/01/19
references:
- https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/ reviewing-the-audit-log-for-your-organization#audit-log-actions
tags:
- attack.impact
- attack.collection
- attack.t1213.003
logsource:
product: github
service: audit
definition: 'Requirements: The audit log streaming feature must be enabled to be able to receive such logs. You can enable following the documentation here: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-audit-log-streaming'
detection:
selection:
action:
- 'codespaces.delete'
- 'environment.delete'
- 'project.delete'
- 'repo.destroy'
condition: selection
falsepositives:
- Validate the deletion activity is permitted. The "actor" field need to be validated.
level: medium
- module: rename
rules:
- 'Action:ECS.Event.Action'
В конце был добавлен плагин Rename, чтобы привести поле Action в соответствие со схемой ECS. Можно было не добавлять этот плагин, а просто поменять в правиле Sigma поле Action на ECS.Event.Action.
Можете попробовать применить этот плагин на коллекторе с приведенным выше событием. В результате должно добавиться еще одно поле Sigma.MatchedRules
с единственным элементом Github Delete Action Invoked
.
Поиск подозрительных запросов SQL
Используем правило, помогающее обнаружить подозрительные запросы SQL. Для проверки этого правила я использую Clickhouse, а более конкретно - запись из лога /var/log/clickhouse-server/clickhouse-server.log
:
2024.05.14 13:44:12.695795 [ 1371 ] {173428c2-1a4e-4e2b-8c89-6c5574951251} <Debug> executeQuery: (from 172.18.0.1:52248, user: komrad) DROP TABLE test_table (stage: Complete)
Поскольку правило работает на основе способа Keywords, плагин Sigma можно использовать сам по себе без предварительного парсинга события:
processors:
- module: sigma
rules:
- title: Suspicious SQL Query
id: d84c0ded-edd7-4123-80ed-348bb3ccc4d5
status: test
description: Detects suspicious SQL query keywrods that are often used during recon, exfiltration or destructive activities. Such as dropping tables and selecting wildcard fields
author: '@juju4'
date: 2022/12/27
references:
- https://github.com/sqlmapproject/sqlmap
tags:
- attack.exfiltration
- attack.initial_access
- attack.privilege_escalation
- attack.t1190
- attack.t1505.001
logsource:
category: database
definition: 'Requirements: Must be able to log the SQL queries'
detection:
keywords:
- 'drop'
- 'truncate'
- 'dump'
- 'select \*'
condition: keywords
falsepositives:
- Inventory and monitoring activity
- Vulnerability scanners
- Legitimate applications
level: medium
Поскольку по умолчанию плагин Sigma регистронезависимый, то наш лог подойдет под правило (DROP TABLE
соотносится с ключевым словом drop
), и в поле Sigma.MatchedRules
будет элемент Suspicious SQL Query
. Если сделать плагин регистрозависимым (case-sensitive: true
), то событие не подойдет под правило, и поля Sigma.MatchedRules
не будет.