CISSP Domain 6: Security Assessment and Testing

Domain 6 ว่าด้วยการสร้างหลักฐานว่า security control ถูกออกแบบเหมาะสม นำไปใช้จริง และทำงานได้ตามวัตถุประสงค์ ไม่ใช่เพียงตรวจว่ามี policy, firewall หรือ scanner อยู่ องค์กรต้องเลือกวิธีประเมินให้ตรงคำถาม ตั้งขอบเขตและ Rules of Engagement (ROE) อย่างปลอดภัย วิเคราะห์ผลโดยเชื่อม technical finding กับ business risk แล้วติดตาม remediation จนปิดหรือส่ง residual risk ให้ผู้มี authority ตัดสินใจ

หลักคิดสำหรับข้อสอบ: เริ่มจาก requirement, objective, scope และ authorization ก่อนเลือกเครื่องมือ แยก audit, assessment, vulnerability assessment และ penetration test ตามวัตถุประสงค์ รักษา independence ของผู้ประเมิน และอย่าถือว่า รายงานหรือผล scan ณ จุดเวลาเดียวพิสูจน์ว่า control มีประสิทธิผลตลอดไป

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

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 6 มีน้ำหนักเฉลี่ย 12% ของข้อสอบ เนื้อหาหลักครอบคลุมการออกแบบและยืนยัน assessment, test และ audit strategy; การทดสอบ security control; การเก็บข้อมูล security process; และการวิเคราะห์ผลพร้อมจัดทำรายงาน

คำว่า “น้ำหนักเฉลี่ย” ใช้จัดสรรเวลาอ่าน ไม่รับประกันจำนวนข้อที่ผู้สอบแต่ละคนจะพบ โจทย์มักถามสิ่งที่ต้องทำ FIRST, วิธีที่ BEST เพื่อพิสูจน์ control หรือ หลักฐานที่น่าเชื่อถือที่สุด ตัวเลือกที่ใช้เครื่องมือซับซ้อนอาจผิด หากยังไม่มี written authorization, scope, owner, baseline หรือเกณฑ์ตัดสินที่ตกลงกัน

ความสามารถสำคัญของ Domain นี้ประกอบด้วย

1. ออกแบบ assessment strategy ตาม risk กำหนด objective, criteria, scope, assessor independence, timing, sampling, evidence, location และ reporting
2. แยกวิธีประเมินให้ถูกคำถาม Audit ตรวจเทียบ criteria; assessment ประเมิน control และ risk; vulnerability assessment ค้นและจัดลำดับจุดอ่อน; penetration test ทดลอง exploit ภายใต้ขอบเขต
3. ทดสอบ control หลายมิติ ตรวจ design, implementation และ operating effectiveness ด้วย document review, interview, observation, sampling และ technical test
4. จัดการ vulnerability และ penetration testing อย่างปลอดภัย มี authorization, ROE, stop condition, emergency contact, data handling และ cleanup
5. ใช้ log และ process data เป็น evidence ตรวจ source coverage, เวลา, ความถูกต้องครบถ้วน, retention, access, review และความพร้อมของ log pipeline
6. วิเคราะห์และสื่อสารผลให้ตัดสินใจได้ แยก observation, finding, root cause, business impact, recommendation, owner, due date, exception และ retest
7. พัฒนาความสามารถอย่างต่อเนื่อง ใช้ metric และ maturity model เช่น CMMI เพื่อเปลี่ยนจากงานแบบ reactive ไปสู่กระบวนการที่วัดผลและปรับปรุงได้

Domain 6 รับ policy, risk appetite และ acceptance authority จาก Domain 1; ใช้ classification, retention และ Data owner จาก Domain 2; ประเมิน architecture และ assurance concept จาก Domain 3; ทดสอบ network control จาก Domain 4; และตรวจ identity lifecycle จาก Domain 5 ผลการทดสอบจะส่งต่อให้ Domain 7 เพื่อ remediation, monitoring และ incident response และให้ Domain 8 แก้ defect ใน Software Development Life Cycle (SDLC)

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

2.1 Requirement → control → evidence → conclusion

Assessment ที่ดีเริ่มจากคำถามว่า control ต้องบรรลุอะไร แล้วจึงระบุ evidence ที่ เพียงพอ หาก requirement กำหนดว่า account ของผู้ลาออกต้องถูกปิดภายในเวลาที่กำหนด หลักฐานไม่ควรมีแค่ procedure แต่ต้องมี HR termination record, identity event, deprovisioning timestamp, account state, exception และ sample ที่ครอบคลุมช่วงเวลา

Evidence ต้องสัมพันธ์กับ conclusion เอกสารพิสูจน์ design ได้ แต่ไม่พิสูจน์ว่า บุคลากรทำตามทุกครั้ง Screenshot หนึ่งภาพอาจพิสูจน์ configuration ณ จุดเวลา แต่ไม่ พิสูจน์ operating effectiveness ตลอดไตรมาส ในทางกลับกัน log จำนวนมากไม่มีคุณค่า หากไม่รู้ source, เวลา, completeness และ criteria ที่ใช้ตีความ

ภาพนี้แสดง feedback loop ของ assessment และ retest

flowchart TD req["Requirement/criteria"] --> ctrl["Control/expected result"] ctrl --> evidence["Evidence จาก examine/interview/test"] evidence --> conclusion["Conclusion: design/implementation/operating effectiveness"] conclusion --> gap{"Control gap"} gap --> pass["ไม่พบใน scope: limitation กับ residual risk"] gap --> finding["Validate และจัดทำ finding"] finding --> decision{"Treatment decision"} decision --> fix["Remediation/compensating control"] fix --> retest["Retest/closure evidence"] retest --> evidence decision --> accept["Formal risk acceptance: owner/approver/expiry"] pass --> residual["ติดตาม residual risk"] accept --> residual

2.2 Design adequacy, implementation และ operating effectiveness

การประเมิน control ควรแยกอย่างน้อยสามคำถาม

• Design adequacy — หากทำตามที่ออกแบบ control มีเหตุผลพอจะบรรลุ objective หรือไม่
• Implementation — control ถูกติดตั้ง กำหนดค่า และนำไปใช้กับ asset ใน scope แล้วหรือไม่
• Operating effectiveness — control ทำงานสม่ำเสมอตามที่ออกแบบตลอดช่วงเวลาที่สนใจหรือไม่

ตัวอย่าง policy กำหนดให้ privileged access ต้องมี approval และหมดอายุภายในแปดชั่วโมง Workflow ที่บังคับ approver และ expiry แสดง design; configuration กับการทดลองขอสิทธิ แสดง implementation; sample ของ request, approval, activation, expiry และ log ตลอด หลายเดือนจึงสนับสนุน operating effectiveness

ข้อสอบชอบให้ “มี policy” เป็นคำตอบลวง Policy เป็น governance requirement แต่ assessment ต้องหาหลักฐานการบังคับใช้และผลลัพธ์ด้วย

2.3 Audit, assessment และ test ไม่ใช่คำเดียวกัน

Audit เป็นกระบวนการที่มีโครงสร้างเพื่อเปรียบเทียบ evidence กับ criteria ที่กำหนด เช่น policy, contract, law หรือมาตรฐาน แล้วรายงาน conformity, nonconformity หรือ ข้อสังเกต Auditor ต้องรักษา objectivity และ independence ตามระดับ assurance ที่ต้องการ

