I'm conscious we can get really boring on crypto.
I really want to do one more thing on crypto.
We should.
Right, which is this; we always ask the question,
is this a way that people get compromised?
You know, I think this is the more complex attack vector.
I think this is where you're talking about risks and rewards, right?
The average, you know, burger joint, laundromat,
hotel, the attacker is going to go after the data in transmission,
right, which we'll talk about next.
Now.
Right.
That's really interesting.
So when I was in the card brands, the attack was against stored cardholder data,
because people did store cardholder data then in ways that they don't now,
and they were always going, oh, it's encrypted,
and the encryption keys were always taken because they
were still in the same database.
Right.
So three or four years ago this was a massive cause of compromise.
The people would take SQL databases with the keys in a
text file mixed in the SQL database, or even better,
in the SQL database in a table called Encryption Keys.
Right.
Now I would say the sort of primary ways of handling
payment card data and encrypting it, that attack vector is less easy.
There are still organizations that, and this frosts me to no end,
right,
that lean on the disk encryption or volume encryption subset of
PCI DSS for servers that are kind of always on,
right?
So just to back up.
This is requirement 3.4?
Maybe 3.1.
Let's just get it on the screen.
Yeah, let's do that.
This is one that absolutely drives me bonkers.
The problem is,
so my view of this requirement is it doesn't know what it's trying to do.
So if you encrypt a hard disk, right?
My laptop hard disk is encrypted.
If someone physically takes my laptop,
the data on that laptop is safe because it's physically encrypted.
If your laptop, I mean if I take your laptop right now while it's powered on,
while it's logged in?
I've had it.
Right, yeah, that's not so useful.
When I power my laptop off and I put it into my bag
and I'm walking down the street,
if someone koshes me over the head with a sock full
of quarters and takes my bag, the disk encryption is engaged,
and by the time you crack the crypto key to get at that,
I'm going to find you, right?
And I'm not going to be very happy about it.
So disk encryption is great for protection of
physical assets that may be stolen, but what about logical assets?
Well, so if it may be stolen and the disk encryption is engaged at the time,
right,
this is the thing I have to harp at for my colleagues when we talk
about our own information security practice,
power this off.
If you just put it in sleep and throw it in your trunk, it's not helpful.
It's decrypted.
A server or a disk storage array or something like that
that's relying on disk or volume encryption,
it has to decrypt that to use it, right?
So the server that's always on,
except for those infinitesimal moments where it's rebooting,
right, is always in a decrypted state.
So does that meet the requirement in the standard to
encrypt cardholder data in storage?
So many organizations would argue that it does,
right,
because there's no provision in 3.4 .1 where it talks about disk
encryption that limits it to those particular states and so there are a
lot of organizations that sort of lean on that and say,
well, at least we're doing disk encryption,
and my argument is, but it doesn't do anything,
right?
And there's another sort of variant on that,
right, where there's like whole database encryption?
Transparent data.
Transparent data encryption or where you have the
appliance sort of sitting in front of,
you know doing the cryptographic action kind of back
and forth in front of the database, and then you know,
then that turns a cryptography problem into an access control problem.
If your access control is insufficiently granular,
right, if everybody can query that database and get the decrypted values,
you know,
now you've got a hardware device that's burning electricity and
warming the planet and not really doing any good.
So again,
the message there is that the cryptography might not fix your security problem.
You might be able to get it past an assessor,
a poor assessor would allow disk cryptography,
yeah?
Yeah, so well,
and what it tells you is that good cryptography doesn't fix bad architecture.