PCI Compliance Update: 'There is no Such Thing as Absolute Security'

Interview with Michael Gavin, Security Strategist and PCI Expert
PCI Compliance Update: 'There is no Such Thing as Absolute Security'
Take this Survey Now Let's cut to the chase: PCI compliance for retailers, banks and service providers is hard.

Michael Gavin, security strategist at Security Innovation, a PCI QSA and ASV assessment firm, offers his insights on PCI compliance struggles, i.e. the Hannaford breach, and the reality that there is no absolute security. A former senior information and risk management analyst at Forrester, Gavin is a highly respected information security professional who speaks at industry conferences and has been quoted in numerous industry publications on information security and risk management topics.

Q: What's your take about what happened at Hannaford Brothers?

Gavin: I think every retailer out there has to acknowledge that they could be the next Hannaford. I think that Hannaford is interesting for a couple of reasons. They were the first ones to announce, "Hey, we were doing everything that PCI told us to do, and the assessor was in here and the day we were notified was the last day they were here." They claim they were doing everything right. They might have been; they may not have been doing everything right.

But there will come a day when someone who is doing everything right will be breached. No matter what PCI says, no matter how good it is, there is no such thing as absolute security. There are ways to beat people who are compliant right now. One of the areas that PCI is concerned with -- vulnerability management -- requires quarterly scans. What those scans are looking for is the presence of known vulnerabilities and common misconfiguration errors.

So, let's say I'm PCI compliant, and I have everything up to date from the vulnerability announcements, and I'm making sure my controls are in place, and a new vulnerability is announced. What happens then? The software vendor most times is already working with the security researcher who found the vulnerability. So hopefully they have a patch ready, but it's going to take some time to get put out and then distributed to everyone. There will be a period of time between when the vulnerability is announced and when a retailer or company has the time to update all of its machines for the vulnerability with a patch.

There is a certain period of time that a hacker could get in. In addition to just asking the retailer to put controls in place to prevent certain things can't take place, PCI also asks the retailer to monitor them. So this means if the retailer really is doing all of the things they say they are doing to be compliant with PCI, they will notice something wrong pretty quickly. The retailer may not have been able to get the patches installed until the fifth day after the announcement, but the other controls in place would alert them to suspicious behavior and being PCI compliant I would alert others quickly and contain the amount of damage that can happen. That's what PCI buys the retailer here -- it doesn't buy 100% security, but it does contain the amount of potential fraud that could happen, and that really is what PCI is all about.

Q. What are the pros and cons of the PCI regulation -- what is working, what isn't?

Gavin: Everyone says PCI is very prescriptive, and in many ways it is. One pro is that it is getting everyone to improve their security. There's a lot of argument in the media and blogs that compliance with PCI doesn't equate to security. I certainly agree with that, but I think the whole argument is a bit overblown. Companies that have become PCI compliant and are improving their security in general - that all is a good thing.

The other pros about PCI is that other "obscure" or less well known corners of the information security domain are brought to light to companies. Basically, attackers are going to look for a way in, and in the last 12 years of improving perimeter security and network controls at companies, attackers see that and then move on to something else. One of the things that PCI is good at is saying, "Where are the attackers hitting us now?" This helps companies find the next hole they have to plug. If you look at how the PCI standard has evolved, known vulnerabilities are one area where it has evolved. Quarterly scans are now required as part of the control to prevent people from getting into your network through known vulnerabilities that you should have patched. Another area that has evolved is wireless, and another is application security. I think the application security is of growing concern -- the fact that requirement 6.6 has grown from being a best practice to being one of the requirements, and the fact the PA-DSS came out recently are indications that there is growing awareness among people involved with PCI Security Standards Council and the various card brands that the application layer is really still a major concern at this point and must be addressed by people who are processing card data.

Q: Is the PCI Security Standards Council doing its job?

Gavin: Yes, they are doing a pretty good job. They've raised awareness significantly and made great strides in making it easier for companies to be PCI compliant. The entire formation of the PCI Security Standards Council and PCI-DSS has made it so much easier for retailers to be compliant. It used to be it could be two or three assessments by individual card companies, and the retailer would still not be compliant. Now a company just has to have one qualified security assessor (QSA) who has been certified on PCI-DSS assessments and the different card brands' programs to perform an assessment. It has streamlined the process.

The card brands have dictated the process and have their different acquiring banks responsible for the security of credit card information for themselves and anyone who is sending credit card information to the acquiring bank. They basically played this game of telephone where the card companies told the acquiring banks, "Okay, so this is what has to get done," and then the banks have told the merchants, "Okay this is what you have to get done." One acquiring bank may have told a merchant this, while another acquiring bank may have told their merchant something different. Some acquiring banks didn't tell anyone anything for a long time. One of the problems was this game of telephone, where merchants came to their QSAs and said, "Okay, this is what my acquiring bank told me to do."

One of the strengths (and weaknesses) of how PCI is implemented is that QSAs have the job of interpreting what is happening, and there is a difference in interpretations from different QSAs as well. One of the things the PCI Security Standards Council is working on now is fairness and consistency across all QSAs that the rules are clear and the assessments are done consistently and the QSAs have the information they need to make valid judgments. So that it is not going to be the case that you go from one QSA to another and get vastly different answers. They're looking to get a level playing field for everyone involved. They've been working on that for the past four or five months but it's not ready to be rolled out yet.

One of the things that happened with PCI, as what happens with any set of regulatory requirements, is the organization moves kind of slowly. It takes a while for things to be changed or implemented, and there's a good reason for doing it this way -- they want to make sure they're doing it right.

