CISSP Domain 1: Security and Risk Management

Domain 1 วางรากฐานให้ทุก Domain ที่เหลือ เพราะการรักษาความมั่นคงปลอดภัยไม่ได้เริ่มจากการซื้อเทคโนโลยี แต่เริ่มจากการเข้าใจวัตถุประสงค์ขององค์กร หน้าที่ตามกฎหมาย คุณค่าของสินทรัพย์ ระดับความเสี่ยงที่ยอมรับได้ และผู้มีอำนาจตัดสินใจ เนื้อหาบทนี้จึงควรอ่านด้วยมุมมองของผู้บริหารความมั่นคงปลอดภัย ไม่ใช่มุมมองของผู้ดูแลระบบเพียงอย่างเดียว

หลักคิดสำหรับข้อสอบ: เลือกคำตอบที่คุ้มครองชีวิตและสังคม สอดคล้องกฎหมาย สนับสนุนวัตถุประสงค์ธุรกิจ และจัดการความเสี่ยงอย่างมีหลักฐาน ก่อนเลือกวิธีแก้เชิงเทคนิคเฉพาะจุด

1. ภาพรวม Domain และน้ำหนักข้อสอบ

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 1 มีน้ำหนักเฉลี่ย 16% ของข้อสอบ เนื้อหาหลักประกอบด้วยจริยธรรม แนวคิดพื้นฐานด้าน security governance ข้อกฎหมายและ compliance การจัดทำนโยบาย Business Continuity การรักษาความปลอดภัยบุคลากร risk management, threat modeling, Supply Chain Risk Management และโครงการ security awareness and training

คำว่า “น้ำหนักเฉลี่ย” ไม่ได้หมายความว่าผู้สอบทุกคนจะพบคำถาม Domain นี้ในสัดส่วนเท่ากันทุกครั้ง โดยเฉพาะเมื่อข้อสอบใช้รูปแบบ Computerized Adaptive Testing ผู้สมัครจึงควรใช้ตัวเลขเพื่อจัดลำดับเวลาอ่าน ไม่ควรใช้เพื่อคาดเดาจำนวนข้ออย่างตายตัว

สิ่งที่ Domain นี้ต้องการวัดมีสามระดับ

1. เข้าใจหลักการ เช่น Confidentiality, Integrity, Availability, due care, risk appetite และ policy hierarchy
2. แยกบทบาทและกระบวนการได้ เช่น governance ต่างจาก management อย่างไร data owner ต่างจาก custodian อย่างไร และ BCP ต่างจาก DRP อย่างไร
3. ตัดสินใจตามสถานการณ์ได้ เช่น เมื่อพบความเสี่ยงควรวิเคราะห์และส่งให้ risk owner ตัดสินใจก่อนหรือควรติดตั้ง control ทันที เมื่อกฎหมายหลายเขตอำนาจขัดกันควรทำอย่างไร และ metric ใดสะท้อนผลของ awareness program จริง

Domain 1 เชื่อมคน กระบวนการ และเทคโนโลยีเข้าด้วยกัน ถ้าองค์กรมี firewall ที่ตั้งค่าดีแต่ไม่มีเจ้าของข้อมูล ไม่มีเกณฑ์รับความเสี่ยง ไม่มีขั้นตอนจัดการข้อยกเว้น และไม่มีแผนฟื้นฟู ก็ยังไม่ถือว่ามี security program ที่บริหารได้อย่างเป็นระบบ

2. แนวคิดหลักพร้อมคำอธิบาย

2.1 CIA Triad

CIA Triad เป็นวัตถุประสงค์พื้นฐานสามด้านของ information security

• Confidentiality หรือการรักษาความลับ ทำให้ข้อมูลเปิดเผยเฉพาะบุคคล กระบวนการ หรือระบบที่ได้รับอนุญาต ตัวอย่าง control ได้แก่ data classification, access control, encryption และการอบรมเรื่องการจัดการข้อมูล
• Integrity หรือความถูกต้องครบถ้วน ทำให้ข้อมูลและระบบไม่ถูกแก้ไขหรือทำลายโดยไม่ได้รับอนุญาต และสามารถตรวจพบการเปลี่ยนแปลงที่ไม่เหมาะสม ตัวอย่าง control ได้แก่ hashing, digital signature, input validation, change control และ separation of duties
• Availability หรือความพร้อมใช้ ทำให้ผู้มีสิทธิเข้าถึงข้อมูลและบริการได้เมื่อจำเป็น ตัวอย่าง control ได้แก่ redundancy, fault tolerance, backup, capacity management, DDoS protection และแผนกู้คืน

ทั้งสามด้านต้องสมดุลตามบริบทธุรกิจ ระบบเวชระเบียนอาจต้องรักษาความลับสูง แต่ถ้าควบคุมเข้มจนแพทย์เข้าถึงข้อมูลฉุกเฉินไม่ได้ การคุ้มครอง Confidentiality ก็สร้างความเสียหายต่อ Availability และความปลอดภัยของผู้ป่วยได้ การตัดสินใจจึงต้องอ้างอิง impact และ risk ไม่ใช่เพิ่มความเข้มของ control ทุกด้านโดยอัตโนมัติ

คุณสมบัติที่มักใช้ร่วมกับ CIA ได้แก่

• Authenticity คือความเชื่อมั่นว่าบุคคล ระบบ ข้อความ หรือแหล่งข้อมูลเป็นของจริงตามที่กล่าวอ้าง
• Nonrepudiation คือความสามารถในการมีหลักฐานที่ทำให้คู่กรณีปฏิเสธการกระทำหรือการส่งข้อมูลได้ยาก เช่น digital signature ที่ใช้ร่วมกับกระบวนการจัดการกุญแจและหลักฐานที่เหมาะสม
• Accountability คือความสามารถในการผูกการกระทำกับตัวตนหรือบทบาทที่รับผิดชอบ ผ่าน identity, authorization, logging และการทบทวน
• Privacy มุ่งการประมวลผล personal data อย่างเหมาะสมตามวัตถุประสงค์ สิทธิของบุคคล และข้อกฎหมาย Privacy จึงไม่เท่ากับ Confidentiality เพราะข้อมูลอาจถูกเก็บเป็นความลับแต่ยังถูกใช้เกินวัตถุประสงค์ที่ชอบด้วยกฎหมายได้

2.2 Security Governance

Governance กำหนดทิศทาง เป้าหมาย ขอบเขตอำนาจ ความรับผิดรับชอบ และการกำกับดูแล ส่วน management วางแผน สร้าง ดำเนินงาน และติดตามกิจกรรมเพื่อให้เป็นไปตามทิศทางนั้น คณะกรรมการและผู้บริหารระดับสูงต้องทำให้ security strategy เชื่อมกับ mission, business objectives และ enterprise risk ไม่ใช่แยก security เป็นงานของฝ่าย IT เท่านั้น

องค์ประกอบสำคัญของ governance ได้แก่

• โครงสร้างการตัดสินใจและสายรายงานที่ชัดเจน
• นโยบายและกรอบควบคุมที่ได้รับอนุมัติจากผู้มีอำนาจ
• การกำหนด accountability ให้ risk owner และ asset owner
• ทรัพยากร งบประมาณ และบุคลากรที่เหมาะกับความเสี่ยง
• metric และรายงานที่ช่วยผู้บริหารตัดสินใจ
• independent assurance เช่น internal audit
• การทบทวนเมื่อกลยุทธ์ เทคโนโลยี กฎหมาย หรือสภาพภัยคุกคามเปลี่ยน

หลัก due care หมายถึงการใช้ความระมัดระวังที่สมเหตุสมผล เช่น กำหนด control และนโยบายที่เหมาะกับความเสี่ยง ส่วน due diligence หมายถึงการตรวจสอบอย่างต่อเนื่องว่าการตัดสินใจและ control เหล่านั้นเหมาะสม ถูกนำไปใช้ และยังทำงานตามที่ตั้งใจไว้ การเขียน policy แล้วไม่ตรวจการปฏิบัติจึงไม่เพียงพอ

