With the ink barely dry on the newest version of the industry standard for payment data protection, the PCI Data Security Standard (PCI DSS), what do organizations need to know about PCI DSS 3.2? In this blog post with Chief Technology Officer Troy Leach, we look at what’s new in this version of the standard.
You’ve announced today the release of version 3.2 of the PCI Data Security Standard. When should organizations implement these changes?
Troy Leach: Companies should adopt the standard as soon as possible to prevent, detect and respond to cyberattacks that can lead to payment data breaches. Version 3.1 will expire on 31 October 2016. However, all new requirements are best practices until 1 February, 2018 to allow organizations an opportunity to prepare to implement these changes.
You mentioned in a previous post that there are certain requirements being incorporated into the PCI DSS from the Designated Entities Supplemental Validation criteria. Can you elaborate?
Troy Leach: We’ve added the PCI DSS Supplemental Designated Entities Validation (DESV) criteria as an appendix to the standard, as well as expanded a few existing PCI DSS requirements (3, 10, 11, 12) to include DESV controls for service providers specifically.
Analysis of recent cardholder data breaches and PCI DSS compliance trends reveal that many organizations view PCI DSS compliance as an annual exercise and do not have processes in place to ensure that PCI DSS security controls are continuously enforced. The process of adhering to PCI DSS requirements is what is meant to be “PCI compliant.” The Report on Compliance (ROC) simply validates that the processes are in place and can evolve as an organization changes over the course of a year. These changes for service providers will provide greater assurance that the security will remain as expected for both the provider and their customers that rely on those services.
Why is it important for organizations to ensure security controls are in place following a change in their cardholder data environment (new requirement 6.4.6)? What type of change would trigger the need to re-evaluate an organization’s security controls?
Troy Leach: It is important to have a process to analyze how changes may impact the environment and the security controls that organizations rely on to protect cardholder data. Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date, and security controls are applied where needed. It sounds simple but can easily be overlooked to have a new device added to a network by an individual unaware of security-relevant issues or even the responsibility to protect cardholder data. A change-management process helps provide supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process and simplify future PCI DSS compliance responsibilities. Our hope is this requirement will eventually lead to better efficiency when reporting PCI DSS and security changes within an organization.
These changes also ensure organizations view security as an organic process that evolves with the company as an ongoing effort and not a yearly assessment to correct behavior.
New requirements 10.8 and 10.8.1 outline that service providers need to detect and report on failures of critical security control systems- why is this deemed necessary?
Troy Leach: Without formal processes to detect and alert to critical security control failures as soon as possible, the window of time grows that allows attackers to identify a way to compromise the systems and steal sensitive data from the cardholder data environment.
While this is a new requirement only for service providers, we encourage all organizations to evaluate the merit of this control for their unique environment and adopt as good security hygiene.
New requirement 11.3.4.1 indicates that service providers need to perform penetration testing on segmentation controls every six months. How often were penetration tests required before this change was implemented? Why is this an important change?
Troy Leach: Previously in the PCI DSS, it was required at least annually for all entities to demonstrate that their segmented environment was truly isolated. The difference is that service providers must demonstrate this now every six months. However, validating the effectiveness of segmentation should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
This is one of the most important controls to assure the proper focus of PCI DSS controls. With this change, we emphasize that importance with more frequency of testing to confirm security controls are in place and working.
There is a new requirement (12.4.1) for executive management of service providers to establish responsibilities and a PCI DSS compliance program. How should an organization go about implementing such a program and why is this important?
Troy Leach: Organizations where executive management are involved in strategic development of payment card security will be able to respond to changes and ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization, but the executive visibility is critical for service providers where protecting cardholder data is central to their business.
What can you tell us about the change that necessitates the use of multi-factor authentication?
Troy Leach: Multi-factor authentication requires two or more technologies 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. Multi-factor authentication is already a requirement in the PCI DSS for remote access. The significant change in PCI DSS 3.2 adds multi-factor authentication as a requirement for any personnel with non-console administrative access to the systems handling card data, so that a password alone is not enough to verify the user’s identity and grant access to sensitive information.
Requirement 12.11 and 12.11.1 asks that service providers perform quarterly reviews to confirm that personnel are following security policies and operational procedures. How should organizations implement these reviews?
Troy Leach: This requirement encourages organizations to reaffirm that those individuals the company relies upon understand the importance of the process and continue to follow the procedures beyond the week the assessor comes to town. Again, the theme of several PCI DSS changes is to demonstrate the processes to protect are operating as expected. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, firewall reviews, etc.—to assist the entity’s preparation for its next PCI DSS assessment.
Another change being introduced relates to primary account number (PAN) masking. Can you explain what this change entails?
Troy Leach: We’ve updated PCI DSS requirement 3.3 to ensure that only the minimum number of digits are displayed as necessary to perform a specific business function. The requirement continues to use the example of first six, last four digits. This update also provides flexibility, such as for varying BIN (Bank Identification Number) routing and aligns with recent considerations to other industry standards.
