คู่มือรับมือการโจมตีไซเบอร์ด้วย SIEM: เลือก Use Case และบริการให้เหมาะกับองค์กร

SIEM ช่วยให้องค์กรเชื่อมโยง Log จากหลายระบบเพื่อค้นหาสัญญาณโจมตีและจัดลำดับการตอบสนองได้ดีขึ้น แต่ควรเริ่มจาก Use Case ที่เสี่ยงสูง ไม่ใช่เปิดรับ Alert ทุกประเภทพร้อมกัน
การเลือกติดตั้ง SIEM ภายใน ใช้ Managed SIEM หรือ Managed SOC ควรดูความพร้อมของทีม ปริมาณ Log และ SLA การตอบสนองเป็นหลัก
ภัยอย่าง Phishing, Ransomware และการเดารหัสผ่านมักทิ้งร่องรอยไว้ในระบบ Identity, Endpoint, Firewall, Cloud และอีเมล หากเก็บ Log ที่เกี่ยวข้องอย่างครบถ้วน
การลงทุนจะคุ้มค่ากว่าเมื่อองค์กรกำหนดทรัพย์สินสำคัญ เจ้าของ Alert และขั้นตอนรับมือเหตุการณ์ไว้ก่อน
ก่อนเปรียบเทียบแพลตฟอร์ม SIEM หรือขอใบเสนอราคาบริการ Managed SOC ควรใช้เช็กลิสต์ด้านล่างเพื่อตรวจสอบขอบเขตงานที่ต้องการจริง

ดูภาพรวมอย่างรวดเร็ว

• เริ่มจาก Use Case ความเสี่ยงสูง เช่น การยึดบัญชีอีเมล การล็อกอินผิดปกติ และพฤติกรรมที่อาจนำไปสู่ Ransomware
• คุณภาพ Log สำคัญกว่า Alert จำนวนมาก ต้องตั้งเวลาให้ตรงกัน กำหนดสิทธิ์เข้าถึง และเชื่อมต่อแหล่งข้อมูลที่เกี่ยวข้อง
• SIEM ไม่ได้ป้องกันเหตุได้เองทั้งหมด ต้องมีผู้คัดกรอง แจ้งเตือน และดำเนินการตาม Playbook ที่ชัดเจน

แนวทาง	เหมาะกับใคร	สิ่งที่ต้องพร้อม	จุดที่ควรถามก่อนขอใบเสนอราคา
ดูแล SIEM ภายในองค์กร	องค์กรที่มีทีมความปลอดภัยและผู้ดูแลระบบพร้อมทำงานต่อเนื่อง	ทีมวิเคราะห์ Alert, การปรับ Use Case, ขั้นตอนตอบสนองเหตุการณ์	ความสามารถในการเชื่อมต่อ Log, การจัดเก็บข้อมูล, ภาระดูแลและปรับแต่ง
Managed SIEM	องค์กรที่ต้องการแพลตฟอร์มและการช่วยดูแลระบบ แต่ยังคงบทบาทการตอบสนองไว้ภายใน	ผู้รับผิดชอบตรวจสอบ Alert และตัดสินใจเมื่อเกิดเหตุ	ขอบเขตการติดตั้ง, Onboarding, แหล่ง Log ที่รองรับ และหน้าที่ของแต่ละฝ่าย
Managed SOC	องค์กรที่มีทีมจำกัด หรือต้องการการเฝ้าระวังและคัดกรองเหตุการณ์ตาม SLA	ช่องทางติดต่อฉุกเฉิน ผู้มีอำนาจอนุมัติ และ Playbook ร่วมกับผู้ให้บริการ	SLA การแจ้งเหตุ, การคัดกรอง, การส่งต่อเหตุ และความรับผิดชอบเมื่อพบความเสี่ยง

SIEM ช่วยรับมือเหตุโจมตีได้อย่างไร: คำตอบสั้นสำหรับผู้ดูแลระบบ

SIEM รวบรวม Log และเหตุการณ์จากหลายแหล่ง เช่น Firewall, Endpoint, ระบบจัดการบัญชีผู้ใช้, Cloud และแอปพลิเคชัน แล้ววิเคราะห์ความสัมพันธ์ของเหตุการณ์เพื่อค้นหาพฤติกรรมที่ควรตรวจสอบต่อ จุดสำคัญไม่ใช่การมีข้อมูลมากที่สุด แต่คือการมีข้อมูลที่เชื่อมโยงกับความเสี่ยงของธุรกิจได้จริง

