Detection Engineering

องค์กรที่ซื้อ SIEM แล้วเปิดใช้ rule default ทั้งหมด มักได้ alert จำนวนมหาศาลที่ไม่สะท้อนความเสี่ยงจริง ทีมจึงใช้เวลาทั้งวันปิด alert แทนที่จะออกแบบ detection ที่ยกระดับ บทนำนี้แนะนำแนวคิด threat-led detection, detection-as-code และการวัดผลด้วย MITRE ATT&CK coverage พร้อมเล่าว่าเหตุใด detection engineering จึงต้องเริ่มจาก use case และ threat model ขององค์กร ไม่ใช่จาก rule ที่ vendor แถมมาให้

 

ในปัจจุบันจำนวน rule ที่ใช้งานใน SIEM ขององค์กรขนาดกลางในไทยโดยเฉลี่ยอยู่ในหลักหลายร้อยถึงพันกว่ารายการ ในขณะที่อัตราการ false positive ของ rule ส่วนใหญ่ยังอยู่ในระดับสูง (จากการสังเกตของทีม detection engineering ของเราใน engagement ภาคการเงิน) การเพิ่มจำนวน rule จึงไม่ใช่หนทางที่นำไปสู่การตรวจจับที่ดีขึ้น แต่กลับสร้างภาระให้กับนักวิเคราะห์และลดความเชื่อมั่นในระบบตรวจจับ Detection Engineering จึงเน้นคุณภาพและ coverage ของ rule มากกว่าปริมาณ

 

กรอบที่ใช้ในการยกระดับ detection ให้กับองค์กรอาศัย MITRE ATT&CK เป็นแกนหลัก โดยแบ่งขั้นตอนออกเป็นการประเมิน coverage, การออกแบบ use case ใหม่, การพัฒนา rule, การทดสอบด้วย Atomic Red Team, การ deploy ไปยัง production, และการ tune ตามข้อมูล telemetry ที่เก็บได้ พร้อมวัดผลผ่าน ATT&CK Navigator ที่แสดงสถานะการครอบคลุมของแต่ละเทคนิค

 

40%

ของ detection rule ใน SIEM ขององค์กรส่วนใหญ่ไม่มีการทดสอบหลังจากเปิดใช้งาน (SANS 2024)

 

600+

จำนวน techniques + sub-techniques ใน MITRE ATT&CK (Enterprise) ที่ SOC ต้องตัดสินใจครอบคลุมอย่างมีลำดับความสำคัญ

 

จำนวนมาก

ของ alert ที่นักวิเคราะห์ใช้เวลามากที่สุด ยังมีสาเหตุจาก rule ที่ไม่ถูก tune (จากการสังเกตของทีมเราในหลาย SOC engagement)

 

คู่มือเล่มนี้แบ่งออกเป็น 7 บท เรียงลำดับจากพื้นฐานความรู้ความเข้าใจในภัยคุกคาม ไปจนถึงการวางกลยุทธ์ การลงมือปฏิบัติ และการวัดผล แต่ละบทจะสรุปแนวคิดหลัก ศัพท์สำคัญ และข้อควรทำจริงให้อ่านเข้าใจได้โดยไม่ต้องมีพื้นฐานเทคนิคมาก่อน

 

 

CHAPTER ONE · THE STRATEGY

 

 

Detection strategy ที่ถูกต้องเริ่มจากการตอบคำถาม 3 ข้อ — crown jewel ขององค์กรคืออะไร, ผู้โจมตีที่มีแรงจูงใจกับสินทรัพย์นั้นคือใคร, และพวกเขาใช้ technique ใดใน MITRE ATT&CK จากนั้นจึงออกแบบ detection ให้ครอบคลุม technique เหล่านั้น วิธีนี้ทำให้ทุก rule มีเหตุผลที่ผูกกับความเสี่ยงธุรกิจ ไม่ใช่แค่ตาม template ของ vendor

 

“Detection strategy ที่ดีตอบคำถามว่า ใครเป็นภัย, โจมตีอะไร, ด้วย TTP ใด — ไม่ใช่เริ่มจากสเปก SIEM”

 

 

CHAPTER TWO · THE COVERAGE

 

 

MITRE ATT&CK ประกอบด้วย 14 tactics และกว่า 600 techniques/sub-techniques การวัด coverage แบบ checklist ของทั้งหมดไม่ได้มีประโยชน์จริง เพราะ technique ที่ไม่เกี่ยวข้องกับ environment ขององค์กรไม่ต้อง detect แนวทางที่ได้ผลคือสร้าง coverage map ที่ filter เฉพาะ technique ที่ threat actor กลุ่มเป้าหมายใช้บ่อย และมี data source ที่องค์กรมีเก็บอยู่

 

