- The benefits of tokenization
- Is tokenization a replacement for encryption?
- How widely used is tokenization?
- The costs of deploying tokenization
What questions should organizations ask of a tokenization vendor during the evaluation process?
Watch the second part of this interview: PCI encryption, virtualization standards: Interpreting PCI guidelines.
Read the full transcript from this video below:
PCI tokenization: Credit card security policy guidance
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
virtualization. Joining me is Ed Moyle and Diana Kelley of Security Curve. Thanks very much
for being here.
Ed Moyle: Thanks.
Diana Kelley: Thanks for having us.
Rob Westervelt: Ed, why don't we begin with you. What are the benefits of
Ed Moyle: Historically, part of the challenge with any kind of PCI compliance
exercise has been the broadness of the scope involved. Where most
organizations start is, they put the entire environment in scope. The
question is, given that any system that stores, processes or transmits
credit card data is in scope and any system that's not segregated from that
is also in scope, how do you limit what that scope is?
Tokenization, the entire goal is, take what that scope is, which is the
areas where the credit card number is actually in play, and replace the
credit card number with something else. That something else - there's
argument about what that might be, but basically some value that is not a
credit card number, itself.
That's really the primary benefit of tokenization. As far as specifics of
what that means and how to do it, there's been some best practice guidance
from Visa. They have tokenization best practices. A lot of folks, including
myself, and I think a lot of us here, at this discussion, are looking
forward with anticipation to guidance from the actual special interest
group from the council.
In absence of that, I think there's been some really good evolution of the
technology and I'm pretty excited about it.
Rob Westervelt: Is it a replacement for encryption?
Ed Moyle: Good question. The encryption and tokenization both serve to forward
the same goal, which is reduction in scope. Encryption, the strategy you
used to get there is to encrypt that data, because the council has
clarified in their FAQ, for example, that encrypted data can be out of
There's also been some guidance around point to point encryption. Not
detailed, technical guidance as yet, but their road map is out. In that document,
they talk about how to scope out areas within your cardholder data
environment by encrypting the data. They do serve very similar purposes,
it's just that the question is, how do you get there?
Diana Kelley: Right, and that's the important thing to note. Specifically, when
talking about PCI, or protecting sensitive data. Obviously tokenization and
encryption can be applied in different ways outside of PCI, but when we're
talking about protecting sensitive data. Then when you're referring to
rendering that card data useless to an attacker. If an attacker gets it,
then if it's tokenized, it's not a usable card number and if it's
encrypted, and it's done well, then it's not a usable card number, too.
Ed Moyle: That's a really great point, actually, one that a lot of people
overlook is, that people buy these products a lot of time specifically for
the purpose of PCI compliance but it doesn't have to be PCI.
Diana Kelley: Right.
Ed Moyle: You can encrypt other things besides a credit card, beside a PAN you
can tokenize other data beyond just a PAN. You can use it for things like
medical records, the tokenization. You can use it for things like Social
Security numbers, depending on the type of product that you purchase.
Obviously it's a complex market, but depending on the kind of product you
Rob Westervelt: How widely used is tokenization? Has there been some adoption?
Ed Moyle: There is. There's a little bit of complexity here and there's two points of
complexity that I would point out. The first set is that there's a lot of
folks waiting for guidance from somebody. From the council, specifically.
There's a lot of folks who have plans to deploy, who are looking to deploy,
but haven't yet done it because the officialness of the guidance that's
come out hasn't really been there.
Tokenization has been around for a long time. There's a lot of folks that
have been thinking about this for awhile, but haven't yet pulled the
trigger. The Visa Best Practices helps, but it's not something they can
say, "Oh the council has approved this." They know that they're certainly
working on it, so there's a little bit of fear there. That's number one.
Number two is, specifically, how they implement. There's two kind of
tokenization strategies. The first one is going with a tokenization that's
provided by your acquirer, or your payment processor. The other strategy is
something that you own and manage yourself. There are folks who are looking
at one or the other and there's pros and cons for each one, but there's a
little bit of hesitancy in the market, as folks seek to get to a unified
approach for how to do this. Like a standardization type of approach. It's
maturing and it's been around for a long time, but there's still a lot of
debate within the industry and discussion within the industry about where
it will ultimately go. I would say that I'm seeing a lot of planning. I'm
seeing a good amount of adoption, but it's certainly nowhere near
Rob Westervelt: Is it costly to deploy? Am I going to have to go out and get a
services team to help me deploy tokenization?
Ed Moyle: It depends, obviously, on the size of the organization. If you have a
relationship with one acquirer, if you're a smaller retailer, maybe you're
a very centralized retailer. You're a merchant that maybe you have a lot of
e-tailoring type of services that are online. In that case, if you can lock
into a particular acquirer or a particular payment processor. Sometimes
that transition can be very easy to do. Because of the fact that there are
some of these folks that are actually offering this technology to you as
part of their service offering. In that case it can be fairly easy to
On the other side of the spectrum, if you have relationships with, think
about a hospital, for example. A hospital gift shop might have a different
acquirer than the hospital cafeteria, which has a different acquirer from
the parking lot, from affiliated clinics. A hospital environment could have,
no exaggeration, potentially hundreds of different acquirer relationships.
In that case, if they want to tokenize, you're talking about a very
significant effort, as far as deployment. It really does run the gamut. I
know that's kind of a little bit of a dodge, but I think a lot of it has to
do with the complexity of the environment and the number of acquirers
Rob Westervelt: What kind of questions should an organization ask of a tokenization
vendor when they're evaluating that vendor?
Ed Moyle: What I would ask about would be the Visa Best Practices guide. In
absence of authoritative guidance from the council, I would say, "To what
degree do you adhere to these best practices?" Looking at the degree to
which they support you in terms of your obligations to meet best practices
in the deployment scenario. I think those would be the critical questions
to ask. A lot of folks would say, "Ask some of the bit, twiddly questions
about how they generate their token," or that kind of thing. I think a lot
of those kinds of questions will shake out as the guidance develops. My suggestion
would be to focus on what we know now, which is the best practices and to
what degree the vendors in the space can help you to get there.
Diana Kelley: Although one slightly bit, twiddly thing I would talk to them about
is what kind of protections they've put into their solution to stop
somebody from actually circumventing the solution or getting through the
solution, in order to get back to the number. Because ultimately, if you
can take this token and get back the credit card, or if you can take this
token and now use it within an internal system like the credit card. You've
got two different risk models there. Talk to them about what they have for
protections like that. One could be your own business process. Don't allow
for token reuse. May or may not fit the right business process, but
certainly you want to get your vendor to help you understand what about
going back with this token, getting that credit card, extracting it back
from the central place. Is this something that's easily accomplished?
Because if it is, and you don't have the proper controls in place, you may
not be getting the same kind of value out of it that you expect. In other
words, I've given you something that's not that useful, but I can give it
back very easily and get that original card number. What are their
protections in place? What have they done to test their own system to make
sure they've looked at misuse cases like that?
Ed Moyle: One last really important thing that didn't occur to me initially, but
as Diana was talking, it did occur to me. Also, if you can get some kind of
assurance from them, that they will support future proofing. It's one of
these things where from a technology, from an engineering standpoint,
vendors hear, "Well we replace this number with that number and that's our
product." It's very tempting to participate in this space and there's a lot
of vendors that do. One thing that's going to be important as the standards
around it develop is your vendor's ability to support you going forward.
Now if you're going with somebody who's also an acquirer or processor,
obviously you can have a little bit more assurance that they're going to
support you, because they have to, to support their business model.
There are some folks who are doing tokenization that maybe aren't as
developed as some of the others. If you're looking at somebody who
specializes in that, obviously there are some vendors who aren't acquirers
or processors, but specialize in that. I'm thinking along the lines of
Protegrity and New Bridges and those folks like that. You can have some
assurance there, but if you can get it in writing and you can get it at the
beginning. I think that's a good position to be in.
Diana Kelley: Some specific future, current proofing can be, can your vendor, you
alluded to, can you just take a number and replace it? Well, can you make
it look like the original number? Because your legacy systems, or who
you're interacting with, may require it to look like the original number. A
16 digit number, for example, with the last four available. These are some
of the things you want to look at to see if that program, or system, or
solution will fit with your business practices now and going forward.