SIEM + SOAR กับ XDR: ข้อดี ข้อจำกัด และคำแนะนำ

SIEM, SOAR และ XDR เป็นเครื่องมือสามแบบที่ใช้ในศูนย์ปฏิบัติการความปลอดภัย (SOC) เหมือนกัน แต่ทำหน้าที่คนละอย่าง จึงมักถูกสับสนกัน SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) เอา log จากทั่วทั้งองค์กรมาเชื่อมโยงกัน SOAR (ระบบที่ทำขั้นตอนการตอบสนองให้เป็นอัตโนมัติ) ช่วยลดงานที่ต้องทำมือ ส่วน XDR (ระบบตรวจจับและตอบสนองการโจมตีที่ครอบคลุมหลายส่วนพร้อมกัน) ตรวจจับและตอบโต้การโจมตีที่ endpoint ระบบตัวตน อีเมล และคลาวด์ โดยใช้ sensor (ตัวเก็บข้อมูลที่ติดตั้งในแต่ละส่วน) ของผู้ผลิตเอง สำหรับองค์กรส่วนใหญ่ คำถามที่แท้จริงไม่ใช่ว่าจะซื้อตัวไหน แต่คือจะวางตัวไหนเป็นศูนย์กลางก่อน และจะเพิ่มอะไรเป็นลำดับถัดไป

แต่ละตัวทำอะไร

• SIEM (security information and event management): รวบรวม log จากหลายแหล่ง เช่น ไฟร์วอลล์ เซิร์ฟเวอร์ ระบบตัวตน บริการคลาวด์ และแอปพลิเคชัน แล้วปรับให้อยู่ในรูปแบบเดียวกัน จากนั้นใช้กฎและการวิเคราะห์เชื่อมโยงเหตุการณ์ แจ้งเตือน เก็บข้อมูลไว้ใช้สืบสวน และออกรายงานสำหรับการตรวจสอบ (audit) และการปฏิบัติตามกฎระเบียบ
• SOAR (security orchestration, automation, and response): เชื่อมเครื่องมือต่าง ๆ เข้าด้วยกันผ่าน API และรัน playbook (ชุดขั้นตอนที่กำหนดไว้ล่วงหน้า) เช่น เพิ่มข้อมูลประกอบให้การแจ้งเตือน เปิด ticket หรือบล็อกที่อยู่ IP นอกจากนี้ยังมีระบบจัดการเคสเพื่อติดตามงาน SOAR ตรวจจับภัยคุกคามเองไม่ได้ แต่ลงมือทำตามการแจ้งเตือนที่เครื่องมืออื่นสร้างขึ้น
• XDR (extended detection and response): พัฒนามาจาก EDR (endpoint detection and response ระบบตรวจจับและตอบสนองบนเครื่องผู้ใช้และเซิร์ฟเวอร์) โดยเพิ่มข้อมูลจากระบบตัวตน อีเมล คลาวด์ และบางครั้งเครือข่าย (ข้อมูลเหล่านี้เรียกรวมว่า telemetry) XDR นำสัญญาณที่ได้มาเชื่อมเป็นเหตุการณ์เดียว และมีคำสั่งตอบสนองในตัว เช่น แยกเครื่องออกจากเครือข่าย ปิดบัญชี หรือกักอีเมล

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

ทำงานร่วมกันอย่างไร

ลองนึกภาพเป็นสายพานส่งต่องาน sensor สร้างข้อมูล XDR ตรวจจับและเชื่อมโยงข้อมูลในส่วนที่ตัวเองควบคุม SIEM รวบรวมข้อมูลจากแหล่งที่เหลือและเก็บบันทึกระยะยาว ส่วน SOAR ทำขั้นตอนซ้ำ ๆ ให้อัตโนมัติ เพื่อให้นักวิเคราะห์ใช้เวลาไปกับการตัดสินใจ

ข้อดีและข้อจำกัด

SIEM

• ข้อดี: มองเห็นได้กว้างที่สุด ข้ามผู้ผลิตและระบบเก่าได้ รวมถึงโครงสร้างพื้นฐานและระบบ OT (ระบบควบคุมอุปกรณ์ในโรงงานหรือโครงสร้างพื้นฐาน) ที่ติดตั้ง agent (โปรแกรมเก็บข้อมูลบนเครื่อง) ไม่ได้ เก็บและค้นข้อมูลย้อนหลังได้นาน เขียนกฎตรวจจับเองได้ยืดหยุ่น และใช้เป็นหลักฐานสำหรับการปฏิบัติตามกฎระเบียบและการตรวจสอบ
• ข้อจำกัด: คุณภาพการตรวจจับขึ้นกับข้อมูลที่นำเข้าและการปรับจูนกฎ SIEM หลายตัวคิดราคาตามปริมาณข้อมูล ค่าใช้จ่ายจึงเพิ่มขึ้นตามขนาดองค์กร ต้องมีวิศวกรที่ชำนาญคอยนำ log เข้าระบบ แยกฟิลด์ข้อมูล และดูแลกฎ และโดยลำพังทำได้แค่แจ้งเตือน ความสามารถในการลงมือตอบโต้บน endpoint มีจำกัด

SOAR

• ข้อดี: จัดการงานซ้ำ ๆ ได้สม่ำเสมอและรวดเร็ว เช่น คัดกรองอีเมลฟิชชิง (phishing) และเพิ่มข้อมูลประกอบให้การแจ้งเตือน ลดขั้นตอนที่ต้องทำมือ ช่วยลด MTTR (เวลาเฉลี่ยที่ใช้ตอบสนองและแก้ไขเหตุการณ์) และบันทึกทุกการกระทำไว้ให้ทบทวนได้
• ข้อจำกัด: ระบบอัตโนมัติขยายผลของสิ่งที่ป้อนเข้าไป ถ้าการแจ้งเตือนมีสัญญาณรบกวนมากหรือยังไม่ได้จูน ระบบอัตโนมัติก็จะรบกวนตามไปด้วย playbook ก็คือโค้ด ต้องทดสอบและปรับตามทุกครั้งที่เครื่องมือเปลี่ยน นอกจากนี้ ถ้าออกแบบการกระทำอัตโนมัติไม่ดี เช่น ปิดบัญชีผิดคน ก็อาจทำให้ระบบหยุดชะงักได้

XDR

• ข้อดี: ได้ข้อมูลเชิงลึกและกฎตรวจจับสำเร็จรูปจาก sensor ของผู้ผลิตเอง เชื่อมการแจ้งเตือนเป็นเหตุการณ์เดียวแทนการแจ้งเตือนที่กระจัดกระจาย มีคำสั่งตอบสนองในตัว และมักติดตั้งเร็วกว่าและดูแลง่ายกว่า SIEM เต็มรูปแบบ
• ข้อจำกัด: ครอบคลุมดีที่สุดกับผลิตภัณฑ์ของผู้ผลิตรายเดียวกัน ส่วนผลิตภัณฑ์ของรายอื่นอาจครอบคลุมไม่เท่ากัน ตรรกะการเชื่อมโยงมักเป็นความลับของผู้ผลิต องค์กรจึงดูหรือแก้เหตุผลที่รวมการแจ้งเตือนเข้าด้วยกันไม่ได้เสมอไป XDR ไม่ได้ออกแบบมาเป็นที่เก็บ log ทั่วไปหรือที่เก็บหลักฐานสำหรับการปฏิบัติตามกฎระเบียบ และยังมีความเสี่ยงที่จะผูกติดกับผู้ผลิตรายเดียว (vendor lock-in)

เปรียบเทียบแบบเคียงข้างกัน

• หน้าที่หลัก: SIEM ให้การมองเห็นและหลักฐาน SOAR ทำเวิร์กโฟลว์ให้อัตโนมัติ XDR ตรวจจับและตอบสนองในส่วนที่กำหนดไว้
• ขอบเขตข้อมูล: SIEM รับข้อมูลได้เกือบทุกอย่าง SOAR รับการแจ้งเตือนและข้อมูลประกอบจากเครื่องมืออื่น XDR ให้ข้อมูลละเอียดที่สุดจาก sensor ของตัวเอง
• ตรวจจับภัยคุกคาม: SIEM ตรวจจับได้ ด้วยกฎที่องค์กรต้องดูแลเอง SOAR ตรวจจับไม่ได้ ต้องพึ่งเครื่องมืออื่น XDR ตรวจจับได้ ด้วยกฎที่ผู้ผลิตดูแลให้
• การตอบสนอง: SIEM ทำได้จำกัด SOAR ทำได้ผ่านการเชื่อมต่อกับเครื่องมืออื่น XDR ทำได้ในตัวบน sensor ของตัวเอง
• การปฏิบัติตามกฎระเบียบและการเก็บข้อมูล: SIEM ทำได้ดี SOAR เก็บประวัติของแต่ละเคส XDR ทำได้จำกัด จึงต้องตรวจระยะเวลาเก็บข้อมูลให้ดี
• แรงงานและทักษะที่ต้องใช้: SIEM สูง SOAR ปานกลางถึงสูง XDR ต่ำกว่า
• ความเสี่ยงที่จะผูกติดกับผู้ผลิต: SIEM ต่ำถึงปานกลาง SOAR ปานกลาง XDR สูงกว่าสำหรับผลิตภัณฑ์แบบ native

เส้นแบ่งกำลังเลือนลง

ผู้ผลิตกำลังรวมเครื่องมือเหล่านี้เข้าด้วยกัน ชื่อผลิตภัณฑ์จึงบอกไม่ได้อีกต่อไปว่าจะได้อะไรบ้าง SIEM หลายตัวมี SOAR และการวิเคราะห์พฤติกรรมผู้ใช้มาให้ด้วย ส่วน XDR หลายตัวก็มีระบบอัตโนมัติในตัว คู่มือของ Microsoft เรื่องการย้าย Microsoft Sentinel ไปอยู่ในพอร์ทัล Defender แสดงให้เห็นทั้งข้อดีและราคาที่ต้องจ่ายของการรวมเครื่องมือ

• ประโยชน์: มีคิวเหตุการณ์เดียวและเห็นเรื่องราวการโจมตีต่อเนื่องจากข้อมูลทั้ง SIEM และ XDR อีกทั้งการจูนการแจ้งเตือนยังใช้กับการแจ้งเตือนของ SIEM ได้ด้วย
• ข้อแลกเปลี่ยน: เอนจินเชื่อมโยงของ Defender เป็นผู้กำหนดวิธีจัดกลุ่มการแจ้งเตือนและรวมเหตุการณ์ โดยใช้ตรรกะที่เป็นความลับของผู้ผลิต กฎ automation และ query เดิมอาจต้องแก้ และการอัปเดตเหตุการณ์อาจไปถึง automation ช้าไปหลายนาที

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

ควรเลือกอะไร

ไม่มีคำตอบเดียวที่ใช้ได้กับทุกองค์กร โปรไฟล์ต่อไปนี้เป็นเพียงจุดเริ่มต้น

• ทีมขนาดเล็กถึงกลาง ที่ใช้ endpoint ระบบตัวตน และอีเมลของผู้ผลิตรายเดียวเป็นหลัก: เริ่มจาก XDR และควรใช้ร่วมกับบริการ MDR (managed detection and response คือบริการที่ผู้ให้บริการภายนอกช่วยเฝ้าระวังและตอบสนองแทนทีมของเรา) จากนั้นเพิ่มที่เก็บ log แบบเบาไว้เก็บข้อมูลย้อนหลังและรองรับการปฏิบัติตามกฎระเบียบ
• องค์กรที่ถูกกำกับเข้มงวด เน้นการปฏิบัติตามกฎระเบียบ หรือมีสภาพแวดล้อมหลากหลาย (ระบบเก่า ระบบ OT ผู้ผลิตหลายราย): วาง SIEM เป็นศูนย์กลาง แล้วป้อนข้อมูลจาก XDR และ sensor อื่นเข้าไป ส่วนระบบ OT อ่านเพิ่มที่ Zero Trust กับระบบ OT
• SOC ที่มีการแจ้งเตือนจำนวนมาก: เพิ่ม SOAR หลังจากจูนการตรวจจับแล้ว โดยเริ่มจาก playbook ไม่กี่ตัวที่ทำให้นักวิเคราะห์เสียเวลามากที่สุด
• มีเครื่องมือจากหลายผู้ผลิตที่ไม่อยากเปลี่ยน: พิจารณา open XDR หรือการเชื่อมโยงข้อมูลบน SIEM และเลือกใช้รูปแบบข้อมูลแบบเปิด เช่น OCSF (รูปแบบมาตรฐานเปิดสำหรับข้อมูลความปลอดภัย) เพื่อลดการผูกติดกับผู้ผลิต

องค์กรที่พัฒนาไปถึงระดับสูงมักใช้ครบทั้งสามอย่าง XDR ตอบสนองได้เร็วและลึกในส่วนหลัก SIEM เป็นระบบบันทึกหลักและเชื่อมโยงข้อมูลข้ามแหล่ง และ SOAR ทำขั้นตอนที่อยู่ระหว่างกันให้อัตโนมัติ

แนวทางการนำไปใช้

• เริ่มจาก use case ไม่ใช่ผลิตภัณฑ์: ระบุการโจมตีที่ต้องตรวจจับให้ได้มากที่สุด เช่น แรนซัมแวร์ การขโมยข้อมูลรับรองการเข้าใช้ (credential) และฟิชชิง แล้วดูว่าแต่ละอย่างต้องใช้ข้อมูลอะไรบ้าง กรอบ MITRE ATT&CK ช่วยทำแผนที่ดูว่าครอบคลุมเทคนิคการโจมตีใดแล้วบ้าง
• จัดลำดับแหล่ง log: การนำเข้าทุกอย่างทั้งแพงและเต็มไปด้วยสัญญาณรบกวน CISA และพันธมิตรเผยแพร่แนวทาง priority logs (log ที่ควรนำเข้า SIEM ก่อน) ซึ่งครอบคลุมเครื่องมือ EDR ระบบปฏิบัติการ และอุปกรณ์คลาวด์และเครือข่าย
• จูนก่อนทำอัตโนมัติ: ลดการแจ้งเตือนผิดพลาด (false positive) ก่อน แล้วค่อยทำอัตโนมัติ เพราะการทำอัตโนมัติกับคิวแจ้งเตือนที่เต็มไปด้วยสัญญาณรบกวน มีแต่จะทำให้ผิดพลาดเร็วขึ้น
• ให้คนร่วมตัดสินใจในการกระทำที่มีผลกระทบสูง: ให้มีการอนุมัติก่อนทำสิ่งอย่างการปิดบัญชีหรือแยกเซิร์ฟเวอร์ออกจากเครือข่าย และทำอัตโนมัติเต็มรูปแบบเฉพาะขั้นตอนที่ความเสี่ยงต่ำ
• ดูแล detection และ playbook เหมือนโค้ด: ใช้ระบบเก็บเวอร์ชัน (version control) ทดสอบ ทบทวน และทดสอบซ้ำทุกครั้งที่เครื่องมือที่เชื่อมต่อเปลี่ยน
• หลีกเลี่ยงการแจ้งเตือนซ้ำ: เมื่อทั้ง XDR และ SIEM นำเข้าข้อมูลจากแหล่งเดียวกัน ให้กำหนดไว้ว่าตัวไหนเป็นผู้สร้างเหตุการณ์
• วางแผนต้นทุนและระยะเวลาเก็บข้อมูล: ประเมินปริมาณข้อมูลที่จะนำเข้า ตัดสินใจว่าข้อมูลใดต้องเก็บนาน และแบ่งชั้นการจัดเก็บตามนั้น
• วัดผล: ติดตาม MTTD (เวลาเฉลี่ยที่ใช้ตรวจพบเหตุการณ์) และ MTTR ก่อนและหลังการเปลี่ยนแปลงทุกครั้ง ตามที่อธิบายไว้ใน นำ AI มาใช้ใน SOC เพื่อลด MTTD และ MTTR

คำถามที่ควรถามผู้ผลิตทุกราย ได้แก่ แหล่งข้อมูลใดรองรับแบบ native การแจ้งเตือนเชื่อมโยงกันอย่างไรและตรวจสอบตรรกะได้หรือไม่ เก็บข้อมูลได้นานเท่าไรและราคาเท่าไร ส่งออกข้อมูลและกฎตรวจจับได้หรือไม่ และระบบอัตโนมัติจะเป็นอย่างไรเมื่อการเชื่อมต่อเปลี่ยนไป

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

องค์กรเริ่มคืบหน้าได้เลยโดยยังไม่ต้องซื้ออะไร

• ตรวจสอบเครื่องมือและไลเซนส์ที่มี: เพราะองค์กรอาจมีความสามารถของ XDR หรือ SOAR อยู่แล้ว
• ระบุ 5 สถานการณ์โจมตีสำคัญ: พร้อมข้อมูลที่ต้องใช้ตรวจจับแต่ละสถานการณ์
• ตรวจความครอบคลุมของ log: เริ่มจากระบบตัวตน endpoint อีเมล และคลาวด์ก่อน
• เลือกงานซ้ำ 1-2 อย่างมาทำอัตโนมัติ: เช่น การคัดกรองอีเมลฟิชชิง
• ซ้อมรับมือเหตุการณ์: เพื่อดูว่าการส่งต่องานระหว่างเครื่องมือติดขัดตรงไหน สำหรับขั้นตอนแรกในการรับมือแรนซัมแวร์ อ่านที่ ป้องกันแรนซัมแวร์: 5 ขั้นตอนแรก

หากต้องการรู้ว่าช่องว่างด้านความสามารถข้อใดสำคัญที่สุดสำหรับองค์กร ลองใช้ แบบประเมินตนเอง

ข้อควรระวัง

• ซื้อเครื่องมือเพื่อแก้ปัญหาที่เกิดจากกระบวนการ: ถ้าไม่มีเจ้าของงานที่ชัดเจนและไม่มีขั้นตอนส่งต่อเหตุการณ์ ซอฟต์แวร์ก็แก้ปัญหานี้ให้ไม่ได้
• ทำอัตโนมัติก่อนจูน: SOAR ที่ทำงานบนคิวแจ้งเตือนที่เต็มไปด้วยสัญญาณรบกวนจะยิ่งขยายสัญญาณรบกวนนั้น
• เข้าใจว่า XDR แทน SIEM ได้เสมอ: ในสภาพแวดล้อมที่ไม่ซับซ้อนอาจแทนได้ แต่ถ้าต้องการแหล่งข้อมูลที่กว้าง เก็บข้อมูลนาน หรือหลักฐานสำหรับการตรวจสอบ จะแทนไม่ได้
• เข้าใจว่า SIEM แทนเครื่องมือตอบสนองได้: การแจ้งเตือนยังต้องมีคนหรือระบบอัตโนมัติลงมือจัดการต่อ
• มองข้ามทักษะและต้นทุนการดำเนินงาน: ทุกแพลตฟอร์มต้องมีวิศวกรคอยดูแลให้กฎตรวจจับทันสมัยอยู่เสมอ
• ยอมรับการเชื่อมโยงแบบกล่องดำโดยไม่ทดสอบ: ควรตรวจสอบด้วยการจำลองการโจมตีที่สมจริง

เมื่อเลือกเครื่องมือแล้ว ควรทดสอบว่าตรวจจับการโจมตีได้จริงด้วยการซ้อมและการจำลองสถานการณ์ อ่านต่อที่ Network & Cyber Security Simulator: ประเภทและการใช้งาน

log จาก domain controller (เซิร์ฟเวอร์ที่ตรวจสอบการ login ของผู้ใช้ในเครือข่ายองค์กร) และ identity provider (ระบบกลางที่ยืนยันตัวตนผู้ใช้) เป็นข้อมูลสำคัญที่ SIEM หรือ XDR ควรมี หากสนใจการตรวจจับที่เน้นเรื่องตัวตน อ่านที่ ITDR: ตรวจจับและตอบสนองการโจมตีที่เล็งตัวตน

ข้อมูลจากเครือข่ายก็เป็นอีกแหล่งหลักฐานที่ป้อนให้ SIEM หรือ XDR ได้ ดูว่าการวิเคราะห์ทราฟฟิกเครือข่ายช่วยตรวจจับอะไรได้บ้างที่ NDR (Network Detection and Response) คืออะไร

ไฟร์วอลล์เป็นหนึ่งในแหล่ง log ที่ส่งเข้า SIEM บ่อยที่สุด ส่วนความแตกต่างระหว่าง NGFW, UTM และ WAF อ่านได้ที่ NGFW, UTM และ WAF ต่างกันอย่างไร และเลือกอย่างไร

หากต้องการดูว่าเครื่องมือเหล่านี้ประกอบกันเป็น SOC ของหน่วยงานภาครัฐได้อย่างไร อ่านต่อที่ SOC Architecture Blueprint สำหรับหน่วยงานภาครัฐ

ถ้าต้องการเลือกระหว่างเครื่องมือที่เริ่มจากเครื่องผู้ใช้กับบริการที่มีทีมเฝ้าดูแทน ดู EDR, XDR และ MDR ต่างกันอย่างไร

SIEM จะตรวจจับได้เท่าที่มี log ส่งเข้ามา ดูว่าควรส่ง log คลาวด์อะไรใน Cloud Logging และ Detection: ต้องเก็บ log อะไร

หลังเลือกเครื่องมือแล้ว ยังต้องตัดสินว่าใครจะเป็นผู้ดูแลเครื่องมือเหล่านั้น ดู SOC ทำเอง, MSSP หรือ Hybrid: เลือกอย่างไร

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

การล่าภัยคุกคามเป็นงานที่ทำต่อยอดจากข้อมูลใน SIEM และ XDR ดู Threat Hunting คืออะไร และเริ่มอย่างไร

ก่อนเลือกเครื่องมือ ควรรู้ก่อนว่าจะส่ง log อะไรเข้าไป และเก็บนานเท่าไร ดู Log Management: ต้องเก็บ log อะไร นานเท่าไร

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

• CISA: Guidance for SIEM and SOAR implementation: แนวทางสำหรับผู้บริหารและผู้ปฏิบัติงาน รวมถึงรายการ log ที่ควรนำเข้า SIEM ก่อน
• Microsoft Learn: การย้าย Microsoft Sentinel ไปพอร์ทัล Defender: ตัวอย่างการรวม SIEM และ XDR พร้อมข้อจำกัด
• NIST glossary: SIEM tool
• NIST SP 800-92: Guide to Computer Security Log Management
• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• MITRE ATT&CK: ใช้จับคู่ความครอบคลุมการตรวจจับกับเทคนิคของผู้โจมตี
• OCSF: Open Cybersecurity Schema Framework: รูปแบบข้อมูลแบบเปิดสำหรับข้อมูลความปลอดภัย
• TechTarget: SIEM vs. SOAR vs. XDR