EDR, XDR และ MDR มักถูกนำมาเทียบกันเหมือนเป็นสินค้า 3 แบบ แต่จริง ๆ เป็นของคนละชนิด EDR (การตรวจจับและตอบสนองที่เครื่องผู้ใช้ หรือ endpoint detection and response) คือซอฟต์แวร์ที่ติดตั้งบนเครื่องผู้ใช้และเซิร์ฟเวอร์ คอยบันทึกว่าแต่ละเครื่องทำอะไรอยู่ จับพฤติกรรมที่น่าสงสัย และให้ทีมวิเคราะห์สั่งตัดเครื่องออกจากเครือข่ายหรือหยุดโปรแกรมได้ XDR (การตรวจจับและตอบสนองแบบขยาย หรือ extended detection and response) ขยายแนวคิดเดียวกันไปยังข้อมูลจากอีเมล ระบบตัวตนผู้ใช้ และคลาวด์ ส่วน MDR (การตรวจจับและตอบสนองที่มีผู้ให้บริการดูแลให้ หรือ managed detection and response) เป็นบริการ คือทีมภายนอกที่เฝ้าดูและตอบสนองแทนองค์กร โดยมักใช้เครื่องมือ EDR หรือ XDR คำถามแรกจึงไม่ใช่ว่าจะซื้อตัวย่อไหน แต่เป็นว่าใครจะอ่านการแจ้งเตือนและลงมือแก้ รวมถึงตอนกลางคืนและวันหยุด

EDR, XDR และ MDR คืออะไร

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

  • EDR: มี agent (โปรแกรมเล็ก ๆ ที่ติดตั้งบนแต่ละเครื่อง) คอยเก็บข้อมูลกิจกรรม เช่น โปรแกรมที่ทำงาน ไฟล์ที่เปลี่ยน และการเชื่อมต่อเครือข่าย แล้วมองหาพฤติกรรมที่ผิดปกติ ไม่ได้ดูแค่ว่าตรงกับมัลแวร์ที่รู้จักอยู่แล้วหรือไม่ ทีมสั่งตอบสนองบนเครื่องนั้นได้ เช่น ตัดเครื่องออกจากเครือข่าย หยุดโปรแกรม หรือลบไฟล์อันตราย EDR เห็นเฉพาะเครื่องที่ติดตั้ง agent
  • XDR: แพลตฟอร์มที่รับข้อมูลจากเครื่องผู้ใช้ และจากเครือข่าย คลาวด์ อีเมล และระบบตัวตน (ระบบที่จัดการบัญชีและการเข้าสู่ระบบ) แล้วรวมสัญญาณที่เกี่ยวข้องกันเป็นเหตุการณ์เดียว และมีการตอบสนองให้ใช้ เช่น ตัดเครื่องออกจากเครือข่ายหรือปิดบัญชี XDR มี 2 แบบ คือ native XDR (รวมอยู่ในผลิตภัณฑ์ของผู้ผลิตรายเดียว) และ open XDR (เชื่อมกับเครื่องมือของผู้ผลิตรายอื่นได้)
  • MDR: เป็นบริการ ไม่ใช่เครื่องมือ หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของแคนาดา (Canadian Cyber Centre) จัด MDR ไว้เป็นบริการหนึ่งของผู้ให้บริการด้านความปลอดภัยแบบมีการจัดการ (MSSP) ได้แก่ การเฝ้าดู การตรวจจับ การแจ้งเตือน และการจัดการการตอบสนองต่อการโจมตี ขอบเขตของแต่ละรายต่างกัน จึงต้องดูที่สัญญามากกว่าชื่อบริการ
INFOGRAPHIC
XDR รวมสัญญาณจากแหล่งใดบ้าง
XDR
รวมสัญญาณเป็นเหตุการณ์เดียว
เครื่องผู้ใช้ (endpoint)
แหล่งเดียวของ EDR
ตัวตนผู้ใช้
บัญชีและการเข้าสู่ระบบ
อีเมล
ฟิชชิงและไฟล์แนบ
คลาวด์
บริการและ workload บนคลาวด์
เครือข่าย
ทราฟฟิกเครือข่าย

