So, we've covered identification, we've covered protection,
we've done the best we can on detection,
so now let's talk about the next thing on our NIST framework,
which is response and then recovery.
So, let's say we find out.
We've found this piece of raw JavaScript that we're serving,
what's our recovery stage?
How are we going to lockdown the web server and get the criminal out of there?
Well, I guess there's going to be multiple phases there,
I mean,
the first thing that I would do if I found JavaScript which was
rogue is get rid of the JavaScript which was rogue,
but you want to identify the vector by which this was
introduced into the ecosystem as well, right?
Yeah.
I mean, does the criminal have permanence?
Do they have credentials?
Are they going to put it straight back there once you've taken it out again?
Well, I guess on something like the BrowseAloud situation before,
like that was really easy to see, if it was me running,
say, the NHS site in Scotland, it would be pretty straightforward.
This external site is running this script,
I mean,
they're going to nuke the script altogether and keep the
site running without accessibility.
But when you sort of get to the point here about what if
someone's modifying content on my web server,
you are going to need to identify the vector by which it was introduced,
because you don't want that persistence.
Absolutely.
And what will happen because if you're an
organization that accepts credit cards,
you've got an obligation to tell your acquiring banker or your merchant banker,
or whatever you call it, the person you have a relationship with,
and they will probably insist you have a forensic investigation.
So,
and I'm curious now because when we go back to the self-assessment point of PCI,
which was sort of the point of putting the payment
provider JavaScript on the site, do you still have to report?
I mean, if you, for example, if you, to keep yourself out of PCI scope,
use that external payment provider,
what is your obligation under PCI if someone gets rogue JavaScript on your site?
Your obligation is not a PCI obligation,
it's in your contract with whichever banker you've agreed to take payment cards.
So when you sign an agreement to take a payment card,
you do it with an acquiring banker or an acquirer or a merchant banker,
they're called different things in the world,
right?
But there's a bank that has the relationship that's going to put the
money in your bank account at the end of the day.
So even if you might be using Stripe,
you still have a relationship with a bank who is,
can you explain that to me?
Yeah, so if you've got a relationship with Stripe,
Stripe's really got a relationship with a bank in each country it works with,
so you have a relationship with Stripe and the bank.
Right, so you would report to the bank?
You'd probably report to Stripe, because one of the things Stripe does,
Stripe works with smaller merchants often.
When it works with a large merchant, it's a sort of three party relationship.
So you might,
if you're a big merchant you probably have a direct relationship with a bank,
if you're a smaller merchant you might have a direct
relationship with the payment processor.
But in your contract, or 500 pages of it because they're big contracts,
it will say if you have a data breach, you must tell us.
And what they will want to do is find out actually two things,
one, how did it happen,
so can we get some knowledge that we can impart around the rest of
the industry to tell people to look out for this?
So that's their number one aim.
Their second aim is to find out the day it started,
because what they want to be able to do is find out all the cards
that were compromised and then put an alert out to all the people
who issued those cards and say,
you might want to be suspicious about these cards.
You might want to cancel them, you might want to be suspicious about them.
Would you might, or let's say you're the website,
would you also need to disclose to your customers who
came along and provided their cards, or would that be something that--?
That's a really great question.
So that comes down to two things, it comes down to GDPR,
or --- So you would under GDPR, assumably.
You would in the GDPR,
and if you were in America where you've got manager breach disclosure,
you would in America under the manager breach disclosure.
We even have it in Australia now.
You would in Australia, then, okay.
You do have a month to disclose it, but --- A month, wow!
Don't get me started.
Okay.
So yeah, so there's two things.
One is do you have another law that requires you to do breach disclosure?
And the second thing is what do you think is right?
I mean, at the end of the day it's about what's right for your customers.
So your customers probably want to know about that.
And that's going to be a big internal debate.
Right, so there might be sort of an ethical decision about that as well.
There's an ethical decision to be made there.
So yeah, so there's two things,
you're going to have to tell the people who will let you take payment cards,
and if GDPR applies or an American Breach Disclosure laws or
the state breach disclosure laws apply,
then you're going to have to make a breach disclosure according to that law,
nothing to do with accepting payment cards.
Right, right.
And also you're going to have to get the code out of there.
Yeah.
Okay, all right.
It all sounds reasonable.