Tuesday, March 13, 2007

PCI-DSS Clarity or Lack Thereof

In Jeremiah's recent post: "Big trouble if PCI-DSS requires CSRF" I think he both over and understates the problems with PCI-DSS and the PABP (Payment Application Best Practices) from Visa/PCI.

On the one hand we have the problem that if we are required to prevent CSRF attacks from a site we're going to have a lot more vulnerable sites.

On the other hand, neither the PCI-1.1 standard nor the PABP specify the criteria for judging an application or system compliant. Most if not all of the standards have the all-or-nothing flavor to them. Unfortunately, as we know, its rarely that simple.

The PABP focuses on two main areas that are application specific:
  • Development Practices and the SDLC
  • Actually countermeasures and vulnerabilities in the code
The first item is relatively easy to pass strictly speaking. All you have to do is fully incorporate security awareness training, developer awareness training, and security touchpoints, requirements, and reviews into your SDLC. From a purely technical (not practical/logistical) standpoint it is relatively straightforward to demonstrate compliance.

The second is much harder to pass because the standard itself doesn't say that you need to have frameworks to prevent attacks, it says you must be preventing them. This means that pretty much every deployed application isn't really compliant, since we know that all applications of a decent size are almost certain to have some sorts of application security vulnerabilities.

What the standard needs is a slightly more proscriptive requirement around the SDLC, a threshold of vulnerabilities that you must reasonably try to prevent, and solid remediation plans should there be a vulnerability discovered and/or audit trails to detect a breach should it occur.

WhiteHat's service actually comes in handy here in that with continuous monitoring of applications you shrink your vulnerability window (theoretically). What WhiteHat isn't monitoring for specifically are cases where there may be something like a stored XSS on your site currently. Unfortunately discovering these programatically is quite difficult, though I'm thinking catching this sort of defacement quickly could be pretty useful. You can always wait for your app/site to show up on the http://sla.ckers.org/ site, but that probably isn't the most efficient way to discover you have an XSS vulnerability..

Where does that leave us from a PCI perspective? Unfortunately we're discovering that as decent a standard as PCI is, and as nicely proscriptive as it is, it still has gaps.

One solution is to do what the government does.
  • Congress passes law
  • Federal agency draws up regulations that implement the law
  • Federal agency draws up interpretations, implementation guidelines, etc.
  • Lots of lawsuits happen, case law is set, and now we have definitive rules
  • Life goes on with a lot of $$ spent on compliance.
How much better or worse is PCI? I'm not sure I know.

3 comments:

Ruth said...

The major card brands have unified in recognition of the need to create a PCI standard which is neither too vague nor too prescriptive and which applies to different geographical needs and business models. PCI DSS 1.1 attempted to do this but is still in need of improvement.

PABP is currently written as a guideline and not a standard. Again, the brands are unifying to make it understandable, relevant and implementable to each different application.

The issues with state or federal legislation is that they are not consistent and each one attempts to enforce a different subset of privacy and PCI rules. This is not only unmanageable but also allows many companies to slip through the cracks depending on what kind of financial institution they are and who regulates them.

This is not only confusing but misleading to the consumer as they may be led into a false sense of security about the standards the company they deal with are complying with. There is also a great risk of prescriptive laws making it impossible to comply with other regulations.

Restrictive confidentiality requirements reduce the ability to maintain integrity and availability and therefore are counter productive. My recommendation would be to let the PCI SSC (Council representing the major card brands who understand the issues and risks and the shortcomings of the current standard) implement improvements to the standard before the states or feds overrule with something which may be much more unachieveable.

pci compliance said...

PCI-DSS Clarity or Lack Thereof

pci compliance said...

Quote"Restrictive confidentiality requirements reduce the ability to maintain integrity and availability and therefore are counter productive. My recommendation would be to let the PCI SSC implement improvements to the standard before the states or feds overrule with something which may be much more unachieveable."