มี EDR หรือ Antivirus แล้ว ต้องมี Wazuh เพิ่มไหม? เทียบหน้าที่และวิธีใช้ร่วมกัน

องค์กรติดตั้ง EDR หรือ Antivirus บนเครื่องผู้ใช้ไปแล้ว แล้วทีมงานเสนอให้เพิ่ม Wazuh คำถามแรกจากผู้อนุมัติงบประมาณมักเป็น "ซ้ำซ้อนกันไหม" หรือ "ถ้าใช้ Wazuh ซึ่งเป็น open source แทน EDR ได้ จะประหยัดกว่าไหม"

บทความนี้เขียนสำหรับ CISO, IT Manager และผู้อนุมัติงบประมาณ อธิบายว่า EDR, XDR และ SIEM ต่างกันอย่างไร Wazuh ทำอะไรบนเครื่องปลายทางได้และทำอะไรไม่ได้ ใช้ร่วมกับ EDR อย่างไร และมีเช็กลิสต์สำหรับตัดสินใจ

EDR คืออะไร และทำอะไรได้บ้าง?

EDR (Endpoint Detection and Response) คือระบบความปลอดภัยที่เฝ้าดูเครื่องปลายทางอย่างต่อเนื่อง เพื่อตรวจจับและตอบสนองต่อภัยคุกคาม เช่น ransomware และ malware ตามคำอธิบายของ CrowdStrike

CrowdStrike ระบุว่าคำนี้ตั้งขึ้นโดย Anton Chuvakin จาก Gartner และยกคำอธิบายของเขา (ตามที่ CrowdStrike อ้างถึง) ว่า EDR บันทึกและจัดเก็บพฤติกรรมระดับระบบของเครื่องปลายทาง แล้วใช้เทคนิควิเคราะห์ข้อมูลหลายแบบเพื่อตรวจจับพฤติกรรมที่น่าสงสัย

ตัวอย่างจากเอกสารของ Microsoft Defender for Endpoint:

• Telemetry: เก็บข้อมูลพฤติกรรมต่อเนื่อง ทั้งข้อมูล process กิจกรรมเครือข่าย ข้อมูลเชิงลึกระดับ kernel และ memory manager การล็อกอินของผู้ใช้ และการเปลี่ยนแปลง registry กับ file system โดย Microsoft ระบุว่าเก็บข้อมูลไว้หกเดือนเพื่อให้นักวิเคราะห์ย้อนดูต้นทางของการโจมตีได้
• การตอบสนอง: Microsoft ระบุว่า Defender for Endpoint Plan 1 และ Microsoft Defender for Business มีการตอบสนองแบบสั่งเองเพียงสี่อย่าง คือ สั่งสแกน antivirus แยกเครื่อง (isolate device) หยุดและกักกันไฟล์ และเพิ่ม indicator เพื่อบล็อกหรืออนุญาตไฟล์ ความสามารถจึงขึ้นกับรุ่นของไลเซนส์
• การรวม alert: alert ที่ใช้เทคนิคเดียวกันหรือมาจากผู้โจมตีรายเดียวกันจะถูกรวมเป็น incident

Microsoft ยังเขียนไว้ในหน้าเดียวกันว่า การตรวจจับของ Defender for Endpoint ไม่ได้ออกแบบมาเป็นระบบ auditing หรือ logging ที่บันทึกทุกการทำงาน ประโยคนี้ช่วยอธิบายว่าทำไม EDR กับระบบรวม log จึงเป็นคนละหน้าที่

ในแนวทาง Eviction Strategies ของ CISA (countermeasure CM0065) เรื่องการแยกเครื่องออกจากเครือข่าย CISA ตั้งสมมติฐานว่าองค์กรใช้ซอฟต์แวร์จัดการเครื่องปลายทางหรือ EDR และยกตัวอย่าง CrowdStrike, Defender for Endpoint และ SentinelOne ว่าใช้แยกเครื่องได้อย่างรวดเร็ว

XDR และ SIEM ต่างจาก EDR อย่างไร?

EDR ดูเฉพาะเครื่องปลายทาง XDR รวมข้อมูลจากหลายแหล่งเพื่อตรวจจับและตอบสนอง ส่วน SIEM เน้นรวบรวมและวิเคราะห์ log ตามคำอธิบายของ Microsoft ซึ่งเป็นคำนิยามของผู้ผลิต ไม่ใช่มาตรฐานกลาง

• XDR (Extended Detection and Response): แพลตฟอร์มรวมที่รับข้อมูลจาก endpoint เครือข่าย Cloud อีเมล และ identity เพื่อตรวจจับ สืบสวน และตอบสนองต่อภัยคุกคาม
• EDR: Microsoft ระบุว่าจำกัดอยู่ที่ endpoint และไม่ได้ให้ภาพรวมของเครือข่าย workload บน Cloud หรือระบบ identity
• SIEM (Security Information and Event Management): รวบรวมและวิเคราะห์ log เพื่อการมองเห็นและงาน compliance แต่มักต้องเชื่อมโยงเหตุการณ์ (correlation) โดยคนแบบ manual

ตัวอย่างความสามารถระดับ XDR คือ automatic attack disruption ของ Microsoft Defender XDR ซึ่ง Microsoft ระบุว่าหยุดการโจมตีที่กำลังเกิดขึ้นได้อัตโนมัติ รวมถึงปิดบัญชีผู้ใช้ที่ถูกเจาะและแยกเครื่องที่ได้รับผลกระทบ ความสามารถนี้ขึ้นกับรุ่นของไลเซนส์

Wazuh ทำอะไรบนเครื่องปลายทางได้บ้าง?

Wazuh เน้นงานด้านการมองเห็นและสุขอนามัยของเครื่อง (visibility และ hygiene) ได้แก่ ตรวจความถูกต้องของไฟล์ ทำทะเบียนฮาร์ดแวร์และซอฟต์แวร์ ตรวจการตั้งค่า ตรวจช่องโหว่ ตรวจ malware แบบหลายชั้น และตอบสนองอัตโนมัติด้วยสคริปต์ แล้วส่งทุกอย่างเข้าศูนย์กลางเดียว

เอกสารของ Wazuh อธิบายตัวเองว่าเป็นแพลตฟอร์มความปลอดภัยแบบ free และ open source ที่รวมความสามารถ XDR และ SIEM ไว้ด้วยกัน ประกอบด้วย agent บนเครื่องปลายทาง, server ที่วิเคราะห์ข้อมูลด้วย decoder และ rule, indexer ที่จัดเก็บ alert และ dashboard สำหรับดูและวิเคราะห์ข้อมูล agent ติดตั้งได้บน Linux, Windows, macOS, Solaris, AIX และ HP-UX ณ วันที่เขียน (ตุลาคม 2026) รุ่นเสถียรล่าสุดคือ 4.14.9 ออกเมื่อ 14 ตุลาคม 2026 ส่วน Wazuh 5.0 ยังอยู่ในสถานะ pre-release

ความสามารถหลักอย่าง File Integrity Monitoring (FIM), Security Configuration Assessment (SCA), การตรวจช่องโหว่ และ MITRE ATT&CK mapping สรุปไว้แล้วใน คู่มือ Wazuh SIEM และ XDR ส่วนนี้จึงเน้นเฉพาะจุดที่เกี่ยวกับการเทียบกับ EDR

• System inventory (Syscollector): รวบรวมข้อมูลฮาร์ดแวร์ ระบบปฏิบัติการ ซอฟต์แวร์ที่ติดตั้ง network interface, port, process ที่รันอยู่ browser extension, service, ผู้ใช้และกลุ่ม และ Windows update บนเครื่อง Windows
• System calls บน Linux: ใช้ Linux Audit system (auditd) เฝ้าดู system call
• Sysmon บน Windows: เก็บได้ แต่ตามไฟล์ตั้งค่าเริ่มต้นของ agent รุ่น 4.14 ค่าเริ่มต้นบน Windows เก็บเฉพาะ log Application, Security, System และ log ของ active response จึงต้องเพิ่ม <localfile> สำหรับ channel Microsoft-Windows-Sysmon/Operational เอง (ดูรูปแบบใน เอกสาร Event logging)

Wazuh ตรวจจับ malware อย่างไร?

