- How do the PCI guidance documents actually work, and have they been helpful?
- PCI council guidance on mobile payment
- End-to-end encryption and its overlap with tokenization
- The use of virtualization and virtual payment systems in cardholder environments
- What it means when a service provider is PCI compliant
Watch the first part of this interview: PCI tokenization: Credit card security policy guidance.
Read the full transcript from this video below:
PCI encryption, virtualization standards: Interpreting PCI guidelines
Rob Westervelt: Hi, I'm Rob Westervelt, thanks very much for joining us for this video. Today we're going to be talking about the payment card industry data security standards, and more specifically, some of the emerging technologies around it, tokenization, end-to-end encryption, and visualization. Joining me is Ed Moyle, and Diana Kelly, of Security Curve. Thanks very much for being here.
Diana Kelly: Thanks for having us.
Rob Westervelt: Diana, let me ask you about all of these guidance documents that have come out of the PCI Council. How does it actually work, and have they been helpful?
Diana Kelly: This is a bit of a sticky wicket in that the council is now with the DSS, the Data Security Standard, on a three year revision cycle. This document is incredibly important to get right. A lot of people, as you're going through the compliance process, anybody who's gone through it knows, what that document says is what you're going to argue about with the QSA, with whoever is doing the assessment. So getting that right and changing it slowly enough so that people aren't, [A] shocked by big changes, and also [B], you didn't introduce some wording that actually going to cause more confusion or problems than it's solving. So you want to be very right about that wording, and about any technologies that are mentioned. However the problem is, that as emerging technologies moves very quickly and we can see this cloud as a great example. Three years in IT in the cloud space, talk about Internet dog years right there. This has really gone very, very quickly. So organizations are also looking for guidance about these emerging technologies so the council has these special interest groups, SIG's that look at particular questions that may not yet get wrapped into the DSS. One that's already been out, it's been out since 2009, is the wireless SIG. So for anybody that's familiar with that, that's what one SIG that's already published. Another SIG additional guidance on visualization and some other areas where they're working are tokenization, Visa's published best practices, the council hasn't yet. Point-to-point encryption has a little bit of guidance, but there's arguably more work going on. Also pre-authorization, and scoping are other areas where there's special interest groups that are looking at emerging pieces that aren't yet ready to be completely rolled in all that guidance into the DSS, but are still really critical for companies to look at as they're trying to figure out what their compliance process is going to be for PCI.
Ed Moyle: One of the areas I don't think you mentioned, and I'm not sure we've a whole lot from the council on is the mobile space, the mobile payment space.
Diana Kelly: Yes, mobile payment is moving very quickly. Google already announced essentially, we're talking about your phone becomes potentially your credit card. I think this is going to go very rapidly so, I expect that we'll get some sort of special guidance from the council, because we're on a three year cycle. It's not going to be in DSS as quickly as we're going to need guidance out in the industry for it.
Rob Westervelt: End-to-end encryption guidance came out at the end of last year, has it been helpful?
Diana Kelly: Essentially with the point-to-point the concept is that, if I swipe the card at the moment of swipe it's encrypted, so it goes off of the swipe device, point of sale and it goes all the way to the back-end encrypted. So as it's traveling, it's not visible, it doesn't need to be visible, and you can send it, if you really go to the very end point, send it all the way back to your processor, who ever the processor, whether it's an intermediary, or it's the acquiring bank. At that point you don't have to worry about where it goes because it's safe, it's secure, it's in it's own encrypted container all the way up. So I think from that perspective it's good, but remember you do have both ends need to be ready to encrypt. So that's really where the problems come in that we've really got a lot of point of sales, that don't have the encryption swipe. We also have processors that don't necessarily want to get encrypted. So it's more about getting the pieces on both ends correct. But once these are in place, I think it's really a great technology for making sure that you've exposed that number as little as possible and you're not storing it in the clear, and sending it in the clear, you're protecting it from the beginning to the end. I think that we could get a little bit more from the council. I think one of the issues with it is, because not everyone goes and reads the additional guidance or knows when it's available, it can be missed, so I think that's one of the big issues is it being missed. But I think is useful and going forward, for people that hate compliance and hate certification this may not sound great, but getting forward to the path where we're starting to actually certify the systems themselves. The point of sale and the encrypt on swipe. These are certified so that the organizations know that they're buying something that's been certified. I think that 's going to really help companies so that they have a high assurance when they go out and do the purchasing.
Rob Westervelt: And Ed, this kind of overlaps with tokenization right, because there are some vendors that actually offer tokenization and end-to-end encryption.
Ed Moyle: That's a good point, there are, and it's a little bit interesting to me, just from a standardization angle, because you were talking about standardization just a second ago. From a standardization angle it's kind of interesting to me, because the road map document, at least from the end-to-end encryption, point-to-point encryption road map document that's out currently. They're teeing up, it looks to me, and I think they pretty much say this, that they're teeing up a whole plan for how to certify products, how to do some very specific technical work in that area. And they've certainly done, if you look at pin security for example, they've done a lot of very technical work in that space. So I think they're going to do a similar thing in the encryption space. But tokenization, I'm not aware of any plans to do that, and actually even right now, the tokenization working group is going through a little bit of a restructuring, and there's some changes going on over there that tokenization guidance itself is almost a year late from what they said they were going to hit. So I'm not seeing the same, I don't know if there's the same plan, or maybe it's on the road map and they haven't announced it yet. I don't know what they're going to do there, but it's just interesting to me from the standards side to see that play out that way.
Rob Westervelt: Let's switch gears and talk about visualization and virtualized payment systems. Are there a lot of organizations using it?
Diana Kelly: 2.0 helped us quite a bit, by saying in there visualization, that can be part of your CDE, and the one function per server it's now one function per server, or virtualized server. They did get that out there, we've got visualization guidance coming. As far as the number of companies using it, I haven't seen any hard numbers, but if you look at what processors do in the cloud space in part to help us use our hardware resources more effectively and you also look at the amount of interest that organizations had to understand if they could use virtualization, I think it's definitely being used, but as far as hard numbers, I haven't' seen any research on it, so I couldn't go out there with a number, but anecdotally, yes. Some processors in the cloud, and, certainly some companies and their own CD's are using virtualization right now in Oracle or data environments, and there has been from 2.0, the council has basically come out with this is something that can be done as long as you follow the rules of one function per virtualized server.
Ed Moyle: I'll tell you, one thing that is interesting to me is how quickly that side of it is evolving. Even a couple of years ago, I was a former QSA, and I remember having arguments with other QSA's about, I was hearing statements like it's impossible to have a cloud environment be PCI complaint for example is one thing that I heard quite often. Now if you look within the past year or two you see organizations like Amazon certifying as having portions of their environment being PCI compliant. Visa has a whole list of folks that are service providers that are certified. So I think it's evolving and I think it's really quickly evolving, and I think it's high time to, I really do I think it was needed.
Rob Westervelt: So Ed, do enterprises really know what it means when a service provider says that it's PCI compliant?
Ed Moyle: I don't think they do. I think a lot of merchants and organizations misconstrue that, to mean that if they use that environment, that now they're PCI compliant. Which is not the way it is at all. Vendors, have the options of specifically what they can certify. So if you're looking at infrastructure as a service provider, or looking at a platform as a service provider, or software as a service provider. Obviously depending on the choice that you make, you're picking what level of the service they have control over, and what level of the service you have control over. So number one, they're certifying a portion of the controls that they implement. Maybe it's physical security, and log monitoring, and something else. What ever it is, they're picking and choosing what they're certifying to, and what their ROC is going to cover. So that's number one, and number two, keep in mind, you take a compliant platform and install a root kit on it, and say hey, come get my credit card numbers. That's not a compliant environment, and so that's one you. You still need to do what you need to do, and now it's extra work. Because you have make sure you go out and validate what your vendor has complied to, and what they've certified to, to make sure it fits into your plans.
Diana Kelly: I think of it as a components been certified, but still how you use it in your context matters. So say you buy something that's UL certified, and you know you can plug it in. But it's a piece of electrical equipment. Used under correct circumstances it's fine. You take that same toaster, and you drop it when it's on into a bathtub, all bets are off. It was UL certified, but you used it in a context that's actually going to break it, and that's a similar thing. So Amazon, and AWS can be certified, but then your whole CDE as it interacts with that has to be used properly and configured and managed properly.
Rob Westervelt: Well Ed Moyal, Diana Kelly thanks for very much for being here.
Diana Kelly: Thank you.
Ed Moyle: Thank you for having us.
Rob Westervelt: And thank you for joining us. For more information on this topic you can go to SearchSecurity.com.