×
By using this site, you agree to the Privacy Policy

Security Watch: Living with PCI DSS

Download our in-depth report: The Ultimate Guide to IT Security Vendors

So here we sit, some 9 months after the dreaded PCI DSS deadline. Just what do we have to show for it?

While I’ve heard lots of conflicting opinions, I believe we’re seeing some fairly significant short- and long-term improvements, as well as some non-insignificant steps back. Let’s explore.

But first, some explanation is in order. Anyone who works in credit card processing these days is likely to be familiar with PCI DSS, or the “payment card industry data security standards,” version 1.1. The release of version 1.1 of “PCI,” as it is also often called, a mere 17-page standards document, required organizations processing credit card data to implement numerous safeguards prior to June 2007.

Additionally, before I describe some of the changes I’ve seen, I should caveat my observations by saying that they are by no means statistically enormous or even particularly scientific. Instead, I’m going to talk about my casual observations from informal discussions with friends, colleagues, as well as my customers.

So, with all that in mind, let’s dive into the descriptions.

First, as I said, I’ve noticed a few relatively short-term effects from PCI. Chief among them is developer training. PCI requirement 12.6 prescribes, “Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.” And sure enough, I’ve noticed in the past year that nearly every training session I’ve done has been scheduled due to this requirement.

Security Articles
We Need to Rethink PC Security Software

Spam Wars: When Good Geeks Say Bad Things

You've Got Spam: The New Field of Reputation Management

Guide to Hotspot Safety

FREE IT Management Newsletters

Now, I call this a short-term gain because I feel that there is likely to be a “burst period” right now, and then things will slowly subside back to a steady state. Also, most of the training I’ve seen driven by PCI has been very introductory. Although I imagine many organizations will have their new employees go through this sort of training from time to time, it’s not likely that these intro classes will be repeated annually for all their developers.

Nonetheless, I’ve seen these intro classes to often be the first exposure to software/application security that many developers get. That, in and of itself, is a good thing, but we can’t stop there. It would be refreshing to see organizations take these training efforts farther and develop serious intermediate and advanced training for their software developers and IT staff. These are not PCI requirements, however, so I admit I’m not optimistic about seeing them happen in the near future.

And, while short-term improvements are good, by their nature they aren’t going to get us to where we need to be. I’ve also been encouraged by some of the longer-term improvements I’ve seen in organizations that handle credit card data.

PCI requirement 3 tells us to, “Protect stored cardholder data” and requirement 4 tells us to, “Encrypt transmission of cardholder data across open, public networks.” These are good things, of course, and speak to the notion of protecting sensitive data while at rest and while in transit. What the requirements lack, on the other hand, even when you dive into their details, is any particular types of encryption—algorithms and such—and key management processes. Rather, they leave significant room for the developer to choose how to implement the different safeguards.

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.”

Security Articles
We Need to Rethink PC Security Software

Spam Wars: When Good Geeks Say Bad Things

You've Got Spam: The New Field of Reputation Management

Guide to Hotspot Safety

FREE IT Management Newsletters

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.

Submit a Comment

Loading Comments...