Requirement 6.6 – The Misunderstood Requirement – Part 1

It still amazes me how many people do not understand PCI requirement 6.6.  Even after the PCI SSC issued a lengthy Information Supplement regarding requirement 6.6, people still do not understand it.  So, foolishly, I’m going to give it a shot.  However, remember, requirement 6.6 only applies to organizations that develop application software, not organizations that purchase solutions.  By developing applications, I do not mean custom reports, I am talking about application development that adds or changes functionality, particularly functionality regarding the processing, storing or transmitting of cardholder data (CHD).

For those that have forgotten, requirement 6.6 states:

“For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes, or installing a web-application firewall in front of public-facing web applications.”

Many people don’t understand the purpose of this requirement.  This requirement is in response to attackers moving from network-based attacks to application-based attacks.  This movement is because applications that run through a browser are essentially the same regardless of the browser.  As a result, an attack against a Windows system running Internet Explorer is highly likely to also be effective against a Macintosh with Safari or a Linux system running Firefox.  Is this a great world or what!

Another big change in requirement 6.6 was a changing of terminology.  Notice the wording has changed from v1.1 from ‘web facing’ to ‘public facing’.  Based on clarifications from the PCI SSC, they have defined ‘public facing’ as any application that processes, stores or transmits CHD that is used on a network.  Therefore, all applications, externally facing or internally facing, are now in-scope if they process, store or transmit CHD.  Even those applications that do not have a browser interface are in scope.  Granted these applications present an extremely low risk, but they still need to be assessed.  Why the change in terminology?  Because FBI statistics indicate that more than 70% of all attacks have some form of an internal component and if an attack can be performed externally, it also can likely be performed internally.

In the next posting, I’ll discuss the use of application firewalls as a method of compliance.


0 Responses to “Requirement 6.6 – The Misunderstood Requirement – Part 1”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


March 2009
« Feb   Apr »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,941 other followers


%d bloggers like this: