นำ AI มาใช้ใน SOC เพื่อลด MTTD และ MTTR

ทีม SOC (ศูนย์เฝ้าระวังและตอบสนองเหตุการณ์ด้านความปลอดภัย) ส่วนใหญ่เจอปัญหาเดียวกัน คือมี alert (การแจ้งเตือนจากระบบเฝ้าระวัง) มากเกินกว่าคนจะไล่ดูได้ทัน นักวิเคราะห์ต้องใช้เวลากับงานซ้ำๆ เช่น รวบรวมข้อมูลประกอบและเขียนสรุป ขณะที่ภัยคุกคามจริงอาจจมอยู่ท่ามกลาง alert ที่ไม่สำคัญ AI จึงเข้ามาช่วยลดเวลาในงานที่ใช้แรงคนก่อน ไม่ได้มาแทนนักวิเคราะห์

MTTD และ MTTR คืออะไร

• MTTD (Mean Time to Detect): เวลาเฉลี่ยตั้งแต่เหตุการณ์เริ่มต้นจนทีมตรวจพบ
• MTTR (Mean Time to Respond / Resolve): เวลาเฉลี่ยตั้งแต่ตรวจพบจนตอบสนองหรือแก้ไขเสร็จ แต่ละองค์กรกำหนดจุดสิ้นสุดไม่เหมือนกัน จึงควรตกลงให้ชัดก่อนเริ่มวัด เพื่อเทียบก่อนและหลังใช้ AI ได้อย่างเป็นธรรม

AI ช่วยลด MTTD และ MTTR ได้ตรงไหน

• ตรวจจับ (ลด MTTD): หาพฤติกรรมผิดปกติของผู้ใช้และอุปกรณ์ด้วย UEBA (การเรียนรู้พฤติกรรมปกติแล้วชี้สิ่งที่เบี่ยงเบนไป) เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องกันแต่กระจายอยู่หลายระบบ และช่วยคัดสัญญาณรบกวนที่ไม่จำเป็นต้องดูออกไป
• คัดแยก (ลด MTTR): เติมบริบทให้ alert โดยอัตโนมัติ เช่น ข้อมูลผู้ใช้ ความสำคัญของเครื่อง และ threat intelligence (ข้อมูลข่าวกรองเกี่ยวกับภัยคุกคาม) แล้วจัดลำดับความสำคัญให้
• สืบสวน (ลด MTTR): สรุปไทม์ไลน์ของเหตุการณ์ และให้นักวิเคราะห์ค้น log ด้วยภาษาพูดทั่วไป แทนการเขียน query ยาวๆ
• ตอบสนอง (ลด MTTR): เสนอ playbook (ขั้นตอนมาตรฐานที่เขียนไว้ล่วงหน้า) หรือขั้นตอนถัดไป และสั่งงานผ่าน SOAR (ระบบสั่งงานตอบสนองอัตโนมัติ) เช่น แยกเครื่องออกจากเครือข่ายหรือปิดบัญชี การกระทำที่มีผลกระทบสูงต้องให้คนอนุมัติก่อน
• ปรับปรุงต่อเนื่อง: ช่วยร่างและปรับแต่ง detection rule (กฎตรวจจับ) จากเหตุการณ์ที่ผ่านมา เพื่อให้ MTTD ดีขึ้นในรอบถัดไป

ข้อควรระวังเมื่อใช้ AI ใน SOC

• คำตอบผิดแต่ฟังดูมั่นใจ: AI อาจสรุปผิดหรือแต่งข้อมูลที่ไม่มีอยู่จริงขึ้นมา การตัดสินใจสำคัญจึงต้องมีหลักฐานจาก log ที่ตรวจสอบได้
• Prompt injection ผ่านข้อมูลที่ AI วิเคราะห์: ข้อความใน log อีเมล หรือไฟล์ที่ผู้โจมตีควบคุมได้ อาจแฝงคำสั่งเพื่อหลอกให้ AI ทำตาม
• ข้อมูลรั่วไหล: log มีข้อมูลอ่อนไหว จึงต้องรู้ว่าข้อมูลถูกส่งไปที่ไหน เก็บไว้นานเท่าใด และถูกนำไปเทรน AI หรือไม่
• อัตโนมัติเกินไป: การตอบสนองอัตโนมัติที่ผิดพลาดอาจตัดระบบที่ธุรกิจต้องใช้เสียเอง
• พึ่งพา AI จนทักษะทีมลดลง: นักวิเคราะห์ยังต้องเข้าใจเหตุผลเบื้องหลังผลลัพธ์

เริ่มต้นใช้ AI ใน SOC อย่างปลอดภัย

• วัดค่าเริ่มต้นก่อน: บันทึก MTTD และ MTTR ปัจจุบัน แยกตามประเภทเหตุการณ์ เพื่อใช้เป็นฐานเปรียบเทียบ
• เลือกงานที่เสี่ยงต่ำและทำซ้ำบ่อย: เช่น การเติมบริบทและสรุป alert ก่อนจะขยับไปถึงการตอบสนองอัตโนมัติ
• ให้ AI แนะนำ คนเป็นผู้ตัดสินใจ: ค่อยเพิ่มระดับความอัตโนมัติเมื่อมีข้อมูลยืนยันว่า AI แม่นยำพอ
• ตั้ง guardrail: guardrail คือกรอบที่กันไม่ให้ AI ทำเกินขอบเขต ได้แก่ จำกัดสิทธิ์ที่ AI ใช้ได้ บันทึกทุกการกระทำ และมีปุ่มหยุดฉุกเฉิน
• วัดผลซ้ำและทบทวนเป็นรอบ: ดูทั้งความเร็วและความแม่นยำ รวมถึงจำนวน alert ที่ AI จัดประเภทผิด

ทดลองกับ alert ประเภทเดียวก่อน

เลือก alert ประเภทที่ทีมเจอบ่อยที่สุด 1 ประเภท ให้ AI ช่วยเติมบริบทและสรุปให้นักวิเคราะห์ แล้ววัด MTTR ของ alert ประเภทนั้น เทียบกับช่วงก่อนใช้ AI ภายใน 1-2 เดือน

หากพนักงานในองค์กรใช้เครื่องมือ AI นอกช่องทางที่องค์กรอนุมัติด้วย ควรอ่าน Shadow AI คืออะไร ควบคู่กัน

การกำกับดูแลความเสี่ยงด้าน AI ในระดับองค์กรใช้กรอบ NIST AI RMF เป็นแนวทางได้ ซึ่งอธิบายไว้ในอีกบทความหนึ่ง

ก่อนเพิ่ม AI ควรรู้ก่อนว่าเครื่องมือหลักของ SOC แต่ละตัวทำหน้าที่อะไร อ่านเปรียบเทียบได้ที่ SIEM + SOAR กับ XDR: ข้อดี ข้อจำกัด และคำแนะนำ

AI ไม่ได้ช่วยแค่ฝ่ายป้องกัน ผู้โจมตีก็ใช้ AI สร้างเสียงและวิดีโอปลอมได้ถูกลงและเร็วขึ้น อ่านวิธีรับมือได้ใน Deepfake และการหลอกลวงด้วย AI: องค์กรรับมืออย่างไร

สำหรับภาพรวมการออกแบบ SOC ทั้งระบบของหน่วยงานภาครัฐ ดู SOC Architecture Blueprint สำหรับหน่วยงานภาครัฐ

ถ้าต้องการให้ทีม SOC ระบุว่าตรวจจับเทคนิคใดได้บ้าง ดู MITRE ATT&CK สำหรับผู้บริหาร: อ่านและใช้อย่างไร ซึ่งอธิบายวิธีอ่านตารางและคำถามที่ควรถามทีม

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

• NIST AI Risk Management Framework: กรอบการบริหารความเสี่ยงด้าน AI
• OWASP: LLM01 Prompt Injection: อธิบายความเสี่ยงและวิธีป้องกัน