PCI Compliance Madness - See! I'm not insane! - Following the White Rabbit Blog -
PCI Compliance Madness - See! I'm not insane!

 Rich Mogull over at Securosis totally nailed it.  This article he put up talking about the Web Application Firewall (although it's still a mis-named product, see my rant here) vs. secure coding is brilliant.  I've been saying this since I can remember hearing about "WAFs"... and it's nice to see someone out there that people actually recognize (Rich is an industry heavyweight) echo this sentiment... although the analogy of using Cajuns and gumbo is probably beyond my abilities :)

Still thinking about this as I sat here and re-read the PCI DSS current standard (and supporting documentation)

{PCI DSS}
6.6 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
  • Installing a web-application firewall in front of public-facing web applications

{/PCI DSS}

 

A few things immediately hit me that I felt the immediate need to comment on, because my mind now thinks in terms of "if I'm a business leader, how do I find loopholes in this...".  Here are my thoughts:

  1.  I am having an issue with the term public-facing being there.  I'd be OK with business-critical or something that indicates the application/site hosts critical data (such as user information, credit card numbers, etc).  What if I'm a business and I have 100 "public-facing" sites, but they just all happen to be brochure-ware.  Granted I am a card processor.  Does it make sense to put non-mission-critical (or containing no critical data) sites through this review process?
  2. "... after any changes" - so if I change the background, or add new legal verbiage I have to re-submit my site to inspection?  That makes no sense from a business perspective... does it?
  3. Notice that it says "Review" and not "Review and mitigate any critical issues found within x time-frame"; does this bother anyone else?
  4. The word "either" implies an OR clause here... why does the PCI DSS council see Security Review and added protection as an OR?
As you can guess, I can come up with no less than 5 scenarios where I'm [assuming I'm a business which should be compliant with this policy] going to be horribly security-deficient while still being PCI Compliant.  So once again, I'm going to return back to this question and I want everyone to think about this carefully.  Would you rather be PCI Compliant, or secure?  Further, does compliance equal security?

Posted 10-25-2008 5:41 AM by RafalLos

Comments

Business Credit On Credit Speak » Blog Archive » See! I'm not insane! wrote Business Credit On Credit Speak » Blog Archive » See! I'm not insane!
on 10-25-2008 6:13 AM

Pingback from  Business Credit On Credit Speak  » Blog Archive   » See! I'm not insane!

Credit Card On Credit Speak » Blog Archive » HP - Application Security Center Community: PCI Compliance Madness -… wrote Credit Card On Credit Speak » Blog Archive » HP - Application Security Center Community: PCI Compliance Madness -…
on 10-25-2008 10:38 AM

Pingback from  Credit Card On Credit Speak  » Blog Archive   » HP - Application Security Center Community: PCI Compliance Madness -…

Ryan Barnett wrote re: PCI Compliance Madness - See! I'm not insane!
on 10-25-2008 3:34 PM

I agree with you that the PCI 6.6 Requirement is poorly worded - code reviews, vuln scanning and WAFs are all critical, complimentary processes that are NOT mutually exclusive.

As to your third thought above - while it doesn't specifically state it within the main PCI doc, the supplemental document on Audit Procedures does state that vulns identified from the code review need to be fixed on production hosts - www.pcisecuritystandards.org/.../pci_audit_procedures_v1-1.pdf (page 27).

I mentioned many of the same issues of requirement 6.6 on my blog - tacticalwebappsec.blogspot.com/.../pci-requirement-66-is-about-remediation.html

Credit Card On Credit Speak » Blog Archive » HP - Application Security Center Community: PCI Compliance Madness - wrote Credit Card On Credit Speak » Blog Archive » HP - Application Security Center Community: PCI Compliance Madness -
on 10-25-2008 10:32 PM

Pingback from  Credit Card On Credit Speak  » Blog Archive   » HP - Application Security Center Community: PCI Compliance Madness -

Sharon Besser wrote re: PCI Compliance Madness - See! I'm not insane!
on 10-27-2008 9:52 PM

I agree with your 3rd bullet - the council should have listed the minimum time frame to fix or mitigate a  vulnerability.  We all know that many vulnerabilities could not be fixed within a reasonable time (what's reasonable: one day? one week? )and therefore organizations will have to use other compensating controls.

The PCI Testing Procedures for section 6.6 actually states the following:

Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods),

as follows:

- At least annually

- After any changes

- By an organization that specializes in application security

- That all vulnerabilities are corrected

- That the application is re-evaluated after the corrections

Note that there is a requirement that all vulnerabilities are corrected and then one should scan to verify that.

I disagree on your 2nd bullet: While there might be changes that do not affect the security of the site (e.g. in your example, the background ), we all learned (the hard way) that developers have this habit of changing code... not to mention that some change control procedures might commit more than one code fix. In other words, while developer A might have changed just the background, developer B might have changes something else and the application would be changed. IMHO, the PCI council did the right thing using the words "any change" so that we will not have to argue about this topic for long :-)

Sharon Besser, Imperva

(http://blog.imperva.com)

Mike wrote re: PCI Compliance Madness - See! I'm not insane!
on 11-07-2008 10:04 PM

Rafal, I have to disagree with both you and Rich, who to date has not taken me up on my open offer to talk with him about the intent behind the PCI DSS requirements.  I implement, train, and liaison with just about every member of the payments industry on a global basis and would be happy to talk with you about any questions you might have around this topic.

I've included some links here for learning more about PCI DSS Requirement 6.6:

pcianswers.com/.../pci-dss-requirement-66

Also, my contact information: phone number and email are on the main PCIAnswers.com website.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

Type the numbers and letters above: