หลัง Incident จบ ต้องรายงานอะไรบ้าง — หลักฐานที่ผู้บริหารและ Auditor ต้องการ
หลัง incident phishing หรือ ransomware จบ ผู้บริหารและ auditor ขอหลักฐานอะไร ดูว่ารายงานที่ตรวจสอบได้ต้องมีฟิลด์ไหน ใครอนุมัติ ตัดยอดเวลาไหน แก้ย้อนหลังได้ไหม
หลัง Incident จบ ต้องรายงานอะไรบ้าง — หลักฐานที่ผู้บริหารและ Auditor ต้องการ
เคสปิดไปแล้วสามสัปดาห์ อีเมลจาก auditor เด้งเข้ามา — "เหตุการณ์วันที่ 12 ใครเป็นคนอนุมัติให้ปิดบัญชีผู้ใช้ และอนุมัติตอนกี่โมง"
ทีมที่ทำเคสนั้นตอบได้แน่นอน เพราะยังจำได้อยู่ แต่ "จำได้" กับ "พิสูจน์ได้" เป็นคนละเรื่องกัน พอถูกขอเอกสาร สิ่งที่งอกออกมามักเป็นสไลด์ที่ทำย้อนหลัง กับ export CSV จาก ticket system ที่ไม่มีใครบอกได้ว่าดึงตอนไหน แก้ไปกี่รอบ และตัวเลขนับถึงวินาทีไหน
ผู้บริหารกับ auditor ถามคนละคำถาม
ผู้บริหารอยากรู้ว่า "เดือนนี้เราคุมอยู่ไหม" — ปริมาณเคส เวลาที่ใช้ตอบสนอง แนวโน้มดีขึ้นหรือแย่ลง เป็นคำถามเชิงบริหาร ตอบด้วยกราฟได้
auditor ถามอีกแบบ เขาไม่ได้สนใจว่าตัวเลขสวยหรือไม่สวย เขาสนใจว่า ตัวเลขนี้เชื่อได้ยังไง ใครเป็นคนสร้าง ใครเป็นคนอนุมัติ อนุมัติก่อนหรือหลังเผยแพร่ และถ้าเดือนหน้าดึงรายงานเดือนเดิมออกมาใหม่ ตัวเลขจะเท่าเดิมไหม
คำถามชุดหลังคือชุดที่ทำให้ทีม security ปวดหัวที่สุด เพราะระบบส่วนใหญ่ออกแบบมาให้ "ดูสถานะตอนนี้" ไม่ได้ออกแบบมาให้ "ยืนยันสถานะตอนนั้น"
ปัญหาจริงคือรายงานที่ขยับได้ตลอดเวลา
สมมติเคส phishing ที่มีคนกดลิงก์ไปแล้ว ทีมทำครบทุกอย่าง — บล็อกโดเมน รีเซ็ตรหัส เพิกถอน session ปิดเคส ถ้ากระบวนการตอบสนองรันผ่าน playbook อัตโนมัติ ทุก action ก็มี log อยู่แล้ว (ตัวอย่าง playbook รับมือ phishing เขียนไว้ละเอียดว่าแต่ละขั้นทำอะไรบ้าง)
ปัญหาไม่ได้อยู่ที่ log ปัญหาอยู่ที่ตอนแปลง log เป็นรายงาน
ดึงรายงาน "เดือนกรกฎาคม" วันที่ 3 สิงหาคม ได้ตัวเลขหนึ่ง ดึงอีกทีวันที่ 20 สิงหาคม ได้อีกตัวเลข เพราะระหว่างนั้นมีเคสเก่าถูกเปิดกลับมา มี alert ที่มาช้าโดนนับเข้าไป มีคนแก้ severity ย้อนหลัง ตัวเลขไม่ได้ผิด แต่มันไม่นิ่ง — และของที่ไม่นิ่งใช้เป็นหลักฐานไม่ได้
แล้วเรื่องเวลาอีก รายงานเขียนว่า "1–31 กรกฎาคม" ซึ่งฟังดูชัดเจนดี จนกระทั่งมีคนถามว่านับตามเวลาไทยหรือ UTC เพราะระบบ log ส่วนใหญ่เก็บเป็น UTC แต่คนอ่านรายงานอยู่ที่กรุงเทพฯ ต่างกัน 7 ชั่วโมง แปลว่าเคสที่เกิดคืนวันที่ 31 กรกฎาคมตอนสามทุ่ม อาจอยู่หรือไม่อยู่ในรายงานเดือนนั้นก็ได้ ขึ้นกับว่าใครเป็นคนตัดยอด
หลักฐานที่ใช้ได้จริงต้องตอบอะไรได้บ้าง
| คำถามที่มักโดนถาม | สิ่งที่ต้องมีในรายงาน |
|---|
| รายงานนี้ครอบคลุมช่วงเวลาไหนกันแน่ | ช่วงเวลาทั้งแบบ local และ UTC ระบุคู่กัน |
| ตัวเลขนับถึงจุดไหน | จุดตัดยอด (as-of) ที่ระบุชัดว่ารวมหรือไม่รวมขอบ |
| ใครอนุมัติ อนุมัติเมื่อไหร่ | ผู้อนุมัติ + timestamp แยกจากผู้เผยแพร่ |
| หลังเผยแพร่แล้วมีคนแก้ไหม | เลข revision + สถานะที่ล็อกการแก้ |
| ไฟล์ที่ถืออยู่ตรงกับต้นฉบับไหม | checksum ของ snapshot |
ห้าข้อนี้ไม่ใช่ของหรูหรา มันคือสิ่งที่แยก "รายงาน" ออกจาก "หลักฐาน" และเป็นเหตุผลที่ zcrSOAR แยกหน้า evidence ออกมาต่างหากจากหน้า dashboard ปกติ แทนที่จะให้ export PDF จากหน้าเดียวกันแล้วหวังว่าจะพอ
หน้าตาจริงเป็นยังไง
หน้า Monthly operations reports ใน zcrSOAR demo อธิบายตัวเองไว้ตรงหัวข้อว่าเป็น "a frozen English evidence record for each closed month" — บันทึกที่แช่แข็งไว้ต่อหนึ่งเดือนที่ปิดรอบแล้ว มีป้าย Checksum-backed กำกับอยู่ด้านขวา
สถานะมีสามขั้น หน้า register ของ demo แสดงสถานะ Draft, Approved และ Published พร้อมกันได้ในหน้าเดียว แม้แต่ปุ่มที่กดสร้างก็ไม่ได้เขียนว่า "สร้างรายงาน" แต่เขียนตรงๆ ว่า Generate draft คือได้ draft ออกมาก่อน แล้วค่อยเดินไปตามสถานะทีละขั้น โดยเวลาที่บันทึกไว้ในขั้น "อนุมัติ" จะเกิดก่อนเวลาที่บันทึกไว้ในขั้น "เผยแพร่" เสมอ (ตัวเลขวันที่จริงในภาพ demo เป็นข้อมูลตัวอย่าง ไม่ใช่ช่วงเวลารายงานจริง)
เวลาถูกระบุสองแบบคู่กัน แต่ละรายการแสดงช่วงเวลาแบบ local (Asia/Bangkok) และแบบ UTC คู่กันเสมอ พร้อมระบุว่าขอบเขตท้ายช่วงเป็นแบบ inclusive หรือไม่ — คำสองคำนี้ทำให้คนอ่านคำนวณเส้นแบ่งเองได้จากตัวเอกสาร ไม่ต้องไปตามถามคนที่กดปุ่ม ยังมีช่อง as-of แยกอีกช่องที่กำกับว่าเป็น exclusive bound และในกล่องสร้างรายงานเองก็เขียนกำกับไว้ว่า "the server freezes the as-of to the period end" — จุดตัดยอดมาจากฝั่งเซิร์ฟเวอร์ ไม่ใช่ตัวเลขที่ใครพิมพ์ใส่เอง (ช่วงเวลาที่ปรากฏในภาพ demo เป็นตัวอย่าง ไม่ใช่ตัวเลขที่ยืนยันสำหรับรอบรายงานจริง)
ผู้อนุมัติกับผู้เผยแพร่เป็นคนละช่อง ช่อง Approved by และ Published by แยกกัน แต่ละช่องมี timestamp ของตัวเอง ขอพูดให้ตรง — ในหน้า demo ช่อง Approved by แสดงเป็นรหัสผู้ใช้ภายใน ไม่ใช่ชื่อคน และ Published by เขียนไว้แค่ว่า recorded ดังนั้นสิ่งที่ยืนยันได้จากหน้าจอคือ ระบบแยกบันทึก "การอนุมัติ" กับ "การเผยแพร่" ออกจากกันพร้อมเวลาของแต่ละอัน ซึ่งเป็นวัตถุดิบที่ auditor ใช้ตรวจ segregation of duties ส่วนจะให้ขึ้นเป็นชื่อคนจริงหรือไม่ อยู่ที่การเชื่อมกับระบบ identity ของแต่ละองค์กร
เผยแพร่แล้วแก้ไม่ได้ กล่อง Publication rule เขียนไว้ตรงๆ ว่า published runs are immutable และถ้าจะแก้ต้องออกเป็น revision ใหม่พร้อมระบุเหตุผล โดยฉบับเดิมยังตรวจสอบย้อนหลังได้อยู่ ทุกแถวใน register จึงมีเลข revision กำกับไว้ทุกแถว ไม่ใช่แค่แถวที่เคยถูกแก้
มี checksum ของ snapshot ท้ายรายการมีช่อง Snapshot checksum ประโยชน์ของมันตรงไปตรงมา — ถ้าอีกหกเดือนมีคนส่งไฟล์รายงานเดือนกรกฎาคมมาให้ตรวจ เทียบ checksum ก็รู้ทันทีว่าเป็นฉบับเดียวกับที่เผยแพร่ไว้หรือถูกแก้ระหว่างทาง
ทั้งหมดนี้คือ metadata ล้วนๆ ไม่มีอะไรเกี่ยวกับความสามารถในการตรวจจับเลย แต่มันคือส่วนที่ทำให้ผลของการตรวจจับเอาไปใช้อ้างอิงได้จริง
สิ่งที่รายงานแบบนี้ทำไม่ได้ — พูดตรงๆ
หนึ่ง — เนื้อรายงานเป็นภาษาอังกฤษ หน้านี้ระบุชัดว่าเป็น "frozen English evidence record" ซึ่งเหมาะกับ auditor ต่างชาติหรือทีม compliance ที่ทำงานเป็นอังกฤษอยู่แล้ว แต่ถ้าต้องเข้าบอร์ดไทยหรือส่งหน่วยงานกำกับในประเทศ ยังต้องมีขั้นแปลและเรียบเรียงเพิ่มอยู่ดี — zcrSOAR ให้ตัวหลักฐานที่นิ่งและอ้างอิงได้ ไม่ได้ให้สไลด์พร้อมนำเสนอ
สอง — นี่คือรายงานรอบเดือนที่ปิดแล้ว ไม่ใช่เอกสารแจ้งเหตุ เวลาเกิดเหตุข้อมูลรั่วแล้วต้องแจ้งภายในกรอบเวลาที่กฎหมายกำหนด สิ่งที่ต้องส่งคือรายละเอียดเหตุการณ์เฉพาะเคสนั้น ไม่ใช่สรุปทั้งเดือน รายงานรอบเดือนมีประโยชน์ในฐานะหลักฐานประกอบว่ากระบวนการทำงานอยู่จริงและต่อเนื่อง แต่ไม่ได้แทนกัน — ใครที่ยังไม่แน่ใจว่าต้องเตรียมอะไรบ้างสำหรับฝั่ง PDPA ลองไล่ตาม เช็กลิสต์ 8 ข้อ ดูก่อน
สาม — ไม่ใช่รายงานสืบสวน หลักฐานชุดนี้ตอบว่า "ทำอะไรไปบ้าง ใครอนุมัติ เมื่อไหร่" ไม่ได้ตอบว่า "ผู้โจมตีเข้ามาทางไหน และไปถึงไหนแล้ว" การเล่าเส้นทางการโจมตีเป็นงานคนละชิ้น (การอ่าน attack flow เทียบกับ MITRE ATT&CK อธิบายฝั่งนั้นไว้แล้ว) ในทางปฏิบัติรายงานหลัง incident ที่สมบูรณ์มักต้องใช้ทั้งสองชิ้นประกอบกัน
สัญญาณว่าเรื่องนี้เกี่ยวกับคุณ
- ถูกขอรายงานย้อนหลังทีไร ต้องนั่งไล่ ticket ประกอบใหม่ทุกครั้ง
- ดึงรายงานเดือนเดิมสองรอบแล้วได้ตัวเลขไม่ตรงกัน แต่อธิบายไม่ได้ว่าเพราะอะไร
- ไม่มีใครตอบได้ว่ารายงานเดือนที่แล้วใครเป็นคนอนุมัติ
- รายงานที่ส่งผู้บริหารเป็นไฟล์ที่แก้ได้ และไม่รู้ว่าเวอร์ชันที่เขาเปิดอยู่คือเวอร์ชันไหน
- เอกสารเขียนแค่ "เดือนกรกฎาคม" โดยไม่ระบุ timezone
เข้าข่ายสองข้อขึ้นไปแปลว่าปัญหาไม่ได้อยู่ที่การตรวจจับ แต่อยู่ที่ขั้นตอนหลังจากนั้น การเพิ่มเครื่องมือตรวจจับอีกตัวไม่ช่วยอะไรเลยกับคำถามชุดนี้
เริ่มจากตรงไหนดี
ถ้ากระบวนการตอบสนองของคุณยังทำมือเป็นหลัก ขั้นแรกคือทำให้ action แต่ละอย่างถูกบันทึกอัตโนมัติก่อน (SOAR คืออะไร อธิบายพื้นฐานส่วนนี้ไว้) เพราะหลักฐานที่ดีที่สุดคือหลักฐานที่เกิดขึ้นเองระหว่างทำงาน ไม่ใช่ที่มานั่งกรอกทีหลัง
จากนั้นค่อยจัดการชั้นรายงาน — ซึ่งเป็นส่วนที่ zcrSOAR จัดให้เป็นรอบที่มีสถานะและการอนุมัติกำกับ ตั้งแต่ draft ไปจนถึง published พร้อมเลข revision และ checksum ทุกแถว และถ้าอยากดูว่าแพ็กเกจไหนครอบคลุมส่วนนี้บ้าง หน้าราคา มีรายละเอียดอยู่ หรือจะเปิด zcrSOAR demo ดูหน้า evidence จริงๆ ด้วยตัวเองก่อนตัดสินใจก็ได้
ติดต่อทีมงาน
อยากรู้ว่ารายงานหลัง incident ที่ทีมคุณส่งอยู่ตอนนี้ ตอบคำถาม auditor ได้ครบไหม คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย
แหล่งข้อมูลอ้างอิง
- พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) — ข้อกำหนดการแจ้งเหตุข้อมูลรั่วไหล (ไม่ระบุกรอบเวลาเป็นชั่วโมงในบทความนี้ เพราะขึ้นกับลักษณะเหตุการณ์และดุลยพินิจของเจ้าหน้าที่คุ้มครองข้อมูล)
- NIST SP 800-92 — Guide to Computer Security Log Management — หลักการทั่วไปด้าน log integrity และการเก็บหลักฐาน