เริ่มจากทรัพย์สินสำคัญและเหตุการณ์ที่กระทบธุรกิจ

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

แนวทางนี้ช่วยลดปัญหาการเปิด Alert จำนวนมากโดยไม่มีลำดับความสำคัญ และช่วยให้ทีม SOC หรือผู้ให้บริการ Managed Security Service เข้าใจบริบทขององค์กรได้เร็วขึ้น

ลำดับการทำงาน: เก็บ Log วิเคราะห์ แจ้งเตือน และตอบสนอง

กระบวนการที่ใช้งานได้จริงควรมีลำดับชัดเจน: เก็บ Log จากแหล่งที่จำเป็น ตรวจสอบความถูกต้องของเวลาและข้อมูล วิเคราะห์ตาม Use Case แจ้งเตือนผู้รับผิดชอบ คัดกรองเหตุการณ์ และดำเนินการตามขั้นตอนตอบสนอง เช่น ตรวจสอบบัญชี กักกัน Endpoint หรือส่งต่อให้ทีมที่มีอำนาจตัดสินใจ

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

ข้อจำกัดที่ SIEM ไม่สามารถแก้ได้ด้วยตัวเอง

SIEM เพียงอย่างเดียวไม่รับประกันว่าจะป้องกันหรือหยุดการโจมตีได้ เพราะผลลัพธ์ขึ้นกับแหล่งข้อมูลที่เชื่อมต่อ คุณภาพของ Use Case และทักษะของผู้ปฏิบัติงาน หากไม่มี Playbook หรือไม่มีผู้ตรวจสอบ Alert ที่ชัดเจน เหตุการณ์สำคัญอาจถูกปล่อยค้างแม้ระบบจะแจ้งเตือนแล้วก็ตาม

ตารางจับคู่ภัยคุกคามกับ Use Case, แหล่ง Log และความเร่งด่วน

ประเภทภัยคุกคาม	Use Case ที่ควรพิจารณา	แหล่ง Log ที่เกี่ยวข้อง	แนวทางตอบสนองเบื้องต้น
Phishing และการยึดบัญชีอีเมล	การล็อกอินผิดปกติ การเปลี่ยนสิทธิ์หรือพฤติกรรมบัญชีที่ไม่สอดคล้องกับปกติ	Identity System, ระบบอีเมล, Cloud และ Firewall	ตรวจสอบบัญชีและกิจกรรมที่เกี่ยวข้อง ส่งต่อเหตุการณ์ตามระดับความเสี่ยง
Ransomware	การใช้บัญชีผิดปกติ การเปลี่ยนสิทธิ์ และกิจกรรม Endpoint ที่ต่างจากพฤติกรรมเดิม	Endpoint, Identity System, Firewall และระบบที่เกี่ยวข้อง	คัดกรองเหตุ กักกันตาม Playbook และแจ้งผู้รับผิดชอบ
Brute Force และ Password Spraying	การล็อกอินล้มเหลวซ้ำ ๆ หรือการพยายามเข้าหลายบัญชีจากแหล่งที่มาผิดปกติ	Identity System, Cloud, Firewall และแอปพลิเคชัน	ตรวจสอบแหล่งที่มา บัญชีเป้าหมาย และรูปแบบการเข้าถึง
Data Exfiltration และ Insider Threat	การเข้าถึงหรือใช้งานข้อมูลที่ไม่สอดคล้องกับบทบาทและพฤติกรรมปกติ	แอปพลิเคชัน, Cloud, Endpoint, Identity System	ตรวจสอบสิทธิ์ ขอบเขตข้อมูล และส่งต่อให้เจ้าของข้อมูลหรือทีมความปลอดภัย

Phishing และการยึดบัญชีอีเมล

Phishing อาจนำไปสู่การขโมยข้อมูลบัญชี การเข้ายึดอีเมล หรือใช้เป็นจุดเริ่มต้นเข้าสู่ระบบภายใน Use Case ที่มีประโยชน์ควรมองหาความสัมพันธ์ระหว่างกิจกรรมการล็อกอิน การเปลี่ยนแปลงบัญชี และเหตุการณ์จากระบบอีเมลหรือ Cloud ไม่ควรตัดสินจาก Alert เดี่ยวโดยไม่มีบริบท

Ransomware และพฤติกรรมผิดปกติบน Endpoint

