Overview

It has certainly been a busy time for the PCI Security Standards Council over the last year with the release of version 3.1 and now the draft release of version 3.2 of PCI DSS. This is no bad thing as it shows that the PCI Council is adapting its approach to releasing updates in recognition of a rapidly changing security and threat landscape in which both merchants and service providers now operate. Those of you familiar with the standard three-year cycle that the PCI Council normally operates will appreciate that this is a significant change.

Draft Documentation

As is normal practice, two documents have been released by PCI Council: a summary of the changes from version 3.1 to 3.2 and a more detailed document with descriptions of the proposed changes. It should be noted that these are still in draft and subject to change. Previous experience would suggest that any further changes will be fairly minor but this should be considered when planning additional work or changing work practices in line with version 3.2 requirements.

Within the Summary of Changes document, amendments are categorised into three types: clarification; additional guidance and evolving requirements. There are forty-seven clarifications to existing procedures and three defined as additional guidance. The eight evolving requirements (five of which only impact service providers) are usually of most interest as these often mean new requirements for merchants and service providers.

Evolving Requirements

All evolving requirements will be effective from 1 February 2018.

Requirement 3.3 has been updated to reflect the need for a legitimate business need to display more than the first six / last four digits of the PAN.

Requirement 3.51 is new and requires service providers to maintain a documented description of their encryption architecture.

Requirement 6.4.6 is new and requires change control procedures to include verification that any PCI requirements impacted by the change have not been compromised.

Requirement 8.3 (8.3.1, 8.3.2) is an extension of the existing requirement 8.3 to require multi-factor (note the change of language from two-factor to multi-factor) authentication for all personnel with non-console administrator access (now 8.3.1) and those personnel with remote access to the CDE (now 8.3.2).

Requirement 10.8, 10.8.1 are new and require service providers to implement a process for the detection and reporting of failures of critical security control systems (defined as, but not limited to firewalls, IDS/IPS, FIM, anti-virus systems, physical & logical access controls, audit / logging mechanisms and segmentation controls).

Requirement 11.3.4.1 is new and requires service providers to perform penetration testing on segmentation controls every six months.

Requirement 12.4 is new and requires senior management within service providers to establish and define responsibilities for the protection of cardholder data and establish a PCI compliance program.

Requirement 12.11 (12.11.1) is new requirement for service providers to perform reviews (at least quarterly) to confirm that personnel are following security policies and operational procedures.

Other Changes

PCI Council has also taken the chance to reorganise the appendices of PCI DSS and add some additional details.

Appendix A2 now confirms the earlier extensions to the continued use of SSL / early TLS (although service providers are still required to offer a secure service (i.e. using TLS 1.2) by 30 June 2016) through to 30 June 2018 (risk mitigation and migration plans will still be needed where less secure versions of SSL and TLS are used).

Appendix A3 now contains the Designated Entities Supplemental Validation requirements, which used to be a separate document. They are designed only to be used when a payment brand or acquirer requires additional validation of a merchant or service provider’s PCI DSS requirements on a BAU basis.

Impact of Version 3.2

The evolution of PCI DSS continues with version 3.2. More of the requirements are pushing merchants and service providers to view the implementation and maintenance of PCI DSS as a business-as-usual process rather than a point-in-time assessment (which it technically still is). This is welcomed and requires a more formal risk-based approach to IT security.

The new requirements will fall most heavily on to service providers although it could be argued that these represent nothing more than security good practice. There is however, plenty of time to implement the new requirements, but it is recommended that they be done as soon as possible (and once the final changes to version 3.2 have been confirmed). As ever, PCI DSS should be viewed as the minimum standard and all organisations should be striving for higher levels of IT security.

Recommendations

As with all new releases of the Standard, take the time to read it carefully and assess the impact of the changes on your business and operations. Consider whether there will be a need for additional resources and an increased budget. You may also wish to repeat or extend risk assessment exercises to look at the impact of the potential changes such as the extension of multi-factor authentication for administrators. Allow plenty of time to implement any changes identified.

CIPHER Security would be happy to discuss further any of the topics highlighted in this article or the wider issues of PCI DSS compliance.