Updates to the Payment Card Industry Data Security Standard (PCI DSS) have been released by the PCI Security Standards Council. The updates, hopefully, will bring some clarity to a number of areas which retailers, merchants, and auditors say are foggy.Come this October, the current PCI DSS Standard 1.1 will become 1.2, and to help retailers that accept credit card payments prepare for the changes, the PCI Security Standards Council released a summary of the anticipated changes coming this fall. In its announcement, the PCI DSS summed it up this way:

Changes to the PCI DSS include clarifications and explanations to the requirements, with these clarifications offering improved flexibility to address today's security challenges in the payment card transaction environment. The new summary document on these changes highlights the key clarifications by requirement. These clarifications will also eliminate existing redundant sub-requirements while improving scoping and reporting requirements.

Quite the bureaucratic mouthful, isn't it? That's a lot of words to say: We're clearing some things up for you. And after a superfluous, yada-yada sounding quote (every press release needs one, don't you know), the release went on to say:

With the summary of changes to the revision of the PCI DSS, the Council is giving stakeholders guidance on what to expect when version 1.2 is publicly available. The Council is finalizing the changes to the standard and will be providing its Participating Organizations with version 1.2 in early September.

Until September, we have the new PCI DSS Summary of Changes document to work from.

While there are too many updates in this document to list in a blog post, many of the changes are minor tweaks to legalese verbiage, such as clarifying that the requirement for antivirus software applies to all operating systems, and using consistent terms for encryption. Other changes will be more profound to retailer security practitioners and PCI DSS assessors.

One such change comes to PCI DSS Requirement 6, which calls for the development and maintenance of secure systems and applications. Like this needs to be a formalized requirement, but in the world we live in -- where expediency and cost-cutting rule over the responsibility to protect your information -- apparently so. Requirement 6 will be updated to allow a risk-based approach to prioritize patch updates. This is, overall, good news. No one needs to feel the pressure to patch "highly critical" print-server vulnerabilities buried 10 firewalls deep and three network segments from the Internet the same day "Intermediate-level" risks are on servers in the DMZ. From a risk-based perspective, it just makes zero sense to treat all patches equally. Trouble comes into paradise for those retailers whose eyes glaze when you ask them to actually implement a risk-based vulnerability management program. Oh, my!

The other clarification in the document regarding Requirement 6 is a restatement to what I thought already had been clarified. Maybe not, but here it is:

Requirement 6.6 is now mandatory. All public-facing Web applications are subject to either 1) reviews of applications via manual or automated vulnerability assessment tools or methods, or 2) installing an application-layer firewall in front of public-facing Web applications.

Considering how many, many attacks are now going straight down the throats of Web applications, any additional security attention here is a good thing. But this reads as if installing a Web Application Firewall (WAF) negates the need for any code review. That's not true, as section 6.5 clearly states that secure coding is the order of the day:

Develop all Web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:

6.5.1 Unvalidated input 6.5.2 Broken access control (for example, malicious use of user IDs) 6.5.3 Broken authentication and session management (use of account credentials and session cookies) 6.5.4 Cross-site scripting (XSS) attacks 6.5.5 Buffer overflows 6.5.6 Injection flaws (for example, structured query language (SQL) injection) 6.5.7 Improper error handling 6.5.8 Insecure storage 6.5.9 Denial of service 6.5.10 Insecure configuration management

Good security problems to eradicate, all. And whether you have a WAF installed or not, periodic application assessments are the way to go. Any retailers relying on WAF need to make sure they're set to actually block attacks. Otherwise, you get this dangerous false sense of security going on. Just monitoring Web application traffic as retailers get pwned doesn't get them past Go. Yet, monitor mode is the way many of these WAFs are configured (you know it's true).

Actually setting them to Block malicious traffic is a clarification I'd like to see in big, bold font in section 6.6.