The way that PCI was rolled out going from the card brands to the acquiring banks down to the merchants has caused some problems because the service providers were kind of left out of the loop. The acquiring banks don't usually have ongoing relationships with the service providers, although some of them do, such as the payment gateways. But the majority of them don't have a relationship with acquiring banks; they have a relationship with the merchant or someone else in the chain, even another service provider.

One of the requirements states that in order for you as a merchant to be PCI compliant, anyone you pass the card information onto must also be PCI compliant. It's written pretty plainly that you as a merchant must ensure this is the case. The way that it was rolled out, service providers weren't made aware of this, and so it left very few choices in the way of PCI-compliant service providers. Last October the PCI Security Standards Council changed the interpretation of this requirement regarding the compliance of those service providers. There are certain refinements like this that are causing problems and making sure they don't become roadblocks for compliance.

Q: Does this change affect whether a merchant would be liable if card data goes missing at a service provider?

Gavin: The merchant still has to manage the risk of where is this data going and what will happen to it once they pass it off, and how secure is it because if it is stolen. The merchant still has to do that risk management exercise.

Q: What are some examples where you see PCI succeeding?

Gavin: I've seen quotes in the press where it was stated that compensating controls are a loophole -- they aren't. Compensating controls are a fairly elegant mechanism that allows a person to become PCI compliant and remain PCI compliant. It allows them to show they are meeting the intent of the PCI requirements, although they may not be doing it in the prescriptive manner that PCI is documented as. For example, one of the complaints about PCI especially from small to middle sized businesses is that it will require them to re-architect everything, and they would be made to buy all sorts of new infrastructure products. It would be too costly and too onerous. PCI is really about asking merchants to protect the data; if they don't want the responsibility, then they can just stop accepting credit cards. To become PCI compliant really just means that you have to show that you are protecting the credit card data and managing any risk involved. If you have an environment with controls in place and they're not exactly the same as the ones prescribed by the PCI standards and various requirements, if you can show you have other controls in place that provide as much and more security as the intent of the original requirement, then you can use that as a compensating control. So the elegance of this is that if a merchant does have controls already in place and is taking security seriously to comply without having to break the bank in terms of redesigning and adding new equipment, it allows the merchant to still use their old back end mainframe that has only a six-digit password available. As long as this mainframe access is controlled by another layer of password access with a minimum of seven digits, this would be a successful compensating control.

Q: How does the upcoming June 30th deadline affect financial institutions?

Gavin: It will affect acquiring banks and issuing banks because they both have to be PCI compliant because they are both handling credit card data. Everyone, the issuers, the acquirer, the merchants and the service providers are all impacted by this change in the rule. The one thing that is unfortunate, and I don't know how this could have been dealt with in a better way, is there is not enough awareness about this change.

Last year when we were doing assessments and we were telling clients that it was a best practice now -- you don't need it, but by the time we come back next year you will be compliant with it because it will be a requirement then. I'm not sure that every QSA did that and told merchants that they would be required to be compliant with it before the June 30 deadline. With the recent update that came out on April 15 -- I think that it woke a lot of people up because they didn't know about how it could be met. Many people don't know what a web application firewall is; I've been involved with them for quite a long time (early 1990s).

One thing that is of concern to me is that some of the network layer firewall vendors are talking about deep packet inspection are leading prospective clients astray. Why? Network packet inspection just looks at the headers on an email. The deep packet inspection they're talking about looks at contents as well. Web application firewalls don't look at packets at all; it takes a collection of packets together and requests a response that the server is going to see.

A web application firewall is akin to reading Shakespeare a line at a time. A network layer firewall is like reading Shakespeare a single letter at a time, not remembering what the previous letter was. So you don't have the context to understand what you're looking at from a network layer firewall inspection or any other type of inspection at the packet layer only. The web application firewall sees the bigger picture and puts it in context. So it can look for malicious input in certain fields. I don't think we need every gas station owner or restaurant owner involved with the security of their systems. We don't expect them to be information security experts. But they are in the front lines of this battle in protecting credit card data. One of the things we've recommended to some of the smaller clients we work with in the Boston area is to outsource this part of their business. We recommend they do their homework and find someone they can trust to keep their business PCI compliant. There is a trade off and risk is still involved.

Q: Are we winning against the criminal hackers?

Gavin: One of the problems is that it is an arms race, us versus the hackers. There's only so much we can do to fight them. The smart attacker is going to encrypt the data they're stealing before they send it through a firewall in case the company is monitoring the information leaving their networks. An information security professional will be reduced to looking at differences in patterns of outgoing information, and that could just be an anomaly, or it could be because an attacker is attacking your network. There's no sure-fire way to prevent or notice it at all times, but there are ways to make it harder for the attacker to attack. PCI makes it harder so the attackers will go someplace else. The survival of the fittest means if you're not as fit as the rest of the pack you will be taken down.

Q: With the number of retailers being breached and making headlines, do you see consumers making a decision on which store to shop at because of the breaches?

Gavin: When looking at the TJX breach that was announced in January of 2007, the news of the breach was a minor blip in TJX's sales, and their sales actually increased. I hate to say this, but it is true. It is something that we as information security professionals need to consider: Do people care that their credit card information was exposed? They've gone back to TJX and spent more money, and I'm sure that they didn't switch to cash for the most part. I'm sure for the most part that the shoppers are still using their credit cards at TJX's stores. What does that say to us? Does it mean we need to do a better job at educating people or should we just throw our arms up and find something else to do? I know my personal answer to this, but as an industry we need to think about this for a bit.

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

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.