[Autogenerated] in this module,
we're going to look at one of the biggest changes to pc IDs s,
which is the customized approach,
the intention of the customized approach is to allow what
the PCs sc terms sophisticated entities to meet the
security objectives of a requirement,
rather than doing the prescriptive controls specified in traditional
pc IDs which is now called the defined approach.
So if we take a look at the standard again,
you can see that the defined approach is still there,
there's a defined approach requirements and the defined
approach testing procedures and that is just the same
structure as MPC IDs version three,
But what is also there is the customized approach objective.
And so if we expand what we can see on screen,
the defined approach says that the control will operate in a particular way,
and the testing procedure validates that the control is operating in that way.
On the other hand,
the customized approach describes the goal of the requirement in this example,
is that malware cannot execute or infect other system components.
The concept of the customized approach is that an entity can
deploy whatever controls it wants to ensure that the
customized approach objective is met,
as long as it can justify that there will be the same or a lower level
of risk than had they followed the defined approach.
Taking the requirement that malware cannot execute or
infect other system components.
An example of a control and organization could use to
meet the objective would be strong, allow listing of any application,
so just saying what applications are allowed to execute in the environment
And then this would prevent any malware executing in the environment because
well the malware wouldn't be on the allow list.
And so essentially for each requirement,
an organization can choose whether it uses the defined approach for that
requirement or the customized approach for that requirement.
This is a really important point.
You're not making the decision about using defined approach or the
customized approach for the entire assessment.
You make that choice on a requirement by requirement basis,
but that's not the whole story.
You could use a defined approach and the customized
approach to a single requirement.
If you have separate environments.
In one environment, the defined approach may be more appropriate,
whereas in the other environment, the customized approach works better.
Perhaps a good example of this might be in a multi channel retailer
for the face to face point of sale environment.
The defined approach could be the right one to choose,
whereas in the Holy cloud based e commerce environment
that uses a continuous integration, continuous deployment pipeline.
The customized approach will be more appropriate.
And yes,
that can really cause your head to explode when you think of how you would have
to both manage that and report it according to the PCs sc.
The customized approaches designed for sophisticated entities.
Now that's not a requirement,
you don't have to prove you are a sophisticated
entity to use the customized approach.
What you have to be able to do is to complete all the
documentation and processes that are required.
The second thing to know is that using the customized
approach is only available to an organization that is
undergoing an assessment by a P C I S S.
C.
Approved assessor.
So that requires a qualified security assessor or an internal
security assessor who will document the results of their
assessment in a report on compliance.
And yes, that means that if you complete a self assessment questionnaire and S.
A.
Q, you cannot use the customized approach.
It's important to realize that we are still in the early
days of pc IDs version for and although I don't know any
information that relates to this,
it is possible that card brands may create separate rules about what types of
organization can and cannot use the customized approach,
for example, and again, this is just an example,
I'm not aware of this being in anyone's plans.
A brand might say that compromised entities must follow a defined approach.
The customized approach is very new, which means that if you choose to do it,
you'll be learning how this works at the same time as your assessor.
And I suspect that because of the amount of extra work that
an assessor has to do to assess an organization's
implementation of the customized approach.
That this will greatly increase the cost of an annual assessment.
You might be asking yourself what's the difference between a
compensating control and the customized approach,
compensating controls are used when an organization can't meet the defined
approach requirement as it is written in the standard because of a
documented and legitimate technical or business reason.
So the organization implements other controls to compensate for this and
which mitigate the risk of not meeting the requirements.
As it is written,
any organization can use a compensating control no matter
whether they are completing a self assessment questionnaire
or they're being assessed by a Q.
S.
A.
Or an essay with the aim of producing that report on compliance.
The customized approach is used when an organization is intentionally
doing something different that has the same security objective as the
customized approach objective and so meets the requirement is designed to
allow the standard to be technologically neutral and allow sophisticated
organizations that are using modern and actually perhaps yet to be
invented in the lifetime of P.
C.
I.
D.
S.
S for security technologies to mitigate the same risk
as a defined approach requirement.
So they're similar but different only organizations
that will be assessed by a Q.
S.
A.
Or an IHSA can use the customized approach.
I like to think of it that compensating controls are by their very
nature temporary because at some stage the legitimate business or
technical reason will be eliminated.
Whereas the customized approaches a permanent commitment to do
something differently in my head compensating controls are band
aids and bandages over an injured arm.
Whereas the customized approaches.
A bionic arm because compensating controls are
still part of Pc IDs Version four,
I have put together this little flow chart to try to understand the
difference between them and when he would use a compensating control
and when he would use the customized approach.
The first question to ask then is whether you cannot meet a
requirement as it is written because of a legitimate and
documented business or technical reason.
If that is the case, the answer is really simple.
You do a compensating control in the same way as you've been able
to do since the start of Pc IDs But if the answer is that you've
chosen technology solutions that allow you to be secure without
following the prescriptive requirements of PCs CSS and you want to
meet the objective.
The requirement by doing something else,
then the next question to ask is whether you're going to have a q essay
or essay assessment and produce a report on compliance because if you are
then the customized approaches the answer.
But if you're not having an assessment resulting in the reporting compliance,
the customized approach is not going to be available to you.
In which case I guess that your best option is basically to create a
legitimate technical or business reason why you can't meet the
requirements as written and frankly the legitimate technical reasons you
chose to use other technologies that meet the objective and then
construct this is a compensating control,
let's look briefly then at what you have to do if you want to meet a
requirement by following the customized approach.
The first thing to do is to start off with the objective
and then from the security objective,
work out the bad thing that the objective is trying to stop happening,
which pc IDs calls the mischief.
In the example we looked at earlier,
the objective was that malware was not able to execute or infect other systems.
And so the mischief,
the bad thing that we're trying to stop is that malware does
in fact execute or infect other systems.
Once we've determined what it is that we don't want to happen,
we can then design our own controls to prevent the mischief happening,
which will then meet the objective.
We need to document those controls in the controls matrix,
which you can find in appendix E one of the standard.
The next step is then to work out the relative risk of using the
controls that we propose as opposed to meeting the requirement
with a defined approach essentially.
How are you sure that your solution meets the objective and
doesn't increase the risk of the mischief happening.
And this needs to be documented in the targeted risk
assessment for the customized approach,
Which you can find in Appendix E two in the standard.
Having now designed the controls to meet the objective and
assess that they do not expose the organization to a higher
risk of the mischief occurring,
You now need to design tests to prove that your control is working.
So in the example we've talked about that would be trying to get malware to
execute and to show that the customized approach solution,
for example, allow listing prevents that malware from executing.
So you would need to document the tests you've designed
and document the results of both tests,
but we're not finished yet because finally,
you need to determine how you would check on an ongoing
basis that your control continues to meet the objective and
prevent the mischief happening.
So perhaps in the example, again,
you'd have the allow listing software report into a central console to
show it was operative and effective for all times.
Or maybe you could have an in house red team that writes its own
malware and tries to get it to execute in the environment and show
that the allow listing stopped it.
And again, you would document those tests and the evidence of the controls,
ongoing effectiveness.
So you see,
taking the customized approach is not something to be undertaken lightly.
It is a lot of work and we're not finished yet because we also have
to look at how an assessor would have validated.
The customized approach meets the objective.
The assessor would first review the documentation so that would be the controls,
matrix, the targeted risk assessment,
the tests and evidence that the control works and the tests and
evidence that the control provides ongoing assurance that the
objective will continue to be met.
Once the accessor is satisfied with the documentation provided,
they will then design their own testing procedures based on the
standard three tests of examining something,
observing something or interviewing someone and from this
they will generate their own test plan.
The assessor will then carry out their own testing
procedures based on the test plan.
They've just written,
collect the evidence in the standard way and then validate that the
customized approach meets the security objective.
There's a lot of work for the assessor to do,
which means that any time you use the customized approach you
can assume that the cost of an annual P.
C.
I.
D.
S.
Assessment will rise accordingly.
Now you've seen the steps needed to take the customized
approach and how it will be assessed.
It's probably easier to understand why.
The PCs sc strongly recommends that this is only for sophisticated entities