Defending PCI: 'Don't Blame the QSA's'

Interview with Bob Russo, GM of PCI Security Standards Council
Defending PCI: 'Don't Blame the QSA's'
Since the announcement of the Heartland data breach in January, the merits of the Payment Card Industry Data Security Standard (PCI DSS) have been questioned, and Bob Russo has led the defense.

Russo is general manager of the PCI Security Standards Council, the group responsible for the development, management, education and awareness of the PCI Security Standards. In an exclusive interview conducted at the council's recent community meeting in Las Vegas, Russo discusses:

Why end-to-end encryption is no security panacea;
The merits of tokenization, Chip and PIN and other solutions;
His response to breached entities that say they were PCI compliant.

Russo brings more than 25 years of high-tech business management, operations and security experience to his role. He is responsible for driving the organization's policies, as well as meeting its goals to create education programs, establish pools of certified Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs) and incorporate feedback from all stakeholders across the payment chain into the work of the Council and the development of new standards. In addition, he oversees the PCI Security Standards Council's training, testing and certification programs for QSAs and ASVs.

LINDA MCGLASSON: The future of PCI -- how do you see it shaping up?

RUSSO: At this point, it's a busy future, is what it looks like to me. I made an analogy this morning about yelling at the ocean because the tide keeps coming in and washing away your house. The tide is going to continue to keep coming in; it's not stopping, no matter what we do. There's always got to be something that's got to be done, and hopefully we'll stay abreast of what these things are by getting feedback by people that are dealing with it on a regular basis, added with the experience that we bring to the table. But this feedback is invaluable to us.

MCGLASSON: In terms of end-to-end encryption issue and tokenization, where do you see those two playing out?

RUSSO: End-to-end encryption and tokenization are just two of 20 or 30 or 40 different solutions that can be added on to make you more secure. Every time we talk about security, the first thing we say is 'Take the layered approach.' So, they're two more things that you can do, but they don't negate the need for the standard. I think Chris Novak said there were no silver bullets out there really, and there is no silver bullet out there. As you're encrypting, you have to decrypt - [data] has got to be protected at that point. I don't like the term end-to-end encryption; I like the term point-to-point encryption a little better. And what point are we talking about? From what point to what point? When somebody says end-to-end, the connotation is that it's true to the entire process, but very often these things will encrypt at the swipe and decrypt at the processors, and then re-encrypt again and then go someplace, and there are keys that have to be handled throughout this thing. It's just horrendous. It is a solution; it will probably save you some effort on complying with the standard, certainly not totally. But there's a price to pay for it. You really need to think about what you're doing, and the reason that we're not endorsing one or the other or any of these things is because, as I say, there are 20 or 30 of these solutions out there. Some people have already invested money running down that path, and we can't forsake what they've done for recommending something else. There are multiple ways to skin a cat, and we're concerned that it's secured. That's all we're concerned about, and if you do it one of 10 different ways, fine.

MCGLASSON: Tokenization -- same drill?

RUSSO: Same drill. There are lots of people out there using tokenized solutions at this point. They don't cover the entire thing. They're really, really good, some of them out there. We'll be looking at not endorsing a particular product or service from somebody. We will be looking at these technologies and say, 'Okay, if you're using a tokenization-type technology, it needs to do these five or six or seven things. It has to be those things; otherwise, we're not going to recognize it as being something that you can layer on to the standards.' So, we've got to find out more; we've got a lot of raw data coming today from PriceWaterhouseCoopers. It's raw, raw data. There are no recommendations. We asked them to do some surveys and research for us, and that's what they've done, and they're just going to come back and say, 'Okay, this is the result from the survey, and we asked people these questions, and we heard this back. 'So, these are the things that we're hearing, and we'll have to look at those in conjunction with other things.

There are solutions out there like Chip and PIN. These are mature solutions that we know work in some areas and do certain things, so we didn't really ask them to delve too deeply into that area. They're well defined; the brands have been using them for many, many years overseas and now in Canada. We asked them to look at things that we thought were sort of new. And while encryption is not new, the way people use it is new. And now -- not to mention any names -- but you're hearing a lot about encryption now, people waving flags and saying, 'This is the end-all, be-all, and this should be required within the standard.' I think if you were listening to Chris Novak, you heard that all of these [breaches] that you're reading about were very simple cases of noncompliance. So, why go through the expense, and why go through all of the heartache of putting a solution like that in? Because, first of all, it's not inexpensive to do it. Second of all, the amount of technical expertise required to do these things is quite a bit. And the chances are, if man can make it, man can break it. There are some issues there, and why do we want to require somebody to do that if, in fact, the standard is covering what some of these issues are? We heard an independent third party just say, "This wouldn't have happened, and some of these things are pretty well defined. Vulnerabilities have been out there for years and years and years, there's no reason that this should have happened."

