PCI Compliance and Web Application Security: What You Need to Know for the Upcoming Policy Changes

If you are a merchant that processes credit cards, then you are probably already well aware of PCI compliance, but you may not be sure how web application security fits into the picture. You may also have heard that starting in June 2008, section 6.6 of the rules for PCI compliance will go from a "best practice" to a mandatory requirement (if not, it's time to pay attention!), but you might not know what this means for your business. The fact is, in a perfect world you already have in place what is necessary to be compliant with not only section 6.6, but PCI rules as a whole. This is because ideally, you would have handled your web application security practices from the start, as the applications are built, so that you are not scrambling to add security to existing applications. Unfortunately, this is often not the case - which makes now a great time for businesses to reevaluate their web application security processes overall.

What PCI Compliance Means

A bit of background regarding PCI compliance - as credit card use has become more widespread both offline and online, and as consumer concern about security has understandably grown, the credit card industries have made an effort to ensure that sensitive information is protected. To that end, in September 2006, the major credit card companies (American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International) formed the PCI Security Standards Council (SSC) and established a set of rules for what they called PCI compliance. These rules have to be followed depending on the size of a business and the number of credit card transactions handled, and if done properly will help protect consumers' data from theft.

The Rules for PCI Compliance

There are six major categories within the standards established by the PCI SSC, which are as follows:

Within these six categories are 12 requirements that address particular issues and that are directly related to web application security:
  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters
  3. Protect stored cardholder data
  4. Encrypt transmission of cardholder data across open, public networks
  5. Use and regularly update anti-virus software
  6. Develop and maintain secure systems and applications
  7. Restrict access to cardholder data by business need-to-know
  8. Assign a unique ID to each person with computer access
  9. Restrict physical access to cardholder data
  10. Track and monitor all access to network resources and cardholder data
  11. Regularly test security systems and processes
  12. Maintain a policy that addresses information security
Each requirement for PCI compliance is broken up into a variety of subsections that go into detail about the process, the full list of which can be viewed at www.pcicomplianceguide.org. Section 6.6 - the most important subsection regarding web application security because it is coming under scrutiny this year - states the following:

Ensure that web-facing applications are protected against known attacks by applying either of the following methods:

As a result of this upcoming change, it is important for companies to have a game plan in place for web application security. Until now, companies may not have taken PCI compliance very seriously. No major fines have been levied for noncompliance so far and the entire process may have been seen as something nonessential. But with this new change to 6.6, IT teams around the world are evaluating the strengths and weaknesses between web application firewalls, code reviews and application assessment software which all satisfy the requirement.

What It Means for Your Business

There are two mistakes that many organizations make related to web application security. First, many businesses and government organizations have historically focused their attention on network security rather than web application security, and it may seem that the June 2008 deadline is coming out of nowhere and that businesses will be scrambling to achieve PCI compliance. But the fact is, your business should have ensured that all of its web applications were secure from the beginning. PCI compliance shouldn't be viewed as a checklist, because then all that will happen is that unreliable fixes will be applied to problems. Instead, the concept of web application security needs to be implemented within the web application itself. When web application security is implemented properly, the PCI compliance requirements related to web application security are automatically met.

As a result, the development and QA teams at businesses need to be focused on web application security. It may be that businesses will need to take their web applications and break them down from the start, rather than trying to install patches and fixes for PCI compliance.

Another section related to PCI compliance that could cause problems in the near future is 11, which states that security scans must be done on a regular basis. If instead of fixing web application security issues internally, patches had been installed as an afterthought, these scans could become nightmarish because they will identify hundreds of issues that will need to be fixed. Better to take the time up front to build in web application security measures and avoid this problem altogether.


Businesses that process credit cards are likely already aware that they must be PCI compliant - but they may not have worked very hard to make sure that they are. In 2008, one of the subsections of PCI compliance will become mandatory, and businesses are going to have to evaluate their web applications very carefully. By ensuring that web application security is built from within, rather than by adding on fixes that will only work in the short term, businesses will find that not only are they compliant with one part of the PCI standards, but that they are compliant with all of them, and that their customers' data is secure across the board.

About the Author

Michael Sutton is a security evangelist for HP Software. Michael is responsible for educating audiences on the importance of integrating web application security best practices throughout the application development process and works closely with the HP Software Security Labs team. The co-author of Fuzzing: Brute Force Vulnerability Discovery, Michael has his CISSP and CISA designations and is a member of ISACA.