[Autogenerated] we didn't.
In the end way near the end,
eso were probably requirement that no one ever even
because they're bored by now, right,
we're a 12.10 having an incident response plan and
testing an incident response plan, right?
We've just been through the theory of that.
And people know that I'm passionate about incident response
planning because it's a way of it's one of the few controls you
have we can limit the impact off the breach.
Most of DSS is about limiting the probability of the breach.
Incident response limits the impact of a breach.
So there's an assessor.
What are you looking for in requirement 12 point?
Tell me.
Tell me what you're gonna be looking at.
So I want to start with an incident response plan that has
some organization specific substance to it.
A lot of first drafts or a lot of, uh, you know,
early attempts or a lot of things that maybe other assessors let
them get away with have very high level stuff for that sort of
parrots back the language of the PC, IDE s s or the payment brands,
you know,
kind of what to do with compromise stuff right and
doesn't talk about how they handle that.
Right on there.
There are There are some.
There's some sort of business kind of strategy, things that you need to do.
And there are some kind of tactical technology,
things that you need to do and and I think to the greatest extent
possible you want as much of that mapped out in procedure as you can
because an incident is never gonna be convenient.
And you don't wanna be making at least those kind of first contact
decisions at three in the morning on a Sunday,
right?
Just want to executable, looking for playbooks as well as an I.
R.
P or just an IOP.
I mean, strictly speaking, there's not a requirement for a playbook, right?
And maybe the document sort of combines those things, and that's fine.
But I want to see that you have the ability to executable plan appropriately.
Does your testing procedure involved interviewing?
Is it just a documentary?
It's both.
It's interviewing and documentation, right?
So you want to understand that people know what their
responsibilities are and can demonstrate some competence,
right?
Or some understanding of what it is they're supposed to be doing okay,
you know, and and this this shows up in a couple different ways,
right?
If you are, you know, the systems people and you have some evidence,
you know, of compromise or potential compromise.
How are you sort of limiting that from widening.
How do you, uh, control those systems that the breach doesn't widen?
That doesn't get worse.
That doesn't spread throughout the organization.
How do you preserve the systems for forensic investigation purposes?
How do you maybe disconnect them from the network
or put them in a in a preserve, a ble state where the evidence,
you know, can't get adversely impacted by somebody continuing to operate That,
uh, I want to stop you briefly, because throughout requirement 12,
you said stuff has to be in place, but there's no quality threshold.
Do you have a quality threshold?
Then, in requirement 12 10,
I would say I apply a more rigorous quality threshold,
but it's it's difficult to sort of expressly point to that in the text.
And I find a lot of organizations where maybe they've been getting
assessments from other parties in years past.
Uh, have a much lower quality threshold.
Haven't have much more sort of boilerplate language and and little specificity.
But you're looking at what is a policy?
It's a plan for this organization, not a generic plan.
Right.
Okay, Now there's a requirement to review and test the plan annually, right?
What evidence are you looking for?
That.
So I mean, testing could take a couple of different shapes, right?
I don't necessarily require somebody to deliberately introduce malware
into the organization or do something like that.
It can be a tabletop exercise, right?
And that could be valuable, really.
And the testing and the training, you know,
sometimes travel together in that In that regard where you know,
the point of the testing is walk through the procedure.
Here is a possible scenario.
Right here is something that's gone wrong.
What do we do?
I think if you're going to do that, you know,
one tip to really consider is to have someone whose job
is to sort of make things go wrong, right?
And and sort of raised the stakes and make sure that the plan is sort of,
uh, rigorous enough to withstand that facilitated to able to \.
Right?
Right.
Definitely.
You have somebody facilitate that.
Have somebody, uh, you know, potentially introduced problems, right?
If if your plan documentation resides, uh,
you know, in some particular storage repository,
right?
What happens when the incident also takes out the storage repository?
Right.
Uh,
or what happens if a particular critical person is unavailable
because they're on vacation or ill or whatever,
but never happens when you do, you know,
you organize the test for when everyone's there,
right?
Clearly, uh, eso so that I mean,
those are the kinds of things you want to think about,
right?
And, you know,
certainly if you have the capacity to do some sort
of more realistic live activity, then sure.
I think you could accomplish that with again.
Sort of a usefully rigorous tabletop exercise.
Okay,
what about the city's actually had a breach and they've actually
documented what they were doing is part of the breach.
Is that is that better than a test?
I mean, I think it's I think it is interesting for other reasons.
I think, um, it doesn't qualify for the test.
Your plan?
Well, I think I think maybe what you could do from that right is okay.
You have the actual incident and then you should have after that
incident some sort of after action activity where you say,
Here's what lessons Here's what we learned right here is
where we did what we were supposed to do.
Here's where we failed that.
Here's where maybe we executed on the plan.
But the plan was not satisfactory, right?
Let's let's sort of put all of those lessons,
you know, into play, and then maybe maybe let's do a tabletop on on,
like a rematch right of that activity, right?
Or some similar thing and say, now that we've made these changes,
does our plan get better?
Um,
looking again at the standard of of of what's expected
there is that everyone has to be trained,
which,
you said often can happen is part of the breach Exercise
Training can happen in the exercise, but people who should be responsible 24 7.
So you need some 24 7 capacity to do the first contact stuff, right?
And then e.
I mean part of training right?
Isn't just, you know, the very technical sort of aspects of incident response,
but it's understanding your role, right?
And so then you need to be able to escalate that appropriately, right?
If you're if your night shift help desk person is the first contact, right?
You know, do they know who they're supposed to call, right?
And then is your second tier person.
Like, Do you have a schedule for who takes the,
you know, the call, you know,
so that they can expect to get woken up in the middle of the night or
at least realize that that's part of their job.
And then go do something about it on.
Do you see this done particularly well, Particularly badly.
An organization?
Is it lip service requirement that people do, You see good stuff.
I generally find lip service and generally have to sort
of kind of herd them towards better, better stuff,
right?
You know, in some of this, you know,
the I t people are capable of doing sort of the useful first contact stuff.
Uh, but then you need some leadership from people higher up in the organization.
Right?
How do you then engage?
Maybe a forensic assessor who communicates with the banks or the payment brands.
Who makes the decision to call law enforcement?
Right?
You can't unring that bell.
So you want somebody who has the right authority to do.
That s o for real practical purposes.
You need to go a bit above where the standard is on this one.
I think so.