On Aug. 18, the PCI Security Standards Council, stewards of the PCI Data Security Standard, released a four-page summary document detailing changes in the upcoming 1.2 version of the PCI DSS. Though version 1.2 won't be finalized until Oct. 1., the summary document offers plenty of interesting information that can help us prepare for the October release.
The clarifications to the standard are great news, but what most retailers, merchants, and processers want to know is: "What will v1.2 mean to my organization?" Will the new version require additional PCI work, such as more processes, procedures, and technical product purchases? This analysis of the expected changes will seek to answer those questions.
PCI 1.1: Open to interpretation?
Here's the good news: PCI DSS version 1.2 is not a sweeping rewrite of version 1.1. Most of the changes listed in the summary document are clarifications of wording and terminology. Bob Russo, general manager of the PCI Security Standards Council, said of the group's goal was "eliminating as many questions as possible."
Many will likely welcome the changes, since some terms were poorly defined in the last iteration, making them confusing and difficult to interpret. For example, Requirement 6.6 of version 1.1 called for an "application-layer firewall." Retailers and PCI assessors (QSAs) alike wondered whether an application-layer-aware firewall, like the Cisco Systems Inc. PIX or ASA firewall, would suffice, or if it called for a Web application firewall like Barracuda Networks Inc.'s Web Site. Although the summary changes continue to reference "application-layer firewall," the Council issued specific guidance on the terminology in February regarding product type intended. Troy Leach, technical director of the PCI Security Standards Council, said that the testing procedures for Requirement 6.6 in version 1.2 make it clear that the Council is referring to Web application firewalls.
Other terms that received clarification and usage consistency makeovers are primary account numbers (PANs) and "strong cryptography." In version 1.1, "strong cryptography" is not defined, however, the audit/assessment procedures used by QSAs did list "Triple-DES 128-bit and AES 256-bit" as examples. Still, questions remained about AES 128-bit; was it acceptable? The clarifications in version 1.2 should answer these questions.
Another tricky one: does the PCI DSS apply to electronic media exclusively or is paper included? According to version 1.2, it applies to both electronic and paper media that contains cardholder data. This will create additional work for those organizations that had misinterpreted version 1.1 and kept paper media out of scope during DSS compliance work.
Compensating controls
When enterprises are not able to meet the exact letter of the standard, they look to controls that will provide the same level of protection. Perhaps the most well-known example of this is PCI Requirement 3.4, which requires that if PANs are stored, they must be either rendered unreadable (by one-way hashing or truncation) or encrypted (using strong cryptography). When many organizations found neither of these options was feasible, Appendix B of PCI DSS version 1.1 provided a list of acceptable compensating controls that could be used in place of those listed in the requirement.
Version 1.2 provides additional information about compensating controls and flexibility options for other requirements. In the updated standard, Requirement 1 eases the timeline for reviewing firewall rules from quarterly to every six months. And the 30-day patch cycle, from the often-dreaded Requirement 6, now has "added flexibility . . . by specifying that a risk-based approach may be used to prioritize patch installation." Under version 1.1, many retailers scrambled to install patches within 30 days, often short-circuiting their standard patch life cycle testing in an effort to meet the strict timeline. A thorough approach to patching, however, requires testing, prioritization, and a robust pre-production process, which can take longer than 30 days. The change allows for risk-based approaches that may require more time.
Another welcome change concerns physical security. PCI DSS Requirement 9 called for cameras to monitor "sensitive areas," but was an area like a restaurant dining room -- where credit cards are handed to staff -- considered sensitive enough to require a camera? How about a point-of-sale (PoS) cash register at a food court kiosk? Under version 1.2, organizations now have more flexibility to select other access control mechanisms when appropriate.
And though it's not in the summary document, the Council has stated there will be additional clarifications regarding definition of scope. According to Leach, the next version of the standard will include a section on scoping and sampling to explain what's within the PCI assessment and what is not.
More requirements?
While the clarification and compensating control changes are welcome, there appear to be some additional requirements in version 1.2. For example: "Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission." For those of you who thought perhaps the Council meant 802.1X, you're not alone; I thought that at first, too, because 802.11x is a placeholder for upcoming standards and not an IEEE standard.
Leach said 802.11x was used to indicate that upcoming versions of the DSS may include recommendations for using emerging 802.11 standards, such as 802.11i. So for more specifics, we'll all have to stay tuned. On the plus side, version 1.2 will continue to allow SSL/TLS and IPsec for protection of data transmissions over both wired and wireless networks.
Some potential heartburn may come from this change regarding wireless network encryption: "New implementations of WEP are not allowed after March 31, 2009… Current implementations must discontinue use of WEP after June 30, 2010." Wired Equivalent Privacy (WEP) has been broken for many years, so it makes sense for the Council to call for an end to its use in cardholder data environments, but many "out of the box" point-of-sale packages still commonly rely on WEP for proper operation. The two-year timeline for complete replacement of these systems may be too aggressive for retailers. If so, the Council will need to amend the timeline.
Finally, the antimalware requirement has been updated to include "all operating system types." Antimalware for Mac platforms and Unix/Linux are available, but options are limited. As for mainframes (like System z), there just aren't options. Look to the actual wording in version 1.2 for clarification beyond what is listed in the summary. It is unlikely that mainframes will be included in the final list. Also, for platforms like mainframe and some flavors of UNIX, organizations can consider layering anti-malware protection by using gateways or other compensating controls.
Editor's note: This tip was originally written in August 2008 and is based on the PCI Security Standards Council summary of changes to the PCI DSS and interviews with representatives from the Council. See the official summary for details. The release of PCI DSS version 1.2 is expected in October.
About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
