PCI DSS v4.0.1: การประเมินช่องโหว่, ASV Scan, Pentest และ Segmentation Testing
มาตรฐานความมั่นคงปลอดภัยสำหรับองค์กรที่จัดเก็บ ประมวลผล ส่งผ่าน หรืออาจส่งผลต่อความปลอดภัยของข้อมูลบัตรชำระเงิน
- กลุ่มเป้าหมายที่บังคับใช้
- ผู้ประกอบการ, ธนาคาร, Payment Processor และ E-commerce ที่รับและจัดเก็บบัตรเครดิต
- ความถี่ในการทดสอบ
- สแกน VA ภายในและ ASV ภายนอกทุกไตรมาส (Req 11.3), Pentest ปีละ 1 ครั้ง (Req 11.4) และทดสอบ Segmentation ทุก 6-12 เดือน (Req 11.4.5/11.4.6)
- ขอบเขตการทดสอบ
- Cardholder Data Environment (CDE), Connected-to Systems, Payment APIs, Network Perimeter
- ความเสี่ยงหากไม่ปฏิบัติตาม
- ค่าปรับหรือผลจากการไม่ปฏิบัติตามขึ้นกับหลักเกณฑ์ของเครือข่ายบัตรที่เกี่ยวข้อง ต้องตรวจเงื่อนไขกับเครือข่ายบัตรและธนาคารผู้รับบัตร ไม่ใช่อัตราค่าปรับกลางที่ PCI SSC กำหนด
การวางแผนทดสอบตาม PCI DSS v4.0.1
จุดเริ่มต้นคือขอบเขต Cardholder Data Environment หรือ CDE และระบบที่อาจส่งผลต่อความปลอดภัยของ CDE ไม่ใช่เฉพาะหน้ารับชำระเงิน
Requirement 11.4 เชื่อม Methodology, CDE Scope, การทดสอบภายในและภายนอก การแก้ไข และ Retest เป็นหลักฐานชุดเดียว
- กำหนดวิธีทดสอบ — ใช้แนวทางที่อุตสาหกรรมยอมรับและบันทึก Methodology
- กำหนดขอบเขต — ครอบคลุม CDE Perimeter, Critical Systems และการควบคุมที่ใช้ลด Scope
- ทดสอบหลายมิติ — ทดสอบภายใน ภายนอก Application Layer, Network Layer และ Segmentation
- ใช้รอบที่กำหนด — ทดสอบอย่างน้อยทุก 12 เดือนและหลังการเปลี่ยน Infrastructure หรือ Application ที่มีนัยสำคัญ
- แก้ไขและทดสอบซ้ำ — แก้ช่องโหว่ตามความเสี่ยงและทำ Pentest ซ้ำเพื่อยืนยันผล
- เก็บหลักฐาน — เก็บผล Pentest และผลการแก้ไขไว้อย่างน้อย 12 เดือน
- จัดทำ Data Flow Diagram และ Asset Inventory เพื่อกำหนดขอบเขต CDE, Connected-to Systems และ Security-Impacting Systems อย่างแม่นยำ
- Requirement 11.3 กำหนดการสแกนช่องโหว่ภายในแบบ Authenticated Scan และการสแกนภายนอกผ่าน PCI SSC ASV ทุกไตรมาส (Quarterly)
- Requirement 11.4 กำหนดการทดสอบเจาะระบบทั้ง Network และ Application Layer ทั้งภายนอกและภายในอย่างน้อยทุก 12 เดือน พร้อม Retesting
- Requirement 11.4.5 และ 11.4.6 กำหนดการทดสอบยืนยันการแบ่งแยกเครือข่าย (Segmentation Verification) ทุก 12 เดือนสำหรับร้านค้า และทุก 6 เดือนสำหรับผู้ให้บริการ
PCI DSS v4.0.1 / CDE SCOPING & GOVERNANCE
โครงสร้างมาตรฐาน PCI DSS v4.0.1 และการกำหนดขอบเขต CDE
PCI DSS v4.0.1 กำหนดให้องค์กรระบุขอบเขต Cardholder Data Environment (CDE) และระบบทั้งหมดที่เชื่อมต่อหรือส่งผลต่อความมั่นคงปลอดภัยของข้อมูลบัตร ก่อนเริ่มกระบวนการทดสอบทางเทคนิค
การระบุขอบเขตอย่างถูกต้องเป็นรากฐานของการตรวจประเมิน หากระบบที่เชื่อมต่อกับ CDE ตกหล่น จะทำให้ขอบเขตการทดสอบและการรับรองล้มเหลวทันที
- 1. ระบุข้อมูลบัตรเป้าหมาย — จำแนก CHD (PAN, Expiry, Cardholder Name) และ SAD (CVV, PIN Blocks)
- 2. Cardholder Data Environment (CDE) — บุคลากร กระบวนการ เซิร์ฟเวอร์ และระบบที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลบัตร
- 3. Connected-to Systems — ระบบที่เชื่อมต่อกับ CDE ทั้งทางตรงและทางอ้อม มีเส้นทางเครือข่ายเข้าสู่ CDE ได้
- 4. Security-Impacting Systems — ระบบที่ส่งผลต่อความมั่นคงปลอดภัย เช่น Active Directory, Bastion Host, SIEM, Firewall
- 5. Out-of-Scope Systems — ระบบภายนอกที่ถูกตัดขาดการเชื่อมต่ออย่างสมบูรณ์ด้วย Segmentation ที่ผ่านการทดสอบ
- กลุ่มผู้มีหน้าที่ตามมาตรฐาน: ครอบคลุมร้านค้า (Merchants), สถาบันการเงินผู้รับบัตรและผู้ออกบัตร (Acquirers/Issuers), ผู้ประมวลผลธุรกรรม (Processors) และผู้ให้บริการ (Third-Party Service Providers - TPSPs) ที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร (Cardholder Data: CHD) หรือข้อมูลการพิสูจน์ตัวตนที่มีความละเอียดอ่อน (Sensitive Authentication Data: SAD)
- ขอบเขตของ CDE: ประกอบด้วยบุคลากร กระบวนการ และเทคโนโลยีที่จัดการข้อมูลบัตร รวมถึง Connected-to Systems (ระบบที่เชื่อมต่อกับ CDE) และ Security-Impacting Systems (ระบบที่ส่งผลต่อความปลอดภัยของ CDE เช่น Active Directory, Bastion Host, SIEM, Firewall)
- เส้นทางการประเมินตามระดับธุรกรรม: แบ่งตามปริมาณธุรกรรม (Levels 1 ถึง 4) ตั้งแต่การทำแบบประเมินตนเอง (Self-Assessment Questionnaire: SAQ A, A-EP, B, C, D) ไปจนถึงการตรวจรับรองหน้างานโดย Qualified Security Assessor (Report on Compliance: ROC)
- ผลบังคับใช้ของข้อกำหนด v4.0.1: ข้อกำหนดใหม่ใน v4.0.1 เช่น Authenticated Scanning (11.3.1.2), Targeted Risk Analysis (11.3.1.1), และ Multi-Tenant Testing Support (11.4.7) มีผลบังคับใช้อย่างสมบูรณ์แล้วตั้งแต่วันที่ 31 มีนาคม 2568
การจัดทำ Data Flow Diagram และ Asset Inventory ที่ถูกต้องตรงกับความเป็นจริงเป็นเงื่อนไขสำคัญที่สุด หากตกหล่นระบบที่เชื่อมต่อกับ CDE การตรวจประเมินของ QSA หรือการยื่น SAQ จะถือว่าไม่สอดคล้องกับมาตรฐาน
PCI DSS REQ 11.3 / VULNERABILITY ASSESSMENTS & ASV
ข้อกำหนด Vulnerability Assessment (VA) ภายใน และ ASV Scan ภายนอก (ข้อ 11.3)
Requirement 11.3 บังคับให้ตรวจหา จัดลำดับความสำคัญ และแก้ไขช่องโหว่ความปลอดภัยทางเทคนิคอย่างต่อเนื่อง โดยแยกเป็น 2 กระบวนการคู่ขนานระหว่างการสแกนระบบภายในและการสแกนจากภายนอกผ่าน ASV
Internal VA ต้องใช้ Authenticated Scan เพื่อมองเห็นช่องโหว่จริงภายในระบบ ส่วน External Scan ต้องใช้รายงานทางการจากผู้ให้บริการ ASV เท่านั้น
- 1. สแกนภายในด้วยสิทธิ์ (11.3.1.2) — ทำ Internal Authenticated Scan ทุกไตรมาสเพื่อตรวจลึกถึงระดับ OS และ Config
- 2. แก้ไขช่องโหว่ High / Critical — อุดช่องโหว่ระดับสูงตามเกณฑ์ข้อ 6.3.1 และจัดการความเสี่ยงต่ำตาม Targeted Risk Analysis (11.3.1.1)
- 3. Rescan ยืนยันปิดช่องโหว่ — สแกนซ้ำภายในกรอบเวลาที่กำหนดเพื่อยืนยันว่าไม่มีช่องโหว่ตกค้าง
- 4. สแกนภายนอกผ่าน ASV (11.3.2) — สแกนระบบ Internet-facing ทุกไตรมาสผ่าน Approved Scanning Vendor ที่รับรองโดย PCI SSC
- 5. เกณฑ์ Passing Scan รายไตรมาส — ต้องไม่มีช่องโหว่ CVSS ≥ 4.0 และไม่มีข้อบกพร่อง Automatic Failure ครบทั้ง 4 ไตรมาสต่อปี
- การประเมินช่องโหว่ภายใน (Internal VA: ข้อ 11.3.1): ต้องสแกนช่องโหว่เซิร์ฟเวอร์ อุปกรณ์เครือข่าย และระบบใน CDE อย่างน้อยทุก 3 เดือน (Quarterly) และต้องแก้ไขช่องโหว่ High และ Critical (ตามข้อ 6.3.1) ให้หมด พร้อมทำ Rescan เพื่อยืนยันว่าช่องโหว่ถูกปิดจริง
- ข้อกำหนด Authenticated Scanning (ข้อ 11.3.1.2): การสแกนภายในต้องใช้สิทธิ์ Credentialed Access ที่มีสิทธิ์เพียงพอ (Sufficient Privileges) เพื่อให้เครื่องมือสแกนสามารถเข้าถึงข้อมูลแพตช์และคอนฟิกภายใน OS ได้อย่างแม่นยำ หากมีอุปกรณ์ที่ไม่รองรับ Credentials ต้องทำเอกสารบันทึกเหตุผลและมาตรการชดเชย
- การจัดการช่องโหว่ความเสี่ยงปานกลางและต่ำ (ข้อ 11.3.1.1): ช่องโหว่ที่อยู่นอกเหนือจาก High/Critical ต้องได้รับการแก้ไขตามกรอบเวลาที่ระบุในเอกสาร Targeted Risk Analysis (TRA ตามข้อ 12.3.1)
- การสแกนภายนอกผ่าน Approved Scanning Vendor (ASV Scan: ข้อ 11.3.2): ระบบ Internet-facing และ External IP ทั้งหมดในขอบเขตหรือที่เชื่อมต่อกับ CDE ต้องได้รับการสแกนทุก 3 เดือน โดยหน่วยงานที่ได้รับการรับรองเป็น ASV จาก PCI SSC เท่านั้น
- เกณฑ์การตัดสินผ่านของ ASV (Passing Scan): ผลการสแกนจะผ่านได้เมื่อไม่มีช่องโหว่ที่มีคะแนน CVSS ตั้งแต่ 4.0 ขึ้นไป และไม่มีช่องโหว่กลุ่ม Automatic Failures (เช่น SQL Injection, XSS, Directory Traversal, หรือซอฟต์แวร์ Out-of-support) โดยต้องได้ใบรับรองผลผ่านครบ 4 ไตรมาสต่อปี
- การสแกนหลังการเปลี่ยนแปลงระบบสำคัญ (Significant Change: ข้อ 11.3.1.3 และ 11.3.2.1): ทุกครั้งที่มีการอัปเกรดโครงสร้างพื้นฐาน ปรับคอนฟิกไฟร์วอลล์ หรือติดตั้งซอฟต์แวร์ใหม่ที่มีนัยสำคัญ ต้องทำ Internal VA และ External Scan ซ้ำทันที
การทำ Internal VA สามารถดำเนินการโดยบุคลากรภายในที่มีความรู้และมีความเป็นอิสระทางองค์กร หรือผู้ให้บริการภายนอก แต่ External Scan ตามข้อ 11.3.2 บังคับว่าต้องใช้เครื่องมือและรายงานจาก PCI SSC Approved Scanning Vendor (ASV) เท่านั้น ห้ามใช้ผลสแกนจากเครื่องมือทั่วไปโดยไม่มีการรับรอง ASV
PCI DSS REQ 11.4 / PENETRATION TESTING
ข้อกำหนดการทดสอบเจาะระบบ (Penetration Testing: ข้อ 11.4)
Requirement 11.4 กำหนดให้ทำ Penetration Testing เพื่อจำลองการโจมตีเชิงรุก พิสูจน์ความสามารถในการเจาะผ่านระบบ และยืนยันว่าการควบคุมความปลอดภัยของ CDE ป้องกันการบุกรุกได้จริง
Pentest ต้องดำเนินการโดยผู้ทดสอบที่มีความเป็นอิสระทางองค์กร และต้องทำการ Retest เพื่อยืนยันว่าช่องโหว่ที่โจมตีได้ถูกปิดสนิทก่อนออกรายงานฉบับสมบูรณ์
- 1. ระเบียบวิธีและ Use Case (11.4.1) — อิงมาตรฐานสากล (NIST/OWASP/PTES) พร้อมนำประวัติภัยคุกคาม 12 เดือนมาร่วมออกแบบ
- 2. ทดสอบภายนอกและภายใน (11.4.2 & 11.4.3) — จำลองการโจมตี Perimeter และ Internal Attack เข้าสู่ CDE อย่างน้อยปีละ 1 ครั้ง
- 3. ครอบคลุม Network & Application — ทดสอบทั้งโครงสร้างพื้นฐานเครือข่าย และ Web Application/API ตามหมวดความเสี่ยงข้อ 6.2.4
- 4. แก้ไขและ Retesting (11.4.4) — อุดช่องโหว่ที่โจมตีได้จริง (Exploitable) และทำการทดสอบเจาะระบบซ้ำเพื่อยืนยันผล
- 5. เก็บหลักฐาน 12 เดือน — เก็บรวบรวมรายงานผล รายละเอียดการแก้ไข และหลักฐาน Retest เพื่อแสดงต่อผู้ตรวจประเมิน QSA
- ระเบียบวิธีทดสอบมาตรฐานสากล (Methodology: ข้อ 11.4.1): ต้องมีเอกสารและปฏิบัติตามแนวทางการทดสอบที่ยอมรับในอุตสาหกรรม (เช่น NIST SP 800-115, OWASP WSTG, PTES) ครอบคลุมทั้งแนวราบและแนวดิ่ง
- รอบการทดสอบภายนอกและภายใน (External & Internal Pentest: ข้อ 11.4.2 & 11.4.3): ต้องทดสอบทั้งจากภายนอกเครือข่าย (External Perimeter) และจากภายในเครือข่าย (Internal Network เข้าสู่ CDE และภายใน CDE) อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงระบบสำคัญ
- ครอบคลุม Network และ Application Layer: ทดสอบระบบเครือข่าย อุปกรณ์ไฟร์วอลล์ สวิตช์ ระบบปฏิบัติการ และเว็บแอปพลิเคชัน/API ที่จัดการธุรกรรมชำระเงิน ครอบคลุมช่องโหว่ตามข้อ 6.2.4 (Injection, Broken Access Control, Authentication Flaws ฯลฯ)
- การวิเคราะห์ประวัติภัยคุกคามรอบ 12 เดือน: แผนการทดสอบต้องนำข้อมูลภัยคุกคามและช่องโหว่ที่เกิดขึ้นจริงกับองค์กรหรืออุตสาหกรรมในช่วง 12 เดือนที่ผ่านมามาร่วมออกแบบ Use Case การทดสอบ
- การแก้ไขและการ Retest ยืนยันปิดช่องโหว่ (ข้อ 11.4.4): ช่องโหว่ที่สามารถใช้โจมตีได้จริง (Exploitable Vulnerabilities) ต้องได้รับการแก้ไข และต้องทำการทดสอบเจาะระบบซ้ำ (Retest) เพื่อยืนยันว่าการแก้ไขได้ผลจริงก่อนปิดรายงาน
- การเก็บรักษาหลักฐานไม่น้อยกว่า 12 เดือน: ต้องเก็บรายงานผลการทดสอบเจาะระบบ แผนปรับปรุงแก้ไข และหลักฐาน Retest ไว้อย่างน้อย 12 เดือน เพื่อแสดงต่อ QSA ในรอบการตรวจประเมิน
- ข้อกำหนดสำหรับ Multi-Tenant Service Providers (ข้อ 11.4.7): ผู้ให้บริการคลาวด์และโฮสติ้งที่มีลูกค้าหลายรายร่วมใช้ทรัพยากร ต้องสนับสนุนกระบวนการทดสอบ External Pentest ของลูกค้า (มีผลบังคับใช้แล้วตั้งแต่วันที่ 31 มีนาคม 2568)
ผู้ทดสอบเจาะระบบต้องมีความเป็นอิสระทางองค์กร (Organizational Independence) จากผู้ดูแลระบบและทีมนักพัฒนา แม้ไม่จำเป็นต้องถือใบรับรอง QSA หรือ ASV แต่ต้องมีคุณสมบัติและประสบการณ์ที่พิสูจน์ได้ เช่น OSCP, GPEN, หรือ CREST
PCI DSS REQ 11.4.5 / 11.4.6 / SEGMENTATION VERIFICATION
การทดสอบการแบ่งแยกเครือข่าย (Segmentation Verification Testing: ข้อ 11.4.5 & 11.4.6)
หากองค์กรใช้ Network Segmentation เพื่อลดขอบเขตการกำกับดูแล CDE มาตรฐานบังคับให้ต้องทดสอบเจาะระบบเพื่อยืนยันว่าระบบภายนอกขอบเขตไม่สามารถเชื่อมต่อเข้ามายัง CDE ได้จริง
การตรวจ Segmentation ต้องพิสูจน์ด้วยการส่งข้อมูลจริงจากภายนอกขอบเขต CDE ห้ามอิงเพียงเอกสารหรือกฎไฟร์วอลล์บนกระดาษโดยเด็ดขาด
- 1. ระบุจุดตัดแยกทุกรูปแบบ — ตรวจสอบไฟร์วอลล์, Router ACLs, VLANs, และ Microsegmentation ระหว่าง Out-of-Scope กับ CDE
- 2. ส่ง Packet Probing จากภายนอก — ยิง Port Scan และ Packet Probes จากเครือข่ายภายนอก (Corporate LAN, Wi-Fi, Dev) มุ่งสู่ CDE
- 3. พิสูจน์ Zero Ingress / Egress — ยืนยันว่าไม่มีพอร์ตหรือเส้นทางใดที่ยอมรับการเชื่อมต่อที่ไม่ได้รับอนุญาตเข้าสู่ CDE
- 4. รอบความถี่ตามประเภทองค์กร — ร้านค้า (Merchants) ทดสอบทุก 12 เดือน ส่วนผู้ให้บริการ (Service Providers) ทดสอบทุก 6 เดือน
- 5. การรับมือ Segmentation Failure — หากพบพอร์ตเปิด ระบบนั้นอาจต้องรวมในขอบเขต CDE ต้องแก้ไขไฟร์วอลล์และ Retest จนผ่าน
- หลักการทดสอบ Segmentation: ผู้ทดสอบจะส่งสัญญาณและสแกนพอร์ต (Port Scanning / Probing) จากเครือข่ายภายนอกขอบเขต CDE (เช่น Corporate LAN, Guest Wi-Fi, สาขา หรือระบบทดสอบ) ยิงตรงมายัง CDE เพื่อยืนยันว่าไม่มีการเปิดช่องทางรับส่งข้อมูลที่ไม่ได้รับอนุญาต
- ครอบคลุมทุกเทคโนโลยีการแบ่งแยก: ต้องทดสอบกลไกควบคุมการแยกส่วนทุกรูปแบบที่มีการใช้งานจริง เช่น ไฟร์วอลล์, Router ACLs, VLANs, Microsegmentation, และ Virtual Switch / Hypervisor Isolation
- รอบการทดสอบสำหรับร้านค้าและองค์กรทั่วไป (Merchants: ข้อ 11.4.5): ต้องทดสอบประสิทธิผลการแบ่งแยกเครือข่ายอย่างน้อยปีละ 1 ครั้ง และทุกครั้งที่มีการเปลี่ยนแปลงกลไกหรือโครงสร้างการแบ่งแยกเครือข่าย
- รอบการทดสอบสำหรับผู้ให้บริการ (Service Providers: ข้อ 11.4.6): สำหรับ Service Provider มาตรฐานกำหนดให้ต้องทดสอบ Segmentation อย่างน้อยทุก 6 เดือน (Semi-Annually) และทุกครั้งที่มีการเปลี่ยนแปลงกลไกแบ่งแยกเครือข่าย
- การแยกส่วนระบบตามระดับความปลอดภัย (ข้อ 2.2.3): ต้องทดสอบยืนยันว่าระบบที่มีฟังก์ชันหรือระดับความเสี่ยงต่างกันได้รับการแยกส่วนอย่างเด็ดขาด ไม่สามารถใช้เป็นจุดก้าวกระโดด (Lateral Movement) เข้าสู่ CDE ได้
- ผลของการเกิด Segmentation Failure: หากพบว่าระบบนอกขอบเขตสามารถเชื่อมต่อเข้าสู่ CDE ได้ ระบบนั้นจะตกเข้ามาเป็นขอบเขต CDE ทันที ซึ่งส่งผลกระทบอย่างรุนแรงต่อการตรวจรับรอง จนกว่าจะแก้ไขกฎไฟร์วอลล์และ Retest สำเร็จ
การทดสอบ Segmentation ไม่ใช่การตรวจดูเอกสารหรือกฎไฟร์วอลล์บนหน้าจอ แต่เป็นการส่ง Traffic จริงจากภายนอกขอบเขตเพื่อพิสูจน์ว่าพอร์ตและโปรโตคอลทั้งหมดถูกบล็อกตามนโยบาย Least Privilege
PCI DSS REQ 11 / TECHNICAL ASSURANCE TAXONOMY
ตารางเปรียบเทียบความแตกต่างระหว่าง VA, ASV Scan, Pentest และ Segmentation Testing
Requirement 11 กำหนดกลไกการทดสอบความปลอดภัย 4 รูปแบบที่มีเป้าหมาย ขอบเขต ความถี่ และข้อกำหนดผู้ทดสอบแตกต่างกันอย่างชัดเจน
| มิติการประเมิน | ข้อกำหนด | ขอบเขตระบบ (Scope) | ความถี่ในการทดสอบ | คุณสมบัติผู้ทดสอบ | เกณฑ์การผ่านผล (Passing Criteria) |
|---|---|---|---|---|---|
| Internal Vulnerability Assessment (VA) | Requirement 11.3.1 / 11.3.1.2 | ระบบ เซิร์ฟเวอร์ และอุปกรณ์เครือข่ายทั้งหมดภายในขอบเขต CDE | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงระบบสำคัญ | บุคลากรภายในที่มีความเป็นอิสระ หรือผู้เชี่ยวชาญภายนอก (ไม่จำเป็นต้องเป็น ASV หรือ QSA) | แก้ไขช่องโหว่ High และ Critical (ตามข้อ 6.3.1) ให้หมด และทำ Rescan ยืนยัน พร้อมทำ Authenticated Scan ตามข้อ 11.3.1.2 |
| External Vulnerability Scanning (ASV Scan) | Requirement 11.3.2 / 11.3.2.1 | ระบบและ IP ภายนอก (Internet-facing) ที่อยู่ในหรือเชื่อมต่อกับ CDE | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงระบบสำคัญ | PCI SSC Approved Scanning Vendor (ASV) เท่านั้น | ไม่มีช่องโหว่ CVSS ≥ 4.0 และไม่มีช่องโหว่กลุ่ม Automatic Failure โดยต้องได้ Attestation of Scan Compliance ครบ 4 ไตรมาสต่อปี |
| Penetration Testing (Internal & External) | Requirement 11.4.1 – 11.4.4 | ขอบเขต CDE Perimeter, Critical Systems, Network และ Application Layer | อย่างน้อยปีละ 1 ครั้ง (Annually) และหลังการเปลี่ยนแปลงระบบสำคัญ | ผู้ทดสอบเจาะระบบที่มีความเป็นอิสระทางองค์กร (ใบรับรองที่แนะนำ: OSCP, GPEN, CREST) | แก้ไขช่องโหว่ที่โจมตีได้ (Exploitable Vulnerabilities) ทั้งหมด และทำ Retest เพื่อยืนยันการปิดช่องโหว่ก่อนปิดรายงาน |
| CDE Segmentation Verification Testing | Requirement 11.4.5 & 11.4.6 | กลไกแบ่งแยกเครือข่ายทั้งหมด (Firewall, VLAN, ACL, Microsegmentation) ที่ตัดแยกระบบนอก CDE ออกจาก CDE | ร้านค้า: อย่างน้อยปีละ 1 ครั้ง | Service Provider: อย่างน้อยทุก 6 เดือน (และหลังเปลี่ยนระบบ) | ผู้ทดสอบเจาะระบบที่มีความเป็นอิสระทางองค์กร (ไม่จำเป็นต้องเป็น ASV หรือ QSA) | พิสูจน์ด้วยการส่ง Packet และ Scan Port จากเครือข่ายนอกขอบเขต แล้วพบว่าไม่สามารถเข้าถึง CDE ได้อย่างเด็ดขาด (Zero Ingress/Egress Unauthorized Access) |
ผู้ตรวจประเมิน QSA จะตรวจสอบหลักฐานแยกกันทั้ง 4 รายการ องค์กรไม่สามารถนำผล ASV Scan มาทดแทน Penetration Testing หรือนำรายงาน Pentest มาอ้างอิงแทนการทดสอบ Segmentation โดยเด็ดขาด
ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย
สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น
| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
|---|---|---|---|
| Requirement 11.3.1 | Internal Vulnerability Scanning (Authenticated Scan) | ระบบและเซิร์ฟเวอร์ภายในขอบเขต CDE ทั้งหมด | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงสำคัญ |
| Requirement 11.3.2 | External Vulnerability Scanning (ASV Scan) | ระบบ Internet-facing และ External IP ของ CDE | อย่างน้อยทุก 3 เดือน (Quarterly) โดย PCI SSC Approved Scanning Vendor |
| Requirement 11.4.2 & 11.4.3 | External & Internal Penetration Testing | ขอบเขต CDE Perimeter, Critical Systems, Network และ Application Layer | อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงสำคัญ |
| Requirement 11.4.4 | Remediation and Retesting of Exploitable Flaws | ช่องโหว่ความปลอดภัยที่ค้นพบจากการทำ Pentest | แก้ไขตามระดับความเสี่ยงและทำ Retest ซ้ำจนกว่าจะปิดช่องโหว่ |
| Requirement 11.4.5 | CDE Segmentation Verification Testing (Merchants) | Network Isolation ระหว่างระบบนอกขอบเขตและ CDE | อย่างน้อยปีละ 1 ครั้ง และหลังเปลี่ยนกลไกการแยกส่วน |
| Requirement 11.4.6 | CDE Segmentation Verification Testing (Service Providers) | Network Isolation และ Firewall Controls ของ Service Provider | ทุก ๆ 6 เดือน และหลังเปลี่ยนกลไกการแยกส่วน |
เครื่องมือประเมินความพร้อม
คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น
คำถามที่พบบ่อย (FAQ)
คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน
PCI DSS v4.0.1 ข้อ 11.4 กำหนดการทำ Penetration Testing ไว้อย่างไร?
Requirement 11.4 บังคับให้ทำ Penetration Testing ทั้งภายนอก (External) และภายใน (Internal) อย่างน้อยปีละ 1 ครั้ง และทุกครั้งที่มีการเปลี่ยนแปลงโครงสร้างพื้นฐานหรือแอปพลิเคชันอย่างมีนัยสำคัญ ครอบคลุมทั้ง Network และ Application Layer และต้องแก้ไขช่องโหว่ที่โจมตีได้พร้อมทำ Retest ยืนยันผล
การประเมินช่องโหว่ภายใน (Internal VA: ข้อ 11.3.1) มีข้อกำหนด Authenticated Scan อย่างไร?
ข้อ 11.3.1.2 ใน PCI DSS v4.0.1 (มีผลบังคับใช้อย่างสมบูรณ์ตั้งแต่ 31 มีนาคม 2568) กำหนดให้การสแกนช่องโหว่ภายในต้องใช้สิทธิ์ Credentialed Scan ที่มีสิทธิ์เพียงพอในการตรวจสอบระบบปฏิบัติการและซอฟต์แวร์ภายใน และต้องทำอย่างน้อยทุก 3 เดือน พร้อมแก้ไขช่องโหว่ High และ Critical
ASV Scan ตามข้อ 11.3.2 คืออะไร และมีเกณฑ์การตัดสินผ่าน (Passing Scan) อย่างไร?
ASV Scan คือการสแกนช่องโหว่ภายนอกผ่านเครือข่ายอินเทอร์เน็ตโดยหน่วยงานที่ได้รับการรับรองจาก PCI SSC (Approved Scanning Vendor) ต้องทำอย่างน้อยทุก 3 เดือน โดยเกณฑ์ผ่านคือต้องไม่มีช่องโหว่ที่ได้คะแนน CVSS ตั้งแต่ 4.0 ขึ้นไป และไม่มีช่องโหว่ประเภท Automatic Failure เช่น SQL Injection หรือ Unsupported Software
การทดสอบ CDE Segmentation Testing (ข้อ 11.4.5 & 11.4.6) ต้องทำบ่อยแค่ไหน และมีความสำคัญอย่างไรต่อการลด Scope?
หากองค์กรใช้ Network Segmentation เพื่อลดขอบเขต CDE ข้อ 11.4.5 กำหนดให้ร้านค้าและองค์กรทั่วไปต้องทดสอบยืนยันประสิทธิผลของการแยกเครือข่ายอย่างน้อยปีละ 1 ครั้งและหลังเปลี่ยนระบบ ส่วนข้อ 11.4.6 บังคับให้ Service Provider ต้องทดสอบอย่างน้อยทุก 6 เดือนและหลังเปลี่ยนระบบ เพื่อยืนยันว่าระบบนอก CDE ไม่สามารถเข้าถึงข้อมูลบัตรได้จริง
ความแตกต่างระหว่าง Vulnerability Assessment (VA), ASV Scan และ Penetration Testing คืออะไร?
VA และ ASV Scan (ข้อ 11.3) เป็นการสแกนแบบอัตโนมัติทุกไตรมาสเพื่อค้นหารายการช่องโหว่ที่รู้จัก (Known CVEs) ขณะที่ Penetration Testing (ข้อ 11.4) เป็นการจำลองการโจมตีเชิงรุกโดยผู้เชี่ยวชาญปีละ 1 ครั้ง เพื่อพิสูจน์การเจาะผ่านระบบและการขโมยข้อมูลบัตรจริง ส่วน Segmentation Testing เป็นการทดสอบเจาะระบบเพื่อพิสูจน์ความสมบูรณ์ของการตัดแยกเครือข่าย