สามอย่างนี้ไม่ใช่บันได 3 ขั้นของเรื่องเดียวกัน องค์กรอาจใช้ EDR เองโดยไม่มีบริการเสริม ซื้อ EDR ร่วมกับบริการ MDR ใช้ XDR เอง หรือให้ผู้ให้บริการ MDR ดูแล XDR ให้ก็ได้ ส่วนความสัมพันธ์ระหว่าง XDR กับ SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) และ SOAR (ระบบสั่งงานตอบสนองอัตโนมัติ) ดูได้ใน SIEM + SOAR กับ XDR: ข้อดี ข้อจำกัด และคำแนะนำ บทความนี้เน้นการเลือกที่เริ่มจากเครื่องผู้ใช้เป็นหลัก

แต่ละแบบมองเห็นอะไร และมองไม่เห็นอะไร

การตรวจจับขึ้นอยู่กับข้อมูลที่เครื่องมือได้รับ จึงควรเทียบความครอบคลุม ไม่ใช่เทียบชื่อ:

  • EDR เห็นเฉพาะเครื่องที่มี agent: เครื่องที่ไม่ได้ติดตั้ง agent เครื่องส่วนตัว และอุปกรณ์เครือข่าย อยู่นอกสายตาของ EDR Microsoft อธิบายว่า EDR ใช้ข้อมูลจากตัวเครื่อง (endpoint) เท่านั้น
  • การโจมตีที่ไม่ผ่านตัวเครื่อง EDR อาจไม่เห็น: เช่น ผู้โจมตีนำรหัสผ่านที่ขโมยมาไป login อีเมลหรือบริการคลาวด์ ข้อมูลจากระบบตัวตนและอีเมลที่ XDR เพิ่มเข้ามาช่วยให้เห็นกรณีนี้ได้
  • XDR แข็งแรงที่สุดกับแหล่งข้อมูลของผู้ผลิตเอง: ความครอบคลุมกับผลิตภัณฑ์ของผู้ผลิตรายอื่นต่างกันไป จึงควรถามว่าเชื่อมแหล่งข้อมูลไหนแบบ native (รองรับในตัว ไม่ต้องต่อเพิ่ม)
  • MDR เห็นเท่าที่เชื่อมเข้ามา: นักวิเคราะห์ของผู้ให้บริการตรวจสอบได้เฉพาะข้อมูลที่เครื่องมือส่งให้ Cyber Centre เตือนว่าผู้ให้บริการอาจไม่รู้เรื่องระบบใหม่หรือการเปลี่ยนแปลง ถ้าองค์กรไม่แจ้ง

ผลทดสอบของ MITRE บอกอะไรได้และบอกอะไรไม่ได้

ผู้ผลิตมักอ้างผลจาก MITRE ATT&CK Evaluations MITRE ATT&CK (ฐานความรู้ที่รวบรวมเทคนิคของผู้โจมตีจริง) เป็นฐานของโครงการนี้ โดย MITRE จำลองพฤติกรรมของผู้โจมตีจริงใส่ผลิตภัณฑ์ด้านความปลอดภัยในสภาพแวดล้อมที่ควบคุมได้ คำถามที่พบบ่อยของ MITRE ซึ่งอ่านเมื่อ 22 ตุลาคม 2026 ระบุว่าไม่มีการจัดอันดับและไม่มีผู้ชนะ และการเข้าร่วมทดสอบไม่ได้หมายความว่า MITRE รับรอง จัดอันดับ หรือให้ใบรับรองผลิตภัณฑ์ ผลที่ได้บอกว่าผลิตภัณฑ์ทำงานอย่างไรในสภาพแวดล้อมมาตรฐานกับสถานการณ์โจมตีที่กำหนด จึงเป็นข้อมูลประกอบการตัดสินใจ ไม่ใช่คำตอบสุดท้าย