2.3 Risk เป็นภาษากลางของการตัดสินใจ

Risk คือผลของความไม่แน่นอนต่อวัตถุประสงค์ ในบริบท security มักพิจารณาความเป็นไปได้ที่ threat จะใช้ประโยชน์จาก vulnerability แล้วสร้าง impact ต่อองค์กร บุคคล หรือสังคม คำสำคัญต้องแยกจากกันให้ชัด

• Asset คือสิ่งที่มีคุณค่าต่อองค์กร
• Threat คือสิ่งหรือเหตุการณ์ที่อาจก่ออันตราย
• Vulnerability คือจุดอ่อนหรือสภาวะที่เปิดโอกาสให้เกิดผลเสีย
• Threat event คือเหตุการณ์ที่ threat กระทำหรือเกิดขึ้นจริง
• Likelihood คือโอกาสที่เหตุการณ์จะเกิดและนำไปสู่ผลกระทบ
• Impact คือขนาดของผลเสียต่อภารกิจ การเงิน กฎหมาย ชื่อเสียง บุคคล หรือความปลอดภัย
• Control คือมาตรการที่ปรับเปลี่ยน risk

การมี vulnerability ไม่ได้แปลว่ามี risk สูงเสมอไป ถ้าระบบแยกจากเครือข่าย ไม่มี threat path ที่เป็นไปได้ และ impact ต่ำ risk อาจต่ำ ในทางกลับกัน vulnerability ที่ดูเล็กอาจมี risk สูงเมื่ออยู่ในระบบสำคัญและมี threat actor ใช้งานได้ง่าย

2.4 Compliance ไม่เท่ากับ Security

Compliance คือการปฏิบัติตาม obligations ที่ใช้บังคับ เช่น กฎหมาย กฎระเบียบ สัญญา มาตรฐานอุตสาหกรรม และนโยบายภายใน ส่วน security คือการจัดการความเสี่ยงให้เหมาะกับวัตถุประสงค์ การผ่าน audit ณ ช่วงเวลาหนึ่งไม่ได้พิสูจน์ว่าองค์กรปลอดภัยต่อภัยคุกคามทั้งหมด และ control ที่จำเป็นต่อความเสี่ยงอาจมากกว่าข้อกำหนดขั้นต่ำ

แนวทางที่ถูกต้องคือรวบรวม obligations สร้าง control ที่ตอบทั้งความเสี่ยงและข้อบังคับ เก็บหลักฐานการปฏิบัติ และติดตามการเปลี่ยนแปลงอย่างต่อเนื่อง ไม่ควรสร้าง control แยกชุดสำหรับทุกกฎหมายหากสามารถใช้ control เดียวตอบหลาย requirement ได้

2.5 Policy เป็นคำสั่งจาก governance สู่การปฏิบัติ

Security policy แปลงเจตนาของผู้บริหารเป็นข้อกำหนดระดับองค์กร จากนั้น standards, baselines, procedures และ guidelines ทำให้ข้อกำหนดนั้นนำไปใช้ได้จริง เอกสารต้องมี owner, approval, version, effective date, review cycle, exception process และช่องทางสื่อสาร ผู้ปฏิบัติงานควรหาเวอร์ชันปัจจุบันได้ง่าย

3. เจาะลึกหัวข้อย่อยพร้อมตัวอย่าง

3.1 โครงสร้าง governance และบทบาท

บทบาทอาจใช้ชื่อต่างกันในแต่ละองค์กร แต่หลัก accountability ควรชัดเจน

• Board of Directors หรือ governing body กำกับทิศทางและดูแลว่า cyber risk อยู่ใน enterprise risk management อย่างเหมาะสม
• Senior management อนุมัตินโยบาย จัดสรรทรัพยากร กำหนด risk appetite และยอมรับ residual risk ที่อยู่ในอำนาจของตน
• CISO หรือ security leader พัฒนา security strategy ให้สอดคล้องธุรกิจ ให้คำแนะนำ ประสาน control และรายงานสถานะความเสี่ยง CISO ไม่ควรเป็นผู้ยอมรับความเสี่ยงของทุกหน่วยธุรกิจแทน risk owner
• Risk owner เป็นผู้รับผิดรับชอบต่อการตัดสินใจและติดตาม risk รายการหนึ่ง รวมถึงเสนอหรืออนุมัติ risk response ตาม delegated authority
• Data owner หรือ information owner กำหนด classification, access requirements, handling requirements และการยอมรับ risk ของข้อมูล
• Data custodian ดูแลข้อมูลและใช้ control ตามที่ owner กำหนด เช่น backup, access provisioning หรือ storage configuration
• System owner รับผิดชอบระบบตลอด lifecycle และประสาน requirement ด้านธุรกิจ ความปลอดภัย และการปฏิบัติการ
• User ใช้ทรัพยากรตาม policy และรายงานเหตุผิดปกติ
• Internal audit ให้ assurance อย่างเป็นอิสระ ไม่ควรออกแบบและเป็นเจ้าของ control เดียวกับที่ตนต้องตรวจ

โมเดล Three Lines ช่วยแยกหน้าที่โดยสรุป: หน่วยธุรกิจและ operations เป็นด่านแรกที่เป็นเจ้าของและจัดการ risk, risk/compliance/security oversight เป็นด่านที่สองซึ่งกำหนดกรอบและติดตาม, internal audit เป็นด่านที่สามซึ่งประเมินอย่างอิสระ การแบ่งนี้ไม่ได้ลด accountability ของฝ่ายธุรกิจ

ตัวอย่าง: ฝ่ายการตลาดต้องการใช้ SaaS ใหม่เพื่อวิเคราะห์ลูกค้า Data owner ระบุว่า dataset มี personal data ฝ่าย security และ privacy ประเมิน control และข้อกฎหมาย Procurement ใส่ security requirements กับสิทธิในการตรวจสอบในสัญญา แต่ business risk owner เป็นผู้ตัดสินใจรับ residual risk ภายในอำนาจที่กำหนด หาก risk เกิน tolerance ต้องยกระดับไปยังผู้มีอำนาจสูงกว่า

การควบรวมกิจการ การแยกธุรกิจ และการจ้าง third party เป็นเหตุการณ์ governance ที่ต้องวิเคราะห์เสมอ ควรตรวจ asset ownership, inherited risk, data transfer, identity lifecycle, contractual obligations, incident notification, exit plan และการลบหรือส่งคืนข้อมูล ไม่ควรรอให้เชื่อมระบบเสร็จแล้วจึงประเมิน security

3.2 Risk Management Lifecycle

ชื่อขั้นตอนแตกต่างกันตาม framework แต่ lifecycle ที่ใช้ตอบโจทย์ได้ทั่วไปมีดังนี้

ภาพนี้เน้นว่า governance กำหนดกรอบการตัดสินใจ และผลจากการติดตามต้องย้อนกลับไปปรับบริบทเพื่อเริ่มการประเมินรอบใหม่

flowchart TD gov["Governance inputs: business objectives, obligations, appetite, tolerance และ authority"] context["1. กำหนดบริบท: scope, stakeholders, criteria และวิธีประเมิน"] identify["2. ระบุ assets, threats, vulnerabilities, dependencies และ existing controls"] analyze["3. วิเคราะห์ likelihood และ impact"] evaluate["4. เทียบ risk กับ criteria, appetite และ tolerance"] response["5. เลือก risk response โดยผู้มีอำนาจที่เหมาะสม"] implement["6. นำ controls และ treatment plan ไปใช้"] residual["ประเมิน residual risk และปรับ risk register"] monitor["7. ติดตาม evidence, KRI, incidents, exceptions และการเปลี่ยนแปลง"] gov --> context gov --> evaluate gov --> response context --> identify identify --> analyze analyze --> evaluate evaluate --> response response --> implement implement --> residual residual --> monitor monitor --> gov

ขั้นที่ 1 กำหนดบริบทและเตรียมการ

ระบุ business objectives, scope, stakeholders, assumptions, legal obligations, risk criteria, risk appetite, วิธีให้คะแนน และผู้มีอำนาจตัดสินใจ ถ้าไม่กำหนดบริบท ทีมต่าง ๆ อาจให้คะแนน “สูง” ด้วยเกณฑ์คนละชุดและเปรียบเทียบกันไม่ได้

ขั้นที่ 2 ระบุ risk

ระบุ assets, business processes, data flows, dependencies, threat sources, threat events, vulnerabilities และ existing controls การเขียน risk statement ที่ดีควรบอกเหตุ สถานการณ์ และผลกระทบ เช่น “ผู้ให้บริการ identity รายหลักหยุดทำงาน ทำให้พนักงานเข้าสู่ระบบสำคัญไม่ได้และกระทบการให้บริการลูกค้า” ดีกว่าเขียนเพียง “cloud risk”

แหล่งข้อมูลอาจมาจาก asset inventory, architecture review, vulnerability assessment, incident history, threat intelligence, BIA, audit finding, supplier assessment และ workshop กับเจ้าของกระบวนการ

ขั้นที่ 3 วิเคราะห์ risk

ประเมิน likelihood และ impact โดยคำนึงถึง existing controls การวิเคราะห์มีสองแนวหลัก

• Qualitative analysis ใช้ระดับเช่น Low, Medium, High หรือคะแนนตามเกณฑ์ เหมาะเมื่อข้อมูลตัวเลขไม่เพียงพอ สื่อสารง่าย แต่ต้องกำหนดคำอธิบายแต่ละระดับเพื่อลดอคติ
• Quantitative analysis ใช้จำนวนเงิน ความถี่ หรือ distribution เพื่อสนับสนุนการตัดสินใจ เหมาะเมื่อมีข้อมูลและสมมติฐานที่น่าเชื่อถือ แต่ผลลัพธ์ไม่แม่นกว่าคุณภาพของข้อมูลนำเข้า

สูตรแบบคลาสสิกที่ข้อสอบมักใช้คือ

Single Loss Expectancy (SLE) = Asset Value (AV) × Exposure Factor (EF)
Annualized Loss Expectancy (ALE) = SLE × Annualized Rate of Occurrence (ARO)

ถ้า server และผลกระทบทางธุรกิจมี Asset Value 2,000,000 บาท เหตุการณ์หนึ่งคาดว่าจะสร้างความเสียหาย 25% จะได้ SLE 500,000 บาท หากคาดว่าเกิดเฉลี่ยทุก 5 ปี ARO เท่ากับ 0.2 และ ALE เท่ากับ 100,000 บาทต่อปี ตัวเลขนี้เป็นค่าคาดหมายเพื่อเปรียบเทียบทางเลือก ไม่ใช่การรับประกันว่าปีหน้าจะเสียหายเท่านั้น

เมื่อประเมิน control เชิงปริมาณ อาจเปรียบเทียบ ALE ก่อนและหลัง control กับ Annual Cost of Safeguard อย่างไรก็ดี การตัดสินใจต้องคำนึงถึงชีวิต ความปลอดภัย กฎหมาย ชื่อเสียง และความเสี่ยงรุนแรงที่เกิดไม่บ่อยด้วย ไม่ควรใช้ต้นทุนทางการเงินเพียงมิติเดียว

ขั้นที่ 4 ประเมินและจัดลำดับ

เปรียบเทียบผลวิเคราะห์กับ risk criteria, appetite และ tolerance เพื่อจัดลำดับ treatment ต้องพิจารณาความสัมพันธ์ระหว่าง risk ด้วย เพราะ control ที่ลด risk หนึ่งอาจเพิ่มอีก risk เช่น ปิด remote access ทั้งหมดอาจลดการโจมตีจากภายนอก แต่ทำให้ BCP ทำงานไม่ได้

• Risk appetite คือชนิดและปริมาณ risk โดยรวมที่องค์กรเต็มใจรับเพื่อบรรลุวัตถุประสงค์
• Risk tolerance คือขอบเขตการเบี่ยงเบนที่ยอมรับได้สำหรับวัตถุประสงค์หรือ risk category ที่เฉพาะขึ้น
• Risk capacity คือระดับสูงสุดที่องค์กรสามารถรับได้โดยไม่กระทบความอยู่รอดหรือข้อจำกัดสำคัญ

ขั้นที่ 5 เลือก risk response

ทางเลือกพื้นฐานมีสี่แบบ

1. Avoid หลีกเลี่ยงด้วยการหยุดกิจกรรมหรือเปลี่ยนวิธีดำเนินธุรกิจที่ก่อ risk
2. Mitigate หรือ reduce ใช้ control เพื่อลด likelihood หรือ impact
3. Transfer หรือ share โอนหรือแบ่งผลทางการเงินและหน้าที่บางส่วนผ่านประกันหรือสัญญา แต่ accountability และผลกระทบบางชนิด เช่น ชื่อเสียง ไม่ได้ถูกโอนทั้งหมด
4. Accept ยอมรับอย่างมีข้อมูล โดยผู้มีอำนาจรับทราบเหตุผล ระยะเวลา เงื่อนไข และ residual risk

การเพิกเฉยไม่ใช่ risk acceptance การยอมรับต้องบันทึกและทบทวนเมื่อบริบทเปลี่ยน ความเสี่ยงที่เกิน authority ของผู้จัดการต้องถูก escalate

ขั้นที่ 6 เลือกและนำ control ไปใช้

เลือก control โดยพิจารณาประสิทธิผล ต้นทุน ผลกระทบต่อธุรกิจ ข้อบังคับ ความสามารถในการปฏิบัติ และ risk ที่ control สร้างขึ้นเอง กำหนด control owner, implementation plan, due date และวิธีทดสอบ การมี control ในเอกสารแต่ไม่ทำงานจริงไม่ลด risk

Control แบ่งได้หลายมิติ

มิติ	ประเภท	ตัวอย่าง
ลักษณะ	Administrative, Technical, Physical	policy, MFA, รั้ว
หน้าที่	Preventive	least privilege, security guard
หน้าที่	Detective	log monitoring, intrusion detection
หน้าที่	Corrective	patch, reconfiguration หลังพบข้อผิดพลาด
หน้าที่	Deterrent	warning banner, ป้ายเตือน
หน้าที่	Recovery	restore from backup, alternate site
หน้าที่	Compensating	control ทดแทนเมื่อใช้ control หลักไม่ได้ แต่ให้ผลลด risk ใกล้เคียงตามที่ยอมรับได้
หน้าที่	Directive	policy, standard, mandatory instruction

Control หนึ่งตัวทำได้หลายหน้าที่ เช่น กล้องวงจรปิดอาจเป็นทั้ง deterrent และ detective การจัดประเภทขึ้นกับวัตถุประสงค์ในสถานการณ์

ขั้นที่ 7 ติดตาม รายงาน และปรับปรุง

ติดตาม control effectiveness, residual risk, change indicators, incidents, exceptions และ treatment progress ใช้ Key Risk Indicator (KRI) เพื่อเตือนการเปลี่ยนระดับ risk และใช้ Key Performance Indicator (KPI) เพื่อวัดผลการทำงานของกระบวนการ รายงานต้องปรับตามผู้รับ ผู้บริหารต้องเห็นแนวโน้ม ผลกระทบ decision required และ risk ที่เกิน tolerance มากกว่ารายละเอียด log

Risk register ควรมีอย่างน้อย risk statement, owner, affected objective, likelihood, impact, rating, existing controls, response, action owner, target date, residual risk, status และ review date

ตัวอย่างรายการย่อ: “Identity provider หยุดทำงาน” มี business owner เป็นเจ้าของ risk, impact สูง, likelihood ปานกลาง Existing control คือ local emergency accounts ส่วน treatment คือเพิ่ม second authentication path และทดสอบ failover รายไตรมาส Residual risk ต้องถูกประเมินใหม่หลังทดสอบ ไม่ใช่ลดคะแนนเพราะซื้อผลิตภัณฑ์แล้ว

3.3 Legal, Regulatory และ Compliance

ผู้เชี่ยวชาญ CISSP ต้องรู้กระบวนการจัดการข้อกฎหมาย แต่ไม่ควรทำหน้าที่แทน legal counsel เมื่อจำเป็นต้องตีความกฎหมายเฉพาะกรณี แนวทางที่ปลอดภัยคือระบุ jurisdiction และ obligations ที่เกี่ยวข้อง ขอคำแนะนำจากผู้เชี่ยวชาญ บันทึกการตัดสินใจ และแปลงคำแนะนำเป็น control ที่ตรวจสอบได้

แหล่ง obligations

• Law และ regulation เป็นข้อบังคับจากรัฐหรือหน่วยงานกำกับ ผลของการฝ่าฝืนอาจรวมถึงคำสั่งแก้ไข โทษทางแพ่ง อาญา หรือทางปกครองตามเขตอำนาจ
• Contract ผูกคู่สัญญาตามข้อตกลง เช่น confidentiality, service level, breach notification, audit right, data location และ secure deletion
• Industry requirement เช่น PCI DSS เป็นมาตรฐานอุตสาหกรรมและข้อกำหนดในระบบบัตร ไม่ควรเหมารวมว่าเป็นกฎหมาย
• Internal policy ผูกพนักงานและผู้เกี่ยวข้องตาม governance ขององค์กร แม้ไม่ใช่กฎหมายภายนอกก็อาจมีผลทางวินัยหรือสัญญา

Jurisdiction และ transborder data flow

กิจกรรมหนึ่งอาจเกี่ยวข้องหลายเขตอำนาจจากที่ตั้งองค์กร ที่ตั้ง data subject สถานที่ประมวลผล ที่ตั้ง cloud region หรือเงื่อนไขสัญญา ก่อนส่งข้อมูลข้ามประเทศต้องตรวจ lawful basis, transfer mechanism, localization requirement, government access risk, retention และหน้าที่ของ controller/processor ตามกฎหมายที่ใช้บังคับ การเลือก cloud region ไม่ได้แก้ทุกประเด็น เพราะ support, backup, telemetry หรือ subcontractor อาจอยู่ประเทศอื่น

Privacy principles

กฎหมายแต่ละแห่งใช้ถ้อยคำต่างกัน แต่หลักที่พบได้บ่อยและใช้เป็นแนวคิดในการออกแบบ ได้แก่ lawfulness และ transparency, purpose limitation, data minimization, accuracy, storage limitation, security safeguards, accountability และการรองรับสิทธิของ data subject ควรกำหนด data inventory, purpose, legal basis, retention, access, sharing และ deletion ตั้งแต่การออกแบบ

อย่าสับสน data owner ใน governance ภายในกับ data controller ตามกฎหมาย privacy โดยทั่วไป controller เป็นนิติบุคคลหรือฝ่ายที่กำหนดวัตถุประสงค์และวิธีการหลักของ processing ส่วน processor ประมวลผลแทน controller ตามข้อตกลง บทบาทจริงสำคัญกว่าป้ายชื่อในสัญญา

Intellectual Property และ licensing

• Copyright คุ้มครองรูปแบบการแสดงออกของงาน เช่น source code เอกสาร และสื่อ ไม่ได้คุ้มครองแนวคิดทั่วไปเพียงอย่างเดียว
• Patent คุ้มครองสิทธิในสิ่งประดิษฐ์ตามเงื่อนไขและระยะเวลาของกฎหมายที่เกี่ยวข้อง
• Trademark คุ้มครองเครื่องหมายที่แยกแยะแหล่งที่มาของสินค้าและบริการ
• Trade secret คุ้มครองข้อมูลเชิงพาณิชย์ที่มีคุณค่าเพราะเป็นความลับและเจ้าของใช้มาตรการรักษาความลับที่สมเหตุสมผล
• Software license กำหนดสิทธิและข้อจำกัดการใช้ คัดลอก ดัดแปลง หรือแจกจ่ายซอฟต์แวร์ การมีไฟล์ติดตั้งไม่ได้แปลว่ามีสิทธิใช้งานทุกแบบ

Investigation และ evidence

ประเภทการสอบสวนอาจเป็น criminal, civil, administrative, regulatory หรือ internal/industry แต่ละประเภทมี authority, procedure, burden of proof และกฎหลักฐานต่างกัน ทีม security ต้องประสาน legal, HR, privacy และ law enforcement ตามกรณี ก่อนเก็บหรือค้นข้อมูลพนักงานต้องมีอำนาจและขอบเขตที่เหมาะสม

หลักปฏิบัติสำคัญคือรักษาความครบถ้วนของ evidence, จดบันทึกผู้ครอบครองและการส่งต่อผ่าน chain of custody, ใช้วิธีเก็บที่ทำซ้ำและอธิบายได้, รักษาเวลาให้สอดคล้อง, จำกัดการเข้าถึง และไม่ทำลายข้อมูลที่อยู่ภายใต้ legal hold รายละเอียด digital forensics อยู่ใน Domain 7

Compliance lifecycle

1. ระบุ applicable requirements และผู้รับผิดชอบ
2. แปลง requirements เป็น control objectives
3. map control เดียวกับหลาย requirements เมื่อเหมาะสม
4. นำ control ไปใช้และเก็บ evidence
5. ประเมิน design และ operating effectiveness
6. บันทึก gap, exception และ remediation
7. รายงานต่อผู้มีอำนาจและติดตามการเปลี่ยนแปลง

3.4 Policies, Standards, Baselines, Procedures และ Guidelines

ลำดับเอกสารที่ข้อสอบชอบนำมาสลับกันมีดังนี้

เอกสาร	หน้าที่	ระดับการบังคับ	ตัวอย่าง
Policy	กำหนดเจตนา หลักการ และข้อกำหนดระดับสูง	บังคับ	“ข้อมูล Restricted ต้องได้รับการคุ้มครองตามความเสี่ยงและกฎหมาย”
Standard	กำหนดข้อกำหนดเฉพาะที่ต้องทำให้สม่ำเสมอ	บังคับ	“บัญชี privileged ต้องใช้ phishing-resistant MFA”
Baseline	กำหนดระดับขั้นต่ำหรือ secure configuration ที่อนุมัติ	บังคับตาม scope	ค่า hardening ขั้นต่ำของ server
Procedure	อธิบายขั้นตอนว่าใครทำอะไร เมื่อใด และอย่างไร	บังคับเมื่อกระบวนการกำหนด	ขั้นตอน revoke access เมื่อพนักงานออก
Guideline	ให้คำแนะนำและทางเลือกที่ควรพิจารณา	โดยทั่วไปไม่บังคับ	แนวทางตั้ง passphrase ที่จำง่าย

Policy ที่ดีควรสั้นพอให้คงเสถียรเมื่อเทคโนโลยีเปลี่ยน ส่วนรายละเอียดที่เปลี่ยนบ่อยควรอยู่ใน standard หรือ procedure เอกสารทุกระดับต้องสอดคล้องกัน ถ้า policy กำหนด least privilege แต่ procedure สร้างบัญชีแบบ administrator เป็นค่าเริ่มต้น กระบวนการยังไม่ compliant

Policy lifecycle ประกอบด้วยการระบุ requirement, ร่างโดย stakeholders, legal/compliance review, approval โดย authority ที่เหมาะสม, communication และ acknowledgement, implementation, enforcement, exception management, periodic review และ retirement เมื่อไม่ใช้แล้ว

ข้อยกเว้นต้องไม่กลายเป็นทางลัด ควรระบุ business justification, scope, risk assessment, compensating controls, approver, owner, expiration date และ review date เมื่อหมดอายุต้องแก้ไข ต่ออายุด้วยการประเมินใหม่ หรือยุติข้อยกเว้น