Security assessment กว้างกว่า audit ใช้วิธี examine, interview และ test เพื่อ ตัดสินว่า control ถูกนำไปใช้ ถูกต้อง ทำงานตามที่ตั้งใจ และสร้างผลลัพธ์ตาม requirement หรือไม่ Assessment อาจเป็น internal, external, supplier, pre-production หรือ continuous ก็ได้

Security test เป็นกิจกรรมเฉพาะเพื่อกระตุ้นหรือสังเกตระบบ เช่น ส่ง synthetic transaction, ทดสอบ authorization, scan vulnerability หรือจำลอง attack Test ให้ evidence บางชนิด แต่ conclusion ระดับองค์กรยังต้องรวมบริบทและหลักฐานอื่น

คำว่า evaluation มักหมายถึงการวิเคราะห์ evidence เพื่อให้ judgment ส่วน inspection เน้นตรวจสิ่งที่มีอยู่เทียบข้อกำหนด การใช้คำอาจต่างกันระหว่างองค์กร จึงต้องกำหนด objective และ criteria ให้ชัดกว่าอาศัยชื่อกิจกรรมอย่างเดียว

2.4 Independence เพิ่มความน่าเชื่อถือ แต่ไม่แทน competence

ผู้สร้าง control ย่อมรู้ระบบดีและแก้ defect ได้เร็ว จึงเหมาะกับ self-test และ continuous testing แต่มี risk จาก confirmation bias หรือ conflict of interest ผู้ประเมินอิสระให้ challenge ที่น่าเชื่อถือกว่า แต่อาจขาด context ทางธุรกิจ

Independence มีหลายระดับ ตั้งแต่คนละบุคคลในทีม คนละสายการรายงาน internal audit ผู้ประเมินภายนอก ไปจนถึง certification body หรือ regulator การเลือกต้องสัมพันธ์กับ risk, obligation และผู้ใช้รายงาน ไม่ใช่สมมติว่า external ดีที่สุดเสมอ Assessor ยังต้องมี competence, access, methodology และ evidence ที่เพียงพอ

2.5 Point-in-time evidence กับ continuous assurance

Audit หรือ penetration test รายปีเป็น snapshot ที่มีวันหมดอายุโดยธรรมชาติ ระบบ, threat, dependency, configuration และบุคลากรเปลี่ยนตลอดเวลา Continuous monitoring และ automated test ช่วยพบ drift เร็วขึ้น แต่เพิ่ม noise, false positive, coverage gap และ dependency ต่อ telemetry

แนวทางที่แข็งแรงจึงผสม continuous evidence กับ periodic independent assessment และ event-driven reassessment เมื่อมี major change, incident, new threat, acquisition หรือข้อกำหนดใหม่ ความถี่ต้อง risk-based: control ที่ critical หรือเปลี่ยนบ่อยควรถูก ทดสอบถี่กว่า control ที่ stable และผลกระทบต่ำ

2.6 Positive assurance ไม่ใช่การพิสูจน์ว่าไม่มีช่องโหว่

ผล “ไม่พบ finding” หมายถึงไม่พบภายใต้ scope, เวลา, technique, access และ test case ที่ใช้ ไม่ได้พิสูจน์ว่าปลอดช่องโหว่ทั้งหมด False positive คือรายงานปัญหาที่เมื่อ ตรวจแล้วไม่ใช่ปัญหาจริง ส่วน false negative คือมีปัญหาแต่การทดสอบไม่พบ

Coverage, scanner quality, credential, environment, test data และ assessor skill มีผลต่อทั้งสองอัตรา การลด false positive ด้วยการปิด rule จำนวนมากอาจเพิ่ม false negative จึงต้อง tune, validate และบันทึก limitation อย่างโปร่งใส

2.7 Severity ไม่เท่ากับ business risk

คะแนน technical severity ช่วยจัดลำดับเบื้องต้น แต่ risk ต้องรวม likelihood, exploitability, exposure, asset value, data classification, existing control, blast radius, safety, legal obligation และ business context ช่องโหว่คะแนนสูงใน isolated test system อาจเร่งด่วนน้อยกว่าช่องโหว่ปานกลางที่เปิด internet และเข้าถึง ข้อมูลสำคัญได้

ผู้ทดสอบรายงาน evidence และความรุนแรง เจ้าของระบบร่วมกำหนด remediation ส่วน Risk owner ที่มี authority ตัดสิน accept residual risk การที่ scanner ใช้คำว่า “accepted” ไม่ได้ทำให้เครื่องมือมีอำนาจรับ risk

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

3.1 ออกแบบ audit และ assessment strategy

Strategy ที่ดีตอบคำถามต่อไปนี้ก่อนเริ่มงาน

1. Objective — ต้องการพิสูจน์ compliance, control effectiveness, readiness, vulnerability exposure หรือ resilience เรื่องใด
2. Criteria — จะเทียบกับ policy, standard, contract, regulation, baseline หรือ control objective ใด และใช้ version ใด
3. Scope และ boundary — ครอบคลุม asset, process, data flow, identity, supplier, environment, region และช่วงเวลาใด สิ่งใด out of scope
4. Authority และ ownership — ใครอนุมัติ ใครเป็น System owner/Data owner/Risk owner และใครรับ finding
5. Method และ depth — ใช้ document review, interview, observation, sampling, scanner, code review หรือ active test เท่าใด
6. Independence และ competence — ใครทำ ใคร review และมี conflict of interest หรือข้อจำกัดด้าน skill ใด
7. Timing และ trigger — periodic, continuous, before release, after change, after incident หรือก่อน contract renewal
8. Evidence handling — เก็บที่ใด ใครเข้าถึง retention เท่าใด ปกป้อง sensitive finding, credential, source code และ personal data อย่างไร
9. Safety และ communication — maintenance window, rate limit, stop condition, emergency contact, escalation และ status communication
10. Reporting และ follow-up — rating, owner, due date, exception, retest และ closure criteria เป็นอย่างไร

Audit plan แปลง strategy เป็นกำหนดการและ procedure ส่วน audit programme บริหาร audit หลายงานตลอดเวลา ทั้งสองไม่ใช่ checklist อย่างเดียว Checklist ช่วย consistency แต่ต้องปรับตาม risk และไม่ควรทำให้ assessor มองข้าม control ที่ล้มเหลว นอกข้อที่เตรียมไว้

ตัวอย่างองค์กรย้ายระบบชำระเงินไป cloud หากใช้ checklist data center เดิมโดยไม่ ปรับ shared responsibility จะเกิด scope gap Strategy ต้องระบุ control ที่ provider รับผิดชอบ control ที่ลูกค้าต้อง configure evidence ที่ขอจาก provider และ test ที่ ลูกค้าทำได้โดยไม่ละเมิด acceptable-use rule

3.2 Internal, external, second-party และ third-party

Internal หรือ first-party assessment ดำเนินภายในองค์กร มี context และเข้าถึง evidence ได้ดี เหมาะกับ self-assessment, internal audit, readiness review และ continuous control monitoring Internal audit ควรรายงานผ่านสายที่รักษา objectivity และไม่ audit งานที่ตนเป็นผู้ปฏิบัติหลักโดยไม่มี safeguard