สำหรับรอบปี 2026 หน้าอธิบายวิธีทดสอบของ MITRE ใช้คะแนนรวมที่เรียกว่า TES (Total Evaluation Score หรือคะแนนประเมินรวม) และแนะนำให้ถามสามข้อกับผลทดสอบทุกรายการ:

  • คะแนนเท่าไร: TES รวมดัชนีคุณภาพการตรวจจับ (DQI) กับดัชนีคุณภาพการป้องกัน (PQI) ซึ่งแต่ละดัชนีมีค่า 0 ถึง 1 คะแนนรวมจึงอยู่ระหว่าง 0.0 ถึง 2.0 ควรดูทั้งสองส่วน เพราะผลิตภัณฑ์ที่ตรวจจับได้ดีแต่ป้องกันได้น้อย ต่างจากผลิตภัณฑ์ที่ป้องกันได้ดีแต่ตรวจจับได้น้อย
  • ตัวปรับค่า (modifier) คืออะไร: ป้ายที่ต่อท้ายคะแนนบอกว่าใครเป็นผู้ทำให้เกิดผลนั้น (P) หมายถึงผลมาจากระบบอัตโนมัติของผลิตภัณฑ์ (platform) ส่วนที่เหลือทีมขององค์กรต้องทำเอง (S/H) หมายถึงมีนักวิเคราะห์ที่เป็นคนจากบริการรวมอยู่ด้วย และ (S/AI) หมายถึง AI ทำหน้าที่เป็นนักวิเคราะห์ MITRE ระบุว่าคะแนนของ platform กับคะแนนของบริการที่มีการจัดการสะท้อนรูปแบบการทำงานคนละแบบ จึงไม่ควรเทียบกันตรง ๆ
  • ช่องว่างอยู่ตรงไหน: ผลรายเทคนิคแสดงจุดบอดของผลิตภัณฑ์ ถ้าคะแนนรวมสูงแต่มีช่องว่างในเทคนิคที่เกี่ยวกับแรนซัมแวร์ ผลิตภัณฑ์นั้นก็อาจไม่เหมาะกับความเสี่ยงขององค์กร

MITRE ระบุด้วยว่าการทดสอบนี้ไม่ได้วัดสิ่งต่อไปนี้:

  • ราคาหรือรูปแบบค่าใช้จ่าย
  • ความง่ายในการติดตั้งและหน้าตาของโปรแกรม
  • คุณภาพการสนับสนุนและเวลาตอบกลับ
  • ผลกระทบต่อความเร็วของเครื่องและเครือข่าย
  • ประสิทธิผลในสภาพแวดล้อมจริงขององค์กรเอง

MITRE ระบุว่าคะแนน TES เทียบกับผลปีก่อนหน้าไม่ได้ เพราะรอบ 2026 ใช้วิธีให้คะแนนใหม่ คำถามที่พบบ่อยยังระบุว่าในรอบ 2026 MITRE ส่งผลของผู้เข้าร่วมแต่ละรายให้เฉพาะรายนั้น และเผยแพร่เฉพาะข้อค้นพบรวม แต่หน้าอธิบายวิธีทดสอบพูดถึงผลรายเทคนิคที่เผยแพร่ ผลที่เปิดเผยจึงอาจต่างกันในแต่ละรอบ ควรถามผู้ผลิตว่าผลส่วนใดเปิดเผยแล้วและอ่านได้ที่ไหน MITRE แนะนำให้ใช้ผลทดสอบเป็นสัญญาณหนึ่ง ควบคู่กับการทดลองใช้ในสภาพแวดล้อมขององค์กรเอง การประเมินการสนับสนุน และการวิเคราะห์ต้นทุนรวม

แบบไหนเหมาะกับสถานการณ์ใด

ข้อต่อไปนี้เป็นแนวทางเริ่มต้น ไม่ใช่กฎตายตัว:

  • ทีมที่เฝ้าการแจ้งเตือนได้ตลอดเวลาและตอบสนองเองได้: EDR หรือ XDR แบบ platform (ใช้ตัวผลิตภัณฑ์อย่างเดียว ไม่รวมบริการ) อาจเพียงพอ ซึ่งตรงกับป้าย (P) ของ MITRE คำถามที่พบบ่อยของ MITRE ระบุว่า ผลิตภัณฑ์แบบ platform ล้วนที่ได้คะแนนต่ำกว่า อาจเหมาะกับองค์กรที่มี SOC (ศูนย์เฝ้าระวังและตอบสนองเหตุการณ์ความปลอดภัย) ภายในที่แข็งแรง
  • ทีม IT ขนาดเล็กที่ไม่มีใครเฝ้าตอนกลางคืนหรือวันหยุด: ควรพิจารณา MDR Cyber Centre ระบุว่าการขาดคนหรือความเชี่ยวชาญภายใน และความต้องการเฝ้าดูนอกเวลาทำงาน เป็นเหตุผลที่พบบ่อยในการใช้บริการด้านความปลอดภัยแบบมีการจัดการ
  • องค์กรที่ใช้อีเมล ระบบตัวตน และเครื่องผู้ใช้ส่วนใหญ่ของผู้ผลิตรายเดียว: native XDR ดูแลง่ายที่สุด และอาจเลือก MDR มาช่วยเฝ้าดูด้วย
  • องค์กรที่มีหลายผู้ผลิตและมีระบบเก่าที่ไม่คิดจะเปลี่ยน: พิจารณา open XDR หรือใช้ SIEM เป็นศูนย์กลาง
  • หน่วยงานที่มีกฎกำกับ หรือมีข้อมูลที่ต้องอยู่ในที่ที่กำหนด: ตรวจว่าผู้ให้บริการเก็บ log และข้อมูลไว้ที่ใด และใครเข้าถึงได้ Cyber Centre ระบุว่าที่ตั้งของข้อมูล (data residency) และการตรวจสอบการเข้าถึง เป็นปัจจัยที่ควรประเมิน

MDR เปลี่ยนว่าใครเป็นผู้ลงมือ แต่ไม่ได้เปลี่ยนว่าใครเป็นเจ้าของความเสี่ยง Cyber Centre ชี้ว่าการจ้างผู้ให้บริการคือการนำความปลอดภัยไปไว้ในมือคนนอก ขณะที่องค์กรยังเป็นเจ้าของความเสี่ยงเอง นอกจากนี้ผู้ให้บริการยังเป็นเป้าหมายที่ผู้โจมตีสนใจ เพราะการเจาะผู้ให้บริการรายเดียวอาจเข้าถึงข้อมูลของลูกค้าหลายราย ดังนั้นก่อนเกิดเหตุต้องตกลงให้ชัดว่าใครทำขั้นตอนใด

INFOGRAPHIC
เมื่อมีการแจ้งเตือน ต้องตกลงว่าใครทำขั้นไหน
01
แจ้งเตือน
เครื่องมือตรวจพบ
02
คัดกรอง
ใครดูเป็นคนแรก
03
สืบสวน
ใครหาขอบเขตเหตุ
04
ตัดเครื่อง
ใครสั่งตัดเครื่องได้
05
กู้คืน
ใครคืนระบบให้ปกติ

คำถามที่ควรถามผู้ให้บริการ

