ภาพในหัว: Black Box ของเครื่องบิน#

ทุกเครื่องบินพาณิชย์มี black box — กล่องที่บันทึกทุกอย่างที่เกิดขึ้นในห้อง cockpit + sensor ของเครื่อง

วันที่เครื่องบินบินวันธรรมดา black box ทำงานเงียบๆ ไม่มีใครสนใจ

วันที่เครื่องบินตก black box คือสิ่งแรกที่ investigator ขอ เพราะมันคือสิ่งเดียวที่บอกได้ว่าเกิดอะไรในนาทีสุดท้าย

log ขององค์กรก็แบบนี้แหละครับ วันธรรมดามันไม่มีค่า แต่วันที่ incident เกิด, breach เกิด, dispute เกิด, regulator ขอตรวจ — log คือสิ่งเดียวที่ตอบได้

ประเภทของ log ที่ auditor ต้องรู้#

CRM list log ไว้ 8 ประเภท ขอ group ใหม่ตามจุดประสงค์ดีกว่า:

Group 1 — Operations log (สำหรับ run ระบบ)

• System log — OS startup, shutdown, error
• Server log — activity ของ server แต่ละเครื่อง
• Event log — network traffic, login attempt

Group 2 — Compliance log (สำหรับ audit trail)

• Change log — ใครเปลี่ยนอะไร
• Audit log — สำหรับ reconstruction event
• Database log — INSERT/UPDATE/DELETE

Group 3 — Security log (สำหรับจับการโจมตี)

• Security log — security threshold event
• Access control log — ใคร access อะไร เมื่อไหร่

แต่ละ group มี integrity requirement ต่างกัน — security log ต้องการ tamper-proof สูงสุด

Log management cycle — 6 ขั้นที่ต้องครบ#

log ไม่ใช่แค่ “เก็บไว้เฉยๆ” นะครับ มันมี cycle ที่ต้องครบ:

1. Collect — เก็บจากทุก source
2. Generate alert — ตั้ง rule ที่จับ anomaly
3. Store — เก็บ + protect from tampering
4. Analyze — วิเคราะห์ pattern
5. Report — ส่งสรุปให้คนที่ relevant
6. Action — แก้ไข / improve

ถ้าขาดขั้นไหน log ก็แค่กองข้อมูลที่เก็บไว้แพงๆ ไม่ได้เป็น control อะไร

กรณีศึกษาที่เห็นซ้ำในวงการ#

กรณี 1 — DVR ที่นิคมอุตสาหกรรม: ระบบกล้อง CCTV ของนิคม เก็บภาพ local ที่ DVR ของแต่ละอาคาร

วันหนึ่งมีของหายในห้อง server ทีม facility ไป pull DVR หาภาพย้อนหลัง

พบว่า DVR drive ของอาคารนั้น “ถูก overwrite” ในสัปดาห์ก่อนเหตุ มี IT staff คนหนึ่งเข้าห้อง server ในช่วงเวลานั้นพอดี

control gap:

• log เก็บใน server เดียวกับที่ admin มี physical access
• ไม่มี centralized log storage
• ไม่มี write-protection

สรุป: กล้องวงจรปิดที่ภาพถูกลบได้ = ไม่ใช่ control

กรณี 2 — โรงพยาบาลที่ DBA controls log: มีข้อร้องเรียน patient คนหนึ่งบอกว่า medical record ของตนถูก access โดยคนที่ไม่ควร

ทีม IT ไป pull access log → log เก็บใน application server เดียวกันที่ DBA มี full access

ปัญหา: DBA คือคนเดียวที่อาจถูกสงสัย แต่ก็เป็นคนเดียวที่อาจ modify log ได้ด้วย

log ที่ใช้ใน investigation ก็ใช้เป็นหลักฐานน่าเชื่อถือไม่ได้

control ที่ขาด: SoD ระหว่างคนคุมระบบกับคนคุม log

SIEM: ตั้งแล้วต้อง calibrate#

SIEM (Security Information and Event Management) = system ที่ centralize log + correlate + alert

หลายองค์กรลงทุนซื้อ SIEM ราคาหลักล้าน แต่ใช้งานไม่ได้ซะงั้น

ทำไม? เพราะ ตั้งแต่วันแรกถึงวันนี้ ไม่เคย calibrate threshold เลย

ตัวอย่างจริง: e-commerce platform ที่กรุงเทพ ติด WAF (Web Application Firewall) ที่ block 500 suspicious request ต่อวัน ตั้ง SIEM alert “ถ้าเกิน 1000 request ต่อชั่วโมง”

attacker ที่ฉลาดก็รู้ตัวเลข threshold พวกนี้ → ค่อยๆ ยิง 50 request/ชั่วโมง

6 วันต่อมา สำเร็จ exfiltrate ข้อมูลลูกค้า

SIEM ทำงานตามที่ถูกตั้งค่า แต่threshold ผิด ก็เลยจบ

บทเรียน: มี SIEM ≠ มี security monitoring นะ SIEM ที่ไม่ calibrate = false sense of security ชัดๆ

Log retention: balance ระหว่างกฎหมายกับ cost#

retention period ของ log ต้อง align กับ:

• Legal/regulatory — PDPA ของไทยกำหนดบางระยะเวลาสำหรับ data processing log, ธปท. กำหนดอีกตัวสำหรับธนาคาร, ก.ล.ต. อีกตัว
• Audit investigation timeline — typical = 7 ปี
• Cost of storage — เก็บมากเกิน = แพง
• Privacy concern — log ที่มี personal data ก็ต้องลบเมื่อหมดวัตถุประสงค์

ที่หลายคนพลาด — assume “เก็บมากที่สุด = ดีที่สุด” ไม่ใช่นะครับ retention policy ต้องเฉพาะเจาะจง

Trap pattern เรื่อง log#

เรื่องที่ผมเก็บไว้สำหรับ D5#

log management ใน D4 = operations focus — เก็บ log สำหรับ run + audit trail

ใน D5 จะกลับมาที่ log อีกครั้งในมุม security — SIEM, SOC, threat hunting — ใช้ log ในการจับ attacker

เดี๋ยว D5 จะลงเรื่อง SIEM operations ละเอียด

SLA ทำให้ “service ดี” จับต้องได้#

ก่อนมี SLA IT กับ business เข้าใจคำว่า “service ดี” ไม่ตรงกัน

• IT — “เราตั้งใจดูแลระบบให้เต็มที่ครับ”
• Business — “ระบบล่ม 4 ชั่วโมงต่อเดือน เป็น ‘ดี’ มั้ย?”

SLA = เปลี่ยนจากความ subjective เป็น measurable contract นั่นเอง

SLA components ที่ครบควรมี#

ที่หลายองค์กรพลาดคือ focus เฉพาะ availability แล้วลืมมิติอื่นไปเลย

Trap ใหญ่ที่สุด: meet SLA ≠ ดี#

ตัวอย่างที่ผมว่าน่าจำที่สุด:

ธนาคารแห่งหนึ่งกำหนด ATM availability = 99.8% / เดือน

รายงานเดือน X IT รายงาน 99.82% ผ่าน SLA

แต่อ้าว 90% ของ downtime ในเดือนนั้น เกิดที่ช่วง 5 โมงเย็น - 2 ทุ่ม (peak time ของการกดเงิน) แล้วยัง concentrate อยู่ที่ 15 สาขาในกรุงเทพที่คนใช้เยอะที่สุดอีกต่างหาก

ตัวเลขผ่าน SLA ก็จริง แต่ลูกค้าด่ายับ

control gap: SLA design ไม่ capture business impact — aggregate uptime มันปกปิด pattern ของ downtime ที่กระทบจริงๆ

แก้ยังไง? — เพิ่ม SLA dimension:

• “uptime during peak hours (5pm-8pm) ต้อง > 99.95%”
• “downtime ที่สาขา top-15 ต้อง < X minute / month”

SLA แบบ outsource: accountability ไม่ outsource#

เรื่องที่ exam ออกแน่ๆ:

outsource service ≠ outsource accountability

เมื่อองค์กร outsource IT service ไปให้ vendor — responsibility ในการทำงานไป vendor แต่accountability ต่อลูกค้า regulator board ยังอยู่กับองค์กรเหมือนเดิม

ตัวอย่างจริง: โรงพยาบาลแห่งหนึ่งใช้ EMR system แบบ SaaS vendor ให้ uptime SLA 99.9%

vendor ส่งรายงานทุกเดือนว่า 99.9% โรงพยาบาลรับรองทุกเดือนโดยไม่ verify

วันหนึ่ง security incident ที่ data center ของ vendor → ข้อมูลผู้ป่วยรั่ว

ตอน investigation พบว่า “uptime” ที่ vendor คำนวณ ไม่นับ planned maintenance window ที่ระบบ accessible แบบไม่ patch ด้วย

แต่ในมุม regulator โรงพยาบาลคือ data controller ตาม PDPA ไม่ใช่ vendor

ความรับผิดชอบทางกฎหมาย = โรงพยาบาล ครบเลย

เชื่อม ตอน 19 (Vendor Management) ที่คุยเรื่อง SOC report + outsourcing controls

สิ่งที่ auditor ต้องตรวจสำหรับ outsourced SLA#

3 ข้อหลัก:

1. SOC 1/SOC 2 report ของ vendor — มี? อายุไม่เกิน 1 ปี? scope ครอบคลุมระบบที่ใช้?
2. Independent verification — มี monitoring ฝั่งเรา ไม่ใช่ trust report ของ vendor อย่างเดียว
3. Right-to-audit clause — ในสัญญา มีสิทธิ์ไป audit vendor มั้ย?

Trap pattern เรื่อง SLA#