In our earlier blog post Planning for PCI DSS 3.2: Key Dates, we outlined important dates and milestones to help organizations prepare for the release of PCI Data Security Standard (PCI DSS) version 3.2 later this month. Here we talk with PCI Security Standards Council Chief Technology Officer Troy Leach about key changes in the standard, what they mean, and how PCI DSS 3.2 helps strengthen payment security programs.
In an earlier blog you indicated multi-factor authentication would be one of the biggest changes coming in PCI DSS 3.2. First, can you explain what is meant by multi-factor authentication?
Troy Leach: By multi-factor authentication we mean that two or more credentials must be used to authorize a person’s access to card data and systems. Examples of factors include something you know, such as a password or passphrase; something you have, such as a token or smart card; or something you are, such as a biometric.
Previously in the PCI DSS, we required any untrusted, remote access into cardholder data environment to use “two-factor authentication” which is the equivalent of multi-factor authentication. Changing the naming convention simply provides consistency that it must be at least two credentials at a minimum.
The significant change in PCI DSS 3.2 adds multi-factor authentication as a requirement for any personnel with administrative access into the cardholder data environment, so that a password alone is not enough to verify the user’s identity and grant access to sensitive information, even if they are within a trusted network.
What can you tell us specifically about the changes regarding multi-factor authentication to help organizations prepare?
Troy Leach: The most important point is that the change to the requirement is intended for all administrative access into the cardholder data environment, even from within a company’s own network. This applies to any administrator, whether it be a third party or internal, that has the ability to change systems and other credentials within that network to potentially compromise the security of the environment.
This will not impact machine authentication where one system is communicating with another as it is intended for personnel authentication; nor will it impact administrators accessing directly from the console.
To prepare for this change, organizations should review how they are currently managing authentication into their cardholder data environment, and review the current administrator roles and access to identify where changes to authentication may likely be impacted by the new requirement.
With a limited number of changes in PCI DSS 3.2, organizations will be able to focus attention on these type of critical controls, re-evaluate their current approach and address improvements that will help mitigate current points of attack.
The “Designated Entities Supplemental Validation” (DESV) is being incorporated into the PCI DSS with version 3.2. Can you explain what this is, and how it impacts payment security?
Troy Leach: The DESV is a set of criteria that can help service providers and others address key challenges in maintaining ongoing security efforts to protect payments. These include effective compliance program oversight; proper scoping of an environment; and ensuring effective mechanisms are in place to detect and alert on failures in critical security controls. Many of the requirements are simply extensions of existing PCI DSS requirements that should be demonstratively tested more regularly, or require more evidence that the control is in place.
With 3.2, we’re moving the DESV into the standard itself as an appendix mainly to consolidate requirements together and also to reinforce the importance of these requirements in establishing and maintaining ongoing security processes. Note that an entity is only required to undergo an assessment per this DESV appendix if instructed to do so by an acquirer or payment brand; moving these requirements into PCI DSS does not change that intent. While the DESV appendix goes above and beyond the core PCI DSS requirements, I encourage organizations to look at those requirements to see whether specific suggestions should be included in their security practices, even if not mandatory.
There are several new requirements for service providers. Can you explain the thought process behind including those requirements?
Troy Leach: Service providers play an important role in securing cardholder data for their customers. An organization could go to great lengths to protect their internal network only to see a third party negate all of their effort as indicated in data breach reports. That is why several new requirements were identified for service providers in PCI DSS 3.2.
These new requirements should already be part of service providers’ efforts to successfully manage the effectiveness of security within the cardholder data environment. These include actions such as maintaining a documented description of the cryptographic architecture and reporting on failures of critical security control systems. In addition, there’s a new requirement for executive management to establish responsibility for protection of cardholder data and the PCI DSS compliance program.
If you are part of senior leadership in an organization and entrusted to protect the cardholder data of your customers, you should be fully aware of your PCI DSS responsibility.
Again, just like DESV, an organization that is not designated as a service provider should still evaluate these new requirements to determine whether they would benefit by applying the security controls to their cardholder data environment even though it may not relate to their compliance reporting.
Making security an everyday priority instead of a compliance checklist continues to be a struggle for organizations. How do you see 3.2 helping with this?
Troy Leach: Specifically, the changes in PCI DSS 3.2 emphasize the importance of validating that security controls are in place and working by, for example, requiring verification that PCI DSS requirements are intact following an impactful change, and specifically for service providers, requiring regular penetration testing on segmentation controls at least every six months. The focus is on establishing ongoing security processes to prevent, detect and respond to attacks that can lead to data loss.
Anytime a new standard is released it provides organizations an opportunity to re-evaluate their existing security posture and whether they should make adjustments prior to applying the new requirements. We encourage organizations to first consider how they currently accept payments and how they store, process and transmit that data. Is there a different business approach? A way to eliminate unnecessary storage? Or technology like point-to-point encryption that can be deployed?
The incremental revisions in 3.2 provide an opportunity to address a few critical security risks and evaluate approaches for how best to accept payments securely in the future. If there is an opportunity to minimize the footprint of cardholder data, then any adjustments for a new version of the PCI DSS can be more focused, compliance reporting more concentrated and most importantly, areas where cardholder data must still be used can be better monitored and protected.
Are there any new changes regarding Secure Sockets Layer (SSL)/early Transport Layer Security (TLS) migration beyond what was announced in December of 2015?
No. The changes published in December 2015 will be the only changes regarding SSL/TLS. The only other addition is an appendix to help organizations in reporting their effort to migrate away from SSL and early TLS. Organizations can and should already be addressing this issue, starting with reviewing the Bulletin on Migrating from SSL and Early TLS.