คำถามต่อไปนี้ใช้ได้กับผู้ให้บริการ EDR, XDR หรือ MDR ทุกราย รวบรวมจากแนวทางของ Cyber Centre ของแคนาดา NCSC (ศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติของสหราชอาณาจักร) และ CISA (หน่วยงานความมั่นคงปลอดภัยไซเบอร์ของสหรัฐ) เรื่องการเลือกผู้ให้บริการแบบมีการจัดการ:

  • ขอบเขต: ครอบคลุมเครื่อง บัญชี และแหล่งข้อมูลใดบ้าง และให้บริการในช่วงเวลาใด
  • ใครลงมือ: การตอบสนองแบบใดที่ผู้ให้บริการทำเองได้ (เช่น ตัดเครื่องออกจากเครือข่าย) แบบใดต้องรอองค์กรอนุมัติ และใครฝั่งองค์กรอนุมัติได้ตอนตีสาม
  • ตารางความรับผิดชอบ: มีเอกสารที่เขียนไว้ชัดเจนหรือไม่ว่าใครทำอะไร
  • ระดับการให้บริการ: เป้าหมายเวลาในการตรวจจับ ตอบสนอง และแก้ไขเป็นเท่าใด และขอดูตัวอย่าง SLA (ข้อตกลงระดับการให้บริการ) ได้หรือไม่
  • การแจ้งเหตุ: ผู้ให้บริการแจ้งองค์กรอย่างไรและเร็วแค่ไหนเมื่อเกิดเหตุ รวมถึงเหตุที่เกิดกับตัวผู้ให้บริการเอง
  • ข้อมูลขององค์กร: log และข้อมูลจากเครื่องเก็บไว้ที่ใด นานเท่าใด ใครเข้าถึงได้ และส่งออกได้หรือไม่เมื่อเลิกใช้บริการ
  • สิทธิ์ที่ผู้ให้บริการมีในระบบขององค์กร: ใช้ MFA (การยืนยันตัวตนหลายขั้นตอน) หรือไม่ ได้รับสิทธิ์เท่าที่จำเป็น (least privilege) หรือไม่ และปิดบัญชีเมื่อสิ้นสุดสัญญาหรือไม่
  • หลังเกิดเหตุ: ช่วยตรวจพิสูจน์หลักฐาน (forensics) และรับมือเหตุหรือไม่ หรือแจ้งเตือนอย่างเดียว
  • หลักฐาน: ถ้าอ้างผลของ MITRE ให้ถามว่ารอบไหน ตัวปรับค่าอะไร และเทคนิคใดเป็นช่องว่าง
INFOGRAPHIC
คำตอบของผู้ให้บริการ: แบบไหนน่าห่วง แบบไหนชัดเจน

คำตอบที่ควรระวัง

  • "เราดูแลให้ทั้งหมด" แต่ไม่ระบุขอบเขตไม่มีรายการเครื่องและเวลา
  • ไม่บอกว่าใครสั่งตัดเครื่องได้ตกลงกันตอนเกิดเหตุจริง
  • อ้างคะแนนทดสอบโดยไม่บอกที่มาไม่บอกรอบและตัวปรับค่า

คำตอบที่ชัดเจน

  • ขอบเขตและเวลาเขียนไว้ในสัญญามีตารางความรับผิดชอบ
  • ตกลงล่วงหน้าว่าตัดเครื่องเองหรือขออนุมัติเขียนไว้ก่อนเกิดเหตุ
  • บอกรอบทดสอบ ตัวปรับค่า และช่องว่างตรวจสอบได้

ข้อผิดพลาดที่พบบ่อย

  • อ่านผลทดสอบ MITRE เป็นการจัดอันดับ: MITRE ระบุว่าไม่มีการจัดอันดับและไม่มีผู้ชนะ
  • เทียบคะแนนของ platform กับคะแนนของบริการที่มีนักวิเคราะห์ตรง ๆ: MITRE ระบุว่าสะท้อนรูปแบบการทำงานคนละแบบ
  • ซื้อ EDR แล้วไม่มีใครอ่านการแจ้งเตือน: เครื่องมือที่แจ้งเตือนตอนตีสองโดยไม่มีคนเฝ้า ก็เพียงบันทึกว่าถูกโจมตี
  • เข้าใจผิดว่าจ้าง MDR แล้วความเสี่ยงย้ายไปอยู่ที่ผู้ให้บริการ: องค์กรยังเป็นเจ้าของความเสี่ยงเอง
  • ติดตั้ง agent ไม่ครบทุกเครื่อง: เครื่องที่ไม่มี agent EDR มองไม่เห็น
  • ไม่แจ้งผู้ให้บริการเมื่อมีระบบใหม่: ผู้ให้บริการมองไม่เห็นสิ่งที่ไม่ได้รับแจ้ง
  • ลืมปิดบัญชีของผู้ให้บริการเมื่อสิ้นสุดสัญญา: CISA เตือนว่าเรื่องนี้ถูกมองข้ามได้ง่ายเมื่อสัญญาสิ้นสุด

