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

• เนื้อหา: feature ใหม่, architecture change, integration ใหม่
• ความถี่: น้อยที่สุด (รายไตรมาส / ราย 6 เดือน)
• process: เต็มรูปแบบ — RFC (Request for Change / คำขอเปลี่ยนแปลง), impact analysis, testing ใน UAT (User Acceptance Testing / การทดสอบให้ผู้ใช้ยอมรับระบบ), 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 (Operating System / ระบบปฏิบัติการ) patch ให้เครื่อง production control ในเย็นวันศุกร์ โดยไม่ test ก่อน

patch มี compatibility issue กับ SCADA (Supervisory Control and Data Acquisition / ระบบควบคุมและเก็บข้อมูลในโรงงาน) 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 แค่ไหน

IS Operations staff ทำอะไรบ้าง#

พอเห็น job description ของทีมนี้ในหนังสือ หลายคนจะนึกว่าเป็นหลายตำแหน่ง จริงๆ มันคือบทบาทเดียวกัน ที่คลุมงาน 7 อย่าง:

• จัด job schedules — งาน batch / cron / scheduled job ต้องวิ่งตรงเวลา
• ทำ backup ตามรอบที่กำหนด
• กัน unauthorized access ของ sensitive data
• Monitor + review ว่าทีมทำตาม procedure ที่ผู้บริหารกำหนดไว้ไหม
• ร่วมทดสอบ DRP (disaster recovery plan)
• Monitor performance / capacity / availability / failure ของ information resources
• Troubleshooting + incident handling เวลามีของพัง

จะเห็นว่าไม่ใช่ “operator นั่งกดปุ่ม” อย่างที่หลายคนเข้าใจ คือคนที่ถือกุญแจระบบทั้งหมดในมือเลยครับ

Operations documentation set ที่ต้องมี#

CRM ระบุว่าทุก IS operations function ต้องมีเอกสาร 5 ชุด ขั้นต่ำ:

ถ้าเอกสารเหล่านี้ขาดสักชุด = control gap ที่ผู้สอบบัญชีต้อง flag ทันที

Operator access controls + operator manuals#

จุดที่ exam ชอบหลอก — operator ≠ คนเขียน code ≠ คนใช้ระบบ operator คือคนที่มีสิทธิ์ run / restart / monitor production system

control ที่ต้องดู:

• จำกัดสิทธิ์ของ operator ไม่ให้แตะ source code library + production data libraries
• utility ที่ใช้ patch software / data ต้องจำกัดสิทธิ์เป็น case-by-case
• operator manual ต้องครอบคลุม: วิธีคุมเครื่อง + peripheral / startup-shutdown / กรณี machine หรือ program fail / record ที่ต้องเก็บ / สิ่งที่ห้ามทำ

operator ที่ทำงานโดยไม่มี manual = ทำงานตามความจำ วันที่จำผิดก็คือวัน outage

Librarian role + media library — คนละเรื่องกับ source code library#

ตรงนี้สำคัญมากครับ เพราะคำว่า “library” ใน CRM มีสองความหมาย คนละโลกเลย:

• Source code library (ที่คุยใน section ถัดไป) = ที่เก็บ source code ของ developer
• Media library (ที่คุยตรงนี้) = ที่เก็บ physical media — tape backup, removable disk, optical media, sensitive print-out

Librarian คือคนที่ดูแล media library ตัวเป็นๆ ไม่ใช่ผู้คุม Git repo ครับ control ที่ต้องมี:

• Labeling — ทุกตลับ / disk / tape มี label ว่าเก็บอะไร classification ระดับไหน
• Check-in / check-out — บันทึกว่าใครหยิบ media ออกไปเมื่อไหร่ คืนเมื่อไหร่
• Receipt / return — librarian รับ + ส่งคืน media ที่ย้ายเข้า-ออกห้อง
• Secure destruction — media ที่เลิกใช้ต้องทำลายตามระดับ classification (degauss / shred / incinerate)
• Physical theft prevention — ห้องล็อก กล้องวงจรปิด ห้ามเอาออกโดยไม่มี authorization

นี่คือ control ที่ digital-first generation มักลืม เพราะคิดว่า “ใครจะมาขโมย tape” แต่จริงๆ tape ที่หายไป 1 ตลับอาจมี customer record หลักล้านอยู่ในนั้นเลย

Lights-out operations — data center ที่ไม่มีคน#

Lights-out operation = data center ที่ run แบบไม่มีคนประจำ ใช้ automation + remote console จัดการทุกอย่าง เจอใน cloud provider + บริษัทใหญ่ที่ลด headcount

control challenge พิเศษของ lights-out:

• Remote master console เปิดให้ standby operator เข้าได้เผื่อกรณี automated software failure → security ของ remote access ต้องแน่นพอกัน hacker เข้ามาคุม console
• Automated software ที่ทำหน้าที่ operator ต้อง documented + tested ที่ recovery site ด้วย ไม่ใช่ทดสอบแค่ที่ primary
• Contingency operator ต้องมีจริง + รู้วิธีเข้ามารับช่วงตอน automation พัง
• Change control ของ automation script เองก็ต้องเข้มไม่แพ้ production code
• Operator notification — error ทุกตัวต้อง alert ถึงคนได้ ห้ามมี error ที่ระบบ “กลืน” เงียบๆ

data center แบบไม่มีคนประจำ ที่ไม่มี control 5 ข้อนี้ = ระเบิดเวลาที่จะระเบิดวันที่ automation เจอ edge case ที่ไม่เคย test

Figure 4.18 — checklist ที่ผู้สอบบัญชีใช้จริง#

CRM แนะนำให้ผู้สอบบัญชี เดินสำรวจ information processing facility (IPF) จริงๆ เพื่อเห็นภาพ operations ก่อนถาม control คำถามที่ใช้ check แต่ละจุด:

ตารางนี้น่าจำที่สุดในตอนนี้ครับ เพราะเป็น physical checklist ที่เอาไปใช้กับ IPF ของบริษัทไหนก็ได้ ผู้สอบบัญชีที่ดีจะถือไปเดิน data center แล้วเช็คทีละข้อ ไม่ใช่นั่งอ่าน policy ที่ฝ่าย IT ส่งมาให้แล้ว stamp ผ่าน

หลักการ: 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 (Secure Shell / โปรโตคอลเข้าถึง server ระยะไกลแบบเข้ารหัส) เข้าไปแก้ไฟล์

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

control gap: production code ไม่ sync กับ source library + ไม่มี FIM (File Integrity Monitoring / ระบบเฝ้าความถูกต้องของไฟล์) ที่ alert

มุม IS Auditor#

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

เกี่ยวเนื่อง: ถ้าซื้อ software จาก vendor แทนการพัฒนาเอง (build-vs-buy) source code อาจไม่อยู่ในมือเราเลย — ตรงนี้ source code escrow คือ control สำคัญที่ exam ออกถามบ่อย รายละเอียดเขียนไว้แล้วใน ตอนที่ 25 — SDLC waterfall + build-vs-buy

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 แตกแล้วไม่มีทางหนีนะครับ