[Autogenerated] requirement 12.3 is a very strange one.
It requires there to be what the DSS calls usage policies for
something it refers to as critical technologies.
Honestly,
when most people think about what a critical technology is in
respect to the security of payment card data,
they think of firewalls of hardware, security modules and payment systems.
And, annoyingly, if you look at the PC IDE CSS glossary,
critical technology is sort of defied like that.
It talks about systems or technologies that are essential for
business operations or security functions.
But this requirement isn't anything to do with that
type of critical technologies.
It should really say something like and use the technologies which,
if not correctly used by people, can create or course security vulnerabilities.
And as the standard says in the note,
critical technologies are things like email laptops,
USB drives on Web browsing, so the core end user computing.
In most organizations,
the requirement is that the organization developed usage policies for
these types of technologies to minimize the risk of them,
causing a security vulnerability.
The standard gets pretty and almost annoyingly prescriptive about
the 10 things that need to be in the usage policy.
But before we go through these,
I want to remind you of something I said at the beginning of Requirement 12.
Be careful that you make sure these requirements only apply to people and
technology and scope of the PC IDE AD CS requirements.
So it might not be that all the critical technology using your
organization and it might not be all of the people.
So with that very clearly in your mind,
let's look at the 10 things that PC IDE CSS wants to be in the usage policies.
The first is the use of all of the defined critical technologies has approved.
The guidance implies that such approval needs to be
actually on an individual basis.
Secondly,
the policy needed to find that the use of technology needs to
be a tied to an authenticated user next.
And remember these error requirements for a policy that a register is kept of
who has been authorized to use what critical technology.
Now, of course, this register could be something like your directory services,
where the technology, like the use of email or the use of Web browsing,
is actually provisioned.
The fourth requirement for the policy is that some sort of way of
tying physical devices to owners it is implemented on.
The next thing that the policy has to define is how
the technology should be used.
So a traditional, acceptable usage policy is what's needed here.
The six thing that the policy has to define is the physical location.
Where such technologies could be used in the seventh is to maintain a
list of company approved products such as phones,
laptops and USB devices that can be used.
And also the policy must prohibit the use of non approved technologies.
We're almost at the end now,
and you may be surprised to see the next to policy
requirements because at first reading, you might think hang on.
They should have already been covered off Been Requirement eight.
They are both concerned with the critical technology of remote access.
12.3 point eight wants to make sure that remote access
sessions are disconnected after they've been idle for an
organization defined period of in activity.
This isn't just a policy requirement because the testing procedures says the
QoS A is going to look at remote access configurations,
and 12.3 point nine is concerned with remote access
for vendors and business partners,
and you may think that this was already comprehensively
covered in requirement 8.1 point five.
But that requirement was about the user ID used for remote access on that
that user IDE should only being able to error needed.
Where is this requirement is about only having the remote
access technology enabled when needed.
This has been a massive course of data breaches at retailers with criminals.
Been able to access every single store in a retailer's estate,
using the same remote access technology in credentials.
But on the other hand, where you've got managed,
I t service providers there,
the people with the control of the remote access technology.
So here is really vital you take a sensible approach discussion with your
QoS a on maybe Go back over requirement 8.1 point five,
where we discuss some of the problems with remote access
technology and outsourced IT providers.
The last critical use policy is another is concerned with remote access,
but on this occasion is concerned with remote access that's given to
cardholder Data on the requirement is that anyone accessing cardholder
data must not be able to copy move or store it locally unless that's
been specifically authorized.
And if it is allowed,
the policy needs to specify that it's copy to an environment
where all the PC GUID CSS requirements apply.
Now the QoS a has got lots to check in this requirement
on the majority of its documentation.
But some of the requirements also specify the QoS A needs to look at settings,
for example,
how remote access software is configured or where
the requirement Astra Register.
The QoS is going to look for that register.
But firstly,
because the scope of what's determined to be a critical technology is
something the organization needs to workout itself,
the QoS is going to look to see where this has been defined on then,
how that definition ties in with the requirement for a risk assessment in 12.2.
Finally, as I said at the beginning,
don't fall into the trap of using this as the benchmark for the
whole end user computing acceptable usage policy.
Will your entire organization remember that this
requirement only applies to critical technology on people
who are in scope of the PC IDE S s.
In many cases, we have a lock down cardholder environment.
The answer is a number of policy statements that say technology,
ex wife said,
like USB drives are not permitted to be used in the cardholder data environment.