The Ticking Time Bomb - PCI Application Security
A while back I wrote a blog post called Lets call a Fig a Fig about the limitations of web application firewalls and the sheer ludicrousness of a security standard offering an alternative of choosing a code review or a web application firewall.
This morning I was reading an excellent post by Chris Eng about a recent PCI Council meeting he attended. Its’s surely hard for anyone to criticize the intent of the PCI DSS. How can someone say ill of a security standard aimed to coerce people who process credit cards online in a responsible way? That said the more I watch the stampede of security vendors selling silver-bullets carefully positioned against issues they magically solve the more my blood boils.
Yesterday I was sent this “clarification” from the PCI Standards council, sent to me by Adam Munter.
The following is from the PCI Security Standards Council - it’s their response to an inquiry that SPI Dynamics made. The response was made in early March 2007.
(follows)
The answer to your inquiry is as follows.
Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.
The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects).
The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.
Thank you and regards,
The PCI Security Standards Council Response Team
I recently heard about some folks that took an intentionally broken application (think Foundstone Hacme Series), modified it a little by re-skinning it so it wasn’t quite so blatant and made sure you could SQL inject the database. They then (in disguise) engaged the services of an approved PCI scanning and passed the technical testing portion. From the logs (timing) it was pretty obvious that only automated tools were used. As an academic exercise I have repeated this with the same result. In fairness to the QSV they only did the minimum asked of them by the standard.As I have blogged before, PCI DSS has created a business model based on price.
Automated tools are to software security what spell check is to Word. We can all agree that they should be turned on and provide a valuable service (which is getting better) but they don’t mean secure software in the same way that a word document with no red squiggles doesn’t mean it should be eligible for a Booker prize.
September 25, 2007 at 8:54 am
you’ve just made my quote of the month club sir!
haha love the analogy
September 25, 2007 at 5:41 pm
Adam spells his last name, “Muntner”, but your spell checker won’t pick that up.
I don’t like the fact that the PCI council can change the words “code review” around to mean “scan and patch”.
September 25, 2007 at 6:12 pm
Dre
If you are going to continue to be one step ahead of me, I am going to have to stop liking you so much
September 25, 2007 at 9:01 pm
PCI gets a bad image as being the “solution” to security, when in fact it is just like you say, the spell checker. It’s the bare minimum, a bumping up of the lowest common denominator, and nothing more. And the more it becomes a business to certify as PCI, the more it becomes like the HackerSafe logo. It is in the best interests of the certifiers to certify more and more people.
September 25, 2007 at 9:06 pm
And no, I didn’t mean to mix your analogy of the spell checker->automated tools as spell checker->PCI. Not entirely anyway!
September 25, 2007 at 9:28 pm
I don’t like how the PCI council lets you choose between a code review and an application firewall. Then, every company in the industry has their own agenda on what constitutes a code review (automated versus manual, SSCA, BCA, scan/patch, etc)
Funny LV brings up “HackerSafe” logo. Ross Anderson brought that up in his “Searching for Evil” presentation at Google tech talks. Sites contain the HackerSafe logo are more likely to be malicious than those do not, simply because bad people go out of their way to seem legit.
September 28, 2007 at 5:03 pm
It should be noted that the Internet vulnerability scanning is meant to automated and to only detect such vulnerabilities. This is why there is a requirement for Internet penetration testing of both network-layer and application-layer vectors.
October 4, 2007 at 3:54 pm
Great article!
You touch on product and service vendors taking advantage of clients with PCI, but it stretches much further than that, and even professional advisory services firms are promoting value of PCI services (scanning and patching) as methods of managing information risks. Although this is comical to risk professionals initially, it really throws more disrespect to risk management as a whole.
In my opinion, compliance standards like PCI, should back-up their good intentions, and gain much needed reputation, by evaluating the client organizations’ capability in measuring and managing information risks to PANs (read sensitive info).
Mark