นโยบายที่พบบ่อย ได้แก่ acceptable use, access control, data classification and handling, encryption, logging, incident response, business continuity, secure development, change management, third-party security และ personnel security การลงนามรับทราบช่วยสร้างหลักฐาน แต่ยังต้องอบรมและบังคับใช้อย่างสม่ำเสมอ

3.5 BCP และ DRP Overview

Business Continuity Planning (BCP) มุ่งให้องค์กรดำเนิน critical business functions ต่อหรือกลับมาได้ภายในระดับที่ยอมรับเมื่อเกิด disruption ส่วน Disaster Recovery Plan (DRP) มุ่งกู้คืนระบบ IT, infrastructure, applications และ data ที่สนับสนุนธุรกิจ DRP จึงเป็นส่วนสนับสนุนของ business continuity ไม่ใช่สิ่งเดียวกัน

ผู้บริหารต้องสนับสนุนและเป็นเจ้าของ BCP เพราะลำดับการฟื้นฟูเป็นการตัดสินใจเชิงธุรกิจ ฝ่าย IT ให้ข้อมูล dependency และความสามารถกู้คืน แต่ไม่ควรกำหนดลำดับความสำคัญแทน business process owner

Business Impact Analysis

Business Impact Analysis (BIA) ระบุ critical processes, ผลกระทบจากการหยุดชะงัก, dependency และเป้าหมายการฟื้นฟู ขั้นตอนโดยทั่วไปคือ

1. กำหนด scope และรวบรวมกระบวนการ ผลิตภัณฑ์ และบริการ
2. สัมภาษณ์ process owner เพื่อระบุผลกระทบที่เพิ่มตามเวลา
3. ระบุ dependency ด้านคน สถานที่ เทคโนโลยี ข้อมูล supplier และ utilities
4. กำหนดลำดับและ recovery objectives
5. ตรวจสอบความสัมพันธ์ระหว่างกระบวนการและขอ management approval

ตัวชี้วัดสำคัญ ได้แก่

• Maximum Tolerable Downtime (MTD) หรือ Maximum Allowable Downtime คือระยะหยุดชะงักสูงสุดที่ธุรกิจยอมรับได้ก่อนผลกระทบไม่อาจยอมรับ
• Recovery Time Objective (RTO) คือเป้าหมายเวลาที่ต้องกู้บริการหรือระบบกลับมา RTO ควรสั้นกว่า MTD และต้องสอดคล้องกับความสามารถจริง
• Recovery Point Objective (RPO) คือจุดย้อนหลังของข้อมูลที่ต้องกู้คืนได้ สื่อถึงปริมาณ data loss ตามเวลาที่ยอมรับได้ เช่น RPO 4 ชั่วโมงต้องมีวิธีทำให้สูญข้อมูลไม่เกินช่วงเป้าหมายนั้นภายใต้สถานการณ์ที่ออกแบบไว้
• Work Recovery Time (WRT) คือเวลาหลังระบบกลับมาจนงาน กระบวนการ ข้อมูลค้าง และการตรวจสอบพร้อมให้ธุรกิจทำงานได้ตามระดับเป้าหมาย โดยทั่วไป RTO บวก WRT ต้องไม่เกิน MTD

ภาพนี้แสดงว่า BIA สร้าง business requirements ที่กำกับทั้ง BCP และ DRP โดย recovery evidence จะย้อนกลับมายืนยันหรือปรับ BIA

flowchart TD bia["BIA: critical processes, ผลกระทบตามเวลา และ dependencies"] approval["Management approval: recovery priorities และ objectives"] mtd["MTD: ระยะหยุดชะงักสูงสุดที่ธุรกิจยอมรับ"] rto["RTO: เป้าหมายเวลาคืน service หรือ system"] wrt["WRT: เวลาทำให้งานพร้อมหลัง system กลับมา"] rpo["RPO: จุดข้อมูลย้อนหลังที่ต้องกู้คืนได้"] limit["ข้อจำกัดด้านเวลา: RTO + WRT ต้องไม่เกิน MTD"] bcp["BCP: คน กระบวนการ สถานที่ supplier และ manual workaround"] drp["DRP: IT infrastructure, applications และ data recovery"] continuity["Critical business functions ดำเนินต่อหรือฟื้นกลับ"] exercise["Exercise และ recovery evidence"] bia --> approval approval --> mtd approval --> rto approval --> wrt approval --> rpo mtd --> limit rto --> limit wrt --> limit approval --> bcp limit --> bcp rto --> drp rpo --> drp bcp --> continuity drp --> continuity continuity --> exercise exercise --> bia

ตัวอย่าง: ระบบรับคำสั่งซื้อมี MTD 12 ชั่วโมง ธุรกิจกำหนด RTO 4 ชั่วโมงและ WRT 2 ชั่วโมง จึงมี buffer ก่อนถึง MTD อีก 6 ชั่วโมง ถ้า RPO เท่ากับ 15 นาที การ backup วันละครั้งไม่ตอบ requirement แม้กู้ server ได้ภายใน 4 ชั่วโมง ต้องออกแบบ replication, journal หรือ backup frequency ให้รองรับ RPO และทดสอบการ restore

หลัง BIA องค์กรเลือก continuity strategy เช่น alternate work location, manual workaround, redundant service, alternate supplier, reciprocal arrangement, hot/warm/cold site หรือ cloud recovery ทางเลือกต้องประเมิน cost, recovery capability, geographic risk, capacity, security, data consistency และ dependency ที่ซ่อนอยู่

แผนควรมี activation criteria, authority, call tree และช่องทางสำรอง, roles, safety procedures, contact list, dependency, recovery sequence, manual workaround, return-to-normal และการเก็บบันทึก เอกสารต้องเข้าถึงได้เมื่อระบบหลักล่มและต้องป้องกันข้อมูลสำคัญในแผน

การทดสอบอาจเริ่มจาก checklist/read-through และ tabletop แล้วเพิ่ม walkthrough, simulation, parallel processing หรือ full interruption ตามความเสี่ยง การทดสอบ full interruption ให้หลักฐานมากแต่มี operational risk สูง จึงต้องได้รับอนุมัติและวาง safety control การทดสอบต้องสร้าง after-action report, owner และ remediation ไม่ใช่จบเมื่อการประชุมสิ้นสุด รายละเอียดการดำเนิน DR และชนิดการทดสอบอยู่ใน Domain 7

3.6 Professional Ethics

ISC2 Code of Ethics มี canons บังคับสี่ข้อซึ่งสรุปสาระได้ว่า

1. คุ้มครองสังคม ประโยชน์ส่วนรวม ความไว้วางใจของสาธารณะ และโครงสร้างพื้นฐาน
2. ปฏิบัติอย่างมีเกียรติ ซื่อสัตย์ ยุติธรรม รับผิดชอบ และชอบด้วยกฎหมาย
3. ให้บริการแก่ principals ด้วยความขยันรอบคอบและความสามารถ
4. ส่งเสริมและคุ้มครองวิชาชีพ

Principal อาจเป็นนายจ้าง ลูกค้า หรือผู้ว่าจ้างที่ผู้เชี่ยวชาญมีหน้าที่ให้บริการ แต่หน้าที่ต่อ principal ไม่อยู่เหนือความปลอดภัยของสังคมและกฎหมาย หากผู้บริหารขอให้ปกปิด breach ที่ต้องรายงาน ผู้เชี่ยวชาญควรรักษาหลักฐาน ตรวจข้อเท็จจริง ใช้ช่องทาง escalation และขอคำแนะนำทางกฎหมาย ไม่ควรทำตามคำสั่งที่ผิดกฎหมายหรือทำลายหลักฐาน

ข้อสอบ ethics มักให้ตัวเลือกที่ทุกข้อดูมีเหตุผล ให้จัดลำดับโดยเริ่มจากความปลอดภัยของชีวิต สังคม และ common good แล้วพิจารณากฎหมาย หน้าที่ต่อ principal และวิชาชีพตามบริบท ผู้เชี่ยวชาญต้องทำงานภายใน competence ของตน เปิดเผย conflict of interest รักษาความลับ และไม่กล่าวอ้างความสามารถหรือผลการตรวจเกินจริง

3.7 Security Awareness, Training และ Education

สามคำนี้มีเป้าหมายต่างกัน

• Awareness เปลี่ยนความใส่ใจและพฤติกรรมในวงกว้าง เนื้อหาสั้นและย้ำซ้ำ เช่น วิธีรายงาน phishing หรือเตือนเรื่อง tailgating
• Training สร้างทักษะสำหรับงานหรือบทบาท เช่น ฝึก help desk ตรวจสอบตัวตนก่อน reset account หรือฝึก developer ทำ threat modeling
• Education สร้างความรู้เชิงลึกและความเข้าใจหลักการระยะยาว เช่น หลักสูตร security architecture หรือ digital forensics

โครงการที่มีประสิทธิผลเริ่มจาก sponsorship และ needs analysis แบ่ง audience ตาม risk และบทบาท จัดเนื้อหาในเวลาที่เกี่ยวข้องกับงาน มีช่องทางรายงานที่ง่าย เสริมแรงอย่างต่อเนื่อง และวัดพฤติกรรม ไม่ควรใช้ annual video ชุดเดียวกับทุกคนแล้วถือว่าเสร็จ

Lifecycle ตัวอย่างมีดังนี้

1. วิเคราะห์พฤติกรรมเสี่ยง เหตุการณ์จริง obligations และกลุ่มเป้าหมาย
2. กำหนด measurable objectives เช่น เพิ่มสัดส่วนการรายงานข้อความน่าสงสัยอย่างถูกต้อง
3. ออกแบบ baseline content สำหรับทุกคนและ role-based training สำหรับกลุ่มเสี่ยง
4. ส่งมอบผ่านหลายวิธี เช่น onboarding, microlearning, workshop, simulation และ security champions
5. วัด completion, knowledge, behavior, incident trend และ feedback
6. ปรับเนื้อหาตามผลวัด เหตุการณ์ และเทคโนโลยีใหม่

Metric ต้องตีความอย่างระมัดระวัง completion rate แสดงว่าผู้เรียนผ่านกิจกรรม ไม่ได้พิสูจน์ว่าพฤติกรรมเปลี่ยน phishing click rate เพียงค่าเดียวอาจถูกบิดเบือนด้วยความยากของแบบทดสอบ ควรดู report rate, เวลารายงาน, repeated susceptibility, help-desk verification quality และ incident trend ร่วมกัน การจำลองควรมีวัตถุประสงค์การเรียนรู้ ไม่ทำให้อับอาย และมีขั้นตอนช่วยผู้ที่ต้องปรับปรุง

Awareness program ต้องครอบคลุมพนักงาน ผู้บริหาร contractor และบุคคลที่เข้าถึงสินทรัพย์ตามความเสี่ยง เนื้อหาควรรวม acceptable use, data handling, password/MFA behavior, social engineering, physical security, incident reporting, privacy, remote work และหน้าที่เมื่อเปลี่ยนบทบาทหรือออกจากองค์กร

3.8 Personnel Security และ Supply Chain Risk

Personnel lifecycle เริ่มก่อนจ้างและต่อเนื่องจนหลังพ้นสภาพตาม obligations ที่ยังมีอยู่ Control อาจรวม background screening ที่ชอบด้วยกฎหมาย, job description, confidentiality agreement, conflict-of-interest disclosure, least privilege, separation of duties, mandatory vacation สำหรับบางบทบาท, performance/disciplinary process และ termination checklist

เมื่อย้ายตำแหน่งต้องทบทวนสิทธิเดิม ไม่ใช่เพิ่มสิทธิใหม่ทับไปเรื่อย ๆ เมื่อพ้นสภาพควรประสาน HR, manager, IAM, physical security และ asset management เพื่อ disable access ตามเวลาที่เหมาะสม คืนทรัพย์สิน รักษาหลักฐาน และย้ำ obligations เรื่องความลับ กรณี involuntary termination อาจต้องดำเนินการพร้อมกันเพื่อลด insider risk โดยยังคำนึงถึงความปลอดภัยและกฎหมายแรงงาน

Supply Chain Risk Management มองความเสี่ยงตลอดเส้นทางของ product และ service ตั้งแต่การออก requirement, due diligence, contracting, delivery, operation, monitoring จน exit ความเสี่ยงรวมถึง counterfeit component, malicious modification, vulnerable dependency, concentration risk, opaque subcontractor, service outage และข้อมูลถูกเก็บหรือลบไม่ตรงเงื่อนไข

Control ที่สำคัญคือกำหนด minimum security requirements ตาม criticality, ตรวจ supplier ก่อนและระหว่างสัญญา, กำหนด incident notification และ cooperation, สิทธิรับ assurance หรือ audit, vulnerability and patch obligations, software/component transparency เมื่อเหมาะสม, business continuity, data return/deletion และ exit assistance การรับรายงาน certification จาก supplier เป็น evidence หนึ่งชิ้น ไม่ใช่การโอน accountability ทั้งหมด

4. กรอบมาตรฐานที่เกี่ยวข้อง

Framework ช่วยจัดระบบและสร้างภาษาร่วม แต่ไม่มี framework ใดแทนการวิเคราะห์บริบท กฎหมาย และ risk ขององค์กร การเลือกใช้ควรเริ่มจากวัตถุประสงค์และ obligations ไม่ใช่เลือกจากชื่อที่คุ้นเคย

4.1 NIST

NIST Cybersecurity Framework (CSF) 2.0 จัด cybersecurity outcomes เป็นหก Functions ที่ทำงานต่อเนื่อง ได้แก่ Govern, Identify, Protect, Detect, Respond และ Recover การเพิ่ม Govern ทำให้เห็นชัดว่า strategy, policy, roles, oversight และ supply chain risk เป็นฐานของอีกห้า Functions CSF ใช้ Current Profile และ Target Profile เพื่อเปรียบเทียบสภาพปัจจุบันกับผลลัพธ์เป้าหมาย และใช้ Tiers เพื่ออธิบายลักษณะการจัดการ risk โดยไม่ควรตีความ Tier เป็นคะแนนรับรองความปลอดภัยอย่างง่าย ดูเอกสารหลักที่ NIST CSF 2.0 Resource Center

NIST Risk Management Framework (RMF) ตาม NIST SP 800-37 Rev. 2 มีขั้น Prepare, Categorize, Select, Implement, Assess, Authorize และ Monitor ใช้เชื่อม security/privacy risk เข้ากับ system development life cycle การ Authorize เป็นการตัดสินใจรับ risk โดย senior official หลังดูหลักฐาน ไม่ใช่ใบรับรองว่าระบบไม่มี risk ดูภาพรวมที่ NIST RMF

เอกสารที่เกี่ยวข้องโดยตรง ได้แก่ NIST SP 800-30 Rev. 1 สำหรับ risk assessment และ NIST SP 800-34 Rev. 1 สำหรับ information system contingency planning แนวทาง NIST มีต้นกำเนิดจากบริบทหน่วยงานสหรัฐฯ แต่หลายองค์กรนำหลักไปปรับใช้ได้โดยต้องพิจารณาบริบทของตน

4.2 ISO/IEC 27001

ISO/IEC 27001:2022 กำหนด requirements สำหรับ Information Security Management System (ISMS) เพื่อให้องค์กร establish, implement, maintain และ continually improve ระบบบริหารความมั่นคงปลอดภัยสารสนเทศ มาตรฐานใช้แนวคิด risk-based และครอบคลุม context, leadership, planning, support, operation, performance evaluation และ improvement

องค์กรต้องประเมิน information security risk, วางแผน treatment, กำหนด controls ที่จำเป็น และจัดทำ Statement of Applicability เพื่ออธิบาย control ที่เลือกและเหตุผลที่เกี่ยวข้อง Annex A เป็น reference set สำหรับ control ไม่ใช่ checklist ที่ทุกองค์กรต้องนำทุก control ไปใช้เหมือนกัน การ certification หมายถึง ISMS ได้รับการตรวจเทียบ requirements ภายใน scope ที่กำหนด ไม่ได้หมายความว่าองค์กรจะไม่เกิด incident ดูภาพรวมทางการที่ ISO/IEC 27001

