AI-Assisted SOC เทียบกับ Autonomous SOC: เลือก Operating Model ให้เหมาะ
AI-Assisted SOC หรือ Autonomous SOC แบบไหนเหมาะกับทีมคุณ ดูว่างานไหนให้ AI ช่วยวิเคราะห์ งานไหนปล่อยให้ระบบทำเอง และควรกำหนดจุดส่งต่อให้นักวิเคราะห์ตรงไหนบ้าง
AI-Assisted SOC เทียบกับ Autonomous SOC: เลือก Operating Model ให้เหมาะ
Operating model ที่เหมาะขึ้นกับผลกระทบทางธุรกิจ คุณภาพหลักฐาน และความสามารถในการทบทวน ไม่ใช่ระดับความ autonomous ในคำโฆษณา
เลือก assisted เมื่อ judgment สำคัญ
AI-assisted เหมาะกับ investigation, triage, report และการเรียนรู้ของ analyst เมื่อ action กระทบธุรกิจหรือข้อมูลยังไม่ครบ
เลือก autonomy แบบมีขอบเขตกับงานเสี่ยงต่ำ
ให้ automation ทำ enrichment, deduplication, ticket routing และ notification ที่อนุมัติแล้ว เมื่อความเสียหายจำกัดและสังเกตได้
กำหนด escalation contract
เขียนว่าใครเป็นเจ้าของการตัดสินใจ ต้องใช้หลักฐานอะไร agent ต้องหยุดเมื่อไร และติดต่อมนุษย์อย่างไร
ระดับ autonomy กำหนดที่ตัว action ไม่ใช่ที่ตัวผลิตภัณฑ์
ใน SOC จริง ระดับ autonomy กำหนดกันทีละ action การสรุป incident เป็นงานแบบ assisted การ isolate เครื่อง laptop หลังมีคนอนุมัติเป็น approved automation ส่วนการแนบผลเช็กชื่อเสียงของ IP เข้า ticket ปล่อยให้ทำเองโดยไม่ต้องรอใครอนุมัติก็ได้
ตัวชี้ว่า action ควรอยู่ระดับไหนมีสองอย่าง คือย้อนกลับได้หรือไม่ กับ blast radius (กระทบ laptop ทดสอบเครื่องเดียว หรือกระทบ domain controller) แนวปฏิบัติที่แนะนำ: ขั้นตอนที่แค่อ่านหรือเพิ่มบันทึกและย้อนกลับได้ เช่น ค้นข้อมูล เพิ่ม note หรือ tag เป็นตัวเลือกของ bounded autonomy ส่วนขั้นตอนที่เปลี่ยนสถานะของระบบจริงให้เริ่มที่การอนุมัติโดยคน แม้จะกระทบวงแคบและย้อนกลับได้ ถ้าย้อนกลับไม่ได้หรือกระทบวงกว้างก็ให้คนเป็นผู้ตัดสิน
วิธีจัดระดับแต่ละ action ดูต่อได้ใน Human-in-the-Loop SOC แนวทางของ OWASP สำหรับแอปพลิเคชัน LLM สนับสนุนเรื่องการอนุมัติ โดยระบุว่าสาเหตุที่พบบ่อยของ Excessive Agency คือ functionality สิทธิ์ และ autonomy ที่เกินจำเป็น และแนะนำให้คนอนุมัติ action ที่มีผลกระทบสูง ส่วนความย้อนกลับได้และ blast radius เป็นเกณฑ์ของเราเอง ไม่ได้มาจาก OWASP
ตารางตัดสินใจ: สาม operating model
เป็นแนวปฏิบัติที่แนะนำ ไม่ได้อธิบายผลิตภัณฑ์ตัวใดตัวหนึ่ง
| หัวข้อ | AI-assisted | Human-approved automation | Bounded autonomy |
|---|
| ใครตัดสินใจ | analyst โดย AI เตรียมสรุปและร่าง query ให้ | ผู้อนุมัติที่ระบุชื่อ โดย AI เสนอและระบบดำเนินการหลังได้รับอนุมัติ | นโยบายที่เขียนไว้ล่วงหน้า โดย AI ทำได้เฉพาะในรายการที่อนุมัติไว้ |
| action ที่พบบ่อย | สรุปเหตุการณ์ ร่างคำค้นให้ตรวจ เสนอขั้นตอนถัดไป | isolate เครื่อง ปิดการใช้งานบัญชี บล็อก indicator | เพิ่ม tag หรือ note เปิด ticket ค้นข้อมูลแบบอ่านอย่างเดียว เฉพาะขั้นตอนที่ย้อนกลับได้และอยู่ในรายการที่อนุมัติไว้ |
| หลักฐานที่ต้องเก็บ | note ของ analyst ข้อมูลที่ AI ใช้ และ query ที่ analyst ตรวจแล้ว | เหมือนคอลัมน์ก่อนหน้า บวกข้อเสนอ ผู้อนุมัติ เวลาอนุมัติ และผลลัพธ์ | เหมือนคอลัมน์ก่อนหน้า บวกนโยบายที่อนุญาตและการสุ่มทบทวนตามรอบ |
| ผลต่อกำลังคน | ต้องมี analyst ทุกเคส ความสามารถในการรับงานโตตามจำนวนคน | ต้องมีผู้อนุมัติที่ติดต่อได้ในช่วงเวลาตอบสนอง รวมนอกเวลางาน | ต้องมีเจ้าของที่ทบทวนผลและดูแลรายการที่อนุญาต งานประจำน้อยที่สุด แต่ไม่ใช่ศูนย์ |
| ความผิดพลาดถูกจับที่ไหน | analyst จับได้ก่อนลงมือ ถ้าตรวจหลักฐานเบื้องหลัง ไม่ใช่อ่านแค่สรุป | ผู้อนุมัติจับได้ ถ้าอ่านข้อเสนอจริง แต่ถ้ากดผ่านโดยไม่อ่าน ความผิดพลาดก็ถูกทำจริง | ไม่มีใครจับก่อนลงมือ จับได้ภายหลังจากการสุ่มทบทวน จึงควรจำกัดรายการให้แคบและย้อนกลับได้ |
| เลือกเมื่อไร | ข้อมูลไม่ครบ asset สำคัญ ทีมใหม่ หรือติดตั้งครั้งแรก | action ที่กระทบธุรกิจและเร่งด่วนเกินกว่าจะทำมือ | งานซ้ำ ผลกระทบต่ำ ย้อนกลับได้ และรันภายใต้การอนุมัติมานานพอจะไว้ใจ |
| ตัวอย่าง: failed login ซ้ำ ๆ บน service account | AI ร่าง timeline และ query แล้ว analyst ตัดสินเอง | AI เสนอให้ปิดการใช้งานบัญชี ผู้อนุมัติที่ระบุชื่ออ่านหลักฐานแล้วจึงอนุมัติ | AI แนบผลเช็กชื่อเสียงของ IP เข้า ticket เป็น note และไม่แตะบัญชี |
สี่คำถามที่ควรถาม vendor ทุกราย
แนวปฏิบัติที่แนะนำ ท้ายแต่ละคำถามมีลักษณะของคำตอบที่ดีให้เทียบ
- action ไหนทำได้ที่ระดับไหน และฝั่งเราแก้รายการนั้นเองได้หรือไม่ คำตอบที่ดีคือรายการรายตัวต่อ action ไม่ใช่ตัวเลือก autonomy อันเดียวทั้งระบบ
- ส่วนที่เป็น AI เข้าถึงอะไรได้ ทั้ง credential, connector และ scope คำตอบที่ดีคือสิทธิ์น้อยที่สุดต่อ connector และตรวจสิทธิ์ที่ระบบปลายทาง ไม่ฝากไว้กับดุลยพินิจของโมเดล
- ใครอนุมัติ action แต่ละประเภทได้ และถ้าไม่มีใครตอบจะเกิดอะไรขึ้น คำตอบที่ดีคือระบุบทบาท เวลารอสูงสุด และทางสำรองเป็นการพักไว้หรือส่งต่อ
- action แต่ละตัวย้อนกลับได้ไหม และเหลือบันทึกอะไรไว้ คำตอบที่ดีคือมีขั้นตอนย้อนกลับที่กำหนดไว้ และมี input หลักฐาน ผู้อนุมัติ กับผลลัพธ์ที่ผู้ตรวจสอบอ่านได้
สิ่งที่ zcr ระบุไว้ และสิ่งที่ยังเป็นการตัดสินใจของคุณ
สิ่งที่ระบุไว้ในเอกสารผลิตภัณฑ์: ใน zcrSOAR แต่ละขั้นตอนของ playbook ตั้งเป็น Autonomous, Approval หรือ Blocked ขั้นตอน Autonomous ทำงานทันที ขั้นตอน Approval รอการอนุมัติจากผู้มีบทบาทที่กำหนด และ Blocked จะไม่ทำงานจนกว่าจะเปลี่ยน gating ส่วน playbook ที่ยังไม่อนุมัติอยู่ใน Draft, Test, Dry-run หรือ Simulation Mode จนกว่าองค์กรจะอนุญาตให้ทำงานจริง และ response action ทุกรายการถูกบันทึกพร้อม user, input, result และสถานะ zcrSIEM แปลงคำถามภาษามนุษย์เป็น query ที่ analyst ตรวจสอบได้ แต่ zcrSIEM ไม่มี SOAR ในตัว การอนุมัติและ containment action เป็นของ zcrSOAR
การจับคู่ที่เราเสนอ (แนวปฏิบัติที่แนะนำ ไม่ใช่ฟีเจอร์ที่ระบุไว้): Approval ตรงกับ human-approved automation, Autonomous ตรงกับ bounded autonomy และ Blocked เป็นระดับล่างสุดของทุก model ส่วนงาน assisted คืองานที่คนทำเองโดยใช้ query ที่ zcrSIEM ร่างให้ตรวจ แต่ gating ที่ระบุไว้ใช้กับขั้นตอนของ playbook ไม่ได้ครอบคลุมการเรียกใช้ tool ของ AI agent เอง การวาง AI ไว้ใต้ระดับเหล่านี้จึงเป็นการออกแบบของคุณเอง
บริการแบบ managed: zcrSOC และ zcrMDR ส่งมอบผ่าน channel partner ที่ได้รับอนุมัติ zcrSOC ระดับ Essential ครอบคลุมการรับทราบ alert การคัดกรอง และรายงานรายเดือน ส่วนระดับ Response เพิ่มการประสานตอบสนอง การยกระดับเหตุ และการสนับสนุน IR ส่วนช่วงเวลาให้บริการกำหนดในสัญญา แนวปฏิบัติที่แนะนำ: ระบุในสัญญาด้วยว่าบริการทำ action ไหนได้และใครเป็นผู้อนุมัติ
ส่วนที่ลูกค้าตั้งค่าเอง: ขั้นตอนไหนเป็น Autonomous ใครเป็นผู้อนุมัติ และ asset ไหนสำคัญต่อธุรกิจ
ข้อจำกัด จุดที่พลาดได้ และเงื่อนไขที่ต้องให้คนเข้ามาคุม
Approval queue อาจพังแบบเงียบ ๆ ได้ ถ้าผู้อนุมัติกดผ่านเกือบทุกรายการ หรือมีคนยกขั้นตอนเป็น Autonomous เพื่อให้คิวหมด ขั้นตอนที่ให้คนตัดสินก็เหลือแค่ความล่าช้า zcrSOAR รองรับการติดตาม approval queue และการเปิดดู approval record แนวปฏิบัติที่แนะนำคือใช้ตรวจหาคำขอที่ค้างและการอนุมัติที่ผ่านไปโดยไม่มีใครอ่าน พร้อมตกลงกฎนอกเวลางานไว้ล่วงหน้า (ผู้อนุมัติที่อยู่เวร ช่วงเวลาของบริการ managed หรือให้ action นั้นรอไปก่อน)
แนวปฏิบัติที่แนะนำ: เจ้าของที่ระบุชื่อไว้ควรมีสิทธิ์ถอย action กลับหนึ่งระดับ (จาก Autonomous เป็น Approval หรือจาก Approval เป็นทำมือ) ซึ่งใน zcrSOAR คือการเปลี่ยน gating ของขั้นตอนนั้น ให้ถอยเมื่อ
- action ไปโดนเป้าหมายนอกขอบเขตที่ตั้งใจไว้
- ย้อนกลับแล้วสถานะไม่กลับมาเหมือนเดิม (การ isolate เครื่องย้อนกลับได้ในทางทฤษฎี แต่ไม่ใช่ตอนที่เครื่องนั้นรันงานที่ธุรกิจต้องใช้พอดี)
- ข้อมูลที่ใช้ตัดสินไม่ครบหรือเก่า เช่น แหล่ง log ที่เงียบไป
- ผู้ทบทวนอ่านบันทึกแล้วอธิบายไม่ได้ว่าทำไม action นั้นทำงาน
- เป้าหมายกลายเป็น asset สำคัญต่อธุรกิจ
คำถามที่พบบ่อย
ควรตั้งเป้าเป็น SOC ที่ autonomous เต็มรูปแบบหรือไม่?
ไม่ควรตั้งเป็นเป้าหมาย Bounded autonomy เหมาะกับขั้นตอนที่แค่อ่านหรือเพิ่มบันทึกและย้อนกลับได้ ส่วน containment, action ที่ย้อนกลับไม่ได้ และ asset สำคัญต่อธุรกิจ ควรให้คนร่วมตัดสินใจ
ทีมที่คนไม่พอ ใช้ bounded autonomy อุดช่องว่างได้ไหม?
ได้เฉพาะขั้นตอนที่อ่านอย่างเดียวหรือเพิ่มบันทึก เช่น note, tag หรือการค้นข้อมูล คนไม่พอไม่ใช่เหตุผลที่จะยก containment step ขึ้นเป็น Autonomous ให้เพิ่มผู้อนุมัติ ตกลงว่างานไหนรอไปก่อนนอกเวลางาน หรือใช้บริการ managed ผ่าน channel partner ที่ได้รับอนุมัติ
จะเลื่อนจาก operating model หนึ่งไปอีกแบบหนึ่งอย่างไร?
แนวปฏิบัติที่แนะนำคือเริ่มจากงานแบบ AI-assisted แล้วลองขั้นตอนนั้นใน Dry-run หรือ Simulation Mode ก่อนย้ายไป Approval จะยกเป็น Autonomous ได้เฉพาะขั้นตอนที่ย้อนกลับได้ ทำงานภายใต้การอนุมัติมาตลอดรอบทบทวนโดยไม่มีการอนุมัติใดต้องถูกย้อนทีหลัง และทดสอบเส้นทางย้อนกลับแล้ว
แหล่งอ้างอิง
อ่านต่อ: เริ่มโครงการ AI SOC อย่างไรโดยไม่ต้องเปลี่ยน Stack เดิม, Agentic AI ในงาน SOC คืออะไร และ คู่มือ AI SOC Agent
ดู zcrSOC · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้