Язык запросов KQL (Kusto Query Language) в Yandex SIEM используется на всех этапах работы анализатора SOC: от интерактивного поиска и проверки гипотез до создания правил корреляции и анализа алертов. Единая логика запросов сокращает время расследования и упрощает передачу результатов между сотрудниками.
**Почему разные инструменты замедляют расследование**
Типичное расследование редко состоит из одного запроса. Аналитик проверяет несколько гипотез, уточняет временные интервалы, сопоставляет данные из разных источников. Если при этом используются разные языки для поиска событий и правил корреляции, контекст может теряться. Промежуточные находки сложно сохранить для повторного использования, а передача материалов коллегам требует восстановления всех шагов. Yandex SIEM решает эти проблемы с помощью единого языка KQL, который поддерживает интерактивный поиск, обработку сохранённых датасетов, потоковые и ретроспективные правила.
**Как обрабатываются события**
В Yandex SIEM события поступают из облачной и гибридной инфраструктуры: аудитные логи Yandex Cloud, события Windows и Linux, сетевые данные. Поток сырых событий проходит фильтрацию и нормализацию, приводящую данные разных источников к единой схеме. Технические характеристики сервиса: входящий поток — 3 млн EPS, после нормализации — 2 млн EPS. Сырые события хранятся 5 лет, нормализованные — 90 дней на горячем хранении и до 5 лет на холодном. Среднее время поиска по одному часу данных составляет менее 20 секунд, по суткам — менее 60 секунд.
**Устройство запросов KQL**
Запрос начинается с источника данных, затем операторы последовательно связываются через пайп (|). Типовая цепочка: выбрать таблицу → отфильтровать записи → извлечь или преобразовать поля → сгруппировать данные → отсортировать → оставить нужные поля. Основные операторы: where (фильтрация), contains (поиск подстроки), extend (вычисляемые поля), summarize (агрегация), bin (группировка по временным интервалам), sort, limit, top, project, let (промежуточные таблицы), join (объединение), external_table (датасеты), case, coalesce, mv-expand (разворот массивов), parse_json (парсинг JSON). Например, сочетание summarize и bin позволяет выявить аномальные пики на гистограмме и быстро сузить диапазон поиска.
**Зачем сохранять результаты в датасеты**
Результат любого запроса можно сохранить как именованный датасет и обращаться к нему через external_table. Это позволяет аналитику не терять промежуточные находки, достраивать новые запросы на уже отобранных данных, избегать повторного запуска тяжелых запросов, прерывать длительное расследование и потом возвращаться к нему, а также передавать выборку другим участникам SOC.
**Сценарий № 1. Обнаружение закрепления через Cloud Functions**
Гипотеза проактивного поиска (threat hunting): злоумышленник может использовать Cloud Functions для закрепления в облаке. Для проверки создана тестовая функция на Python с SDK Yandex Cloud, которая при запуске создавала сервисный аккаунт, назначала ему роль администратора каталога и формировала статический ключ.
Аналитик с помощью KQL отбирает события, инициированные учётной записью Cloud Functions, и фильтрует только успешные операции. Затем ограничивает запрос критичными действиями управления доступом — изменениями привязок ролей на уровне каталога или облака. Первый запуск по ретроспективным данным за несколько недель не дал результатов. После имитации атаки запрос показал факт изменения прав, выполненного функцией.
Для превращения запроса в правило корреляции необходимо доработать его: через extend извлечь нужные поля из нормализованного события, использовать coalesce для выбора первого заполненного значения, применить mv-expand для разворачивания массива назначенных ролей, а через project сформировать итоговый набор полей (время, субъект, роль, ресурс, тип действия). Затем правило переносится в интерфейс Yandex SIEM, выбирается потоковый режим (критические события требуют быстрой реакции), шаблон карточки алерта заполняется с помощью Jinja. В правиле можно добавить исключения для легитимной активности, не меняя основную логику. После развёртывания повторная атака создаёт полноценный алерт с детальным описанием.
**Сценарий № 2. Расследование факта назначения публичного IP**
Исходное событие — виртуальной машине (ВМ) назначен публичный IP-адрес. Само по себе действие может быть легитимным, но может и свидетельствовать об ошибке конфигурации или атаке. Задача аналитика — установить, кто назначил адрес, было ли это санкционировано, и что происходило с машиной после.
Шаг 1: анализ сетевых соединений. Выбираются соединения, появившиеся после назначения IP. С помощью case адреса преобразуются так, чтобы в отдельных полях были адрес исследуемого инстанса и удалённый IP. Удалённый адрес обогащается геоданными через пользовательскую функцию. Через summarize рассчитывается количество сессий, средний объём данных, время первого и последнего соединения, с группировкой по адресу ВМ, направлению трафика и удалённому адресу. В выборке обнаруживается соединение всего 384 байта с адресом в Нидерландах через порт 31337 — возможный признак первоначального reverse shell.
Шаг 2: проверка DNS-запросов. В нормализованных DNS-событиях найдены обращения к Downloads Metasploit и GitHub User Content. Это усиливает подозрение на загрузку дополнительных инструментов.
Шаг 3: поиск инициатора через Audit Trails. По идентификатору ВМ находятся события её создания и назначения публичного адреса. Из них извлекается идентификатор субъекта и способ выполнения операции (в консоли Yandex Cloud).
Шаг 4: погружение в сырые события. Для более широкого поиска используется таблица сырых событий. Из JSON извлекаются время, тип события, идентификатор субъекта и User-Agent. Поиск по идентификатору учётной записи выдаёт около 80 событий, включая создание ВМ, назначение публичного адреса, а также другие операции с ресурсами и правами. Часть назначений ролей выполнена другим пользователем и с другим User-Agent — это повод расширить расследование. Полученная таблица сохраняется как датасет для дальнейшего использования.
Шаг 5: по совокупности признаков принимается решение о компрометации хоста. Рекомендуются изоляция, создание образа, возможный сбор дампа памяти и передача материалов следующей линии SOC или команде реагирования. Датасет с аудитными событиями сохраняется для продолжения анализа.
**Уменьшение количества лишних алертов**
Даже корректное правило может генерировать много срабатываний, если его сразу развернуть без проверки. Перед включением правила следует выполнить запрос по историческим данным и оценить количество возвращаемых событий, попавшую легитимную активность, селективность фильтров и достаточность полей для триажа. Для конкретных техник полезно провести локальные тесты в контролируемой среде. Агрегация по ключевым полям (пользователь, ресурс, IP) позволяет объединять похожие инциденты за временной интервал. Точечные исключения для тестового стенда или известных учётных записей также снижают шум, при этом исключённые срабатывания остаются доступны для анализа. Важно периодически проверять цепочку от нормализации до алерта, так как изменение схемы данных может повлиять на детектирование.
**ИИ для написания KQL-запросов**
KQL достаточно распространён, поэтому открытые языковые модели могут написать базовый запрос по текстовому описанию гипотезы. Полученный результат часто требует доработки, например, перестановки фильтров от более селективных к менее. В промпте стоит перечислить поддерживаемые в Yandex SIEM операторы и явно запретить неподдерживаемые. В любом случае сгенерированный запрос необходимо проверять на реальных данных и адаптировать под схему событий конкретной инфраструктуры.
**Заключение**
KQL связывает воедино этапы работы аналитика SOC: интерактивный поиск, threat hunting, обработку датасетов, создание и доработку правил корреляции, а также расследование алертов. Первый сценарий демонстрирует преобразование гипотезы в потоковое правило, второй — многошаговый анализ от простого алерта до выявления компрометации с сохранением промежуточных результатов. Единый язык не отменяет необходимости тестирования и адаптации, но позволяет переиспользовать логику и не начинать каждый этап с нуля.
**Хотите оценить Yandex SIEM для задач своего SOC?**
Сервис находится на стадии Preview, доступ предоставляется по запросу. Оставьте заявку и опишите задачи, которые планируете решать.
Источник: https://yandex.cloud/ru/blog/yandex-siem-kql-rules-incident-investigation
Комментарии(0)
Оставьте комментарий
Войдите, чтобы присоединиться к обсуждению