MCGLASSON: On the legislative side, Nevada is one of several states that are just passing a data security law that has PCI compliance written into it. Anybody who does business in Nevada will be held to it. Your take on future legislation?

RUSSO: We're not waiting for these guys. We've been out in front of this before the PCI Council was formed. In fact, the industry has been out in front of it for five or six years at this point. We're not waiting for them, so we're way out in front of the curve, and anything that they do now to blame, and bring more attention to what's going on out there, what needs to be done, is welcome. I welcome the fact that they're talking about PCI, and they're more importantly talking about security. But, ultimately, we're the experts of the industry.

MCGLASSON: Have they come to you?

RUSSO: Yes, they have. They have come to us and asked us questions. I spend a lot of time in Washington D.C., not so much lobbying for something that I want done, but educating people specifically on what this really means. Because in the absence of anybody else talking, they believe whoever is talking at this point. When we go up, and we talk to them about these things, it's not to refute something that somebody else has said, but basically to educate them. And when we do that, they go, "Wow, really? That's the case?" Yeah, that's the case, and we can -- we can corroborate it with independent third-party people who'll say, 'Look this stuff is all hammered into the standard.' And [then we hear], 'Well, they said that they were compliant.' Then we go back to our old stand-bys: Compliance is a snapshot in time. It's a marathon; compliance and security are something that you have to live everyday. You can't just pass the test, put the certificate up on your wall and then not think about it for another year. You have to do it.

Now, these companies are suffering because of it, and there's a lot of finger-pointing going on. A lot of people being thrown under the bus, okay, and we're doing our part to make sure that our end is held up with getting all of our QSAs certified. They're all going through a QA program that we've got out there.

MCGLASSON: How many have left the QSA program because they weren't able to recertify?

RUSSO: Maybe three or four. I don't have the number exactly, but there are a number of them are in remediation at this point; we don't hide this fact. You can even go to the website, and if one of them is under mediation, they're red on the website. So, they're all going through this process; they're all being tested. It just irks me when somebody says, 'The problem was with the QSA.' Okay, tell us what the QSA did wrong, why the problem was the QSA. Show us what the QSA did wrong. A lot of these QSAs have been through the QA process -- they go through it once a year, have been through it, and we found nothing that they are doing to be wrong. When we ask, 'What did they do wrong,' and we don't get an answer, that's one thing. And then when somebody says, 'The standard is good, but, we were compliant,' which leads people to believe the standard is not good.

This is where the government comes back and says, 'Well, wait a minute; if they were compliant, why did they get breached?' And we try to explain to them that they were not compliant, but they have the certificate. For example, if I don't keep batteries in my smoke detector, and my house burns down, it's my fault. Because you have to stay on top of this stuff. So if they said that they were compliant, they've got to document and prove that they were compliant.

And if there's something wrong with the standard, I need to know what it is. I reach out; anytime there's a breach. I reach out to whatever company the breach happened to, and I say, 'Look, I know you're going to be going through lawsuits, and I know you're not going to be dealing with a whole lot of information. But if you can share something with us -- if there's something wrong with the standard or something wrong with the way our QSAs are dealing with you -- tell us what it is; we want to fix it.'

MCGLASSON: Other topics to be discussed in the coming days?

RUSSO: I think people are looking for assistance with technology, making it easier. We're hearing a lot now about Level 3 and Level 4 merchants -- can we come up with a solution for them that they can just buy off the shelf and become compliant? We're going to be looking at the things like that. We're reaching out to a lot of these Level 4's. We just released a document recently that covered skimming best practices. It's surprising the amount of press that we're getting on it, because it's geared not only to the Level 1 and 2 merchants, but it's geared to these Level 4 merchants. It is filled with "aha" moments and some common sense kind of things that people don't think about that they really need to do.

Unfortunately, if you're in business today, and you want to take credit cards, you have to be thinking about this stuff. You really do, because, literally, if you're a Level 4 merchant and something happens to you, you might go out of business. Forget about fines; it's that you could literally go out of business.

For a small Mom and Pop shop that takes a dozen credit-card transactions a week, this could be disastrous. They don't know about these dangers, so it's an education process. It's about cards. Everybody along the chain has to be educated, and unfortunately it all comes down to the merchant at the end. It all comes on the merchant's shoulders.


About the Author

Linda McGlasson

Linda McGlasson

Managing Editor

Linda McGlasson is a seasoned writer and editor with 20 years of experience in writing for corporations, business publications and newspapers. She has worked in the Financial Services industry for more than 12 years. Most recently Linda headed information security awareness and training and the Computer Incident Response Team for Securities Industry Automation Corporation (SIAC), a subsidiary of the NYSE Group (NYX). As part of her role she developed infosec policy, developed new awareness testing and led the company's incident response team. In the last two years she's been involved with the Financial Services Information Sharing Analysis Center (FS-ISAC), editing its quarterly member newsletter and identifying speakers for member meetings.




Around the Network