จาก Alert ถึงหลักฐาน: Workflow AI SOC ที่ตรวจสอบย้อนหลังได้
Workflow AI SOC ที่ตรวจย้อนหลังได้ต้องเก็บอะไรบ้าง ตั้งแต่ alert ต้นทางและ raw event จนถึงการอนุมัติและ action สุดท้าย เพื่อให้ analyst อีกคนตรวจซ้ำได้
จาก Alert ถึงหลักฐาน: Workflow AI SOC ที่ตรวจสอบย้อนหลังได้
Workflow AI SOC น่าเชื่อถือเมื่อ analyst อีกคนสามารถทำความเข้าใจและตรวจซ้ำได้ตั้งแต่ signal แรกจนถึง action สุดท้าย
เก็บ signal ต้นทาง
เก็บ alert เดิม เวลา แหล่งที่มา detection rule และ raw identifier อย่าแทนที่ source ด้วยสรุปจาก AI
ผูกข้อสรุปกับหลักฐาน
ทุก finding ต้องชี้ไปยัง event, query, asset, identity หรือแหล่งข้อมูลภายนอกที่รองรับ และแยก assumption ให้ชัด
ปิดวงจร
บันทึก approval, response, ผลลัพธ์ และคำแนะนำถัดไป แล้วใช้ข้อมูลปรับ detection และ playbook
"ตรวจสอบย้อนหลังได้" ต้องหมายถึงอะไรเมื่อมี model อยู่ใน workflow
NIST SP 800-53 Rev. 5 เป็นชุด control ที่ NIST ซึ่งเป็นหน่วยงานรัฐบาลกลางของสหรัฐฯ เผยแพร่ ใช้เป็นเกณฑ์เทียบได้ (ไม่ใช่ข้อกำหนดทางกฎหมายของไทย)
Control AU-3 กำหนดให้ audit record ระบุได้ว่าเกิดเหตุการณ์ประเภทใด เมื่อไร ที่ไหน มาจากแหล่งใด ผลเป็นอย่างไร และเกี่ยวข้องกับใครหรืออะไร ตัวข้อกำหนด AU-3 เองไม่ได้พูดถึง AI
เมื่อมี model เข้ามา ต้องเพิ่มอีกสามเรื่อง (1) เก็บ output ของ model พร้อม template หรือ model version เบื้องหลัง เพราะรันซ้ำแล้วอาจได้ข้อความไม่เหมือนเดิม (2) แยก output กับการตัดสินใจของคนเป็น record คนละรายการ model เสนอได้ แต่คนที่อยู่ใน role ที่มีสิทธิ์เท่านั้นที่อนุมัติได้ (3) มี trail ของ incident (บันทึกว่ามีการตัดสินใจอะไรกับ case หนึ่ง) แยกจาก audit log ของแพลตฟอร์ม เพราะใช้แทนกันไม่ได้ ส่วนที่เหลือเป็นแนวปฏิบัติที่แนะนำ เว้นแต่ระบุว่ามีเอกสารของ zcr รองรับ
Evidence trail ทีละขั้น
| ขั้นตอน | record ที่ต้องมี | fields (ทุกแถวมี timestamp และ actor) | เหตุผลที่ auditor ถามหา |
|---|
| 1. รับ alert | alert ต้นฉบับและตัวอ้างอิงไปยัง raw event เก็บแยกจากสรุปของ AI | input (alert, rule, event ID), actor (ต้นทางหรือ rule) | แสดงว่างานเริ่มจากอะไร |
| 2. เปิด case | case ที่ระบุเจ้าของงาน, severity และ alert ที่จัดกลุ่มไว้ | output (severity, การจัดกลุ่ม) | ยืนยันเจ้าของงานและเวลาเริ่ม |
| 3. สืบสวน | ทุก query พร้อมคำถามต้นทาง และผลลัพธ์ (หรือตัวอ้างอิงที่ตรึงไว้) เก็บก่อนเริ่ม remediation | input (คำถาม), query, output (ตัวอ้างอิงผลลัพธ์) | ให้อีกคนรันซ้ำได้ |
| 4. output ของ AI | สรุปหรือคำแนะนำของ AI ตามตัวอักษร พร้อม event ที่อ้างถึง ถ้าแก้ให้เก็บเป็น version ใหม่ | input (context), template หรือ model version, output, actor (agent) | รันซ้ำอาจต่างออกไป สำเนาที่เก็บไว้พิสูจน์ได้ว่า analyst เห็นอะไร |
| 5. คนตัดสินใจ | approve, reject หรือแก้ไข พร้อมเหตุผล ผูกกับข้อเสนอนั้น | human decision, actor (ชื่อและ role), ตัวอ้างอิงไปยังขั้น 4 | แสดงความรับผิดชอบและอำนาจของผู้อนุมัติ |
| 6. ทำ action | บันทึกการรัน: playbook และ version, ขั้นของ playbook, connector, target, gating mode | action, input (parameter), result | พิสูจน์ว่าสิ่งที่รันตรงกับที่อนุมัติ |
| 7. ปิด case | บันทึกการปิด: classification, เจ้าของงานติดตามผล, รายงานที่สร้างจากหลักฐานชุดเดียวกัน | output (classification), human decision (การปิด), result | ปิด trail พร้อมผลลัพธ์และงานติดตามผล |
คำถามห้าข้อที่ auditor จะถาม
ถ้า trail ตอบข้อใดไม่ได้ ให้ถือว่าขั้นนั้นพิสูจน์ย้อนหลังไม่ได้ ข้อ 1, 3 และ 4 ตรงกับ AU-3 ส่วนข้อ 2 คือสิ่งที่ model เพิ่มเข้ามา และข้อ 5 รวมเรื่องเวลาใน AU-3 เข้ากับเรื่องที่ AU-9 ให้ความสำคัญ
| คำถาม | record ที่ตอบได้ |
|---|
| 1. อะไรเป็นตัวจุดชนวน และทีมเห็นอะไร | ขั้น 1 และ 3 |
| 2. AI มีส่วนอะไร และ version ไหนเป็นผู้สร้าง | ขั้น 4 |
| 3. ใครตัดสินใจ ใน role ใด กับข้อเสนอไหน | ขั้น 4 และ 5 |
| 4. ทำอะไรลงไป กับ target ไหน ผลเป็นอย่างไร | ขั้น 6 |
| 5. เรียงลำดับเหตุการณ์กลับมาได้ไหม และมี record ถูกแก้หรือหายไปหรือเปล่า | ขั้น 2 และ 7, timestamp ทุกค่า, การป้องกันที่ storage |
เอกสารรองรับ แนวปฏิบัติที่แนะนำ และสิ่งที่ลูกค้าตั้งค่าเอง
มีระบุไว้ในเอกสารของ zcr
- zcrSOAR บันทึก timestamp, user, action, incident, playbook, connector, input, result และสถานะการรัน มีรายงาน audit และ dashboard ที่ drill-down ไปยัง incident, playbook execution, approval record และ evidence ได้ แต่ละขั้นของ playbook ตั้งเป็น Autonomous, Approval หรือ Blocked ประวัติ version ที่มีเอกสารรองรับครอบคลุม playbook
- zcrCTEM ซึ่งเป็นผลิตภัณฑ์ด้าน attack surface และ exposure บันทึกทุกคำตอบและร่างที่ AI สร้างไว้ใน audit trail ของตัวเอง พร้อม template และ version ที่อยู่เบื้องหลัง
- zcrSIEM เก็บ note, evidence และประวัติสถานะไว้กับ case แปลงคำถามเป็น query ที่ analyst ตรวจได้ และมี MFA, RBAC กับ audit trail ส่วน approval queue และการตอบสนองอัตโนมัติอยู่ที่ zcrSOAR เพราะ zcrSIEM ไม่รวม SOAR
- zcrLog เก็บข้อมูลจราจรทางคอมพิวเตอร์ พร้อม integrity check และการเข้ารหัส AES-128 ส่วน audit record ครอบคลุมการ sign-in, การเข้าถึง และการเปลี่ยนแปลงระบบ ซึ่งเป็นบันทึกฝั่งแพลตฟอร์ม ไม่ใช่ของ incident
แนวปฏิบัติที่แนะนำ
ใส่ case ID, หมายเลขขั้น และ timestamp แบบ UTC ในทุก record โดยชี้ไปที่ input แทนการคัดลอก ยกเว้นหลักฐานที่ต้นทางหมดอายุก่อน case ให้เก็บสำเนาที่ตรึงไว้ใน case เลือกระบบหนึ่งเป็นที่เก็บ case หลักและตั้งเวลาให้ตรงกัน เก็บ output ของ AI ตามตัวอักษรพร้อม template และ model version (ใน zcrSIEM ให้ใส่ใน analyst note) และบันทึกการแก้เป็น version ใหม่ ทุกไตรมาสให้ทำ replay drill โดยให้คนนอกทีม SOC ลองประกอบ case ที่ปิดแล้วหนึ่งเรื่องขึ้นใหม่จาก record อย่างเดียว
ลูกค้าต้องตั้งค่าเอง
คุณตั้งค่า retention ให้ครอบคลุมรอบ audit ตั้ง role และเส้นทางของผู้อนุมัติ และกำหนด gating รายขั้น (ให้ playbook ผ่าน Draft, Test, Dry-run หรือ Simulation Mode ก่อนใช้งานจริง) พร้อมตรวจว่า run record มีฟิลด์ของขั้น 6 ครบ
trail ขาดตรงไหน และเมื่อไรต้อง escalate
trail ที่ครบบอกได้เพียงว่ากระบวนการถูกทำตาม ส่วนเรื่อง model ตอบถูกหรือไม่ ให้คนสุ่มเทียบ output ของ AI กับข้อสรุปของ analyst จุดที่ trail อาจขาดมีดังนี้
- output ของ AI ไม่ถูกเก็บ หรือถูกแก้ทับ ขั้น 4 พิสูจน์ย้อนหลังไม่ได้ ให้หยุดพึ่ง output นั้น
- approval มาหลังการรัน ถ้าขั้นของ playbook นั้นเป็น Autonomous ถือว่าเป็นไปตามที่ออกแบบ ถ้าเป็น Approval หรือ Blocked ให้ถือเป็นความล้มเหลวของ control และหาว่ารันไปได้อย่างไร
- retention สั้นกว่าช่วงเวลาที่ถูกตรวจ หรือนาฬิกาของระบบไม่ตรงกัน raw event หายไปก่อนวันตรวจ หรือเรียงลำดับเหตุการณ์กลับมาไม่ได้
- audit data ที่ผู้ดูแลระบบลบได้ หรือมีข้อมูลส่วนบุคคลปนอยู่ AU-9 ให้ป้องกันการแก้ไขและการลบโดยไม่ได้รับอนุญาต ส่วนคำอธิบายของ AU-3 เตือนว่า input ที่บันทึกไว้อาจเปิดเผยข้อมูลส่วนบุคคล แนวปฏิบัติที่แนะนำคือแยกหน้าที่ระหว่างผู้ดูแลระบบกับผู้ตรวจ
ให้ escalate ไปที่เจ้าของงาน compliance และย้ายขั้นของ playbook ที่เกี่ยวข้องเป็น Approval หรือ Blocked เมื่อเกิดข้อใดข้อหนึ่งต่อไปนี้ คือ replay drill ล้มเหลว, พบ action ที่ไม่มี approval, หา output ของ AI ไม่เจอ หรือ storage พิสูจน์ไม่ได้ว่า record ไม่ถูกแก้
คำถามที่พบบ่อย
สรุปจาก AI ใช้เป็นบันทึกของ incident ได้ไหม?
ใช้เพียงอย่างเดียวไม่ได้ สรุปเป็นข้อความที่ model เรียบเรียงจากข้อมูลอื่น บันทึกจริงคือ event ต้นทาง query และการตัดสินใจ ให้แนบสรุปไว้พร้อม template, model version และ event ที่อ้างถึง
audit trail ต้องเก็บใน storage แบบ write-once ไหม?
ไม่จำเป็นเสมอไป ขึ้นกับว่ามาตรฐานหรือ auditor ของคุณกำหนดไว้หรือไม่ AU-9(1) ของ NIST ให้ใช้สื่อ write-once ที่บังคับด้วยฮาร์ดแวร์ ซึ่งต่างจากสื่อที่แค่ป้องกันการเขียน ถ้าต้องใช้ write-once ให้ยืนยันว่า platform และ deployment model ของคุณมีอะไรให้ แล้ว export สำเนาไปยัง storage ที่ตรงตามข้อกำหนด
ควรเก็บ record ของ AI นานแค่ไหน?
แนวปฏิบัติที่แนะนำคือเก็บอย่างน้อยเท่ากับ incident record ที่มันอธิบาย และให้ครอบคลุมรอบ audit ของคุณ zcrLog มีเอกสารระบุ 90 วันถึง 2 ปี ส่วน zcrSIEM เก็บ log ย้อนหลังอย่างน้อย 90 วัน แต่ตัวเลขเหล่านี้เป็นระยะเก็บ log ส่วน output ของ AI ที่เก็บใน case หรือ ticket เป็นไปตาม retention ที่ตั้งไว้ที่นั่น
แหล่งอ้างอิง
อ่านต่อ: AI Agent ระหว่างรับมือ Ransomware, Human-in-the-Loop SOC, คู่มือ AI SOC Agent และ Agentic Automation ใน SOAR ทำงานยังไง
ดู zcrSIEM · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้