PCI DSS 3.2 is due out by the end of April 2016; however, participating members have been provided a draft copy of the standard to be released. The release of the standard comes with some expected changes that not only clarify existing requirements, but also add some new ones that can bring a few new twists to one’s environment, most notably for service providers. But first, let’s go over the requirements that affect everyone.
As already known, the date to stop the use of SSL/early TLS as a security control has been extended until June 30, 2018. This extension directly affects requirements 2.2.3, 2.3, and 4.1. However, even though the timeframe was extended, it must be understood that:
- New implementation must not use SSL/early TLS – This means if one were to deploy a new firewall tomorrow, web access to the firewall must support TLS 1.1+. Similarly, rolling out a new e-Commerce site would require the site to use TLS 1.1+, even for existing organizations.
- All service providers must provide a secure service offering by June 30, 2016.
- Prior to June 30, 2018, existing implementation must have a formal Risk Mitigation and Migration plan in place.
- Existing POI terminal exceptions are still in place, but the date has been extended to June 30, 2018.
Updated guidance was provided for masking of the PAN (Requirement 3.3) when displayed on screens, paper receipts, and printouts. The need to mask the PAN is still in place and is limited to no more than the first six and last four digits, unless there are personnel with a business need to see more than those allowed. However, additional guidance is given that the masking approach should always ensure that only the minimum number of digits is shown. For example, if personnel only need to see the first six digits to perform a business function, then that is all that should be displayed.
A new requirement (6.4.6) was added in regards to system change management. Once changes are made to an environment (addition of new systems, Operating System upgrades, etc.), change records must document that applicable PCI DSS requirements were implemented as required by the change. For example, if a new web server is added to a DMZ network, change records should indicate that network diagrams were updated to show the addition of the new system and that the new system was included in the quarterly vulnerability scanning process.
Multi-factor authentication requirements have expanded within the new standard. Requirement 8.3.1, which is set to become a requirement on January 31, 2018, will require multi-factor authentication for all non-console access into the CDE for administrative access. This does not apply to application access, but only to personnel using non-console access (meaning not at the system they are connecting to). For example, if an organization uses RDP to connect to systems remotely, then multi-factor authentication at some level (network or system) must be used for authentication.
For service providers specifically, the release of PCI DSS 3.2 includes some specific, additional requirements. Each requirement needs to be met and/or enforced by January 31, 2018.
- Service providers must maintain a documented description of their cryptographic architecture (Requirement 3.5.1). This means a service provider will need to create a Key Matrix detailing each Key type, purpose, algorithm, key strength, and expiry date. In addition, details for storage and key creation will be needed to include an inventory of devices used for key management, like HSMs.
- An additional reporting requirement will require a service provider to implement procedures for the timely detection and reporting of failures for critical security systems (Requirement 10.8 & 10.8.1). One could state that the intent of PCI DSS and a sound Incident Response Plan addresses this need already, but by clearly spelling out the required response expectations, no grey area exists.
- Service providers must now increase the occurrence of the segmentation penetration testing (Requirement 11.3.4.1). Instead of an annual occurrence, testing will be required every six months.
- Executive management must establish responsibility and define a charter for PCI DSS compliance. This allows an organization to define overall responsibility for the compliance program to defined individuals/roles, but is meant to show that Executive Management has visibility into the status and understands the ultimate responsibility in ensuring PCI DSS requirements are met. In addition, the status on PCI DSS compliance must be communicated to executive management.
- Service providers will be required to perform quarterly reviews to confirm personnel are following security policies and operational procedures (Requirement 12.11 & 12.11.1). The purpose here is not to confirm if responsible personnel understand their roles or the procedures, but to essentially establish an internal audit role to confirm that procedures are being carried out, such as daily log reviews and responding to security alerts.
Finally, entities identified as a designated entity will now find the supplemental validation requirements (Appendix A3) within the newly published standard rather than as a separate document. Note: only such entities – entities instructed by an acquirer or a payment brand that they are a designated entity – need address the additional controls contained within Appendix A3.
