Following publication of PCI Data Security Standard version 3.2 (PCI DSS) we sat down with a member of the PCI assessor community for his perspectiveon the new version of the PCI DSS, how it’s addressing industry challenges, and the potential impact of changes for merchants.James Devoy is CSO & Global Head of Risk and Assurance for Sysnet Global Solutions, a PCI Qualified Security Assessor (QSA) company and an Approved Scanning Vendor (ASV) that works closely with acquirers, service providers and merchants on PCI DSS compliance.
Does PCI DSS 3.2 address the challenges you’re seeing in the industry today? How do you see the standard making payments more secure moving forward?
James Devoy: The PCI DSS is well established, well understood, and reflects industry good practice and other information security standards. I don’t see that there are any major ‘gaps’ that need to be addressed through the development and release of an entirely new version of the PCI DSS.
What the PCI SSC has done with v3.2 is to follow their existing process of continuous improvement and refinement to make iterative changes to the existing standard. They have adopted the feedback received from ourselves and many others, as well as addressing technology and industry changes.
The standard on its own cannot make organizations and payments more secure. By necessity it is written to be applicable across all payment methods, environments, industries and payment channels. The effectiveness of the standard relies not only on the organizations subject to the standard but also on their service providers and suppliers all playing their part in understanding how and where the security controls defined in the standard apply. As I see it, only when all of these parties correctly scope their environments, processes and responsibilities will we see improved payments security.
From your perspective, what are the changes that will have the biggest impact on merchants?
James Devoy: Firstly, in relation to changes made to their in-scope networks and systems, they need to make sure that PCI DSS requirements are applied or updated, which organizations should already be doing as part of their activities to maintain their PCI DSS compliance. This is meant to address the compliance gap that seems to occur between PCI DSS validations – often the status of the environment at the time of a breach is not the same as at the last PCI DSS assessment.
The second relates to two-factor (now called multi-factor) authentication. This requirement has been included to make sure that users with the ability to make changes to cardholder data environment (CDE) systems, and hence to potentially weaken security controls or introduce vulnerabilities, are more strongly authenticated. This makes a lot of sense. It may be problematic for some organizations, for example those that have deliberately avoided allowing remote access into their CDE, because they didn’t want the expense and complication of implementing a multi-factor authentication solution. With this change, all organizations that allow any kind of non-console administrative access – whether remotely, from their own network or from the CDE itself - will now need such a solution.
How do you see the market responding to this required use of multi-factor authentication?
James Devoy: It may take time but I think multi-factor authentication for non-console admin access will gradually come to be seen the ‘norm’, as good security practice for internal administrative access to systems. As such, I can also see that the providers of remote desktop and remote support software and solutions will see this as an opportunity to develop their products to provide simpler and cheaper methods of implementation.
Can you provide an example of what is meant by “non-console admin” access?
James Devoy: Non-console administrative access is where the system is being administered or managed over a network. It is called non-console administrative access as the IT administrator is not physically present at the system’s console interacting via the local screen and keyboard. For example, the system is being administered using remote desktop software, terminal services or a web-based management interface (GUI).
What is your advice to merchants about the new requirement for multi-factor authentication?
James Devoy: Impacted merchants will need to consider how and where the requirement applies to them before they can determine an appropriate solution to meet the requirement. Multi-factor authentication applies to accounts used by all individuals performing administration of merchant CDE systems, whether they are employees or third party IT support personnel. Once they have an understanding of the impacted administrative roles, the types and methods of systems’ administration used and all routes of access (i.e. from within the CDE or from an untrusted network into the CDE), I recommend that merchants make their next step one of simplifying, centralizing and consolidating. Merchants should make the most of the time available before multi-factor authentication becomes a requirement (January 31, 2018) to centralize user account administration, consolidate access methods and entry points to CDE systems. This will help to make selection and implementation of a suitable multi-factor authentication solution much more straightforward and its ongoing management simpler.
Any other tips for merchants on PCI DSS 3.2 adoption?
James Devoy: PCI DSS version 3.2 has allowed companies a decent amount of time (21 months) to plan for and implement the new requirements. My main recommendation for organizations is to start as soon as they can to consider how best to meet these requirements for their business.
For those merchants that have outsourced to and rely entirely on third party service providers for the handling and processing of cardholder data, we recommend they stay abreast of their service provider’s plans to meet the standard’s deadlines. They should seek assurance that the service provider is aware of and planning for those deadlines, not just the January 2018 deadline for v3.2’s new requirements but also the soon to arrive June 2016 deadline for them to offer services supporting a secure implementation of TLS v1.1 or greater.
Lastly, not all of our merchant customers will be impacted by the new requirements included in v3.2. Our advice is to make sure they investigate the changes that are specific to their assessment and validation requirements (whether self-assessment or on-site assessment) and to plan accordingly to take full advantage of the time allowed, if they do need to implement new requirements.
