AI SOC Agent เทียบกับ SIEM Rules: แต่ละอย่างควรทำอะไร
SIEM rule และ AI SOC Agent แก้ปัญหาคนละแบบ Rule ใช้ตรวจจับเงื่อนไขที่กำหนดแน่นอน ส่วน agent ช่วยรวบรวมบริบท สืบสวน และอธิบายขั้นตอนถัดไปให้นักวิเคราะห์
AI SOC Agent เทียบกับ SIEM Rules: แต่ละอย่างควรทำอะไร
SIEM rule และ AI SOC Agent แก้ปัญหาคนละแบบ Rule ใช้ตรวจจับเงื่อนไขที่กำหนดแน่นอน ส่วน agent ช่วยรวบรวมบริบท สืบสวน และอธิบายขั้นตอนถัดไปให้นักวิเคราะห์
ใช้ rule กับการตรวจจับที่ทำซ้ำได้
Rule เหมาะเมื่อเงื่อนไขชัด เช่น impossible travel บัญชีที่ถูกปิดแต่ยัง login หรือ process ที่เริ่มจาก parent ผิดปกติ เพราะตรวจสอบ ทดสอบ และ audit ได้ง่าย
ใช้ agent กับบริบทและการสืบสวน
หลัง alert เกิด agent ช่วยค้น event ที่เกี่ยวข้อง เทียบ asset กับ identity แปลงคำถาม hunting เป็น query ที่ตรวจสอบได้ และร่างสรุปพร้อมหลักฐาน
ขอบเขตที่ใช้งานได้จริง
ไม่ควรใช้ agent แทน rule ที่เขียนชัด และไม่ควรให้ rule อธิบาย incident ที่มีหลายแหล่งข้อมูล ควรเชื่อมผ่าน workflow ที่นักวิเคราะห์ตรวจหลักฐานได้
ทำไมไม่ควรให้โมเดลชี้ขาดเพียงลำพังว่าอะไร "อันตราย"
Rule คือฟังก์ชัน ใส่ event ชุดเดิมก็ได้ alert เดิมทุกครั้ง จึงเอา log เดือนที่แล้วมา replay ทดสอบตอนแก้ rule ได้ เก็บ version ได้ และอธิบายได้ว่าทำไมถึงยิง alert ส่วนคำตัดสินของโมเดลขึ้นกับ prompt, context และเวอร์ชันของโมเดลด้วย รันสองรอบกับ incident เดียวกันจึงอาจได้คำตอบไม่ตรงกัน ถ้าปล่อยให้โมเดลตัดสินเองทั้งหมดแล้วพลาดขึ้นมา ก็ไม่มีอะไรให้ไล่ debug ไม่มี rule ที่ match ไม่ติดให้ไปแก้ เหลือแค่ย่อหน้าหนึ่งที่อ่านแล้วดูมีเหตุผล
Agent มีปัญหาเพิ่มอีกข้อ คือ field จำนวนมากที่ไหลเข้า SIEM เป็นข้อความที่ผู้โจมตีกำหนดเองได้ ทั้ง user-agent, URL, ชื่อไฟล์, command line, หัวข้ออีเมล และ username ที่พิมพ์ลงหน้า login OWASP อธิบาย indirect prompt injection ว่าเป็นกรณีที่โมเดลรับข้อมูลจากแหล่งภายนอก เช่น เว็บไซต์หรือไฟล์ ซึ่งเนื้อหานั้นอาจเปลี่ยนพฤติกรรมของโมเดลได้ นิยามของ OWASP พูดถึงเว็บไซต์และไฟล์ การเอามาใช้กับ field ใน log จึงเป็นการต่อยอดของเราเอง Rule ใช้ field เหล่านี้เป็นข้อมูลไว้ match ส่วน agent อ่านเป็นข้อความที่อาจมีคำสั่งแฝงอยู่
ตัวอย่างใช้งานจริง: logon ล้มเหลวซ้ำ ๆ แล้วตามด้วยสำเร็จ
Microsoft ระบุว่า Event ID 4625 ถูกบันทึกทุกครั้งที่ logon ล้มเหลว ส่วน 4624 เกิดเมื่อสร้าง logon session หมายเหตุด้าน monitoring ของ 4625 ชี้ status 0xC000006A (รหัสผ่านผิด) สำหรับบัญชีสำคัญและ service account
แนวปฏิบัติที่แนะนำคือเขียนให้ replay ทดสอบได้ ด้านล่างเป็น pseudo-logic ไม่ใช่ syntax ของ zcrSIEM
A: count of 4625 (status or sub status 0xC000006A)
by (target account, source address) >= N within T
B: distinct target accounts in 4625 by source address >= M within T
C: (A or B), then a 4624 for a targeted account within T2,
from the same source address when 4624 has one -> alert
ค่า N, M, T และ T2 ลูกค้าต้องตั้งเองจาก baseline ของตัวเอง A กับ B อ่านเฉพาะ 4625 ส่วน Microsoft ระบุ 4771 (Kerberos pre-authentication ล้มเหลว เฉพาะบน domain controller) และ 4776 (การตรวจ credential แบบ NTLM บันทึกบนเครื่องที่รับผิดชอบตรวจ credential นั้น) ไว้ด้วย จึงควรเพิ่ม event ล้มเหลวที่สภาพแวดล้อมจริงสร้างขึ้น
เมื่อ C ทำงาน agent มีงานที่ขอบเขตชัดเจน คือรวบรวม logon อื่นของบัญชีนั้นและร่างสรุปที่ทุกประโยคต้องอ้าง event ID ส่วน logon ที่สำเร็จเป็นเจ้าของบัญชีจริงหรือไม่ และควรกักกันหรือเปล่า analyst เป็นคนตัดสิน
join ที่ source address ต้องระวัง เพราะใน 4624 ถ้าเป็น NTLM logon จะไม่มีรายละเอียด TCP/IP ถ้าไม่มี source C จะเหลือแค่ match ที่บัญชี agent จึงต้องบอกว่า join ไม่ได้ ห้ามเดาเติมเอง
แบ่งงานทีละงาน: ใครควรเป็นเจ้าของอะไร
| งาน SOC | SIEM rule และ query ควรเป็นเจ้าของ | AI agent ช่วยได้ | คนต้องเก็บไว้ | ถ้าสลับบทบาท |
|---|
| ตรวจจับและปรับจูนพฤติกรรมที่รู้จัก | Rule ที่มี version กับ exception ที่ระบุเจ้าของและวันหมดอายุ | ร่าง rule ที่เสนอ และบอกว่า exception จะซ่อน alert ไหน | อนุมัติ rule และทุก exception | คำตัดสินเปลี่ยนทุกรอบที่รัน พลาดแล้วไม่มี rule ให้ไล่ debug |
| จัดกลุ่ม alert เป็น incident | Correlation ตาม host, user, IP ที่ใช้ร่วมกัน และลำดับเหตุการณ์ | อ่าน incident ที่จัดกลุ่มแล้ว และรายงาน join ที่ทำไม่ได้ | ยืนยันว่าบัญชี เครื่อง และวันที่ใดอยู่ใน incident | โยงกันเพราะชื่อคล้าย หรือพลาดความเชื่อมโยงจริงโดยไม่มีใครรู้ |
| จัดลำดับคิวงาน | Risk score ที่คำนวณจากปัจจัยที่ระบุชัดและแสดงปัจจัยให้ดู (severity, confidence, ความสำคัญของ asset, สิทธิ์ของบัญชี, ATT&CK) | อธิบายลำดับโดยอ้าง field เหล่านั้น | ปรับลำดับและรับผิดชอบการ escalate | ได้ลำดับที่ฟังดูดีแต่ไม่มีใครทำซ้ำได้ |
| กักกัน (ปิดบัญชี, isolate เครื่อง) | ไม่ใช่งานของ SIEM (zcrSIEM ไม่มี SOAR) เจ้าของคือขั้นตอน playbook ใน zcrSOAR ที่ตั้งเป็น Autonomous, Approval หรือ Blocked | เสนอขั้นตอนพร้อมหลักฐาน | อนุมัติที่ขั้น Approval ใน zcrSOAR | Agent เรียก tool แบบ free-form ที่ไม่ผ่านขั้นตอนที่กำหนดไว้ โดนเป้าหมายผิดและไม่มีบันทึกการอนุมัติ |
การแบ่งงานนี้เป็นแนวปฏิบัติที่แนะนำ ไม่ได้อธิบายหน้าจอของ zcrSIEM สิ่งที่ zcrSIEM ระบุไว้คือ predefined, custom และ Sigma-based rule, UEBA พร้อม risk scoring, การรวม alert เป็น incident, AI summary และการแปลงคำถามภาษามนุษย์เป็น query ที่ตรวจสอบได้ ส่วนการทำ version ของ rule, เจ้าของและวันหมดอายุของ exception, การร่าง rule, การอ้าง event ID ทุกประโยค และการ replay rule กับ log เก่า เป็นวิธีทำงานที่ลูกค้าต้องทำเอง ไม่ใช่ความสามารถที่ zcrSIEM ระบุไว้ แถวสุดท้ายเป็นงานของ zcrSOAR ซึ่งบันทึกทุกครั้งที่รัน ส่วนขั้นไหนต้องอนุมัติและใครอนุมัติได้ ลูกค้าต้องตั้งค่าเอง
ข้อจำกัด จุดที่พังได้ และเมื่อไหร่ต้องยกระดับ
Rule มองไม่เห็นสิ่งที่ไม่เคยเข้ามา ถ้า parser เปลี่ยนหรือ log source หยุดส่งจน rule จับไม่ได้ หน้าจอจะเงียบ และโมเดลก็ไม่เห็นสิ่งที่หายไปเหมือนกัน จึงควรเฝ้าสุขภาพของ log source แยกจากการตรวจจับ อีกข้อคือไม่ควรให้ agent ปิดหรือ suppress alert ที่ rule ยิงมา เพราะ false negative แบบนั้นมองไม่เห็น การ suppress ควรเป็น exception ที่มีเจ้าของและวันหมดอายุ
หยุด agent แล้วส่งต่อให้คนเมื่อสรุปมีข้อความที่ไม่อยู่ใน raw event, agent อ้าง event ID ที่ไม่มีใน incident, มีบัญชีสิทธิ์สูงหรือ domain controller เกี่ยวข้อง หรือ agent เสนอให้กักกัน กรณีสุดท้าย แนวปฏิบัติที่แนะนำคือส่งเรื่องกักกันเข้าขั้นตอนใน zcrSOAR ที่ตั้งเป็น Approval ไว้
คำถามที่พบบ่อย
AI SOC Agent แทน detection rule ใน SIEM ได้ไหม?
ไม่ได้ การตรวจจับต้องทำซ้ำและทดสอบได้ ซึ่ง rule ทำได้ ส่วน agent เหมาะกับ event ที่ rule ยิงมาแล้ว โดยช่วยเพิ่มบริบท สรุป และร่าง query ถ้า agent ร่าง rule ให้ ต้องมีคนรีวิวและ replay ทดสอบก่อนใช้จริง
ถ้า zcrSIEM ไม่มี SOAR แล้วการตอบสนองอัตโนมัติทำที่ไหน?
ทำที่ zcrSOAR ซึ่งไม่จำเป็นต้องมี zcrSIEM ก็ใช้งานได้ ขั้น Autonomous ทำงานทันที ขั้น Approval จะรอการอนุมัติจากผู้มีสิทธิ์ตามบทบาท ส่วนขั้น Blocked จะไม่ทำงานจนกว่าจะเปลี่ยนการตั้งค่า gating
จะตรวจงานของ agent อย่างไร และถ้ามี log ที่พยายามสั่ง agent ล่ะ?
ทุกประโยคในสรุปต้องอ้าง event ID ที่มีอยู่จริงใน incident และให้ analyst สุ่มอ่านเป็นระยะ ควรนับด้วยว่า analyst แก้หรือปฏิเสธร่างบ่อยแค่ไหน เพราะเป็นพฤติกรรมที่สังเกตได้จริง ต่างจากคะแนนที่โมเดลอีกตัวให้ ส่วนการจำกัดความเสียหายเมื่อมี log ที่พยายามบังคับ agent แนวปฏิบัติที่แนะนำคือถือ field ใน log เป็นข้อมูลที่ไว้ใจไม่ได้ ไม่ให้ agent มี tool ที่เปลี่ยนสถานะระบบโดยไม่ผ่านการอนุมัติ และให้ rule เป็นฝ่ายตรวจจับ ส่วนการชี้ว่าอันตรายหรือไม่เป็นของ analyst
แหล่งอ้างอิง
- OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, 2025, เข้าถึงเมื่อ 2026-09-28
- Microsoft Learn, 4625(F) An account failed to log on., 2026-03-29, เข้าถึงเมื่อ 2026-09-28
- Microsoft Learn, 4624(S) An account was successfully logged on., 2021-09-07, เข้าถึงเมื่อ 2026-09-28
- Microsoft Learn, 4771(F) Kerberos pre-authentication failed., 2021-09-07, เข้าถึงเมื่อ 2026-09-28
- Microsoft Learn, 4776(S, F) The computer attempted to validate the credentials for an account., 2021-09-13, เข้าถึงเมื่อ 2026-09-28
อ่านต่อ: Human-in-the-Loop SOC, AI Agent ลด Alert Fatigue อย่างไรโดยไม่ซ่อนหลักฐาน และ คู่มือ AI SOC Agent
ดู zcrSIEM · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้