คำว่า external บอกว่าผู้ประเมินอยู่นอก organizational control แต่ยังต้องดู ความสัมพันธ์เพิ่มเติม

• Second-party assessment มักเกิดเมื่อ customer ประเมิน supplier ตาม contract หรือ supplier assurance requirement
• Third-party assessment ดำเนินโดยหน่วยงานอิสระที่ไม่ใช่ผู้ให้บริการหรือผู้รับบริการ เช่น independent assessor หรือ certification body
• Regulatory examination ดำเนินตาม authority ของ regulator และมี scope/reporting requirement ของตน

Third-party report ลดงานซ้ำได้ แต่ไม่ควรรับมาแล้วเชื่อทั้งหมด ผู้ใช้รายงานต้องตรวจ scope, system description, control responsibility, period, test method, exception, subservice organization, complementary user controls และความเกี่ยวข้องกับ use case ตน รายงานสะอาดของ provider ไม่พิสูจน์ว่า customer configuration ถูกต้อง

สำหรับ service organization report โดยทั่วไป Type 1 ให้ภาพ design ของ control ณ วันที่กำหนด ส่วน Type 2 เพิ่มการทดสอบ operating effectiveness ตลอดช่วงเวลา จึงให้ evidence ต่างกัน นอกจากนี้ SOC 1 มุ่ง control ที่เกี่ยวกับ financial reporting ส่วน SOC 2 ใช้ Trust Services Criteria; ชื่อ SOC ไม่ได้แปลว่าครอบคลุมทุก security requirement ของลูกค้า

Location ก็เป็นส่วนของ strategy On-premises, cloud และ hybrid มี boundary, access, evidence และข้อจำกัดต่างกัน ใน cloud องค์กรอาจทดสอบเฉพาะ tenant configuration และ ต้องใช้ provider assurance สำหรับ infrastructure บางชั้น แต่ customer ยังรับผิดชอบ ข้อมูล identity และ configuration ตาม shared responsibility

3.3 Assessment types และวิธีเก็บ evidence

วิธีหลักสามกลุ่มมักใช้ร่วมกัน

• Examine — ตรวจ policy, architecture, configuration, ticket, source code, record, log, report และ artifact
• Interview — ถามผู้มีบทบาทเพื่อเข้าใจ process, decision, exception และความรู้
• Test — กระตุ้น control แล้วเปรียบเทียบ actual result กับ expected result

Document review เร็วและ risk ต่ำ แต่อาจพบเพียงสิ่งที่เขียนไว้ Interview อธิบาย เหตุผลและ workflow ได้ แต่เป็น testimonial evidence ซึ่งต้อง corroborate Observation เห็นงานจริงแต่บุคลากรอาจเปลี่ยนพฤติกรรมเมื่อรู้ว่าถูกสังเกต Technical test ให้ evidence ตรงกว่าใน test case ที่ใช้ แต่มี operational risk และ coverage จำกัด

Sampling จำเป็นเมื่อ population ใหญ่ Sample ต้องสะท้อน objective และ risk เช่น รวม privileged user, leaver, contractor, exception, หลาย location และหลายช่วงเวลา Random sampling ลด selection bias ขณะที่ judgmental sampling เลือก item risk สูง ทั้งสองตอบคนละคำถาม Assessor ต้องบันทึก population, selection method, sample size, exception และ limitation ไม่ขยาย conclusion เกินสิ่งที่ sample สนับสนุน

Assessment อาจแบ่งตามจุดประสงค์ เช่น

• Compliance assessment ตรวจว่าตรงข้อกำหนดหรือไม่ แต่ compliance ไม่รับประกัน security เพียงพอต่อ threat ทุกแบบ
• Risk assessment ระบุและวิเคราะห์ risk เพื่อเลือก treatment ตาม Domain 1
• Control assessment ประเมิน design, implementation และ effectiveness
• Architecture/configuration review ตรวจ trust boundary, data flow, baseline, hardening, firewall rule หรือ cloud policy
• Readiness/gap assessment หาช่องว่างก่อน audit หรือ certification จริง
• Vulnerability assessment ค้นหาและจัดลำดับ weakness โดยไม่จำเป็นต้อง exploit
• Penetration test ทดลองใช้ weakness เพื่อพิสูจน์ exploitability และ impact
• Red/purple team exercise ประเมิน detection และ response ต่อ objective ของ adversary simulation

3.4 Vulnerability assessment และ lifecycle

Vulnerability assessment ไม่ใช่เพียงกด scanner ขั้นตอนที่สมบูรณ์ประกอบด้วย

1. สร้างหรือยืนยัน asset inventory และ ownership
2. กำหนด scope, authorization, credential, safe-check policy และ scan window
3. ทำ discovery และเลือก scanner/signature/plugin ที่เหมาะกับ technology
4. เก็บผลแล้ว validate เพื่อลด false positive และ duplicate
5. เชื่อม finding กับ asset criticality, exposure, threat และ existing control
6. มอบ owner และเลือก remediate, mitigate, transfer, avoid หรือ accept ตาม authority
7. ทดสอบซ้ำเพื่อยืนยัน closure และติดตาม recurrence หรือ exception expiry

Authenticated scan ใช้ credential ที่อนุมัติเพื่อตรวจ package, patch, configuration และ local state ได้ลึกกว่า แต่เพิ่ม risk จาก privileged credential และอาจยังมี blind spot Unauthenticated scan แสดงมุมมองที่เข้าถึงได้โดยไม่ login เหมาะกับ external exposure แต่ไม่เห็น internal state ทั้งสองเสริมกัน

Network scanner, web application scanner, database scanner, cloud configuration scanner, container/image scanner และ dependency scanner เห็นคนละชั้น การใช้ network scanner อย่างเดียวไม่พิสูจน์ว่า source code หรือ authorization logic ปลอดภัย และ scanner ที่ไม่รู้ ephemeral asset อาจรายงาน coverage สูงเกินจริง

คะแนนอย่าง Common Vulnerability Scoring System (CVSS) ให้ภาษากลางสำหรับ technical severity แต่ไม่ได้รวม business context ทั้งหมด Prioritization ควรพิจารณาว่า asset ถูกเปิดเผยหรือไม่ มี exploit path จริงหรือไม่ compensating control ทำงานหรือไม่ ข้อมูลและ mission สำคัญเพียงใด และ patch กระทบ Availability หรือ safety อย่างไร

ตัวอย่าง scanner รายงาน library ที่มีช่องโหว่ใน container image ระดับสูง ทีมต้อง ตรวจว่า version อยู่จริง โหลดใน runtime และ feature ที่มีปัญหาถูกเรียกหรือไม่ แต่ การ “not exploitable” ต้องมี evidence และวันทบทวน ไม่ใช่ลบ finding เพื่อให้ dashboard เป็นสีเขียว

3.5 Penetration testing และ Rules of Engagement

Penetration testing ใช้การโจมตีที่ได้รับอนุญาตเพื่อยืนยันว่า weakness ถูก exploit ได้ เชื่อมต่อกันเป็น attack path หรือสร้าง business impact ใด จุดต่างสำคัญคือ vulnerability assessment เน้น breadth และการค้นหา ส่วน penetration test เน้น validation และ depth ภายใน objective/scope ที่กำหนด

