In this second installment of our feature called, “Thought Leadership with an Industry Expert,” we spoke with David Taylor, the founder of the PCI Knowledge Base, about PCI compliance.

Scott Olson: So I have a few questions for you today about PCI standards. The first one is, that you attended the PCI Security Standards Council’s Community Meeting recently, what were some of the hottest topics?

David Taylor: Well, I have talked to several people since then. Generally the agreement is that the folks at Price Waterhouse Coopers who were there to report on the study they had done for the PCI Security Standards Council of what you might call “Beyond PCI topics” — certain things that were really not addressed explicitly by PCI DSS in the 1.2 version, but were raised by many merchants and service providers and acquiring banks as ways to address compliance. This was either to reduce the scope of compliance, or to secure card holder data, or both of the above, and they were looking into a number of different things. I think they started out with twelve and they narrowed it down to three or four, depending on how you count.

The rest of the meeting largely consisted of feedback, meaning that people went up to the microphone and talked. The subcommittees or the special interest groups related to virtualization and wireless and the scope of the PCI standards, everybody spoke. I think generally what was reported out was the status of committee efforts, and nothing earth shattering. You’re not supposed to expect earth shattering things out of a meeting that takes place in the off year, meaning that the standards come out every two years and this is an off year. So they are preparing people for what is going to happen next year. I think the clarity of that is always like, “Well, we are working on stuff and there are a lot of things going on, but we can’t really tell you all that much because it is a work in progress.”

The PWC report was probably — just simply because it addressed stuff that wasn’t already in the standards — I think that that was comparatively the most enlightening of the sessions I participated in.

Ok, well certainly PCI compliance has been in the news a lot lately in association with companies who have had data breaches but had passed their PCI audit. In light of these events, what do you think is important to take away from this?

It’s an interesting question. There’s the whole notion of “what does compliance mean, and how is compliance evaluated?” If you think about it as the 100% that you have to score on the PCI standards, a lot of people recognize that as soon as you start talking about “wow, you have to score 100% on the test, and the test is only given one time a year,” what happens in the meantime? I think the answer is, like anything that you study up for, again keeping with the test analogy, you study, study, study. You cram, if you will. If you think about college and high school, you cram for an exam, and you pull a bunch of all nighters, and you get through, by hook or by crook, and then what happens afterwards? You rest up. You take a break. Things that you really should have done and knowledge that you should retain and all that sort of stuff tends to fall by the wayside. Other things become important. You’ve got other exams. Maybe it’s a Sarbanes Oxley exam, or whatever, so you begin working toward some other goal.

So what happens is that PCI compliance begins to deteriorate, much like your knowledge loss if you crammed for an exam. This can happen immediately, within hours, within minutes even, because all that has to happen is you have to change the firewall rules, or you change the configuration of a particular key system and enable some services that you had disabled in order to pass compliance, or you have to simply ignore logs that you were evaluating on a daily basis up to the PCI exam.

Following the exam, you simply may not have the time to evaluate those logs on a regular basis, and guess what? Something slips through. Malware is downloaded by an employee working remotely from their home office and they log back into the network, they upload it, it’s missed and the logs that might catch it don’t. Or the people that might evaluate the logs don’t see it.

So all of a sudden you have an infection. You were compliant three or four days ago, or two or three weeks ago, or a couple of months ago, and you’re not compliant anymore and you can be breached.

Could you be breached while you’re 100% compliant? Yeah, actually you could. There’s a variety of different techniques. There are very targeted malware oriented techniques where people custom design malware so they can get past a lot of the defenses. The Albert Gonzales indictment — he’s the guy who stole all the data from the different merchants, like Heartland, etc. — showed he used targeted attacks. PCI compliance, even as comprehensive as the standards are, can actually miss some of that. It’s just the nature of security and bad folks.

Well, that’s actually a good segway, speaking of Albert Gonzales and Heartland, Robert Carr, the CEO of Heartland, was highly critical of PCI standards and their own auditors, with respect to their accountability, following their own data breach. Was this fair criticism?

Well it’s hard to say whether it’s fair or not, simply because who knows what went on at Heartland. The forensic investigators probably know. Bob and his team probably know. I as a researcher don’t exactly know, but I’ll tell you the general case.

What happens that we’ve seen in our research certainly, is that most organizations out there don’t want to spend the most amount of money that they could possibly spend to have an assessor come and evaluate them. They don’t even want to spend the middle amount of money. They’d rather get away for as little as they can get away for and still achieve compliance. In fact, that’s one of the major complaints from the QSAs (Qualified Security Assessor), or the assesors that we’ve interviewed, which is people are always nickel and diming us on price, and in order for us as a QSA to win business, we’ve got to come out with a very aggressive implementation of an audit, or gap analysis, etc. What aggressive typically means is that if we can avoid going on site, we’ll avoid going on site. If we think we can get away without sampling stores or other remote locations, we’ll do that. Why? Because those things run up the price and if we run up the price then people won’t buy our services.

So, what happens is, whether it’s Heartland or your average merchant level one even level two, you’ve got a lot going on technically. You’ve got a lot of different implementations, a lot of different applications, infrastructures, physical stores, etc. If a company can get compliant for less money that’s what they’ll do. Did that happen in the Heartland case? I’d say probably, simply because it happens in almost every case.

