The fourth PCI DSS requirement is concerned with the protection
of cardholder data in transit across open,
public networks.
Its aim is to prevent the interception of payment card data by attack.
It's listening to a transmission or acting as a man in the middle.
It's a relatively short and simple requirement,
and this simplicity is reflected in there being just three sub requirements.
To encrypt cardholder data in transit,
to protect cardholder data when it is being sent over messaging services,
and finally, to have those policies and procedures.
Now, let's look at our sample network.
Look requirement 4 is going to apply anywhere data is
transmitted or received over an open public network,
which in our case here is the VPN connection between
a retail store and a head office,
and also how cardholder data is encrypted between the
customer and the e-commerce web server,
and depending on where the TLS connection is terminated,
that could be either at the firewall or at the web server itself,
because some firewalls terminate the TLS connection and
then send it onwards to the web server.
Requirement 4.1 contains the main demand of this requirement,
that strong cryptography is used.
The actual requirement needs a closer look because there's quite a lot in it.
Firstly, it's about transmission over open public networks.
So first off, let's define what an open public network is.
Well, the standard calls out the internet and any wireless technology,
because it's pretty obvious that data could be accepted on any wireless
network with someone with the right wireless type of receiver.
So that's the internet and wireless networks.
I personally use a stronger definition,
which is basically any network that's got shared traffic on it,
and if you think, well, does a wireless network have shared traffic on it?
No, it probably might not, but the air has shared traffic on it,
and so that's open and public defined.
Now what about the other part of requirement 4.1?
Strong cryptography, and when PCI DSS uses the words,
strong cryptography, it references the glossary,
which calls for a minimum of 112 bits of effective key strength,
the standard algorithm, and proper key management.
Although, as the glossary says, any new implementation,
for example,
that site-to-site VPN in our example network that's going to be using IPSec,
I mean that needs to be using at least
one-hundred-twenty-eight bits of effective key strength.
Now if we look back at the requirement,
the last thing to point out is the standard talked about transmission,
and I've seen people claim this means it's nothing to do
with the reception of cardholder data.
That's a mistake.
If you run a web server that controls the encryption used in the transmission
of cardholder data between a client and the web server,
you're responsible for how that data is encrypted,
and so it's very clearly up to you to make sure that your
server only established secure TLS connections,
and you can see that this made quite clear in the guidelines.
So practically we're talking TLS here for web
browser to web server communications.
So let's look at what's safe to use.
All versions of SSL and TLS 1.0 should never be used.
TLS 1.1 wasn't actually widely deployed.
It's not actually deprecated either, and yeah,
you can use it if you must, but let's face it now.
TLS 1.2 and TLS 1.3 are preferred versions.
There is one exception to this,
which is the cryptography used in old point-of-sale POI systems that read cards,
and that's typically because these systems can't be upgraded.
So if you have old points of interaction,
POIs, that still use SSL or TLS 1.0,
there's a separate set of requirements in Appendix 2 of
PCI DSS that you need to comply with,
and you should talk to your merchant bank processor or acquiring bank,
I mean,
whoever it is that gave you the POIs to work out how they
want you to comply or how they're going to help you comply
with Appendix 2 of PCI DSS.
To test requirement 4.1,
the QSA is going to look at policies and standards and that the
actual configuration of any system responsible for the
transmission or receipt of cardholder data.
The sub requirement 4.1 .1 particularly focuses on
encryption of wireless networks,
which is we now know are always classed as open public networks,
and again the demand is for strong cryptography; however,
this isn't just for wireless networks that transmit cardholder data,
but any wireless network that is connected to the cardholder data environment,
and that strong cryptography needs to be in use for
both the transmission of data, and here's the important point,
any authentication credentials.
And of course, this means you're certainly not going to be using WEP.
To assess compliance with this requirement,
the QSA is going to look both at written standards and how any wireless
networks in the environment are actually configured.