So I think we've sort of gone through the NIST framework now,
we've related that to each part of the phase of how we might have
JavaScript keyloggers stealing payment card info,
I guess to sort of wrap it all up, where does this leave us?
Gosh,
it leaves us in a place where we have to realize that the world
changes and the world changes all the time,
and as we change the way we deliver technology and then we change the
way that we build interfaces for our consumers,
the criminals are watching what we're doing and thinking,
oh, how can I take advantage of that?
You know,
when the company that first worked out how to make sure the
merchant's website didn't get the payment data,
they were probably doing that for all the right reasons.
We know merchants aren't great at protecting payment data,
the payment data stays with the payment service provider,
this is a really better secure model,
and then it took awhile for the criminals to work out how are we
going to attack it by this JavaScript attack.
As models change, and as we try and do security better,
criminals are going to keep changing,
we're going to have to keep looking at how to do that.
I mean, we didn't get a great answer.
The best answer we got on how do we defend against this was use SRI,
use CSP, and then find a way of seeing if your CSP has been modified or deleted.
I think that's what we came to.
And don't get your web server owned.
Yeah, and fundamentally, don't get your web server owned!
I think that's kind of the right note to end on,
you know, like we have good security controls built on the browser for free,
we do need to protect the underlying resources,
whether they're payment forms or other things.
Absolutely.
John, thank you very much.
It's been very useful,
and I've learned a couple things from this as well and I want to
say I had never seen some of those resources,
so thanks very much for that, mate.
Thank you.
Thanks guys.