ภาพนี้แยก objective ของ vulnerability assessment กับ penetration testing ก่อน รวมผล

flowchart LR start["Objective/scope/authorization"] --> question{"Breadth หรือ impact"} question --> va["Breadth: Vulnerability assessment"] question --> pt["Exploit/path/impact: Penetration testing"] va --> vad["Discovery/scan/validation"] vad --> vap["Prioritize: business context"] pt --> ptr["Written authorization/ROE"] ptr --> pte["Discovery/exploitation/impact validation"] vap --> outcome["Finding/owner/treatment decision"] pte --> outcome outcome --> followup["Remediation/retest/risk acceptance"]

ขั้นตอนระดับบริหารประกอบด้วย

1. Pre-engagement — ระบุ objective, written authorization, scope, ROE, stakeholder, legal/contract constraint และ success criteria
2. Discovery และ threat modeling — ทำความเข้าใจ asset, interface, identity, data flow และ attack surface ตามขอบเขต
3. Vulnerability analysis — ตรวจ weakness และเลือก test case ที่คุ้ม risk
4. Controlled exploitation — ยืนยัน exploitability โดยหยุดที่หลักฐานขั้นต่ำที่ พิสูจน์ impact ไม่ขยายความเสียหายโดยไม่จำเป็น
5. Post-exploitation validation — ประเมิน privilege, lateral path และ data access เฉพาะที่อนุมัติ
6. Cleanup และ restoration — ลบ account, payload, test data และ configuration ที่สร้าง พร้อมยืนยันระบบกลับสู่ state ที่ตกลง
7. Reporting, remediation และ retest — ส่งทั้ง executive summary และ technical evidence โดยปกป้องรายละเอียดที่ attacker ใช้ได้

ROE ต้องระบุ IP/domain/account ที่อยู่ในและนอก scope, เวลา, allowed/prohibited technique, production restriction, social engineering/physical test, data exfiltration simulation, denial-of-service, rate limit, source address, emergency contact, stop condition, incident handling, evidence retention และ communication หากไม่มี authorization ผู้ทดสอบไม่ควร “ลองก่อนแล้วขออนุญาตทีหลัง”

Black-box, gray-box และ white-box อธิบายระดับ knowledge/access ของผู้ทดสอบ

แนวทาง	Knowledge โดยทั่วไป	คุณค่าหลัก	ข้อจำกัด
Black-box	น้อยหรือไม่มีข้อมูลภายใน	ใกล้มุมมอง outsider และทดสอบ discovery	ใช้เวลาค้นหาและอาจ coverage ต่ำ
Gray-box	มีข้อมูลหรือสิทธิบางส่วน	สมดุล realism กับ efficiency; เหมาะกับ user role	อาจไม่เห็น privileged/internal path ทั้งหมด
White-box	มี architecture, code, credential หรือ configuration มาก	coverage ลึกและใช้เวลาคุ้มกว่า	ไม่จำลอง outsider แบบบริสุทธิ์

ระดับ knowledge ไม่ได้บอกสีของทีม Red team ทำ objective-driven adversary emulation เพื่อทดสอบคน กระบวนการ และเทคโนโลยี Blue team ป้องกัน ตรวจจับ และ ตอบสนอง Purple team คือการทำงานร่วมกันเพื่อปรับ control และ detection ไม่ใช่ เพียงตั้งทีมสีใหม่ Penetration test มักมี scope ชัดและเน้นค้น/พิสูจน์ช่องโหว่ ส่วน red team อาจเน้น mission objective และหลีกเลี่ยงการตรวจจับภายใต้ ROE

ใน Operational Technology (OT), healthcare หรือระบบ safety-critical active test อาจทำให้เกิด physical harm วิธีที่เหมาะอาจเป็น passive review, replica, digital twin, maintenance window หรือ vendor-approved test โดยให้ human safety มาก่อน คะแนน severity หรือความสมจริงของ exercise

3.6 Red, blue, purple team และ breach and attack simulation

Red team exercise เริ่มจาก objective เช่น “พิสูจน์ว่าสามารถเข้าถึงข้อมูลการเงินโดย ไม่ถูกตรวจพบหรือไม่” ไม่จำเป็นต้องสร้างรายการ vulnerability ให้ยาวที่สุด Success criterion ต้องรวมความสามารถของ blue team ในการ detect, triage, contain และ communicate ไม่ควรให้คะแนนจากการที่ red team “ชนะ” เพียงด้านเดียว

Purple teaming ทำให้ red และ blue แลกเปลี่ยน technique, telemetry และ detection hypothesis อย่างมีโครงสร้าง ตัวอย่าง red team จำลอง credential misuse ใน test account แล้ว blue teamตรวจว่า identity log มาถึง Security Information and Event Management (SIEM), correlation rule alert, analyst triage ถูก และ playbook revoke session ได้ จากนั้นทำซ้ำหลังแก้ไขเพื่อวัด improvement

Breach and Attack Simulation (BAS) ใช้ automation รัน attack-like action ที่ ควบคุมได้ซ้ำ ๆ เพื่อยืนยัน preventive และ detective control เหมาะกับ regression, coverage และ drift detection แต่ BAS ไม่แทน human creativity, social context, complex business logic หรือ independent penetration test การรันถี่ไม่ได้แปลว่า coverage ครบ หาก technique, asset หรือ telemetry สำคัญไม่อยู่ใน library

คำอย่าง blind และ double-blind ใช้ไม่สม่ำเสมอระหว่างองค์กร บางแห่งหมายถึง blue team ไม่รู้เวลา บางแห่งหมายถึงผู้ทดสอบมีข้อมูลจำกัด จึงต้องนิยามใน ROE อย่าอาศัยชื่อ เพียงอย่างเดียวในการตัดสิน risk

3.7 Log management, log review และ SIEM

Log เป็นทั้ง operational telemetry, detection input, audit evidence และ forensic artifact แต่การ “เปิด logging” ไม่ทำให้เกิด accountability อัตโนมัติ Log management ต้องจัดการ lifecycle ตั้งแต่การกำหนด use case ไปจนถึง disposition

1. Define — ระบุ event ที่ต้องตอบคำถามได้ เช่น authentication, authorization decision, privilege use, configuration change, data access และ security alert
2. Generate — ให้ source บันทึก identity, action, object, result, timestamp, source/context และ correlation identifier เท่าที่เหมาะสม
3. Collect และ transport — ส่ง log ผ่านช่องทางที่ปกป้องความลับและความถูกต้อง ครบถ้วน พร้อม buffer/retry เมื่อ collector ใช้งานไม่ได้
4. Normalize และ enrich — แปลง field ให้ค้นร่วมกันได้และเพิ่ม asset, owner, classification หรือ threat context โดยรักษา raw evidence ตาม requirement
5. Store และ protect — ใช้ access control, segregation, integrity protection, backup/availability และ retention ที่สัมพันธ์กับ legal/business need
6. Analyze และ correlate — ใช้ query, rule, baseline และ analyst judgment เพื่อ เชื่อม event หลายแหล่ง
7. Review และ respond — กำหนด owner, frequency, escalation, case handling และ evidence preservation
8. Dispose — ทำลายเมื่อหมด retention/legal hold ตาม Domain 2