ก่อนเกิดการเข้ารหัสข้อมูล อาจพบสัญญาณอย่างการใช้บัญชีผิดปกติ การเปลี่ยนสิทธิ์ หรือกิจกรรมบน Endpoint ที่ต่างจากพฤติกรรมปกติ จึงควรเชื่อมต่อ Log ของ Endpoint เข้ากับ Identity System เพื่อดูว่าใครทำอะไร บนเครื่องใด และเกิดขึ้นในช่วงเวลาใด

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

Brute Force, Password Spraying และการเข้าถึงจากตำแหน่งเสี่ยง

การโจมตีแบบ Brute Force และ Password Spraying มักแสดงเป็นการล็อกอินล้มเหลวซ้ำ ๆ หรือความพยายามเข้าถึงหลายบัญชีจากแหล่งที่มาผิดปกติ SIEM สามารถช่วยรวมรูปแบบที่กระจายอยู่ในหลายระบบให้เห็นเป็นเหตุการณ์เดียวได้

ควรกำหนด Use Case ให้แยกความสำคัญของบัญชี เช่น บัญชีทั่วไปกับบัญชีที่มีสิทธิ์สูง เพื่อให้ทีมตอบสนองต่อเหตุที่มีผลกระทบมากก่อน

Data Exfiltration และ Insider Threat

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

ประเมินความคุ้มค่า: ดูแล SIEM เองหรือใช้ Managed SOC

การเปรียบเทียบแพลตฟอร์ม SIEM ไม่ควรดูเพียงความสามารถของเครื่องมือ ควรประเมิน คน เวลา และความต่อเนื่องในการปฏิบัติการ ด้วย องค์กรที่มีเครื่องมือครบแต่ไม่มีผู้ดูแล Use Case และ Alert อย่างสม่ำเสมอ อาจยังมีช่องว่างในการตรวจจับเหตุการณ์

เปรียบเทียบทีมงาน ความพร้อม 24/7 และภาระการปรับแต่ง Use Case

การดูแลเองทำให้องค์กรควบคุมลำดับความสำคัญและบริบทภายในได้มาก แต่ต้องมีทีมสำหรับตรวจสอบ Alert ปรับ Use Case และประสานงานเมื่อเกิดเหตุ ส่วน Managed SIEM หรือ Managed SOC อาจเหมาะเมื่อทีมภายในมีข้อจำกัดด้านเวลาและบุคลากร โดยควรแยกให้ชัดว่าผู้ให้บริการทำหน้าที่เฝ้าระวัง คัดกรอง แจ้งเตือน หรือช่วยตอบสนองในระดับใด

ต้นทุนที่ควรถามในใบเสนอราคา: ปริมาณ Log, การเก็บข้อมูล, Onboarding และ SLA

ค่าใช้จ่ายของ SIEM และ Managed SOC แตกต่างตามปริมาณข้อมูล ระยะเวลาการเก็บรักษา จำนวนอุปกรณ์ และขอบเขตบริการ ดังนั้นก่อนขอใบเสนอราคา ควรถามให้ครบเกี่ยวกับ ปริมาณ Log ที่รองรับ การจัดเก็บข้อมูล ขั้นตอน Onboarding การปรับ Use Case และ SLA รวมถึงเงื่อนไขการแจ้งเหตุและการส่งต่อให้ทีมภายใน

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

เมื่อใดควรเริ่มจากบริการภายนอกแทนการสร้าง SOC เต็มรูปแบบ

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

ขั้นตอนตั้งค่าเพื่อลดความเสี่ยงและลด Alert ที่ไม่จำเป็น

เป้าหมายของการตั้งค่า SIEM ไม่ใช่การทำให้มี Alert มากที่สุด แต่คือการทำให้ Alert ที่เกิดขึ้นมีความหมายและสามารถดำเนินการต่อได้ การเริ่มต้นเป็นลำดับช่วยลดภาระทั้งทีมไอทีและทีม SOC

จัดลำดับการเชื่อมต่อ Log จาก Identity, Endpoint, Firewall และ Cloud

สำหรับองค์กรที่เริ่มต้นจากงบประมาณจำกัด สามารถจัดลำดับ Use Case ตามความเสี่ยงก่อน โดยให้ความสำคัญกับ Log จาก Identity System, Endpoint, Firewall และ Cloud เพราะเกี่ยวข้องกับการล็อกอิน การใช้บัญชี การเชื่อมต่อ และกิจกรรมในสภาพแวดล้อมที่ใช้งานจริง

ก่อนเพิ่มแหล่ง Log ใหม่ ควรตรวจสอบว่า Log เดิมถูกส่งเข้าระบบครบถ้วนหรือไม่ มีข้อมูลสำคัญเพียงพอหรือไม่ และใช้สร้างการตรวจจับที่ตอบโจทย์ได้จริงหรือไม่

