В этой статье подробно рассмотрю амбициозный проект , девиз которого: «Sigma для логов — это как Snort для трафика и Yara для файлов».
Речь пойдет про три аспекта:
- Применимость синтаксиса Sigma-правил для ведения базы знаний сценариев выявления угроз
- Возможности инструментария по генерации правил для коробочных SIEM-систем
- Ценность для SOC текущего наполнения публичных репозиториев Sigma-правил
Началось все несколько лет назад, когда деревья были большими, а команда нашего мониторинга — еще маленькой. Мы столкнулись с большим количеством вопросов, через это проходит практически любая команда, перерастающая рубеж в три человека.
Причины появления вопросов различны:
- Рост команды
- Текучка кадров
- Большое количество разнородных систем на мониторинге
Библиотека Use Case
Мировой опыт построения центров мониторинга уже придумал решение для упорядочивания хаоса и имя ему — библиотека юз кейсов. Цель каждого кейса — всесторонне описать решение некоторой задачи в рамках мониторинга информационной безопасности.
Состав знаний, закладываемый в каждый кейс, может разниться, мы отталкиваемся от следующего набора:
- Objective – задача, решаемая кейсом
- Threat – угроза, на обнаружение которой направлено действие правила выявления
- Stakeholders – люди, заинтересованные в работе этого правила: ИБ/IT/Бизнес
- Data Requirements – набор данных, требуемый для выявления угрозы
- Logic – логика правила выявления угрозы
- Testing – алгоритм для тестирования корректности работы правила выявления
- Priority – приоритет обработки события по кейсу (как правило, вычисляется из потенциального ущерба от успешно реализованной угрозы)
- Output – Перечень действий по разбору алерта, описание корректных выходов из процедуры разбора и состав данных, фиксируемых в результатах разбора
Пример значительно упрощен, в реальности кейс при должном описании разрастается на многостраничный документ.В тот момент, когда количество кейсов перевалило за несколько десятков, мы начали искать готовые средства для ведения подобной базы знаний, желательно имеющие, помимо human friendly, еще и какой-то machine friendly интерфейс для работы.
Проект Sigma
Проект Sigma безусловно заслуживает рассмотрения в разрезе базы знаний по правилам выявления инцидентов. Стартовал он в 2016 году, и я за ним слежу практически с самого основания.
Фактически проект состоит из
- Самих Sigma-правил
- Утилит по преобразованию правил в запросы для различных SIEM-систем
Синтаксис правил
Sigma-правила представляют из себя YAML-документы, описывающие сценарий выявления определенной атаки. Синтаксически правила состоят из следующих блоков:
Метаинформация
Описательная часть для структуризации и упрощения поиска нужных правил.
Отдельно хочется отметить, что многие правила уже снабжаются ссылками на технику атаки по методологии MITRE ATT&CK.
Декларация источника данных
Описание источника, на базе событий которого реализована логика обнаружения.
Синтаксически возможно описать как конечный сервис определенного продукта, так и целую категорию систем.
Декларация логики обработки
На уровне логики обнаружения описываются:
- Искомые паттерны
- Значения определенных полей в логе
- Временные рамки
- Агрегатные функции
так и достаточно сложной:
Выразительные средства языка хоть и не универсальны, но все же достаточно широкие и позволяют описать большое количество кейсов по выявлению атак.
Средства разработки правил
Помимо вашего любимого текстового редактора для YAML доступен еще WEB UI от компании SOC Prime, позволяющий как валидировать синтаксис уже написанного правила, так и создавать правила вручную из графических блоков.
Sigma как средство ведения базы знаний
Подведем краткое резюме.
На текущий момент синтаксис правил в основном концентрируется на описании логики обнаружения угрозы и не предназначен для всестороннего описания use case, соответственно вести полноценную библиотеку только с помощью Sigma Rules не получится.
Для той структуры use case, которую мы выбрали, Sigma закрывает только половину (Objective, Data requirements, Logic и Priority).
Конвертация в различные SIEM
Поскольку мы являемся сервис-провайдером услуг SOC, для нас очень заманчивой выглядела идея держать все наши наработки по правилам корреляции в некотором универсальном формате и на этапе внедрения преобразовывать в формат нужного SIEM.
В состав проекта входят консольные утилиты для генерации запросов к событиям в формате различных SIEM. Рассмотрим, что представляет собой конвертация и что у нее под капотом.
Преобразование происходит в 3 этапа:
- Парсинг правил — думаю, с этим все понятно: YAML-документ разбирается на составляющие блоки
- Приведение к таксономии SIEM
Необходимость данного этапа связана с тем, что нормализация в SIEM-системах реализована немного по-разному, соответственно декларации из Sigma-правил нужно привести к таксономии событий выбранного SIEM - Генерация запроса для SIEM
Для работы данного этапа требуется еще один компонент — backend для этой SIEM.
Фактически backend — это плагин для утилиты конвертации, в который заложена логика преобразования в конечный формат запроса в SIEM. Преобразуются блоки detection и logsource c учетом ранее наложенного маппинга полей, добавляется дополнительная SIEM-специфичная информация.
В итоге запуск утилиты преобразование выглядит следующим образом:
В качестве параметров передаются:
- Целевая SIEM
- Правило
- Файл с маппингами для данной SIEM
Подводные камни конвертации
- Изучив механику конвертации, мы столкнулись с существенными ограничениями, что удержало нас от перевода всех наработок в формат Sigma:
- Конвертер оперирует только запросом. Правило корреляции в SIEM затрагивает больше аспектов: временное окно, агрегация, действия по результатам выявленных алертов
- Не учитываются ключевые особенности отдельных SIEM, например, ActiveList’ы
- Недостаточная детализация маппинга полей — в рамках конфигурации маппинга описаны поля всего нескольких источников, соответственно, имея в базе правила для нескольких десятков различных типов источников событий, придется сильно вкладываться в написание маппингов.
Посмотрим, что несет в себе публично доступная база правил Sigma. На текущий момент контент активно добавляется в два репозитория:
- Основной репозиторий проекта
- Threat Detection Marketplace от компании SOC Prime
Правила в составе репозиториев имеют ненулевое пересечение.
У SOC Prime ряд правил распространяется в платной подписке, их контент в этой статье не рассматриваю.
Для аналитики нам потребуется библиотека для Python и немного скиллов программирования.
Для парсинга и загрузки правил из каталога в словарь можно воспользоваться таким кодом:
Дедуплицируя одинаковые правила, выходит следующая картина:
В рамках уникального перечня правил получаем следующие распределения:
По типу источника событий:
Немного укрупняя статистику
- Windows ~80 %
- Sysmon ~53 %
- Proxy ~8 %
- Linux ~ 4 %
По степени готовности контента:
Выходит, что разработчики Sigma-правил пометили как стабильные менее 20% всех существующих правил.
Подведем итоги
В публично доступных источниках присутствует большое количество правил. Они регулярно обновляются, и оперативно появляются правила обнаружения индикаторов, а иногда даже и техник по наиболее громким APT-компаниям.
Для применения правил в реальной жизни есть большое количество ограничений:
- Очень много правил для Microsoft Sysmon, который достаточно редко используется в энтерпрайзе.
- Много правил, которые фактически осуществляют проверку по IoC (хэши, IP-адреса, URL, User Agent). Такие правила быстро устаревают, и для поиска IoC есть механизмы более эффективные, чем правила.
- Много экспериментального контента, соответственно накладываются дополнительные требования на качественное тестирование перед введением в эксплуатацию.
Мы в «Инфосекьюрити» используем контент Sigma-правил как дополнительный источник знаний для более эффективного выявления инцидентов. Если находим что-то интересное – реализуем уже в рамках наших правил корреляции, которые учитывают и ядро, на котором работают правила (Apache Spark), и специфику инфраструктур и используемых нами средств защиты.