Log aggregation คือรวบรวม log ไว้ด้วยกัน ส่วน correlation เชื่อม event หลายรายการตามเวลา identity, asset หรือ pattern เพื่อสร้างความหมาย SIEM สนับสนุน collection, normalization, correlation, alert และ search แต่ SIEM ที่รับ log ไม่ครบ เวลาคลาด หรือ rule ไม่ถูก review จะให้ความมั่นใจลวง

Time synchronization สำคัญต่อการเรียงเหตุการณ์และ correlation ต้องเก็บ timezone, clock source และความคลาดที่ยอมรับได้ตามระบบ หากเวลาของ IdP, endpoint และ application ต่างกัน อาจดูเหมือน authorization เกิดก่อน authentication อย่า “แก้” raw timestamp โดยไม่มี traceability

Log ต้องปกป้องทั้งสามด้านของ CIA:

• การรักษาความลับ เพราะ log อาจมี personal data, token, query, filename หรือ business activity; หลีกเลี่ยงบันทึก password, private key และ secret
• ความถูกต้องครบถ้วน ด้วย restricted write/delete, append-oriented storage, integrity check, immutable/WORM capability ตาม risk และ chain of custody
• ความพร้อมใช้ ด้วย capacity planning, health monitoring, queue, redundancy และ recovery เพราะ incident มักสร้าง log volume สูง

Log review เป็น control test ได้สองแบบ หนึ่ง ตรวจว่า event ที่ policy กำหนดถูกสร้าง และมี field พอหรือไม่ สอง วิเคราะห์ log เพื่อหาพฤติกรรมผิดปกติ ตัวอย่าง test authentication failure ใน account ทดสอบ แล้วตาม event ตั้งแต่ source ถึง alert และ ticket หาก event อยู่ที่ source แต่ไม่ถึง SIEM ปัญหาอาจอยู่ใน pipeline ไม่ใช่ authentication control

Retention ไม่ควรตั้งว่า “เก็บให้นานที่สุด” โดยอัตโนมัติ ต้องสมดุล investigation window, regulation, contract, storage, privacy และ data minimization Log rotation เพียงเปลี่ยนไฟล์ ไม่เท่ากับ retention; dashboard แสดงกราฟได้ ไม่พิสูจน์ว่า raw log ครบหรือแก้ไขไม่ได้

3.8 Code review และ application security testing

Code review ตรวจ source code หรือการเปลี่ยนแปลงเพื่อหา defect, insecure pattern, logic flaw, authorization bypass, secret exposure และการไม่ทำตาม secure coding standard การ review ที่ดีดูทั้งสิ่งที่เพิ่ม แก้ และลบ รวมทั้ง test, configuration, Infrastructure as Code (IaC), dependency และ migration ที่มากับ change

วิธีสำคัญประกอบด้วย

• Peer review/manual review ใช้ความเข้าใจ business logic, trust boundary, misuse case และ context ที่เครื่องมือมองไม่เห็น
• Static Application Security Testing (SAST) วิเคราะห์ code, bytecode หรือ artifact โดยไม่ต้องรัน application เหมาะกับ feedback เร็ว แต่ต้อง tune rule และ validate data flow
• Dynamic Application Security Testing (DAST) ทดสอบ application ที่กำลังทำงาน จาก interface ภายนอก เห็น runtime behavior แต่ไม่รู้ source path ทั้งหมด
• Interactive Application Security Testing (IAST) ใช้ instrumentation ระหว่าง runtime test เพื่อเชื่อม behavior กับ code path; coverage ขึ้นกับ test ที่รัน
• Software Composition Analysis (SCA) ระบุ open-source component, version, dependency และ known vulnerability/licensing signal; inventory ที่ไม่ครบทำให้ผลผิด
• Fuzz testing ส่ง input จำนวนมากหรือผิดรูปเพื่อหาการ crash, exception, validation flaw และ unexpected state โดยต้อง monitor และลดผลกระทบ

Automated tool scale ได้และตรวจ pattern ซ้ำสม่ำเสมอ แต่ไม่เข้าใจ requirement ทั้งหมด Manual review เหมาะกับ authorization, cryptographic use, state transition, race condition และ business abuse แต่ช้าและขึ้นกับ reviewer ทั้งสองควรเสริมกัน

Review process ต้องกำหนด reviewer independence ตาม risk, protected repository access, change traceability, severity, merge gate, exception, remediation และ retest Code owner ไม่ควร approve exception ของตนเองโดยไม่มี authority แยก และการ มีสองคนกด approve ไม่พิสูจน์ว่าตรวจ security หากไม่มี criteria หรือ competence

Misuse case testing เริ่มจากสิ่งที่ผู้ไม่หวังดีหรือผู้ใช้ผิดวิธีอาจทำ เช่น เปลี่ยน object identifier เพื่ออ่านข้อมูลคนอื่น ข้าม approval step, replay request หรือใช้ field ที่ UI ซ่อนไว้ Test ต้องผ่านทุก relevant interface ไม่ใช่เฉพาะ GUI เพราะ API, batch, mobile และ administrative path อาจบังคับ policy ต่างกัน

Interface testing ตรวจ input validation, authentication, authorization, session, error handling, rate limit และ contract ระหว่าง component ตัวอย่าง UI ซ่อนปุ่ม “Refund” แต่ API ยังรับ request จาก user role ปกติ การทดสอบ UI ผ่านไม่ได้ พิสูจน์ API authorization

3.9 Coverage analysis, synthetic transaction และ benchmark

Coverage บอกว่าพื้นที่ใดถูกทดสอบ ไม่ได้บอกว่าผลถูกต้องหรือปลอด defect ทั้งหมด

• Requirements/control coverage — requirement หรือ control objective ใดมี test และ evidence
• Asset/interface coverage — asset, account type, API, network path และ environment ใดอยู่ใน scope
• Code coverage — statement, branch, condition หรือ path ใดถูก execute
• Attack/technique coverage — behavior หรือ detection hypothesis ใดถูกจำลอง
• Log source/use-case coverage — source และ detection use case ใดส่งข้อมูลครบ

Code coverage 100% อาจรันทุก statement ด้วย assertion ที่อ่อน และ path ทั้งหมดอาจ มีจำนวนสูงจนทดสอบครบไม่ได้ Coverage จึงเป็น indicator ของพื้นที่ที่สัมผัส ไม่ใช่ quality score โดยตัวมันเอง ต้องจับคู่กับ test design, expected result และ defect escape

Synthetic transaction เป็นธุรกรรมจำลองที่รู้ expected result เช่น login ด้วย test identity, สร้าง order ทดสอบ หรือเรียก health-check API เพื่อยืนยัน end-to-end service และ monitoring สามารถใช้ตรวจ Availability, authentication, workflow และ alert pipeline อย่างต่อเนื่อง ต้องแยก test data จาก production record และไม่ให้ synthetic account กลายเป็น privileged backdoor

Benchmark เปรียบเทียบ configuration หรือผลกับ baseline/reference ที่อนุมัติ เช่น secure configuration benchmark หรือ performance baseline Benchmark ต้องตรง technology/version และถูก tailor ตาม business requirement การผ่าน baseline ไม่ ยืนยันว่า application logic ปลอดภัย และ deviation อาจเป็น authorized exception หรือ finding ต้องตรวจเหตุผล ไม่ตัดสินจากความต่างเพียงอย่างเดียว

