[Autogenerated] There are a number of changes in version four
concerned with identity and access control.
And typically you'll find these in principle requirements seven and 8.
System and application accounts.
So accounts that are not used by humans but are used for machine
to machine or system to system communications.
These previously haven't been given much attention in pc.
ID CSS Well version for the standard.
Sure changes that With five new requirements spread
between principal requirements seven and 8.
The reason for this is that many attacks against organizations have taken
advantage of badly secured system or application accounts.
So the first thing now is that these accounts should only be given the
privileges they need and this needs to be documented in policy and
then both that policy and the actual rights granted to an account will
be checked by your assessor.
Organizations must also re validate the rights given to
these accounts on a periodic basis.
And this is one of those periods that the entity's free to determine
themselves by the use of a targeted risk assessment.
If a system or application account can also be used by
a human for interactive logging.
There are many requirements 8.6.1 detailing how that interactive
use of the account is managed and honestly this essentially
requires an organization to deploy some sort of privileged
access management or pAM system.
Also, if the account can be used for interactive login,
then it's not permitted to store the passwords somewhere.
An attacker could find it such as in a configuration file or hard coded in
source code or has happened to me once on a internal wiki.
The final requirement that applies to these type of accounts is to
make sure that they have strong complex passwords and that the
password is changed on a periodic basis.
Changing the password of these type of accounts can be pretty complex.
I've worked in organizations where even suggesting that we change
some application account passwords almost got me thrown out of the
company because nobody knew where the accounts were used or where
the password was hard coded.
And this is why we need this type of requirement in P C I D s s.
The good news is that the frequency of password changes can be
determined by targeted risk assessments.
There are a couple of requirements that affect proper user accounts.
You know,
the ones used by humans firstly that their rights and access
permissions need to be revalidated every six months.
This requires the access rights given to every account
being confirmed as correct by management,
which typically means either the person's line manager or the business
owner who is responsible for a particular system.
And secondly, a much needed change the password complexity requirements.
This has increased to a minimum length of 12 characters.
But honestly, if you look at the expected life of pc IDs version 4,
12 characters really isn't sufficient.
The standard does allow for circumstances where the technology and used
by an organization such as an old mainframe computer doesn't support 12
character passwords in which case the minimum is now eight characters
contrary to all modern guidance from the UK National cyber Security
center and from nest.
P C I D s are still requires passwords to be changed every three months.
But now that's only if they are the only factor used to authenticate a user
which from april 2025 won't be the case ever because of both.
Version three of P C i D s s required multi factor
authentication for privileged access and for remote access
to the cardholder data environment.
Version four extends this to all user access to the cardholder data environment,
not just for admin and not just for remote access but everyone.
However, there is still a separate requirement for securing remote access,
which does mean that the standard requires somebody who
uses remote technology to access,
say the corporate network and then who accesses the cardholder
data environment from the corporate network,
that person would need to authenticate twice and on each
occasion use multi factor authentication.
The standard now also requires multi factor authentication to be
well configured and then what we should consider to be a welcome
move away from previous guidance,
The definition of well configured encompasses the typical commercial MFA
solutions that are available in the market today because rolling out to to a
large number of users is not an insubstantial task.
And so if this is one that your organization might face,
it might be worth looking at whether those users really do need
access to the cardholder data environment.
Like many of the requirements in principle,
requirement A this requirement for MFA does not extend to
personnel who only deal with a card number at a time,
and that's typically people in face to face retail environments.