สารบัญ
ลองนึกภาพเถ้าแก่คนหนึ่ง เพิ่งจัดกระเป๋าใบแรกเสร็จ — เรื่อง control ทั่วไป framework พื้นฐาน จบไปแล้ว กำลังจะปิดซิปนอน อยู่ๆ ก็มีข่าวว่าโรงงานข้างบ้านโดนแฮก ระบบล็อกทั้งบริษัท ทำงานต่อไม่ได้สามวัน ลูกค้าหนี ของเสียคาสายพาน เถ้าแก่สะดุ้งตื่น หยิบกระเป๋าใบที่สองขึ้นมาทันที
เพราะกระเป๋าใบนี้มันไม่ใช่เรื่องของ “ฝ่าย IT” คนเดียวอีกแล้วครับ ภัยไซเบอร์เดินออกจากห้อง server มายืนอยู่กลางห้องประชุมสภาแล้ว ถ้าพลาดขึ้นมา บริษัททั้งบริษัทหยุดหายใจได้ในชั่วข้ามคืน
รอบนี้ผมเลยต้องเก็บของใส่กระเป๋าใบสองให้ครบ — ตั้งแต่ “มีอะไรบ้างที่เป็นภัย” (cyber risk), “กันด้วยอะไร” (control ให้ตรงชั้น), “ปกป้องข้อมูลส่วนบุคคลยังไง” (privacy), “พอโดนเจาะแล้วรับมือยังไง” (incident response), ไปจนถึง “ถ้าไฟไหม้ทั้งตึกจะกู้ระบบกลับมายังไง” (business resilience) และที่สำคัญสำหรับคนจะไปสอบอย่างเรา ทุกหัวข้อนี้ข้อสอบ P2 ชอบเอามาหลอกด้วย pattern เดิมๆ ที่ผมจดไว้แล้ว เดี๋ยวเล่าให้ฟัง
ตอนที่แล้วเราเปิดกระเป๋าใบแรกเรื่อง IT กันครับ (ตอนที่ 21) โหมดประมวลผล batch กับ online real-time, audit trail ที่ไล่ย้อนต้นตอ, ITGC กับ application control ชั้น input/processing/output และ control frameworks อย่าง COSO/COBIT/ISO ที่ต้องจับลายนิ้วมือให้ถูก ทั้งหมดเป็นฐานของ IT ทั่วไป ตอนนี้เลื่อนขึ้นไปอีกชั้นที่ร้อนกว่า — พอ IT เชื่อมโลกภายนอก ภัยไซเบอร์ก็เดินเข้ามาถึงห้องประชุมสภา
โครงของบทนี้
- Cyber risk บน mobile/IoT/cloud + Cybersecurity Topical Requirement ที่กลายเป็น baseline บังคับใหม่
- จับ control ให้ตรงชั้นของภัย — firewall กันคนนอก, encryption กันข้อมูลรั่ว, IAM คุมสิทธิ์, biometric/physical กันตัวคน
- policy คือรากฐาน เครื่องมือมาทีหลัง — และรู้จักสัตว์ malware ทีละตัว
- Incident response: ผู้ตรวจ ประเมิน ไม่ลงมือ + คำศัพท์ precursor/indicator/escalation + อุดช่องให้ตรงช่อง
- Security & privacy audit: ใครเป็นเจ้าของ ใครตรวจ + privacy สี่กล่อง + assurance ไม่สร้าง control เอง
- Business resilience: BIA → BCP → DRP, hot/warm/cold site, backup ที่ off-site และครบ transaction, พิสูจน์ด้วยการทดสอบ
ภัยมาจากของใกล้ตัว — mobile, IoT, cloud
เริ่มที่ “มีอะไรบ้างที่เป็นภัย” ก่อน
ในอาณาจักรเถ้าแก่สมัยนี้ ของที่ต่อเน็ตได้มันเยอะจนน่าตกใจ ไม่ใช่แค่คอมกับมือถือ แต่มีนาฬิกา เครื่องวัดอุณหภูมิในโรงงาน กล้องวงจรปิด แม้แต่เครื่องมือแพทย์ พวกนี้เรียกรวมๆ ว่า Internet of Things (IoT) — อุปกรณ์ที่ต่อเครือข่ายไร้สายและส่งข้อมูลได้ ปัญหาคือแต่ละชิ้นมันเป็นช่องให้คนร้ายเดินเข้าบ้านได้หมดเลย
ความเสี่ยงของ IoT/mobile ที่ข้อสอบชอบหยิบมาถาม แต่ละตัวมันมีลายเซ็นเฉพาะตัว ต้องจำให้แม่นว่าอาการแบบนี้คือชื่ออะไร:
- Weak authentication — ไม่มีการยืนยันตัวตนก่อนเข้าถึงทรัพยากร และ poor password management — ใช้รหัสซ้ำหรือรหัสอ่อนที่ถูกเดา/crack ได้ง่าย
- Lack of encryption — IoT ส่วนใหญ่ไม่เข้ารหัสข้อมูล
- Low processing power — footprint เล็ก เก็บข้อมูลได้น้อย เลยใส่ firewall, virus scanner หรือ end-to-end encryption ไม่ไหว
- Use of legacy assets — แอปเก่าที่ไม่ได้ออกแบบมาต่อเว็บ เข้ากับ encryption รุ่นใหม่ไม่ได้
- Inconsistent security standards — ไม่มีมาตรฐานเดียวสำหรับ IoT ทำให้การคุยเครื่องต่อเครื่องเสี่ยง และพอ จำนวนอุปกรณ์โตแบบก้าวกระโดด ผสมกับมาตรฐานที่ไม่นิ่ง กลายเป็นภัยตัวหลักของ IoT
- Data leakage — พอแอป (riskware) ขอ permission กว้างๆ แล้วผู้ใช้กดยอมโดยไม่อ่าน นักพัฒนาแอปฝังโค้ดลึกในระบบปฏิบัติการมือถือ แอบส่งข้อมูลออกได้
- Physical vulnerability — อุปกรณ์ถูกจับต้องบ่อย เสี่ยงถูกงัดแงะ ขโมย SIM หรือหน่วยเก็บข้อมูล
- Spyware — software ที่ถูกลอบติดตั้งลงในระบบหรือมือถือเพื่อเก็บข้อมูลคนหรือองค์กรโดยเจ้าตัวไม่รู้
มุมผู้ตรวจ (คนสอบ): ข้อ IoT ชอบเป็นแบบ “อาการนี้ตรงกับความเสี่ยงชื่อไหน” — โจทย์ยื่นนิยามมาให้ แล้วให้เลือกชื่อ
⚠️ กับดัก: ตัวหลอกเป็นชื่อความเสี่ยง IoT จริงทั้งนั้น (data leakage, weak authentication, physical vulnerability) วางไว้ให้คนอ่านลวกๆ ตอบผิด — “data leakage” จะถูกก็ต่อเมื่อ permission กว้างทำให้ฝังโค้ดแอบส่งข้อมูล ไม่ใช่ทุกครั้งที่เห็นคำว่า permission ส่วน “physical vulnerability” คือ hardware ถูกงัด/ขโมย (SIM, storage) ไม่ใช่การดักฟังข้อความ และเวลาโจทย์ถาม “อะไร best describes ความเสี่ยง IoT” ให้เลือกข้อที่ยอมรับ จุดอ่อน (ไม่มี encryption, auth อ่อน) ไม่ใช่ข้อที่ฟังดูดี “แข็งแรง/สม่ำเสมอ/รัดกุม”
Cloud — ใครดูแลชั้นไหน และภัยที่มีเฉพาะบนคลาวด์
Cloud computing คือการเช่าบริการ IT ผ่านอินเทอร์เน็ตแบบจ่ายตามใช้ ไม่ต้องซื้อ server เอง แบ่งเป็นสามแบบ ดูกันที่ “ใครดูแลชั้นไหน”:
- IaaS (Infrastructure as a Service) — ผู้ให้บริการยื่น hardware เสมือน/จริง, OS, network, storage มาให้ องค์กรเอาไปวาง infrastructure ของตัวเอง
- PaaS (Platform as a Service) — hardware กับ OS ถูกดูแลให้ องค์กรแค่ deploy และดูแลซอฟต์แวร์ตัวเอง
- SaaS (Software as a Service) — ทั้ง infrastructure และแอปถูกดูแลโดย cloud service provider (CSP) องค์กรแค่ใช้แอป ไม่ต้องดูแลอะไรเลย
ความเสี่ยงบนคลาวด์มีทั้งแบบที่มีเฉพาะบนคลาวด์ กับแบบที่มีทั้งบนคลาวด์และ on-premises ตัวที่ เฉพาะคลาวด์ คือพวกที่หายไปถ้ากลับไปอยู่ server ตัวเอง เช่น เสียการมองเห็นและควบคุม (loss of visibility/control) ทรัพย์สินที่ย้ายขึ้นคลาวด์, ลบข้อมูลไม่หมด/ยืนยันการลบไม่ได้ (incomplete data deletion), tenant แยกกันไม่ขาด, และพนักงานแอบ provision บริการเองโดย IT ไม่รู้ (unauthorized self-provisioning) ตัวหลังนี้จริงๆ เป็นเรื่องของ identity and access management (IAM) — การจัดการตัวตนและสิทธิ์เข้าถึงที่หละหลวม
มุมเถ้าแก่: ขึ้นคลาวด์มันสบายตรงลงทุนน้อย ขยับตัวเร็ว แต่เถ้าแก่ต้องรู้ว่าแลกมาด้วยการ มองไม่เห็นของตัวเอง ข้อมูลอยู่ที่ server ใครก็ไม่รู้ ลบแล้วลบจริงไหมก็ตรวจไม่ได้ นี่แหละราคาที่ต้องยอมรับ แล้วก็วาง control เพิ่มเอา
⚠️ กับดัก: โจทย์สลับนิยาม service model ข้ามกัน (โจทย์ถาม IaaS แต่ยื่นนิยาม SaaS มาเป็นเหยื่อ) และเอา “private cloud” (infrastructure เฉพาะองค์กรเดียว) มาวางเหมือนเป็น service model ทั้งที่มันไม่ใช่ ส่วนโจทย์ที่ถาม “ภัยที่ unique to cloud” จะเอาภัยที่มีบน on-premises ด้วย (ขโมย server, ขโมย credential, ระบบ legacy, ransomware) มาหลอก — พวกนี้มีทั้งสองที่ เลยผิด และมุมกลับ ถ้าถาม “ภัยที่มีร่วมกัน both” ทีนี้ตัว on-premises ได้ (ขโมย credential) กลายเป็นคำตอบถูก ส่วนตัว cloud-only (tenant แยกไม่ขาด, ลบไม่หมด) กลายเป็นตัวหลอก
เลือก control ที่แก้ตรงจุด อย่าเลือกตัวที่ดูใหญ่
พอรู้ว่าภัยคืออะไรแล้ว คำถามถัดมาคือ “แก้ด้วยอะไร” — อันนี้แหละกับดักที่ผมเจอบ่อยที่สุดในหมวดนี้ เพราะทุกตัวเลือกมันเป็น security practice จริงหมด แต่มีตัวเดียวที่แก้ ตรงจุด ที่โจทย์บอก
วิธีที่ผมใช้คือ อ่าน stem แล้ว ตั้งชื่อภัยให้ตรง ก่อน แล้วค่อยเลือก control ที่นั่งทับภัยนั้นพอดี:
- ข้อมูลรั่วตอนส่ง / ถูกดักระหว่างทาง / ยังไม่เข้ารหัส → encryption (end-to-end ถ้าโจทย์ระบุ)
- patch ไม่สม่ำเสมอ / ทำมือ → ระบบ patch รวมศูนย์ หรือ นโยบาย patch (โครงสร้าง ไม่ใช่คนคนเดียว ไม่ใช่เปลี่ยน vendor)
- ตรวจจับการเจาะจากภายนอก → network monitoring จับความผิดปกติแบบ real-time
- สิทธิ์เข้าถึงคุมไม่อยู่ / provision มั่ว → IAM framework
⚠️ กับดัก: ตัวหลอกที่ ดูใหญ่แต่ไม่แก้ราก — “เปลี่ยน/ย้าย provider” หรือ “outsource IT security” (วุ่นวายและไม่แตะต้นเหตุ), “ทำ risk assessment / security audit อีกรอบ” (ความเสี่ยงถูกระบุแล้ว วิเคราะห์เพิ่มไม่ใช่การลงมือ), “อบรมพนักงาน / จำลอง phishing” (สร้าง awareness ระยะยาว ไม่ใช่ control ทันทีสำหรับช่องที่บอก) และตัวหลอกเล็งผิดชั้น — ยัด “physical security” มาทั้งที่ภัยคือข้อมูลระหว่างส่ง ไม่ใช่เรื่องกายภาพ
Cybersecurity Topical Requirement — baseline ใหม่ที่ต้องจำ
ตรงนี้ของใหม่ที่กระเป๋าใบสองต้องมี — Topical Requirement ของ The IIA
หลักการทั่วไปว่า Topical Requirement คืออะไร (เส้นขั้นต่ำสำหรับงาน assurance), ใช้ตามความเสี่ยงไม่ใช่ใส่อัตโนมัติ, เสริมไม่แทน the Standards, และ CAE รับผิดชอบ conformance — เล่าละเอียดไปแล้วตอน /posts/cia-p2-17-objectives-scope-criteria-topical-requirements/ ตรงนี้ขอโฟกัสสิ่งที่ Cyber TR บังคับให้ผู้ตรวจไปดูโดยเฉพาะ เรื่องนี้ผูกกับ Principle 13 Plan Engagements Effectively พอความเสี่ยงไซเบอร์ถูกดึงเข้ามาในงาน ก็ต้องเอา requirement นั้นมาใช้
ตอนนี้ Cybersecurity (ออก ก.พ. 2025) มีผลบังคับแล้วตั้งแต่ ก.พ. 2026 ส่วน Third-Party และ Organizational Behavior ออกแล้วและทยอยมีผลภายในปี 2026 ตามกติกา “12 เดือนหลังประกาศ” หัวข้อในอนาคตอย่าง culture กับ business resiliency ยังอยู่ระหว่างพัฒนา ฉบับที่เราสนใจในตอนนี้คือ Cybersecurity ซึ่งวางกรอบให้ผู้ตรวจประเมินสามด้าน — governance (มีกลยุทธ์และนโยบายไซเบอร์ที่ทบทวนสม่ำเสมอ สภารับรู้), risk management (มีกระบวนการระบุ วิเคราะห์ ลด และเฝ้าติดตามภัย รวมถึงเส้นทาง escalate ที่เร็ว), และ controls (control ที่ฝ่ายบริหารตั้งขึ้นและประเมินเป็นระยะ ครอบคลุม encryption, patching, การจัดการสิทธิ์เข้าถึง, firewall, IDS/IPS ไปจนถึงกระบวนการ incident response ที่ถูกทดสอบ)
มุมเถ้าแก่: จุดที่เถ้าแก่ต้องเข้าใจคือ Topical Requirement มันบังคับสำหรับงาน assurance (งาน advisory แค่แนะนำ) แปลว่าเวลากองผู้ตรวจการมาให้ความเชื่อมั่นเรื่องไซเบอร์ ต้องเดินตามเส้นขั้นต่ำนี้เสมอ จะตรวจตามอำเภอใจไม่ได้ แล้วองค์กรไหนความเสี่ยงสูงมากๆ ก็ต้องประเมินเกินเส้นขั้นต่ำไปอีก
มุมผู้ตรวจ (คนสอบ): เรื่อง CAE ต้องหาทรัพยากรมารองรับและยังรับผิดชอบ conformance แม้ outsource ออกไป — หลักนี้อยู่ตอน /posts/cia-p2-17-objectives-scope-criteria-topical-requirements/ แล้ว สำหรับ Cyber TR ที่ต้องจำเพิ่มคือ ต้อง document ว่าประเมิน requirement ด้านไซเบอร์แต่ละข้อแล้ว ถ้าตัดข้อไหนออก (เพราะไม่ตรง scope) ก็ต้องเขียนเหตุผลเก็บไว้เสมอ
Policy คือรากฐาน — เครื่องมือมาทีหลัง
ก่อนจะพูดถึง control ตัวๆ ต้องปักหมุดหลักคิดหนึ่งไว้ก่อน เพราะข้อสอบชอบถามว่า “อะไรมาก่อน”
Policies เป็นรากฐาน ของ information security และ cybersecurity ส่วน standard, procedure, guideline พวกนี้แค่ เอานโยบายไปปฏิบัติ ไม่ใช่รากฐาน ผู้บริหารระดับสูงเป็นคนรับผิดชอบทั้งการประเมินความเสี่ยงและการวางนโยบายด้านความปลอดภัยขององค์กร แล้วก่อนจะไปลง control ทาง IT องค์กรต้อง นิยามก่อนว่าจะจัดการข้อมูลภายในและแบ่งปันข้อมูลออกภายนอกยังไง สามเป้าหมายที่ทุกนโยบายต้องคุ้มครองคือ confidentiality (ความลับ), integrity (ความถูกต้องครบถ้วน) และ availability (พร้อมใช้เมื่อผู้มีสิทธิ์ต้องการ)
มุมผู้ตรวจ (คนสอบ):
⚠️ กับดัก: เจอ stem ถาม “รากฐาน / สิ่งที่ต้องทำก่อน / ขั้นแรก” แล้วมีตัวเลือกเป็น เครื่องมือเฉพาะ — penetration test, two-factor authentication, ติดตั้ง firewall, อัปเดตซอฟต์แวร์ — พวกนี้ผิด เพราะกระโดดไปเครื่องมือก่อนวางรากฐาน ถ้าถาม “ขั้นแรกในการประเมิน/ลดความเสี่ยงที่เจอ” คำตอบคือ ประเมินนโยบายความปลอดภัยที่มีอยู่ก่อน เพื่อหาช่องโหว่ กฎง่ายๆ คือ พอ “ขั้นตอนกำกับดูแล/นิยาม” มาแข่งกับ “เครื่องมือรูปธรรม” ในโจทย์ที่ถามรากฐาน/ก่อน/แรก — ฝั่งกำกับดูแลชนะเสมอ
จับ control ให้ตรงชั้น — ยาม รหัส กับกำแพง
ทีนี้ลงเครื่องมือจริง หัวใจของทั้งหมวดนี้คือ จับ control ให้ตรงชั้นของภัย ลองคิดเป็นบ้านหลังหนึ่งนะ — ยามเฝ้าประตูหน้า ก็คนละเรื่องกับรหัสที่ล็อกตู้เอกสาร คนละเรื่องกับกำแพงรอบบ้าน คนละหน้าที่กันหมด
ชั้นกายภาพ (เข้าอาคาร/ห้อง server) → physical access controls — biometric (ลายนิ้วมือ ม่านตา), card reader, keypad, ยาม, บัตร ID พวกนี้กันคนเดินเข้าไปในห้องจริงๆ
ชั้น logical (เข้าถึงข้อมูล/ระบบ/โปรแกรม) → authorization table, บัญชีผู้ใช้เฉพาะตัว, auto log-off ตอนไม่มีคนใช้, คำถามตั้งรหัสใหม่ พวกนี้กันการเข้าถึง ข้อมูล
Firewall — อันนี้ต้องจำให้แม่นเลยเพราะโจทย์รักมาก มันคือกำแพงที่แยกเครือข่ายภายในออกจากภายนอก แล้วก็กัน การ login ที่ไม่ได้ยืนยันตัวตนจากคนภายนอก เท่านั้น firewall ไม่ กันไวรัส ไม่กัน Trojan ไม่กันคนในที่แอบเอาข้อมูลออกทางแฟลชไดรฟ์
Encryption — เข้ารหัสข้อมูลให้ใครดักไปก็อ่านไม่ออก เป็นคำตอบของภัย ความลับของข้อมูลที่จัดเก็บหรือส่ง เท่านั้น ไม่ใช่ภัยการเดินเข้าห้องหรือ login
พูดถึงการเจาะจากภายนอก ยังมี intrusion detection system (IDS) — ระบบตรวจจับการบุกรุกที่เฝ้าดูทราฟฟิกเครือข่าย เทียบกับฐานข้อมูลรูปแบบภัยที่รู้จัก แล้วส่งสัญญาณเตือนเมื่อเจอ ส่วนตัวที่ บล็อก ทราฟฟิกร้ายได้เลยคือ intrusion prevention system (IPS) รวมกันเรียก IDPS ทำงานแบบ real-time เสริม firewall อีกชั้น
มุมผู้ตรวจ (คนสอบ): อ่านภัยใน stem → ติดป้ายว่าอยู่ชั้นไหน → จับ control ให้ตรงชั้น
⚠️ กับดัก: โจทย์ชอบยัด encryption มาแก้ภัยการเข้าถึง/เข้าอาคาร — แต่ encryption คุ้มครองข้อมูลที่จัดเก็บ ไฟล์ตอนถูกเปิดใช้งานก็ถอดรหัสแล้ว และมันไม่เคยบล็อกการเดินเข้าห้องหรือ login เลย กลับกัน ยัด “access-control software” มาแก้ภัย กายภาพ — software หยุดคนเดินเข้าห้อง server ไม่ได้ ส่วน “screensaver / keystroke log / transaction log” ที่ยัดมาแก้ภัย “ป้องกันการเข้าถึง” ก็ผิด เพราะพวกนี้ทำงาน หลัง เข้าไปแล้ว ไม่ได้กันตอนเข้า และมุมกลับ ถ้าถาม “อันไหนเป็น control แบบ logical” ทีนี้ของกายภาพ (card reader, biometric, keypad) กลายเป็นตัวหลอก ส่วน authorization table เป็นคำตอบ
⚠️ กับดัก: เรื่อง firewall — ตัวหลอกคือ “ไวรัส”, “Trojan horse”, “คนในแอบส่งข้อมูลออก” firewall กันไม่ได้สักอย่าง และมุมกลับ ถ้าภัยคือ คำร้องที่เป็นอันตรายต่อ web application คำตอบเลื่อนไปเป็น application gateway ไม่ใช่ firewall ธรรมดา ส่วนถามว่าอะไรลด “จุดอ่อนของ firewall” — คำตอบคือ password/authentication เพราะ firewall พึ่งการยืนยันตัวตน
สัตว์แต่ละตัวใน malware zoo
ก่อนไปเรื่องรับมือ ต้องรู้จักตัวร้ายก่อน — พวก malicious software (malware) หรือซอฟต์แวร์ประสงค์ร้ายที่ลอบเข้ามาผ่านช่องโหว่ของแอปหรือระบบปฏิบัติการ วิธีจำที่ผมใช้คือ ผูกแต่ละคำกับพฤติกรรมเด่นแค่หนึ่งเดียว ของมัน อย่าไปจำที่อาการร่วม เพราะอาการร่วมนี่แหละที่โจทย์เอามาหลอก
- Virus — จำลองตัวเองด้วยการ แนบไปกับโปรแกรมอื่น (นี่คือลายเซ็นเฉพาะ Trojan ทำไม่ได้)
- Worm — โปรแกรมอิสระที่ ก็อปตัวเองข้ามเครื่อง กินทรัพยากรจน DoS
- Trojan horse — ดูเหมือนโปรแกรมปกติ (เช่นสเปรดชีต) แต่ซ่อนฟังก์ชันร้ายไว้ ทำงานตอนถูกรัน อาจเปิดเป็น backdoor
- Spoofing — ปลอมตัวตน (เว็บปลอม ผู้ส่งปลอม)
- Ransomware — ล็อก/ขู่เผยข้อมูลเพื่อ เรียกค่าไถ่ (คีย์เวิร์ดคือ “extort”)
- Phishing — ใช้อีเมล/ข้อความ/เสียง/เว็บปลอม หลอกให้คนแบ่งปันข้อมูล (คีย์เวิร์ดคือ “หลอก/deceive”)
- Denial-of-service (DoS) — ถล่มด้วยคำร้องเท็จจน server ล่ม ถ้ามาจากหลายแหล่งผ่านเครื่องผู้บริสุทธิ์ที่ติด Trojan = distributed DoS (DDoS)
มุมผู้ตรวจ (คนสอบ):
⚠️ กับดัก: โจทย์เอา อาการร่วม มาล่อ — Trojan ก็ทำข้อมูลเสียหาย/ลบไฟล์ได้เหมือนกัน เลยเอา “ทำข้อมูลเสีย” มาแข่งกับ “จำลองตัวเอง” ทั้งที่ การจำลองตัวเอง เป็นของ virus เท่านั้น อีกกับดักคือชื่อการโจมตีคล้ายๆ กัน (brute-force, sniffing, man-in-the-middle) เอามาแข่งกับ spoofing/DDoS เพราะทั้งหมดเป็น “online attack” และคู่ที่สับกันบ่อยคือ ransomware (เรียกค่าไถ่) กับ phishing (หลอกให้แบ่งข้อมูล) — เลือกด้วยกริยาใน stem: extort หรือ deceive
Information protection — กันไว้ที่ต้นทาง อย่าตามแก้
พอรู้จักตัวร้ายแล้ว คำถามคือกันด้วย control พันธุ์ไหน หลักที่ข้อสอบยึดคือ คำว่า “best / most effective / ทันที” มันมักหมายถึง control ที่ หยุดภัยก่อนเกิด ไม่ใช่ตัวที่ตรวจเจอ ตรวจสอบ หรือกู้คืนทีหลัง
- Preventive (หยุดก่อนเกิด) = ยอมให้ใช้เฉพาะซอฟต์แวร์ที่อนุญาตจากแหล่งที่รู้จัก, application control ที่กันแอปแปลกปลอมไม่ให้รัน, IDS/IPS แบบ real-time ที่บล็อกได้, patch ตามรอบ — พวกนี้คือคำตอบ
- ตรวจเจอทีหลัง (audit, review log, เทียบเวอร์ชัน) = detective → ตัดทิ้งถ้าโจทย์ถาม preventive
- แก้/กู้หลังติด (รันโปรแกรมกำจัดไวรัส, กู้จากแผน recovery, แก้หลังโดนเจาะ) = corrective → ตัดทิ้งเช่นกัน
หลักเรื่อง protectability คือ IT asset ต้องมี safeguard กันการเข้าถึง/ใช้/ทำอันตรายโดยไม่ได้รับอนุญาต และซอฟต์แวร์จากแหล่งที่รู้จักก็ยังควรเอาไปทดสอบใน quarantine (เครื่องแยกเดี่ยว) ก่อน เพราะแม้แต่ของจาก vendor ก็อาจติดไวรัสมา
มุมผู้ตรวจ (คนสอบ): จัดกลุ่มแต่ละตัวเลือกก่อน แล้วเลือก preventive
⚠️ กับดัก: ตัวหลอก detective แต่งตัวเป็นทางแก้ — “ตรวจนับ inventory ซอฟต์แวร์”, “เทียบกับเวอร์ชันที่อนุญาต”, “เฝ้า log ด้วยมือ”, “security audit รายไตรมาส” พวกนี้ เจอ ปัญหา ไม่ได้ กัน และตัวหลอก corrective — “รันโปรแกรมกำจัดไวรัส”, “เตรียมและทดสอบแผนกู้คืน” ทำงานหลังติดแล้ว ส่วน “เพิ่มการอบรม / ลงโทษวินัย” ยกระดับความรู้แต่ไม่ได้บล็อกการกระทำในทางเทคนิค ถ้ามี preventive สองตัวเสมอกัน ให้เลือกตัวที่เป็น ระบบ/แก้ราก ไม่ใช่แค่เพิ่มความถี่ของการรีวิว
ใครเป็นเจ้าของความน่าเชื่อถือของข้อมูล
อีกเรื่องที่ต้องปักหมุด — information reliability and integrity (IRI) ความน่าเชื่อถือและความถูกต้องของข้อมูล อันนี้เป็นหน้าที่ของ management ครับ ไม่ใช่ฝ่าย IT (IT แค่เป็น custodian ที่ถูกฝ่ายบริหารมอบให้เฝ้าและบังคับใช้นโยบาย) ไม่ใช่ “พนักงานทุกคน” ไม่ใช่ผู้ถือหุ้น ส่วน CAE เป็นคนตัดสินว่า internal audit function มีทรัพยากรที่เก่งพอจะประเมิน IRI กับความเสี่ยงที่เกี่ยวข้องไหม
มุมผู้ตรวจ (คนสอบ):
⚠️ กับดัก: โจทย์เอา “ฝ่าย IT” มาเป็นเจ้าของปลอมของ IRI, เอา “พนักงานทุกคน/ผู้ถือหุ้น” มาหลอกด้วยความรู้สึกครอบคลุม และในข้อทรัพยากร เอา CEO/COO/ผู้สอบบัญชีภายนอกมาแทน CAE — จำว่าเจ้าของ integrity คือ management, คนตัดสินทรัพยากรตรวจสอบคือ CAE
Incident response — ผู้ตรวจประเมิน ไม่ลงมือ
กันเต็มที่แล้วก็ยังมีวันที่โดนเจาะจนได้ คำถามคือ “รับมือยังไง” — อันนี้คือ incident response
Incident คือเหตุด้านความปลอดภัยไซเบอร์ที่คุกคาม confidentiality, integrity หรือ availability ของข้อมูลหรือระบบ เป้าหมายของ incident response management คือ ป้องกันการโจมตีและลดการหยุดชะงักของธุรกิจกับต้นทุน ลำดับขั้นเริ่มที่ Identification (รับรู้/ยอมรับว่าอาจมีเหตุ) แล้วค่อย classify → notify/escalate → investigate
คำศัพท์ที่โจทย์ชอบสลับต้องล็อกให้แม่น:
- Precursor = สัญญาณว่าภัย กำลังจะมา (คนร้ายกำลังเตรียมตัว)
- Indicator = สัญญาณว่าเหตุ อาจเกิดขึ้นแล้ว
- Escalation = การ แจ้ง stakeholder ให้องค์กรตอบสนองทันเวลา (ไม่ใช่การยกระดับความรุนแรง ไม่ใช่การ auto-resolve ไม่ใช่การ document)
ทีนี้บทบาทของผู้ตรวจ — จำคาถาเดิม auditor ประเมิน ไม่ลงมือ ผู้ตรวจสอบภายในประเมินความพร้อมและประสิทธิผลของแผน แล้วแนะนำการปรับปรุง ส่วนงานลงมือจริง (สืบสวน forensic, ทำ tabletop, ทดสอบเทคโนโลยีตรวจจับ) เป็นของทีม IR/security ไม่ใช่ผู้ตรวจ
มุมเถ้าแก่: เถ้าแก่อาจอยากให้กองผู้ตรวจการที่เก่งลงไปสางเหตุเอง — แต่ลองคิดดูนะ ถ้าให้คนที่ต้องมาประเมิน ความพร้อม ของแผนทีหลัง เป็นคนลงมือตอบสนองเองเสียตั้งแต่ต้น ความเป็นกลางมันก็หายหมด ผู้ตรวจเลยยืนอยู่ที่ ประเมินและแนะนำ งานมือเปื้อนปล่อยให้ทีมเฉพาะทางเขาทำ
มุมผู้ตรวจ (คนสอบ): เลือกตัวเลือกที่ผู้ตรวจ ประเมินความพร้อม/ประสิทธิผล หรือ แนะนำการปรับปรุง ให้อุดช่องที่โจทย์บอก
⚠️ กับดัก: ตัวหลอกที่ใส่กริยาลงมือให้ผู้ตรวจ — “ช่วยสืบ forensic”, “อำนวยการ tabletop”, “ร่วมทดสอบเทคโนโลยี”, “เขียนรายงานแนวโน้ม incident ให้ผู้บริหาร” — งานทีม IR ทั้งนั้น และ “รีบ escalate ประเด็นนี้ขึ้นผู้บริหารเอง” ฟังดูเด็ดขาดแต่ เร็วไป ผลผลิตของผู้ตรวจคือ ข้อเสนอแนะ ไม่ใช่การไปแจ้งเอง ส่วนระหว่าง “review เอกสาร IR” (จริงแต่แคบ) กับ “ประเมินความพร้อมและประสิทธิผล” (กว้างกว่า) — เลือกตัวกว้างเป็นบทบาท หลัก
⚠️ กับดัก: เจอช่องไหนให้อุดช่องนั้น อย่าเลี่ยง — ช่องคือ “ไม่มีขั้นตอนแจ้งผู้เสียหาย” → แผนการแจ้ง/สื่อสาร (แจ้งภายนอกชนะเครื่องมือภายในล้วน), ช่องคือ “ไม่มีขั้นตอนกู้หลังภัยพิบัติ” → โปรโตคอล backup และ recovery, ช่องคือ “ไม่มีขั้นเก็บรักษาหลักฐาน” → เก็บ/บันทึกหลักฐานเพื่อใช้ทางกฎหมาย (ห้ามทิ้ง ห้าม “เก็บไม่มีกำหนด” ห้าม “จำกัดการเก็บ”), ช่องคือ “ไม่มีแผน/ทีม” → ตั้งทีม IR และนิยามบทบาท ส่วนตัวหลอกคือ preventive/detective (firewall, antivirus, monitoring) มาแก้ช่อง response, ขยายขอบเขตเกิน (“ขยายไปทุก IT incident”, “ทำ full risk assessment”), หรือเลี่ยงด้วยงบ/จ้างคน/outsource
Security & privacy audit — ใครเป็นเจ้าของ ใครแค่ตรวจ
ขยับมาที่การตรวจสอบด้านความปลอดภัยและความเป็นส่วนตัวกันบ้าง หัวใจคือ แยกเจ้าของออกจากผู้ตรวจให้ขาด:
- ความน่าเชื่อถือ/ความถูกต้อง/ความปลอดภัยของข้อมูลสำคัญ = management เป็นเจ้าของ (ไม่ว่าจัดเก็บด้วยสื่ออะไร IT แค่เฝ้าแทน)
- วางและกำกับ privacy framework = board (รับผิดชอบสูงสุดในการระบุความเสี่ยงหลักและวาง control ลด)
- ตัดสินความพอเพียงของทรัพยากรตรวจสอบ = CAE
- internal audit = ประเมิน ประเมิน แนะนำ — ไม่เคยเป็นเจ้าของ
ในงาน assurance ด้านความปลอดภัย ผู้ตรวจ ประเมินความเสี่ยง เฝ้าติดตามการแก้ไข ประเมิน control แต่ ไม่ออกแบบหรือ implement control เอง เพราะการไปออกแบบและวาง control มันเป็นงาน advisory คนละงานกัน การให้ความเชื่อมั่นคือ ประเมิน ไม่ใช่ สร้างเอง
มุมผู้ตรวจ (คนสอบ): จับกริยากับเจ้าของ
⚠️ กับดัก: “ออกแบบและ implement control” ถูกแต่งให้ดูเป็นส่วนหนึ่งของงาน assurance ปกติ — ผิด เพราะนั่นคือ advisory และในโจทย์แบบ “อะไรถูก ยกเว้น” ข้อที่โยนความเป็นเจ้าของ information security ให้ internal audit นั่นแหละคือข้อที่ ผิด จึงเป็นคำตอบ ส่วนโจทย์ “อะไร ห้ามทำ ในงาน assurance” — ข้อ “ทำงานกับ user/security staff เพื่อ implement control” กลายเป็นคำตอบถูก
Privacy สี่กล่อง — อย่าสลับกล่อง
privacy คือการปกป้องข้อมูลส่วนบุคคลตั้งแต่เก็บ จัดเก็บ ประมวลผล เผยแพร่ ไปจนทำลาย และลึกกว่านั้นมันคือสิทธิมนุษยชนเลยด้วยซ้ำ มีสี่กล่องที่ต้องล็อกให้แม่นและห้ามสลับ:
- Personal privacy = กายภาพ + จิตใจ
- Privacy of space = อิสระจากการ สอดส่อง (surveillance)
- Privacy of communication = อิสระจากการ ดักฟัง/เฝ้าดู (monitoring)
- Privacy of information = การเก็บ ใช้ และเปิดเผยข้อมูลส่วนบุคคล
เวลาประเมิน privacy framework ผู้ตรวจต้อง ปรึกษาที่ปรึกษากฎหมายและผู้เชี่ยวชาญ IT และพิจารณากฎหมายในเขตอำนาจที่องค์กรดำเนินการและข้อมูลเดินทางผ่าน ไม่ใช่แค่ซื้อเครื่องมือหนึ่งชิ้น สำคัญคือ ประโยชน์ของมาตรการต้องมากกว่าต้นทุน — encryption เป็นวิธีที่แพง บางครั้ง access control เหมาะกับความเสี่ยงมากกว่า
มุมเถ้าแก่: พอเจอกฎหมายความเป็นส่วนตัวที่เข้มขึ้น เถ้าแก่อาจอยากทุ่มงบซื้อ encryption รุ่นท็อปให้จบๆ ไป — แต่การซื้อของชิ้นเดียวมันไม่ทำให้ compliant ได้ทั้งกระดานหรอก ที่คุ้มกว่าคือปรึกษากฎหมายให้เข้าใจว่ากฎมันบังคับอะไรจริงๆ แล้วค่อยวาง control ให้พอดีกับความเสี่ยง
⚠️ กับดัก: โจทย์สลับกล่อง — เอา “อิสระจากการ monitoring” ไปนิยาม privacy of space (ผิด นั่นคือ communication) หรือ “อิสระจาก surveillance” ไปนิยาม communication (ผิด นั่นคือ space) ส่วนข้อ compliance ตัวหลอกคือ “เพิ่มงบซื้อ encryption ขั้นสูง”, “บังคับเข้ารหัสข้อมูลส่วนบุคคล” (จริงๆ access control อาจเหมาะกว่า), หรือ “โยน privacy ให้ผู้จัดการสายงาน” (ขาดความเชี่ยวชาญ) — คำตอบคือปรึกษากฎหมาย + IT และประเมิน control และจำเกร็ดหนึ่ง กฎหมายบางฉบับอาจ ห้าม บันทึกข้อมูลส่วนบุคคลลงในเอกสารงานตรวจสอบ
Business resilience — ไฟไหม้ทั้งตึกแล้วกู้กลับยังไง
ของชิ้นสุดท้ายในกระเป๋าใบสอง — business resilience ความสามารถขององค์กรในการรับมือ ปรับตัว และเติบโตในสภาพแวดล้อมที่ท้าทาย ในบริบทนี้มันคือเป้าหมายด้าน data availability ที่ต้องวางแผนไว้สองสถานการณ์:
- data center ยังอยู่ — ไฟดับ ไวรัส แฮก ตัวอาคารดี แต่ต้องรีบทำอะไรเพื่อให้ประมวลผลต่อ (เช่น generator สำรองเริ่มเองเมื่อไฟตก, ไวรัส/DoS ต้องปิดระบบอย่างนุ่มนวลเพื่อหยุดการแพร่)
- data center ใช้ไม่ได้ — น้ำท่วม ไฟไหม้ แผ่นดินไหว ต้องมี สถานที่ประมวลผลสำรอง
สองคำที่ต้องแยก: disaster recovery คือการ กลับมาประมวลผลปกติ หลังเหตุใหญ่ ส่วน business continuity คือการ ดำเนินธุรกิจต่อด้วยวิธีอื่น ระหว่างที่ระบบยังใช้ไม่ได้เต็มที่
Backup ที่เก็บไว้ที่เดิม เท่ากับไม่ได้ backup
Periodic backup และ off-site rotation เป็นส่วนพื้นฐานที่สุดของทุกแผน DR/BC รูทีนปกติคือ duplicate ไฟล์ข้อมูลและโปรแกรมทั้งหมดตามรอบ แล้ว backup ส่วนที่เปลี่ยนแปลง (incremental) ส่งไปเก็บนอกสถานที่เป็นระยะ จุดที่ต้องจำคือ ต้อง backup ทั้งไฟล์ข้อมูลและ application เพราะโปรแกรมมันก็เปลี่ยนได้ แล้วที่เก็บสำรองก็ต้อง ไกลพอ ที่จะไม่โดนภัยพิบัติลูกเดียวกัน
⚠️ กับดัก: ตัวหลอกคือเก็บ backup ในสถานที่เดิม — “ตู้กันไฟในห้อง data center” ฟังดูปลอดภัยแต่มันตายพร้อมกันในไฟ/น้ำเดียวกัน อีกกับดักคือเก็บแค่ master file แต่ ทิ้งไฟล์ transaction — กู้กลับมาจะขาดทุกอย่างหลัง backup ครั้งล่าสุด ต้องเก็บ ทั้ง master และ transaction ที่ปรับปรุง ถึงจะ reconstruct ได้ และ “real-time replication ไป hot site” ไม่ใช่คำตอบเสมอ — ถูกเมื่อไม่คิดเรื่องเงิน แต่ถ้าโจทย์บอกให้ ประหยัดต้นทุน สำหรับความเสียหายที่ เกิดไม่บ่อย มันคือการ over-engineer และมุมกลับ ถ้าถาม “จุดอ่อน ร้ายแรงที่สุด” ในการตรวจ DR ตัวเลือก backup on-site นั่นแหละคือคำตอบ
Hot / warm / cold — ยิ่งร้อนยิ่งเร็วยิ่งแพง
พอ data center ล่ม ต้องมีสถานที่ประมวลผลสำรอง มีสามระดับ วัดกันที่ ความเร็วในการกู้ แลกกับต้นทุน:
- Hot site — พร้อมใช้ทันที hardware+software ตั้งไว้ครบ ไม่มี downtime เสี่ยงน้อยสุด แพงสุด (สัญญาต้องมีการทดสอบประจำปี — ประกาศภัยพิบัติปลอม โหลด backup ขึ้นเครื่อง วัดว่าใช้เวลากู้เท่าไหร่)
- Warm site — กลางๆ ทรัพยากรมีอยู่แต่อาจต้อง config หรือ restore ข้อมูลบางส่วน
- Cold site — เปลือกเปล่า มีไฟ มีระบบแวดล้อม มีสายสื่อสาร แต่ต้องยกอุปกรณ์มาติดตั้งเอง พึ่ง vendor ช้าสุด ถูกสุดในระยะยาว
⚠️ กับดัก: ตัวหลอกคือ ชื่อ site ปลอม — “Quick site”, “Cool site”, “Flying-start site”, “Hot-spare agreement” ไม่มีอันไหนเป็น tier มาตรฐาน ผิดบนข้อนิยาม และ “cold” ฟังดูถูกและปลอดภัยเลยล่อบนข้อความเร็ว — แต่ cold ช้าสุดและพึ่ง vendor ผิดเมื่อโจทย์ต้องการความทันที มุมกลับ ถ้าถาม “ข้อดีของ cold” หรือ “อันไหนพึ่ง vendor เกินไป” คำตอบพลิกเป็น cold (ข้อดี = ไม่ต้องมีอุปกรณ์ตั้งไว้ / จุดอ่อน = พึ่งการส่งของจาก vendor)
DRP = กู้คืนเท่านั้น และ BCM วางกล่องให้ถูก
DRP ที่ดีต้องถูกสร้างและ ทดสอบ คู่กับแผน business continuity มันอธิบายกลยุทธ์กู้ IT — data center, แอปและข้อมูลที่ต้องใช้, server, การสื่อสาร ฯลฯ แล้วก็ต้องอิงจาก business impact analysis (BIA) อะไรที่จะนับเป็น “องค์ประกอบของ DRP” ได้ ต้องเป็นเรื่อง กู้คืนหลังเหตุ — เก็บ backup สำเนาไว้ห่างจากศูนย์คอมพิวเตอร์, ระบุแอปวิกฤต, แผนกู้ IT ละเอียดพร้อมข้อตกลง recovery กับบุคคลที่สาม
BIA คือหัวใจของการวางแผน — ระบุกระบวนการวิกฤต แล้วนิยาม recovery time objective (RTO) = ระยะเวลาที่กระบวนการต้องถูกกู้กลับภายใน และ recovery point objective (RPO) = ปริมาณข้อมูลที่ยอมเสียได้ ยิ่ง objective ทั้งสองตัวน้อยลง ต้นทุนของทางแก้ก็ยิ่งสูงขึ้น
ส่วน business continuity management (BCM) เป็น หนึ่งในสาม องค์ประกอบของ emergency management program — อีกสองคือ emergency response (มุ่งช่วยชีวิต ความปลอดภัย กรอบเวลาเป็นชั่วโมง/นาที) และ crisis management (จัดการการสื่อสารและงานผู้บริหารระดับสูง กรอบเวลาเป็นวัน/ชั่วโมง)
มุมผู้ตรวจ (คนสอบ): เจอโจทย์ “best / most crucial / primary” เรื่อง resilience ให้เลือก แผนใหญ่ที่ครอบชิ้นส่วน ไม่ใช่ชิ้นส่วนเดียว
⚠️ กับดัก: เอาชิ้นส่วนจริง (IS backup, สถานที่สำรอง, BIA) มาบอกว่า “สำคัญที่สุด” — แต่มันอยู่ ใน DRP แผนใหญ่จึงชนะ และมี “continuous availability” (เทคโนโลยีล้วน) หรือ “crisis communication” (สื่อสารล้วน) มาหลอกแทน business continuity planning ส่วนโจทย์ที่ถามวัตถุประสงค์ตรวจ ครบต้องเลือกข้อที่คลุม ทั้งหมด ไม่ใช่ข้อที่ลงท้าย “only”
⚠️ กับดัก: DRP นับเฉพาะ กู้คืน — ตัวหลอกคือ prevention แต่งเป็น recovery: “UPS/ไฟสำรอง”, “physical security” พวกนี้ กันเหตุ หรือ ประคองการประมวลผลปัจจุบัน ไม่ใช่การกู้ และ housekeeping (inventory อุปกรณ์, รายชื่อลูกค้า, cross-training, เปลี่ยน PC) ก็ไม่ใช่ขั้นกู้ ส่วนเรื่องสัตว์ตัวใหม่ — ทบทวน reciprocal agreement ความกังวลหลักคือ hardware/software ของสององค์กร เข้ากันได้ไหม ไม่ใช่ BIA
⚠️ กับดัก: วางกล่อง BCM ให้ถูก — RTO/RPO และ “ระบุกระบวนการวิกฤต” เป็นงาน BIA (อย่าโยนไป risk assessment), “ระบุภัยและประเมินผลกระทบ/ความน่าจะเป็น” เป็น risk assessment & mitigation (อย่าดึงมา BIA), และสามองค์ประกอบคือ BCM + emergency response + crisis management เท่านั้น (ถ้าตัวเลือกใส่ DR, backup, หรือ risk assessment เป็น “องค์ประกอบ” ผิด เพราะพวกนั้นอยู่ ใต้ BCM) มุมกลับ ถ้าถาม “BCM ให้ทุกอย่าง ยกเว้น” ตัวที่ผิดคือ segregation of duties (มันเป็น ประเภท control ไม่ใช่องค์ประกอบ continuity)
พิสูจน์ด้วยการทดสอบเท่านั้น
ปิดท้ายด้วยหลักที่สำคัญสุด — ประสิทธิผลของแผน continuity/contingency พิสูจน์ได้ด้วยการทดสอบที่สำเร็จเท่านั้น ไม่ใช่เอกสารครบ ไม่ใช่ผู้ตรวจเซ็นรับ ไม่ใช่ปีที่ผ่านมาไม่มีระบบล่ม แล้วก็ไม่ใช่มี generator/cold storage/inventory ตั้งไว้เฉยๆ IIA แนะให้ทดสอบขนาดใหญ่อย่างน้อยปีละครั้ง มีหลายแบบ ตั้งแต่ desk check (สอบทานเอกสาร เบาสุด), walkthrough, tabletop (จำลองเหตุแบบผ่อนคลาย), communication testing, ไปจนถึง end-to-end testing (ทดสอบทั้งกระบวนการตั้งแต่ต้นจนจบ)
มุมเถ้าแก่: เถ้าแก่หลายคนสบายใจเพราะ “มีแผนเป็นเล่ม มี generator ตั้งอยู่” — แต่แผนที่ไม่เคยลองใช้จริง ก็เหมือนถังดับเพลิงที่ไม่เคยเช็ก วันไฟไหม้จริงอาจฉีดไม่ออก การนอนหลับสบายมาจากการ ซ้อม ไม่ใช่การมีของ
มุมผู้ตรวจ (คนสอบ): ถามตัวเองว่าตัวเลือกนั้น แสดงการกู้คืนภายใต้การจำลองเหตุ ไหม ถ้าใช่ (การทดสอบสำเร็จ หรือตัวชี้วัดจากการทดสอบ เช่น เวลาที่ใช้กู้กระบวนการวิกฤตระหว่างทดสอบ) นั่นคือคำตอบ
⚠️ กับดัก: “เอกสารครบถ้วน”, “ผู้ตรวจเซ็นรับ”, “ปีที่ผ่านมาไม่มีการหยุดชะงัก” ฟังดูน่าเชื่อถือแต่ ไม่พิสูจน์อะไร จนกว่าจะได้ลอง และตัวชี้วัดของ site สำรอง — จำนวน/ระยะทาง/ต้นทุนเป็นแค่คุณสมบัติการวางแผน มีเพียง เวลาที่ใช้กู้กระบวนการวิกฤตระหว่างทดสอบ ที่วัดประสิทธิผลจริง
ตารางกับดักรวม
| สถานการณ์ | คำตอบหลอก | คำตอบจริง |
|---|---|---|
| ข้อมูลถูกดักระหว่างส่ง | ทำ risk assessment อีกรอบ / เปลี่ยน vendor / อบรม | encryption (end-to-end ถ้าระบุ) |
| patch ไม่สม่ำเสมอ | เปลี่ยน provider / จ้างคนเพิ่ม | ระบบ/นโยบาย patch รวมศูนย์ |
| สิทธิ์เข้าถึงคุมไม่อยู่ | เพิ่ม encryption / อบรม | IAM framework |
| อาการตรงกับความเสี่ยง IoT ไหน | ชื่อความเสี่ยง IoT อื่นที่ skim แล้วเผลอตอบ | ชื่อที่ตรงกลไกที่ stem บรรยาย |
| ”best describes” ความเสี่ยง IoT | ข้อที่ฟังดูดี (แข็งแรง/รัดกุม) | ข้อที่ยอมรับจุดอ่อน (ไม่มี encryption) |
| นิยาม cloud service model | นิยาม model อื่นที่สลับมา / private cloud | IaaS/PaaS/SaaS/CSP ตาม “ใครดูแลชั้นไหน” |
| ภัย “unique to cloud” | ขโมย credential / legacy / ransomware (มีทั้งสองที่) | loss of visibility/control, ลบไม่หมด, tenant แยกไม่ขาด |
| รากฐาน/ก่อน/ขั้นแรกของความปลอดภัย | pen test / 2FA / firewall / อัปเดต | policy (และประเมิน policy ที่มีก่อน) |
| firewall กันอะไร | ไวรัส / Trojan / คนในแอบส่งออก | การ login ไม่ยืนยันตัวจากคนนอกเท่านั้น |
| คำร้องร้ายต่อ web app | firewall ธรรมดา / packet-filter | application gateway |
| ภัยเข้าอาคาร/ห้อง server | encryption / access-control software | biometric / physical access controls |
| ภัยเข้าถึงข้อมูล (logical) | card reader / biometric / keypad (physical) | authorization table / auto log-off |
| virus ต่างจาก Trojan ตรงไหน | ทำข้อมูลเสีย / ลบไฟล์ (อาการร่วม) | จำลองตัวเอง (replicate) |
| เรียกค่าไถ่ vs หลอกให้แบ่งข้อมูล | สลับ ransomware กับ phishing | ดูกริยา: extort=ransomware, deceive=phishing |
| ”best/most effective” กันไวรัส | audit / review log / กำจัดไวรัส / กู้คืน | preventive: อนุญาตเฉพาะซอฟต์แวร์ที่รู้จัก |
| เจ้าของ IRI | ฝ่าย IT / พนักงานทุกคน / ผู้ถือหุ้น | management (ทรัพยากรตรวจ = CAE) |
| precursor vs indicator | สลับ imminent กับ occurred | precursor=กำลังจะมา, indicator=อาจเกิดแล้ว |
| จุดประสงค์ escalation | ยกระดับความรุนแรง / auto-resolve / document | แจ้ง stakeholder ให้ตอบสนองทันเวลา |
| บทบาทผู้ตรวจใน IR | ลงมือ forensic/tabletop / escalate เอง | ประเมินความพร้อม+ประสิทธิผล แนะนำปรับปรุง |
| อุดช่อง IR | preventive tool / ขยายขอบเขต / งบ | control ที่สร้างขั้นตอนที่ขาดตรงๆ |
| assurance ทำอะไรได้ | ออกแบบและ implement control | ประเมินความเสี่ยง/control (implement = advisory) |
| privacy of space vs communication | สลับ monitoring กับ surveillance | space=surveillance, communication=monitoring |
| ทางแก้ privacy compliance | เพิ่มงบซื้อ encryption / โยนให้ line manager | ปรึกษากฎหมาย + IT ประเมิน control |
| เก็บ backup ที่ไหน | ตู้กันไฟในห้อง data center (on-site) | off-site + เก็บทั้ง master และ transaction |
| ชื่อ recovery site | Quick / Cool / Flying-start / Hot-spare | hot / warm / cold |
| องค์ประกอบ DRP | UPS/ไฟสำรอง / physical security (กันเหตุ) | เก็บ backup ห่างศูนย์ / ระบุแอปวิกฤต / กู้ IT |
| RTO/RPO เป็นงานกล่องไหน | risk assessment / recovery strategy | BIA |
| สามองค์ประกอบ emergency mgmt | ใส่ DR/backup/risk assessment เป็นองค์ประกอบ | BCM + emergency response + crisis management |
| พิสูจน์ว่าแผนใช้ได้ | เอกสารครบ / ผู้ตรวจเซ็น / ปีนี้ไม่ล่ม | การทดสอบที่สำเร็จเท่านั้น |
สิ่งที่จดสำหรับวันสอบ
- ตั้งชื่อภัยใน stem ก่อนเลือก control — encryption แก้ข้อมูลรั่ว, IAM คุมสิทธิ์, patch รวมศูนย์แก้ patch มั่ว, network monitoring จับการเจาะ
- ภัย “unique to cloud” = ตัวที่หายไปถ้ากลับไป on-premises (มองไม่เห็น/คุมไม่ได้, ลบไม่หมด, tenant แยกไม่ขาด, self-provision)
- Cybersecurity Topical Requirement = baseline ขั้นต่ำ บังคับสำหรับ assurance · ไม่ปลดจาก the Standards · CAE รับผิดชอบทรัพยากรและ conformance แม้ outsource
- Policy คือรากฐาน เครื่องมือมาทีหลัง — เจอ pen test/2FA/firewall บนข้อ “รากฐาน/ก่อน/แรก” = ผิด
- จับ control ตรงชั้น: firewall กันคนนอก (ไม่กันไวรัส/คนใน), encryption กันข้อมูลจัดเก็บ/ส่ง, biometric/physical กันเข้าอาคาร, IDS จับทราฟฟิกร้าย
- malware ผูกหนึ่งคำหนึ่งพฤติกรรม: virus=จำลองตัว, worm=ข้ามเครื่อง, Trojan=แฝงตัว, spoofing=ปลอมตัวตน, ransomware=เรียกค่าไถ่, phishing=หลอกให้แบ่งข้อมูล
- “best/most effective” กันภัย = preventive เสมอ · detective/corrective เป็นตัวหลอก
- เจ้าของ integrity ข้อมูล = management · framework privacy = board · ทรัพยากรตรวจ = CAE · IA แค่ประเมิน
- IR: ผู้ตรวจประเมิน ไม่ลงมือ · precursor=กำลังจะมา, indicator=อาจเกิดแล้ว · escalation=แจ้ง stakeholder · เจอช่องอุดช่องนั้นตรงๆ
- assurance = ประเมิน · การออกแบบ/implement control = advisory (คนละงาน)
- privacy สี่กล่อง: space=surveillance, communication=monitoring, information=เก็บ/ใช้/เปิดเผย, personal=กาย+ใจ · encryption แพง access control อาจเหมาะกว่า
- backup ต้อง off-site + เก็บทั้ง master และ transaction · on-site = จุดอ่อนร้ายแรงสุด
- hot=เร็วแพง / cold=ช้าถูกพึ่ง vendor / warm=กลาง · ชื่อ site แปลกๆ = ปลอม
- DRP นับเฉพาะ กู้คืน (UPS/physical security = กันเหตุ ไม่นับ) · RTO/RPO = งาน BIA · สามองค์ประกอบ = BCM + emergency response + crisis management
- แผน continuity พิสูจน์ด้วยการทดสอบที่สำเร็จเท่านั้น — เอกสาร/เซ็นรับ/ปีนี้ไม่ล่ม ไม่นับ
ปิดกระเป๋าไซเบอร์แล้ว ตอนหน้าเปลี่ยนโหมดจากภัยดิจิทัลมาที่ภาษาตัวเลข — การอ่านงบการเงินให้เป็นภาษาผู้ตรวจ งบสี่ตัวเชื่อมกันยังไง ทำไม accrual ถึงบอกความจริงมากกว่าเงินสด และ ratio ตัวไหนที่ใช้เป็นเข็มทิศ ตอนถัดไป: กระเป๋าบัญชี — อ่านงบการเงินให้เป็น
อ้างอิง: Gleim CIA Review (2026), Part 2 · IIA Global Internal Audit Standards (2024)