Regression testing รัน test เดิมหลัง change เพื่อยืนยันว่า defect ที่แก้ไม่กลับมา และ control อื่นไม่เสีย Test suite ต้อง versioned, reviewed และเพิ่ม case จาก incident/finding ใหม่ มิฉะนั้น automation จะทำซ้ำเพียง blind spot เดิม

3.10 Security process data, KPI และ KRI

Process data ตอบว่า control ทำงานในระดับระบบและองค์กรหรือไม่ ตัวอย่างจาก Domain นี้ ได้แก่ account management, management approval, training, backup verification, Disaster Recovery (DR), Business Continuity (BC), vulnerability remediation และ security review

Key Performance Indicator (KPI) บอก performance เทียบ objective เช่นสัดส่วน critical finding ที่ remediate ภายใน target หรือสัดส่วน leaver account ที่ปิดทัน เวลา Key Risk Indicator (KRI) ส่งสัญญาณ exposure หรือแนวโน้ม risk เช่นจำนวน internet-facing critical asset ที่เลย remediation deadline หรือสัดส่วน log source สำคัญที่ไม่ส่ง telemetry

Metric ที่ใช้ตัดสินใจได้ต้องมี owner, definition, formula, data source, frequency, target/threshold, segmentation, limitation และ action เมื่อเกินเกณฑ์ ระวัง metric ที่ถูก game ได้ ตัวอย่าง “จำนวนช่องโหว่ที่ปิด” อาจดีขึ้นเพราะปิดรายการความเสี่ยงต่ำ จำนวนมาก ขณะที่ critical exposure ยังอยู่ ควรดู severity, age, asset criticality, recurrence และ exception ร่วมกัน

Leading indicator ส่งสัญญาณก่อนผลเสีย เช่น patch coverage, percentage ของ change ที่ผ่าน security test หรือ log pipeline health Lagging indicator สะท้อน ผลที่เกิดแล้ว เช่น incident, control failure หรือ missed recovery target ทั้งสอง จำเป็น Leading metric ที่ดีไม่ได้พิสูจน์ผลลัพธ์ และ lagging metric “ไม่มี incident” อาจเกิดจาก detection อ่อน

ตัวอย่าง process evidence ที่เหมาะสม:

Process	Evidence และ metric ตัวอย่าง	สิ่งที่ไม่ควรสรุปเกิน
Account management	request, approval, grant/revoke timestamp, orphan scan, access review exception	Ticket ปิดแล้วไม่ได้พิสูจน์ว่า entitlement ถูกถอนทุกระบบ
Management review	agenda, decision, owner, due date, follow-up	ลายเซ็นอย่างเดียวไม่พิสูจน์ว่าผู้อนุมัติมีข้อมูลพอ
Training	assignment, completion, simulation result, role-specific coverage	Completion 100% ไม่พิสูจน์ว่าพฤติกรรมเปลี่ยน
Backup	job status, integrity check, restore test, RPO evidence	“Backup successful” ไม่พิสูจน์ว่ากู้คืนและใช้งานได้
DR/BC	exercise objective, participant, result, gap, retest	Tabletop ไม่พิสูจน์ technical failover
Vulnerability	coverage, age, exploit context, exception, retest	จำนวน finding ลดไม่พิสูจน์ว่า attack surface ลด

3.11 วิเคราะห์ผล รายงาน และติดตาม remediation

ผลจากเครื่องมือยังไม่ใช่ finding ที่สมบูรณ์ Analyst ต้อง validate, de-duplicate, เชื่อม asset/owner, อธิบาย condition เทียบ criteria, ประเมิน cause และ impact แล้ว บันทึก limitation รายงานควรแยกสองระดับ

• Executive summary อธิบาย objective, scope, overall risk, systemic theme, business impact, decision และ resource ที่ต้องใช้
• Technical detail ระบุ asset, evidence, reproduction ที่ปลอดภัย, affected control, severity/risk rationale, recommendation และ validation method

Finding ที่ actionable ควรมีอย่างน้อย criteria, condition, evidence, cause, consequence, rating, owner, target date และ recommended outcome Recommendation ไม่ควรบังคับ product หาก objective ทำได้หลายทาง Owner อาจเลือก corrective action, compensating control, system retirement หรือ formal risk acceptance

Root cause analysis มองลึกกว่าการ patch instance เดียว เช่น finding เรื่อง security group เปิดกว้างอาจเกิดซ้ำเพราะ IaC template, approval gap หรือไม่มี policy as code ถ้าแก้เฉพาะ resource ปัจจุบัน recurrence ยังสูง Corrective action แก้เหตุ ของ nonconformity ส่วน correction แก้สิ่งที่พบ ณ จุดนั้น

Closure ต้องใช้ evidence ไม่ใช่เพียงสถานะ ticket Retest ยืนยันว่า remediation แก้ finding และไม่สร้างผลข้างเคียง หากยอมรับ risk ต้องมี scope, rationale, compensating control, approver, expiry/review date และ monitoring Exception ที่ไม่มี วันหมดอายุมักกลายเป็น control bypass ถาวร

การ disclose finding ต้องใช้ need-to-know รายงาน penetration test อาจมี credential, attack path และ exploit detail ที่เพิ่ม risk หากรั่ว ต้องกำหนด classification, encryption, recipient, retention และ secure destruction ตาม Domain 2

3.12 CMMI และการวัด process maturity

Capability Maturity Model Integration (CMMI) เป็นกรอบปรับปรุง process และ performance ไม่ใช่ vulnerability scanner, penetration methodology หรือหลักฐานว่า security control ทุกตัวมีประสิทธิผล CMMI ช่วยมองว่ากระบวนการ assessment/testing พึ่งบุคคลเฉพาะหน้า หรือถูกจัดการ กำหนดมาตรฐาน วัดเชิงปริมาณ และปรับปรุงอย่างต่อเนื่อง

ตามคำอธิบายระดับของ CMMI Institute maturity level ในกรอบปัจจุบันประกอบด้วย

ระดับ	ชื่อ	ลักษณะของ process
0	Incomplete	งานไม่สมบูรณ์หรือไม่แน่นอน อาจสำเร็จหรือไม่สำเร็จ
1	Initial	Reactive และคาดการณ์ยาก ผลลัพธ์พึ่งบุคคลหรือสถานการณ์
2	Managed	งานระดับ project ถูกวางแผน ดำเนิน วัด และควบคุม
3	Defined	ใช้มาตรฐานระดับองค์กรและ tailor อย่างมีหลักเกณฑ์
4	Quantitatively Managed	ใช้ข้อมูลเชิงปริมาณควบคุม performance และ predictability
5	Optimizing	ปรับปรุงอย่างต่อเนื่องด้วยข้อมูล เรียนรู้ และตอบการเปลี่ยนแปลง

ตำราหรือข้อสอบรุ่นเดิมอาจเน้น maturity level 1–5 แต่คำอธิบายทางการปัจจุบันแสดง Level 0 ด้วย ต้องอ่านถ้อยคำในโจทย์ให้ดี นอกจากนี้ capability level ใช้กับ practice area รายด้าน ส่วน maturity level เป็น staged path ของชุด practice area ระดับองค์กร ไม่ควรใช้แทนกัน