กำหนด Baseline และเกณฑ์แจ้งเตือนตามความเสี่ยง

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

หากพบ Alert ลวงบ่อย ควรย้อนดูเงื่อนไข Use Case และคุณภาพข้อมูล แทนการปิดกฎทิ้งทันที เพราะอาจทำให้สูญเสียความสามารถในการมองเห็นเหตุที่สำคัญ

สร้าง Playbook สำหรับคัดกรอง กักกัน และส่งต่อเหตุการณ์

ทุก Use Case สำคัญควรมี Playbook ระบุว่าใครเป็นผู้รับ Alert ต้องตรวจสอบข้อมูลใดก่อน ระดับใดที่ต้องกักกันหรือส่งต่อ และใครเป็นผู้ตัดสินใจขั้นสุดท้าย Playbook ที่ดีช่วยลดเวลาสับสนเมื่อเกิดเหตุ และทำให้การทำงานร่วมกันระหว่างทีมภายในกับ Managed SOC มีความชัดเจน

ข้อผิดพลาดที่ควรหลีกเลี่ยงในการเก็บรักษาและเข้าถึง Log

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

แนวทางตามขนาดและสภาพแวดล้อมขององค์กร

ธุรกิจขนาดเล็กที่มีทีมไอทีจำกัด

ควรเริ่มจาก Use Case ที่มีผลกระทบสูงและแหล่ง Log หลักก่อน เช่น Identity, Endpoint และ Firewall หลีกเลี่ยงการเชื่อมต่อทุกระบบโดยไม่มีผู้ดูแล เพราะจะเพิ่ม Alert และภาระจัดการโดยไม่จำเป็น หากทีมไม่พร้อมตรวจสอบต่อเนื่อง ควรพิจารณาขอบเขตของ Managed SIEM หรือ Managed SOC ที่ตรงกับหน้าที่ที่ยังขาด

องค์กรที่ใช้ Cloud และ SaaS หลายระบบ

องค์กรลักษณะนี้ควรวางแผนการเชื่อมต่อ Log จาก Cloud, Identity System และแอปพลิเคชันให้เห็นความสัมพันธ์ของการเข้าถึงบัญชีและข้อมูล อย่าตัดสินใจเลือกเครื่องมือจากรายการฟีเจอร์เพียงอย่างเดียว ควรตรวจสอบว่าแพลตฟอร์มรองรับแหล่ง Log ที่ใช้อยู่จริงหรือไม่

องค์กรที่มีข้อกำหนดด้านข้อมูลและการตรวจสอบสูง

ควรให้ความสำคัญกับการจัดเก็บ Log การกำหนดสิทธิ์เข้าถึง และการตรวจสอบย้อนกลับ รวมถึงระยะเวลาเก็บข้อมูลที่เหมาะกับข้อกำหนดขององค์กรหรือหน่วยงานที่เกี่ยวข้อง รายละเอียดเหล่านี้ควรระบุในขอบเขตโครงการและใบเสนอราคาให้ชัดเจนก่อนเริ่มติดตั้ง

เกณฑ์เลือก SIEM และบริการเฝ้าระวัง: สรุปก่อนตัดสินใจ

เช็กลิสต์ความเข้ากันได้กับระบบเดิมและแหล่ง Log

ตรวจสอบว่า SIEM หรือบริการที่พิจารณาสามารถรับ Log จากระบบ Identity, Endpoint, Firewall, Cloud และแอปพลิเคชันที่องค์กรใช้งานอยู่ได้หรือไม่ พร้อมถามวิธีรับข้อมูล ขอบเขตการตั้งค่า และหน้าที่ในการดูแลแต่ละส่วน

วิธีเทียบขอบเขตบริการ SLA และความรับผิดชอบเมื่อเกิดเหตุ

เปรียบเทียบว่าใครทำหน้าที่เฝ้าระวัง ใครคัดกรอง Alert ใครแจ้งเหตุ และใครดำเนินการกักกันหรือแก้ไขจริง SLA การตอบสนอง ควรอ่านร่วมกับขอบเขตการให้บริการ ไม่ใช่ดูเฉพาะข้อความว่าให้บริการตลอดเวลา

คำถามที่ควรถามก่อนขอเดโมหรือใบเสนอราคา

