[Autogenerated] The final thing we need to talk about is what happens
when an entity cannot comply with the requirement in PC,
Idea says.
And the answer is contained in a process known as a compensating control,
compensating controls of the mechanism that allow an
organization to do something else if it caught me a
requirement because of the legitimate technicals.
Constraint such as a legacy device, for example,
perhaps has a system in the network only supports
telnet and not Ssh administration.
Hmm.
Entities can use a competent control if they can't make a
requirement because of a documented business constraints.
For example,
a system that's used to be completely replaced next year
when you won't want to spend a lot of money on temporary
solution to make it compliance.
The process to create a compensating control that an organization
and its assessed there has to follow his detailed in appendix B of
PC Idea says have highlighted here.
The first paragraph and as you can see,
explains that compensating controls can only be used when a
required compliment is explicitly stated,
because off legitimate, technical or documented business constraint,
and this is the important part.
The organization also has to have sufficiently mitigated the risk.
Associating with the requirement through implementing other
compensating controls the compensating control process on the
documentation that has to be completed,
a found in the back of PC idea says in appendices B and C,
let's want through an example,
we'll write a competent control for an entity that still uses
some systems but only support Telmo for market so they can not
comply with the requirement 2.3, which, if you remember,
is to encrypt administrative credentials when
they're transmitted over a network.
Any competent control must meet the intent of the original requirement on Be
just a strong so it has to have the same security effect.
So in our example of a system that didn't support ssh for locking,
you couldn't have a conversation control off,
say, a 15 character password,
because that wonderful fill the intent of stopping an attacker
eavesdropping on a plane tickets credential because the password is
still being transmitted in plain text about how long is also a
compensating control can't be Justin Existing PC idea,
says requirement.
It has to be something above and beyond.
So you couldn't say, Oh, I'll pick this PC idea says,
requiring compensating control for this requirement
because it's already a requirement.
When an organization wants to use a competent control,
there's a work ethic that's needed to be filled in,
and this worksheet contains six sections.
In the first,
the organization has to detail the legitimate technical
or documented business constraint.
That means a compensating control is required next.
By looking at the requirements on the guidance,
the organization needs to say what it believes.
The original objects for the requirement WAAS and therefore what
needs to be met by the compensating control then,
based on this subject,
if the organization needs defined the risk faced by not
having the requirements in place,
and now the organization should define its compensating controls,
making clear how they meet the objective of the original requirement on and
mitigate the risk of the original requirement not being met because there isn't
a written test procedure for the compensating control,
the organization should write down how they're going to validate that
the compensating control is in place and working,
and finally,
the way that the compensate control is going to be maintained over
the next 12 months should also be listed in the compensating control
worksheets and in our imaginary example,
the legitimate technical constraint is that the switches in our carnal the
data environment do not support any encrypted protocols.
For administrative Loggins,
the objective of Requirement 2.3 is it is trying to prevent a
threat actor eavesdropping or intercepting plain text
administrative credentials from the network.
And the risk of this is that the Threat Act will be able to log into a
switch and potentially reconfigure the switch so they could.
They could monitor or redirect all traffic in the cardholder data environment,
although here we've noted that as all other couple
the data and credentials encrypted,
it's a limited risk in our imaginary environment.
The competent and control we've designed is that we've
created a jump post on a fixed I P address,
which is the only host the switches will allow log in from.
So if the Threat actor was able to read the admin credentials for the
network but also have to compromise the jump posted bail to log in
separate of jump pose to be able to log into a switch to validate that
the compensating control is working,
the assessor would try to tell that into the switches from
somewhere on the network that wasn't the jump post and check
the connection attempt was rejected.
And so ensure the conversation control was working
throughout the course the next 12 months,
we would make sure the bill documentation for old
switches have the instruction toe only enable telnet from
the i p address of the jump post.
We also try to tell the into the switches from somewhere random within the CD.
Let's say a quarterly basis to validate that they
continue to be configured correctly.
I've dealt with lots of organizations and assessors that
don't like to use conversating controls.
That is not good policy.
The card brands know that a prescriptive stand that could be hard to follow,
especially Weathers legacy equipment.
So the use of compensating controls is really I don't say encourage,
but it's part the standard.
So use compensating controls wisely.
Whether a riel technical or business constrains some
of the reasons that I've heard,
assessors will not accept a compensating control that you can't use a
conversation control for a particular requirement.
Well, that's not the case, and if it was,
it will be written in the guidance column of the requirement would say,
this requirements cannot have a compensating control,
but it doesn't do that.
I've also heard assessors say that compensating controls are only valid for,
say, a couple of years, and I can't be used beyond that.
And again, that's simply not true.
There's no limit to how long an organization could
use the conversation control four.
However,
they do need to be reviewed every year to confirm that
the legitimate business reason well,
the technical constraint is still valid and that the compensating control still
meets the intent of the requirement and mitigates the risk.
I've also heard assessors say, but for merchants,
all compensating controls have to be agreed with
the entities acquirer and again, that isn't the case.
I don't recommend that the use of a compensating control and the
control itself is discussed with an acquirer,
especially the large degree of risk associated with her.
But at the end of the day is the assesses call the control
is correctly designed and implement it.
And finally I've had in assesses say that all compensating
controls have to be approved by the PCs,
etc.
That's simply not true,
and it's addressed in a thank you number 1046 So let's
summarize what an organization has to do if it cannot make a
PC Ideas s requirement as it is written.
Firstly, if there's a legitimate technical or documented business constrains,
can the organization use a compensating control?
And if the answer is yes, go ahead and use a conversation control.
If the answer is no,
then the next step is to go and ask the organization
that is asking you to comply with PC, Idea says.
And see if you can negotiate for that particular part,
the environment to be temporarily removed from your scope in the next module.
We're going to look at the assessment itself.
But before we do that, let's hear Jacob's thoughts on compensating controls.