ตัวอย่าง vulnerability management ที่ Level 1 อาจ scan เมื่อ auditor ขอและเก็บผลใน spreadsheet ของแต่ละคน Level 2 มีกำหนดการ owner และ ticket; Level 3 ใช้มาตรฐาน ร่วมกับ exception process ทั่วองค์กร; Level 4 วัด coverage, age, recurrence และ predict remediation capacity; Level 5 ใช้ข้อมูลจาก incident, threat และ defect escape ปรับ test strategy อย่างต่อเนื่อง

ระดับสูงไม่ใช่เป้าหมายอัตโนมัติทุก process องค์กรต้องเลือก capability ที่เหมาะกับ business objective และ risk การสร้างเอกสารจำนวนมากเพื่อ “ได้ระดับ” โดยไม่เพิ่ม security outcome เป็นการวัดผิดเป้าหมาย

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

4.1 NIST

NIST SP 800-53A Rev. 5 ให้ methodology และ assessment procedure สำหรับ security และ privacy controls ที่ สัมพันธ์กับ NIST SP 800-53 Rev. 5 โดยใช้วิธี examine, interview และ test Procedure สามารถ tailor ด้าน scope, depth และ coverage ให้ตรง risk tolerance และ phase ของ system lifecycle ได้

NIST SP 800-115 เป็น Technical Guide to Information Security Testing and Assessment ครอบคลุม planning, review technique, target identification/analysis และ vulnerability validation ใช้เป็น กรอบวาง technical assessment ได้ แต่ต้องปรับตาม technology และ threat ปัจจุบัน

NIST SP 800-92 ให้แนวทาง computer security log management ตั้งแต่ infrastructure, process, operational role จนถึง การวางแผน แม้เป็นเอกสารเก่า หลักเรื่อง policy, central management, analysis, retention และ operational responsibility ยังใช้เป็นพื้นฐานได้โดยต้องเทียบกับ technology และ obligation ปัจจุบัน

การใช้ NIST ที่ดีไม่ใช่รัน procedure ทุกข้อเท่ากัน แต่เริ่มจาก control objective, tailor assessment plan, ระบุ evidence และบันทึก limitation ให้ผู้ตัดสิน risk เข้าใจ

4.2 ISO/IEC 27001

ISO/IEC 27001:2022 วาง requirement ของ Information Security Management System (ISMS) แบบ risk-based ส่วนที่เกี่ยวข้อง โดยตรงคือ Clause 9.1 เรื่อง monitoring, measurement, analysis and evaluation และ Clause 9.2 เรื่อง internal audit รวมถึง management review, corrective action และ continual improvement ที่ทำให้ finding ไม่จบแค่รายงาน

Annex A ที่เกี่ยวข้องรวม independent review of information security, compliance with policies/rules/standards, management of technical vulnerabilities, logging, monitoring activities และ security testing in development and acceptance การเลือก control ต้องมาจาก risk treatment และ Statement of Applicability ไม่ใช่สมมติว่า Annex A ทุก control ใช้เหมือนกันทุกองค์กร

ISO/IEC 27004:2016 ให้แนวทาง monitoring, measurement, analysis และ evaluation ของ information security performance กับ ISMS effectiveness ส่วน ISO/IEC 27007:2020 ให้แนวทางจัดการ ISMS audit programme, ดำเนิน audit และ competence ของ auditor โดยต่อยอดจาก ISO 19011

4.3 COBIT

COBIT 2019 เป็นกรอบ governance และ management ของ enterprise information and technology ช่วยเชื่อม assessment activity กับ enterprise objective, decision rights, accountability และ performance management ไม่ได้แทน technical testing guide

กลุ่ม Monitor, Evaluate and Assess (MEA) เกี่ยวข้องชัดเจน ได้แก่ MEA01 Managed Performance and Conformance Monitoring, MEA02 Managed System of Internal Control, MEA03 Managed Compliance With External Requirements และ MEA04 Managed Assurance ส่วน APO12 Managed Risk, APO13 Managed Security, DSS05 Managed Security Services และ BAI06 Managed IT Changes เชื่อมผล assessment กับ risk, operations และ change

COBIT ช่วยตอบว่าใครต้องรับ information, ใครตัดสิน และ process ต้องให้ outcome ใด ขณะที่ NIST หรือวิธี technical test ช่วยตอบว่าจะเก็บ evidence อย่างไร อย่าใช้ capability score เป็นเป้าหมายโดยไม่เชื่อม business value และ risk

4.4 ITIL

ITIL 4 เชื่อม assessment และ testing เข้ากับ service value chain และงานประจำ Practice ที่เกี่ยวข้อง ได้แก่ Information Security Management, Monitoring and Event Management, Change Enablement, Service Validation and Testing, Release Management, Incident Management, Problem Management และ Continual Improvement รายชื่อ practice หลักเหล่านี้ปรากฏใน เอกสาร ITIL 4 ของ PeopleCert

ตัวอย่าง finding จาก log review ว่า collector หลุดบ่อยไม่ควรจบที่ security ticket ต้องเชื่อม monitoring event, incident เพื่อคืนบริการ, problem เพื่อหา root cause, change เพื่อแก้ pipeline, validation เพื่อทดสอบ และ continual improvement เพื่อวัด recurrence ITIL เน้นให้ test สนับสนุนคุณค่าและคุณภาพของ service ไม่ใช่ทำเพื่อผ่าน audit เพียงวันเดียว

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

ใช้ ISO/IEC 27001 สร้างวงจร ISMS และ audit requirement; COBIT กำหนด governance, objective, accountability และ assurance; NIST ให้ control assessment, technical testing และ log guidance; ITIL ฝัง monitoring, test, change และ remediation ใน service management; CMMI ช่วยวิเคราะห์และพัฒนา process maturity

กรอบเหล่านี้เสริมกัน ไม่ควรเอา maturity level, certification, compliance report หรือ tool output อย่างใดอย่างหนึ่งมาแทน conclusion เรื่อง security effectiveness ลำดับร่วมกับบทก่อนหน้าคือ requirement → control → evidence → conclusion → remediation/decision → residual risk

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

