Okay, and then we get to requirement 3.3,
which is my favorite because it's one that really frustrates me,
which is this thing about masking cardholder data when it's displayed on screen.
Now the PCI Council, you know, have a glossary so they define what masking is,
and we're going to talk about truncation in the next module.
Right.
There is an FAQ about masking and truncation,
and I know a lot of people get them really confused,
so before we go into like some practical examples,
I just want to make sure that we can see on screen that there is an FAQ that
talks about the difference between masking and truncation.
So masking is displaying, you've got a whole PAN,
but when you display it, you put stars in it.
So the person seeing it doesn't see it, but the whole PAN is there.
It is there.
So it's sort of like behind the asterisk.
Right.
So the entity still has the card data.
Right.
And truncation is where you take bits out,
and you never have the card data anymore.
You replace it with stars, yeah.
So masking is just on screen, but the card data is there,
and the requirement says something like,
and I'm doing this from memory,
but you need to mask card data when it's displayed,
unless the person's got a business requirement to see it.
Right.
Okay, and I have this terrible problem,
actually with the merchant where their QSA had said,
well the people on the telephone answering the card data,
it had to be masked.
So as they were typing it in, it was asterisks,
and you can imagine what happened was their authorization rate declined,
but they kept typing the number wrongly because they
were listening to it on the phone,
but the QSA said they weren't allowed to see it on screen.
Is that right, because that struck me as idiocy.
Well,
I think that fails to sort of recognize that there's a
legitimate need to see the PAN in that case,
right?
While that contact center agent or while that person that's hearing it on
the phone or handling it in person is keying it in,
sure,
see the card number; there's a reasonable case to be made to say that
person has a justifiable reason to see the PAN.
Now once that transaction is over, that phone call is ended,
you've handed the card back to the customer,
do you get to then go, you know,
and you've processed the order from the cashiering standpoint,
do you get to go back to the order that you took an hour ago and go that PAN?
No.
Then it' masked, because you don't have a business need.
Right, but at the time,
saying you don't have a business need seems like a stretch.
So it's the worst stretch, because the person is actually in their other hand,
holding the card and can see the number,
and it's just like, there is no risk; there's no increased risk.
Yeah,
there's no incremental risk from displaying it on the screen
in terms of what that does for the person,
yeah.
That just seems like a way to increase errors and frustration.
Yeah,
so I think my key message is if you have an accessor that's
saying something that sounds really idiotic,
but oh, that person can't see that card number,
and you think, well, they're the fraud department,
they need to see the card number; that's their job,
right?
If it's your job,
PCI DSS doesn't say you can't do this; PCI DSS says very
clearly if you have a business requirement,
they can see the card numbers, and as an assessor,
you're looking for the business requirement,
aren't you?
Right.
Now, I've seen this go the other way where the organization says,
all of our people have a business requirement because they might
in some remote circumstance need to see the PAN for some obscure
thing that happens infrequently, right?
And that's kind of the shoe on the other foot, like that's idiocy, right?
Okay, the fraud department, fine.
Okay, cashiers, at the time of, fine.
Okay, maybe there are some other specific use cases,
right, but everybody always?
Nonsense!
So it sounds to me, common sense is what we're after here.
Generally, yeah.
Okay, that's requirements 3.1, 3.2, and 3.3.
So is there anything generally with those requirements we should think about?
So any architectural principles in terms of that,
or anywhere that people have failed their assessments when you look there?
Well, so I think with 3.3, with the question of who gets to see the whole PAN,
think about kind of the roles, alright,
the groupings of who gets to do that and who doesn't,
and then how you enforce that, right?
So if it's this kind of mishmash of oh, you know,
this person does and that person doesn't,
and this person does and that person does,
and they're all on the same team, they're all in the same group,
that's, you know,
then you have a very difficult time sort of managing enforcement,
right?
But if you're saying, okay, our customer service team generally does not,
but then we have a, you know, customer service plus,
right, that does these other functions and they have the right to do that,
right, and then you can clearly assign, you know,
people into those roles, good!
So you're looking for role-based, if you people see PANs,
you're looking for role-based access?
Yes.
And, you know, need-to-know basis basically.
And there's just some clear linkage between that, right?
How do you determine who gets that role?
How do you have those roles defined,
and then what is the enforcement mechanism for that role?
Okay, when we talk about any requirement,