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.