[Autogenerated] requirement, 10.8 only applies to service providers.
Now, if you're not a service provider,
I'd like you to work through this requirement with me anyway,
because it's a really important requirement.
And requirements like this that are just aimed at service.
Providers often appear in the next version of standards as
mandatory for all organizations on the requirements.
Concerned with the availability of security systems,
it wants the organization to put in place systems or
processes to detect when systems or services providing
security functions error not working.
The types of services concerned with a listed here,
and these include most of the core technical security functions
organizational have now this list is no exclusive,
so your risk assessment should document what systems error
going to be in scope of this requirement.
Now, in my time, I've seen lots of forensic reports written after a data breach,
and there's often a very common theme that the merchant or
service provider had the technical control in place that would
have defeated or detected the attacker.
But it wasn't working properly or it was turned off.
So this is a really sensible and important requirement,
and even if you're not a service provider.
I'd recommend that you do this to test it is in place.
The QoS is going to first look for policies and procedures to
understand how the failure or non functioning of a critical
security system will be detected.
And they'll also interview people to make sure those alerts error generated.
And if I was the QC,
I'd look for some historical evidence from the incident logs
to make sure that this really happened so I'd look to see
something stopped writing logs.
It's a really good indication it's not functioning and then see
if this policy and procedures were followed.
The next requirement is also just for service provided,
and it's concerned with what happens when the failure of a
critical security system or control is detected.
The requirement is that the organization follows a formal response process.
Now, Wow,
the standard is pretty detailed about what that response process includes and
describes seven activities that must be followed firstly on.
Perhaps unsurprisingly,
the security function that failed needs to be made to work again,
and that's the first in the listen.
That's the first thing you should do next.
The organization should make sure it records when the
system failed when it was restored,
which would be useful in any future forensic investigation.
So you know that something you thought was there wasn't there on
you could see even attacker took advantage of it.
Thirdly, a root cause or,
as I prefer to call them now contributing factor analysis must be
performed so the organization can do understand what happened and take
the necessary steps to prevent a re occurrence,
and that will then feed into the fourth process that's required
after a failure of a critical security system,
which is to implement the recommendations that root cause or
contributory factors analysis and implement technical or process
controls to prevent the failure from happening again.
The fifth thing that's required is to make sure you take a careful
look at your logs and any instance raised during the time period the
system had failed and investigate them.
Remember,
somebody else might have noticed one of your lives of
protection have failed before you did next.
The six thing is to formally Macon document a risk assessment to
understand the risks while the system was down,
and to make sure that the root cause analysis feeds into this risk assessment.
So it's a forward looking risk assessment you would ask yourself.
But what happens if this happens again?
One of the risk?
What do we need to do about it?
And then, finally,
to make sure that the monitoring of the system is also operational
working properly so you'd notice if it went down again.
To test this requirements in place,
the QoS is going to check the written procedures and
interview people to make sure they know what to do when a
critical security system fails,
The QoS is also going to look for evidence to see the processes were followed.
So if there was a failure of the QoS Estelle from the testing procedure in 10.8,
they look for the documentation you're supposed to have is 10.8 point one,
such as the root cause analysis,
the risk assessment and evidence that you went back and looked through the logs