Now we're going to look inside the PCI DSS standard in a bit more depth.
And in the last module we discovered that the
standard's broken down into 12 requirements.
So we got to find out a bit more about each requirement and look at a bit
more details about what it applies to and how it works.
But to that,
I'm going to use a couple of example networks to see where the PCI DSS
requirements will be used in a typical environment.
So firstly, here's a face-to-face example.
We're at a store like a normal merchant store.
And in here we've got a chip and pin machine and a point of sales system.
A local server within this store, you know,
which might contact the bank to process a transaction; and
then some sort of connection through its head office where
there's a payment processing system, which again,
may also talk to the bank,
and a database server is going to keep a record of all transactions.
And here's an e-commerce example.
We've got a user shopping on her computer at home,
a connection through to the merchant's web server,
located within a DMZ,
and then a payment processing system which again will talk
to the bank to get the payment processed.
And finally, a database server is going to keep a record of all the transactions.
So there's two just sample networks.
Now,
you probably remember from the previous module that PCI
DSS applies to all systems that store, process,
or transmit cardholder data and that that's called
the cardholder data environment.
And also that PCI DSS applies to anything that's
connected to the cardholder data environment.
So I'm going to take a quick look at our example networks,
both the store and the e-commerce example,
and work out which system components store,
process, or transmit cardholder data.
Firstly then with the face-to-face example.
So the chip and pin machine processes and transmits cardholder data.
As does the point of sales system, and in my experience,
it's going to be pretty typical that that point of sales
system will also store cardholder data.
You know, even though it probably doesn't need to.
When people wrote these systems,
they tended to store data wherever they could in case
something went wrong and they needed to recover.
So the store server, well that's going to process and transmit data,
and again, in my experience, that's probably going to store the data as well.
Cardholder data's going to be transmitted through the firewall to the bank,
and also through the connection to head office,
into the firewall at head office, and then onto the payment system.
Then it's going to process and transmit the data and that,
yeah, I guess it may also store it.
Finally, the database server will store cardholder data.
So, it appears that every single component in our example system either stores,
processes, or transmits cardholder data.
And so, it would be in scope for all those 280 or so PCI DSS requirements.
And now the e-commerce example: cardholder data is
transmitted from the user's browser, through the perimeter firewall,
and onto the web server where it will be processed and transmitted onwards.
You'll often find that web servers also store cardholder data,
you know,
in case payment processing systems are unavailable and so
they'll keep it in what's often called an offline state until
they can process the transaction.
From the web server,
the card data's transmitted through the DMZ firewall into the payment
system where it's processed and transmitted to the bank.
And of course the payment system may well just store a
copy of the cardholder data just in case.
And then, finally the data's going to be stored in the database server.
So again, looking at this example, everything we see we either store,
process, or transmit cardholder data.
And therefore, all the PCI DSS requirements will apply.
Now, of course some of the transmission of cardholder data will be encrypted.
So as the data travels over the internet,
it's going to be encrypted using TLS all the way through to the web server.
And that's good news because that means we don't have to take
responsibility for applying PCI DSS to the internet.
Okay, that's my little joke.
But I actually have seen consultants suggest that
organizations have to do that and make the internet PCI DSS
compliant which of course is clearly nonsense.
Now, if the data's encrypted with TLS,
then the perimeter firewall doesn't see the cardholder data,
so it's no longer transmitting it.
And similarly,
my guess most organizations will encrypt cardholder data moving from the web
server to the payment system through that DMZ firewall.
And so that's going to be out of scope and not transmitting cardholder data.
But remember that PCI DSS requirements apply to the cardholder
data environment and also all components that are connected to
the cardholder data environment,
which can affect the security of the cardholder data environment.
So although those two firewalls no longer transmit cardholder data,
they are actually both connected to and can affect the
security of the CDE and so they will still be in scope of the
appropriate 12 PCI DSS requirements.