[Autogenerated] the final set of new requirements that we're
going to look at and which apply to all organizations aim to
prevent successful phishing attacks.
And there's also some of that add more requirements to
the management of the cardholder data.
Environment fishing is one of the most successful attack
vectors we know at the moment either to trick users into
divulging their credentials,
their user name and their password or to trick a user
into installing an attacker's software.
Pc.
DSS now has two types of control to help prevent this type of attack.
The first in principle, requirement five.
Our technical controls to reduce the success of phishing attacks.
The standard is quite vague and doesn't require any particular technology,
although what it has in mind is an email filter that removes phishing
attempts before they arrive and he uses inbox and also perhaps something
that verifies the links that users click on.
So in addition to these technical controls,
the standard also requires users to be made aware of fishing in.
The requirement for annual security training.
In principle, requirement 12.
The standard emphasizes the role of a user as a detective
control in alerting the information security team to
phishing emails that they've received.
This is an important distinction between the old fashioned message
of trying to train users not to click on links,
but it emphasizes the fact that if there are technical controls in place
but a phishing email gets past those technical controls.
The user is the only person who is able to detect that and then to
be able to notify the information security team.
One of the criticisms of Pc idea says, is that it is a point in time assessment,
it doesn't require you to provide evidence that all your
controls are operating as you plan.
100% of the time requirement 10.7 point three aims to address this in
some way by requiring organizations to be able to detect failures of
critical security controls to be alerted to those failures and then to
respond and address them initially.
Addressing a failure requires well putting the control back to a working state,
but it also means that afterwards some sort of post failure
analysis is undertaken and this must include developing an
understanding of what risks there were two the organization when
the control was in the failed state,
it must include discovering the contributory factors to the failure of the
control and then based on the contributing factor analysis,
undertaking some remediation activities to make sure the
control won't fail in a similar way.
Again,
a frequent criticism of Pc IDs S is that it involves busy work work
that the information security team has to do,
but which doesn't in many people's minds,
improve security and I know many people will criticize the new
inventory requirements in Pc IDs S as busywork,
but I've always been a great believer that if you don't
know what you have in your environment,
it's really hard to manage and protect it and so there are three new inventory
related requirements in Pc ID CSS The first in principle requirements six is to
have an inventory of bespoke and custom software.
Bespoke software is software that people have developed for you.
Custom software is software you've developed yourself.
The reason for this is to make sure that it's possible to
patch and maintain all of that software.
And this really mirrors the general dr within information
security to have a software bill of materials.
So you know what components,
what libraries and what modules are inside the bespoke and custom
software you have and so you can properly manage.
It's security by understanding its dependencies.
There's been a longstanding requirement for an inventory
of hardware and software components.
So this isn't exactly a new requirement.
But what is a new requirement is that the hardware and software
technology and use in the organization needs to be reviewed annually and
the inventory will need to support this activity.
What the review is looking for is to make sure that any hardware or software in
use doesn't compromise the security of cardholder data because it's still
currently being supported and maintained by the vendor.
And so what's key is that the hardware software or firmware continues to
receive security patches and updates and if it's end of life has been
announced by the vendor that the organization has a plan that will keep it
secure and re mediate whatever it is the hardware,
the software,
the firmware when it's no longer possible to keep it
securely because you can't use compensating controls to
secure it and you can't patch it.
We've mentioned it before,
but there's also a new requirement for a
cryptographic inventory in the organization.