اساسیات KQL برای هر تحلیلگر SOC

Kusto Query Language (KQL) مغز شکار تهدیدات و بررسی هشدارها در Microsoft Sentinel و Microsoft Defender است. اگر در یک SOC کار می‌کنید، تسلط بر KQL تحلیلگرانی را از هم جدا می‌کند که می‌توانند سریع به سؤال "اینجا چه اتفاقی افتاده؟" پاسخ دهند از آن‌هایی که در حال کلیک کردن در داشبوردها گیر افتاده‌اند. این یک مرجع کامل زبان نیست — این زیرمجموعه عملی است که در حین شیفت به طور مداوم استفاده می‌شود.

چرا KQL در SOC اهمیت دارد

KQL فقط‌خواندنی است و برای پرس‌وجوی سریع مجموعه‌های داده‌های لاگ بزرگ بهینه شده است. Sentinel، Defender for Endpoint، Azure Monitor و Log Analytics همه آن را سخن می‌گویند. وقتی که آن را یاد بگیرید، می‌توانید بین محصولات با همان مدل ذهنی حرکت کنید: یک جدول انتخاب کنید، آن را فیلتر کنید، خروجی را شکل دهید. هر بررسی — بررسی phishing، شکار حرکت جانبی، تنظیم false-positive — با یک query شروع می‌شود.

Pipe همه چیز است

Query های KQL به صورت pipeline ساخته می‌شوند. شما با یک جدول شروع می‌کنید و داده‌ها را از یک سری operator عبور می‌دهید، هر کدام نتیجه قبلی را فیلتر، تبدیل یا خلاصه می‌کند:

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

آن را از بالا به پایین مثل یک جمله بخوانید: با لاگ‌های SecurityEvent شروع کنید، فقط failed logons (4625) را نگه دارید، محدود به روز گذشته، شمارش failures برای هر account/computer، سپس مرتب کنید. این خوانایی خطی نقطه قوت بزرگ KQL نسبت به SQL برای شکار ad hoc است.

Operator های کور برای حفظ در ذهن

• where — فیلتر اصلی شما. از آن زود و اکثر استفاده کنید تا volume داده را قبل از عملیات گرانبهایی کاهش دهید.
• project — ستون‌های خاص را انتخاب و تغییر نام دهید، نویز‌هایی را که در خروجی نیاز ندارید دور بریزید.
• extend — ستون‌های محاسبه‌شده را بدون حذف موارد موجود اضافه کنید، برای parsing string ها یا flag کردن شرایط مفید است.
• summarize — داده‌ها را با count()، sum()، dcount() یا make_set() aggregate کنید، تقریباً همیشه با by جفت شده است.
• join — در جداول بین‌رابطی ایجاد کنید، مثلاً linking sign-in logs با device inventory برای شناسایی logons دستگاه غیر مدیریت‌شده.
• render — نتایج را به صورت timechart یا barchart مستقیم در query editor تجسم کنید، برای شناسایی spike ها مفید است.

فیلتر کردن زمان به درستی

همیشه بر TimeGenerated (یا ستون timestamp معادل جدول) در اوایل pipeline فیلتر کنید. موتور KQL به شدت اطراف فیلتر‌های time-range بهینه می‌شود، و قرار دادن | where TimeGenerated > ago(7d) نزدیک به بالا به جای پایین می‌تواند تفاوت بین query ای باشد که در ثانیه برگردد در مقابل یکی که در tenant مشغول timeout شود.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## String Matching: has در مقابل contains در مقابل ==

یک اشتباه معمول پیش‌فرض کردن `contains` برای همه چیز است. `has` term های کامل را match می‌کند و از term index استفاده می‌کند، آن را به طور فاحش سریع‌تر روی جداول بزرگ می‌سازد. `contains` را فقط زمانی استفاده کنید که به substring match داخل یک کلمه نیاز دارید (مثل fragment domain جزئی)، و از `==` برای exact match برای field های ساخت‌شده مثل EventID یا IPAddress استفاده کنید. این یک عادت به طور قابل توجهی شکار را در جداول با volume بالا مثل `DeviceNetworkEvents` یا `CommonSecurityLog` تسریع می‌کند.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

ساخت منطق تشخیص قابل استفاده مجدد

هنگامی که یک query ثابت می‌شود مفید است، آن را به صورت function با let بسته بندی کنید، یا آن را به صورت Sentinel Analytics Rule با اجرای scheduled ذخیره کنید. threshold ها را پارامتریز کنید (مثل failed logon count) تا همان منطق در تمام tenant ها scale شود یا بدون نوشتن دوباره تنظیم شود. این نحوه‌ای است که one-off hunting query ها به detectionهای standing تبدیل می‌شوند که SOC را به طور خودکار page کنند.

Pitfalls معمول

• فراموشی فیلتر‌های TimeGenerated، باعث slow و expensive full-table scans می‌شود.
• استفاده از summarize قبل از where، که موتور را وادار می‌کند تا داده‌های unfiltered را aggregate کند.
• نام‌های ستون مطابقت نداشته در join کردن جداول — همیشه ابتدا schema را با getschema بررسی کنید.
• overusing contains، که benefit های indexing را skip می‌کند و شکار بزرگ‌مقیاس را کند می‌کند.

KQL تحلیلگرانی را پاداش می‌دهد که به جای subquery های تودرتو در pipeline فکر می‌کنند. هر بررسی را با یک time window باریک و یک جدول خاص شروع کنید، سپس فقط به اندازه نیاز گسترش دهید.

اگر این یک پایه‌ی محکم برای شما فراهم آورد، بخش‌های Blue Team و Digital Forensics را در Korra Studio برای walkthrough های query SOC بیشتر و تمرین‌های detection-building کاوش کنید.