Feb. 6, 2012
While the Payment Card Industry Data Security Standard (PCI DSS) is now fairly mature, organizations applying and interpreting the standard might feel like they’re trying to hit a moving target. The PCI Security Standards Council published Version 2.0 of the Data Security Standard on Oct. 28, 2010. Although the revised version became effective Jan. 1, 2011, stakeholders had one year – until Dec. 31, 2011 – to understand and implement the changes from the previous version. Starting Jan. 1 of this year, all compliance assessments (whether done by a qualified security assessor or via a self-assessment questionnaire) must be performed under Version 2.0 of the standard.
Compliance requires organizations to align their security programs with the updated standard, which specifies 12 requirements. The majority of the changes from the previous version are clarifications designed to make adoption of the standard easier for merchants and service providers. Some of the clarifications still seem open to some interpretation, however.
Following are some of the most significant revisions in Version 2.0.
- Revisions to requirements 2 and 6 of the standard require an organization to assess and prioritize its vulnerabilities by adopting a risk-based approach based on its specific business circumstances. They clarify that all high-risk vulnerabilities must be appropriately tested prior to a system being deployed and that system-hardening standards must address all vulnerabilities. The requirement for ranking the risks of the vulnerabilities is considered an evolving standard and is not required to be put in place until June 30, 2012.
- Some of the clarifications reinforce the need for stakeholders to have a particular methodology for defining the scope of the compliance assessment so that it includes all data storage and system components in the environment where cardholder data resides. Scoping is the first - and one of the most important - steps to assessing compliance in an organization’s environment. If you don’t know where the data is, you can’t protect it. Organizations often fail to include in the scope backup or archival systems where production data may reside. Without the appropriate assessment of systems that store, process, or transmit cardholder data – in addition to an assessment of people and processes – the organization could still be taking on unidentified risk.
- Additional clarifications better accommodate the unique environments of issuers and issuer processors. In requirement 3 of the standard, the council clarified that cardholder data (specifically sensitive authentication data) might need to be stored for business purposes and should be secured; the previous version of this requirement strictly prohibited any storage at all. This requirement stipulates that the organization provide documentation that the business justification is stated in its data retention policy and to show that it can demonstrate that the data is stored securely.
- The PCI Security Standards Council has addressed in writing the fact that “user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts)” do not apply to the unique identification and secure authentication requirements outlined in requirement 8. However, Version 2.0 of the standard clarifies that although the application is not out of scope for requirement 8, it does allow more flexibility in the requirements for the particular user accounts that meet this description.
- The revised standard also encourages more effective log management in compliance efforts. Clarifications focus on the use of time synchronization technology and protecting these settings to make sure that logs are accurate and useful for forensic investigations when needed.
The PCI Council’s Special Interest Groups subsequently released two Information Supplements that address new types of technology that are not clearly defined in the standard and provided additional guidance in a document on the use of wireless technology in the cardholder data environment. While the supplements don’t provide step-by-step instructions for validating compliance in environments that use virtualization, security tokens, and wireless networks, they do provide guidance on determining how the scope of the PCI compliance assessment would be affected by such technology and answer common questions about the requirements’ applicability. With the ever-changing technology used in the payment card industry today, it’s easy to become lost in the many requirements for compliance and how they apply in any particular environment.