Wazuh ตรวจ malware แบบหลายชั้นที่อาศัยแหล่งข้อมูลประกอบ เอกสาร Malware detection ระบุชัดว่า FIM เพียงอย่างเดียวตรวจหาไฟล์อันตรายไม่ได้ ต้องใช้ร่วมกับ

• rule ตรวจจับภัยคุกคาม และ CDB list ที่เก็บ hash ของไฟล์
• การเชื่อมกับ VirusTotal และการสแกนด้วย YARA
• การตรวจพฤติกรรมของ rootkit บนเครื่องที่เฝ้าดู
• การรวบรวมและวิเคราะห์ log จากซอฟต์แวร์ตรวจ malware อื่น เช่น Windows Defender และ ClamAV

ข้อควรระวังสองข้อ:

• YARA: เมื่อ FIM พบการเปลี่ยนแปลง จะสั่งสแกน YARA ผ่าน active response สคริปต์ตัวอย่างในเอกสารสำหรับ Linux แค่บันทึกผล แต่สคริปต์ตัวอย่างสำหรับ Windows ลบทุกไฟล์ที่ตรงกับ rule ของ YARA เอกสารจึงเตือนให้เฝ้าดูเฉพาะโฟลเดอร์ที่ยอมรับการลบได้ สคริปต์นี้เป็นตัวอย่าง ไม่ใช่ค่าเริ่มต้น ควรทดสอบก่อนใช้จริง
• VirusTotal: integration นี้ส่งเฉพาะ hash ของไฟล์ที่ FIM แจ้ง ไม่ได้อัปโหลดไฟล์ เอกสารของ Wazuh ระบุว่า Public API จำกัด 500 request ต่อวันและ 4 request ต่อนาที และห้ามใช้ในผลิตภัณฑ์หรือบริการเชิงพาณิชย์ องค์กรที่จะใช้ในบริบทธุรกิจควรตรวจเงื่อนไขการใช้งานของ VirusTotal ก่อน

Active response ของ Wazuh ทำอะไรได้บ้าง?

Active response รันสคริปต์บนเครื่องปลายทางเมื่อ alert ตรงกับ rule ID, level หรือ rule group ที่กำหนด มีสองแบบ คือ stateless ที่ทำครั้งเดียว และ stateful ที่ย้อนการกระทำกลับเมื่อครบเวลาที่ตั้งไว้

ตามรายการสคริปต์เริ่มต้น ส่วนใหญ่เป็นการบล็อก IP เช่น firewall-drop, firewalld-drop, host-deny, route-null และ netsh.exe บน Windows นอกจากนั้นมี disable-account การ restart agent ตัวแจ้งเตือน Slack และ hook สำหรับ Kaspersky

เราไม่พบการแยกเครื่องออกจากเครือข่าย (host isolation) เป็นความสามารถในตัวที่มีเอกสารรองรับ หากต้องการต้องเขียนสคริปต์เอง หรือสั่งให้ EDR ที่มีอยู่เป็นผู้แยกเครื่อง

Agent ของ Wazuh ทำงานระดับไหนของระบบปฏิบัติการ?

Wazuh ระบุในบล็อกเรื่อง endpoint security แบบไม่ใช้สิทธิ์ระดับ kernel ว่า agent ทำงานใน user mode และอาศัย API ของระบบปฏิบัติการ เช่น Windows Event Log API, inotify, auditd และ journald โดยให้เหตุผลว่าลดความซับซ้อนและความเสี่ยงที่มากับการเข้าถึงระดับ kernel

ขณะที่ Microsoft ระบุว่า Defender for Endpoint เก็บข้อมูลเชิงลึกระดับ kernel และ memory manager เมื่อวางสองข้อความนี้คู่กัน เราสรุปว่าข้อมูลที่แต่ละระบบเห็นบนเครื่องเดียวกันมีความละเอียดต่างกัน ข้อสรุปนี้เป็นของเราเอง ไม่ใช่คำกล่าวของผู้ผลิตรายใด

EDR กับ Wazuh ต่างกันอย่างไร?

EDR เน้นตรวจจับเชิงพฤติกรรมและตอบสนองบนเครื่องปลายทาง ส่วน Wazuh เน้นรวม log จากหลายแหล่ง ตรวจสุขอนามัยของเครื่อง และเก็บหลักฐานสำหรับงานตรวจสอบ ตารางด้านล่างสรุปจากเอกสารที่อ้างถึงในบทความนี้ โดยใช้ Defender for Endpoint เป็นตัวอย่างของ EDR

หมายเหตุเรื่องไลเซนส์: รายละเอียดไลเซนส์แต่ละส่วน รวมถึงความต่างระหว่างรุ่น 4.x กับ 5.0 อยู่ในหัวข้อ "Wazuh ฟรีจริงไหม?" ของ คู่มือ Wazuh SIEM และ XDR หากจะแก้ไขหรือแจกจ่ายต่อ ควรให้ฝ่ายกฎหมายตรวจกับรุ่นที่ใช้จริง

มี EDR แล้ว ต้องมี Wazuh เพิ่มไหม?

ควรพิจารณาเพิ่มเมื่อองค์กรยังไม่มีชั้นรวม log หรือ SIEM กลาง หรือต้องการงานที่ EDR ไม่ได้ทำ เช่น ตรวจความถูกต้องของไฟล์บนเซิร์ฟเวอร์ ทำทะเบียนซอฟต์แวร์ ตรวจการตั้งค่า และเก็บ log ของระบบที่ EDR ไม่ครอบคลุม แต่ถ้ามี SIEM หรือ XDR ที่ทำหน้าที่เหล่านี้ครบแล้ว Wazuh อาจซ้ำซ้อน

รูปแบบที่เสริมกันคือ ให้ EDR ทำงานบนเครื่องปลายทางต่อไป และใช้ Wazuh เป็นชั้นกลางที่รับ alert จาก EDR มาดูร่วมกับ log อื่น การเชื่อมต่อขึ้นกับยี่ห้อของ EDR:

• ผลิตภัณฑ์ Microsoft Defender: Wazuh มีโมดูล ms-graph อย่างเป็นทางการ ดึง log ผ่าน Microsoft Graph ด้วย GET request จาก Defender for Endpoint, Microsoft 365 Defender, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Entra ID Protection และ Purview โดยหน้าตั้งค่าใช้สิทธิ์แบบอ่านอย่างเดียว เช่น SecurityAlert.Read.All และ SecurityIncident.Read.All โมดูลนี้ใช้รับข้อมูลเท่านั้น การสั่งตอบสนองยังทำใน console ของ Defender
• SentinelOne: มีแนวทางในบล็อกของ Wazuh ส่ง log ผ่าน syslog หรือผ่าน SentinelOne API ด้วยสคริปต์ Python เป็นคู่มือแบบ how-to ไม่ใช่โมดูลในตัว
• CrowdStrike Falcon: ณ วันที่เขียน (ตุลาคม 2026) เราไม่พบ integration อย่างเป็นทางการในเอกสารของ Wazuh และ feature request #8129 บน GitHub ยังเปิดอยู่ แนวทางที่มีคือส่ง log ในรูปแบบ syslog จาก Falcon SIEM connector แล้วเขียน decoder และ rule เอง ซึ่งเป็นวิธีจากชุมชนที่ต้องสร้างและทดสอบเอง

ใช้ EDR อย่างเดียวพอไหม?

EDR เป็นการป้องกันที่สำคัญ แต่การพึ่ง EDR อย่างเดียวมีความเสี่ยง ตัวอย่างจากรายงาน CISA AA24-326A (พฤศจิกายน 2024) ซึ่งสรุปบทเรียนจาก red team assessment ขององค์กรหนึ่ง

CISA ระบุว่าองค์กรนั้นพึ่ง EDR บนเครื่องปลายทางมากเกินไปและไม่ได้มีการป้องกันในระดับเครือข่ายที่เพียงพอ และยังพึ่ง IOC ที่รู้จักอยู่แล้วกับ EDR แทนการวิเคราะห์กิจกรรมบนเครือข่ายด้วยตัวเอง

บทเรียนนี้มาจากการประเมินองค์กรเดียว จึงไม่ได้แปลว่า EDR ใช้ไม่ได้ แต่ชี้ว่าควรมีชั้นอื่นประกอบ ระบบรวม log อย่าง Wazuh ช่วยให้ทีมวิเคราะห์ log จากอุปกรณ์เครือข่ายและระบบอื่นร่วมกับ alert จาก EDR ได้ แต่ Wazuh ไม่ได้ทดแทนการป้องกันระดับเครือข่าย การควบคุมอย่าง firewall และการแบ่งโซนเครือข่าย (segmentation) ยังเป็นอีกงานหนึ่งที่ต้องทำ

ใช้ Wazuh แทน EDR ได้ไหม?

ไม่ควรมอง Wazuh เป็นตัวแทน EDR เพราะ agent ทำงานใน user mode และเราไม่พบ host isolation ในตัวในเอกสารของ Wazuh (ณ ตุลาคม 2026) แต่ Wazuh อาจเป็นจุดเริ่มต้นที่เหมาะในบางสถานการณ์ เมื่อองค์กรยังไม่มี EDR ครอบคลุมทุกเครื่อง

• เซิร์ฟเวอร์ Linux และระบบเก่า: ต้องการมองเห็น log, system call, การเปลี่ยนแปลงไฟล์ และช่องโหว่บนเซิร์ฟเวอร์ รวมถึงระบบปฏิบัติการที่ agent ของ Wazuh รองรับ เช่น Solaris, AIX และ HP-UX ดูแนวทางดูแลระบบเก่าเพิ่มเติมใน วิธีดูแลระบบเก่าให้รันต่ออย่างปลอดภัย
• หลักฐานสำหรับงานตรวจสอบ: เอกสาร Regulatory compliance ของ Wazuh ใช้คำว่าช่วยนำข้อกำหนดด้าน compliance ไปปฏิบัติ (helps implement) สำหรับ PCI DSS, GDPR, HIPAA, NIST 800-53 และ TSC การติดตั้ง Wazuh ไม่ได้ทำให้องค์กรผ่านมาตรฐานหรือได้รับการรับรองโดยอัตโนมัติ องค์กรยังต้องมีนโยบาย กระบวนการ และผู้รับผิดชอบ และควรตรวจข้อกำหนดกับผู้ตรวจสอบหรือที่ปรึกษากฎหมาย
• ชั้นกลางก่อนเลือก EDR: เริ่มรวม log และทำทะเบียนเครื่องก่อน แล้วใช้ข้อมูลนั้นประกอบการเลือก EDR สำหรับเครื่องที่เสี่ยงที่สุด

ตัวอย่างสมมติ: องค์กรที่มี EDR บนเครื่องผู้ใช้แต่ไม่มีบนเซิร์ฟเวอร์

สถานการณ์ต่อไปนี้เป็นตัวอย่างสมมติเพื่ออธิบายวิธีคิด ไม่ใช่ผลลัพธ์จากลูกค้า สมมติองค์กรหนึ่งใช้ Defender for Endpoint บนเครื่อง Windows ของพนักงาน แต่เซิร์ฟเวอร์ Linux ที่รันระบบภายในไม่มี EDR และ log ของ firewall ไม่ได้ส่งไปที่ใดเลย

• ทีมติดตั้ง Wazuh agent บนเซิร์ฟเวอร์ Linux เปิด FIM กับโฟลเดอร์สำคัญ ใช้ SCA และ vulnerability detection
• ส่ง log ของ firewall เข้า Wazuh และเปิดโมดูล ms-graph เพื่อรับ alert จาก Defender มาดูร่วมกัน
• การแยกเครื่อง Windows ยังสั่งจาก console ของ Defender ส่วน active response ของ Wazuh ใช้เฉพาะกรณีที่ทดสอบแล้ว เช่น บล็อก IP
• กำหนดว่าใครดู alert ในเวลาทำการและนอกเวลาทำการ และ alert ระดับไหนต้องแจ้งใคร

ประเด็นคือ แต่ละเครื่องมือทำหน้าที่ที่ตัวเองถนัด และมีคนรับผิดชอบดู alert ชัดเจน

ก่อนตัดสินใจ ต้องเช็กอะไรบ้าง?

เริ่มจากสิ่งที่มีอยู่แล้ว ช่องว่างที่ยังไม่มีใครดู และคนที่จะรับ alert ไม่ใช่เริ่มจากรายชื่อเครื่องมือ

• สิ่งที่มีอยู่: EDR หรือ Antivirus ที่ใช้อยู่เป็นรุ่นไหน ครอบคลุมเครื่องกี่ประเภท (ผู้ใช้ เซิร์ฟเวอร์ Windows, Linux, ระบบเก่า) และรุ่นไลเซนส์มีการแยกเครื่องหรือไม่ Antivirus แบบดั้งเดิมอาจไม่มีความสามารถตอบสนองอย่างการแยกเครื่อง ให้ตรวจกับเอกสารของผู้ผลิต
• ชั้นรวม log: มี SIEM หรือ XDR ที่รวม log ของเซิร์ฟเวอร์ อุปกรณ์เครือข่าย Cloud และ alert จาก EDR ไว้ที่เดียวแล้วหรือยัง
• ช่องว่าง: เครื่องหรือระบบใดยังไม่มีใครเห็น log การเปลี่ยนแปลงไฟล์ ช่องโหว่ หรือการตั้งค่าที่ผิดมาตรฐาน
• การเชื่อมต่อ: EDR ที่ใช้อยู่ส่ง alert เข้า Wazuh ได้ด้วยวิธีที่มีเอกสารรองรับ หรือต้องสร้าง decoder เอง
• การตอบสนอง: การแยกเครื่อง การปิดบัญชี และการบล็อก IP สั่งจากระบบไหน ใครมีสิทธิ์สั่ง และทดสอบแล้วหรือยัง
• คนดู alert: ใครคัดกรอง alert ในเวลาทำการและนอกเวลาทำการ มีขั้นตอน escalate อย่างไร เครื่องมือที่ไม่มีคนดูช่วยได้น้อย
• Integration ภายนอก: ถ้าใช้ VirusTotal ได้ตรวจเงื่อนไขการใช้งานเชิงพาณิชย์แล้วหรือยัง
• Compliance: ข้อกำหนดที่ต้องการหลักฐานคืออะไร และใครเป็นเจ้าของนโยบายกับกระบวนการ เพราะเครื่องมือเพียงช่วยเก็บหลักฐาน

ถ้ายังไม่แน่ใจว่าควรดูแลระบบเหล่านี้ด้วยทีมภายในหรือใช้ผู้ให้บริการ อ่าน Managed Services หรือทีม IT ภายใน และถ้าจะจ้างผู้ดูแล ควรตรวจขอบเขตงานตาม เช็กลิสต์สัญญา MA และ SLA

UNIXDEV ติดตั้ง ปรับจูน rule และดูแล Wazuh ให้ทำงานร่วมกับ EDR และระบบที่องค์กรมีอยู่ ตามขอบเขตที่ตกลงกัน รวมถึงงานดูแลระบบต่อเนื่องผ่านบริการ DevOps & SRE Managed Services

แหล่งอ้างอิงและอ่านต่อ

• CrowdStrike — What is Endpoint Detection and Response (EDR)?
• Microsoft Learn — Overview of endpoint detection and response
• Microsoft — What is XDR?
• CISA — Isolate Endpoints from Network (CM0065)
• CISA — Advisory AA24-326A (red team assessment lessons learned)
• Wazuh documentation — Getting started
• Wazuh documentation — Malware detection
• Wazuh documentation — Default active response scripts
• Wazuh documentation — Monitoring Microsoft Graph API
• Wazuh documentation — VirusTotal integration
• Wazuh documentation — Detecting malware using YARA integration
• Wazuh documentation — Active response
• Wazuh documentation — Microsoft Graph API setup
• Wazuh documentation — Regulatory compliance
• Wazuh documentation — Event logging
• Wazuh blog — Endpoint security without kernel-level access
• Wazuh blog — Integrating SentinelOne XDR with Wazuh
• GitHub — wazuh/wazuh issue #8129: CrowdStrike integration
• บทความที่เกี่ยวข้อง: คู่มือ Wazuh SIEM และ XDR

บทความโดย UNIXDEV Team · 30 ตุลาคม 2026 · ข้อมูลผลิตภัณฑ์อ้างอิงเอกสารของผู้ผลิต ณ วันที่เขียน (ตุลาคม 2026) ตัวอย่างเป็นสถานการณ์สมมติ และสรุปเรื่อง compliance และไลเซนส์เพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย