สารบัญ
สมมติว่ามีองค์กรที่วาง controls ครบทุกอย่างที่ checklist กำหนด — firewall, IDS, encryption, access controls, audit trails
แล้ว IS auditor มาตรวจ แล้วพบว่า controls หลายอย่างที่วางไว้นั้น… ไม่ได้จัดการ risk จริงๆ ที่องค์กรนี้เผชิญอยู่
มีการเข้ารหัสข้อมูลที่ไม่มีคนสนใจ แต่ไม่มีใครดูแล access control ของระบบที่ประมวลผลธุรกรรมการเงินสำคัญที่สุด
นั่นคือปัญหาของ controls ที่ไม่ได้ถูกเชื่อมกับ risk อย่างชัดเจน — มีมาก แต่จัดการผิดจุด
Control ต้อง Justify ตัวเองด้วย Risk
หลักการ Risk-Control Relationship ของ ISACA กำหนดชัดเจนว่า:
Risk is addressed through Control, and Control is justified by the Risk it addresses.
ความสัมพันธ์นี้เป็น สองทิศทาง:
- Risk → Control: ทุก risk ที่ระบุไว้ต้องมี control ที่จัดการ
- Control → Risk: ทุก control ที่วางไว้ต้องสามารถ trace กลับไปถึง risk ที่มันออกแบบมาเพื่อจัดการ
ถ้า control ไม่สามารถ trace กลับไปถึง risk ได้ → เป็นคำถามว่าทำไมถึงมี control นั้นอยู่?
IS Auditor ต้องทำอะไรกับ Link นี้?
เมื่อ IS auditor ประเมิน controls:
- ตรวจว่า controls โยงกลับไปถึง risk ที่เกี่ยวข้อง — ตรวจว่า management ได้ระบุ controls ที่สอดคล้องกับ risk ที่ระบุไว้
- ประเมินนัยสำคัญ ของ control weaknesses — ถ้า control ไม่ทำงาน มันมีนัยสำคัญต่อ overall audit risk มั้ย?
- ประเมินความเพียงพอ — controls ที่มีอยู่ลด risk ได้ถึงระดับที่ยอมรับได้หรือยัง?
ความรับผิดชอบของ Management: Management (ไม่ใช่ IS auditor) ต้องรับผิดชอบดูแลให้ controls ถูกบันทึกและวางไว้ตาม risk assessment ของตัวเอง
บทบาทของ IS auditor: ประเมินอย่างอิสระและรายงานว่า controls นั้นได้ผลหรือเปล่า
เมื่อ Controls ไม่พอ
ถ้า controls ที่วางไว้ไม่สามารถลด risk ได้ถึงระดับที่ยอมรับได้ (ตาม risk tolerance ขององค์กร) — ต้องวาง controls เพิ่มเติม
ถ้าไม่สามารถวาง controls ที่เหมาะสมได้เนื่องจากข้อจำกัดทางธุรกิจ — Compensating Controls อาจเป็นทางออก แต่ต้องมีเงื่อนไขว่า compensating control นั้นให้ผลลัพธ์เดียวกันกับ control ที่ออกแบบมาเดิม
Prescriptive Controls: เมื่อ External Framework กำหนด Control Sets ให้
มีอีกมิติหนึ่งของ controls ที่สำคัญมากในทางปฏิบัติ: Prescriptive Control Frameworks
แทนที่จะให้องค์กรประเมิน risk เองและออกแบบ controls เอง — บางหน่วยงานหรือแหล่งอ้างอิงกำหนด ชุด controls มาตรฐาน ที่องค์กรควรนำไปใช้
ตัวอย่าง Prescriptive Frameworks ที่ CISA ต้องรู้จัก
| Framework | ออกแบบมาสำหรับ | จุดเด่น |
|---|---|---|
| CIS 18 Critical Security Controls | ทุกองค์กรที่ต้องการเสริมความแข็งแกร่งด้าน cybersecurity | จัดลำดับความสำคัญ ใช้ best practices ที่เรียบง่าย |
| OWASP SAMM | องค์กรที่พัฒนาซอฟต์แวร์ | กลยุทธ์ security ของซอฟต์แวร์ที่ปรับให้เข้ากับ risk เฉพาะ |
| SOC Reports (AICPA) | Service organizations ที่ประมวลผลข้อมูลลูกค้า | Framework สำหรับการให้ความเชื่อมั่นแก่ลูกค้า |
| PCI DSS | องค์กรที่จัดเก็บ/ประมวลผลข้อมูลบัตรเครดิต | ข้อกำหนดบังคับสำหรับการปกป้องข้อมูลบัตร |
| CSA Cloud Controls Matrix | สภาพแวดล้อม cloud computing | หลักการ security พื้นฐานสำหรับ cloud providers และลูกค้า |
ใช้ Prescriptive Framework ยังไงให้ถูกต้อง
สิ่งที่องค์กรต้องทำเมื่อใช้ prescriptive framework:
1. ระบุมาตรการรับมือเพิ่มเติม: Prescriptive framework ให้แค่ baseline — แต่องค์กรอาจมี risk เฉพาะที่ framework ไม่ครอบคลุม ต้องระบุและวาง controls เพิ่มเติม
2. ระบุ controls ที่ไม่ applicable: บาง prescribed controls อาจไม่เกี่ยวข้องกับองค์กรเฉพาะนั้น
ตัวอย่างที่ ISACA ยกมา: องค์กรที่รับบัตรเครดิตแต่ไม่ได้ store credit card data ตัว controls ใน PCI DSS ที่เกี่ยวกับ “storing credit card data” จะไม่เกี่ยวข้อง → ไม่ต้องนำไปใช้
3. บันทึกเหตุผลของ non-applicability: ถ้าตัดสินใจว่า control ไม่ apply — ต้องบันทึกว่าทำไม เพราะ IS auditor จะตรวจเหตุผลนั้นว่าสมเหตุสมผลหรือเปล่า
Prescriptive vs. Risk-Based: ต่างกันอย่างไร?
| Prescriptive Approach | Risk-Based Approach | |
|---|---|---|
| จุดเริ่มต้น | External framework กำหนด controls | องค์กรประเมิน risk ตัวเอง |
| ความยืดหยุ่น | ต่ำ — ต้อง justify ทุกการเบี่ยงเบน | สูง — สร้าง controls ตาม risk เฉพาะ |
| ความสามารถในการตรวจสอบ | ชัดเจน — ตรวจเทียบกับ checklist | ต้องการการใช้วิจารณญาณมากกว่า |
| ช่องว่างของความครอบคลุม | อาจครอบคลุมเกินบางพื้นที่ ครอบคลุมไม่พอในพื้นที่เฉพาะ | จัดการ risk เฉพาะได้ตรงกว่า |
ในทางปฏิบัติ: หลายองค์กรใช้ ทั้งสองแบบ — prescriptive frameworks เป็น baseline (ข้อกำหนด compliance) และ risk-based approach สำหรับพื้นที่ที่ prescriptive framework ครอบคลุมไม่เพียงพอ
Control Environment ต้องพัฒนา
โครงสร้าง control ไม่ใช่สิ่งที่วางครั้งเดียวแล้วจบ — ISACA กำหนดว่า control environment ต้องประเมินใหม่ตาม risk-based audit plan อยู่เสมอ
เหตุผล: สภาพแวดล้อมของ risk เปลี่ยน สภาพแวดล้อมธุรกิจเปลี่ยน threat landscape เปลี่ยน — controls ที่เพียงพอสำหรับเมื่อวานอาจไม่เพียงพอสำหรับวันนี้
Management Control Monitoring
นอกจาก IS auditor ที่ตรวจ controls — management เองก็ควร เฝ้าติดตามประสิทธิผลของ control ระหว่างรอบ audit ด้วย
ประโยชน์: ตรวจพบการเบี่ยงเบนของ control ก่อนที่ formal audit จะมาถึง ซึ่งทำให้ management สามารถลงมือแก้ไขได้เร็วขึ้น แทนที่จะรอให้ IS auditor พบและรายงาน
นี่คือการเชื่อมโยงกับ CSA ที่เราคุยกันใน D1.07 — การที่ management เฝ้าติดตาม controls ของตัวเองอย่าง active เป็นส่วนเสริมที่ดีสำหรับ formal IS audit ไม่ใช่การแทนที่
มุมผู้บริหาร: ความต่างระหว่าง Control ที่ “มีอยู่” กับ Control ที่ “ทำงานจริง”
หนึ่งในเรื่องที่ผมเห็นบ่อยที่สุดในการเตรียมองค์กรก่อน audit คือ management พยายามทำเอกสาร controls หลังจากที่ IS auditor แจ้งว่าจะมาตรวจ
นั่นคือความผิดพลาดที่แพง เพราะ IS auditor ไม่ได้แค่ดูว่า “มีเอกสารหรือเปล่า” — แต่ต้องทดสอบว่า control นั้น ทำงานจริงๆ มั้ย ในสภาพแวดล้อมการทำงานจริง
ความต่างระหว่าง:
- Controls “on paper”: Policy เขียนว่ามี access review ทุกไตรมาส
- Controls “in operation”: Access review ทำจริงทุกไตรมาส มีหลักฐานเป็น sign-off records, ถ้าพบ access ที่ไม่เหมาะสมมีหลักฐานว่าถูกเพิกถอน
IS auditor ต้องการหลักฐานของแบบที่สอง — ไม่ใช่แค่แบบแรก
และถ้า controls ที่วางไว้ไม่ได้ trace กลับไปถึง risk จริงๆ — ไม่ว่าจะทำเอกสารดีแค่ไหน IS auditor ก็จะชี้เป็นจุดอ่อน
Forward Reference: Risk-Control Link ใน Domain 5
สิ่งที่เราเรียนใน D1.11 จะกลับมาเจออีกใน Domain 5 ครับ แต่ในขนาดที่ใหญ่กว่ามาก
ใน Domain 5 (Information Security and Systems — 26% ของ exam) เราจะเจอ control frameworks เฉพาะทางสำหรับ information security เช่น zero trust architecture, identity and access management, encryption ทุกชั้น — ทั้งหมดนั้นยังคงอยู่บนหลักการเดียวกัน:
Control ต้อง trace กลับไปถึง risk ที่มันออกแบบมาเพื่อจัดการ
ใน Domain 5 context: ถ้า threat model บอกว่า insider threat เป็น risk สูงสุด → access management controls (IAM, PAM) ต้องถูกลงทุนมากกว่า perimeter security controls เพราะคนในอยู่ใน perimeter แล้ว
Prescriptive frameworks ใน Domain 5 เช่น NIST Cybersecurity Framework, ISO 27001 ก็ยังต้องการ justification เดิม: control ไหน applicable กับ risk ขององค์กรนี้? control ไหนที่ออกแบบเกินความต้องการ?
เข้าใจ risk-control link ที่ D1.11 แล้ว ขั้นต่อไปคือลงมือทำ audit จริง ซึ่งต้องมีโครงสร้างของ project management ที่ชัดเจน
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.4 Types of Controls and Considerations
