Of course,
there will times when an organization can't comply with
one of the requirements in the standard.
And there's actually a mechanism for an organization to do
something else if it can't meet a requirement because of a
legitimate technical reason, such as, I don't know,
a legacy device, for example.
Maybe you've got a system that only supports Telnet
and not SSH for administration.
Or a real documented business constraint.
I don't know, again, a system,
maybe a system that is due to be completely replaced next year,
so you wouldn't want to spend lots of money on a
temporary solution to make it compliant.
And so the standard has a mechanism to allow you to
cater for these eventualities.
And that's called a compensating control.
And any compensating control must meet the intent of the
original requirement and it must be just as strong,
so it has to have the same security effect as the original requirement.
And, it can't just be an existing PCI DSS requirement.
So, take our example of a system that didn't support SSH for log in.
You couldn't then say, "Well, I'll have a really long password,
" as a compensating control because that wouldn't
fulfill the intent of the requirement,
which is the password doesn't travel in plain text over a network.
And having a long password is already a PCI DSS requirement.
Now, you know,
I've dealt with lots of organizations that don't
like to use compensating controls.
They think they're dirty or wrong or it's a failure.
You know, the standard's designed to allow people to do this.
You know,
the PCI DSS knows that this prescriptive standard can be hard to follow,
where you've got billions of different organizations
with lots of different technologies.
And so I'm really going to encourage you to use compensating controls wisely
when there are real technical or business constraints.
I've also hear silly rumors that you can't use a
compensating control for more than a year,
that's not true.
They just have to be re-evaluated every year to make sure you've still
got a documented business constraint or a legitimate technical problem
that means you need the compensating control.
One concern people have with this standard is how frequently it changes
because staying compliant with an ever-changing standard would be like
trying to shoot something that was moving all the time.
And the answer with PCI DSS is the standard changes about every three years.
It was released in 2006, it had a minor upgrade in 2008,
and the first major revision, Version 2,
in 2010.
The next major version, Version 3, came in 2013,
and then there was a minor upgrade for typos and the SSL problem in 2015.
By the SSL problem,
I mean that in this deprecated SSL and the standard actually
referred to SSL as an example of a secure protocol,
and so it had to be revised then.
Version 4 was expected at the end of 2016.
But actually, we got a minor update called, Version 3.
2.
The rumor now is that we won't see a Version 4 of PCI
DSS until 2018 at the earliest.
Now, on this trying to shoot the moving target,
when a new version of the standard comes out,
organizations have at least 12 months to prepare for
the new version of the standard,
and any really significant new requirements also generally
start off by being a recommendation before they become a
requirement and they typically have, say,
an 18-month vacant period.
Now, finally, in case you really are just about to go into a meeting,
we need to discover a couple of really strange words that
people in the PCI industry use all the time.
The first is PAN, or Primary Account Number.
And that's PCI speak for the long 15 or 16 digit number
found in the middle of the payment card.
You might have called this the big card number in the
middle of the payment card before, but from this point forward,
it's a PAN.
The second, SAD, or Sensitive Authentication Data.
This refers to the secret values that are used to
authenticate a card or a cardholder.
There's three of them you really need to be aware of.
In the merchant environment,
this would either be the data encoded in the magnetic stripe on the card,
or the CVV2 value printed on the back of the card that's used
in e-commerce or mail order transactions.
SAD also refers to the customer's PIN.
And so, PAN and SAD, and knowing PAN and SAD,
you can now speak basic PCI because you'll hear people talk about
doing things to the PAN or you can't store the SAD,
so that's what they mean when they're talking about PAN and SAD.
So that's a quick look at PCI DSS,
the highly prescriptive technical standard that consists of 12
requirements split into about 280 sub-requirements.
Each sub-requirement is defined along with guidance
describing the intent of the requirement,
with testing procedures that you or an external assessor will be able to use to
validate a requirement's truly in place and is functioning.
The standard applies to all people, processes,
and systems that store, process, or transmit cardholder data,
which is known in PCI terms as the cardholder data environment.
And also,
it applies to anything that's connected to the cardholder data environment.
And in the next module,
we'll discover why companies choose to comply with this
technical standard to protect cardholder data.