There's been a lot of talk about transparency, but I have not seen in practice a huge amount of change yet.
"There's been a lot of talk about transparency, but I have not seen in practice a huge amount of change yet," said Diana Kelley, a partner at Amherst, N.H.-based consultancy SecurityCurve.
There has been a slow and steady uptick in adoption of cloud-based services. Merchants that are moving payment systems to the cloud or considering it are awaiting guidance from the PCI Security Standards Council (PCI SSC) to ensure they can maintain PCI compliance during and after the transition. Some progress is being made, Kelley said. The non-profit Cloud Security Alliance (CSA) is heading a movement to standardize the transparency of security practices within cloud providers.
However, many cloud service providers continue to force clients to sign contractual agreements, affirming the ultimate responsibility for the security of credit card data lies with the merchant. But far too few provide the visibility and documentation necessary to maintain compliance.
Most cloud-based services also decline to be audited, Kelley said. Large businesses can often use their weight to force a cloud provider to open up and accept an audit, but smaller businesses can suffer, she said. "If you are not a big enough account they could be willing to let your business go," Kelley said.
In an interview with SearchSecurity.com, Kelley explained how organizations are using the latest PCI guidance documents and why the point-to-point (P2P) encryption, tokenization and virtualization reports can help merchants efficiently reduce the scope of their cardholder environments and purge credit card data from their systems.
The PCI DSS won't get updated until the end of 2013. Are companies still investing in PCI compliance-related technologies?
Diana Kelley: There's the PCI DSS, and that's on a three-year update cycle, but some of the emerging technology is being addressed. Things you may be prioritizing right now are being addressed in their special interest groups (SIGs), and then they are coming out with separate guidance. At this point it's independent in that it's a separate publication from the PCI DSS, but I guess I would call it adjacent. You can look at that guidance, take it into account, and make it part of your overall PCI compliance program, but you still have to be PCI DSS compliant. That is still the overarching umbrella.
Some of the emerging technologies organizations are looking to prioritize with are areas like virtualization. There was a separate guide that came out last year specifically on virtualization. It touched on cloud. Cloud is going to be addressed in its own guide this year. Tokenization is another example of an emerging technology putting into their CDE [cardholder data environment] that isn't embedded specifically in the PCI DSS.
Let's talk about PCI compliance in the cloud. Are there architectural issues that are hindering adoption of cloud computing for merchants?
Kelley: Yes and no. We know there are three different architectural models in cloud computing: infrastructure, platform and Software as a Service (SaaS). When you are looking at how most people are adopting for PCI, if they are using the software it is often using a gateway. With that adoption model, if you have a gateway provider and they have gone through PCI DSS compliance, are certified, and understand where your scope ends -- and you're not storing the credit cards -- this can really be a benefit, especially for the smaller companies and even some of the larger ones. It's reducing the scope of what you need to do for PCI. You're not storing credit card data, you're not keeping it around, so what you have to do is prove that when you accept the card data it goes into that gateway payment provider and that payment provider is doing what they've agreed to do with the information. When you get down into custom payment software such as a Platform as a Service (PaaS) or Infrastructure as a Service (IaaS), the responsibilities change a little bit.
If you look at something like the infrastructure, you are responsible for protecting that data and making sure the controls and configuration in how that data is set up in the infrastructure and is managed are secure. But you may not have as much control as you actually need to make sure everything is being done right. In cloud environments, auditing is not allowed and you might not get all the logging information you need. So there's a little bit of confusion there. … There's a bit of a transparency log problem with cloud data coming back to us and really understanding what is happening in the cloud because you have providers that say, "It's my data center." How much are they really going to open up to let you see what is happening?
On June 30, PCI DSS 6.2 became a requirement. It is requires the establishment of a process to assign a risk ranking to newly discovered security vulnerabilities. Can you tell us about that and how meaningful it is?
Kelley: It's meaningful in the way we apply and do a vulnerability assessment and our understanding of vulnerabilities. Originally with patching of vulnerabilities in the PCI DSS, you had 30 days to get it done. Now they are saying you need to do a risk assessment, prioritize the patches and get the patches in a timely manner. You need to stay aware of what those vulnerabilities are and that you have a [information] feed to those vulnerabilities. It needs to be any sort of an accepted feed. You can use a public feed or vendors that do vulnerability management [provide a feed list]. This is something companies can do and most of them have implemented. The change here is really about how vulnerability management is done overall with PCI. Companies have already seen this coming; they are doing it and ready for it.
There have been a number of guidance documents out. The main message seems to be around reducing scope. Is that right?
Kelley: One of the strongest pieces is how you can reduce the scope and increase your protection capabilities. Looking at point-to-point encryption, if you encrypt on swipe, you don't have to worry because you've encrypted at the point of sale, it gets transmitted and encrypted to the endpoint, and where that endpoint is, is where the [cardholder data environment] CDE starts. You don’t have to have the CDE everywhere, you’ve got a point-of-sale. We've had problems with this. In a couple of the known breaches it has been wireless point-of-sales that are out on the shop floor, you swipe and the data goes through the air and is in the clear. Somebody can pick that up.
The point-to-point encryption guidance had interesting language in it. It said merchants should "work closely with their acquiring bank." Is that a new message from the council?
Kelley: I think it might be a fairly new message from the council. It certainly is not a new message at all in the PCI world. I've been saying this for a long time. I've talked to a lot of QSAs that have been saying it and analysts that have been saying it for a long time. The reason is because somebody has to do a tiebreaker. There will be a time when reasonable people disagree on the PCI report on compliance attestation process. You may get a customer and a QSA that disagree. Who is going to tiebreak that disagreement? If it is not specifically in the DSS, anything that is written down can be open to interpretation. The council does the best they can with clarity of language. The compliance programs are still owned by the five individual card brands. They would be the ultimate tiebreakers, but they don't want to get involved all the time. So very often the acquiring bank becomes the tiebreaker. Whether or not they want to be the tiebreaker is a different question.