คำศัพท์	นิยามสั้น
Audit	การตรวจ evidence เทียบ criteria อย่างเป็นระบบและรักษา objectivity
Security assessment	การ examine, interview และ test เพื่อประเมิน control และ risk
Security test	การกระตุ้นหรือสังเกตระบบเพื่อเปรียบเทียบ actual กับ expected result
Criteria	policy, standard, contract หรือ requirement ที่ใช้ตัดสิน evidence
Design adequacy	ความเหมาะสมของแบบ control ต่อ objective หากทำตามแบบ
Operating effectiveness	ความสม่ำเสมอที่ control ทำงานตามแบบตลอดช่วงที่ประเมิน
Evidence	ข้อมูลหรือ artifact ที่ตรวจสอบได้และสนับสนุน conclusion
Sampling	การเลือกส่วนหนึ่งของ population มาทดสอบด้วยวิธีที่อธิบายได้
Rules of Engagement (ROE)	ข้อตกลง authorization, scope, technique, safety และ communication ของ test
Vulnerability assessment	การค้นหา validate และจัดลำดับจุดอ่อนโดยไม่จำเป็นต้อง exploit
Penetration testing	การทดลอง exploit ที่ได้รับอนุญาตเพื่อยืนยัน path และ impact
Red team	ทีมจำลอง adversary เพื่อบรรลุ objective ภายใต้ ROE
Blue team	ทีมป้องกัน ตรวจจับ วิเคราะห์ และตอบสนอง
Purple team	การร่วมมือ red-blue เพื่อทดสอบและปรับ control/detection
BAS	automation ที่จำลอง attack action แบบควบคุมและทำซ้ำได้
Black-box testing	ทดสอบด้วย knowledge/access ภายในน้อยหรือไม่มี
Gray-box testing	ทดสอบด้วย knowledge/access ภายในบางส่วน
White-box testing	ทดสอบด้วย architecture, code หรือ credential ภายในมาก
False positive	รายงานปัญหาที่ตรวจยืนยันแล้วไม่เป็นปัญหาจริง
False negative	มีปัญหาจริงแต่การทดสอบไม่พบหรือไม่รายงาน
Log aggregation	การรวบรวม log หลาย source ไว้เพื่อจัดการร่วมกัน
Correlation	การเชื่อม event หลายรายการเพื่อหาความสัมพันธ์และความหมาย
SIEM	ระบบรวบรวม วิเคราะห์ correlate และสนับสนุน alert/search ของ security event
SAST	วิเคราะห์ code/artifact โดยไม่ต้องรัน application
DAST	ทดสอบ application ที่กำลังทำงานผ่าน interface ภายนอก
IAST	ใช้ runtime instrumentation เชื่อม test behavior กับ code path
SCA	วิเคราะห์ component/dependency เพื่อทำ inventory และหาความเสี่ยงที่รู้จัก
Synthetic transaction	ธุรกรรมจำลองที่รู้ expected result สำหรับทดสอบ end-to-end
Coverage analysis	การวัดว่าส่วนใดของ requirement, asset, code หรือ technique ถูกทดสอบ
KPI	indicator ของ performance เทียบ objective
KRI	indicator ที่ส่งสัญญาณระดับหรือแนวโน้ม risk
Retest	การทดสอบซ้ำเพื่อยืนยัน remediation และผลข้างเคียง
CMMI	กรอบปรับปรุง capability, process และ performance อย่างเป็นลำดับ

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

1. เริ่มจาก objective, scope และ authorization ไม่ใช่เริ่มที่ scanner
2. Audit เทียบ criteria; assessment ประเมิน control; test สร้าง evidence คำเหล่านี้เกี่ยวข้องแต่ไม่เหมือนกัน
3. มี policy ไม่พิสูจน์ operating effectiveness ต้องดู transaction ตลอดช่วงเวลา
4. ผู้สร้าง control อาจ self-test ได้ แต่ independent review ให้ assurance ต่างกัน
5. External ไม่เท่ากับ independent เสมอ Supplier อาจเป็นคนนอกแต่มีผลประโยชน์ตรง
6. Sample ไม่ใช่ population ทั้งหมด ระบุ selection และ limitation ก่อนสรุป
7. ไม่พบ finding ไม่ได้แปลว่าไม่มีช่องโหว่ ผลถูกจำกัดด้วย scope และ coverage
8. Authenticated scan ลึกกว่าโดยทั่วไป แต่ credential ต้องป้องกัน และยังมี blind spot
9. Vulnerability scan ไม่เท่ากับ penetration test Scan หา breadth; pentest ยืนยัน exploit/path
10. Penetration test ต้องมี written authorization และ ROE โดยเฉพาะ production, social engineering, physical และ denial-of-service
11. Black/gray/white box บอก knowledge ไม่ได้บอก team color
12. Red team ไม่ใช่ pentest ที่ใหญ่กว่าเสมอ Red team เน้น objective และ detection/response ด้วย
13. Purple team คือ collaboration ไม่ใช่ assessor อิสระประเภทใหม่
14. BAS ทำซ้ำได้ แต่ไม่แทน human testing Automation มี coverage ตาม library
15. False positive สร้างงานเกิน; false negative ทิ้ง blind spot การ tune มี trade-off
16. CVSS เป็น technical severity ไม่ใช่ risk acceptance decision
17. SIEM ไม่สร้าง evidence หาก log source ไม่ครบ ต้องทดสอบ end-to-end pipeline
18. Aggregation ไม่เท่ากับ correlation รวมข้อมูลได้แต่ยังไม่สร้างความหมาย
19. Log rotation ไม่เท่ากับ retention และ retention นานที่สุดไม่ดีเสมอ
20. Code coverage สูงไม่พิสูจน์ว่า test ดี ต้องดู assertion, path และ misuse case
21. SAST ไม่รันระบบ; DAST ทดสอบ runtime จากภายนอก IAST ต้องมี runtime test
22. SCA หา dependency risk ไม่พิสูจน์ business logic Manual review ยังจำเป็น
23. UI ซ่อนปุ่มไม่ใช่ authorization ต้องทดสอบ API และ interface อื่น
24. Backup job สำเร็จไม่พิสูจน์ restore ต้องทดสอบกู้คืนเทียบ RPO/RTO
25. Ticket ปิดไม่เท่ากับ finding ปิด ต้องมี closure evidence หรือ retest
26. Risk owner รับ residual risk Scanner, tester และ administrator ไม่มี authority โดยอัตโนมัติ
27. Type 1 เน้น design ณ จุดเวลา; Type 2 รวม effectiveness ตลอดช่วงเวลา
28. CMMI วัด process maturity ไม่ใช่ความปลอดภัยของ product โดยตรง
29. Maturity สูงไม่ใช่เป้าหมายทุกกรณี เลือกระดับตาม business objective และ risk
30. ถ้าโจทย์ถาม BEST ให้เลือก evidence ที่ตรง objective และน่าเชื่อถือพอโดยไม่ สร้าง operational หรือ safety risk เกินจำเป็น

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

• Domain 1: Security and Risk Management — ใช้ governance, policy, audit requirement, risk appetite, due care, supplier risk และ acceptance authority
• Domain 2: Asset Security — ใช้ inventory, classification, Data owner, retention, legal hold และ evidence handling กำหนด scope กับการปกป้องรายงาน
• Domain 3: Security Architecture and Engineering — ประเมิน trust boundary, defense in depth, cryptography, security model, fail securely, assurance และ safety ของ architecture
• Domain 4: Communication and Network Security — ทดสอบ segmentation, firewall, wireless, VPN, secure channel, management plane, detection และ network resilience
• Domain 5: Identity and Access Management — ทดสอบ provisioning/deprovisioning, access review, SoD, authorization bypass, MFA, federation, PAM และ orphaned account
• Domain 7: Security Operations — รับ finding ไปทำ configuration/patch/change, log monitoring, incident response, evidence, backup/restore, DR/BC และ retest
• Domain 8: Software Development Security — ฝัง code review, SAST/DAST/IAST/SCA, misuse case, interface, regression และ release gate ใน SDLC/CI-CD

Security Assessment and Testing ที่มีคุณภาพจึงไม่ได้วัดจากจำนวน scan หรือรายงาน แต่จากความสามารถตอบอย่างมีหลักฐานว่า control ใดถูกต้อง ทำงานจริง ครอบคลุม risk ใด มี limitation อะไร และใครต้องตัดสินหรือแก้ไขต่อ พร้อมทดสอบซ้ำจน residual risk อยู่ ในขอบเขตที่ผู้มี authority ยอมรับ