ภาพในหัว: 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#