We've seen that the standard is pretty in depth and prescriptive,
and people often ask why that is.
So let's explore that.
Now, just for a couple of minutes, I want you to imagine you own a small island.
And on the island, there are lots of diamonds.
However, around the island, there are also lots of pirates.
And you want to give the job of securing the
diamonds from the pirates to a company.
And so,
you need to write a standard that tells the company protecting the diamonds
what they have to do to stop the pirates stealing them.
We could call it, oh, I don't know,
the Pirate Control Initiative - Diamond Security Standard.
And if the company guarding the diamonds follow the standard,
then the pirates wouldn't get your diamonds.
So, what would you put in such a standard?
Now, when I ask this question in a group of security specialists,
they came up with suggestions such as, "Build a fence,
" and, "put land mines on the beach.
" Some people suggested putting mines in the sea.
You know,
and other people wanted search lights and watchtowers and
guards and people watching for the pirates coming off
their boats and onto the beach.
One strange person suggested we provide awareness training to the diamonds, hmm.
So, let's just explore the first suggestion of building a fence.
And if we wrote in the standard, "Build a Fence,
" would the company guarding the island know to build
a small wooden fence like this, or say,
a big two meter or six foot high metal fence,
topped with razor wire?
So, we'd probably have to be a bit more specific than just, "Build a fence.
" we could start with a simple requirement that says,
"Build a fence to keep pirates outside "of the Controlled Diamond Environment.
" And then we'd have to say that the fence had to be,
I don't know, pirate-resistant,
so that it completely encircled the CDE and that
because pirates are known to dig holes, that the fence was buried,
say, a meter or three foot into the ground.
We'll also assume that sometimes you might want to get
inside the fence to look at your diamonds.
So there's probably going to be a door inside the fence.
So we better specify some sort of pirate-proof door.
And you can see very quickly we get a requirement and some sub-requirements.
But as I'm sure you've found out in life words can mean
different things to different people.
So if we just specify a pirate-resistant fence,
people might have all sorts of ideas what that means.
And so we better help people by explaining it.
And in PCI terms,
we call that explanation a description of the intent of the requirements
which helps people understand what a requirement means.
So now we've got a requirement and we've got a
description of the intent of the requirements.
But once a year,
we're going to go and send in an auditor to the island to make sure
that the diamonds are being properly protected.
So we also need to define a set of test criteria
for every requirement we defined.
So I'm going to keep on with the ensure the fence is pirate-resistant.
So, how could we make sure the fence is pirate-resistant,
I mean, how can we test that?
Perhaps it might have a test certificate from a manufacturer.
We could maybe stand behind the fence, holding a diamond, shouting, "Here, Mr.
Pirate, look!
"A nice shiny diamond for you!
" And validate it takes the pirate more than two hours to cut through the fence.
We could try our Swiss Army knife and our pen knife and see if
we could cut through the fence on our own.
And that would give us the assurance the fence will do its job.
So together, to protect the diamond,
we'd have this standard and this standard would have in it,
it would have a number of requirements.
It would have a description of the intent of the requirement to help
people interpret what it means and it would have a number of testing
procedures to validate the requirements in place.
And it won't surprise you to know this is how PCI DSS is constructed.
So, I'm going to pick one example, Requirement 6.
4.
3,
which specifies that live card numbers shouldn't be used
or tested in development environments.
It explains the intent behind the requirement and then how an auditor or
an assessor can validate the requirements in place.
So a requirement, the intent of the requirement, and a testing procedure.
And if we look at the real printed standard,
you can see that we've got the requirement,
the guidance describing the intent of the requirement,
and then the testing pro-- actually, that's a bit small.
Let's just zoom in on this and actually have a look properly.
So, yeah, that's better.
So now we can actually read, we've got there,
we've got the requirement,
we've got the guidance that describes the intent of the requirement,
and we've got the testing procedure.