Today's the day! PCI DSS section 6.6 is required

by Steve Ragan - Jun 30 2008, 11:28

Today, June 30, marks the start of new revisions on the PCI DSS specs. Section 6.6 is now required, specifically companies who deal with credit or debit cards online must use an application layer firewall or have a complete website audit code review to remain PCI compliant.

With all the stolen and lost data in the news recently, the beef up of section 6.6 addresses one of the growing causes for PCI compliance failure. “PCI DSS Requirement 6.6 provides two options that are intended to address common threats to cardholder data and ensure that input to web applications from untrusted environments is inspected “top to bottom.” The details of how to meet this requirement will vary depending on the specific implementation supporting a particular application. Forensic analyses of cardholder data compromises have shown that web applications are frequently the initial point of attack upon cardholder data, through SQL injection in particular,” The PCI Security Standards Council stated.

There are vendors who will, starting today, offer new tools and services to help with PCI compliance regarding section 6.6 especially. If your company wants to use them, that’s great. There are three ways to ensure you meet the requirements of section 6.6, code reviews of the website done by hand, automated tools, or the use of an application layer firewall. However, while this seems easy, there is no quick fix for PCI compliance. The best way to earn this is to make sure it is included with the business process.

If you use the OWASP top ten list, the things you need to check for include Cross Site Scripting (XSS), SQL Injection (SQLi), Remote File Inclusion (RFI), Insecure Direct Reference, Cross Site Request Forgery (CSRF), Information leakage and Improper error handling, Broken authentication and session management, Insecure cryptic storage, insecure communications and non restrictive URL access.

Some of these ten vectors of attack are well known, others are still just as valid, but often overlooked. For example, error messages, which are not suppressed, can lead to problems. Sessions that never expire are another problem that is valid, but rarely given. Attackers can take advantage of insecure tokens or keys and hijack authenticated sessions. You have seen this on such domains as Google in the past.

It will take weeks for everyone to ensure full compliance. The frightening truth is that most will still opt for a quick fix, install an application firewall, and leave some avenues of the website open to access.

Some official info on section 6.6 is here: http://tinyurl.com/45op4z

The OWASP Top 10 is here: http://www.owasp.org/index.php/Top_10_2007

Around the Web

comments powered by Disqus