So here it is, PCI SSC has officially released the final version of PCI DSS v3.2 standard document. PCI DSS v3.1 will retire after six months from now and organizations are required to use PCI DSS v3.2 for assessments during this period. The newly added requirements will be considered best practices till 31st January 2018. Post this date they will be effective as requirements.
So, What’s New In PCI DSS V3.2?
The major requirements are listed below with a more detailed description given in the subsequent sections:
- Stronger push to later versions of TLS and complete migration from SSL and earlier vulnerable versions of TLS. Final deadline is 30th June 2018
- Multiple new requirements for service providers requiring documentation of their cryptographic architecture, detection and reporting of failures of critical security systems, segmentation penetration testing required every 6 months, charter and accountability for PCI DSS compliance program to be established, etc.
- Changes to existing requirements include changing vendor defaults of applications besides infrastructure, annual training for software developers, etc.
- Perhaps the most important requirement is for the implementation of two-factor authentication for all non-console access by administrators. This requirement was earlier only for remote access to the cardholder environment.
Details On The Changes
Below are the new requirements which are introduced through the release of PCI DSS version 3.2:
- “Appendix A2” is introduced which covers additional requirements and testing procedures for entities using SSL/Early TLS. PCI DSS requirements 2.2.3, 2.3 and 4.1 are directly affected by this change, therefore SSL and Early TLS shall not be used to meet these requirements. Entities looking to migrate from SSL and Early TLS are helped through following provisions:
- New implementations must not use SSL or Early TLS.
- Processing and third party entities such as Acquirers, Processors, Gateways and service providers must provide a TLS v1.1 or greater service by 30th June 2016.
- The sunset date for the use of SSL and early TLS is now changed to 30th June 2018. Post 30th June 2018, entities must use secure version of TLS as defined by NIST.
- Prior to sunset date, all entities must have a formal risk mitigation and migration plan documented.
- POS POI terminals that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control beyond 30th June, 2018.
- Requirement 3.5.1 is introduced for service providers which requires service providers to have a documented description of Cryptographic architecture.
- Requirement 6.4.6 is introduced which requires verification of the PCI DSS requirements which are impacted due to a change introduced in the environment.
- Requirement 10.8 and 10.8.1 are introduced for service providers which requires detection and reporting of failures of critical security systems such as Firewalls, FIM, Audit Logs, IPS/IDS etc.
- Requirement 126.96.36.199 is introduced for service providers which requires services providers to perform segmentation control penetration testing at least every six months.
- Requirement 12.4.1 is introduced for service providers which requires their executive management to establish responsibility of protection of card holder data and PCI DSS compliance program. This requires defining accountability for maintaining PCI DSS compliance and a charter for PCI DSS compliance program.
- Requirements 12.11 and 12.11.1 are introduced for service providers which requires quarterly reviews to be performed by service providers to ensure that personnel are following policy and procedures. The results of reviews shall be documented and signed off by personnel assigned responsibility for PCI DSS compliance program under requirement 12.4.1.
- “Appendix A3: Designated entities supplemental validation(DESV)” is now included in PCI DSS v3.2.
New Changes In Existing Requirements:
- Business Justification document for use of all services, ports and protocols needs to have approval by personnel independent of personnel managing the configurations.
- Requirement 2.1 which requires changing vendor defaults applies to payment applications also. The requirement is not just limited to Servers, Network Devices, End user systems, POS terminals, software and applications used to provide security services.
- Requirement 3.3 which requires masking of PAN for displays now needs a legitimate business justification document to display digits greater than first 6 and last 4 digits of PAN. Earlier in PCI DSS v3.1, this justification document was required only in the cases where Full PAN was displayed.
- Change control process under requirement 6.4.5 is not limited to patches and software modification. Changes such as hardware updates, application updates will also fall under requirement 6.4.5.
- An up to date annual training for software developers is required as per Requirement 6.5.
- Authentication requirement 8 is not applicable to accounts used by cardholders or consumers.
- Requirement 8.3 now requires that all non-console administrative access and all remote access to CDE should be secured by using Multi-Factor Authentication. Multi factor authentication required minimum of two of the three following methods:
- Something you know
- Something you have
- Something you are
- The list of service providers under requirement 12.8.1 needs to have description of services provided by each service provider.
Changes have been introduced to add value to your existing security practices therefore it is advised to organizations to start introducing these changes in and gear up to achieve compliance to PCI DSS v3.2.
Nikhil Raj Singh currently serves as Information Security Analyst at Network Intelligence India focusing on Strategy and Risk Advisory Services. He has carried out consulting and audit engagements of different compliance standards such as PCI DSS, ISO 27001 for industry verticals such as Banks, Airlines, Ecommerce Merchants, BPOs, ODCs, Telecommunications, Software Development, Payment Instrument providers. He also has varied experience in vendor risk assessments and third party risk review assignments in IT Risk and Governance.”