ทดสอบเจาะระบบตาม PCI DSS
ครอบคลุมการทดสอบ network, application และ segmentation ตาม Requirement 11 พร้อมสนับสนุน ASV scan และเอกสารส่งมอบที่จัดทำเพื่อ QSA ของคุณ
หากองค์กรของคุณจัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลบัตรชำระเงิน คุณต้องทำตาม PCI DSS รวมถึงการทดสอบที่มาตรฐานกำหนด Requirement 11 ของมาตรฐาน ที่ว่าด้วย "การทดสอบระบบและกระบวนการด้านความปลอดภัยอย่างสม่ำเสมอ" มีอยู่เพราะสภาพแวดล้อมรอบข้อมูลผู้ถือบัตรไม่เคยหยุดนิ่ง ระบบใหม่ถูกนำขึ้นใช้งาน กฎ firewall เปลี่ยน network ไร้สายใหม่โผล่ขึ้นมา และช่องโหว่ใหม่ถูกเผยแพร่ทุกวัน มาตรการที่ยังได้ผลตอนประเมินเมื่อปีก่อน วันนี้อาจพังเงียบ ๆ ไปแล้ว คำตอบของมาตรฐานคือให้พิสูจน์ซ้ำไปเรื่อย ๆ ตามรอบเวลา พร้อมหลักฐานประกอบ องค์กรส่วนใหญ่รู้อยู่แล้วว่าต้องทดสอบ ที่ติดขัดคือการทดสอบให้ออกมาในแบบที่ QSA (Qualified Security Assessor) ยอมรับได้ ซึ่งต้องวาง scope ให้ตรงกับ cardholder data environment (CDE) ใช้ระเบียบวิธีที่เป็นที่ยอมรับ และจัดทำเอกสารในรูปแบบที่แมปเข้ากับข้อกำหนดได้ชัดเจน รายงานที่ไม่ครอบคลุม segmentation ไม่ระบุขอบเขต CDE หรือไม่มีหลักฐานการทดสอบซ้ำ อาจทำให้ผู้ประเมินขอให้ทำใหม่ ซึ่งอาจตรงกับช่วงใกล้เส้นตายการปฏิบัติตามมาตรฐานพอดี บริการ PCI DSS penetration test ของเราทดสอบตามที่ Requirement 11 เรียกร้อง และส่งมอบหลักฐานในรูปแบบที่ QSA ของคุณต้องการ
Incognito Lab เป็นพันธมิตรด้านการทดสอบเจาะระบบของคุณ เราไม่ใช่ QSA และไม่ได้ออก Report on Compliance ซึ่งเป็นหน้าที่ของผู้ประเมิน เราวาง scope การทดสอบตามแนวทางของมาตรฐาน ส่งมอบ finding ที่ทีมคุณแก้ได้จริง และเอกสารที่ผู้ประเมินใช้ประกอบการประเมินได้ ถ้าอยากเข้าใจโครงสร้างของมาตรฐานและบทบาทของแต่ละฝ่าย ทีมเราเขียนคู่มือไว้ที่ บทนำสู่ PCI DSS
Requirement 11 ต้องการอะไร
ภายใต้มาตรฐาน PCI DSS v4.0.1 ฉบับปัจจุบัน Requirement 11 กำหนดกิจกรรมการทดสอบไว้สี่แบบ แต่ละแบบมีรอบเวลาของตัวเอง บริการของเราครอบคลุมครบทั้งสี่:
Wireless access point testing
ตรวจหาทั้ง wireless access point ที่ได้รับอนุญาตและที่ไม่ได้รับอนุญาต (rogue AP) ทุกไตรมาส rogue access point ที่ถูกเสียบเข้ากับ network ที่เชื่อมต่อกับ CDE คือสะพานลัดข้ามแนวป้องกันของคุณตรง ๆ มาตรฐานจึงกำหนดให้ต้องไล่ตรวจอย่างสม่ำเสมอ แทนที่จะเชื่อว่ารายการอุปกรณ์ที่มีอยู่นั้นครบถ้วนถูกต้อง
Network vulnerability scan
ทำ vulnerability scan บน network ทั้งภายในและภายนอก อย่างน้อยทุกไตรมาสและหลังการเปลี่ยนแปลงสำคัญทุกครั้ง โดย external scan รายไตรมาสต้องดำเนินการโดย Approved Scanning Vendor (ASV) ที่ PCI รับรอง (ดูวิธีที่เราสนับสนุนได้ในหัวข้อถัดไป) ส่วนการสแกนภายในจะยืนยันว่าระบบภายในสภาพแวดล้อมของคุณได้รับการ patch และตั้งค่าตามที่มาตรฐานกำหนด
Penetration testing
external penetration test และ internal penetration test อย่างน้อยปีละครั้ง และหลังการอัปเกรดหรือแก้ไข infrastructure หรือ application ครั้งสำคัญทุกครั้ง ในข้อนี้ผู้ทดสอบทำได้มากกว่าผลของ scanner คือร้อยช่องโหว่หลายจุดเข้าด้วยกัน ยืนยันว่าโจมตีได้จริง และทดสอบ application กับ network ที่แตะข้อมูลผู้ถือบัตรแบบเดียวกับที่ผู้โจมตีจริงจะทำ
Segmentation testing
เมื่อมีการใช้ segmentation เพื่อกัน CDE ออกจาก network อื่น ตัวการควบคุม segmentation เองต้องผ่าน penetration test อย่างน้อยปีละครั้ง และหลังการเปลี่ยนแปลงทุกครั้ง เป้าหมายคือยืนยันว่า segmentation ทำงานได้จริงและมีผล ระบบที่คุณประกาศว่าอยู่นอก scope นั้นเข้าถึง CDE ไม่ได้จริง ๆ เหตุผลที่ใช้จำกัดขอบเขตการประเมิน และต้นทุนการประเมินที่ลดลงตามมา ล้วนขึ้นอยู่กับว่า segmentation กั้นได้จริง
หากคุณไม่แน่ใจว่าข้อไหนใช้กับสภาพแวดล้อมของคุณ หรือต้องทำในรอบเวลาแบบใด นั่นคือบทสนทนาเรื่อง scope ที่เราคุยกับคุณก่อนจะเขียนข้อเสนอ พื้นผิวที่จะไม่ทดสอบตกลงกันตั้งแต่ตอนวาง scope
การสนับสนุน ASV scan
การสแกนช่องโหว่ภายนอกรายไตรมาสมีสถานะพิเศษในมาตรฐาน คือต้องรันโดย Approved Scanning Vendor บริษัทที่ได้รับการรับรองจาก PCI Security Standards Council ให้สแกนแบบนั้นโดยเฉพาะ Incognito Lab ไม่ใช่ ASV สิ่งที่เราทำคือลดภาระรอบ ๆ กระบวนการนั้น:
การประสานงาน
เราช่วยคุณตั้งค่าและวางกำหนดการ ASV scan วาง external scope ให้ถูกต้อง และดูแลรอบรายไตรมาส เพื่อไม่ให้รอบที่ตกหล่นกลายเป็นปัญหาตอนประเมิน
การแก้ไขช่องโหว่
ผล ASV scan เป็นรายการ finding ดิบ และการสแกนที่ไม่ผ่านจะบล็อกการปฏิบัติตามมาตรฐานของคุณ เราตีความผล แยกช่องโหว่จริงออกจากผลบวกลวง พาทีมคุณไล่แก้ทีละจุด และสนับสนุนการ rescan จนกว่าคุณจะได้ attestation ว่าผ่าน
ความสอดคล้อง
ASV scan, internal scan และ penetration test ล้วนอธิบายสภาพแวดล้อมเดียวกัน เราจัดข้อมูลจากทั้งสามงานให้สอดคล้องกัน เพราะความไม่ลงรอยระหว่างกันคือสิ่งที่ผู้ประเมินจะหยิบขึ้นมาถาม
ASV เป็นผู้สแกนตามที่มาตรฐานกำหนด ส่วนการวาง scope การจัดกำหนดการ การแก้ไขช่องโหว่ และหลักฐาน เราทำไปกับคุณ
วิธีการทำงานของเรา
ภายใต้กรอบเฉพาะของ PCI DSS การทดสอบพื้นฐานก็คือชุดงานเดียวกับที่เราทำทุกวัน infrastructure penetration test ของเราครอบคลุมการทดสอบ network ทั้งภายในและภายนอก และ web application penetration test ครอบคลุม application ที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร ทั้งคู่วาง scope ตาม CDE และระบบที่เชื่อมต่อกับมัน ทุกงานเดินผ่านเฟสเดียวกันนี้:
Scoping
เราแมป CDE ไปกับคุณ ระบบไหนจัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร ระบบไหนเชื่อมต่อกับมัน เส้นแบ่ง segmentation อยู่ตรงไหน และงานนี้ต้องครอบคลุมกิจกรรมข้อไหนบ้างในสี่ข้อของ Requirement 11 ขั้นนี้เรายังจูนให้ตรงกับไทม์ไลน์การประเมินของคุณ เพื่อให้ทั้งการทดสอบและการทดสอบซ้ำเสร็จก่อนที่ QSA จะต้องใช้หลักฐาน
ข้อเสนอระบุไทม์ไลน์และราคาไว้ชัดเจน
Testing
external penetration test และ internal penetration test ตาม scope ที่ตกลงกัน wireless access point testing ทั่วทุกไซต์ของคุณ และ segmentation testing ที่ลงมือพยายามข้ามจาก network นอก scope เข้าไปยัง CDE จริง ๆ
เครื่องมืออัตโนมัติช่วยเรื่องความครอบคลุม แต่ทุก issue ที่รายงานผ่านการยืนยันด้วยมือ และรายงานไม่มีผลดิบจาก scanner
Reporting
เขียน finding พร้อมขั้นตอนการทำซ้ำ ระดับความเสี่ยง และแนวทางแก้ไข วางกรอบเทียบกับข้อกำหนดที่แต่ละข้อกระทบ เพื่อให้เห็นว่าอะไรพัง และส่งผลต่อการประเมินของคุณอย่างไร
Remediation support & retest
ทีมคุณแก้ finding เราคอยตอบคำถามระหว่างทาง จากนั้น retest และอัปเดตรายงานให้เห็นว่าปิดอะไรไปแล้วบ้าง
สำหรับ PCI DSS หลักฐานว่าปัญหาที่พบถูกแก้และตรวจยืนยันซ้ำแล้ว เป็นส่วนหนึ่งของสิ่งที่ผู้ประเมินคาดหวังจะเห็น
สิ่งที่คุณได้รับ
เราจัดทำเอกสารส่งมอบเพื่อตอบสิ่งที่ QSA ต้องการ เป็นหลักฐานที่ผู้ประเมินรับไปใช้ในการประเมินได้ ทุกรายงานมีอย่างน้อย:
Executive summary
ภาพความเสี่ยงระดับธุรกิจ เหมาะกับทั้งผู้บริหารและผู้ประเมินของคุณ
Findings by Risk Level
แต่ละ issue ให้ระดับ Critical, High, Medium หรือ Low เพื่อจัดลำดับการแก้ไขได้อย่างมีหลักการ
POC ประกอบทุก finding
request และหลักฐานของ issue นั้น พร้อมขั้นตอนทำซ้ำของแต่ละ finding อย่างละเอียด
คำแนะนำการแก้ไข
วิธีแก้ที่ใช้ได้จริงกับสภาพแวดล้อมของคุณ
หลักฐานการทดสอบซ้ำ
เราตรวจซ้ำ finding หลังทีมคุณแก้ และรายงานอัปเดตให้สะท้อนรายการที่ปิดแล้ว แสดงให้ผู้ประเมินเห็นว่า finding ถูกแก้และตรวจยืนยันซ้ำแล้ว ตามที่มาตรฐานคาดหวัง
หลักฐาน segmentation testing
เมื่อ segmentation อยู่ใน scope จะมีเอกสารชัดเจนว่าการควบคุมได้รับการทดสอบแล้ว และระบบนอก scope เข้าถึง CDE ไม่ได้
ทีมและใบรับรอง
- OSCP
- OSCE
- CREST CRT
- CREST CPSA
- GIAC GREM
งาน penetration test ดำเนินการโดยทีมภายในของเรา ใบรับรองเหล่านี้ได้มาจากการสอบภาคปฏิบัติ ดูใบรับรองทั้งหมดที่ทีมถือ
ระเบียบวิธีของเราอิงตาม NIST SP800-115 (Technical Guide to Information Security Testing and Assessment) โดยวาง scope รอบเวลา และการรายงานให้สอดคล้องกับ PCI DSS Requirement 11 ภายใต้มาตรฐาน v4.0.1 ฉบับปัจจุบัน
บริการที่เกี่ยวข้อง
Infrastructure penetration test
ครอบคลุมการทดสอบ network ทั้งภายในและภายนอก
Web application penetration test
ครอบคลุม application ที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร วาง scope ตาม CDE และระบบที่เชื่อมต่อกับมัน
Consulting
penetration testing เป็นเพียงหนึ่งในสิบสองข้อกำหนด ถ้าคุณยังอยู่ช่วงต้นของเส้นทาง ยังนิยาม CDE ไม่เสร็จ หรือกำลังสร้างโปรแกรมความปลอดภัยภาพใหญ่ที่มาตรฐานนี้ฝังอยู่ (นโยบาย, ISMS, ISO/IEC 27001) งานส่วนนั้นทีม consulting ของเราดูแลให้ การทดสอบยืนยันว่าการควบคุมกั้นได้ ณ วันนี้ ส่วนโปรแกรมความปลอดภัยทำให้กั้นได้ต่อเนื่องระหว่างการประเมินแต่ละครั้ง
ตรวจทานล่าสุด: 14 Oct 2026
ทดสอบเจาะระบบตาม PCI DSS
บอกเราว่ากิจกรรมไหนใน Requirement 11 ใช้กับสภาพแวดล้อมของคุณ เราแมป CDE ไปกับคุณ แล้วเสนอแผนที่ระบุไทม์ไลน์และราคาชัดเจน
คำถามที่พบบ่อย
ช่วยวาง scope ของ CDE ให้เราไหม?
ได้ การวาง scope เป็นขั้นที่กำหนดผลของงาน PCI ทั้งงาน เราจะวาง scope ของ CDE ไปด้วยกัน ระบุว่าระบบไหนเก็บ ประมวลผล หรือส่งผ่าน cardholder data ระบบไหนเชื่อมต่อกับระบบพวกนั้น เส้นแบ่ง segmentation อยู่ตรงไหน และงานนี้ต้องครอบคลุมกิจกรรมไหนใน Requirement 11 ทั้งสี่แบบ เรายังวางกำหนดการให้สอดคล้องกับรอบ assessment ของคุณ เพื่อให้ทั้ง penetration test และ retest เสร็จก่อนที่ QSA จะต้องใช้หลักฐาน
PCI DSS Requirement 11 กำหนดให้ทดสอบอะไรบ้าง?
ภายใต้ PCI DSS v4.0.1 Requirement 11 กำหนดกิจกรรมการทดสอบไว้สี่แบบ แต่ละแบบมีรอบเวลาของตัวเอง wireless access point testing หา rogue AP ทุกไตรมาส network vulnerability scan ทั้งภายในและภายนอกอย่างน้อยทุกไตรมาสและหลังการเปลี่ยนแปลงสำคัญ external และ internal penetration test อย่างน้อยปีละครั้งและหลังการเปลี่ยนแปลงสำคัญ และ segmentation testing อย่างน้อยปีละครั้ง (ทุกหกเดือนสำหรับ service provider) เมื่อใช้ segmentation กั้น CDE บริการของเราครอบคลุมครบทั้งสี่ ส่วน external scan รายไตรมาสดำเนินการโดย ASV ที่ได้รับการรับรอง ซึ่งเราเป็นผู้ประสานงาน
เอกสารส่งมอบจะได้รับการยอมรับจาก QSA ของเราไหม?
เอกสารส่งมอบถูกจัดทำขึ้นเพื่อตอบสิ่งที่ QSA ต้องการ เป็นหลักฐานที่ผู้ประเมินรับไปใช้ได้ finding แต่ละข้อวางกรอบเทียบกับข้อกำหนดที่มันกระทบ และหลักฐานการทดสอบซ้ำแสดงว่าปัญหาที่พบถูกแก้และตรวจยืนยันซ้ำแล้ว เป็นส่วนหนึ่งของสิ่งที่ผู้ประเมินคาดหวังจะเห็น
บทความที่เกี่ยวข้อง
ARTICLES/19 May 2025
มหาวิทยาลัยทักษิณ เดินหน้าสู่ ISO/IEC 27001:2022
อินค็อกนิโตแล็บร่วมโครงการพัฒนาระบบบริหารจัดการความมั่นคงปลอดภัยสารสนเทศของมหาวิทยาลัยทักษิณ ตามมาตรฐาน ISO/IEC 27001:2022 พร้อมงาน Cyber Drill และ Pentest
ARTICLES/12 Nov 2012
PCI DSS คืออะไร มาตรฐานความปลอดภัยข้อมูลบัตรชำระเงิน และข้อมูลที่เข้าข่าย
PCI DSS คือมาตรฐานความปลอดภัยข้อมูลบัตรชำระเงินที่เริ่มในปี 2006 โดยห้าค่ายบัตรใหญ่ บทความอธิบายที่มา ระบบแบบไหนเข้าข่าย และข้อมูลบัตรที่มาตรฐานนี้คุ้มครอง
เล่าให้เราฟังเรื่อง cardholder data environment ของคุณ
เราแมป CDE ไปกับคุณ แล้วเสนอแผนที่ระบุไทม์ไลน์และราคาชัดเจน
