ใช้ AI Agent ร่วมกับ EDR เดิม: SentinelOne และ BYO
AI SOC Agent ไม่ได้บังคับให้เปลี่ยน EDR แนวทางที่ปลอดภัยกว่าคือคง EDR เป็นจุดเก็บ telemetry และควบคุม แล้วกำหนดชัดว่า agent อ่าน เสนอ และลงมือทำอะไรได้บ้าง
ใช้ AI Agent ร่วมกับ EDR เดิม: SentinelOne และ BYO
AI SOC Agent ไม่ได้บังคับให้เปลี่ยน EDR แนวทางที่ปลอดภัยกว่าคือคง EDR เป็นจุดเก็บ telemetry และควบคุม แล้วกำหนดชัดว่า agent อ่าน เสนอ และลงมือทำอะไรได้บ้าง
เริ่มจาก read-only
เริ่มด้วยบริบท alert, endpoint timeline, identity และ threat intelligence ก่อนตรวจว่าหลักฐานถูกต้อง
แบ่งระดับ action
แยกคำแนะนำ action ที่ analyst อนุมัติ และ action อัตโนมัติความเสี่ยงต่ำ การ isolate production และเปลี่ยน identity ต้องมี approval
เขียน boundary ให้ชัด
ระบุข้อมูลที่รองรับ retention rate limit response action และเจ้าของ escalation ไม่ให้คำว่า connected ถูกเข้าใจว่า fully managed
สองคำถามที่ต้องตอบก่อนออก credential ให้ AI agent
EDR ต้องเปิดข้อมูลอะไรให้อ่านบ้าง แนวปฏิบัติที่แนะนำคือขอเท่านี้ก่อน
- detection พร้อม ID ที่ EDR ออกเอง และ payload ตามที่รับมาจริง
- ตัวตนของ endpoint ใน EDR ได้แก่ device ID, hostname และลูกค้าหรือ site ที่เครื่องสังกัด
- สถานะ EDR agent รวมเวลา last seen และสถานะ isolation ขณะนั้น
- กิจกรรมด้าน process, network และ file ของเครื่องนั้น ภายในช่วงเวลาที่จำกัด
- สิ่งที่ EDR จัดการไปแล้วเอง เช่น บล็อก กักกัน หรือปล่อยผ่าน
ถ้า EDR เปิดข้อมูลข้อใดไม่ได้ผ่านวิธีเชื่อมต่อที่เลือก (zcrSOAR ระบุไว้คือ API, Webhook, Syslog, Native Connector และ Custom Integration) ให้บันทึกเป็น gap ไว้ อย่าให้ AI agent เดาเอง
AI agent ขอให้ทำ action อะไรได้บ้าง ให้แบ่งตามว่าคำสั่งเดียวส่งผลถึงอะไร แล้วดูต่อว่าย้อนกลับได้หรือไม่
- เครื่องเดียว ย้อนกลับได้: สั่ง scan, isolate เครื่อง และ release ออกจาก isolation โดย release ต้องระวังพอกัน เพราะเป็นการนำเครื่องที่เพิ่งสงสัยเมื่อชั่วโมงก่อนกลับเข้าเครือข่าย
- เครื่องเดียว ย้อนกลับยาก: ลบไฟล์, kill process, รัน script ระยะไกล
- หลายเครื่อง หรือตัว EDR เอง: สั่งหลายเครื่องพร้อมกัน, แก้ policy ของ EDR, ถอน EDR agent
ตาราง integration scope
หนึ่งแถวต่อหนึ่งความสามารถของ EDR กรอกแยกตามสภาพแวดล้อมของลูกค้าแต่ละราย แถวไหนกรอกไม่ได้ ก็อย่าเพิ่งเชื่อมต่อความสามารถนั้น
คอลัมน์ gating ใช้สามสถานะที่ zcrSOAR ระบุไว้ต่อ step ของ playbook (Autonomous, Approval, Blocked) ค่าในตารางเป็นแนวปฏิบัติที่แนะนำ
| ความสามารถของ EDR | ทิศทาง | Scope ขั้นต่ำที่ควรให้ | Gating class | หลักฐานที่ต้องเก็บ |
|---|
| Detection และสถานะ endpoint | อ่าน | Read-only เฉพาะ tenant หรือ site ของลูกค้ารายเดียว | Autonomous (อ่านอย่างเดียว) | detection ID ของ EDR, payload ตามที่รับมา, เวลา last seen และสถานะ isolation |
| Timeline กิจกรรมของ endpoint | อ่าน | Read-only จำกัดช่วงเวลา แยกจาก credential ฝั่ง action | Autonomous โดยมีโควตา query ต่อ case | query, ช่วงเวลา, ผลครบหรือบางส่วน |
| สั่ง scan | ลงมือ (ย้อนกลับได้) | เฉพาะ scan บน endpoint ของลูกค้ารายเดียว | Approval; Autonomous เฉพาะกลุ่มเครื่องความเสี่ยงต่ำ และต่อเมื่อ scan ย้อนกลับได้ เคยทำงานภายใต้ Approval มาตลอดรอบทบทวนโดยไม่มีการอนุมัติใดต้องถูกย้อนทีหลัง และมีเส้นทางย้อนกลับที่ทดสอบแล้ว | ผู้อนุมัติ, device ID, ID งานฝั่ง EDR (ถ้า EDR ส่งกลับมา), ผลลัพธ์ |
| Isolate endpoint | ลงมือ (ย้อนกลับได้ แต่กระทบการใช้งาน) | เฉพาะ isolate หนึ่งเครื่องต่อหนึ่งคำขอ | Approval | บันทึกการอนุมัติ, ความสำคัญของเครื่อง, สถานะก่อนและหลัง |
| Release ออกจาก isolation | ลงมือ (ย้อนกลับได้ แต่เป็นการนำเครื่องกลับเข้าเครือข่าย) | เฉพาะ release หนึ่งเครื่องต่อหนึ่งคำขอ | Approval โดยผู้อนุมัติต้องเห็นหลักฐานว่าเครื่องสะอาด | ผู้อนุมัติ, หลักฐานนั้น, สถานะก่อนและหลัง |
| ลบไฟล์, kill process, script ระยะไกล, แก้ policy ของ EDR, ถอน EDR agent | ลงมือ (ย้อนกลับยาก) | ไม่ให้ credential ที่ AI agent ใช้ได้ | Blocked | ทุกคำขอ บันทึกเป็นงาน manual พร้อมผู้ขอและเหตุผล |
แนวปฏิบัติที่แนะนำ: แยก credential ฝั่งอ่านกับฝั่งลงมือออกจากกัน จะได้เพิกถอนฝั่ง action ได้โดยฝั่งอ่านยังทำงานต่อ ถ้า role ของ EDR แยกสิทธิ์ scan, isolate และ release ไม่ได้ ให้ตั้ง action ส่วนเกินเป็น Blocked ใน playbook และสมมติว่า credential นั้นกว้างกว่าในตาราง ส่วน "หนึ่งเครื่องต่อหนึ่งคำขอ" เป็นกฎของ playbook ไม่ใช่ role ของ EDR
สิ่งที่มีเอกสารรองรับ แนวปฏิบัติที่แนะนำ และสิ่งที่ลูกค้าตั้งค่าเอง
ระบุไว้ใน zcrSOAR: ทำงานร่วมกับระบบหลายหมวด รวมถึง EDR ตัวอย่างในแคตตาล็อกคือ isolate หรือ release endpoint และสั่ง scan ผ่าน SentinelOne จาก case หรือ step ของ playbook zcrSOAR บันทึก timestamp, user, action, playbook, connector, input และ result ของแต่ละการทำงาน ส่วน playbook ที่ยังไม่อนุมัติจะอยู่ใน Draft, Test, Dry-run หรือ Simulation Mode จนกว่าองค์กรจะอนุญาตให้ทำงานจริง ฟีเจอร์ AI ของ zcrSOAR คือ assistant ที่ร่าง playbook จาก prompt ให้ตรวจทาน
ระบุไว้สำหรับ zcrMDR: ทำงานร่วมกับ workflow EDR เดิมของลูกค้าได้ โดย integration, response action และ SLA กำหนดกันตอน onboarding บริการนี้เป็น managed service ที่ส่งมอบผ่าน channel partner ที่ได้รับอนุมัติ
แนวปฏิบัติที่แนะนำและสิ่งที่ลูกค้าตั้งค่าเอง: ค่าในตารางและการตรวจต่าง ๆ ในหัวข้อ failure mode เป็นแนวปฏิบัติที่แนะนำ ส่วนการสร้าง credential ฝั่ง EDR การระบุผู้อนุมัติ การเลือกกลุ่มเครื่องที่สั่ง scan แบบ Autonomous ได้ และการต่อ AI agent เข้ากับ step ของ playbook ใน zcrSOAR เป็นการตั้งค่าที่ลูกค้าต้องทำเอง
Failure mode และเงื่อนไขส่งต่อให้คน
Telemetry ล้าสมัย เวลา last seen ที่เก่าอาจแปลว่าเครื่องถูก reimage ย้ายที่ หรือปิดไปแล้ว zcrCTEM แสดง coverage ของ EDR รายเครื่อง (มี ขาด หรือยังยืนยันไม่ได้) ช่วยหาจุดบอดได้ แต่ไม่ใช่การตรวจก่อนลงมือ
แนวปฏิบัติที่แนะนำ: อ่านสถานะ EDR agent และ isolation ใหม่ก่อน step ที่ลงมือทุกครั้ง หยุดถ้า last seen เก่ากว่าเกณฑ์ที่ลูกค้ากำหนด และส่ง case เข้าคิวของคนพร้อมระบุว่า "context ไม่ครบ"
ส่งต่อให้คนเมื่อ EDR agent ของเครื่องสำคัญหายไปหรือยืนยันสถานะไม่ได้
Detection เดียวกันมาสองทาง zcrSOAR รับข้อมูลจาก EDR ที่เชื่อมต่อไว้ได้ และเชื่อมกับ zcrSIEM ได้เมื่อติดตั้งทั้งคู่ ส่วน zcrSIEM เองก็รวม alert จาก endpoint กับแหล่งอื่นเป็น incident เดียว ถ้าตั้งให้ทั้งสองทางเปิด case detection เดียวก็อาจกลายเป็นสอง case
แนวปฏิบัติที่แนะนำ: ติด detection ID ของ EDR ไว้ทุก case ค้นหา case ที่เปิดอยู่และมี ID เดียวกันก่อนสร้างใหม่ และสร้าง idempotency key จาก detection ID, action และเครื่องเป้าหมาย เพื่อให้ระบบรู้ว่าคำขอ isolate ที่ส่งซ้ำคือคำขอเดิม
ส่งต่อให้คนเมื่อมีสอง case บนเครื่องเดียวกัน ให้คนรวม case
API rate limit query ตอนสืบสวนมักถูกเรียกบ่อยกว่า action จึงมักชนเพดานก่อน เพดานจริงดูได้จากเอกสาร API ของ vendor EDR
แนวปฏิบัติที่แนะนำ: จำกัดช่วงเวลาของ query, ตั้งโควตา query ต่อ case, เก็บผลลัพธ์ไว้ใน case และห้าม retry step ที่ลงมือวนซ้ำ ถ้า API ตอบ HTTP 429 (ส่ง request มากเกินไปในช่วงเวลาหนึ่ง ตาม RFC 6585) ให้รอตามที่ response ระบุ header Retry-After อาจมีหรือไม่มีก็ได้ playbook จึงต้องมีค่า back-off สำรองของตัวเอง
ส่งต่อให้คนเมื่ออ่านข้อมูลไม่ครบ อย่าลงมือด้วยข้อมูลครึ่งเดียว
Tenant isolation สำหรับ MSP ถ้าใช้ credential เดียวกับลูกค้าทุกราย token รั่วหนึ่งครั้งหรือเลือกเป้าหมายผิดหนึ่งครั้งก็กระทบทุกลูกค้า
แนวปฏิบัติที่แนะนำ: ใช้หนึ่ง credential และหนึ่ง connector ต่อลูกค้า จำกัดที่ tenant หรือ site ของลูกค้ารายนั้น ตรวจก่อน step ที่ลงมือทุกครั้งว่า device ID ของเป้าหมายเป็นของลูกค้าที่ระบุใน case และแยกโควตา query ต่อลูกค้า
ถ้าเป้าหมายเป็นของลูกค้ารายอื่น ให้หยุด playbook และส่งต่อให้คนทันที
คำถามที่พบบ่อย
เอา EDR ที่ใช้อยู่ เช่น CrowdStrike มาใช้ต่อได้ไหม?
การคง EDR เดิมไว้เป็นแนวปฏิบัติที่แนะนำ ตัวอย่างของ zcrSOAR ที่มีเอกสารรองรับคือ SentinelOne ส่วน CrowdStrike หรือ EDR ยี่ห้ออื่น ควรให้ channel partner ที่ได้รับอนุมัติยืนยันเป็นลายลักษณ์อักษรก่อนว่าใช้ action อะไรได้บ้าง แล้วจึงสร้าง playbook
ทดสอบอย่างไรก่อนปล่อยให้ AI agent ลงมือ?
แนวปฏิบัติที่แนะนำคือเริ่มแบบอ่านอย่างเดียว แล้วเทียบข้อมูลที่ AI agent รวบรวมสำหรับ detection จริงในอดีตกับที่ analyst ดึงเอง จากนั้นรัน Dry-run โดยตั้ง step ที่ลงมือเป็น Approval
เป็น MSP ใครควรอนุมัติ isolate เครื่องของลูกค้า?
แนวปฏิบัติที่แนะนำคือกำหนดเป็นลายลักษณ์อักษรก่อน onboarding ว่าใครอนุมัติ isolate และ release ของลูกค้าแต่ละรายได้ เพราะเป็นข้อตกลงในสัญญา zcrSOAR กำหนดผู้อนุมัติตาม asset, site หรือ business unit ได้
แหล่งอ้างอิง
- IETF (RFC Editor), RFC 6585: Additional HTTP Status Codes, เมษายน 2012, เข้าถึงเมื่อ 2026-09-28
อ่านต่อ: จาก Alert ถึงหลักฐาน: Workflow AI SOC ที่ตรวจสอบย้อนหลังได้, Human-in-the-Loop SOC, คู่มือ AI SOC Agent และ วิธีส่ง Log จาก SentinelOne และ CrowdStrike EDR เข้า SIEM
ดู zcrMDR · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้