4.3 COBIT

COBIT 2019 ของ ISACA เป็น framework สำหรับ governance และ management of enterprise information and technology จุดที่สำคัญต่อ Domain 1 คือการแยก governance objectives ออกจาก management objectives และการเชื่อม stakeholder needs ไปยัง enterprise goals และ I&T-related goals

กลุ่ม governance ใช้แนวคิด Evaluate, Direct and Monitor (EDM) ส่วน management objectives จัดในกลุ่ม Align, Plan and Organize (APO), Build, Acquire and Implement (BAI), Deliver, Service and Support (DSS), Monitor, Evaluate and Assess (MEA) COBIT ช่วยกำหนด decision rights, accountability, objectives และ performance แต่ต้องปรับ governance system ตามบริบท ไม่ใช่คัดลอกทุก process ดูข้อมูลทางการจาก ISACA COBIT resources

4.4 ITIL

ITIL 4 เป็นกรอบ service management ที่มุ่ง co-creation of value ผ่าน Service Value System ซึ่งประกอบด้วย guiding principles, governance, service value chain, practices และ continual improvement ความเกี่ยวข้องกับ Domain 1 คือการทำให้ information security รองรับ utility, warranty, service level, change, incident, continuity และ supplier management ในฐานะส่วนหนึ่งของ service lifecycle

ITIL ไม่ใช่ security control framework และไม่แทน ISO/IEC 27001 หรือ risk assessment แต่ช่วยฝัง security requirement เข้าในวิธีออกแบบ ส่งมอบ สนับสนุน และปรับปรุงบริการ เช่น service owner ต้องเข้าใจ security requirements และยอมรับได้ว่าการ change เร่งด่วนอาจสร้าง risk ใด ดูภาพรวมจาก PeopleCert ITIL

4.5 เลือกใช้ร่วมกันอย่างไร

คำถามขององค์กร	กรอบที่ช่วยตอบ
ต้องการ outcomes และภาษากลางสำหรับ cyber risk ทั้งองค์กร	NIST CSF
ต้องการ lifecycle เลือก ประเมิน อนุมัติ และติดตาม controls ของระบบ	NIST RMF
ต้องการ ISMS ที่มี requirements และสามารถตรวจรับรองตาม scope	ISO/IEC 27001
ต้องการ governance และ management objectives สำหรับ enterprise I&T	COBIT
ต้องการฝัง security ในการบริหาร product และ service	ITIL

องค์กรหนึ่งอาจใช้ ISO/IEC 27001 เป็น management system, NIST CSF เป็นโครงสื่อสาร outcomes, COBIT เป็น governance lens และ ITIL เป็น operating model ด้าน service โดย map controls เพื่อลดงานซ้ำ การใช้หลาย framework ควรมี common control library และ owner ที่ชัดเจน

5. คำศัพท์สำคัญพร้อมนิยาม

คำศัพท์	นิยามสั้น
Asset	สิ่งที่มีคุณค่าต่อองค์กรและต้องได้รับการคุ้มครอง
Threat	แหล่งหรือเหตุการณ์ที่อาจก่อผลเสีย
Vulnerability	จุดอ่อนหรือสภาวะที่ threat อาจใช้ประโยชน์
Risk	ผลของความไม่แน่นอนต่อวัตถุประสงค์ โดยพิจารณา likelihood และ impact
Inherent risk	Risk ก่อนพิจารณาผลของ controls ที่ใช้จัดการ
Residual risk	Risk ที่เหลือหลังใช้ controls
Secondary risk	Risk ใหม่ที่เกิดจากการเลือก risk response
Risk appetite	ปริมาณและชนิด risk โดยรวมที่องค์กรเต็มใจรับเพื่อบรรลุเป้าหมาย
Risk tolerance	ขอบเขตการเบี่ยงเบนจากระดับเป้าหมายที่ยอมรับได้
Risk capacity	ระดับ risk สูงสุดที่องค์กรสามารถรับได้
Risk owner	ผู้มี accountability ในการตัดสินใจและติดตาม risk รายการหนึ่ง
Risk register	บันทึก risk, owner, rating, controls, treatment, status และการทบทวน
Control	มาตรการที่ปรับเปลี่ยน likelihood หรือ impact ของ risk
Compensating control	Control ทดแทนเมื่อใช้ control หลักไม่ได้และลด risk ได้ในระดับที่ยอมรับ
Control objective	ผลลัพธ์ด้านการควบคุมที่ต้องการ ไม่ใช่ผลิตภัณฑ์หรือวิธีเฉพาะ
Governance	การประเมิน กำหนดทิศทาง และกำกับติดตามเพื่อให้บรรลุวัตถุประสงค์
Management	การวางแผน สร้าง ดำเนินงาน และติดตามตามทิศทาง governance
Accountability	ภาวะที่บุคคลหรือบทบาทต้องตอบต่อผลการตัดสินใจและไม่อาจโอนออกทั้งหมด
Responsibility	หน้าที่ในการดำเนินงานที่สามารถมอบหมายได้
Due care	การใช้ความระมัดระวังและมาตรการที่สมเหตุสมผล
Due diligence	การตรวจสอบอย่างต่อเนื่องว่าการตัดสินใจและมาตรการเหมาะสมและทำงานจริง
Compliance	การปฏิบัติตามกฎหมาย กฎระเบียบ สัญญา มาตรฐาน และนโยบายที่ใช้บังคับ
Policy	ข้อกำหนดระดับสูงที่สะท้อนเจตนาของผู้บริหาร
Standard	ข้อกำหนดเฉพาะที่บังคับใช้เพื่อความสม่ำเสมอ
Baseline	ระดับขั้นต่ำหรือ configuration ขั้นต่ำที่อนุมัติ
Procedure	ขั้นตอนปฏิบัติที่ระบุวิธีและลำดับงาน
Guideline	คำแนะนำที่โดยทั่วไปเปิดให้ใช้ดุลยพินิจ
Exception	การอนุมัติให้เบี่ยงเบนจาก requirement ชั่วคราวภายใต้ risk review
Data owner	ผู้กำหนด classification, access และ handling requirements ของข้อมูล
Data custodian	ผู้ดูแลข้อมูลและนำ controls ตามที่ owner กำหนดไปใช้
Data controller	ฝ่ายที่กำหนดวัตถุประสงค์และวิธีการหลักของ personal data processing ตามกฎหมายที่เกี่ยวข้อง
Data processor	ฝ่ายที่ประมวลผล personal data ในนามของ controller
BIA	การวิเคราะห์ผลกระทบจากการหยุดชะงักและ requirement การฟื้นฟู
BCP	แผนทำให้ critical business functions ดำเนินต่อหรือฟื้นกลับ
DRP	แผนกู้คืน IT systems, infrastructure และ data หลัง disruption
MTD	ระยะหยุดชะงักสูงสุดก่อนผลกระทบต่อธุรกิจไม่อาจยอมรับ
RTO	เป้าหมายเวลาที่ต้องกู้บริการหรือระบบกลับมา
RPO	จุดย้อนหลังของข้อมูลที่ต้องกู้คืนได้
WRT	เวลาหลังระบบกลับมาจนธุรกิจจัดการงานและข้อมูลพร้อมดำเนินการ
SLE	มูลค่าความเสียหายที่คาดจากเหตุการณ์หนึ่งครั้ง
ARO	อัตราความถี่คาดหมายของเหตุการณ์ต่อปี
ALE	มูลค่าความเสียหายคาดหมายต่อปี
KRI	ตัวชี้วัดที่ส่งสัญญาณการเปลี่ยนระดับ risk
KPI	ตัวชี้วัดผลการทำงานเทียบเป้าหมายของกระบวนการ
Chain of custody	บันทึกการครอบครอง ควบคุม และส่งต่อ evidence
Security awareness	กิจกรรมสร้างความใส่ใจและพฤติกรรมที่ลด risk
Security training	กิจกรรมสร้างทักษะเฉพาะงานหรือบทบาท
Security education	การเรียนรู้เชิงลึกเพื่อสร้างความเข้าใจระยะยาว

