In October 2010, Version 2.0 of the Payment Card Industry – Data Security Standard (affectionately called PCI-DSS) was released by the Security Standards Council and went into effect January 1, 2011. Most of the changes were focused on clarification of existing guidelines but could have an impact on the steps required to get PCI compliant. While Version 2.0 went into effect January 1, 2011, the PCI council was gracious enough to allow a grace period so any validation efforts completed in 2011 are allowed to use either version. Some of the changes have a longer grace period. Version 1.2.1 will be retired on December 31, 2011 so come 2012, all merchants who are required to be PCI-DSS Compliant will have to get their validation under provisions of PCI-DSS 2.0.
Before we look at the changes in PCI 2.0 that become mandatory in 2012, let’s look at fundamentals of PCI-DSS.
The Payment Card Industry Data Security Standard
The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data. PCI standard is built around twelve key requirement categories:
Source: PCI DSS Requirements and Security Assessment Procedures, Version 2.0
Although most of the emphasis for compliance has been put on Level 1 and 2 merchants, various credit card companies are push the standard down to Level 3 and 4 merchants as well. For example, VISA requires compliance from all level merchants with some variations in requirements:
Other card providers have slightly different requirements and deadlines.
Changes in Version 2.0
Here are some of the key changes that were made in PCI-DSS 2.0:
• Requirement 1.3.8 – Do not disclose private IP addresses and routing information to unauthorized parties. Clarified with specific examples for methods of preventing IP address disclosure.
• Requirement 2.2.1 – Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. Additional clarification was made for virtualization – Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
• Requirement 6.2 – Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. Previously ranking wasn’t required. Most merchants have not been focusing on these and it’s an important distinction. Rankings should be based on industry best practices. The council gave an extra grace period for this change and this will become a requirement after June 30th, 2012.
• Requirement 6.5 – Instead of just using OWASP Top 10 as the benchmark, the council clarified that as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these. In Section 6.5.6 was changed to clarify that all the “High” vulnerabilities identified in Requirement 6.2 must be fixed.
• Requirement 11.1 – Processes should be in place to detect unauthorized wireless access points on a quarterly basis. Provided flexibility in terms of methods used for detection. • Requirement 12.1.2 – Risk assessment methodologies should be documented. Changes also included examples – Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
• Requirement 12.6.1 – For security awareness program – broadened the scope so it says “personnel” vs. “employees”. Also defines various methods to be used depending on the role of personnel.
• Requirement 12.8.4 – Clarified that “entity” instead of “entity assessed” maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.
In addition to the above, there are a lot of minor clarifications of the existing requirements. Some of the clarifications can be important too. For example, one major clarification has to do with the primary account number (PAN) on a credit card. If you store an account number it must be rendered unreadable.
Be sure to verify that you are meeting all the requirements appropriately and consult with your acquirer for additional clarifications.
There’s limited time left for PCI DSS 2.0 compliance timeline. Some of these changes require time so do not procrastinate and start working toward these goals now. While getting compliant with PCI DSS like any other regulations is important, remember, this is just a means to the end and not the end itself. The ultimate goal is to get your infrastructure secure so you can protect your customer and employee data from hackers. Focus on security first and compliance will follow automatically. Getting a checkbox for compliance can get you in trouble. Compliance doesn’t necessarily mean security. Strong security should usually result in compliance. Stay secure.
Related Content: Embracing Mobile Payments? You Might Not Be Compliant
