Основи KQL, які повинен знати кожен аналітик SOC

Kusto Query Language (KQL) — це основа полювання на загрози та тріажу сигналів у Microsoft Sentinel і Microsoft Defender. Якщо ви працюєте в SOC, вільне володіння KQL розділяє аналітиків, які можуть швидко відповісти на питання «що тут сталося?», від тих, хто застряг у розглядуванні панелей. Це не повна довідка мови — це практичне підмножество, яке постійно використовується під час зміни.

Чому KQL важлива в SOC

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

Труба — це все

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

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

Читайте це зверху вниз як речення: почніть з логів SecurityEvent, залишіть лише невдалі входи (4625), обмежте останній день, підрахуйте помилки для кожного облікового запису/комп'ютера, потім відсортуйте. Така лінійна читаність — найбільша сила KQL порівняно з SQL для спеціальних операцій полювання.

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

• 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 та вправ з побудови виявлення.