KQL Basics Every SOC Analyst Should Know

เรียนรู้ไวยากรณ์ KQL หลักและรูปแบบการค้นหาที่นักวิเคราะห์ SOC ใช้ทุกวันใน Microsoft Sentinel และ Defender เพื่อตรวจจับภัยคุกคามได้เร็วขึ้น

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 สำหรับการตรวจจับแบบตามต้องการ

ตัวดำเนินการหลักที่ต้องจดจำ

where — ตัวกรองหลักของคุณ ใช้มันเร็วและบ่อยเพื่อลดปริมาณข้อมูลก่อนการดำเนินการที่มีค่าใช้จ่ายสูง
project — เลือกและเปลี่ยนชื่อคอลัมน์เฉพาะ ทิ้งสัญญาณรบกวนที่คุณไม่ต้องการในผลลัพธ์
extend — เพิ่มคอลัมน์ที่คำนวณได้โดยไม่ลบคอลัมน์ที่มีอยู่ มีประโยชน์สำหรับการแยกวิเคราะห์สตริงหรือการตั้งค่าเงื่อนไข
summarize — รวมข้อมูลด้วย count(), sum(), dcount() หรือ make_set() เกือบทุกครั้งจับคู่กับ by
join — เชื่อมโยงระหว่างตาราง เช่น การเชื่อมโยงบันทึกการลงชื่อเข้าระบบกับสินค้าคงคลังอุปกรณ์เพื่อตรวจจับการลงชื่อเข้าระบบอุปกรณ์ที่ไม่มีการจัดการ
render — แสดงภาพผลลัพธ์เป็น timechart หรือ barchart โดยตรงในตัวแก้ไขการค้นหา มีประโยชน์สำหรับการตรวจจับการเพิ่มขึ้น

การกรองเวลาที่ทำได้ถูกต้อง

อยู่เสมอกรองบน TimeGenerated (หรือคอลัมน์เวลาแสตมป์ที่เทียบเท่ากันของตาราง) เร็วที่สุดเท่าที่เป็นไปได้ในไปป์ไลน์ เครื่องยนต์ KQL ปรับให้เหมาะสมอย่างมากรอบตัวกรองช่วงเวลา และการใส่ | where TimeGenerated > ago(7d) ใกล้ด้านบนแทนด้านล่างสามารถเป็นความแตกต่างระหว่างการค้นหาที่ส่งคืนในไม่กี่วินาทีกับการค้นหาที่หมดเวลาบนผู้เช่าที่ว่างเหง่า

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

การจับคู่สตริง: has vs contains vs ==

ข้อผิดพลาดทั่วไปคือการใช้ contains สำหรับทุกสิ่ง has ตรงกับคำศัพท์ทั้งหมดและใช้ดัชนีคำศัพท์ ทำให้เร็วขึ้นอย่างมากบนตารางขนาดใหญ่ ใช้ contains เฉพาะเมื่อคุณต้องการการจับคู่สตริงย่อยภายในคำ (เช่นส่วนโดเมนบางส่วน) และใช้ == สำหรับการจับคู่ที่แน่นอนบนเขตข้อมูลที่มีโครงสร้างเช่น EventID หรือ IPAddress นิสัยเดียวนี้จะเร่งการตรวจจับอย่างเห็นได้ชัดบนตารางที่มีปริมาณสูงเช่น DeviceNetworkEvents หรือ CommonSecurityLog

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

การสร้างตรรกะการตรวจจับที่สามารถนำกลับมาใช้ได้

เมื่อการค้นหาพิสูจน์แล้วว่ามีประโยชน์ ให้ห่อมันเป็นฟังก์ชันด้วย let หรือบันทึกเป็นกฎ Sentinel Analytics ที่มีการดำเนินการตามตารางเวลา นำพารามิเตอร์ไปใช้กับค่าขีดจำกัด (เช่นจำนวนการล็อกอินที่ล้มเหลว) เพื่อให้ตรรกะเดียวกันสามารถปรับขนาดได้ในผู้เช่าหรือได้รับการปรับแต่งโดยไม่ต้องเขียนใหม่ตั้งแต่เริ่มต้น นี่คือวิธีที่การค้นหาการตรวจจับแบบพิเศษทีละครั้งกลายเป็นการตรวจจับที่ยืนหยัดซึ่งโทร SOC โดยอัตโนมัติ

ข้อผิดพลาดทั่วไป

ลืมตัวกรอง TimeGenerated ทำให้เกิดการสแกนตารางเต็มอย่างช้าและมีค่าใช้จ่ายสูง
ใช้ summarize ก่อน where ซึ่งบังคับให้เครื่องยนต์รวมข้อมูลที่ไม่มีการกรอง
ชื่อคอลัมน์ที่ไม่ตรงกันเมื่อเข้าร่วมตาราง — ตรวจสอบสคีมาเสมอด้วย getschema ก่อน
การใช้ contains มากเกินไป ซึ่งข้ามประโยชน์ของดัชนีและทำให้การตรวจจับขนาดใหญ่ช้าลง

KQL ให้รางวัลแก่นักวิเคราะห์ที่คิดในแนวท่อแทนการสอบถามย่อยที่ซ้อนกัน เริ่มการสอบสวนทุกครั้งด้วยช่วงเวลาแคบและตารางเฉพาะ จากนั้นขยายออกไปเท่านั้นตามที่จำเป็น

หากนี่ให้พื้นฐานที่มั่นคงแก่คุณ ให้สำรวจส่วน Blue Team และ Digital Forensics บน Korra Studio เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการสัอบถาม SOC ที่ใช้ได้จริงและแบบฝึกหัดการสร้างการตรวจจับ

เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio