ประเภทที่ 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

ตัวอย่าง pattern คลาสสิคของวงการ: e-commerce platform บางที่ใน 6 เดือน apply emergency change หลายร้อยครั้ง และเกือบ 1 ใน 6 ของ emergency change สร้าง 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 แค่ไหน

หลักการ: check-in / check-out + version + library#

Source code library = ที่เก็บ source code ที่มี:

• Version control — ทุก commit มี version + author + timestamp
• Check-out / check-in — developer ที่จะแก้ → check-out → แก้ → ทดสอบ → check-in กลับ
• Branch protection — ห้าม commit ตรงไปยัง production / main branch
• Code review — ก่อน merge ต้องมี reviewer คนอื่น approve

ในยุค Git/GitHub concept พวกนี้ implement ผ่าน pull request + branch protection rule

Production code ≠ Development code#

กฎเหล็ก: code ที่ run ใน production ต้องตรงกับ version ที่ checked-in + tested + approved

ถ้า developer ลอง edit production code ตรงๆ (hot fix แบบ console) โดยไม่ผ่าน source library → CMDB กับ source library ไม่ตรงกัน เป็น control gap ระดับร้ายแรง

ตัวอย่างจริง#

โรงงานแห่งหนึ่ง developer แก้ bug ใน production server ตรงๆ โดย SSH เข้าไปแก้ไฟล์

• Source library ยังมี version เก่า
• 2 สัปดาห์ต่อมา มี deployment ใหม่จาก source library → overwrite hot fix → bug กลับมา
• ไม่มีใครรู้ว่าทำไม bug “หายไปแล้วกลับมา” 555+

control gap: production code ไม่ sync กับ source library + ไม่มี FIM ที่ alert

มุม IS Auditor#

• Reconciliation — ระหว่าง production binary กับ source library ตรงไหม (ใช้ hash compare)
• Access control — ใครมีสิทธิ์ check-in / merge / approve PR
• SoD ใน source pipeline — developer ≠ reviewer ≠ release manager
• Audit trail — ทุก change มี traceability กลับไป commit + approver + ticket

Software piracy ≠ ปัญหาเฉพาะ pirated copy#

หลายคนคิดว่า software licensing risk = “บริษัทใช้ software เถื่อน”

จริงๆ แล้ว bigger risk คือ license non-compliance ของ software ที่ซื้อถูกต้องต่างหาก

ตัวอย่างที่เจอบ่อย:

• ซื้อ license สำหรับ 100 user — install จริง 130 user (เกิน license)
• ซื้อ license แบบ named user — แชร์ account ให้หลายคน (ผิดเงื่อนไข)
• ซื้อ license สำหรับ on-premise — install ใน virtual machine ที่ migrate ไป cloud (license ไม่คลุม)
• ซื้อ Oracle Database Standard Edition — รัน feature ของ Enterprise Edition (audit แตก)

กฎเหล็กของ vendor (Microsoft, Oracle, SAP): vendor มีสิทธิ์ audit การใช้ software ของลูกค้าได้ ถ้าเกิน license จริง ค่าปรับมหาศาล + retroactive licensing fee เลยครับ

Vendor License Audit#

vendor ใหญ่มี dedicated team ที่ทำ license audit:

• Microsoft Software Asset Management (SAM)
• Oracle License Management Services (LMS)
• BSA (Business Software Alliance) — ตัวกลางที่ enforce license สำหรับ vendor หลายราย รวมถึงในไทย

ถ้า audit แตก — penalty อาจ 3-5 เท่า ของ license cost จริง + back-payment

ตัวอย่างจริงในไทย#

บริษัทขนาดกลางในไทย ใช้ Microsoft Office + Adobe Creative Suite

เริ่มซื้อ license 50 ชุด → growth เป็น 80 พนักงาน IT install เพิ่มแต่ไม่ซื้อ license เพิ่ม

3 ปีต่อมา Microsoft initiate audit (จากการ license tracking ของ Office activation)

ผลลัพธ์: pay back-licensing 3 ปี + penalty + true-up licensing สำหรับ 30 user ที่เกิน เจ็บมาก

มุม IS Auditor — License Compliance Audit#

5 จุดที่ตรวจ:

• License inventory — จำนวน license ที่ purchased + entitlement detail
• Deployment count — install จริงในระบบมีกี่เครื่อง / กี่ user
• Usage reconciliation — license usage ≤ entitlement
• License terms compliance — concurrent vs named, on-prem vs cloud, geographical scope
• Open source compliance — open source library มี license terms (MIT, GPL, Apache) ที่ business ต้อง comply (โดยเฉพาะ GPL ที่บังคับเปิด source)

มุมที่ผู้บริหารต้องเข้าใจ: software license = legal liability ไม่ใช่แค่ procurement issue ผู้บริหารที่ตอบ “IT ดูแลเรื่องนี้แทน” → ตอน vendor audit แตกแล้วไม่มีทางหนีนะครับ