องค์กรที่ทำ Security อยู่แล้วอาจยังไม่ผ่าน PCI DSS เพราะ PCI DSS ต้องการมากกว่าเครื่องมือป้องกัน แต่ต้องมี scope ที่ถูกต้อง การแมป control กับ 12 requirements หลักฐานประกอบ การทำงานอย่างต่อเนื่อง และการบริหารโครงการ compliance อย่างเป็นระบบ
ทำ Security แล้วไม่ผ่าน PCI DSS เพราะอะไร? 8 สาเหตุที่องค์กรควรรู้
หลายองค์กร ทำ Security แล้วไม่ผ่าน PCI DSS แม้จะลงทุนด้านความมั่นคงปลอดภัยไซเบอร์มาไม่น้อย ทั้ง Firewall, Endpoint Protection, SIEM, Vulnerability Scan, Penetration Test หรือ Security Policy ต่าง ๆ แต่เมื่อเข้าสู่การเตรียมความพร้อมด้าน PCI DSS กลับพบว่ายังมีช่องว่างจำนวนมาก และบางแห่งยังไม่สามารถผ่านการประเมินได้
เหตุผลสำคัญคือ PCI DSS ไม่ได้วัดแค่ว่าองค์กรมีเครื่องมือ Security หรือไม่ แต่ดูว่าองค์กรสามารถควบคุม ปฏิบัติ พิสูจน์ และรักษาความสอดคล้องกับข้อกำหนดของมาตรฐานได้จริงหรือไม่ ภายใต้ขอบเขตที่ถูกต้อง โดย PCI Security Standards Council ระบุว่า PCI DSS มีชุดทรัพยากรสนับสนุนจำนวนมาก ทั้งเรื่อง scoping, segmentation, SAQ, ROC, Prioritized Approach, Targeted Risk Analysis และ Business-as-Usual ใน PCI DSS v4.x ซึ่งสะท้อนชัดว่าการทำ compliance ต้องมองมากกว่าเครื่องมือเพียงอย่างเดียว
สำหรับองค์กรไทย ปัญหาที่พบบ่อยจึงไม่ใช่ “ไม่มี Security” แต่เป็น “มี Security แบบยังไม่เชื่อมกับข้อกำหนด PCI DSS อย่างเป็นระบบ”
PCI DSS ไม่ใช่แค่ Security แต่คือ Security ที่พิสูจน์ได้ตามมาตรฐาน
PCI DSS เป็นมาตรฐานที่ใช้กับองค์กรที่เก็บ ประมวลผล หรือส่งข้อมูลบัตร และรวมถึงหน่วยงานที่มีผลต่อความปลอดภัยของ Cardholder Data Environment (CDE) ด้วย โดยในชุดเอกสารและทรัพยากรของ PCI SSC มีทั้งมาตรฐานหลัก แบบประเมินตนเอง แนวทาง scoping/segmentation และเอกสาร supporting guidance สำหรับการนำไปใช้จริง
ดังนั้น การมีเครื่องมือ Security อยู่แล้ว ไม่ได้หมายความว่าองค์กรจะผ่าน PCI DSS อัตโนมัติ เพราะมาตรฐานต้องการมากกว่า “การมีอยู่” ของ control แต่ต้องการ ความครอบคลุม, ความสม่ำเสมอ, ความเหมาะสมกับ scope และหลักฐานประกอบ ด้วย
1) องค์กรทำ Security แบบ “ทั่วไป” แต่ไม่ได้ทำตามขอบเขต PCI DSS ที่ถูกต้อง
หนึ่งในสาเหตุหลักที่สุดคือองค์กรมีมาตรการ Security ทั่วไปอยู่แล้ว แต่ยังไม่ได้เริ่มจากการทำ PCI DSS scoping อย่างจริงจัง
หลายแห่งมีระบบป้องกันดีพอสมควร แต่ไม่รู้ชัดว่า
- ข้อมูลบัตรเข้ามาทางไหน
- ระบบใดอยู่ใน CDE
- ระบบใดเชื่อมต่อหรือมีผลกระทบต่อ CDE
- พนักงานหรือ third party กลุ่มใดเข้าถึงระบบเหล่านั้นได้
PCI SSC ให้ความสำคัญกับเรื่อง Scoping and Segmentation Guidance โดยเฉพาะ เพราะหากกำหนด scope ผิด องค์กรอาจป้องกันไม่ครบ หรือทำ controls ไม่ตรงจุดตั้งแต่ต้น
พูดง่าย ๆ คือ บางองค์กร “ปลอดภัย” ในภาพรวม แต่ยังไม่ปลอดภัย “ตรงขอบเขตที่ PCI DSS สนใจ”
2) มีเครื่องมือครบ แต่ control ไม่ได้ทำงานอย่างสม่ำเสมอ
อีกปัญหาที่พบมากคือองค์กรมีเครื่องมือหรือระบบหลายอย่างอยู่แล้ว แต่ไม่สามารถแสดงได้ว่า control เหล่านั้นถูกใช้งานอย่างต่อเนื่องและสม่ำเสมอ เช่น
- มี log แต่ไม่ได้ทบทวนตามรอบ
- มีการสแกน แต่ไม่ติดตาม remediation จนจบ
- มี MFA หรือ access control แต่มี exception มาก
- มี secure configuration แต่ไม่ได้ตรวจสอบสม่ำเสมอ
- มี policy แต่การใช้งานจริงไม่ตรงกับเอกสาร
PCI DSS v4.x ให้ความสำคัญกับเรื่อง Business as Usual, Targeted Risk Analysis และการรักษาความพร้อมอย่างต่อเนื่อง ไม่ใช่แค่เตรียมเฉพาะตอนจะถูกประเมิน
นั่นทำให้หลายองค์กรที่ดูเหมือน “มี Security” ยังไม่ผ่าน เพราะยังขาด operational discipline และ evidence ที่ต่อเนื่อง
3) มี Security Control แต่ไม่มีเอกสารและหลักฐานรองรับ
การประเมิน PCI DSS ไม่ได้พิจารณาแค่สภาพแวดล้อมเชิงเทคนิค แต่ต้องอาศัย documentation และ evidence ประกอบจำนวนมาก เช่น policy, standard, network diagram, data flow, access record, vulnerability evidence, change record และหลักฐานการทบทวนกิจกรรมต่าง ๆ
จุดนี้เป็นช่องว่างสำคัญมากในหลายองค์กร เพราะ control บางอย่างมีอยู่จริง แต่ไม่มีหลักฐานที่ชี้ได้ชัดว่า
- ใครรับผิดชอบ
- ทำเมื่อไร
- ทำอย่างไร
- ตรวจสอบผลอย่างไร
- มี exception หรือ remediation อย่างไร
หลักสูตร PCI – Introduction to PCI DSS Implementation Training ของ ACIS เองก็ระบุหัวข้อ Documentation and evidence, Managing a PCI DSS project และ How to gain compliance ไว้อย่างชัดเจน ซึ่งสะท้อนว่าการผ่าน PCI DSS ต้องอาศัยการจัดการเอกสารและโครงการควบคู่กับเรื่องเทคนิค
4) องค์กรมอง PCI DSS เป็นงานของฝ่าย Security หรือ IT เพียงฝ่ายเดียว
หลายองค์กรเริ่มต้นจากการโยนเรื่อง PCI DSS ให้ทีม IT Security ดูแลทั้งหมด ทั้งที่ในความเป็นจริง มาตรฐานนี้เกี่ยวข้องกับหลายส่วนงาน เช่น operations, application owner, infrastructure, network, compliance, internal audit, procurement และผู้บริหารที่เกี่ยวข้องกับการตัดสินใจเรื่อง risk และ resource
ผลคือเกิดปัญหาแบบนี้บ่อย
- ทีมเทคนิครู้ requirement แต่ธุรกิจไม่สนับสนุน
- มี control ในระบบ แต่ process หน้างานยังไม่รองรับ
- third-party ไม่ถูกบริหารในมุม PCI DSS
- เอกสารและหลักฐานกระจัดกระจายอยู่หลายทีม
ACIS ระบุว่าบริการ consulting ของบริษัทครอบคลุม People, Process and Technology ซึ่งตรงกับลักษณะของโครงการ PCI DSS มาก เพราะปัญหามักไม่ได้อยู่ที่เทคโนโลยีอย่างเดียว
5) มี Security อยู่แล้ว แต่ไม่ได้แมปกับ 12 Requirements ของ PCI DSS
อีกสาเหตุสำคัญคือองค์กรมี Security controls หลายตัว แต่ไม่ได้แปล control เหล่านั้นให้เชื่อมกับ 12 requirements ของ PCI DSS อย่างชัดเจน
ตัวอย่างเช่น
- มี firewall แต่ segmentation ยังไม่ชัด
- มี endpoint security แต่ secure configuration ยังไม่สอดคล้อง requirement
- มี IAM แต่ access review ยังไม่เป็นรอบ
- มี monitoring แต่ log review กับ alert handling ยังไม่ครบ
- มี vulnerability management แต่หลักฐานและความถี่ไม่ตรง requirement
หลักสูตร PCI ของ ACIS ระบุหัวข้อ The In-depth 12 Requirements, Practical implications of the PCI DSS และ How to scope for the PCI DSS ซึ่งสะท้อนว่าองค์กรต้องเข้าใจทั้งตัวมาตรฐานและผลกระทบเชิงปฏิบัติ ไม่ใช่แค่เชื่อว่ามีเครื่องมือแล้วน่าจะเพียงพอ
6) เลือกแนวทางประเมินหรือรูปแบบการปฏิบัติไม่เหมาะกับบริบทตัวเอง
PCI SSC มีทั้ง SAQ, ROC Template, guidance ต่าง ๆ และ supporting documents สำหรับหลายบริบทขององค์กร หากองค์กรเลือกแนวทางผิดตั้งแต่ต้น เช่น เข้าใจขอบเขตตัวเองคลาดเคลื่อน หรือเลือกแบบประเมินที่ไม่ตรงกับวิธีรับชำระเงินจริง ก็อาจทำให้การเตรียมความพร้อมผิดทิศทางได้
ในหลายกรณี องค์กรไม่ได้ “ไม่ปลอดภัย” แต่ “เตรียมผิดเฟรม” ทำให้ทำงานหนักแต่ยังไม่ตอบ requirement ที่ถูกต้อง
7) ขาดการลำดับความสำคัญและการบริหารโครงการอย่างเป็นระบบ
องค์กรจำนวนไม่น้อยเริ่มทำ PCI DSS แบบเก็บ requirement ทีละข้อโดยไม่มี roadmap ชัด ทำให้เกิดปัญหา เช่น
- ทำงานซ้ำ
- ใช้ทรัพยากรเกินจำเป็น
- แก้ปลายเหตุแทนแก้รากของปัญหา
- เริ่มจาก control ที่ยากก่อน ทั้งที่ควรเริ่มจาก scope และ gap
- ทีมงานเหนื่อย แต่ภาพรวมไม่เดินหน้า
PCI SSC มี Prioritized Approach เป็นหนึ่งในทรัพยากรสนับสนุนสำหรับ PCI DSS v4.x และหลักสูตรของ ACIS ก็ระบุเรื่อง Managing a PCI DSS project และ The PCI Prioritized Approach Tool ไว้ชัดเจน
นั่นแปลว่า การผ่าน PCI DSS ต้องอาศัย “project governance” พอ ๆ กับ security governance
8) ยังไม่พร้อมกับ requirement เชิงต่อเนื่องของ PCI DSS v4.x
PCI DSS v4.x เพิ่มน้ำหนักให้กับเรื่อง Targeted Risk Analysis, Customized Approach และการรักษาความพร้อมเชิงปฏิบัติอย่างต่อเนื่องมากขึ้น โดย PCI SSC ออก guidance และ sample templates เพื่อช่วยองค์กรนำแนวคิดเหล่านี้ไปใช้จริง
สำหรับหลายองค์กร นี่คือจุดที่ทำให้รู้สึกว่า “เราก็มี Security อยู่แล้วนะ” แต่ยังติดข้อกำหนด เพราะมาตรฐานรุ่นใหม่ต้องการให้ control มีเหตุผลรองรับ วัดผลได้ และทำซ้ำได้อย่างเป็นระบบ ไม่ใช่ทำแบบ ad hoc
สรุปให้ชัด: ทำไมมี Security แล้ว แต่ยังไม่ผ่าน PCI DSS
เหตุผลหลักมักสรุปได้แบบนี้
- ทำ Security โดยยังไม่ทำ scoping ให้ถูก
- มี control แต่ไม่สม่ำเสมอ
- มีระบบแต่ไม่มี documentation/evidence
- มองว่าเป็นงานของ IT อย่างเดียว
- ไม่ได้แมป control กับ 12 requirements
- เลือกแนวทางประเมินไม่ตรงบริบท
- ขาด roadmap และ project management
- ยังไม่พร้อมกับแนวคิดต่อเนื่องใน PCI DSS v4.x
ดังนั้น “Security” กับ “PCI DSS compliance” จึงไม่ใช่เรื่องเดียวกันทั้งหมด แม้จะเกี่ยวข้องกันอย่างใกล้ชิด
องค์กรควรเริ่มต้นอย่างไร หากมี Security อยู่แล้วแต่ยังไม่พร้อมสำหรับ PCI DSS
แนวทางที่เหมาะสมมักเริ่มจาก 4 ขั้นหลัก
1) ตรวจ scope ให้ชัด
เริ่มจาก payment flow, CDE, connected systems และผู้เกี่ยวข้องทั้งหมดก่อนเสมอ เพราะนี่คือฐานของทุก requirement
2) ทำ gap analysis เทียบ requirement จริง
อย่าประเมินจากความรู้สึกว่าระบบ “น่าจะพอ” แต่ควรแมป controls ที่มีอยู่กับข้อกำหนด PCI DSS ทีละเรื่อง
3) เก็บหลักฐานและจัด owner ให้ชัด
control ที่ไม่มี owner และไม่มี evidence มักใช้ผ่านการประเมินไม่ได้ในทางปฏิบัติ
4) วาง roadmap แบบ People, Process, Technology
โครงการจะเดินได้เร็วกว่า หากมองทั้งเรื่องคน กระบวนการ และเทคโนโลยีไปพร้อมกัน ซึ่งเป็นแนวทางที่สอดคล้องกับบริการ consulting ของ ACIS
ACIS Professional Center ช่วยองค์กรเรื่อง PCI DSS ได้อย่างไร
ACIS Professional Center ระบุว่าบริษัทให้บริการ training services และ consulting services ในด้าน information technology, cybersecurity, IT Governance, ITSMS, information security และ business continuity โดยครอบคลุม People, Process and Technology และมีประสบการณ์ให้บริการทั้งภาครัฐและเอกชน
ในมุมของบริการที่ปรึกษา แนวทางของ ACIS เหมาะกับองค์กรที่ “มี Security อยู่แล้ว แต่ยังไม่แน่ใจว่าช่องว่าง PCI DSS อยู่ตรงไหน” เพราะสามารถช่วยได้ในประเด็นสำคัญ เช่น
- ประเมิน scope และ payment flow
- วิเคราะห์ gap เทียบข้อกำหนด PCI DSS
- จัดลำดับ remediation ให้เหมาะกับทรัพยากรองค์กร
- ช่วยเตรียม documentation และ evidence
- ช่วยให้ทีมต่าง ๆ เข้าใจบทบาทของตัวเองในโครงการ
- สนับสนุนการยกระดับความพร้อมสู่ compliance อย่างเป็นระบบ
นอกจากนี้ ACIS Academy ยังมีหลักสูตร PCI – Introduction to PCI DSS Implementation Training ซึ่งครอบคลุมหัวข้อสำคัญ เช่น scoping, scope reduction, 12 requirements, documentation and evidence, managing a PCI DSS project, how to gain compliance, PCI Prioritized Approach Tool และ business as usual จึงเหมาะทั้งสำหรับทีมงานที่เริ่มต้นและองค์กรที่ต้องการจัดระเบียบโครงการให้ชัดขึ้น
หากองค์กรต้องการประเมินช่องว่างก่อนเข้าสู่การประเมินจริง สามารถเริ่มจากบริการ Cybersecurity Consulting ของ ACIS เพื่อวิเคราะห์ scope, gap และ readiness ของ PCI DSS ได้อย่างเป็นระบบ https://www.acisonline.net/?page_id=55683
สรุป
หลายองค์กรทำ Security อยู่แล้ว แต่ยังไม่ผ่าน PCI DSS เพราะมาตรฐานนี้ไม่ได้วัดแค่ว่ามีเครื่องมือหรือไม่ แต่ดูว่าองค์กรสามารถกำหนด scope ได้ถูกต้อง แมป controls เข้ากับ requirement ได้ครบ ดำเนินงานได้สม่ำเสมอ และมีหลักฐานรองรับเพียงพอหรือไม่ ภายใต้แนวคิดการรักษาความพร้อมอย่างต่อเนื่องของ PCI DSS v4.x
หากองค์กรของคุณมี Security foundation อยู่แล้ว นั่นถือเป็นต้นทุนที่ดีมาก แต่ขั้นต่อไปคือการแปลง foundation นั้นให้กลายเป็น PCI DSS readiness อย่างเป็นระบบ
ACIS Professional Center พร้อมสนับสนุนองค์กรด้วยบริการที่ปรึกษาและการพัฒนาศักยภาพ เพื่อช่วยให้การทำ PCI DSS ไม่ใช่แค่ “มี Security” แต่เป็น “พร้อมสู่ Compliance” อย่างแท้จริง
FAQ
ทำไมองค์กรมี Security อยู่แล้ว แต่ยังไม่ผ่าน PCI DSS
เพราะ PCI DSS ไม่ได้พิจารณาแค่ว่ามีเครื่องมือ Security หรือไม่ แต่พิจารณาเรื่อง scope, requirement mapping, documentation, evidence, operational consistency และการรักษาความพร้อมอย่างต่อเนื่องด้วย
PCI DSS ต่างจากการทำ Security ทั่วไปอย่างไร
Security ทั่วไปมักเน้นการป้องกันเชิงเทคนิค แต่ PCI DSS เป็นมาตรฐาน compliance ที่ต้องการทั้ง controls, กระบวนการ, เอกสาร, หลักฐาน และการประเมินภายใต้ขอบเขตที่กำหนดถูกต้อง
Documentation สำคัญกับ PCI DSS แค่ไหน
สำคัญมาก เพราะ control ที่ไม่มีเอกสารและหลักฐานรองรับ มักไม่เพียงพอสำหรับการพิสูจน์ compliance ในทางปฏิบัติ และหัวข้อนี้ก็เป็นส่วนหนึ่งของหลักสูตร PCI ของ ACIS โดยตรง
องค์กรควรเริ่มจากอะไรหากยังไม่ผ่าน PCI DSS
ควรเริ่มจากการทำ scoping ให้ชัด, ประเมิน gap เทียบ requirement จริง, จัด owner และ evidence ให้ครบ และวาง roadmap remediation อย่างเป็นระบบ
ACIS Professional Center ช่วยเรื่อง PCI DSS อย่างไร
ACIS ให้บริการ training และ consulting ด้าน cybersecurity, IT Governance, information security และมีหลักสูตร PCI DSS Implementation Training ที่ครอบคลุม scoping, 12 requirements, documentation, project management และ BAU เพื่อช่วยองค์กรยกระดับความพร้อมสู่ compliance
หลายองค์กรทำ Security อยู่แล้ว แต่ยังไม่ผ่าน PCI DSS เพราะ PCI DSS ไม่ได้วัดแค่การมีเครื่องมือป้องกัน แต่ต้องการให้ควบคุมความปลอดภัยภายใต้ scope ที่ถูกต้อง มีการแมปกับข้อกำหนดของมาตรฐาน ดำเนินงานอย่างสม่ำเสมอ และมี documentation กับ evidence ที่พิสูจน์ได้จริง รวมถึงรองรับแนวคิดต่อเนื่องของ PCI DSS v4.x เช่น Targeted Risk Analysis และ Business as Usua
