Security Watch: Living with PCI DSS: Page 2

Nonetheless, as a result of these requirements, I’ve witnessed several significant efforts by organizations to re-architect some or at least significant components of their credit card handling systems. This has been a direct result of bringing their systems into compliance with PCI.

Now, at one level, it could be argued that some of these engineering improvements have been done at too superficial a level, and not necessarily for the “right” reasons. But, as one who often prefers a “glass half full” outlook, I like to look at the overall system before PCI vs. after PCI.

In most cases, the actual sensitive data—credit card numbers, customer information, etc.—is significantly better protected against exposure and compromise now than it was in the previous systems. In some cases, I’ve seen old-fashioned point-of-sale (“POS”) systems replaced with encrypted architectures that go to substantial lengths to secure the data while it is both in transit and at rest.

So, in my view, these are significant steps forward. At the very least, these two requirements have forced developers to actively decide how to protect the sensitive data and not to just assume that “someone else” will worry about it.

But not all of the news about PCI’s impact is good. I have seen some steps backwards as well as steps forward. Most notable among them has come from PCI requirement 6.6, which actually becomes mandatory by June 30th, 2008. It tells us to either, “Hav(e) all custom application code reviewed for common vulnerabilities by an organization that specializes in application security” or “Install an application layer firewall in front of web-facing applications.”

In my discussions with folks, I’ve found that most development organizations favor the latter—installing a web-application firewall (“WAF”)—rather than allowing their source code to be reviewed by outsiders. While this is likely to be a boon for the WAF product vendors, I see it as an overall step backwards.

To illustrate this, I’ll say it’s been my experience that many developers will feel they can neglect things like input validation if they know the WAF will be doing that for them. When that happens, the WAF has failed us. (This is a generalization, and there are no doubt significant exceptions to it, but I see it as a major concern to over-reliance on products such as WAFs.)

So there’s my quick look at the benefits and the down sides we’ve seen from PCI. In my experience, I’ve never seen a regulatory document like PCI have the direct and palpable impact on software security that I’ve seen PCI have. This is a good thing on the whole. I hope the industry can keep that momentum going and start really paying attention to the security of our software, and not just try to retro-engineer security through largely superficial bolt-on products.