Перейти к основному содержимому
Версия: 4.5.X

Плагин sigma

Введение​

Плагин sigma входит в состав YAML плагинов processors и позволяет проводить предварительную фильтрацию на коллекторах, используя правила Sigma.

Немного о правилах Sigma: это open-source формат правил для SIEM, конвертируемый в различные представления (elasticsearch, splunk и т.д.). Преимуществами этих правил является богатый набор открытых правил и активное сообщество, покрывающее правилами появляющиеся уязвимости. Поэтому данный плагин удобен для своевременного реагирования на тенденции в сфере ИБ, поскольку новые правила достаточно загрузить в плагин, после чего новая уязвимость сразу отслеживается нашей SIEM.

Конфигурация​

Не считая поля module, обыкновенного для плагинов processors и позволяющего определить тип плагина, в конфигурацию плагина sigma входит 3 поля:

  1. rules - массив правил Sigma. Структура каждого правила полностью соответствует указанному в документации и спецификации
  2. case-sensitive - по умолчанию плагин sigma игнорирует регистр в тексте события и его полей. Данное поле позволяет управлять этим поведением, определяя, чувствителен ли плагин к регистру (case-sensitive: true) или нет (case-sensitive: false).
  3. 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) может производить фильтрацию тремя различными способами:

  1. По ключевым словам - идет проверка вхождения заданных ключевых слов в исходный текст события. Если говорить в контексте YAML, то для применения этого способа в блоках selection необходимо указать ключевые слова в виде списка, например:

    detection:
      my_keywords:
        - первое слово
        - второе слово
        - третье слово
      condition: my_keywords

  2. По полю - идет проверка соответствия поля заданному значению. Для применения этого способа необходимо реализовать selection как словарь, а для конкретного поля запись словаря должна иметь тип "строка-строка". Например:

    detection:
      field_selection:
        field: value
        second_field: second_value
    condition: field_selection

  3. Множественная проверка по полю - идет проверка соответствия поля одному из заданных значений. Для применения этого способа необходимо реализовать 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 не будет.

Последнее обновление