ภาพในหัว: 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 (Operating System / ระบบปฏิบัติการ) 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 (Closed-Circuit Television / กล้องวงจรปิด) ของนิคม เก็บภาพ local ที่ DVR (Digital Video Recorder / เครื่องบันทึกภาพดิจิทัล) ของแต่ละอาคาร

วันหนึ่งมีของหายในห้อง 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 (Database Administrator / ผู้ดูแลฐานข้อมูล) มี full access

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

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

control ที่ขาด: SoD (Segregation of Duties / การแยกหน้าที่) ระหว่างคนคุมระบบกับคนคุม 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 (Personal Data Protection Act / พรบ.คุ้มครองข้อมูลส่วนบุคคล) ของไทยกำหนดบางระยะเวลาสำหรับ 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 แล้วลืมมิติอื่นไปเลย

OLA — สัญญาภายในที่ทำให้ SLA ภายนอกเกิดจริง#

SLA เป็นสัญญาระหว่าง vendor กับลูกค้า (หรือระหว่าง IT department กับ business unit) แต่บริการ IT ส่วนใหญ่ต้องอาศัยทีมหลายทีมต่อกันถึงจะส่งมอบได้

ตรงนี้แหละที่ OLA (Operating Level Agreement / สัญญาระดับการให้บริการระหว่างทีมภายใน) เข้ามา — OLA = สัญญาระหว่างทีมภายในด้วยกันเอง ที่ทำให้ SLA ภายนอกเกิดได้จริง

ลองนึก: ลูกค้าจ่ายให้บริษัทรับ SLA “P1 incident resolve ภายใน 4 ชั่วโมง” ภายในบริษัทมีทีม helpdesk รับเรื่อง → ส่งต่อทีม network → ส่งต่อทีม application

OLA คือสัญญาภายในที่บอกว่า:

• ทีม network ต้องตอบ helpdesk ภายใน 1 ชั่วโมงหลังรับ ticket
• ทีม application ต้อง deploy hotfix ภายใน 2 ชั่วโมงหลัง network confirm
• helpdesk closeout ภายใน 30 นาทีหลัง fix

รวมกันเข้า → 4 ชั่วโมง = ตรงกับ SLA ที่สัญญากับลูกค้า

ถ้าไม่มี OLA แต่ละทีมก็ optimize ของตัวเอง แต่รวมแล้วทะลุ SLA — ทีม network ใช้ 2 ชั่วโมง, application ใช้ 3 ชั่วโมง = SLA หลุดทันที โดยไม่มีใคร “ผิด” คนเดียวเลย

กฎสำคัญ: SLA ที่ไม่มี OLA backing = สัญญาที่ตั้งใจดีแต่ไม่มีโครงสร้างให้เกิด ทีมภายในต้องมี measurable commitment กันเองก่อน SLA ภายนอกถึงจะ achievable

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

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

ธนาคารแห่งหนึ่งกำหนด ATM (Automated Teller Machine / ตู้กดเงินอัตโนมัติ) 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 (Electronic Medical Records / เวชระเบียนอิเล็กทรอนิกส์) system แบบ SaaS (Software as a Service / ซอฟต์แวร์แบบบริการบนคลาวด์) 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 (Service Organization Controls — รายงานตรวจสอบ control ของ service provider) 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 มั้ย?

Network Management Tools — 5 ตัวที่ป้อน metric ให้ SLA#

SLA เรื่อง availability, response time, downtime วัดด้วยอะไร? CRM 4.7.3 list เครื่องมือ network management 5 ประเภทที่ป้อนตัวเลขให้กับ SLA report:

มุม IS auditor: ก่อนเชื่อ SLA report ที่ vendor ส่งมา ขอดูว่า metric มาจาก tool ไหนใน 5 ตัวนี้ และ tool นั้นเก็บข้อมูลจาก source เดียวกับที่ business ใช้จริงรึเปล่า — บางที่ vendor วัด availability จาก ping network device แต่ไม่ได้วัดจาก application end-user เห็น

Trap pattern เรื่อง SLA#