“MITRE ATT&CK coverage ไม่ใช่ checklist แต่คือเข็มทิศของทีม detection”

 

 

CHAPTER THREE · THE LIFECYCLE

 

 

Rule development ควรมี lifecycle ที่เป็นระบบ — Hypothesis (ตั้งสมมติฐานว่าพฤติกรรมไหนคือ attack), Research (ค้นหาเอกสาร วิเคราะห์ sample), Design (ออกแบบ logic และเลือก data source), Implementation (เขียน rule ใน SIEM/EDR), Testing (ทดสอบกับ attack จริงและ benign traffic), Review (peer review จากทีม), Deployment (deploy ในรูปแบบ tuning mode ก่อน), Monitoring (ติดตาม FP/TP rate), Retirement (ยกเลิกเมื่อ technique หมดความเกี่ยวข้อง)

 

“Rule ที่เขียนเสร็จแล้วคือจุดเริ่มต้น ไม่ใช่จุดสิ้นสุด”

 

 

CHAPTER FOUR · THE VALIDATION

 

 

ทุก rule ควรผ่าน 2 ระดับการทดสอบ — unit test ที่ทดสอบ logic กับ sample log ที่ known-good และ known-bad, และ integration test ที่ทดสอบกับ attack จริงใน lab environment เครื่องมือ open-source เช่น Atomic Red Team, Caldera, Sliver, Stratus Red Team สามารถ simulate technique ได้โดยไม่ต้องใช้ malware จริง

 

“ถ้าคุณไม่ test rule ใหม่กับ attack จริง คุณกำลัง deploy ความเชื่อ ไม่ใช่ detection”

 

 

CHAPTER FIVE · THE AUTOMATION

 

 

SOAR มีประโยชน์เมื่อ process ของทีม IR ชัดเจนและเสถียรแล้ว การ automate ขั้นตอน triage — enrichment (lookup IP, hash, user), context gathering (ดึง log ประกอบ), และ classification (จัด severity เบื้องต้น) — เป็นจุดที่ ROI สูงที่สุด เพราะช่วยลดงาน Tier 1 ลงได้อย่างมีนัยสำคัญ (ตัวเลขจริงขึ้นกับ baseline และคุณภาพของ playbook)

 

“Automation ที่เพิ่ม alert = เพิ่มความเจ็บปวด ไม่ใช่เพิ่มความสามารถ”

 

 

CHAPTER SIX · THE ADVERSARY

 

 

Threat-Informed Detection คือการออกแบบ detection โดยเริ่มจาก threat actor ที่เป็นเป้าหมายขององค์กร — เช่น ธนาคารไทยควรสนใจ APT41, FIN7, Scattered Spider, Lazarus — แล้วศึกษา TTP ของพวกเขาจาก threat report เช่น Mandiant, CrowdStrike, Group-IB รวมถึง CTI feed ของ ThaiCERT และหน่วยงานในประเทศ

 

“ผู้โจมตีไม่เคยอ่าน rule ของคุณก่อนโจมตี — แต่คุณต้องอ่าน TTP ของเขาก่อนเขียน rule”

 

 

CHAPTER SEVEN · THE METRICS

 

 

Detection KPI ที่ผิดพลาดที่สุดคือการนับจำนวน rule ที่เขียน หรือจำนวน alert ที่ปิด — ตัวเลขเหล่านี้ไม่สะท้อนความสามารถในการตรวจจับ threat จริง KPI ที่ใช้งานได้ ได้แก่ Detection Coverage (% ของ technique ที่มี detection), Detection Accuracy (precision × recall), Time to Detect (MTTD), False Positive Rate, และ Rule Efficacy Score ที่คำนวณจาก TP/(TP+FP+FN)

 

“KPI ที่วัดจำนวน rule = การนับน้ำหนักไม่ใช่การวัดคุณค่า”

 

 

Detection Engineering คือการยกระดับจาก ad-hoc rule writing สู่ระบบที่มี process, tool และ metric ที่ชัดเจน การเปลี่ยนผ่านนี้ต้องใช้เวลา 12–24 เดือน แต่ผลลัพธ์คือ SOC ที่สามารถตรวจจับ threat ที่สำคัญจริง ๆ โดยไม่จมอยู่ใน alert ที่ไม่สำคัญ

 

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: