ไทย
English
หลายองค์กรลงทุนกับ SIEM เพราะเชื่อว่าเมื่อมีระบบรวม Log และแจ้งเตือนภัยคุกคามแล้ว จะสามารถมองเห็นเหตุการณ์ด้านความปลอดภัยได้ชัดเจนขึ้น แต่ในความเป็นจริง หลายทีมยังคงเจอคำถามเดิมซ้ำ ๆ ว่า เกิดอะไรขึ้น?เริ่มจากตรงไหน? กระทบระบบใดบ้าง? หรือเราควรทำอะไรก่อน? ซึ่งปัญหาเหล่านี้อยู่ที่ว่าองค์กรใช้ SIEM อย่างไร ออกแบบข้อมูลอย่างไร และมีความพร้อมในการวิเคราะห์เหตุการณ์มากแค่ไหน
SIEM คืออะไร?
SIEM หรือ Security Information and Event Management คือระบบที่ช่วยรวบรวม วิเคราะห์ และแจ้งเตือนเหตุการณ์จากแหล่งข้อมูลต่าง ๆ เช่น Firewall, Endpoint, Server, Cloud, Application และ Identity System อย่างไรก็ตาม SIEM เป็นเพียงเครื่องมือไม่ใช่ระบบที่สามารถทำความเข้าใจได้โดยอัตโนมัติ
หลายองค์กรลงทุนใน SIEM แล้ว แต่ยังไม่รู้ว่าเกิดอะไรขึ้น เพราะ SIEM เป็นเพียงแพลตฟอร์มสำหรับรวบรวม วิเคราะห์ และแจ้งเตือนข้อมูล Log เท่านั้น คุณค่าที่แท้จริงจะเกิดขึ้นเมื่อมีการออกแบบ Use Case, ปรับแต่ง Rule, เชื่อมโยงข้อมูล, ทำ Data Normalization และกำหนด Incident Response Workflow ที่เหมาะสม
หากขาดองค์ประกอบเหล่านี้ SIEM อาจกลายเป็นเพียงคลังเก็บข้อมูลขนาดใหญ่ที่เต็มไปด้วย Alert แต่ไม่สามารถอธิบายภาพรวมของเหตุการณ์หรือช่วยให้องค์กรตอบสนองต่อภัยคุกคามได้อย่างมีประสิทธิภาพ
สาเหตุที่พบบ่อย ได้แก่
- มี Log เยอะ แต่ไม่มี Context
หลายองค์กรเข้าใจว่าการเก็บ Log ให้มากที่สุดคือแนวทางที่ปลอดภัยที่สุด แต่ Log จำนวนมากไม่ได้แปลว่ามี Visibility ที่ดีเสมอไป
| เก็บ Log เยอะ ไม่ได้แปลว่า Detect ได้ดี
ตัวอย่างเช่น SIEM อาจเห็นว่า User หนึ่ง Login สำเร็จจากต่างประเทศ เห็นว่ามีการเข้าถึงไฟล์จำนวนมาก และเห็นว่ามีการเชื่อมต่อไปยัง IP ภายนอก แต่ถ้าข้อมูลเหล่านี้ไม่ถูกเชื่อมโยงกัน ระบบอาจมองเป็นเหตุการณ์แยกกันไม่ใช่การโจมตีต่อเนื่องหนึ่งชุด
สิ่งที่องค์กรต้องการไม่ใช่แค่ Log แต่คือ Context เช่น ใครเป็นเจ้าของบัญชีนี้ ระบบนั้นสำคัญแค่ไหน พฤติกรรมนี้ผิดปกติหรือไม่ และเหตุการณ์นี้สัมพันธ์กับ Alert อื่นอย่างไร
- Alert มากเกินไปจนทีมมองไม่เห็นเรื่องสำคัญ
SIEM ที่ไม่ได้ปรับแต่งอย่างเหมาะสมมักสร้าง Alert จำนวนมากเกินไป จนทีม Security ต้องใช้เวลาส่วนใหญ่กับ False Positive หรือเหตุการณ์ที่มีความเสี่ยงต่ำ
เมื่อ Alert มีมากเกินไป ทีมจะเริ่มเกิดอาการ Alert Fatigue คือเห็นการแจ้งเตือนจนชิน และอาจพลาดสัญญาณสำคัญที่ซ่อนอยู่ในกองข้อมูล
ปัญหานี้ทำให้องค์กรมีการแจ้งเตือนแต่ไม่มีการจัดลำดับความสำคัญว่าเหตุการณ์ใดต้องตอบสนองทันที เหตุการณ์ใดต้องเฝ้าระวัง และเหตุการณ์ใดเป็นเพียง Noise
- Use Case ไม่สอดคล้องกับความเสี่ยงจริงของธุรกิจ
SIEM ที่ดีควรเริ่มจากคำถามว่าองค์กรต้องการตรวจจับอะไรไม่ใช่เริ่มจากเรามี Log อะไรบ้าง แต่หลายองค์กรติดตั้ง SIEM แล้วใช้ Rule สำเร็จรูปเป็นหลัก โดยไม่ได้ปรับให้เข้ากับสภาพแวดล้อมจริง เช่น ระบบสำคัญของธุรกิจ รูปแบบการทำงานของผู้ใช้ ช่องทางโจมตีที่มีความเสี่ยงสูง หรือข้อกำหนดด้าน Compliance
ผลลัพธ์คือ SIEM อาจตรวจจับเหตุการณ์ทั่วไปได้ แต่พลาดเหตุการณ์ที่สำคัญต่อองค์กรจริง ๆ เช่น การเข้าถึงข้อมูลลูกค้าโดยบัญชีภายใน การใช้สิทธิ์ Admin นอกเวลางาน หรือพฤติกรรมผิดปกติในระบบ Cloud
- ข้อมูลไม่ครบ ทำให้ตรวจสอบต่อไม่ได้
บางครั้ง SIEM แจ้งเตือนว่ามีเหตุการณ์ผิดปกติ แต่เมื่อต้องตรวจสอบหรือ investigate ทีมกลับไม่มีข้อมูลเพียงพอ เช่น ไม่มี Endpoint Telemetry, ไม่มี DNS Log, ไม่มี Cloud Audit Log, ไม่มี Identity Log หรือไม่มีรายละเอียดของ Network Session เมื่อข้อมูลขาดหาย การตอบคำถามพื้นฐานจึงทำได้ยาก เช่น
- เหตุการณ์เริ่มเมื่อไหร่
- บัญชีใดถูกใช้งาน
- เครื่องใดได้รับผลกระทบ
- ผู้โจมตีเคลื่อนที่ต่อไปที่ไหน
- ข้อมูลถูกดึงออกไปหรือไม่
นี่คือเหตุผลที่บางองค์กรมี SIEM แต่ยังไม่สามารถตอบ Incident ได้อย่างมั่นใจ
- ไม่มีคนและกระบวนการรองรับ
SIEM ไม่สามารถทำงานแทนทีม Security ได้ทั้งหมด องค์กรยังต้องมีคนที่เข้าใจการวิเคราะห์ Log, Threat Detection, Incident Response และสภาพแวดล้อมของธุรกิจ หากไม่มี Playbook ที่ชัดเจน เมื่อ Alert เกิดขึ้น ทีมอาจไม่รู้ว่าต้องตรวจสอบอะไรต่อ ติดต่อใคร ปิดกั้นอย่างไร หรือ Escalate เมื่อไหร่ สุดท้าย SIEM จึงกลายเป็นระบบที่แจ้งเตือน แต่ไม่ได้นำไปสู่การตอบสนองอย่างมีประสิทธิภาพ
- ไม่ได้ปรับปรุงต่อเนื่อง
ภัยคุกคามมีการเปลี่ยนแปลงตลอดเวลา ระบบใหม่ถูกเพิ่มเข้ามา ผู้ใช้เปลี่ยนพฤติกรรม และองค์กรย้าย Workload ไปยัง Cloud มากขึ้น หาก SIEM ไม่ถูกปรับปรุงอย่างสม่ำเสมอ Detection Rule ก็จะค่อย ๆ ล้าสมัย SIEM ที่เคยมีประสิทธิภาพเมื่อปีที่แล้ว อาจไม่เพียงพอกับความเสี่ยงของวันนี้ องค์กรจึงควรมีการ Review Use Case, Tune Rule, ตรวจสอบ Data Source และทำ Lessons Learned หลัง Incident อย่างต่อเนื่อง
แล้วองค์กรควรพิจารณาทำอย่างไร
การมี SIEM ให้เกิดผลจริงควรเริ่มจากการเปลี่ยนมุมมอง จากติดตั้งระบบเป็นสร้างความสามารถในการตรวจจับและตอบสนอง
สิ่งที่ควรให้ความสำคัญ ได้แก่ การกำหนด Use Case ตามความเสี่ยงของธุรกิจ การเลือก Data Source ที่จำเป็น การเพิ่ม Context ให้กับข้อมูล การลด False Positive การจัดลำดับความสำคัญของ Alert และการสร้าง Playbookสำหรับ Incident Response
นอกจากนี้ ควรวัดผล SIEM ด้วยคำถามที่สะท้อนความสามารถจริง เช่น ตรวจจับเหตุการณ์สำคัญได้เร็วแค่ไหน ใช้เวลาสืบสวนนานเท่าไร Alert ใดมีคุณภาพต่ำ และทีมสามารถตอบได้หรือไม่ว่าเหตุการณ์หนึ่งส่งผลกระทบอะไรบ้าง
SIEM ไม่ได้ล้มเหลวเพราะเป็นเทคโนโลยีที่ไม่ดี แต่หลายครั้งล้มเหลวเพราะองค์กรคาดหวังว่าเครื่องมือจะสร้างความเข้าใจให้เอง การรู้ว่าเกิดอะไรขึ้นต้องอาศัยมากกว่า Log และ Alert ต้องมีบริบท (Context) ข้อมูลที่ครบถ้วนUse Case ที่ตรงกับความเสี่ยง คนที่วิเคราะห์เป็น และกระบวนการตอบสนองที่ชัดเจน
SIEM ที่มีประสิทธิภาพควรถูกออกแบบให้เป็นศูนย์กลางในการตรวจจับ วิเคราะห์ จัดลำดับความสำคัญ และสนับสนุนการตอบสนองต่อภัยคุกคามอย่างเป็นระบบ ซึ่งสิ่งสำคัญคือ องค์กรต้องรู้ก่อนว่า ต้องการตรวจจับอะไร ระบบใดสำคัญ พฤติกรรมใดถือว่าผิดปกติ ความเสี่ยงใดต้องตอบสนองก่อน และข้อมูลใดจำเป็นต่อการตรวจสอบเหตุการณ์ จากนั้นจึงนำสิ่งเหล่านี้มาออกแบบเป็น Use Case, Rule, Policy, Correlation และ Playbook ที่เหมาะกับสภาพแวดล้อมจริงขององค์กร เพราะแต่ละองค์กรมีระบบงาน ผู้ใช้งาน ความเสี่ยง และข้อกำหนดด้าน Compliance ที่แตกต่างกัน การปรับแต่ง SIEM ให้เข้าใจบริบทขององค์กรจึงเป็นสิ่งสำคัญที่จะช่วยลด False Positive เพิ่มความแม่นยำในการตรวจจับ และทำให้ทีม Security มองเห็นเหตุการณ์ที่สำคัญจริงได้เร็วขึ้น
บริการ SIEM จาก BMSP
BMSP สามารถช่วยองค์กรของคุณออกแบบ ปรับแต่ง และพัฒนา SIEM Use Case, Detection Rule, Policy และ Playbook ให้สอดคล้องกับความเสี่ยงทางธุรกิจ สภาพแวดล้อมด้าน IT, Cloud, Identity และ Security Operation ขององค์กร
ไม่ว่าจะเป็นการเริ่มต้นใช้งาน SIEM การปรับแต่ง Rule ที่มีอยู่ การลด Alert Noise การเพิ่ม Context ให้กับการตรวจจับ หรือการวางกระบวนการ Incident Response ให้มีประสิทธิภาพมากขึ้น BMSP พร้อมช่วยให้องค์กรของคุณเปลี่ยน SIEM จากระบบเก็บ Log ให้กลายเป็นเครื่องมือสำคัญในการตรวจจับและตอบสนองภัยคุกคาม