6. Exam Tips: จุดที่ข้อสอบชอบหลอก

1. คิดแบบ manager ก่อน technician ถ้าคำถามถามสิ่งที่ควรทำ “ก่อน” ให้ระบุ scope, requirement, owner และ risk ก่อนเลือก product เว้นแต่มีเหตุฉุกเฉินต่อชีวิตหรือ containment ที่ชัดเจน
2. ชีวิตและความปลอดภัยมาก่อนทรัพย์สิน ระหว่าง disaster ห้ามเลือกการกู้ระบบที่เสี่ยงต่อบุคลากร
3. Senior management เป็นเจ้าของทิศทางและ residual risk Security team วิเคราะห์และแนะนำ แต่ไม่ควรรับ risk ของธุรกิจแทนผู้มีอำนาจ
4. Accountability โอนไม่ได้ทั้งหมด งานหรือ responsibility มอบหมายได้ แต่ผู้บริหารและ owner ยังต้องตอบต่อผล
5. CIA เป็น objectives ไม่ใช่ technologies Encryption ช่วย Confidentiality เป็นหลัก แต่การจัดการ key ผิดอาจกระทบ Availability และ Integrity
6. Privacy ไม่เท่ากับ Confidentiality การป้องกันการเปิดเผยไม่ทำให้การใช้ข้อมูลชอบด้วยวัตถุประสงค์โดยอัตโนมัติ
7. Threat ไม่ใช่ vulnerability Hacker เป็น threat source, default password เป็น vulnerability, account takeover เป็น threat event หรือผลลัพธ์ตามบริบท
8. Risk transfer ไม่ได้ลบ risk Insurance ช่วยแบ่งผลทางการเงิน แต่ไม่โอนชื่อเสียง กฎหมาย หรือ accountability ทั้งหมด
9. Risk acceptance ต้องมี authority และหลักฐาน “ยังไม่ได้แก้” ไม่เท่ากับ accept
10. Residual risk อยู่หลัง controls Inherent risk อยู่ก่อนพิจารณาผล control อย่าสลับลำดับ
11. Cost-benefit ไม่ใช่เหตุผลเดียว Control ที่กฎหมายบังคับหรือคุ้มครองชีวิตอาจต้องทำแม้ ALE อย่างง่ายดูต่ำ
12. Qualitative ไม่ได้แปลว่าไม่มีหลักเกณฑ์ ต้องมีนิยาม scale และ rationale ที่สม่ำเสมอ
13. Policy ระดับสูงและบังคับ Standard กับ baseline ให้รายละเอียดบังคับ, procedure บอกวิธีทำ, guideline ให้คำแนะนำ
14. Exception ต้องหมดอายุและทบทวน Permanent exception ที่ไม่มี owner มักเป็น finding หรือ untracked risk
15. BCP กว้างกว่า DRP BCP รักษากระบวนการธุรกิจ ส่วน DRP กู้ IT อย่าให้ IT จัดลำดับธุรกิจโดยลำพัง
16. RTO คือเวลา, RPO คือข้อมูล RPO 2 ชั่วโมงไม่ได้หมายถึงระบบต้องกลับมาใน 2 ชั่วโมง
17. Backup ไม่เท่ากับ recovery ต้องทดสอบ restore, dependency, credential, capacity และ recovery sequence
18. BIA มาก่อนเลือก recovery solution ต้องรู้ critical process และ objectives ก่อนซื้อ hot site หรือ replication
19. Audit ไม่ได้เป็นเจ้าของ control ที่ตนตรวจ ความเป็นอิสระสำคัญต่อ assurance
20. Compliance เป็น baseline ไม่ใช่ปลายทาง ผ่าน audit แล้ว risk ยังเปลี่ยนได้ ต้อง monitor ต่อเนื่อง
21. Data owner กำหนด requirement, custodian ดำเนินการ อย่าสลับผู้กำหนด classification กับผู้ทำ backup
22. Awareness, training และ education ต่างกัน ข้อความเตือน phishing คือ awareness, workshop ตามบทบาทคือ training, หลักสูตรเชิงลึกคือ education
23. Completion rate ไม่พิสูจน์ behavior เลือก metric ที่เชื่อมกับ outcome เช่น report rate และ incident trend
24. Framework ต้อง tailor ISO Annex A, NIST controls หรือ COBIT objectives ไม่ใช่ checklist ที่ทุกองค์กรใช้เหมือนกัน
25. Authorize ไม่ได้แปลว่า risk เป็นศูนย์ หมายถึงผู้มีอำนาจตัดสินใจจากหลักฐานว่า risk อยู่ในระดับที่รับได้หรือมีเงื่อนไขจัดการ
26. Ethics ให้คุ้มครอง society และ common good ก่อน หน้าที่ต่อนายจ้างไม่ทำให้การกระทำผิดกฎหมายหรือเป็นอันตรายกลายเป็นสิ่งที่ยอมรับได้
27. เมื่อกฎหมายไม่ชัด ให้ปรึกษาผู้เชี่ยวชาญ ผู้สอบไม่ควรเลือกทำลายหลักฐาน เปิดเผยข้อมูล หรือสรุป jurisdiction เองโดยไม่มี authority
28. Third-party assurance เป็น input ไม่ใช่จุดจบ รายงาน audit ของ supplier ต้องตรวจ scope, period, exceptions และ relevance ต่อ service ที่ใช้

เทคนิคอ่านโจทย์คือขีดคำบอกลำดับ เช่น FIRST, BEST, MOST, PRIMARY แล้วแยกว่าโจทย์ถาม governance, process หรือ implementation คำตอบที่ถูกหลายข้ออาจอยู่คนละลำดับ หากถาม FIRST มักเริ่มจาก requirement, assessment หรือการคุ้มครองชีวิต หากถาม BEST ให้เลือกคำตอบที่แก้ root cause และสอดคล้อง business risk มากที่สุด

7. Cross-reference ไป Domain อื่น

• Domain 2: Asset Security ขยายเรื่อง asset/data classification, ownership, privacy, retention, handling และ secure disposal ซึ่งเป็นข้อมูลนำเข้าสำคัญของ risk assessment
• Domain 3: Security Architecture and Engineering ขยาย security models, control design, cryptography, secure architecture, physical design และ resilience ที่ใช้ทำให้ CIA requirements เป็นจริง
• Domain 4: Communication and Network Security ขยาย network architecture, secure protocols, segmentation และ communication controls ที่ลด threat paths
• Domain 5: Identity and Access Management ขยาย identity lifecycle, authentication, authorization, least privilege, separation of duties และ access review
• Domain 6: Security Assessment and Testing ขยาย control assessment, audit strategy, test independence, metrics และวิธีพิสูจน์ว่า control ทำงานตามที่ตั้งใจ
• Domain 7: Security Operations ขยาย incident response, investigations, evidence handling, logging, vulnerability management, DR implementation, DR testing และ personnel safety
• Domain 8: Software Development Security ขยาย SDLC, secure requirements, threat modeling, software supply chain, change control และการฝัง risk treatment ในการพัฒนา

เมื่อนำ Cross-reference ไปใช้ ให้เริ่มจาก Domain 1 เพื่อกำหนด เหตุผลและผู้ตัดสินใจ จากนั้นใช้ Domain อื่นกำหนด วิธีออกแบบ ดำเนินงาน และตรวจสอบ ตัวอย่างเช่น Domain 1 ระบุ risk และ RTO, Domain 3 ออกแบบ resilience, Domain 7 ดำเนิน recovery และ Domain 6 ทดสอบว่าผลลัพธ์ตรง requirement หรือไม่