ทดสอบเจาะระบบตาม PCI DSS

หากองค์กรของคุณจัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลบัตรชำระเงิน PCI DSS ไม่ใช่ทางเลือก และการทดสอบที่มาตรฐานกำหนดก็เช่นกัน Requirement 11 ของมาตรฐาน ที่ว่าด้วย "การทดสอบระบบและกระบวนการด้านความปลอดภัยอย่างสม่ำเสมอ" มีอยู่เพราะสภาพแวดล้อมรอบข้อมูลผู้ถือบัตรไม่เคยหยุดนิ่ง ระบบใหม่ถูกนำขึ้นใช้งาน กฎ firewall เปลี่ยน network ไร้สายใหม่โผล่ขึ้นมา และช่องโหว่ใหม่ถูกเผยแพร่ทุกวัน มาตรการที่ยังได้ผลตอนประเมินเมื่อปีก่อน วันนี้อาจพังเงียบ ๆ ไปแล้ว คำตอบของมาตรฐานคือให้พิสูจน์ซ้ำไปเรื่อย ๆ ตามรอบเวลา พร้อมหลักฐานประกอบ ปัญหาในทางปฏิบัติที่องค์กรส่วนใหญ่เจอ ไม่ใช่ไม่รู้ว่าต้องทดสอบ แต่คือการทำการทดสอบให้ออกมาในแบบที่ QSA (Qualified Security Assessor) ยอมรับได้จริง นั่นคือวาง scope ให้ตรงกับ cardholder data environment (CDE) ใช้ระเบียบวิธีที่เป็นที่ยอมรับ และจัดทำเอกสารในรูปแบบที่แมปเข้ากับข้อกำหนดได้ชัดเจน รายงาน penetration test ทั่วไปที่ไม่พูดถึง 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 ไม่ได้จริง ๆ เรื่องนี้สำคัญทั้งในเชิงเทคนิคและเชิงธุรกิจ ข้อโต้แย้งเรื่องการลด scope ทั้งหมดของคุณ และต้นทุนการประเมินที่ตามมาจากมัน ตั้งอยู่บนเงื่อนไขว่า segmentation กั้นได้อยู่จริง

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

การสนับสนุน ASV scan

การสแกนช่องโหว่ภายนอกรายไตรมาสมีสถานะพิเศษในมาตรฐาน คือต้องรันโดย Approved Scanning Vendor บริษัทที่ได้รับการรับรองจาก PCI Security Standards Council ให้ทำการสแกนแบบนั้นโดยเฉพาะ Incognito Lab ไม่ใช่ ASV และเราจะไม่กลบความต่างตรงนี้ สิ่งที่เราทำคือเอาความยุ่งยากรอบ ๆ กระบวนการนั้นออกไป:

• การประสานงาน — เราช่วยคุณตั้งค่าและวางกำหนดการ ASV scan วาง external scope ให้ถูกต้อง และดูแลรอบรายไตรมาสไม่ให้พลาดสักช่วง จนกลายเป็นปัญหาโผล่ตอนประเมิน
• การแก้ไขช่องโหว่ — ผล ASV scan ออกมาเป็น finding ดิบ ๆ และการสแกนที่ไม่ผ่านจะบล็อกการปฏิบัติตามมาตรฐานของคุณ เราตีความผล แยกความเสี่ยงจริงออกจาก noise พาทีมคุณไล่แก้ทีละจุด และสนับสนุนการ rescan จนกว่าคุณจะได้ attestation ว่าผ่าน
• ความสอดคล้อง — ASV scan, internal scan และ penetration test ล้วนอธิบายสภาพแวดล้อมเดียวกัน เราทำให้ทั้งสามเล่าเรื่องเดียวกันแบบสอดคล้อง เพราะความไม่ลงรอยระหว่างกันคือสิ่งที่ผู้ประเมินจะจี้ถามพอดี

ผลลัพธ์คือ ตัวการสแกนดำเนินการโดย ASV ตามที่มาตรฐานกำหนด ส่วนทุกอย่างรอบ ๆ ทั้งการวาง scope การจัดกำหนดการ การแก้ไขช่องโหว่ และหลักฐาน จัดการไปด้วยกันกับคุณ ไม่ใช่โยนทิ้งไว้ให้เป็นการบ้าน

วิธีการทำงานของเรา

ภายใต้กรอบเฉพาะของ PCI DSS การทดสอบพื้นฐานก็คือชุดงานเดียวกับที่เราทำทุกวัน infrastructure penetration test ของเราครอบคลุมการทดสอบ network ทั้งภายในและภายนอก และ web application penetration test ครอบคลุม application ที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร ทั้งคู่วาง scope ตาม CDE และระบบที่เชื่อมต่อกับมัน ทุกงานเดินผ่านเฟสเดียวกันนี้:

1. Scoping — เราแมป CDE ไปกับคุณ ระบบไหนจัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร ระบบไหนเชื่อมต่อกับมัน เส้นแบ่ง segmentation อยู่ตรงไหน และงานนี้ต้องครอบคลุมกิจกรรมข้อไหนบ้างในสี่ข้อของ Requirement 11 ตรงนี้ยังเป็นจุดที่เราจูนให้ตรงกับไทม์ไลน์การประเมินของคุณ เพื่อให้ทั้งการทดสอบและการทดสอบซ้ำเสร็จก่อนที่ QSA จะต้องใช้หลักฐาน คุณจะได้ข้อเสนอที่มีไทม์ไลน์ชัดเจน ไม่มีการคิดเงินแบบปลายเปิด
2. Testing — external penetration test และ internal penetration test ตาม scope ที่ตกลงกัน wireless access point testing ทั่วทุกไซต์ของคุณ และ segmentation testing ที่ลงมือพยายามข้ามจาก network นอก scope เข้าไปยัง CDE จริง ๆ เครื่องมืออัตโนมัติช่วยเรื่องความครอบคลุม แต่ทุก issue ที่รายงานผ่านการยืนยันด้วยมือ ไม่มีผลดิบจาก scanner หลุดเข้าไปในรายงาน
3. Reporting — เขียน finding พร้อมขั้นตอนการทำซ้ำ ระดับความเสี่ยง และแนวทางแก้ไข วางกรอบเทียบกับข้อกำหนดที่แต่ละข้อกระทบ เพื่อให้เห็นชัดไม่ใช่แค่ว่าอะไรพัง แต่มันหมายความว่าอย่างไรต่อการประเมินของคุณ
4. Remediation support & retest — ทีมคุณแก้ finding เราคอยตอบคำถามระหว่างทาง จากนั้น retest และอัปเดตรายงานให้เห็นว่าปิดอะไรไปแล้วบ้าง สำหรับ PCI DSS ขั้นตอนนี้ไม่ใช่ของแถม หลักฐานว่าปัญหาที่พบถูกแก้และตรวจยืนยันซ้ำแล้ว เป็นส่วนหนึ่งของสิ่งที่ผู้ประเมินคาดหวังจะเห็น

สิ่งที่คุณได้รับ

เอกสารส่งมอบถูกจัดทำขึ้นเพื่อตอบสิ่งที่ QSA ต้องการ เป็นหลักฐานที่ผู้ประเมินรับไปใช้ในการประเมินได้ ไม่ใช่แค่รายงานเทคนิคที่บังเอิญเอ่ยถึง PCI DSS ทุกรายงานมีอย่างน้อย:

• Executive summary — ภาพความเสี่ยงระดับธุรกิจ เหมาะกับทั้งผู้บริหารและผู้ประเมินของคุณ
• Findings by Risk Level — แต่ละ issue ให้ระดับ Critical, High, Medium หรือ Low เพื่อจัดลำดับการแก้ไขได้อย่างมีหลักการ
• POC ประกอบทุก finding — ขั้นตอน request และหลักฐานที่ทำซ้ำ issue นั้นได้เป๊ะ วิศวกรของคุณไม่ต้องเดาว่าเราทำได้อย่างไร
• คำแนะนำการแก้ไข — วิธีแก้ที่ใช้ได้จริงกับสภาพแวดล้อมของคุณ ไม่ใช่ boilerplate จาก scanner
• หลักฐานการทดสอบซ้ำ — finding ถูกตรวจซ้ำหลังทีมคุณแก้ และรายงานอัปเดตให้สะท้อนรายการที่ปิดแล้ว ส่งมอบเส้นทาง "แก้แล้วและยืนยันแล้ว" ที่มาตรฐานคาดหวังให้ผู้ประเมิน
• หลักฐาน segmentation testing — เมื่อ segmentation อยู่ใน scope จะมีเอกสารชัดเจนว่าการควบคุมได้รับการทดสอบแล้ว และระบบนอก scope เข้าถึง CDE ไม่ได้

ทีมและใบรับรอง

การทดสอบทั้งหมดลงมือโดยทีมภายในของเราที่ถือใบรับรองระดับสากล ทั้ง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ใบรับรองที่ได้มาจากการสอบภาคปฏิบัติอย่างเข้มข้น ไม่ใช่ข้อสอบปรนัย ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

ระเบียบวิธีของเราอิงตาม NIST SP800-115 (Technical Guide to Information Security Testing and Assessment) โดยวาง scope รอบเวลา และการรายงานให้สอดคล้องกับ PCI DSS Requirement 11 ภายใต้มาตรฐาน v4.0.1 ฉบับปัจจุบัน แต่ penetration testing ก็เป็นเพียงหนึ่งในสิบสองข้อกำหนด ถ้าคุณยังอยู่ช่วงต้นของเส้นทาง ยังนิยาม CDE ไม่เสร็จ หรือกำลังสร้างโปรแกรมความปลอดภัยภาพใหญ่ที่มาตรฐานนี้ฝังอยู่ (นโยบาย, ISMS, ISO/IEC 27001) งานส่วนนั้นทีม consulting ของเราดูแลให้ การทดสอบพิสูจน์ว่าการควบคุมยังกั้นได้ในวันนี้ ส่วนตัวโปรแกรมคือสิ่งที่ทำให้มันกั้นได้ต่อเนื่องระหว่างการประเมินแต่ละครั้ง