กว่าที่เราจะสามารถ Certify PCI-DSS กันจนสำเร็จ
ในยุคของสังคมไร้เงินสด การทำธุรกรรมด้วยบัตร ไม่ว่าจะเป็นบัตรเดบิตหรือบัตรเครดิตในแต่ละปีมีปริมาณการใช้เพิ่มขึ้นอย่างมาก นำมาซึ่งความสะดวกสบาย การเติบโตทางเศรษฐกิจ และธุรกรรมด้านการเงินต่างๆ แต่ในขณะเดียวกันภัยทางด้าน Cybersecurity และการฉ้อโกงต่างๆ ก็เพิ่มขึ้นเป็นเงาตามตัว
เพื่อที่จะเป็นการสร้างมาตรฐานกลางให้การทำธุรกรรมด้วยบัตรต่างๆ นั้นมีความปลอดภัยใน Ecosystem เดียวกัน ในปี 2004 ทาง Card Brand ต่างๆ (ณ ปัจจุบัน มี VISA, Mastercard, AMEX, Discover, JCB โดย Unionpay ถือเป็น Strategic Member) ตัดสินใจจับมือกันออกมาตรฐาน PCI-DSS V1.0 ขึ้นมา
PCI คืออะไร?
PCI ย่อมาจาก Payment Card Industry ส่วน DSS ย่อมาจาก Data Security Standard ซึ่ง PCI Security Standards มีหลายตัวด้วยกัน (ดูรายละเอียดในภาพประกอบ)
ลักษณะทั่วไปของห่วงโซ่ของการทำธุรกรรมด้วยบัตรจะเริ่มตั้งแต่…
Step 1: Issuer (ธนาคารผู้ออกบัตร) อนุมัติบัตรให้ลูกค้า (Consumer) และมีการนำไปใช้งานกับ Merchant (ร้านค้า) และ Service Provider (ผู้ให้บริการ) เช่น นาย A นำบัตรที่ออกโดยธนาคาร K ไปซื้อสินค้าบนเว็บออนไลน์ ซึ่งมีการใช้บริการ Payment Gateway จากนั้นข้อมูลการทำธุรกรรมต่างๆ จะถูกส่งต่อมายังระบบหลังบ้านที่เชื่อมต่อกับ Payment Gateway นั้น
Step 2: ระบบงานหลังบ้านต่างๆ ไม่ว่าจะเป็นที่ Merchant หรือ Service Provider ใช้งานจะมีการจัดการพัฒนาระบบแอปพลิเคชันต่างๆ เพื่อรองรับการทำธุรกรรมโดย Vendor หรือ Solution Provider
Step 3: ข้อมูลการทำธุรกรรมต่างๆ จะวิ่งจาก Merchant และ Service Provider ไปยัง Acquirer (ธนาคารที่เป็นผู้ให้บริการกับร้านค้านั้นๆ) ข้อมูลธุรกรรมจะโดนส่งต่อไปยัง Card Brand ที่ลูกค้าใช้งานและ Issuer Bank เพื่อตรวจสอบธุรกรรมเพื่ออนุมัติหรือปฏิเสธรายการ
จากภาพจะเห็นได้ว่านอกจาก PCI-DSS ที่เราได้ยินกันบ่อยๆ คือ PCI-DSS นั้น PCI Standards ได้ถูกออกแบบมาให้ครอบคลุมทั้งห่วงโซ่ ตั้งแต่จุด Point-of-Sale ฮาร์ดแวร์ ที่เกี่ยวข้องกับการทำธุรกรรม (PIN Transaction Security) การ Transmit ข้อมูลต่างๆ การพัฒนาระบบแอปพลิเคชัน (Payment Application) และการจัดการระบบต่างๆ ไปจนถึงการประมวลผล การจัดเก็บข้อมูล และการแสดงข้อมูลธุรกรรมต่างๆ (Data Security Standard)
มาตรฐานต่างๆ ที่ออกมานั้นมีความสำคัญในแง่ของ Compliance ตามกฎของ PCI หรือ Card Brand ที่บังคับให้ผู้ที่เกี่ยวข้องใน Ecosystem นี้ต้องปฏิบัติตาม ทั้งยังมาพร้อมกับประโยชน์ในมุมอื่นๆ เช่น
- สร้างความเชื่อมั่นให้กับลูกค้าและการเติบโตของธุรกิจ เนื่องจาก PCI เป็นมาตรฐานกลางและมีการควบคุมอย่างจริงจัง มีร้านค้าและ Partner หลายแห่ง โดยเฉพาะ International Corporation เวลาที่จะทำธุรกรรมหรือเป็นพันธมิตรกับทางธนาคาร จะต้องขอดูหลักฐานการ Certify เพื่อให้มั่นใจว่าธนาคารได้มีการดูแลระบบอย่างเป็นมาตรฐาน
- เป็นพื้นฐานในการ Certify ไปยังมาตรฐานอื่นๆ ที่เกี่ยวข้อง นอกเหนือจาก PCI Standard ในตลาดยังมีไกด์ไลน์หรือมาตรฐานอื่นๆ เช่น ISO ที่ Regulator ต่างๆ เช่น ธนาคารแห่งประเทศไทย สำนักงานคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์บังคับให้ธนาคารต้องปฏิบัติตาม ซึ่งการปฏิบัติตาม PCI Standard สามารถเป็นจุดเริ่มต้นในการขยับไป Comply ได้อย่างไม่ยาก
- เสริมสร้างความปลอดภัยและป้องกันข้อมูลรั่วไหล อันเป็นหัวใจและวัตถุประสงค์หลักในการดูแลระบบไอทีต่างๆ ให้เป็นไปตามมาตรฐาน
แล้ว PCI DSS มีอะไรบ้างที่จำเป็นต้องปฏิบัติตาม?
PCI Requirements มีทั้งหมด 12 Requirements ด้วยกัน เพื่อให้ตอบทั้ง 6 เป้าหมาย ดังนี้
1. การสร้างและดูแลรักษาระบบเครือข่ายที่มั่นคงปลอดภัย รวมไปถึงในเรื่องของอุปกรณ์ หลักๆ จะเน้นไปที่ระบบเครือข่ายและอุปกรณ์เครือข่ายภายใน Environment โดยจะต้องมีการแบ่งโซนให้เป็นไปตามหลัก Security (Internal, DMZ, Untrusted Networks) และที่สำคัญ (มาก ๆ) โซนที่มีข้อมูลบัตรเครดิตจะต้องไม่เชื่อมต่อโดยตรงกับอินเทอร์เน็ตหรือ Wireless Network และในแต่ละโซนจะต้องมีการจำกัดการเข้าถึงโดย Firewall และมีการตั้งค่าตาม Security Baseline จำกัดการเข้าออกเฉพาะ Traffics ที่กำหนด อีกทั้งจะต้องมีการรีวิว Rulesets อย่างสม่ำเสมอ รวมไปถึงการเปิดใช้งาน Firewall บนเครื่องคอมพิวเตอร์ที่ใช้ในการรีโมทเข้าสู่ระบบที่เก็บข้อมูลบัตร
2. ไม่ใช้ค่าตั้งต้นจากผู้ผลิต (Vendor-Supplied Defaults) ไม่ว่าจะเป็นชื่อผู้ใช้ (Username) หรือรหัสผ่าน (Password) เนื่องจากค่าตั้งต้นจากผู้ผลิตนั้นสามารถหาได้โดยทั่วไปตามอินเทอร์เน็ตหรือเว็บไซต์ผู้ผลิต Product นั้นๆ และหากนำค่าตั้งต้นนั้นมาใช้ก็อาจมีความเสี่ยงจากการถูกโจมตีจากผู้ไม่ประสงค์ดี นอกจากการเปลี่ยนค่าตั้งต้นจากผู้ผลิตแล้ว การตั้งค่าระบบต่างๆ เช่น OS, Database และแอปพลิเคชันก็ให้เป็นไปตาม Security Baseline ยกตัวอย่างเช่น ไม่เปิด Ports ที่ไม่จำเป็น และโปรโตคอลที่มีความเสี่ยงต่อการถูกโจมตี และต้องมีการรีวิวการตั้งค่าอย่างสม่ำเสมอ นี่ถือเป็นตัวอย่างของค่าตั้งต้นที่ติดมากับอุปกรณ์
3. การปกป้องข้อมูลผู้ถือบัตร องค์กรควรกำหนดให้ใช้ หรือจัดเก็บข้อมูลเท่าที่จำเป็น ถ้าไม่ได้ใช้ก็ไม่มีความจำเป็นต้องจัดเก็บ PCI กำหนดว่าข้อมูลที่เป็น Sensitive Data เช่น PIN, CVV, Full Track Data ไม่ให้จัดเก็บในระบบ (หลังจากถูกใช้เพื่อพิสูจน์ตัวตน)
และสำหรับข้อมูลหมายเลขบัตร หากองค์กรมีความจำเป็นต้องเก็บ ก็จะต้องมีวิธีการปกป้องข้อมูลเหล่านั้นด้วย คือทำยังไงก็ได้ที่จะไม่ให้เห็นข้อมูลบัตรเครดิตหรือเดบิตทั้งหมด โดยให้เห็นเฉพาะบางส่วนเท่านั้น ยกตัวอย่างเช่นการเข้ารหัสข้อมูล (Encryption), Hashing, Truncation เป็นต้น ทั้งนี้ไม่ใช่แค่ข้อมูลบัตรที่เก็บบน Database เท่านั้น แต่ยังรวมไปถึงข้อมูลที่แสดงบนหน้าจอหรือกระดาษอีกด้วย และองค์กรจะต้องมีกระบวนการในการค้นหาและลบข้อมูลบัตรที่ไม่ได้ใช้งานในระบบอย่างสม่ำเสมออีกด้วย
4. เข้ารหัสลับข้อมูล ของผู้ถือบัตรระหว่างการส่งข้อมูลผ่าน Public Network นอกจากจะปกป้องข้อมูลบัตรที่เก็บอยู่ในระบบแล้ว ยังต้องปกป้องข้อมูลระหว่างการส่งอีกด้วย เช่น การส่งผ่านช่องทางที่มีการ Encrypt มีการใช้ Keys และ/หรือ Certificates ที่มาจากแหล่งที่น่าเชื่อถือ รวมถึงห้ามส่งข้อมูลบัตรผ่านช่องทาง SMS, Instant-Messaging หรืออีเมลที่ไม่มีการเข้ารหัสอย่างปลอดภัย
5. ติดตั้ง Antivirus สำหรับเครื่องเซิร์ฟเวอร์และ Clients ในระบบ และมีการอัพเดทซอฟท์แวร์และ Virus Signature อย่างสม่ำเสมอ
6. หมั่นพัฒนาและดูแลรักษาระบบและแอปพลิเคชันต่างๆ ให้มีความมั่นคงและปลอดภัย เช่น กระบวนการปิดช่องโหว่ของระบบ (Patch Management), กระบวนการพัฒนาแอปพลิเคชันอย่างปลอดภัยตามหลัก Security (Secure Development Life Cycle) แน่นอนว่าจะต้องรวมไปถึงการเขียนโค้ดอย่างปลอดภัยอีกด้วย พร้อมทั้งกิจกรรมภายใต้ข้อกำหนดนี้อย่างการจัดอบรม Secure Coding และการสแกน Source Code
7. จำกัดการเข้าถึงระบบ และข้อมูลผู้ถือบัตรเฉพาะผู้ที่จำเป็นต้องรู้ข้อมูลเท่านั้น โดยจะเป็นการกำหนดสิทธิ์การเข้าถึงตามความจำเป็นต่อ Roles และ Job Functions และองค์กรจะต้องมีกระบวนการในการกำหนดสิทธิ์เข้าถึงระบบต่างๆ (Access Control Process) รวมถึงการทบทวนสิทธิ์เหล่านั้นอย่างสม่ำเสมอ
8. กำหนดให้มีการพิสูจน์ตัวตน ก่อนการเข้าถึงระบบต่างๆ รวมถึงอุปกรณ์ POS (Point of Sale) เพื่อเป็นการบันทึกและระบุว่าใครเข้าสู่ระบบเวลาใดและทำกิจกรรมใดๆ
อีกทั้งยังกำหนดให้มีการใช้ MFA (Multi-Factor Authentication) ในการรีโมทเข้าสู่ระบบด้วยสิทธิ์แอดมิน ซึ่งก็คือการพิสูจน์ตัวตนมากกว่าการใช้เพียงแค่ชื่อผู้ใช้และรหัสผ่านในการล็อกอิน ยกตัวอย่างเช่น การใช้ OTP เป็นต้น การตั้งค่ารหัสผ่านก็ให้เป็นไปตามข้อกำหนด PCI เช่น สร้างบัญชีผู้ใช้
(User Account) เฉพาะรายบุคคล ไม่แชร์กัน ตั้งรหัสผ่านให้มีความซับซ้อน เป็นต้น
9. จำกัดการเข้าถึงข้อมูลบัตรทางกายภาพ (Physical Access Control) ไม่ว่าจะเป็นอุปกรณ์ POS Machine อุปกรณ์เน็ตเวิร์ค เซิร์ฟเวอร์ต่างๆ ใน Data Center ที่ต้องจัดให้เป็น Secure Area เช่น Data Center ที่จะมีการติดตั้ง CCTV, Log book ในการบันทึกข้อมูลผู้เข้าออกพื้นที่ และการเข้าออกพื้นที่จะต้องปฏิบัติตามกระบวนการทาง Physical Security ทั้งก่อนเข้าจนกระทั่งออกจากพื้นที่ รวมถึงสื่อบันทึกข้อมูลต่างๆ เช่น Backup Tape, HDD ที่เก็บข้อมูลบัตร โดยจะต้องตรวจเช็คเรื่องการจัดเก็บและกระบวนการทำลายสื่อบันทึกข้อมูลเหล่านั้นด้วย
10. มีการติดตามและตรวจสอบการเข้าถึงระบบและข้อมูลบัตร เช่น การบันทึกข้อมูลการเข้าออกระบบ การเข้าถึงข้อมูลบัตร กิจกรรมใดๆ ที่เกิดขึ้นจากสิทธิ์แอดมิน หรือแม้กระทั้งการตั้งค่า Audit Log เป็นต้น รวมถึงการบันทึกเหตุการณ์ (Events) ที่เกิดขึ้นในระบบ เช่น การพยายามล็อกอินเข้าระบบหลายครั้งแต่ไม่สำเร็จ การสร้างหรือลบไฟล์สำคัญของระบบ และนำมาวิเคราะห์ดูว่าเป็น Incident หรือไม่ รวมถึงการส่ง Alert ไปยังบุคคลที่เกี่ยวข้องเพื่อรับทราบและดำเนินการต่อหลังจากนั้น และแน่นอนว่าเมื่อพูดถึงเรื่อง Log ก็ต้องอย่าลืมตั้งค่า NTP ตามที่องค์กรกำหนดไว้ด้วย เพื่อให้เวลาในการบันทึกเหตุการณ์ต่างๆ เป็นไปอย่างถูกต้องและแม่นยำ
11. มีการดำเนินการทดสอบระบบด้าน security อย่างสม่ำเสมอ เช่น Penetration Test การสแกน VA และ ASV เพื่อหาช่องโหว่ของระบบ การสแกนเครือข่าย Wireless ไปจนถึงการตรวจจับการกระทำใดๆ ต่อระบบจากผู้ไม่มีสิทธิ์ เช่น ติดตั้ง IDS IPS เพื่อตรวจจับ Traffic ที่เข้ามาในระบบ หรือแม้แต่ภายในระบบเองก็ต้องมีการตรวจจับว่าไฟล์หรือการตั้งค่าของระบบสำคัญต่างๆ นั้น ไม่ได้ถูกเปลี่ยนแปลง อีกทั้งยังต้องทดสอบกระบวนการ Incident Response กรณีที่เจอเหตุการณ์ข้างต้นด้วย ยกตัวอย่างเช่น ตรวจจับการเข้าถึงระบบโดยไม่มีสิทธิ์ในเครือข่าย Wireless หรือมีการติดตั้ง Rogue Access Point เป็นต้น
12. จัดทำ Information Security Policy และประกาศให้ทุกคนในองค์กรรับทราบและปฏิบัติตามเพื่อปกป้องข้อมูลขององค์กร มีการจัดตั้งทีม Security และกำหนดหน้าที่ความรับผิดชอบไว้ชัดเจน ตัวอย่างนโยบายเช่น การใช้เทคโนโลยีต่างๆ ภายในองค์กรอย่างเหมาะสม การจัดการ Service Provider เป็นต้น กิจกรรมในข้อนี้ก็จะหลากหลาย ทั้งการทำ Awareness Training ซักซ้อมแผน Incident Response การประเมินความเสี่ยง และอื่นๆ
ถึงเวลา Certify กันแล้ว
หลังจากที่ได้เรียนรู้ Background และ Requirements ต่างๆ ของ PCI กันพอหอมปากหอมคอแล้ว เราลองมาดูกระบวนการที่จะ Certify มาตรฐานตัวนี้บ้างดีกว่า โดยจะขอแบ่งเป็น 3 ขั้นตอนง่ายๆ ดังนี้
Step 1: “กำหนดว่า Scope ที่เราจะ Certify นั้นอยู่ใน Merchant และ/หรือ Service Provider ระดับไหน ?”
อ้างอิงจากเว็บไซต์ของ VISA สมาชิกของ PCI SSC ได้กำหนดระดับของ Merchant (ร้านค้า) และ Service Provider (ผู้ให้บริการ) รวมถึง Validation Requirements ที่ต้องทำไว้ดังนี้
Merchant Level
Service Provider Level
หากสังเกตดีๆ เราจะเห็นว่า Level 1 ของทั้ง Merchant และ Service Provider มี Validation Requirements ที่ค่อนข้างซับซ้อนและยุ่งยาก ธนาคารกสิกรไทยเองก็จัดอยู่ในกลุ่มนี้อีกด้วย ดังนั้นเราจะมา Focus การ Certify Level 1 กัน
*หมายเหตุ: ผู้อ่านสามารถดูคำนิยามของ Merchant และ Service Provider ที่ PCI กำหนดไว้ได้จากเว็บไซต์ทางการของ PCI SSC ได้ที่ https://www.pcisecuritystandards.org/pci_security/glossary
Step 2: “ร่วมแรงร่วมใจ Implement!”
ขั้นตอนนี้เรียกง่ายๆ ว่าการ Implement ทุกอย่างที่อยู่ใน Scope ให้ Comply กับ PCI Requirement นั่นเอง และการกำหนด Scope ที่ถูกต้องและเหมาะสมนั้นแทบจะเรียกได้ว่าเป็นก้าวแรกที่จะชี้ชะตาว่าการทำ Certify นั้นๆ จะสำเร็จลุล่วงไปได้ด้วยดีหรือไม่ เนื่องจากเราต้องมาประเมินกันว่าระบบที่มีมาก่อนหน้านั้นมีอะไรบ้างที่จะต้องปรับให้เหมาะสมกับ Requirements
ซึ่งแน่นอนว่าทั้ง Technology Process และ People มีส่วนเกี่ยวข้องทั้งหมดอย่างไม่ต้องสงสัย ในบทความนี้เราอาจจะยังไม่ได้ลงลึกถึงแนวทางการ Implement เท่าไหร่ แต่จะมาพูดถึง Challenge ที่เจอในระหว่างการ Implement แทน
เนื่องจากตัวผู้เขียนมีส่วนร่วมในการดูแลภาพรวมแผนการ Implement มาตรฐานนี้ของธนาคาร ทำให้รู้ว่าแต่ละ Activity นั้นค่อนข้างจะ Challenge ในเรื่องของไทม์ไลน์ที่ค่อนข้างกระชั้น และเข้มงวดจากตัวมาตรฐานที่มีการกำหนดไว้ว่าจะต้องดำเนินการ Activity นั้นๆ ถี่แค่ไหน เช่น ต้องดำเนินการเป็นรายวัน (Daily) รายเดือน (Monthly) รายไตรมาส (Quarterly) รายปี (Annually) ตรงนี้จึงต้องวางแผนกันอย่างรอบคอบ เพื่อให้ทุกอย่างเป็นไปตามแผนที่กำหนด
รวมไปถึงการทำการ Certify มีความจำเป็นต้องประสานงานและได้รับความสนับสนุนจากหลายทีมงานมาก ความชัดเจนในเรื่องของหน้าที่และความรับผิดชอบนั้นเป็นจุดที่สำคัญ ทั้งนี้ในการปฏิบัติงานจริง มีหลายๆ Area ที่ไม่ได้มีการขีดเส้นอย่างชัดเจนว่าทีมงานไหนจะต้องเป็นผู้รับผิดชอบ เช่น ระบบงานต่าง ๆ มีการ Authenticate ด้วย Active Directory การดูแลความเรียบร้อย เรื่อง Access Control กลายเป็นว่าต้องมี 3 ทีมที่ต้องมาร่วมมือกัน ทั้ง System Owner ของระบบงาน, Admin ของ AD และ ทีม User ID เพราะฉะนั้นความชัดเจนในการทำงานว่าใครดูแลส่วนไหนจะทำให้สามารถทำงานได้สะดวกและมีผู้รับผิดชอบ (Accountability & Responsibility)
นอกจากนั้นแล้วยังเป็นเรื่องของความซับซ้อน (Complexity) ของ Scope ที่ต้องระมัดระวังเป็นพิเศษ เช่น เมื่อมีการเพิ่ม Components ต่างๆ ในแต่ละครั้งจำเป็นต้องทำให้มั่นใจว่า ถ้ามี Scope ที่เปลี่ยนแปลงไป ระบบนั้นๆ จะต้อง Comply กับ Requirement ด้วย
จาก Challenge ต่างๆ ที่เจอมาระหว่าง Implement ในท้ายที่สุดแล้ว ทีมงานทุกคนก็ช่วยกันผลักดันการ Implement จนได้รับการรับรองมาตรฐาน
ยิ่งไปกว่านั้น เราก็มีพี่ๆ ผู้บริหารคอยช่วยสนับสนุนเมื่อเจอ Challenge ในการ Implement ให้เดินหน้าต่อไปง่ายขึ้น สุดยอดไปเลย!!!
**หมายเหตุ: ผู้อ่านสามารถศึกษาแนวทางการ Implement เพื่อให้ Comply กับ PCI ได้จาก Website Official ของ PCI SSC ได้ที่ https://www.pcisecuritystandards.org/document_library
Step 3: “เข้าห้องเชือด เอ้ย ไม่ใช่ จ้าง PCI QSA มาตรวจ”
ในขั้นตอนนี้ต้องขอบอกก่อนว่าใช้ได้เฉพาะ Level 1 ตามที่บอกไปก่อนหน้าเท่านั้นนะ
QSA หรือ Qualified Security Assessor คือผู้ที่ได้รับการรับรองว่าสามารถตรวจสอบมาตรฐาน PCI DSS ได้ และมีใบอนุญาตให้สามารถลงนามตรวจ ROC ให้กับ Merchant, Issuing Bank, Acquiring Bank และ Service Provider ที่ให้บริการ ประมวลผล ส่งต่อและจัดเก็บข้อมูลบัตร
หน้าที่ของ QSA คือการมารีวิว Control ต่างๆ ตาม Requirement ของ PCI โดยทีมงานที่เกี่ยวข้องจะต้องช่วยกันเข้าร่วมสัมภาษณ์หรือจัดเตรียมเอกสาร ไม่ว่าจะเป็น Configuration ของระบบ Data Flow Diagram และอื่นๆ อีกมากมาย เพื่อรองรับการตรวจด้วย
โดยการตรวจจะใช้ระยะเวลาคร่าวๆ ประมาณ 3 เดือน แต่ก็จะเป็น 3 เดือนที่วุ่นวายมากของปี เพราะในหลายๆ ครั้ง ระหว่างการรีวิวจะเจอปัญหาที่ต้องจัดการเพิ่มเติม ทำให้ทีมงานต้องช่วยกันหา Solution ต่างๆ ในการ Mitigate ด้วยระยะเวลาอันสั้นนี้ ถือเป็นภาระที่หนักหน่วงของทีมงาน เพราะงาน Operation ปกติที่เป็น BAU ก็มีอยู่แล้ว ยังต้องมีอะไรที่ Super Urgent และมีเดดไลน์ของการตรวจขึงไว้เพิ่มเข้ามาอีก
หลังจากได้รับการตรวจสอบจาก QSA เสร็จเรียบร้อย เราจะได้รับเอกสารสำคัญจำนวน 2 ชุด เพื่อใช้ในการรับรองว่า Scope ที่เราได้รับการตรวจนั้นผ่าน PCI DSS แล้ว
- ROC (Report on Compliance) คือรายงานที่บันทึกผลการตรวจสอบ PCI DSS โดยละเอียดจาก QSA
- AOC (Attestation of Compliance) คือเอกสารสำหรับ Merchant และ Service Provider ที่ใช้ในการรับรองผลการตรวจสอบ PCI DSS (จริงๆ ติ๊ต่างได้ว่าเป็นใบ Certificate)
เมื่อมาถึงตรงนี้ก็เป็นอันสิ้นสุด 3 ขั้นตอนสุดหรรษาของการ Certify PCI กันแล้ว โดยขอย้ำอีกทีว่ามาตรฐาน PCI DSS นั้นต้องทำการตรวจ Re-Certify ทุกปี หากองค์กรของผู้อ่านอยู่ใน Level 1 เหมือนกันกับบทความนี้ ทางทีมงานก็จะต้อง Maintain การดำเนินการตามขั้นตอนที่ 2 และ 3 ในทุกๆ ปีไปเรื่อยๆ รับรองว่าสนุกแน่นอน 😁
การทำการ Certify เหล่านี้ไม่ได้เป็นกิจกรรมที่ทำเพียงครั้งเดียวแล้วจบ ความสำคัญคือการผสมผสานทั้งกระบวนการและเทคโนโลยีที่ต้องมีการจัดการให้ล้ำหน้าเป็นหนึ่งเดียว (💖 ONE Step Ahead, 💖 ONE Goal) และเราต้องมี People ที่ต้องร่วมมือร่วมใจ (💖 ONE Team) เข้ามาร่วมกันจัดการอย่างต่อเนื่อง (Continuously) เป็น BAU เพื่อให้กระบวนการ และ Control ต่างๆ ที่มีการวางไว้มีการปฏิบัติตามอย่างถูกต้อง ลุล่วงตามเป้าหมาย (💖 Number ONE) ที่วางไว้
FAQ คำถามที่โดนถามบ่อยๆ ระหว่าง Certify PCI
1. วิธีการจัดเก็บ PAN (Primary Account Number) ที่ถูกต้องตามมาตรฐาน PCI
จาก Requirement 3.2 ของ PCI DSS ระบุว่าเลข PAN นั้น ไม่ว่าจะถูกจัดเก็บไว้ ณ ที่ใดๆ ก็ตาม ต้องถูกเก็บในรูปแบบที่ไม่สามารถอ่านได้ โดยใช้วิธีต่อไปนี้
- One-Way Hashes (เลข PAN ทุก Digits) เช่น SHA-256
- Truncation (การเก็บเลข PAN เฉพาะบางส่วน ไม่เก็บทุกหลัก หรือแทนที่บางส่วนด้วยเครื่องหมายอื่นที่อ่านไม่ได้ เช่น แทนที่ 6 Digits ตรงกลางด้วยค่าอื่น และแสดงเฉพาะ First 6 Digits หรือ Last 4 Digits)
- Strong Encryption (การเข้ารหัสข้อมูลที่มีความปลอดภัยสูง) เช่น AES-256 ร่วมกับการบริหารจัดการ Key ที่มีประสิทธิภาพ
2. วิธีการ Display PAN ที่ถูกต้องตามมาตรฐาน PCI
จาก Requirement 3.3 ของ PCI DSS ระบุว่า First 6 Digits และ Last 4 Digits นั้นเป็นรูปแบบที่สามารถ Display ให้กับผู้ใช้เท่านั้น ไม่สามารถเปิดเผย Digits อื่นๆ ได้มากกว่านี้ ซึ่งหากจำเป็นต้องใช้จริงๆ ต้องระบุ Business Justification ในการใช้งานและขออนุมัติจากหัวหน้างาน หรือผู้มีอำนาจในการให้ใช้งานข้อมูลส่วนนี้เพื่อยอมรับความเสี่ยง
ตัวอย่างการ Display PAN ที่ถูกต้อง
- เลข PAN: 1234 5678 9012 3456
- เลข PAN ตอน Display: 1234 56xx xxxx 3456
3. วิธีการ Transmit CHD (Cardholder Data) ที่ถูกต้องตามมาตรฐาน PCI
จาก Requirement 4.1 ของ PCI DSS ระบุให้ใช้ Secure Protocol ในการปกป้องข้อมูลเหล่านี้เมื่อมีการส่งผ่าน Open และ/หรือ Public Network ซึ่ง Secure Protocol ที่นิยมใช้คือ TLS v1.2 ขึ้นไป
4. SAD คืออะไร
SAD หรือ Sensitive Authentication Data เป็นข้อมูลที่ใช้ยืนยันตัวตนหรือการทำ Authentication ในการซื้อสินค้าหรือบริการต่างๆ ประกอบไปด้วย
- Full Magnetic Stripe Data คือข้อมูลทั้งหมดในแถบแม่เหล็กหรือข้อมูลที่อยู่บนชิปสมาร์ทการ์ด
- CAV2/CVC2/CVV2/CID คือตัวเลข 3 หลัก พิมพ์อยู่ด้านหลังหรือด้านหน้า แล้วแต่ชนิดของบัตร
- PIN/PIN Block โดย PIN คือ Personal Identification Number คือรหัสลับ 6 หลักที่ผู้ออกบัตรกำหนดไว้เพื่อใช้ทำรายการธุรกรรมจากตู้ ATM ส่วน PIN Block คือ Block ที่ใช้ในปกป้องข้อมูล PIN ระหว่างการประมวลผล ซึ่งใน Block ของ PIN จะมีข้อมูล PIN ความยาวของ PIN และอาจจะมีส่วนย่อยของ PAN ประกอบอยู่ได้ด้วย
ตัวอย่างข้อมูลต่างๆ บนบัตร สามารถดูได้จากภาพด้านล่างนี้
คำศัพท์ที่มักจะพบบ่อย
AOC (Attestation of Compliance) ฟอร์มสำหรับ Merchants และ Service Providers ในการยืนยันผลการประเมิน PCI DSS โดยบันทึกอยู่ใน Self-Assessment Questionnaire หรือ Report on Compliance
ASV (Approved Scanning Vendors) บริษัทที่ได้รับการอนุมัติจาก PCI SSC ที่สามารถให้บริการในการทำ External Vulnerability Scan
BIN (Bank Identification Number) เลข 4–6 หลักแรกหน้าบัตร บางครั้งอาจเรียกว่า Institution Identification Number (IIN)
CDE (Cardholder Data Environment) Area ที่ต้องการจะป้องกันและควบคุม (รวมถึง People กระบวนการ และเทคโนโลยี)
CHD (Cardholder Data) เป็นส่วนที่ PCI DSS ให้ความสำคัญ ประกอบไปด้วย PAN ชื่อผู้ถือบัตร วันหมดอายุ และเลข CVC/CVV
CVC/CVV (Card Verification Code or Value) รหัสที่อยู่บนบัตรเครดิตมีไว้เพื่อการยืนยันตัวตนของผู้ถือบัตร
PAN (Primary Account Number) เลขบัญชีของบัตรนั้นๆ ที่ระบุอยู่บนบัตร
POS (Point of Sale) เครื่องหรือซอฟต์แวร์ที่ใช้ในการชำระเงินหรือทำธุรกรรมโดยใช้บัตร
QSA (Qualified Security Assessor) ผู้ที่ได้รับคุณวุฒิจาก PCI SSC ในการทำการประเมิน PCI DSS On-Site Assessment
ROC (Report of Compliance) Report ที่ระบุรายละเอียดของผลการประเมิน PCI DSS ขององค์กรนั้นๆ
SAD (Sensitive Authentication Data) ข้อมูลบนแถบแม่เหล็กหรือชิป CVC/CVV
บทความนี้เขียนโดย มุก ออม เป้
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
