Правила Sigma все больше и больше используются командами SOC, как способ написания одного правила, которое можно использовать в нескольких средах. Изучив, как работают правила Sigma и как их создавать, вы сможете поднять свои навыки SOC на новый уровень.
Обнаружение инцидентов внутри инфраструктуры в значительной степени основано на анализе и мониторинге событий с помощью log-файлов (журналов событий).
Существуют различные типы журналов, системы агрегации, стратегии и технологии, которые помогают SOC - аналитикам в их повседневной работе. Несмотря на то, что существует широкий спектр инструментов, которые SOC – команды и организации могут внедрить в свою систему безопасности, это также усложняет процесс обмена информацией и знаниями внутри организации и сообщества так как каждая SIEM имеет свой собственный синтаксис запроса (или язык), а каждый журнал имеет свои собственные уникальные поля.
Часто аналитики создают правила для обнаружения активных угроз или атак, и организации хотели бы использовать их для оповещения о возможном нарушении. Например, у нас может быть отличное правило для обнаружения создания определенного вредоносного процесса, и мы хотим поделиться этим правилом с сообществом, партнерами или клиентами.Отличным решением заключается использование правил Sigma. Эти правила написаны в четко определенном формате с использованием языка разметки.
Sigma используется для генерации запросов для конкретных систем и конфигураций.
Использование Sigma для написания правил обнаружения облегчает их совместное использование и интеграцию в организации, независимо от конкретных используемых инструментов и журналов.
Что такое правила Sigma?
Sigma-это фреймворк с открытым исходным кодом, который предоставляет возможность писать правила для анализа журналов – аналогично YARA для файлов или Snort для сетевого анализа.
Правила Sigma записываются с использованием предопределенного синтаксиса в формате YAML, а затем преобразуются (с помощью sigmac или онлайн-конвертера) в формат, соответствующий целевому SIEM или платформе, используемой в организации.
Существует множество поддерживаемых целей, таких как Splunk, Elasticsearch, Microsoft Defender и многие другие.
Sigma может использоваться с различными источниками журналов.
Гибкость правил Sigma и тот факт, что одно правило может использоваться в средах с различными конфигурациями, облегчают аналитикам написание этих правил и обмен ими с коллегами и сообществом.
Правила Sigma-это мощный инструмент, который позволяет легко анализировать различные типы журналов и находить конкретные действия или угрозы. Его можно использовать двумя способами:
Выявлять и предупреждать о подозрительной деятельности
Правила Sigma могут быть интегрированы в платформы SIEM и обнаруживать различные события по мере их возникновения, тем самым помогая обнаружить и остановить их до дальнейшего повреждения. Например, мы можем создать правила для обнаружения: несанкционированных действий, доступа к веб-ресурсам, модификации файлов, создания процессов и многого другого.
Охота на угрозы (threat hunting)
Правила Sigma можно использовать для поиска угроз:
- Использовать правила, чтобы определить, когда определенная атака или угроза нацелены на вашу организацию.
- Проверить, не была ли нарушена ваша организация, применив правила Sigma к старым журналам (при условии, что ваша организация агрегирует журналы не менее чем за несколько месяцев). Часто организации требуется несколько месяцев, прежде чем они обнаружат, что злоумышленник уже находится в системе. Анализируя журналы на предмет подозрительных действий, вы повышаете шансы обнаружить нарушение безопасности и начать процесс реагирования на инциденты раньше.
Синтаксис
Структура правил Sigma состоит из необязательной и обязательной частей, как видно на рисунке ниже.
Метаданные
Эти поля содержат информацию о правиле и добавляют информативные комментарии и примечания. Хотя это не обязательно, особенно важно добавить эту информацию, если вы планируете поделиться этим правилом с другими людьми. Здесь можно использовать несколько полей:
- Название правила
- Автор (необязательно)
- Дата (необязательно)
- Уникальный идентификатор (необязательно)
- Лицензия (необязательно) – рекомендуется добавить это поле, если вы планируете предоставить общий доступ к правилу. По умолчанию дистрибутив очень строгий, вы можете изменить его с помощью стандарта SPDX.
- Tag (необязательно) – например, свяжите правило с техникой из фреймворка MITRE ATT&CK.
- Status (необязательно) – возможные значения могут быть экспериментальными или тестовыми, указывающими на то, что правило может нуждаться в дальнейшей настройке и тестировании.
Источник журнала
В разделе источник журнала описывается, какие журналы следует искать и анализировать. Существует несколько необязательных полей, которые определяют, какой тип журналов релевантен для правила Sigma. Хотя эти поля являются необязательными, правило должно включать хотя бы одно из них, поскольку оно предоставляет жизненно важную информацию, относящуюся к обнаружению, и поможет пользователю правила интегрировать правило в свою инфраструктуру.
- Категория: укажите журналы из группы продуктов. Например: брандмауэр, process_creation, file_event.
- Продукт: конкретное программное обеспечение или услуга. Например: Windows, Apache, Zeek.
- Сервис: выберите подмножество из продукта.
- Определение: место для комментариев и дополнительной информации, касающейся журнала.
Обнаружение
В этом разделе мы определяем, что мы ищем в журналах. Этот раздел будет содержать один или несколько блоков, обычно называемых "выбор " или "фильтр", но он может иметь любое другое имя. Каждый блок будет содержать соответствующие поля и информацию, необходимые для обнаружения конкретного события. При поиске совпадения мы можем искать определенную строку, идентификатор события или их комбинацию, используя следующие поля и свойства. Давайте рассмотрим пример ниже:
Правило для обнаружения выполнения mshta, где родительский образ процесса заканчивается на ‘\svchost.exe-а изображение процесса заканчивается словами: \mshta.exe’:
Исходя из того, что мы узнали из предыдущего раздела, мы знаем, что это правило можно использовать для сканирования журналов создания процессов в ОС Windows.
Далее следует блок под названием "выбор", представляющий собой карту (или каталог), содержащую пары ключей и значений. В приведенном выше примере есть два ключа: ‘ParentImage’ и ‘Image’. Элементы карты связаны логически и по смыслу, мы ищем совпадение как для образа процесса, так и для образа его родителя.
Для родительского изображения строки находятся в формате списка – они связаны с OR, и нам нужно как минимум 1 совпадение в конце (из-за ‘endswith’) пути :’svchost.exe‘, ' cmd.exe-или ... powershell.exe. В Sigma строка:
- Регистр нечувствителен.
- При обнаружении можно использовать подстановочные знаки (* and?). При необходимости эти символы можно экранировать с помощью обратной косой черты.
Обратите внимание, что значение использует модификатор: ‘endswith’ – он указывает, где должна быть найдена строка; есть много других модификаторов, которые можно использовать. В примерах изображение процесса должно заканчиваться на ‘\mshta.exe.
Наконец, условие указывает, какие условия должны быть выполнены, чтобы идентифицировать событие и при необходимости вызвать оповещение. Когда правило состоит из нескольких разделов, они могут быть связаны различными логическими операциями, такими как and, or, not и многих других. Мы можем использовать условие для создания более подробных правил, фильтрации определенных совпадений и настройки правила, чтобы избежать ложных срабатываний. В нашем примере обнаружение произойдет, когда журнал будет содержать указанные пути к изображениям.
Составление правил Sigma
После того как мы напишем правило, нам нужно сохранить файл и использовать sigmac (доступный в репо) для компиляции правила. Команда будет выглядеть следующим образом:
Для компиляции правила необходимо указать целевую SIEM, предоставить конфигурационный файл и путь к правилу. Каждый аргумент очень важен для успешной компиляции правила и интеграции правила в SIEM - системы.
Цель
Цель-это SIEM или система, которая будет анализировать логи: это может быть splunk, stix, sysmon и т. Д. Каждая система имеет свой собственный синтаксис, поэтому выходные данные будут отличаться.
Мы продолжим использовать наш пример обнаружения mshta из предыдущего раздела, давайте скомпилируем его для splunk:
А теперь о sqlite:
Мы написали одно правило, которое можно легко интегрировать в две совершенно разные среды, и это сила правил Sigma.
Вы можете запустить sigmac –list, чтобы просмотреть полный список поддерживаемых целей.
Конфигурационный файл
Каждая среда и организация могут использовать разные источники журналов или индексировать их по-разному. Чтобы сделать правила Sigma релевантными и пригодными для использования в средах, независимо от используемых ими журналов, Sigma полагается на файлы конфигурации. Файл конфигурации содержит сопоставление журналов и полей, используемых в среде, с полями, используемыми в правилах.
Допустимое определение источника журнала должно содержать хотя бы одну категорию, спецификацию услуги или продукта, которая точно соответствует тем же полям в разделе logsource правила.
Репозиторий Sigma Git содержит множество конфигурационных файлов для различных источников журналов и SIEM-систем. Обратите внимание, что для того, чтобы использовать файл конфигурации в вашей среде, вам может потребоваться немного изменить его и настроить отображение, но для простой тестовой среды они тоже подойдут.
Например, это вывод нашего примера правила при использовании журналов windows-services для splunk:
Sysmon-это служба, входящая в состав sysinternals, она отслеживает и регистрирует широкий спектр событий и действий, выходные данные можно просмотреть в средстве просмотра журнала событий Windows. Это вывод примера правила для sysmon для splunk:
Давайте проверим конфигурацию для Sysmon. Ниже приведен фрагмент конфигурации:
Файл конфигурации определяет поля, которые будут использоваться в правиле Sigma, а также то, как они будут определены или где они будут расположены в журналах, создаваемых sysmon. Способ определения полей в правиле должен полностью соответствовать значениям, заданным в файле конфигурации.
Приведенная выше конфигурация сообщает sigmac, что для правил, содержащих logsource с категорией process_creation и окнами продукта, замените эти поля окнами продукта и sysmon службы. В зависимости от ОС, на которую нацелено правило, скомпилированные выходные данные будут определять тип продукта.
EventID: 1 добавляется с логическим and к запросу, выводимому sigmac, что означает, что только события с этим идентификатором события применимы к этому правилу. Таким образом, правила, которые не использовали sysmon в качестве источника журнала, могут быть интегрированы в инфраструктуру, использующую sysmon в своем протоколированиии, и использовать это правило.
Наше правило mshta для sysmon:
В исходном примере нашего правила mshta используется более “общий” подход: мы не указывали, какой источник журнала использовать, и пользователь может преобразовать правило в соответствии со своей средой, сопоставив поля в своем конфигурационном файле.
В первом примере пользователь должен настроить правило и настроить правило или файл конфигурации, а в последнем варианте мы специально указываем, какой источник журнала и поля используются правилами.
Оба правила приведут к одному и тому же результату.
Продолжение следует