KQL بنیادی باتیں جو ہر SOC تجزیہ کار کو معلوم ہونی چاہیں

Microsoft Sentinel اور Defender میں SOC تجزیہ کاروں کی روزمرہ استعمال میں آنے والے KQL کی بنیادی ترکیب اور سوال کے نمونے سیکھیں تاکہ خطرات کو تیزی سے تلاش کیا جا سکے۔

Kusto Query Language (KQL) Microsoft Sentinel اور Microsoft Defender میں خطرات کی تلاش اور انتباہات کی درجہ بندی کی بنیاد ہے۔ اگر آپ SOC میں کام کر رہے ہیں تو KQL میں مہارت ان تجزیہ کاروں کو الگ کرتی ہے جو جلدی "یہاں کیا ہوا؟" کا جواب دے سکتے ہیں ان لوگوں سے جو ڈیش بورڈس کے ذریعے کلک کرنے میں پھنسے ہوتے ہیں۔ یہ مکمل زبان کا حوالہ نہیں ہے — یہ عملی ذیلی مجموعہ ہے جو شفٹ میں مسلسل استعمال ہوتا ہے۔

SOC میں KQL کیوں اہم ہے

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)، آخری دن تک محدود کریں، فی اکاؤنٹ/کمپیوٹر ناکامیوں کو شمار کریں، پھر ترتیب دیں۔ یہ خطی سے پڑھنے کی صلاحیت SQL سے زیادہ موازنے والی تلاش کے لیے KQL کی سب سے بڑی طاقت ہے۔

بنیادی آپریٹرز یاد رکھیں

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 بمقابلہ contains بمقابلہ ==

ایک عام غلطی ہر چیز کے لیے `contains` پر غور میں آنا ہے۔ `has` پورے اصطلاحات سے میل کھاتا ہے اور اصطلاح انڈیکس استعمال کرتا ہے، اسے بہت بڑی ٹیبلز پر بہت تیز بناتا ہے۔ `contains` صرف اس وقت استعمال کریں جب آپ کو لفظ کے اندر ذیلی سٹرنگ میچز کی ضرورت ہو (جیسے جزوی ڈومین فریگمنٹ کی طرح)، اور منظم فیلڈز جیسے EventID یا IPAddress پر بالکل میل کے لیے `==` استعمال کریں۔ یہ ایک عادت `DeviceNetworkEvents` یا `CommonSecurityLog` جیسی high-volume ٹیبلز میں تلاشوں کو نمایاں طور پر تیز کرتی ہے۔```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

دوبارہ استعمال کنے کے قابل شناخت منطق تیار کرنا

ایک بار جب سوال مفید ثابت ہو تو اسے let کے ساتھ فنکشن میں لپیٹیں، یا اسے Sentinel تجزیاتی اصول کے طور پر متعین عمل کرنے کے ساتھ محفوظ کریں۔ حدود (جیسے ناکام لاگ ان کی تعداد) کو پیرامیٹرائز کریں تاکہ ایک جیسی منطق کرائے کے پار پھیل جائے یا دوبارہ لکھے بغیر ٹیون ہو سکے۔ یہ ہے کہ کیسے ایک مرتبہ استعمال میں آنے والی تلاش سوالات مستقل شناخت میں تیار ہوتی ہیں جو SOC کو خودکار طریقے سے صفحہ کرتی ہے۔

عام نقصانات

TimeGenerated فلٹرز بھولنا، سست، مہنگے مکمل ٹیبل سکینز کا سبب بننا۔
where سے پہلے summarize استعمال کرنا، جو انجن کو unfil شدہ ڈیٹا کو جمع کرنے پر مجبور کرتا ہے۔
ٹیبلز کو جوڑتے وقت غلط کالم کے نام — ہمیشہ getschema کے ساتھ پہلے سکیما چیک کریں۔
contains کو بہت زیادہ استعمال کرنا، جو انڈیکسنگ فوائد کو چھوڑ دیتا ہے اور بڑے پیمانے پر تلاشوں کو سست کرتا ہے۔

KQL ان تجزیہ کاروں کو انعام دیتا ہے جو nested subqueries کی بجائے pipelines میں سوچتے ہیں۔ ہر تحقیق کو ایک تنگ وقت کی کھڑکی اور ایک مخصوص ٹیبل کے ساتھ شروع کریں، پھر صرف ضرورت کے مطابق وسیع کریں۔

اگر اس نے آپ کو ایک مضبوط بنیاد دی ہے تو Korra Studio پر Blue Team اور Digital Forensics کے حصوں کو دیکھیں مزید عملی SOC سوال کے ذریعے سیر اور شناخت کی تعمیر کی مشقوں کے لیے۔

AI کی مدد سے لکھا گیا، Michal Pilch (CISSP)، Korra Studio کے ذریعے جائزہ لیا گیا اور شائع کیا گیا۔