Human-in-the-Loop SOC: จุดที่นักวิเคราะห์ต้องอนุมัติ AI
Human-in-the-Loop SOC คือการให้นักวิเคราะห์อนุมัติก่อน AI ลงมือในขั้นตอนที่กระทบธุรกิจ เช่น isolate production server หรือปิด incident พร้อมวิธีทำหน้าจออนุมัติ
Human-in-the-Loop SOC: จุดที่นักวิเคราะห์ต้องอนุมัติ AI
การให้มนุษย์อนุมัติไม่ใช่ความล้มเหลวของ automation แต่เป็น control ที่ทำให้ action สำคัญมีผู้รับผิดชอบ ขณะที่ agent ทำงานเตรียมข้อมูลได้เร็ว
ต้องอนุมัติเมื่อกระทบธุรกิจ
การ isolate production server ปิด identity block domain สำคัญ ลบหลักฐาน หรือปิด incident ควรต้องมีผู้มีอำนาจตรวจสอบ
ทำให้หน้าจออนุมัติใช้งานได้จริง
แสดงหลักฐาน action ที่เสนอ ผลกระทบ ความเชื่อมั่น และวิธีย้อนกลับ เพื่อให้ reviewer ตัดสินใจได้โดยไม่ต้องสืบสวนใหม่ทั้งหมด
บันทึกการตัดสินใจ
เก็บผู้อนุมัติ หลักฐาน tool ที่ถูกเรียก และสิ่งที่เปลี่ยนแปลง เพื่อใช้ทบทวน incident และสื่อสารกับลูกค้า
จัดระดับแต่ละ action ตามผลเสียเมื่อพลาด
คิวที่เต็มไปด้วยคำขอเล็ก ๆ สอนให้ผู้อนุมัติกดผ่านโดยไม่อ่าน จึงควรถามสามข้อกับทุก action ข้อแรก ย้อนกลับได้ในไม่กี่นาทีโดยธุรกิจไม่เสียหายหรือไม่ (ใน กักกันเครื่องที่ติด Ransomware อัตโนมัติ — แต่ต้องมีคนกดอนุมัติ การ isolate เครื่องอยู่ฝั่งที่ต้องมีคนตัดสิน) ข้อสอง ถ้าพลาดจะกระทบกี่ระบบและกี่หน่วยธุรกิจ ข้อสาม แตะหลักฐานหรือบันทึกของ incident หรือไม่
ค่า confidence แสดงให้ผู้อนุมัติเห็นได้ แต่ไม่ควรใช้ย้าย action ข้ามระดับ เพราะโมเดลมั่นใจแล้วผิดได้ และอีเมลที่ผู้โจมตีเขียนขึ้นก็ชี้นำโมเดลได้ (ตัวอย่างที่ OWASP ยกเอง) OWASP LLM06:2025 (Excessive Agency) แนะนำให้ action ที่มีผลกระทบสูงต้องมีคนอนุมัติก่อนลงมือ
Approval matrix (แนวปฏิบัติที่แนะนำ)
| ประเภท action | Gating | ใครอนุมัติได้ | ผู้อนุมัติต้องเห็น | บันทึกเพิ่มที่ควรเก็บ |
|---|
| 1. อ่าน ค้น enrich และร่างเอกสาร (ค้น log, เช็ก indicator, ร่างข้อความ ticket หรือ takedown) กับ step ที่ไม่เปลี่ยนอะไรบนเป้าหมาย (คัดลอกหลักฐานไปที่เก็บที่ป้องกันไว้, เปิด case, แจ้งคนที่เกี่ยวข้อง) | Autonomous; ส่วนที่ร่างยังเป็นข้อเสนอ | ไม่ต้องมีสำหรับการอ่านหรือร่าง ส่วนการส่ง ticket หรือ takedown ที่ร่างไว้ออกไปคือแถว 4 | query และผลลัพธ์ใน case | input และผลลัพธ์ |
| 2. กักกันที่ปลดออกได้ เป้าหมายเดียวที่ไม่ใช่ asset สำคัญและไม่ใช่ production (isolate endpoint เครื่องเดียว หรือปิดบัญชีผู้ใช้ทั่วไปหนึ่งบัญชี; zcrSOAR สั่ง isolate และ release ผ่าน SentinelOne ได้) | Approval | analyst เวรที่ไม่ใช่ผู้ขออนุมัติ | หลักฐานของ alert; ชื่อเครื่องตาม asset inventory; สิ่งที่จะถูกตัดขาด; วิธีย้อนกลับ | ผู้อนุมัติ; เวลา; สิ่งที่ผู้อนุมัติเห็น; เหตุผลถ้าปฏิเสธ |
| 3. กักกันวงกว้าง (production หรือ asset สำคัญ; บัญชีผู้บริหารหรือ service account; โครงสร้างพื้นฐานที่ใช้ร่วมกัน; การบล็อก domain สำคัญ; หลายเป้าหมาย) | Approval สองคนจากต่างบทบาท | incident commander กับเจ้าของ asset | ข้อมูลของแถว 2 บวก business process ที่พึ่งพาเป้าหมาย | การอนุมัติของแต่ละคนแยกกัน; การแจ้งเจ้าของ |
| 4. เอกสารหรือผลลัพธ์ทางการ (ส่ง ticket หรือ takedown ที่ร่างไว้, ปิด incident, แจ้งลูกค้าหรือหน่วยงานกำกับ) | Approval; จำนวนตาม policy ขององค์กร (zcrCTEM กำหนดต่อ protected asset สำหรับ takedown) | reviewer ที่ไม่ได้ทำ case นั้น; ฝ่ายกฎหมายหรือ DPO สำหรับหนังสือแจ้ง | ข้อความตามที่จะส่งจริง; timeline; งานที่ค้างอยู่ | ฉบับที่ส่งจริง; ผู้อนุมัติ; ผลที่ได้ |
| 5. ทำลายหรือเขียนทับหลักฐาน (ลบไฟล์, wipe หรือ reimage, purge กล่องจดหมาย) | Blocked | ไม่มีใน playbook; ผู้ดูแลที่ระบุชื่อทำด้วยมือ หลังผู้มีอำนาจอนุมัติ | ยืนยันว่าเก็บหลักฐานไว้แล้ว | ผู้ทำ; สิ่งที่ทำ; อ้างอิงถึงหลักฐาน |
| 6. เปลี่ยนตัว automation (เปิด playbook ใน production, เปลี่ยน step จาก Approval เป็น Autonomous, ขยายสิทธิ์ของ connector) | Approval | หัวหน้าทีมวิศวกรรมที่ไม่ได้เป็นคนแก้; เจ้าของความเสี่ยงถ้าเป็นการเปลี่ยนไปทาง Autonomous | ผลเปรียบเทียบ version; ผล dry-run; asset ที่เข้าถึงได้เพิ่ม; ถ้าเป็น Autonomous ให้ดูประวัติ Approval และผลทดสอบย้อนกลับ | version ใหม่; ผู้แก้กับผู้อนุมัติคนละคน; ย้อนกลับ version เดิมได้ |
ส่วนที่ มีในเอกสาร ของ zcrSOAR: gating ที่ตั้งทีละ step ของ playbook (Autonomous ทำงานทันที, Approval รอการอนุมัติที่คุมสิทธิ์ตามบทบาท, Blocked ไม่ทำงานจนกว่าจะเปลี่ยนการตั้งค่า); คิวเดียวที่คุมสิทธิ์ตามบทบาท กำหนดผู้อนุมัติตามประเภท action, severity, asset, site หรือ business unit ได้; บันทึกการทำงาน (user, action, playbook, connector, input, result, สถานะ) ส่วนที่ ลูกค้าตั้งค่าเอง คือผู้รับแต่ละบทบาท และเกณฑ์ว่า asset ไหนสำคัญ
นอกจากที่ zcrCTEM ให้ analyst อนุมัติสิ่งที่ AI ร่างแล้ว Approval ในแถว 4 และ 6 เป็นกติกาที่ขั้นตอนขององค์กรเองต้องบังคับ ส่วน response approval matrix ของ zcrSOAR เป็นฟีเจอร์แยกต่างหาก
กติกา separation of duties
แนวปฏิบัติที่แนะนำ ตามหลัก separation of duties ใน NIST SP 800-53 ข้อ AC-5:
- ผู้ขออนุมัติไม่อนุมัติเอง ไม่ว่าจะเป็น agent, playbook หรือ analyst และผู้เขียน playbook ไม่ควรเป็นคนเปิดใช้ ส่วน zcrSOAR จำกัดสิทธิ์ของ playbook และ connector ตามบทบาทได้ (สิทธิ์ approve แยกจาก create, edit และ enable) อย่าเพิ่งเชื่อว่าระบบปฏิเสธการอนุมัติคำขอของตัวเอง ให้ลองในสภาพแวดล้อมทดสอบ
- การกดอนุมัติไม่ใช่การตรวจสิทธิ์ OWASP แนะนำให้ระบบปลายทางตรวจสิทธิ์เอง (complete mediation) แทนที่จะเชื่อโมเดล ดังนั้นให้บัญชีของ connector มีสิทธิ์เท่าที่ตารางต้องใช้ (ลูกค้าตั้งค่าเอง)
- ผู้อนุมัติรับผิดชอบเป้าหมาย จึงให้ route ตาม asset, site และ business unit สำหรับผู้อนุมัติสองคนในแถว 3 ให้วาง step Approval สองตัวต่อกัน route ไปคนละบทบาท แล้วลองในสภาพแวดล้อมทดสอบว่าใช้งานได้จริง
ถ้าไม่มีใครอนุมัติทันเวลา
ตามเอกสาร step แบบ Approval จะรอ step ที่ติด gate จึงยังไม่เปลี่ยนอะไรระหว่างนั้น ส่วนขั้นตอนขององค์กรต้องกำหนดเองว่าคำขอรอได้นานแค่ไหน และเมื่อครบกำหนดทำอย่างไร
แนวปฏิบัติที่แนะนำ: คำขอที่หมดเวลาถือเป็นการปฏิเสธพร้อมเหตุผลที่บันทึกไว้ ห้ามกลายเป็นการอนุมัติ ให้ผู้ดูแลคิวที่ระบุชื่อเป็นคนปฏิเสธเมื่อถึงกำหนด หลังจาก escalate ไปผู้อนุมัติถัดไปผ่านช่องทางแจ้งเตือนที่เชื่อมไว้แล้ว การอนุมัติที่มาช้าไม่ทำให้คำขอเดิมกลับมามีผล ให้ตรวจเป้าหมายและ alert อีกครั้งแล้วส่งคำขอใหม่ ระหว่างรอ step ที่ไม่เปลี่ยนอะไรบนเป้าหมาย (อ่าน, enrich, ร่างเอกสาร, คัดลอกหลักฐานไปที่เก็บที่ป้องกันไว้, เปิด case, แจ้งคนที่เกี่ยวข้อง) ทำงานต่อได้ ส่วน step ที่เปลี่ยนสถานะบนเป้าหมายทุกตัวต้องรอ
เจ้าของความเสี่ยงควรรับเรื่องการรอเป็นลายลักษณ์อักษร ถ้า action แคบ ๆ ที่ย้อนกลับได้รอไม่ได้ ให้จัดเวรผู้อนุมัติ ส่วน Autonomous มีเกณฑ์ที่สูงกว่า ตามที่อธิบายไว้ใน AI-Assisted SOC เทียบกับ Autonomous SOC คือ step ต้องย้อนกลับได้ เคยทำงานภายใต้ Approval มาตลอดรอบทบทวนโดยไม่มีการอนุมัติใดต้องถูกย้อนทีหลัง และมีเส้นทางย้อนกลับที่ทดสอบแล้ว
จุดที่ gate พัง และเมื่อไรต้อง escalate
แนวปฏิบัติที่แนะนำ: ทุกจุดต่อไปนี้ escalate ไปที่ CISO หรือเจ้าของความเสี่ยง
- กดผ่านโดยไม่อ่าน ถ้าเกือบทุกคำขอถูกอนุมัติทันทีที่เข้าคิว reviewer ก็ไม่ได้ตัดสินอะไร ให้คำนวณอัตราอนุมัติต่อ reviewer จาก approval record และ escalate เมื่อ reviewer ไม่เคยปฏิเสธเลยตลอดรอบทบทวน
- อนุมัติตามคำอธิบายของโมเดล ให้แสดงเป้าหมาย เจ้าของ และพารามิเตอร์จากระบบต้นทางไว้ข้างสรุปของ agent และ escalate เมื่อสองฝั่งไม่ตรงกัน
- gate หลวมลง และ action นอกตาราง ให้ escalate เมื่อ step แถว 3 หรือ 4 ถูกย้ายไปเป็น Autonomous หรือเมื่อ step แถว 5 หลุดจาก Blocked ส่วน action ที่ไม่อยู่ในตารางให้ถือเป็น Blocked จนกว่าจะจัดระดับ (ไม่ใช่ค่าเริ่มต้นของ zcrSOAR)
คำถามที่พบบ่อย
การบังคับให้มีคนอนุมัติทำให้รับมือ ransomware ช้าเกินไปหรือเปล่า?
action ที่ติด gate ต้องรอเพิ่มจริง แต่ step แถว 1 ทำงานทันที และ case ถึงมือ reviewer พร้อมหลักฐานที่รวบรวมไว้แล้ว reviewer จึงเหลืองานตัดสินใจเป็นหลัก
ใช้ AI ตัวที่สองอนุมัติแทนคนได้ไหม?
เพิ่มการตรวจได้ แต่ให้โมเดลตัวหนึ่งตรวจอีกตัวก็ยังอยู่ในวงของโมเดลเหมือนเดิม และผู้อนุมัติมีไว้ให้คนที่ระบุชื่อได้รับผิดชอบผลของ action ส่วนใน zcrCTEM ticket หรือ takedown ที่ AI ร่างยังเป็นข้อเสนอจนกว่า analyst จะอนุมัติหรือปฏิเสธ
ถ้า managed service ดูแลคิวอยู่ ใครควรเป็นคนอนุมัติ?
zcrSOC เป็นบริการ managed ที่ส่งมอบผ่าน channel partner ที่ได้รับอนุมัติ ระดับ Essential ทำงานบน zcrSIEM ส่วน Response เพิ่ม zcrSOAR แนวปฏิบัติที่แนะนำในระดับ Response คือให้ action ที่กระทบธุรกิจอยู่กับเจ้าของ asset หรือหน่วยธุรกิจฝั่งลูกค้า และให้ partner อนุมัติเฉพาะแถว 2 ภายในขอบเขตที่ตกลงในสัญญา
แหล่งอ้างอิง
อ่านต่อ: ใช้ AI Agent ร่วมกับ EDR เดิม, จาก Alert ถึงหลักฐาน: Workflow AI SOC ที่ตรวจสอบย้อนหลังได้ และ คู่มือ AI SOC Agent
ดู zcrSOC · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้