สารบัญ
จบ Domain 4 ครบแล้วครับ — 11 ตอน, 16 sections, ครอบทั้ง operations และ business resilience
ตอนนี้ขอย้อนภาพรวมทั้งหมด + flag 5 บทเรียนสำคัญที่ผมเก็บได้ + เกริ่นสิ่งที่กำลังจะมาใน Domain 5 (Security)
Map ของ Domain 4 — 11 ตอน
| ตอน | Part | เรื่อง | Sections CRM |
|---|---|---|---|
| 31 | Overview | เปิด Domain 4 — Run + Survive (storyboard) | 4.1-4.16 ภาพรวม |
| 32 | A | OSI + USB + Asset + Job Scheduling | 4.1 + 4.2 + 4.3 |
| 33 | A | Interfaces + Shadow IT | 4.4 + 4.5 |
| 34 | A | Capacity + Incident + Problem | 4.6 + 4.7 |
| 35 | A | Change + Configuration + Patch Management | 4.8 |
| 36 | A | Log Management + SLA | 4.9 + 4.10 |
| 37 | A | Database Management | 4.11 |
| 38 | B | BIA — เปิด Part B | 4.12 |
| 39 | B | Resilience + Backup | 4.13 + 4.14 |
| 40 | B | BCP + DRP + RPO/RTO + Recovery Sites | 4.15 + 4.16 |
| 41 | Close | ปิด Domain 4 (ตอนนี้) + Recap | (close) |
Part A (ตอน 32-37): “Run” — ดูแลระบบในวันธรรมดา Part B (ตอน 38-40): “Survive” — เตรียมรอดเมื่อเกิดเหตุ
5 บทเรียนสำคัญที่ Domain 4 ฝังในหัว
ถ้าจำได้แค่ 5 อย่างจาก D4 ขอให้จำ:
1. BIA คือต้นน้ำของทุก Resilience Decision
ในมุมที่ผมว่าสำคัญที่สุดของ D4 — ทุกตัวเลขใน Part B downstream จาก BIA
- RTO ของ DRP — มาจาก BIA
- RPO และ backup frequency — มาจาก BIA
- เลือก hot/warm/cold site — มาจาก RTO ที่มาจาก BIA
- BCP scope — มาจาก critical process ที่มาจาก BIA
ถ้า BIA weak → ทุก downstream control ก็ inadequate
ถ้า BIA strong → resilience ทั้งระบบจะมีรากที่แน่น
คำถาม audit แรกของผมเสมอ: “BIA ครั้งล่าสุดของท่านทำเมื่อไหร่ ใครเป็น sponsor?“
2. Control Gap มักอยู่ที่ “รอยต่อ”
control gap ในระบบใหญ่ — ไม่ได้อยู่ในระบบ มันอยู่ระหว่างระบบ:
- Interfaces (ตอน 33) — ข้อมูลส่งผิดระหว่างระบบ
- Shadow IT (ตอน 33) — ข้อมูลออกนอก official IT
- Logs ไม่มีคนอ่าน (ตอน 36) — บันทึกแล้วเสียเปล่า
- Backup ไม่เคย restore (ตอน 39) — promise ที่ไม่รู้ว่าทำได้รึเปล่า
- BCP ไม่เคยซ้อม (ตอน 40) — กระดาษที่ไม่มีค่า
จุดร่วม — ทั้งหมดคือ control ที่ “มีในทฤษฎี, fail ตอน implement”
3. Test เท่านั้นที่พิสูจน์ Control
list ที่ผมเรียกว่า “promise without proof”:
- backup ที่ไม่เคย test restore → ไม่รู้ว่า restore ได้
- BCP ที่ไม่เคย test → ไม่รู้ว่า team ทำตามได้
- hot site ที่ไม่เคย test → ไม่รู้ว่า hardware ตรงกับ production
- patch ที่ไม่เคย test ใน staging → ไม่รู้ว่าจะ break อะไร
- DRP ที่ไม่เคย test → ไม่รู้ว่า procedure executable
- failover plan ที่ไม่เคย test → ไม่รู้ว่า cluster ทำงานจริง
กฎง่ายๆ: untested control = อาจเป็นอย่างที่คิด หรืออาจไม่เป็น — ไม่มีทางรู้ ในมุม audit untested = inadequate
4. Automation = Systemic Risk
ใน D4 ระบบ automate เยอะ — job scheduler, interface, batch job, replication
ลด human error แต่สร้าง new risk:
- error 1 ตัว × scale ใหญ่ = หายนะ ใหญ่
- silent failure — fail แต่ไม่มี alert
- human ไม่ได้ใส่ใจ — เพราะ “ระบบ auto จัดการ”
จุดที่ต้อง audit ใน automated system:
- exception handling
- alerting
- manual override authority + log
- reconciliation ระหว่าง automated output กับ expected
5. Document ที่ไม่ Maintain = ภาระ ไม่ใช่ control
เอกสารที่ไม่ update มี 3 ปัญหา:
- False confidence — คนคิดว่ามีแล้ว เลยไม่ตรวจอีก
- Legal risk — ตอน regulator ถามเจอว่า outdated → worse than no document
- Operational risk — ตอนเหตุเกิดจริง ใช้ document ที่ผิด → ผิดทาง
ตัวอย่างที่เจอตลอดบทนี้:
- Asset register outdated → ไม่รู้ว่ามีอะไรในระบบ
- CMDB ไม่ accurate → ไม่รู้ว่า config ปัจจุบันคืออะไร
- BCP contact list outdated → ตอนเหตุเกิด call ไม่ติด
- DRP procedure outdated → ทำตามแล้วไม่ work
กฎ: document ที่ไม่มี named owner + ไม่มี review schedule → ไม่ใช่ control
Theme ที่เห็นซ้ำตลอด D4
Theme 1 — Lifecycle: Prevent → Detect → Respond → Recover
D4 ทุกบทอยู่ในหนึ่งใน 4 phase นี้:
| Phase | บทใน D4 | ตอบคำถาม |
|---|---|---|
| Prevent | Capacity, Change Mgmt, Asset Mgmt | ไม่ให้เหตุเกิด |
| Detect | Logs, Capacity threshold, SIEM alert | จับสัญญาณก่อนล่ม |
| Respond | Incident Mgmt | เกิดแล้วกู้คืน |
| Recover | Problem Mgmt, BCP, DRP | กลับมาทำงาน + เลิกล่มซ้ำ |
control ที่ดี = ครอบ 4 phase ไม่ใช่ phase เดียว
Theme 2 — Business นำ IT support
ในเกือบทุก section ของ D4:
- BIA — business เป็นคน define criticality
- SLA — business เป็นคน define service level ที่ต้องการ
- Capacity planning — business growth ขับ IT capacity
- BCP — board level decision
IT ที่ดี = IT ที่รู้ตำแหน่งของตัวเอง — เป็น enabler ไม่ใช่ decision maker
Theme 3 — Trust + Verify ผ่าน Audit Trail
ทุก control ใน D4 ที่จับต้องได้ — ผ่าน audit trail:
- Change log
- Console log จาก scheduler
- Database access log
- BCP test record
- Restoration test result
- Vendor SLA report
ถ้าทำแล้ว — ต้องบันทึก ถ้าไม่บันทึก = ไม่มีทางพิสูจน์ว่าทำ
Trap Patterns ที่เก็บไว้สำหรับ exam
| Trap | ความเข้าใจผิด | ความเข้าใจที่ถูก |
|---|---|---|
| RPO = RTO | คิดว่าเหมือนกัน | RPO = data loss tolerance, RTO = downtime tolerance |
| BCP = DRP | คิดว่าเหมือนกัน | BCP = ทั้งองค์กร, DRP = IT เฉพาะ component |
| Incident = Problem | คิดว่าเหมือนกัน | Incident = restore service, Problem = eliminate root cause |
| Backup = ready | คิดว่า backup เสร็จ = recover ได้ | ต้อง test restoration จึงพิสูจน์ |
| Hot site = ดีที่สุด | คิดว่าใช้ hot site กับทุกระบบ | ต้องเลือกตาม BIA — cold site valid สำหรับ low priority |
| Reciprocal agreement = OK | คิดว่าใช้ได้ | ไม่แนะนำสำหรับ critical system |
| Emergency change = no controls | คิดว่า emergency = bypass | ยังต้อง authorize + log + post-hoc review |
| SLA met = good service | คิดว่า aggregate uptime = OK | peak-hour failure อาจ mask ใน aggregate |
| Outsource = no accountability | คิดว่า vendor รับผิดชอบ | accountability stays with org |
| Tabletop = full test | คิดว่าเทียบเท่ากัน | tabletop = paper, full = real failover |
เกริ่น Domain 5 — Security
จบ D4 แล้ว — ระบบ run ได้ มี resilience รับเหตุ ขั้นต่อไปคือ ปกป้องจากการถูกโจมตี
Domain 5 (น้ำหนัก 26% เท่ากับ D4) จะคุยเรื่อง:
- Security policies + physical security
- IAM (Identity and Access Management) — กุญแจของระบบ
- Network + endpoint security + DLP
- Cryptography + PKI — encryption + digital signature
- Cloud + virtualization security
- Mobile + IoT security
- Security awareness + training
- Attacks + penetration testing
- Security monitoring (SIEM, SOC) + Incident Response
- Digital forensics
ความเชื่อมระหว่าง D4 → D5:
- D4 ตอน 36 (Logs) → D5 SIEM + threat hunting
- D4 ตอน 37 (Database access) → D5 IAM (privileged access)
- D4 ตอน 39 (Backup encryption) → D5 cryptography
- D4 ตอน 32 (OSI Network) → D5 Network security controls
- D4 ตอน 34 (Incident) → D5 Security incident response
D4 = “ดูแลให้ทำงาน + รอด” D5 = “ปกป้องจากโจร”
ทั้งคู่อยู่บน infrastructure ตัวเดียวกัน แต่มองคนละมุม — D4 มองในมุม operations + resilience ส่วน D5 มองในมุม security threat
ในมุมที่ผมเห็น — D5 จะ build ต่อยอดจาก D4 ทุกส่วน เพราะ security control เกือบทั้งหมดต้องการ — ระบบที่ run ได้ + log ที่เก็บครบ + backup ที่ test แล้ว + change management ที่ทำงาน
ขอบคุณที่อ่านมาถึงจุดนี้
Domain 4 — 11 ตอน — เป็นการเดินทางที่ผมว่าทำให้เห็น “ชีวิตจริงของ IT operations” มากที่สุดในซีรีส์
ที่หลายเรื่องดูเหมือนงานของ IT ลึกๆ — แต่จริงๆ แล้วเชื่อมตรงกับ business decision ทุกตัว
ถ้าจำได้แค่อย่างเดียวจาก Domain 4 — ขอให้จำ:
resilience ของ organization ไม่ได้วัดที่กระดาษ — มันวัดที่ตอนเหตุเกิดจริง ทีมทำตาม plan ได้รึเปล่า
ตอนหน้าเข้าสู่ Domain 5 ที่ใหญ่ที่สุดของซีรีส์ — Security ที่จะปิด CISA series ทั้งหมด
เจอกันครับ
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: ภาพรวมทุก Section + Domain 4 wrap-up
