So the rest of requirement 3.
We've done the hard bit about let's not keep cardholder data,
let's not keep sensitive authentication data.
Now we're in Kansas,
and we are actually deciding as a business we have a legitimate business need to
store primary account numbers as PANs and cardholder data.
Right.
So now we need to protect them.
Yes.
So I want to think about this really in two ways.
The first bit is how are we going to protect them?
Right.
And then the second bit is okay, now we're going to use cryptography,
and then we'll talk about the cryptography stuff.
Sure.
So DSS gives us a few options, doesn't it?
Yes.
It talks about we could truncate them?
Yes.
It talks about the fact we could encrypt them,
and then it talks about tokenization as well.
Yes.
So let's run through very quickly the merits of those.
Sure.
So from a risk perspective, as well as your job as an assessor,
you know, obviously I'm guessing that truncation is the easiest to assess?
Truncation is the easiest to assess, right,
because at that point you're getting rid of what's technically
cardholder data and sort of rendering it down into,
you know, at most first six, last four.
So you're doing the Jedi mind trick?
This is not the cardholder data you're looking for?
Yeah, well,
I mean you're doing it and then actually like excising some
of the digits out and throwing them away.
So actually it's not a Jedi mind trick, it's actually magic.
Right.
Right, we've taken cardholder data, we've taken the middle digits out of it,
and we've turned it into not cardholder data.
Right, right, right,
and so now what you've got is just this limited set of
digits that's not the full number.
Okay.
How many, remind me, how many digits do I have to take out of the middle?
Right, so you can keep what they describe as the first six and the last four,
right?
So usually that's eight digits in the middle, am I counting right?
Six.
Six digits in the middle,
maybe five for American Express cards that you're pulling
out of the middle and getting rid of, right?
And you could do less, you could just keep the last four.
You could maybe,
I've seen like the first two and the last four or
similar configurations like that.
So if you've got some need for the last four for verification purposes,
right,
or you need the first two to identify the card type or
you need the first six for the bin, you know then you can do that,
but then the stuff in the middle, you get rid of,
and that's that.
And that's great because now as an assessor it's just truncating.
You can check in a database, you're seeing truncated card numbers.
Right, all these truncated card numbers and that's it.
Okay,
and actually we should talk a bit more about truncation because
there is a really good FAQ because now people are making card
numbers that are more than sixteen digits.
Sure.
In Europe we've had Maestro cards,
which have been longer than 16 digits for a while,
and now I know where're running out of card numbers,
the card brands are talking about adding and having longer numbers.
Right.
So there is an FAQ on the PCI SSC website,
which actually goes into great detail about how we can
truncate cards and what different brands allow,
because these are actually defined by the brand.
This is one of the weird things where the PCI,
where the brands write this bit for the PCI Council.
Right.
Because they've all got different rules about what numbers you
can keep and what numbers you can't keep.
So this FAQ is like the one place to look.
I guess you look at this as an assessor.
Right.
If you see someone with a 19-digit PAN, to refresh yourself about,
what do I do here?
Yeah, I know I used to like print this one out and carry it with me.
Yeah, that's probably a good idea.
Okay, that's truncation, now the next thing is tokenization.
Right.
I mean, talk to me about really, as an assessor,
what are you looking for to makes sure a token is a token?
Because that does strike me as a potential Jedi mind trick.
That has the potential to be more smoke and mirrors
than sort of useful substance,
and tokenization is one of those things that means slightly
different things in certain contexts.
So we're not talking about tokenization on devices like Apple
Pay or Android Pay or anything like that?
Correct, right, let's put that aside, that's something else.
This is a merchant or a service provider replacing the
card with something that's not the card?
Right, so then the question, the first question is,
where do you get the tokens, right?
If you or if the assessed entity is sort of doing its own tokenization,
it's got some vault somewhere where there's a database with two
columns and a PAN on one side and a token on the other,
I mean,
then it still has cardholder data stored and it still needs to
protect that according to what's in requirement 3,
and what that maybe does is then the database or some other system that's
using the token maybe even doesn't have those requirements about stored
cardholder data applied to those systems.
Yeah.
Right?
And maybe that's a benefit?
Yeah.
Good!
Right?
Well and good,
but you still have that sort of token vault that you have to contend with,
right?
I think that's more of a minority case.
The more likely cases, the payment processing entity,
sort of upstream from that organization gets the PAN from,
you know, the merchant or from the service provider or from,
you know, whoever the entity is.
Okay, so that's your payment service provider or your merchant acquiring bank?
Right, so you send the PAN as part of the transaction?
Right.
And they give you a token?
And they give you a token back.
Right, and then you can use that token to do what?
That depends.
Right.
So in some cases,
that token could potentially be used for recurring transactions?
Right.
And then I think you have some questions about is that
a quote-unquote high-value token?
Right.
If I'm the attacker and I capture that token,
can I replay that and affect some fraud?
So now we're talking risks rather than DSS because I'm
going to ask you as an assessor,
if you get a token back from your merchant acquiring bank or payment processor,
is that out scope now?
Is that a PAN or is that not a PAN?
I would say it depends, because that's the assessor answer, right?
But, so just pro tip, when the assessor says it depends,
right, make the assessor tell you on what it depends,
and that tells you if you've got a good assess or not.
Okay.
Right?
So it depends; if the token is limited to just that particular transaction,
right, such that it's not about that card number,
but it's literally just about that transaction and all I can maybe then do is
replay it to void that transaction or something like that,
then I think your risk is pretty small.
Yeah.
If that, and you know, or for particular merchant,
for that particular transaction, for that particular,
you know, use, right, that particular dollar value,
right?
Then your risk is probably pretty small.
If that token is good for that card number,
for that PAN and is not necessarily restricted to a
particular merchant or a particular transaction,
right,
and it could be replayed to go buy flat screen TVs from a big-box retailer,
right?
Now you've got a different risk characteristic.
So it's meant to be a PAN?
Right, and it really is.
My take was always also this, was like,
if the merchant can send the token to wherever it
got it from and the PAN back Yes!
Right?
That's very reversible and very easy,
how do they protect that and how do they protect?
So we're actually moving away from DSS and into helping people be secure, yeah?
Right, right, well,
and I'd say then if you've got a situation where you can
send the token back and get the PAN back,
right, then we at least have to test the,
okay, so now you get the PAN back, what happens,
right?
Does it get stored?
What system does it transit through?
Yeah.
Now we think about that, right?
And maybe those requirements apply in some capacity there.
And really also where can that happen?
So like if you have a payment switch that can do that,
it's probably okay because that might be in a nice secure area,
but if anyone in the organization can take that token and fire it
off to an API somewhere and get the PAN back,
that's probably not okay.
That's less great, right?
Yeah.
Okay, yeah, you know,
where I've recently been working we did a massive tokenization program,
and it was culturally the right way of doing compliance
for the organization of you know, you see a pattern.
In my view, tokenization is really weird,
is that as soon as, you need to tokenize as soon as you can,
because there's no point tokenizing once you've brought
half your environment into scope.
Exactly.
So your aim of tokenization is to tokenize as soon as you can see the card
number and de-tokenize the latest possible moment you do it.
Right.
So you know,
a lot of organizations will use devices like F5s and do
tokenization on the way into the network.
They decrypt the traffic, see the PAN, tokenize it straightaway.
You can tokenize it even earlier from that using
like content distribution networks, and they can tokenize it to CDN,
and then tokenize on the way out, literally when you go for authorization.
Because you know, if you're investing in tokenization,
and I don't know if you agree with this,
but my view is you should tokenize this as much as you can of your environment.
Absolutely, yeah, if you're going to go down that road,
if you're going to pay somebody for it, if you're going to,
you know, get those sort of premium payment processing services,
then you should derive the greatest benefit from it as possible.
Tokens are great for two reasons.
One is if a bad guy steals them, they can't do anything with them.
So they're not valuable so they're not going to attack you for them,
and secondly, it reduces your scope.
And so we're always talking about compliance here,
but tokens are great because they reduce your attack surface
massively and bad guys won't come and take them from you.
You know, it's not just about compliance.
Right.
So anything else we want to talk about tokenization before we move
onto the thing that we don't want to talk about?
Right,
I'd say the only other thing to consider is just making sure
that the tokens are not mathematically related to the PAN in
some way that could be undone.
So you can't like add 1 to a PAN and make it a token?
That's probably not a good idea.
Is there a standard for that?
Is there a way you can evaluate tokenization appliances or tokenization systems?
I believe there is, yes, I believe there is.
I asked that question because I spent a lot time when I was on the Council,
actually developing what turned out not to be a standard,
but there's a guidance document, isn't there?
Right, it's quite hard to find, but if you're doing your own tokenization,
there's a really good document that describes how to do it well.
Right.
And do you use that when you're assessing?
Do you say if a merchant says I've rolled my own tokenization system,
is that one of the ways that you assess it?
That would be what I would reach for,
but usually what I find when there is some sort of
tokenization effort where I can see both sides of it,
right, is that there's essentially a stack of kind of numbers,
sequential or randomly generated or whatever,
but sort of not meaningfully related to the PAN,
and then as PANs come in, they just take the next one,
right?
And so you know, are these numbers incremental to one another?
Yeah, but that's just the history of the last PAN that came in, right?
So that's very often what I see usually,
because people don't want to figure out more complex algorithms.
Yeah, my probably with some tokenization is some of it's done really badly.
Yes.
And you have to be really careful before you,
I mean,
this is one actually really good piece of advice; I hope you'll agree with this,
is that if you're about to buy a tokenization system,
get your QSA to be part of your RSA.
Absolutely.
Because the last thing you want is to buy a tokenization system,
the assessor to come along and go, but they're not tokens.
Right, they're not tokens, right?
You've just xor'd this with a 1 or something stupid like that, right?
You know, congratulations on dropping, you know, five figures on garbage, right?