Now let's jump in and look at each of the 12 PCI DSS
requirements in bit more detail.
The first requirements is to install and maintain a firewall
configuration to protect cardholder data.
But sub-requirements are divided into three main sections.
The first is to have configuration standards for the firewalls,
the second is unsurprisingly to build the firewalls
to the configuration standards,
and then the third one is to make sure that all the traffic
coming into and going out of your organization actually does
pass through those firewalls.
There's also a sub-requirement for devices that leave the office and connect
to networks that are not your corporate network and that's to make sure
they've got a personal firewall installed on them,
and as we're going to find out in all 12 of the PCI DSS requirements,
you need to make sure there are written policies that say
this is what your organization does.
Now, if we take our example networks, let's see where Requirement 1 will apply.
And here's the face-to-face network and the requirement obviously applies
just to the firewalls which you can see highlighted.
And again, in the e-commerce example,
PCI DSS Requirement 1 applies to the firewalls.
The second requirement is a battle against the default values.
You know, when criminals hack they use default accounts,
default passwords,
and they exploit services that have been installed on
machines that right not used but they were just there
because people used a default build.
So to comply with the second requirement,
you need to change default passwords,
make sure you build systems to a secure baseline using an industry standard,
an independent standard such as CIS or something like that.
Encrypt administrator usernames and passwords when
they're transmitted over a network,
make sure you've got an up-to-date inventory of all the systems in scope,
and of course,
have all those exciting policies that say this is
what you will do as an organization.
So, moving to the example networks,
Requirement 2 is going to apply to every single
system component and that example, in the face-to-face illustration there,
and also to every component in the e-commerce network,
because everything has a build and everything has a default,
so no more defaults.
The third requirement is only concerned with stored cardholder data.
And although that distinction between ram and disk is increasingly less clear,
this requirement deals with non-volatile storage of cardholder data.
So it doesn't apply to cardholder data in volatile memory.
The sub-requirements start with actually what's the most
sensible PCI DSS requirement of all which is to only
retain minimal cardholder data.
Work out what cardholder data you really need to store and only store that.
You know, and in my career,
I've worked with organizations that have retained every single payment
card number they've ever take for almost 20 years.
There was no need for it, they didn't do anything with it,
but no one actually made the decision to delete it.
So this first sub-requirement to have a storage and retention policy of
cardholder data and only keep data you've got a really business need for is
perhaps the most important requirement in the whole standard.
Because you know, if you don't store the data,
a criminal can't steal it from you.
Other requirements mean you have to encrypt,
hash, or otherwise obscure cardholder data.
Don't store the cardholder data that is used to authenticate a
card or a customer such as the magnetic stripe,
the track data,
or PINs of a card verification of values that we use in e-commerce transactions.
And then finally,
there's a whole set of sub-requirements that if you are doing encryption,
deal with how to do encryption properly.
If we look at the example networks,
this is going to obviously apply to the databases.
But again, to anywhere else cardholder data is stored,
no matter how temporarily, even if it's there for a couple of seconds on,
say, the point of sales system or the store server,
then Requirement 3 will apply.
Similarly, in the e-commerce scenario,
Requirement 3 is certainly going to apply to the database,
but it may also apply to the web server and the payment system
if cardholder data is stored on disk there.
The fourth requirement is to encrypt cardholder data when it
travels across open and public networks.
You know, and typically for most people,
this will mean the internet and wireless networks.
When you ask people to send you cardholder data over the internet,
or you send cardholder data over the internet,
it has to be encrypted with want the standard calls strong cryptography,
which basically means anything that's approved by NIST.
And as there are vulnerabilities now in SSL and TLS 1.
0,
the standard requires organizations to move away
from these protocols to Version 1.
1 of TLS or higher.
There are also sub-requirements to prevent the
transmission of cardholder data of what's expected to be
insecure end user messaging and email.
Although now that the strongest end-to-end cryptography's
available on mobile messaging apps, you know,
such as WhatsApp and Signal,
it really remains to be seen if this requirement will be
updated because that's probably a more secure way of
sending data than anywhere else.
The final sub-requirement is once again to have documented policies.
So, looking at our example networks, in the face-to-face scenario,
we make sure that if a connection between the store and the
head office went over a public network, that it was encrypted; and similarly,
both connections out to the banks for payment
processing would also need encryption.
And in the e-commerce example,
the most important point to remember is that the requirement applies to
accepting cardholder data over a public network using strong
cryptography and not just sending it over a network.
And so,
the web server would need to be configured to only accept cardholder data by
TLS and if the payment system talked to their acquiring bank,
then it would also need to use a and encrypted connection.
And this is quite important.
Many people forget that the standard applies to how you accept
cardholder data as well as how you send the cardholder data.
The fifth requirement is to have working anti-virus on
systems that are typically infected by viruses.
And then risk-assess other operating systems where
you wouldn't install anti-virus, such as Linux.
So you're keeping up to date with making that decision of whether
having AV would be useful based on the risk.
There are sub-requirements to make sure the AV is logging,
that it can't be disabled,
and that you've got policies and procedures to back this up.
So turning to the example networks, the store scenario,
well,
if those computers run operating systems that are typically attacked by viruses,
then all the systems would have AV applied to them.
And then, in the e-commerce example, again,
depending on the operating systems on the servers,
they may require anti-virus deployments.
Now, I know people are saying, "Well,
I use Linux and therefore there's no need "to use anti-virus,
" let me tell you a quick story.
I had a client who was running Linux on all their web
servers but they did decide to AV on there,
not because it was affected by viruses,
but the AV provided some other protection.
And they were compromised,
they were compromised by a one day old vulnerability in scripts
and the criminal installed a web back door,
like a web shell on it,
and actually it was the anti-virus software that picked
that up before anything else did.
So even if you don't think you're going to get infected by viruses on Linux,
it might be a good idea to install software that will tell
you when it sees certain malware on there.
Now,
the sixth requirement's quite a long one and it deals
with the security operating systems, commercial software,
and software you develop yourself.
So the first two requirements are targeting the software you buy,
and that you must track published vulnerabilities for all
the software activating your environment,
that's applications and operating systems.
And also make sure software is patched to eliminate known vulnerabilities.
For software you develop yourself,
there are quite a few sub-requirements that in total add up to
basically having a secure software development lifecycle.
The next sub-requirement is to have some really great change control,
and believe me,
change control is your best friend when it comes to keeping
your organization in compliance with PCI DSS,
especially when you've gone through your first assessment.
And the reason for that is that you need to catch change to your
cardholder data environment and change your systems to make sure that
actually that change will become PCI DSS compliant.
The final technical sub-requirement is concerned with the
security of web-facing applications.
They must either have an independent code review or be
protected by a web application firewall.
Now, personally, I'd have both for a high-volume e-commerce site,
but the standard's happy with one or the other.
And as always, you need to have written policies for these activities.
So if we go to both of our scenarios,
Requirement 6 applies to everything; even if you
don't develop your own software,
everything you buy will have vulnerabilities on what you're patching.
And if you're running an e-commerce system,
then you're also going to have to have a secure software
development lifecycle as well as patching all the things.