The PCI Security Standards Council (SSC) will soon release version 3.2 of the Payment Card Industry (PCI) – Data Security Standards (DSS), and, based on a preview, it is expected to have more testing for payment system software.
At the end of April, the standards council will publish an overview of 3.2 with a timeline and resources for adoption. Additionally, they will publish PCI DSS 3.2 supporting documents including Self-Assessment Questionnaires (SAQ), Attestation of Compliance (AOC) forms, Report on Compliance (ROC) templates, Frequently Asked Questions (FAQ) and Glossary will be published.
According to PCI Guru, which obtained an advance copy of the new standard, requirement 6.5 has been clarified that developers must go through secure coding training at least annually. Organizations developing software that is in-scope for PCI compliance will need to comply with this starting in February 2018.
Also, service providers will need to perform penetration testing on segmentation controls at least every six months. They, too, have until February 1, 2018, to set up these tests.
And section 11.5.a will change the use of the term “insecure protocols”. In v3.2, the Council has finally removed the “insecure” designation as, in their words, “these may change in accordance with industry standards.”
There was no mention of changes with 6.2 which covers Terminal Software Security, specifically Secure Software-Development Life Cycle. The current language reads:
The key to addressing potential threats is a robust, secure software-development life cycle. All software-development organizations should:
• Understand the current threats and how they impact the software.
• Develop and maintain secure coding standards and other processes to address those threats.
• Conduct reviews (including source-code reviews) to ensure the defined processes are being followed.
• Test the software components and terminal as a whole to give additional confidence that nothing has been overlooked.