ควรถามว่าแพลตฟอร์มหรือบริการรองรับแหล่ง Log ใดบ้าง ต้องเตรียมข้อมูลอะไรในช่วง Onboarding มีผู้ช่วยปรับ Use Case หรือไม่ จัดเก็บ Log อย่างไร ใครเข้าถึงข้อมูลได้ และเมื่อเกิด Alert สำคัญจะมีขั้นตอนแจ้งและส่งต่ออย่างไร คำตอบเหล่านี้ช่วยให้เปรียบเทียบค่าใช้จ่าย SIEM และ Managed SOC บนขอบเขตงานเดียวกันได้มากขึ้น

เกณฑ์เลือกและสรุปเปรียบเทียบ

ก่อนตัดสินใจ ให้ตรวจสอบ ความพร้อมของทีม ว่ามีผู้คัดกรอง Alert หรือไม่, ปริมาณและคุณภาพ Log ที่ต้องรับเข้า, Use Case ความเสี่ยงสูง ที่ต้องการเริ่มก่อน, ระยะเวลาเก็บข้อมูล และ SLA การตอบสนอง ที่องค์กรต้องการ ใช้เช็กลิสต์นี้ก่อนเปรียบเทียบผู้ให้บริการ และดูรายละเอียดขอบเขตบริการหรือเงื่อนไขในหน้าข้อมูลอย่างเป็นทางการของแต่ละราย

ส่งท้าย

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

ข้อมูลที่ควรรู้เพิ่มเติม

1. Log ที่มีเวลาตรงกันช่วยให้วิเคราะห์ลำดับเหตุการณ์ได้แม่นยำขึ้น
2. Alert จำนวนมากไม่ได้แปลว่าตรวจจับได้ดี หากไม่มีการจัดลำดับความสำคัญ
3. Use Case ควรปรับตามระบบและความเสี่ยงที่เปลี่ยนไป
4. สิทธิ์เข้าถึง Log ควรถูกกำหนดอย่างเหมาะสม เพราะข้อมูลใน Log อาจมีความละเอียดอ่อน
5. การติดตั้งและปรับแต่งขึ้นกับความพร้อมของ Log และการแบ่งหน้าที่ระหว่างองค์กรกับผู้ให้บริการ

ประเด็นสำคัญที่ต้องตรวจสอบ

ความสามารถในการตรวจจับจริงไม่ได้ขึ้นกับ SIEM เพียงอย่างเดียว แต่ขึ้นกับแหล่งข้อมูลที่เชื่อมต่อ คุณภาพการตั้งค่า Use Case และทักษะของทีมปฏิบัติการ ค่าไลเซนส์ ค่าจัดเก็บ Log และค่าบริการ Managed SOC อาจแตกต่างกันตามปริมาณข้อมูล จำนวนอุปกรณ์ ระยะเวลาเก็บรักษา และขอบเขตบริการ จึงควรยืนยันรายละเอียดกับผู้ให้บริการก่อนตัดสินใจ

คำถามที่พบบ่อย

Q1. องค์กรขนาดเล็กจำเป็นต้องใช้ SIEM หรือ Managed SOC หรือไม่?

A1. ไม่สามารถสรุปได้ว่าเหมาะกับทุกองค์กร ควรดูระบบที่ใช้งาน ความเสี่ยง ปริมาณ Log และความพร้อมของทีม หากมีทีมจำกัด อาจเริ่มจาก Use Case สำคัญและประเมินบริการภายนอกที่มีขอบเขตตรงกับความต้องการ

Q2. ค่าใช้จ่ายของ SIEM ควรประเมินจากปัจจัยใดบ้าง?

A2. ควรดูปริมาณข้อมูลที่รับเข้า ระยะเวลาเก็บ Log จำนวนอุปกรณ์ แหล่ง Log ที่ต้องเชื่อมต่อ ค่า Onboarding การปรับแต่ง Use Case และขอบเขต SLA ของบริการ ค่าใช้จ่ายจริงต้องขอรายละเอียดจากผู้ให้บริการตามสภาพแวดล้อมขององค์กร

Q3. SIEM ตรวจจับ Ransomware และ Phishing ได้ทันทีหรือไม่?

A3. SIEM สามารถช่วยค้นหาสัญญาณที่เกี่ยวข้องได้เมื่อมี Log ที่เหมาะสมและมีการตั้งค่า Use Case อย่างถูกต้อง แต่ไม่รับประกันการตรวจจับทุกเหตุการณ์หรือการหยุดการโจมตีโดยอัตโนมัติ องค์กรยังต้องมีขั้นตอนคัดกรอง แจ้งเตือน และตอบสนองที่ชัดเจน