สารบัญ
จบ 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 + Hardware Review Program | 4.1 + 4.2 + 4.3 |
| 33 | A | Interfaces (EDI / EDIFACT / X12 / API / MFT) + Shadow IT | 4.4 + 4.5 |
| 34 | A | Capacity + Incident + Problem | 4.6 + 4.7 |
| 35 | A | Change + Configuration + Patch + IS Operations (lights-out / librarian) | 4.8 |
| 36 | A | Log Management + SLA | 4.9 + 4.10 |
| 37 | A | Database Management + DAM | 4.11 |
| 38 | B | BIA + Classification of Operations 4-tier + ALE | 4.12 |
| 39 | B | Resilience + Backup | 4.13 + 4.14 |
| 40 | B | BCP + DRP + RPO/RTO + Recovery Sites + Testing (BCP 3 / DR 5) + Auditor checklist | 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 (Business Impact Analysis / การวิเคราะห์ผลกระทบต่อธุรกิจ)
- RTO (Recovery Time Objective / เวลาที่ยอมระบบล่ม) ของ DRP (Disaster Recovery Plan / แผนกู้คืนระบบหลังภัยพิบัติ) — มาจาก BIA
- RPO (Recovery Point Objective / จุดเวลาที่ยอมเสียข้อมูล) และ backup frequency — มาจาก BIA
- เลือก hot/warm/cold site — มาจาก RTO ที่มาจาก BIA
- BCP (Business Continuity Plan / แผนบริหารความต่อเนื่องของธุรกิจ) scope — มาจาก critical process ที่มาจาก BIA
ถ้า BIA weak ทุก downstream control ก็ inadequate
ถ้า BIA strong resilience ทั้งระบบจะมีรากที่แน่น
คำถามแรกที่ใช้เปิดทุก scenario เรื่อง resilience: “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 (Configuration Management Database) ไม่ 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 (Service Level Agreement / สัญญาระดับการให้บริการ) — 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 |
| BCP test = DR test | คิดว่าใช้ scale เดียวกัน | BCP test 3 ระดับ (ฝั่งธุรกิจ) vs DR test 5 ระดับ (ฝั่ง IT recovery) — คนละชุดกัน |
| Insurance = แทน BCP ได้ | คิดว่าซื้อ cyber insurance แล้วไม่ต้องมี BCP | insurance complement BCP — กู้ financial loss, ไม่กู้ operation |
| Classify operations ไม่ทำ | คิดว่าทุก system สำคัญเท่ากัน | Critical / Vital / Sensitive / Nonsensitive — ขับ control investment ทั้งหมด |
เกริ่น Domain 5 — Security
จบ D4 แล้ว ระบบ run ได้ มี resilience รับเหตุ ขั้นต่อไปคือ ปกป้องจากการถูกโจมตี
Domain 5 (น้ำหนัก 26% เท่ากับ D4) จะคุยเรื่อง:
- Security policies + physical security
- IAM (Identity and Access Management) — กุญแจของระบบ
- Network + endpoint security + DLP (Data Loss Prevention / ระบบกันข้อมูลรั่วไหล)
- Cryptography + PKI (Public Key Infrastructure / โครงสร้างพื้นฐานกุญแจสาธารณะ) — encryption + digital signature
- Cloud + virtualization security
- Mobile + IoT (Internet of Things / อุปกรณ์อัจฉริยะที่ต่ออินเทอร์เน็ต) security
- Security awareness + training
- Attacks + penetration testing
- Security monitoring (SIEM — Security Information and Event Management / ระบบรวมและวิเคราะห์ log security, SOC — Security Operations Center / ศูนย์ปฏิบัติการ security) + 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 (Open Systems Interconnection — โมเดล network 7 ชั้น) 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 ขององค์กรไม่ได้วัดที่กระดาษ มันวัดที่ตอนเหตุเกิดจริง ทีมทำตาม plan ได้รึเปล่า
ตอนหน้าเข้าสู่ Domain 5 ที่ใหญ่ที่สุดของซีรีส์ — Security ที่จะปิด CISA series ทั้งหมด
เจอกันครับ
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: ภาพรวมทุก Section + Domain 4 wrap-up
