สารบัญ
ขึ้น Domain 4 แล้วครับ เอาตรงๆ Domain นี้ผมตั้งใจอ่านที่สุดในทั้งซีรีส์เลย
เหตุผลง่ายๆ: D4 น้ำหนักข้อสอบ 26% ใหญ่สุดร่วมกับ D5 มี section รวม 16 sections (มากที่สุดในทุก Domain) แล้วก็เป็น Domain ที่ผมว่าใกล้เคียงกับงานจริงของ IS auditor มากที่สุด เพราะมันคือเรื่องของ ระบบที่อยู่ในสนามจริง ไม่ใช่ระบบบนกระดาน
ก่อนลงรายละเอียด ขอใช้บทนี้วาดแผนที่ใหญ่ก่อน — แบบเดียวกับใน ตอน 03 สำหรับ D1, ตอน 14 สำหรับ D2, และ ตอน 23 สำหรับ D3
ที่ผ่านมาเรารู้อะไรแล้ว
ลองย้อนภาพรวมทั้งซีรีส์ก่อน เพราะ D4 ไม่ได้อยู่โดดเดี่ยว มันต่อยอดจากทุก Domain ก่อนหน้าหมด
- Domain 1 — วิธีของ auditor: รู้กฎ มีอำนาจ วางแผนตามความเสี่ยง ลงสนาม เก็บหลักฐาน ออก report
- Domain 2 — สรีระของ organization ที่ดี: governance, ERM, policy hierarchy, vendor management, performance
- Domain 3 — กระบวนการสร้างระบบใหม่: business case, SDLC, application controls, testing, go-live, post-implementation review
- Domain 4 — ระบบที่ go-live แล้ว ดูแลยังไง รอดยังไง — ที่กำลังจะคุยกัน
- Domain 5 — ปกป้องระบบและข้อมูลจากการถูกโจมตี (รออยู่)
ทุก Domain ต่อกันแน่น D4 รับช่วงมาจาก D3 ตอนที่ระบบเพิ่ง go-live ส่วน D5 ค่อยมารับต่อในมิติ security
คำถามใหญ่ของ D4 — Run + Survive
D3 จบลงตรงไหน? ตรงที่ระบบใหม่ผ่าน UAT, migrate ข้อมูลเข้าได้ครบ, เปิดให้ user ใช้งาน, ผ่าน post-implementation review
แล้วต่อจากนั้นล่ะ?
ระบบก็อยู่ในสนาม มีคนใช้งานจริง 8 ชั่วโมงต่อวัน 365 วันต่อปี ข้อมูลไหลเข้าออกตลอดเวลา มี integration กับระบบอื่น มี vendor มาเสริม patch ใหม่ออกทุกเดือน พนักงานใหม่เข้า พนักงานเก่าออก server อายุเริ่มเก่า ข้อมูลโตขึ้นเรื่อยๆ
แล้วก็จะมีวันที่ ระบบช้า ระบบแฮ้ง ระบบเพี้ยน serverล่ม น้ำท่วม data center, hard driveพัง, พนักงานกดผิด, hackerเข้ามา, vendorผิดสัญญา
D4 คือคำตอบของ 2 คำถามที่อยู่คู่กันตลอด:
- Run — ทำยังไงให้ระบบทำงานสม่ำเสมอทุกวัน ไม่ล่มก่อนเวลา
- Survive — เมื่อเกิดเหตุที่ระบบล่มจริง รอดมาได้ยังไง
ในมุม business owner D4 คือเรื่องของ continuity (ธุรกิจไม่หยุด) กับ resilience (เจ็บแล้วยังลุกได้)
ในมุม auditor D4 คือเรื่องของการตรวจว่า control ที่อยู่รอบๆ การ run + survive มีครบและทำงานจริงรึเปล่า
โครงของ Domain 4 — 16 sections แบ่งเป็น 2 parts
CRM แบ่ง D4 เป็น 2 ส่วนใหญ่ๆ:
Part A — Information Systems Operations (Section 4.1-4.11): เรื่องของการ “Run” ระบบในวันธรรมดา
Part B — Business Resilience (Section 4.12-4.16): เรื่องของการ “Survive” เมื่อเกิดเหตุ
ขอ map สั้นๆ ก่อนว่าแต่ละ section คุยเรื่องอะไร แล้วตอนถัดๆ ไปค่อยเจาะทีละส่วน
Part A: Run — งานประจำที่ทำให้ระบบทำงาน
เรื่องที่ Part A คุยกัน เรียงตามลำดับที่ผมจะเล่า:
| ขั้น | เรื่อง | คำถามใหญ่ |
|---|---|---|
| รู้จักโครงสร้าง | OSI Model + LAN/WAN + USB + Asset Inventory + Job Scheduling | auditor ต้องอ่านโครงสร้าง IT ให้ออกก่อนตรวจอะไรเลย |
| รอยต่อ | System Interfaces + Shadow IT | ข้อมูลหายไปไหนระหว่างระบบ — รอยต่อมักเป็นจุดอ่อน |
| เมื่อระบบมีปัญหา | Capacity + Incident + Problem Management | ป้องกันก่อนล่ม / กู้คืนเมื่อล่ม / เลิกล่มซ้ำ |
| เมื่อต้องเปลี่ยนแปลง | Change + Configuration + Patch Management | ทำไมระบบดีๆ ถึงพังหลัง update |
| ความจำขององค์กร | Log Management + SLA | จดทุกเหตุการณ์ไว้ + วัดบริการได้ |
| โกดังข้อมูล | Database Management | ใครคุม DBA ที่มีกุญแจทุกดอก |
จะเห็นว่า Part A เริ่มจาก infrastructure ก่อน → operations process → data layer
ในมุมผม Part A คือเรื่องของ “ความสม่ำเสมอ” ระบบที่ดีไม่ใช่ระบบที่ไม่เคยมีปัญหา แต่เป็นระบบที่จัดการปัญหาได้สม่ำเสมอต่างหาก
Part B: Survive — แผนเมื่อเกิดเหตุ
Part B สั้นกว่าแต่หนักกว่า เพราะนี่คือส่วนที่ exam ออกข้อสอบหนัก:
| ขั้น | เรื่อง | คำถามใหญ่ |
|---|---|---|
| รู้ว่าอะไรสำคัญ | BIA — Business Impact Analysis | ก่อนวางแผนรอด ต้องรู้ก่อนว่าอะไรสำคัญ + ทนได้นานแค่ไหน |
| สร้างความพร้อม | Resilience + Backup | ระบบไม่ล่ม + ข้อมูลไม่หาย — สองชั้นความพร้อม |
| เมื่อเกิดเหตุจริง | BCP + DRP + RPO/RTO + Recovery Sites | แผนตอนเกิดเหตุ + กลยุทธ์การฟื้นฟู |
Part B มี logic ลำดับชัดเจน BIA เป็นต้นน้ำ ทุกอย่างไหลตามมา ถ้า BIA ผิด ทุก decision ที่ตามมา (RTO, RPO, จะเลือก hot site หรือ cold site, จะลงทุน backup แบบไหน) ก็ผิดหมด
4 Theme ที่ขึ้นมาซ้ำตลอด D4
ก่อนจะลงตอน 32 ขอ flag 4 theme ที่ขึ้นมาซ้ำๆ ตลอด D4 รู้ไว้ก่อน เวลาอ่านบทถัดๆ ไปจะจับแก่นได้เร็วขึ้น
Theme 1 — Lifecycle: Prevent → Detect → Respond → Recover
D4 ไม่ใช่ list ของ control แต่เป็น lifecycle ที่ control แต่ละตัวอยู่ในตำแหน่งต่างกัน:
- Prevent (ก่อนเหตุ) — change management, capacity planning, asset inventory ทำให้เหตุไม่เกิด
- Detect (ตอนเหตุเริ่ม) — log monitoring, alert จาก SIEM, threshold ของ capacity เริ่มเตือน
- Respond (ตอนเหตุเกิด) — incident management ตอบสนองเฉพาะหน้า กู้บริการคืน
- Recover (หลังเหตุ + ระยะยาว) — problem management หาต้นตอ, BCP/DRP กู้คืนระยะยาว
control ที่ดีไม่ใช่ control ที่ป้องกันได้ทุกอย่าง แต่คือ control ที่ ครอบทุก phase ของ lifecycle ถ้าองค์กร invest แต่ Prevent ไม่ invest Detect ตอนเกิดเหตุจะไม่รู้ตัวด้วยซ้ำ
Theme 2 — Control Gap มักอยู่ที่ “รอยต่อ”
จุดที่ control พังบ่อยสุดไม่ใช่ภายในระบบ แต่อยู่ที่รอยต่อ:
- ข้อมูลส่งจากระบบ A ไประบบ B (interface)
- ข้อมูลที่อยู่นอก official IT (Shadow IT, Excel ของฝ่ายบัญชี)
- log ที่บันทึกแล้วไม่มีคนอ่าน
- backup ที่มีแล้วไม่เคย test restore
- BCP ที่เขียนแล้วไม่เคยซ้อม
Auditor ที่เก่ง รู้ว่าจะหา finding ตรงไหนก่อน คำตอบคือ รอยต่อ เสมอ
Theme 3 — BIA คือต้นน้ำของทุก resilience decision
ถ้าจำได้แค่อย่างเดียวจาก D4 ขอให้จำเรื่องนี้ครับ BIA นำ ทุกอย่างตาม
ใครจะตัดสินใจว่า:
- ระบบนี้ต้องกู้คืนภายในกี่ชั่วโมง? (RTO)
- ข้อมูลย้อนหลังกี่ชั่วโมงที่ยอมเสียได้? (RPO)
- ต้องลงทุน hot site หรือ cold site พอ?
- ต้อง backup ทุกชั่วโมงหรือทุกวัน?
ทั้งหมดนี้ตอบได้ก็ต่อเมื่อ BIA ทำเสร็จ + business เป็นคนตอบเอง ไม่ใช่ IT
Theme 4 — Automation = Systemic Risk
ใน D4 ระบบ auto-mate เยอะมาก: job scheduler รันงานคืนละหลายพัน, interface ส่งข้อมูลระหว่างระบบทุก 5 นาที, batch job คำนวณเงินเดือน, replication ทำ backup real-time
automation ลด human error ก็จริง แต่สร้างความเสี่ยงใหม่ขึ้นมา — เพราะพอ error เกิด มันเกิดที่ scale ใหญ่และเงียบมาก
ตัวอย่าง: ถ้าคน 1 คนกดผิด 1 ครั้ง = 1 record ผิด แต่ถ้า batch script กดผิด 1 บรรทัด = 50,000 record ผิด และไม่มีใครรู้ทันที
D4 บังคับให้ auditor มอง automation เป็น risk เฉพาะตัว ต้องตรวจ control ของกระบวนการที่ auto-mate ด้วย ไม่ใช่ตรวจแค่กระบวนการที่ทำมือ
บทเรียนใหญ่ที่ผมเก็บได้ตอนเรียนทั้ง Domain
มีอยู่ 3 ความเข้าใจที่ผมว่าเป็น “key” ของทั้ง D4:
1. Operations ดูเหมือนเรื่องเทคนิค แต่ตัวตัดสินใจคือ business
จะวาง capacity เท่าไหร่, จะลงทุน hot site มั้ย, RTO ควรเท่าไหร่ ทั้งหมดนี้เป็น business decision ที่อาศัยข้อมูล technical ประกอบ ไม่ใช่กลับกัน
2. Test เท่านั้นที่พิสูจน์ว่า control ทำงาน
backup ที่ไม่เคย restore, BCP ที่ไม่เคยซ้อม, hot site ที่ไม่เคย test ทั้งหมดนี้คือ control ที่อยู่ในกระดาษ ไม่ได้อยู่ในความเป็นจริง
3. Document ที่ไม่มีคน maintain เป็นภาระ ไม่ใช่ control
asset register ที่ไม่ update, BCP contact list ที่ outdated, CMDB ที่ไม่มีใครแก้ เอกสารพวกนี้ให้ false sense of security ที่อันตรายกว่าการไม่มีเลย
ลำดับ 11 ตอนที่จะเล่าใน D4
ผม restructure ลำดับ CRM ใหม่ให้เล่าต่อเนื่องดีกว่า ไม่ได้ตามเลข section เป๊ะๆ แต่อยู่ใน 16 sections ครบ
Part A — Operations ในวันธรรมดา (ตอน 32-37)
- ตอน 32 — โครงสร้าง IT ที่ auditor ต้องเข้าใจ (OSI + USB + Asset + Job Scheduling)
- ตอน 33 — Interfaces + Shadow IT (รอยต่อที่มักหลุดมือ)
- ตอน 34 — Capacity + Incident + Problem (เมื่อระบบช้า/ล่ม)
- ตอน 35 — Change + Patch Management (ทำไมระบบดีๆ ถึงพังหลัง update)
- ตอน 36 — Log Management + SLA (Black Box ขององค์กร)
- ตอน 37 — Database Management (โกดังกับคนถือกุญแจ)
Part B — Business Resilience (ตอน 38-40)
- ตอน 38 — BIA (รู้ว่าอะไรสำคัญก่อนเกิดเหตุ)
- ตอน 39 — Resilience + Backup (สองระดับความพร้อม)
- ตอน 40 — BCP + DRP + RPO/RTO (บทใหญ่สุด)
ปิดท้าย
- ตอน 41 — ปิด D4 + Recap + เกริ่น D5 (Security)
ตอนนี้พร้อมแล้วครับ บทถัดไปจะเริ่มที่ infrastructure layer — OSI Model, USB risk, IT asset management และ job scheduling ที่ทำงานอยู่ในเงา
ก่อนตรวจอะไรในระบบ auditor ต้องอ่านโครงสร้างของระบบให้ออกก่อน เพราะถ้าอ่านโครงสร้างไม่เป็น เจอ finding ปุ๊บก็ไม่รู้ว่ามันมาจาก layer ไหน
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.1-4.16 (synthesis post — ภาพรวม Domain 4 ทั้งหมด ไม่ตรงกับ section ใด section หนึ่ง)
