one of the questions I'm always thinking about is,
is this requirement a common one for compromises?
Again, I think maybe 3.2 or 3.1 are things that make compromises worse.
Yeah.
I don't think the masking necessarily is common to compromises.
Honestly, with merchants, particularly smaller or medium-sized merchants,
yes, you decrease what we call your attack surface by eliminating storage,
right,
but when you look at card capture malware that gets deployed
on point-of-sale systems by attackers,
by and large it's capturing the data in transit.
So it's not going out looking for stores of cardholder data?
Yeah, the level of effort to attack even sort of badly encrypted,
stored repositories of cardholder data is usually higher than
sort of capturing it as it goes by in transit,
and the malware to what we call scrape the memory,
right,
where I'm scraping now or look for stuff in volatile memory as it passes
through the keyboard or the card swiper or whatever,
is pretty well defined at this point.
And we will talk about that in the next section,
because we're going to come to an obvious hole in DSS where we're both going,
yeah, that should probably be in that standard as well?
Somewhere.
So my experience is that as you say,
the stored cardholder data makes compromises worse,
and the excuse you usually get is,
we didn’t know that database of 5000 cards was there.
Right.
We didn't know as an organization we were storing that data.
So it's usually based around non-compliance with 3.1,
of I didn't know we were doing that, and also for 3.2 with CVD stores,
with e-commerce transactions, I didn't know we were capturing the CVV.
Right.
The developer didn't tell us they were doing it.
So when I've looked at any compromises that involve CVV2,
yeah,
there were some where people were doing deliberately so
they could do repeat transactions in CVV2 when that used to
be a financial benefit to them, but it isn't now.
It isn't now, and it hasn't been for a long time.
And some people don't know that it isn't a financial benefit.
Right, yes.
So they still think they get their interchange rate if they have the CVV2.
Yes.
Then they haven't read the fact the rules have changed.
Right.
So it's always been, but generally it's been inadvertent storage,
and if you look at some of the action,
there were some quite big breaches in the U.K.
where our information commissioner took action.
You know, they had stored cardholder data,
they just didn't know they had stored cardholder data.
Right.
And we'll talk about this, you know, in the other course,
you know, achieving and maintaining compliance,
but part of that roadmap is finding cardholder data you
don't need and having that big clear-out,
you know?
Right, and well, if you go into the actual DSS itself,
right,
in the section before you get into the grit of requirements and read about
the scoping and you read about sort of the data flow,
alright,
there's some pieces there that talk about how are you identifying
your data flows and repositories of card data,
and if you're saying, oh, I didn't realize that this database had all this stuff,
or I didn't realize that somebody had copied this inadvertently onto some,
you know, work station or some piece of removable media or something like that,
then you've sort of missed some of the requirement-0 kinds of things.
The requirement 0 that isn't written in the standard,
but often people think about.
But it kind of is, but really should just have a section called requirement 0.
Yeah, there is a long story about that.
I'm sure there is.
There really is a long story about that.
I'm sure there is.