KQL Basics Every SOC Analyst Should Know

Learn the core KQL syntax and query patterns SOC analysts use daily in Microsoft Sentinel and Defender to hunt threats faster.

Kusto Query Language (KQL) হল Microsoft Sentinel এবং Microsoft Defender-এ threat hunting এবং alert triage-এর মূল ভিত্তি। যদি আপনি একটি SOC-তে কাজ করেন, KQL দক্ষতা সেই বিশ্লেষকদের আলাদা করে যারা দ্রুত "এখানে কী ঘটেছে?" প্রশ্নের উত্তর দিতে পারেন তাদের থেকে যারা ড্যাশবোর্ডের মাধ্যমে ক্লিক করে বেড়াতে থাকে। এটি একটি সম্পূর্ণ ভাষার রেফারেন্স নয় — এটি বাস্তব উপসেট যা শিফটে ক্রমাগত ব্যবহৃত হয়।

SOC-তে KQL কেন গুরুত্বপূর্ণ

KQL read-only এবং বিশাল log dataset দ্রুত query করার জন্য অপ্টিমাইজ করা। Sentinel, Defender for Endpoint, Azure Monitor এবং Log Analytics সবাই এটি ব্যবহার করে। একবার আপনি এটি জানলে, একই মানসিক মডেল দিয়ে পণ্যগুলির মধ্যে pivot করতে পারেন: একটি table বেছে নিন, এটি ফিল্টার করুন, output গঠন করুন। প্রতিটি investigation — phishing triage, lateral movement hunt, false-positive tuning — একটি query দিয়ে শুরু হয়।

Pipe সবকিছু

KQL query একটি pipeline হিসেবে তৈরি। আপনি একটি table দিয়ে শুরু করেন এবং data একটি সিরিজ অপারেটরের মাধ্যমে পাঠান, প্রতিটি আগেরটি ফিল্টার করে, রূপান্তরিত করে বা সংক্ষেপ করে:

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

এটি উপরে থেকে নিচে একটি বাক্যের মতো পড়ুন: SecurityEvent log দিয়ে শুরু করুন, শুধুমাত্র ব্যর্থ logon রাখুন (4625), শেষ দিনে সীমাবদ্ধ করুন, অ্যাকাউন্ট/কম্পিউটার প্রতি failures গণনা করুন, তারপর sort করুন। এই রৈখিক পাঠযোগ্যতা ad hoc hunting-এর জন্য SQL-এর চেয়ে KQL-এর সবচেয়ে বড় শক্তি।

মূল অপারেটররা মনে রাখতে হবে

where — আপনার প্রাথমিক filter।비용ী অপারেশনের আগে data volume কমাতে এটি তাড়াতাড়ি এবং প্রায়ই ব্যবহার করুন।
project — নির্দিষ্ট column নির্বাচন এবং পুনর্নাম করুন, output-তে আপনার প্রয়োজন নেই এমন noise বাদ দিন।
extend — বিদ্যমান column বাদ না দিয়ে computed column যোগ করুন, string parsing বা conditions flag করার জন্য দরকারী।
summarize — count(), sum(), dcount() বা make_set() সহ data aggregate করুন, প্রায় সবসময় by সঙ্গে জোড়া।
join — tables জুড়ে correlate করুন, যেমন sign-in log-কে device inventory-র সাথে linking করে unmanaged device logon খুঁজে পান।
render — query editor-এ সরাসরি result timechart বা barchart হিসেবে visualize করুন, spike খুঁজে পেতে দরকারী।

সঠিকভাবে Time Filtering করা

সর্বদা TimeGenerated-এ ফিল্টার করুন (বা table-এর সমতুল্য timestamp column) pipeline-এ যত তাড়াতাড়ি সম্ভব। KQL engine সময়-পরিসীমা filter-এর চারপাশে ভারীভাবে অপ্টিমাইজ করে, এবং | where TimeGenerated > ago(7d)-কে শীর্ষের পরিবর্তে নিচে রাখলে query যা সেকেন্ডে return হয় এবং যা busy tenant-এ timeout হয় তার পার্থক্য হতে পারে।

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| where UserPrincipalName has "@yourdomain.com"

String Matching: has vs contains vs ==

একটি সাধারণ ভুল সবকিছুর জন্য contains ডিফল্ট করা। has সম্পূর্ণ term ম্যাচ করে এবং একটি term index ব্যবহার করে, বড় table-এ এটি নাটকীয়ভাবে দ্রুত করে তোলে। শুধুমাত্র contains ব্যবহার করুন যখন আপনার একটি word-এর ভিতরে substring match দরকার (যেমন একটি আংশিক domain fragment), এবং structured field-এ exact match-এর জন্য == ব্যবহার করুন যেমন EventID বা IPAddress। এই একটি অভ্যাস DeviceNetworkEvents বা CommonSecurityLog-এর মতো high-volume table জুড়ে hunt উল্লেখযোগ্যভাবে গতিশীল করে।

DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

পুনরায় ব্যবহারযোগ্য Detection Logic তৈরি করা

এক বার একটি query দরকারী প্রমাণিত হলে, এটি let দিয়ে function হিসেবে wrap করুন, অথবা এটি একটি Sentinel Analytics Rule হিসেবে সংরক্ষণ করুন scheduled execution সহ। threshold parameterize করুন (যেমন failed logon count) যাতে একই logic tenant জুড়ে scale হয় বা rewriting ছাড়াই tune হয়। এটি কীভাবে one-off hunting query স্থায়ী detection-তে বিকশিত হয় যা SOC-কে স্বয়ংক্রিয়ভাবে page করে।

সাধারণ Pitfall

TimeGenerated filter ভুলে যাওয়া, ধীর, ব্যয়বহুল full-table scan সৃষ্টি করে।
where-এর আগে summarize ব্যবহার করা, যা engine-কে unfiltered data aggregate করতে বাধ্য করে।
table-এ join করার সময় মিলমেষ মানানসই নয় এমন column নাম — সর্বদা প্রথমে getschema দিয়ে schema পরীক্ষা করুন।
contains overusing, যা indexing সুবিধা skip করে এবং large-scale hunt ধীর করে।

KQL সেই বিশ্লেষকদের পুরস্কৃত করে যারা nested subquery-এর পরিবর্তে pipeline-এ চিন্তা করে। প্রতিটি investigation একটি সংকীর্ণ time window এবং একটি নির্দিষ্ট table দিয়ে শুরু করুন, তারপর শুধুমাত্র প্রয়োজন অনুযায়ী প্রসারিত করুন।

যদি এটি আপনাকে একটি দৃঢ় ভিত্তি দেয়, আরও hands-on SOC query walkthroughs এবং detection-building exercise-এর জন্য Korra Studio-তে Blue Team এবং Digital Forensics segment অন্বেষণ করুন।

AI সহায়তায় লেখা, পর্যালোচনা ও প্রকাশ করেছেন Michal Pilch (CISSP), Korra Studio।