ขั้นแรกที่ทำได้ทันที

  • นับเครื่องและ agent: ทำรายการเครื่องทั้งหมด รวมเซิร์ฟเวอร์ แล้วทำเครื่องหมายเครื่องที่ติดตั้ง agent EDR แล้ว
  • กำหนดว่าใครตอบสนองนอกเวลางาน: ระบุชื่อคนหรือทีมสำหรับกลางคืนและวันหยุด และสิ่งที่ทำได้เองโดยไม่ต้องขออนุมัติ
  • ระบุสิ่งที่ต้องครอบคลุม: เครื่อง บัญชีผู้ใช้ อีเมล และบริการคลาวด์ เรียงตามความสำคัญที่องค์กรกำหนด
  • ร่างตารางความรับผิดชอบ: ใครคัดกรอง สืบสวน ตัดเครื่อง และกู้คืน สำหรับแต่ละทางเลือก NCSC ระบุว่าตารางแบบนี้เป็นแนวปฏิบัติที่ดี
  • ทดลองใช้ตัวเลือกที่คัดไว้ในสภาพแวดล้อมขององค์กรเอง: MITRE แนะนำให้ใช้ผลทดสอบเป็นสัญญาณหนึ่งควบคู่กับการทดลองจริง
  • ซ้อมหนึ่งสถานการณ์: ใช้การซ้อมรับมือเหตุ ดู วิธีป้องกันแรนซัมแวร์: 5 ขั้นตอนที่องค์กรทำได้ทันที

EDR ตรวจจับสิ่งที่หลุดเข้ามาได้ ส่วน hardening (การปรับตั้งค่าให้เครื่องเปิดช่องให้โจมตีน้อยลง) ช่วยลดสิ่งที่จะหลุดเข้ามา อ่านวิธีเริ่มได้ใน Endpoint Hardening ด้วย CIS Benchmarks เริ่มอย่างไร ถ้าต้องการวัดว่าผู้ให้บริการช่วยให้เร็วขึ้นหรือไม่ ให้ติดตาม MTTD (เวลาเฉลี่ยในการตรวจพบ) และ MTTR (เวลาเฉลี่ยในการตอบสนองหรือแก้ไข) ดูวิธีวัดใน นำ AI มาใช้ใน SOC เพื่อลด MTTD และ MTTR

หากต้องการทราบว่าการตรวจจับและตอบสนองที่เครื่องผู้ใช้ขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง

ขอบเขตและความถูกต้อง

ข้อความเกี่ยวกับ MITRE มาจากคำถามที่พบบ่อยและหน้าภาพรวมวิธีทดสอบของ ATT&CK Evaluations ตามที่อ่านเมื่อ 22 ตุลาคม 2026 โดยรอบ Enterprise 2027 ยังระบุว่าอยู่ระหว่างพัฒนา แนวทางเรื่องผู้ให้บริการมาจาก Cyber Centre ของแคนาดา (ตุลาคม 2022) NCSC ของสหราชอาณาจักร (พฤศจิกายน 2025) และคำเตือนร่วม AA22-131A ของ CISA กับหน่วยงานพันธมิตร (พฤษภาคม 2022 ปัจจุบันเป็นหน้าที่เก็บถาวร) คำอธิบาย EDR และ XDR เป็นการบรรยายทั่วไป ไม่ใช่มาตรฐาน เพราะผู้ผลิตใช้คำเหล่านี้ไม่เหมือนกัน ก่อนตัดสินใจควรยืนยันรายละเอียดล่าสุดกับผู้ผลิตแต่ละราย

เมื่อตัดสินใจจะใช้บริการ MDR แล้ว ดูขั้นตอนเลือกผู้ให้บริการได้ใน MDR: เลือกผู้ให้บริการอย่างไร

ทีมที่มี EDR แล้วสามารถใช้ข้อมูลนั้นล่าภัยคุกคามเชิงรุกได้ ดู Threat Hunting คืออะไร และเริ่มอย่างไร

เครื่องมือตรวจจับจะทำงานได้ดีขึ้นเมื่อได้รับข่าวกรองที่ผ่านการประเมินแล้ว ดู Cyber Threat Intelligence (CTI) สำหรับมือใหม่

แหล่งอ้างอิงและข้อมูลเพิ่มเติม