Основы KQL для аналитика SOC

Kusto Query Language (KQL) — основа поиска угроз и триажа алертов в Microsoft Sentinel и Microsoft Defender. Если вы работаете в SOC, владение KQL отделяет аналитиков, которые быстро могут ответить на вопрос «что произошло?» от тех, кто застрял в кликании по дашбордам. Это не полный справочник языка — это практическое подмножество, которое постоянно используется в смену.

Почему KQL важен в SOC

KQL — это язык только для чтения, оптимизированный для быстрого запроса больших наборов логов. Sentinel, Defender for Endpoint, Azure Monitor и Log Analytics все используют его. Когда вы его знаете, вы можете переходить между продуктами с одной и той же логикой: выберите таблицу, отфильтруйте её, оформите вывод. Каждое расследование — триаж фишинга, поиск латерального движения, настройка ложных срабатываний — начинается с запроса.

Pipe — это всё

Запросы KQL построены как конвейер. Вы начинаете с таблицы и пропускаете данные через серию операторов, каждый из которых фильтрует, трансформирует или суммирует предыдущий результат:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Читайте это сверху вниз как предложение: начните с логов SecurityEvent, оставьте только неудачные входы (4625), ограничьте последним днём, подсчитайте ошибки на аккаунт/компьютер, затем отсортируйте. Эта линейная читаемость — самое большое преимущество KQL перед SQL для ad hoc поиска.

Основные операторы для запоминания

• where — ваш основной фильтр. Используйте его рано и часто, чтобы снизить объём данных перед дорогостоящими операциями.
• project — выберите и переименуйте конкретные столбцы, отбросив шум, который вам не нужен в выводе.
• extend — добавьте вычисляемые столбцы без удаления существующих, полезно для разбора строк или флагирования условий.
• summarize — агрегируйте данные с count(), sum(), dcount() или make_set(), почти всегда в паре с by.
• join — сопоставьте таблицы, например, связав логи входа с инвентарём устройств, чтобы обнаружить входы с неуправляемых устройств.
• render — визуализируйте результаты как timechart или barchart прямо в редакторе запросов, удобно для обнаружения скачков.

Правильная фильтрация по времени

Всегда фильтруйте TimeGenerated (или эквивалентный столбец временной метки таблицы) как можно раньше в конвейере. Движки KQL сильно оптимизированы вокруг фильтров по временному диапазону, и размещение | where TimeGenerated > ago(7d) в начале вместо конца может быть разницей между запросом, который возвращает результат за секунды, и запросом, который истекает на перегруженном тенанте.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Поиск по строкам: has vs contains vs ==

Обычная ошибка — использовать `contains` для всего. `has` совпадает с целыми терминами и использует индекс терминов, что делает его значительно быстрее на больших таблицах. Используйте `contains` только когда вам нужны совпадения подстрок внутри слова (например, фрагмент домена), и используйте `==` для точных совпадений на структурированных полях вроде EventID или IPAddress. Эта одна привычка заметно ускоряет поиск в таблицах с высоким объёмом, таких как `DeviceNetworkEvents` или `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Построение переиспользуемой логики обнаружения

Когда запрос доказывает свою полезность, оберните его в функцию с let или сохраните как Sentinel Analytics Rule с запланированным выполнением. Параметризируйте пороги (например, количество неудачных входов) так, чтобы одна и та же логика масштабировалась между тенантами или настраивалась без переписывания с нуля. Вот как разовые запросы поиска превращаются в постоянные детекции, которые автоматически оповещают SOC.

Распространённые ошибки

• Забывание фильтров TimeGenerated, вызывающее медленное и дорогое сканирование всей таблицы.
• Использование summarize перед where, что заставляет движок агрегировать нефильтрованные данные.
• Несовпадение имён столбцов при объединении таблиц — всегда проверяйте схему сначала с getschema.
• Чрезмерное использование contains, которое пропускает преимущества индексирования и замедляет крупномасштабный поиск.

KQL вознаграждает аналитиков, которые думают конвейерами, а не вложенными подзапросами. Начинайте каждое расследование с узкого временного окна и конкретной таблицы, затем расширяйте только по мере необходимости.

Если это дало вам прочный фундамент, исследуйте сегменты Blue Team и Digital Forensics на Korra Studio для дополнительных практических прохождений запросов SOC и упражнений по построению детекций.