[Autogenerated] Before we dive into the new
requirements in version four of PC headset,
which we'll do in the next module,
I'm going to look at some of the wording changes or clarifications to
the existing requirements that may actually have an impact on how you
meet a requirement because these are not new,
future dated requirements.
Just changes in wording to existing requirements,
They come into force when the standard itself
becomes the only standard you can use, which you will remember is one April 2024.
Firstly,
requirement 1.2 point two clarifies that any changes to
networking devices need to be under the same change control
processes as everything else in the organization.
And these change control processes are specified in requirements six,
Staying in principle, requirement one,
there's a potentially significant change to requirement 1.2.8,
this was a legacy requirement to protect and synchronize things
like router configuration files in the days when routers used to
load their configuration files from.
Ftp servers.
Now,
the requirement is actually quite important because with so much
networking infrastructure defined in software,
for example, for creating cloud environments,
we now have things that need to be protected and synchronized,
such as Terraform scripts because if these were altered by an attacker,
for instance, by changing network access rules in the configuration file,
this could have a significant impact on security.
So requirement 1.2.8 is vital again,
to make sure that any networking configuration file which includes cloud
networking configuration files are included in scope.
And if you're running a continuous integration,
continuous deployment type of pipeline for your network configuration,
this then may bring that entire pipeline into the scope of the Pc DSS
requirements and that might be a major thing you need to think about
given there's only two years to implement it.
And the final clarification in principle,
requirement one is that standard has lost the concept
of a demilitarized zone or DMZ.
Now,
the standard only talks about trusted and untrusted networks and how to
manage the security boundary between them both trusted network and
untrusted network are defined in the glossary,
essentially an untrusted network is any network
that's not been protected by pc IDs S.
So a corporate network that is out of scope of pc IDs S
is classed as an untrusted network.
The internet is classes untrusted network and the network in
scope of the P C I D S s requirements is trusted.
There's a subtle change to the state,
full firewall requirements and that it is now more
host based on network segment based.
And this change has come about because in a lot of cloud
environments you might not create an obvious DmS.
I mean you should but you might not.
Okay, moving away from requirement one,
there's a potentially impactful clarification requirement
three and that's in requirement 3.4.1.
This is the requirement that deals with the on screen
masking of primary account numbers.
Remember,
masking is where you have the whole pan but where the pan is
displayed such as I'm a printout on a screen and some of the numbers
are masked out so the whole pan isn't visible.
The requirement has always been that people can see the full pan if there's
a business need but where there is not a business need,
the display should be of a masked pan consisting of a maximum of
the first six digits which represent the bank identification number
or been and also the last four digits.
Now with some card brands moving to eight digit Bins,
this requirement now says there needs to be a business requirement to see more
than the bin and the last four digits I predict this is going to create some
problems because a pan with an eight digit been is essentially
indistinguishable from a pan with a six digit been.
And so assessors and entities will struggle to know when they're masking
a pan with an eight digit bin or a six digit been.
My suspicion is that this will be clarified in version 4.01.
But from a practical perspective now I'd recommend people assume that
all Mastercard and visa pans have an eight digit been and american
express cards to have a six digit been Principal requirement five
used to require antivirus but now in version four kids anti malware
solutions are required.
The wording always felt a bit well last century given the
rate of change in malware protection,
so this is less of an impactful change but more want to celebrate
because the standard now also allows for behavioral anti malware
detection as well as traditional signature based periodic scanning
and scanning on access.
In version three of PC ideas requirement 8.7 aim to
restrict direct query access of databases.
Just the privileged users.
The idea was to prevent an attacker who had got hold of a normal user
account to be able to issue queries directly to a database containing
cardholder data because well back in the day,
this was a cause of some big compromises.
This requirement has now moved into principal requirements seven,
which is a more logical place for it to be.
And it's been extended to encompass any store of
cardholder data that can be queried.
So not just traditional databases.
The clarification innit requirement 11.2.1 concerns an entity's
obligation to scan for rogue wireless access points.
The requirement now includes an amusing clarification that even if an
entity has a policy prohibiting the use of wireless access points
scanning for rogue wireless access points still needs to take place
because and it really does say this in the standard because Attackers do
not read and follow company policy.
It's impressive to see that the working group has resorted to humor to get this
point across to the thousands of entities that have claimed that this
requirement doesn't apply to them because of their policies.
And the final potentially impactful clarification is in requirement
12.8.5 In version three of PC idea says this requirement used to say
it was important to keep a list of which requirements and the entity
was responsible for And which requirements of 3rd party service
provider was responsible for.
The standard.
Now acknowledges that in many cases responsibility shared
between both the entity and the service provider.
And so it's added the concept of shared responsibility to 12.8.5 personally.
I hope the standard would have mandated the use of the responsibility matrix.
That is found in the third party security assurance information supplements.
However,
that's not the case and the use of the responsibility
matrix is just highlighted is good practice,
but that's a good practice.
I'd really encourage everyone to follow.
Remember All of these potentially impactful clarifications are not
new requirements and so there in force as soon as you are assessed
against version four in the next module,
I'm going to look at most of the new requirements in the standard and
certainly the ones that you'll need to start thinking about today.