Now, the PCI council tried to change that,
and they built a cut down version of PCI that was
designed for those merchant environments,
but it didn't really stop the problem.
And should I show you this hack now?
What do we call the cut down version just so we get the term right?
We call it Wow.
It's got a really sexy name.
It's SAQ, self-assessment questionnaire,
A-EP, self-assessment questionnaire, A for EP,
whatever EP stands for.
Okay.
I have no idea.
Maybe the key there is self-assessment,
so I imagine some criteria that you need to implement on your
website which then allows you to do this,
but it sounds like that may not be sufficient.
It's not sufficient.
And I was going to say,
this is about 50% of all card data compromise is seen by the
card brands across the world at the moment.
And like I know you're going to get into the actual tech now,
but when you say that the 50%,
is this 50% even though they have met this self-assessment criteria?
Yeah.
So what's the point of this self-assessment criteria if like
half of the breaches are owning the very thing that's there to
try and stop that from happening?
The problem really is that merchants are not great,
so I'm going to separate this out, large merchants,
really big e-commerce websites, big airlines,
big shops where you shop at online, they have a team of security people,
they can do the security properly, but smaller merchants,
even medium-sized merchants cannot do the security properly.
So they even get the question,
they don't understand the questions on the questionnaire,
and they've just gone and bought a hosted web server,
so a hosted shop from somebody; they're just trying to sell their stuff,
they're not experts at security, so they think they've got it all in place.
But you know the difference in doing security is not
only thinking you've got the control,
but making sure the control is effective and it's turned on all the time,
and when you patch you really do patch,
and you patch against the vulnerabilities.
So it's about the fact that security, I mean,
I think we both agree security is hard now,
it's not something that's really easy to do,
and so merchants struggle to do it right.
And you know the bad guy, the bad guy needs to get in once, right?
I'll give you a really great example.
I had a good friend who was a merchant.
He was running Struts, Of Equifax fame?
It was well before the Equifax attack, but it was the same Struts.
And there was a vulnerability posted in Struts,
it was announced, it got CVE, and he was attacked within three hours.
Yeah, right.
Right, because the criminal had mapped out who was using that version of Struts.
Yeah, it's interesting, there's a bit of a framework disclosure discussion here,
too, isn't there?
There is.
And he was really quick, and actually he was fully PCI DSS compliant,
he noticed the attacker through its intrusion detection.
But you can never win all of the time, and small merchants can't do that,
small merchants can't win.
Even medium-sized merchants.
Let's describe the attack and how it works at the moment.
I'm doing a really simple version of that,
so I'm going to go with the direct post model where the
form is coming from the merchant.
So here we've got a merchant web server and here we've got a criminal and
basically the criminal owns the merchant web server.
And they own the merchant web server and they put their one line
of script source equals criminal JavaScript in.
The consumer goes to the merchant's website,
they get the payment page coming up in their browser,
and they've also got this little bit of JavaScript at the same time.
That JavaScript says something like script src= a go and pull,
go and pull some form logging stuff from the criminal's web server.
So the real key here is that the criminal has managed to get their
own arbitrary script onto the merchant's site.
It's not even that, it's an instruction to load their script,
so it's one line, they need to put one line of code --- Sure,
but it would then pull that down, it will execute it on the,
it in the context of the merchant's site.
Absolutely.
So, the consumer's browser goes to the criminal's web server,
pulls in the JavaScript, and now basically that form is owned.
The criminal owns that form.
The user types in the cardholder data same as normal,
and they press the Buy button,
and the cardholder data goes to the payment service provider in the bank,
and the cardholder data goes to the criminal at the same time.
And the terrible thing with this is, it's not detectable.
Well, I was just going to say, I mean,
this is kind of interesting because you're saying that the legitimate
transaction is still going through to the payment provider,
but the criminal is just I assume just asyncing this data back to them as well.
Absolutely, yeah.
Okay, all right, so clearly this is problematic; where do we go from here?
We need to, well,
I thought the great thing about having this chat today was we would be
able to work out how to stop this attack happening.
So what I really wanted to do was actually talk about how
we would go about fixing that problem, because I want to fix the problem,
but also in the context of the NIST cyber security framework,
which is split into these five areas of identify what's
going to be out there that attacks you,
work at how to protect yourself against it,
work out how you can detect when you have been attacked,
because it assumes you will be attacked at some stage,
know how to respond to that attack,
and then know how you're going to recover from it.
And this is a great model.
It's very simplistic; this is not rocket science.
And so I'd like to look at the way we're going to defend
against this by looking at the NIST model.
So we're basically in the identify stage now.
We're identifying how bad guys steal cardholder data.