ประเภทที่ 1 — Major Release#

• เนื้อหา: feature ใหม่, architecture change, integration ใหม่
• ความถี่: น้อยที่สุด (รายไตรมาส / ราย 6 เดือน)
• process: เต็มรูปแบบ — RFC, impact analysis, testing ใน UAT, sign-off, scheduled deployment, post-implementation review
• backout plan: ต้องมี + ทดสอบแล้ว

ประเภทที่ 2 — Minor Release#

• เนื้อหา: bug fix เล็กๆ, configuration tweak, parameter change
• ความถี่: บ่อย (รายเดือน / รายสัปดาห์)
• process: ลดทอนแต่ยังครบ — minor RFC, peer review, testing แบบ smoke test, sign-off
• backout plan: ต้องมี

ประเภทที่ 3 — Emergency Release#

• เนื้อหา: critical bug, security patch ที่ห้ามรอ, production hot fix
• ความถี่: ตอนเกิดเหตุจริง
• process: เร็วแต่ยังควบคุม — verbal approval ก่อน, written ตามหลัง, mandatory post-implementation review
• backout plan: ต้องมี (เพราะ urgency = ไม่ได้ test เต็ม → risk สูง)

Trap ใหญ่ที่สุดของ exam — Emergency change ≠ no controls#

ที่ผมว่าอันตรายและ exam ออกแน่ๆ:

“Emergency = ไม่ต้องผ่าน process” — ผิด

emergency change ยังต้องมี:

• authorization (อาจเป็น verbal ก่อน, written ตาม)
• logging (ทุก action ที่ทำ)
• post-hoc review (review ภายใน X วัน)

ถ้าองค์กรไหน emergency change > 10% ของทั้งหมด → flag finding ทันที เพราะนั่นคือ sign ของ process avoidance — ทีม dev ใช้ “emergency” เป็นข้ออ้าง bypass change management

ตัวอย่างจริง: e-commerce platform ที่ผมเจอ — 6 เดือน apply emergency change 140 ครั้ง 23 ครั้งสร้าง incident ใหม่ ไม่มี post-implementation review เลย

นี่ไม่ใช่ “emergency” — นี่คือ change management ที่ตายไปแล้ว

Patch ≠ optional#

ทำไม security patch ถึงเป็นเรื่องด่วน?

เพราะ — เมื่อ vendor ออก patch สาธารณะ = vulnerability นั้นถูกเปิดเผยแล้ว hacker รู้แล้วว่าจะเข้ามาจากตรงไหน

ทุกวันที่ผ่านไปโดยไม่ติด patch = วันที่ attacker รู้แต่เราไม่ได้ปิดประตู

แต่ patch ก็ไม่ใช่ “apply ทันที” เสมอ#

นี่คือความขัดแย้งของ patch management:

• ติดเร็ว → กันโจรเร็ว แต่อาจ break production
• ติดช้า → ไม่ break แต่เปิด window ให้โจรนาน

วิธีที่ work: test → stage → production ในระยะเวลาที่กำหนด

สำหรับ patch ที่มี exploit ใน the wild แล้ว — timeline จะสั้นลงทันที (24-48 ชั่วโมงทั้ง pipeline)

กรณีจริง: SCADA factory ที่ Bangpoo#

โรงงานแห่งหนึ่ง — ทีม IT apply OS patch ให้กับเครื่อง production control ในเย็นวันศุกร์ โดยไม่ test ก่อน

patch มี compatibility issue กับ SCADA system — Monday เช้า production start ไม่ได้

ลอง rollback — แต่ไม่มี documented backout procedure

ใช้เวลา 6 ชั่วโมง restore จาก backup → เสียกะการผลิตทั้งวัน

control gap ทุกชั้น:

• ไม่มี test environment ก่อนลง production
• ไม่มี documented backout plan
• ลง patch เย็นวันศุกร์ (= “Friday deployment” anti-pattern — ถ้าพังเสาร์อาทิตย์ไม่มีใครแก้)

CMDB คืออะไร#

CMDB (Configuration Management Database) = ฐานข้อมูลที่บันทึกว่า ระบบของเราตอนนี้ configure ยังไง

• server แต่ละตัวรัน OS version อะไร? patch level เท่าไหร่?
• database parameter set ยังไง?
• network device firewall rule ปัจจุบัน?
• ระบบ A กับ B เชื่อมกันที่ port อะไร?

ถ้า CMDB accurate — auditor ตอบคำถาม “ระบบเรามีอะไรอยู่บ้าง” ได้

ถ้า CMDB outdated หรือไม่มี — ทุก control downstream ก็เดิน blind

กรณี hospital DB parameter#

โรงพยาบาลแห่งหนึ่ง — developer เปลี่ยน “timeout parameter” ใน database เพื่อปรับ performance

parameter นั้น โดยบังเอิญ — disable audit logging ของการ access ผู้ป่วย

2 สัปดาห์ต่อมา — investigation เรื่อง data breach ต้องการ audit log → log ไม่อยู่

control gap:

• configuration change ของ database ไม่ผ่าน change management
• ไม่มี security review สำหรับ configuration change
• ไม่มี monitoring ว่า audit logging กำลัง active อยู่หรือไม่

นี่คือเหตุผลที่ — configuration change ทุกตัวต้องผ่าน process ไม่ว่าจะดู minor แค่ไหน