PCI DSS v3.2 – Rocks under the water?

Jul 22, 2016

By Stephen Hancock, 7Safe PCI DSS Consultant | 21 July 2016

By now, any company with an interest in PCI DSS should be aware of the new version, PCI DSS 3.2, which is mandated from 1st November 2016.  There are a number of clarifications and amendments but the two changes that look most significant to many people are the removal of SSL/early TLS as an acceptable secure protocol and the extension of the requirement for multi factor authentication to all personnel with non-console administrative access not just for remote access into the CDE.  The latter may require some changes to processes and some investment for some companies but at least it has been well trialed and companies should know that it is coming. 

Changes to PCI compliance requirements are not the only ones to watch for - Self Assessment Questionnaires  

Less apparent are some significant changes, not to the requirements themselves, but to how they are applied through some of the Self Assessments Questionnaires.  Many e-commerce merchants have used SAQ A or, since 1 January 2015 SAQ A-EP.   SAQ A had only 14 PCI requirements and could be used by merchants who have fully outsourced their on-line payments and as a result can certify that they “do not process or transmit any cardholder data on their systems or premises”.  VISA have clarified that this includes merchants who use a full redirect to the web site of a PCI DSS compliant payment service provider before any card data is entered or who use an Iframe from a PCI DSS compliant service provider.  [1] The beauty of SAQ A, from a merchant’s perspective, was that, while it might be best practice to secure the web application and the server, it was not mandated. None of the requirements in SAQ A was technical controls for securing the merchant’s web site and this remained out of scope.

SAQ A-EP applies where the merchant uses a direct post/silent order post API or Java script form.  The merchant’s web site still does not process the card data but it is responsible for running the API or calling the Java script form.  SAQ A–EP is considerably longer and had 136 requirements including many related to securing network devices, the web server and web site coding.     

'Hidden' changes in scope: will your systems be caught out?

Many QSAs have queried the logic behind the two SAQs – if the web server needs to be protected in the direct post scenario because of the risk that it could be manipulated so that the card data might be posted to a fraudulent location (Man-in-the-Middle attacks), is there not also a risk that a web site might be manipulated to redirect a user to a fraudulent location? Recent reports of an attack on an Iframe implementation from a well-known payment service provider, shows that this is not hypothetical.

In the new versions of the SAQs, the PCI Council appears to have responded to some of these concerns.  SAQ A remains much shorter than SAQ A-EP but it now contains 21 requirements instead of 14.  Most significantly, it now includes controls that relate to the web server.  Requirement 2.1 requires changing default accounts and values and there are five access control requirements from requirement eight.  All of these are reasonable but merchants who have been comfortable in the knowledge that their own systems were out of scope, will now find that this is not the case.  If, as many small merchants do, they have outsourced the hosting and management of their web site to a third party they will find that the hosting web server that was previously out of scope is now in scope. 

Further, if we apply the usual rule used in defining the scope of PCI compliance that devices connected to the in scope devices are also in scope, then the scope may extend beyond the web server to network devices and other components unless adequately segmented.  Guidance from the PCI Council on whether this is the intention would be welcome.

The changes to SAQ A-EP may be less significant in that they will not extend compliance requirements to new bodies and devices but they are still significant.  The number of relevant parts of PCI requirement One rises from 10 to twenty-three, there are seven newly applicable parts of requirement Six, requirement Eight rises from 15 to 24 and requirement Ten from 15 to 32.  At least merchants who have been using SAQ A-EP are used to their devices being in scope but the changes are significant enough that they may catch out many when they come to re-assess.   However, the merchants who may really be holed by these ‘hidden’ changes in version 3.2 are those who never thought their systems were in scope at all.  


[1] VISA. Processing e-commerce payments. A guide to security and PCI DSS requirements

PCI DSS Services 

Looking for a PCI qualified security assessor or expert advice about how to implement the standard? 

7Safe's established Scope-Gap-Audit model will help you to ensure that the PCI DSS requirements only impact those systems, employees and 3rd parties that need to be involved in handling card data and for you to understand exactly what you need to do in order to achieve compliance.

Our approach will also help you to adopt those requirements into your regular BAU activities in order to ensure that you retain your compliance with minimal cost and upheaval through future years.

Find out more by visiting  7Safe’s Audit and Compliance pages. Alternatively, speak to one of our trained advisers in complete confidence on 0870 600 1667.

PCI DSS Sailing through rocky waters