The seventh PCI DSS requirement is one of the core
fundamentals of information security.
You must give people the minimum access they need to do their job.
And this is especially true,
both the privileged users and any user roles that have got
actual access to real cardholder data.
It also requires you to have some sort of automated access control,
and of course documenting all of this in policies.
And so if we look through the scenarios,
Requirement 7 is going to apply to every system and device in the store and
also to every system and device in the e-commerce scenario.
Because basically, if you can log into it, it's in scope of the requirement.
Where Requirement 7 is all about authorization,
Requirement 8 is about identification and authentication.
So firstly, everyone needs to have their own user ID,
so no group or no shared accounts.
Next, there are lots of sub-requirements dealing with password strength.
But most importantly, there's also here the requirements,
the Multi-Factor Authentication for remote access into the CDE
and also all administrator access in the CDE.
Now, you might think this is a bit annoying,
but in my experience, and I saw lots of data breaches,
correctly implementing this requirement alone would have prevented so
many breaches of cardholder data from merchants.
Still in this Requirement 8,
there are a few other authentication sub-requirements.
One of the key ones I'm going to pull out is if you have databases.
So it applies if you've got databases containing cardholder data
in that the tables where the cardholder data's stored shouldn't
be directly queryable by users.
Only application access can be allowed, and again,
that's to stop someone who gains access to the network,
it's when a query goes to the database and pulling card data back.
And finally, as I'm sure you've guessed by now,
the last sub-requirement is to have documented policies
for identification and authentication.
And it will cover as no surprise that the identification
authenticate requirements is going to apply to every system
and component in the store example,
and every system and component in the e-commerce example.
Now, the next requirement, Requirement 9, is about getting physical.
Getting physical in respect of people's access into
areas where a cardholder data is stored,
processed, and transmitted,
but also the protection of physical things that have card data on them,
such as bits of paper or disks.
And these need to be kept secured and disposed of properly.
So that typically means shredding paperwork and destroying disks that
have had cardholder data on it and not putting,
for instance,
bits of paper with card data on in the bins so
someone can dumpster dive for them.
There are special requirements for looking after devices that read the
magnetic stripe or that read the chips on payment cards,
and of course, all of this needs to be documented again in policies.
And so if we look at the scenarios,
these physical requirements are going to apply to all the
locations where a cardholder data's present,
including the physical stores and head office,
and it applies to data centers.
Now, the final three requirements we're about to look at,
requirements 10, 11, and 12,
also apply to all systems in the organization that are in the
cardholder data environments or connected to it.
So I'm going to start with showing these pictures of the two example
scenarios and just say everything applies here.
So, Requirement 10.
Now, Requirement 10 is the security logging and monitoring,
which you might hear called SLAM.
The sub-requirements are for everything to generate logs and the
standard goes into some detail here about,
you know, the events that need to be logged in and how,
the sort of granularity of logging you require.
And to make sure the logs can't be tampered with,
there are requirements against that and then there's also a requirement that
the logging is properly synchronized to the same time source.
So if you're doing forensics,
you could actually track an intruder going through your network.
Now, finally, this requirement, Requirement 10,
contains one of the hardest requirements in PCI DSS,
and that's to make sure the logs are reviewed daily.
And that doesn't mean, you know,
having an intern sitting in a cupboard watching the logs from our office screen.
Nowadays, that will certainly almost,
almost certainly mean using some automated tools to do that.
And finally, as in all the other requirements,
there needs to be policy supporting the logging and monitoring.
Now, in my experience,
Requirement 11 is one of the ones that organizations fail to
keep up with and only surveys that are published about PCI DSS
always highlight that Requirement 11 is the one that people fail
on in a second year audit.
And, you know,
that's a shame because this is about making sure that all your
other security controls and systems are working,
and that they're doing their jobs.
You know,
sometimes I wonder whether this requirement's neglected
because it's at the end of the standard.
People have just got tired of reading and doing all the controls by now and,
you know, if it got moved to Requirement 1,
maybe people would pay more attention.
Many of the sub-requirements here need you to do something on a regular basis.
So you doing that regularly assures that your security is working.
Firstly,
you need to test for the presence of rogue wireless access points
plugged into your network on a quarterly basis.
Also, every three months,
you need to scan the internal networks and all your
externally facing systems for vulnerabilities.
You know, and frankly, I hope you do it a lot more than every three months.
Each year, and after a significant change,
you have to conduct a penetration test from within the network,
and also from outside the network looking in.
And finally,
there are sub-requirements for continuous assurance the form of intruder
detection or intruder prevention systems in the network perimeter and
also a key points on the internal network.
There's also a requirement to use change detection software
such as File Integrity Monitoring to alert you any changes
in system files and again,
have policies written down that says this is what
you're going to do as an organization.
We're coming to the end now, the 12th and final requirement.
And this one can be called the People In Process Requirement.
It actually has quite a lot of sub-requirements so it'll
take a few minutes to go through this one.
And the sub-requirements aim to make sure there's adequate
governance of the security of cardholder data.
And the first one, I'm not going to be surprised,
is to have an information security policy that aligns and
includes all the PCI DSS requirements.
Next is a requirement to an annual risk assessment.
Yep, I paused there because I've heard people say to me,
"John,
why do we need to do an annual risk assessment "given that
PCI DSS effectively tells an organization "what to do to
protect its cardholder data.
" You know, but remember, PCI DSS is a baseline security standard.
You might be in a higher threat environment,
you might have a lot more cards than other people,
or there may be a new form of cyber attack that the standard
doesn't have the controls in to take account of.
So a risk assessment is crucial for your business to
understand how to protect its data.
The next set of sub-requirements are all people focused.
So, the responsibilities for looking after lots of things,
the security policy, monitoring and analyzing alerts,
looking after incident response, administrating user accounts,
monitoring and control access to cardholder data,
all of these functions need to be allocated to individual roles.
All people that interact with or who could affect the
security of the cardholder data environment must receive
security awareness training annually, there must be a proper program for this,
and there also needs to be a risk-based screening program in place.
And finally, right at the end of this standard,
now, you know, if you're reading this, we're on about page 110 now.
Right at the end of the standard, there are two of the most crucial requirements.
The first of which is to make sure that any of third party
suppliers you use that have access to cardholder data,
or third party suppliers that could affect the security of your cardholder
data have to comply with a relevant requirement of PCI DSS.
The second crucial requirement is to have and also
practice an incident response plan.
So, if you suspect a loss of cardholder data, you know what to do.