Nobody says, “I want you to crawl up my butt and do the absolute most to find everything you can possibly find, and I’m willing to spend a couple hundred thousand dollars or more to have you do that.” Nobody says that. If you criticize then, somebody, a QSA or whatever, for not being thorough, and you probably didn’t even want them to be thorough, because who does? Guess what, somebody who’s really, really thorough and you wind up spending a ton more money against the probability that you are going to be breached. That probability is relatively low, so why would I want to spend a ton of money against a relatively low probability.

So I think the answer is, in hindsight, we all go, “Wow, I wish they’d found this,” and “Wow, they should have found it.” You know, Bob’s been criticized because he threw the QSAs under the bus. That’s a phrase that’s typically used to describe what happened. I don’t think that his situation and Heartland’s situation is really very different from most of the rest of what’s going on out there, just in our experience. There’s a lot of QSAs that would be happy to do much more comprehensive assessments if only people would pay them to do it. So that’s the real issue I think is going on there.

Changing gears a little bit, PCI standards are geared at card data security. Have you seen businesses incorporating this on a broader basis to combat fraud and manage risk and other purposes?

Yeah, actually it’s a popular refrain in many of the interviews that we conduct. When we do our interviews, which are 100% anonymous, one of the things we like to focus on is, ok, this is a pretty comprehensive set of standards. There are ways to improve them, as the PWC study I cited earlier is really all about, improving the standards. Nonetheless, even as they stand today, they’re pretty freaking comprehensive. Well, if they’re so freaking comprehensive, why aren’t we applying them to other data that we have to protect? Why is card data somehow special, and social security numbers, or account numbers, or employee information, or salary data, why isn’t that as important? And the answer is, it is.

In fact, if you wanted to drive data security from a typology or data classification system, where you created a class of data called sensitive or confidential and you said, ok, all data in all of the different databases, and applications where it is stored and used, all data that is confidential needs to be protected in the same way. What’s a good comprehensive set of controls that we could apply to protect that data? It’s probably some combination of what you’ve got to do for PCI compliance plus throw in some Sarbanes Oxley, and say some of the financial industry standards, etc. PCI is typically the cornerstone simply because it’s very detailed.

A lot of the rest of the standards that you see, whether it’s HIPPA or even SOX, focuses on what used to be called the “reasonable person theory.” Would a reasonable person acting under reasonable circumstances with reasonable constraints protect their data in the same way? PCI says, no, no, no, this is the way to do it. So some security people really want to be left to their own devices and apply the reasonable person standard, and just do what they, as security professionals, think is reasonable.

Other people, and I think this is common, not only because it’s explicit, but actually if you are in the IT organization, or specifically in data security, you want a standard that says “you need to do this.” Why? Because it gives you justification to go out and buy things. When you go up to upper management, to the CEO and to the Board of Directors, and say I need $2.5 million to secure data, because we want to do what’s reasonable, they say, “Oh really? That’s nice. We’re reasonable people and we don’t think that’s reasonable.” So for an IT person or security person to go in there with a specific set of standards that says you need these kind of firewalls, these kind of logging and intrusion detection, and data encryption, and key management systems in order to be compliant they say, “Well, we’re going to do this anyway for PCI, why don’t we apply this to all this other data?”

The logic of that has been very helpful in terms of getting organizations to apply the PCI standards to other types of confidential data or other examples of confidential type data.

Last question. PCI standards are up for revision next year. What do you think are some of the most important improvements to be made with the standards?

Well, again, you have to believe that there are a couple of different sources for this. Maybe several, depending on how you look at it. There are the card brands themselves. The card brands, their job is to try to ensure that the standards remain comprehensive. While there are communities, you know there is the Community Meeting. There are members of the PCI Security Standards Council, and the PCI Knowledge Base for our part, we’re one of those members.

But I think the thing is it’s the card brands, it’s the members of the community, and then it’s specific things like this Price Waterhouse Coopers study. They had this study done for a reason. They had it done by an outside organization, presumably for objectivity and to gather a wider range of data. So I suspect they’ll be leaning heavily on what PWC recommends. So you figure, according to that report, as was presented at the community meeting that they are going to focus on several different things. They could focus on end-to-end encryption, tokenization, and virtual terminal technology. Those are the three top priorities they came out with.

So I suspect, that of all the things that they studied, those are the ones that are most likely to affect the standards. Whether they’ll affect the standards in terms of a rewording? I mean are we going to go from the digital dozen to the digital fifteen? I doubt it. Are we going to see language within the standards altered to reflect, let’s say in the case of 3.4 or 3.6 which relate to data at rest encryption and data at rest key management? Are we going to see those standards modified to reflect incorporation of end-to-end encryption? That’s possible. There are certainly other scenarios that simply say that you don’t need to modify some of the standards, you need to focus on giving advice to the QSAs and to the affected companies about how they determine scope. Maybe the best analogy is network segmentation. Network segmentation is pretty much what every QSA and every organization has done to keep their entire network from being part of PCI scope. They segment it using internal firewalls and a variety of other things, but the point is network segmentation isn’t a PCI standard. It’s something everybody does to achieve PCI compliance, but it’s not a standard in and of itself. Maybe end-to-end encryption or tokenization fall into that category as well.

It’s hard to say exactly what they’ll do but certainly those are the three areas that I think are most likely to affect the structure of the PCI standards and the logic of how they’re evaluated and enforced.