Requirement 6.4 is in my opinion one of the most important in PCI DSS.
In fact, it's so important that it has its module in this course,
and that's because it deals with change,
and more specifically change control.
If you're concerned we finished the last module with 6.2, don't worry.
Requirement 6.3 is in the next module along with the other
requirements relating to software development.
Requirement 6.4 is very simple.
It demands that an organization must have documented and in use and
compliant with PCI DSS change control procedures,
and that such change control procedures follow the requirements laid down in the
very detailed and quite annoying at times sub requirements.
I love the PCI DSS guidance series; it says,
look, without effective change management,
bad things will happen to the security of the environment,
which is like that's no surprise, is it?
What it doesn't say is this,
that change is also the one thing that is guaranteed to
make compliance environments noncompliant.
And I've seen this on so many occasions,
that a company will put lots of resources into a
project to get PCI DSS compliance, but then once the project team leaves,
the cardholder data environment is subject to business as usual change,
which doesn't follow the requirements of 6.4,
and so the environment slowly becomes both insecure and noncompliant.
To test requirement 6.4,
the QSA is just going to look at the documented change control procedures
and make sure that these meet the detailed requirements of PCI DSS and have
all the eight sub requirements included in them.
The first few sub requirements are actually not so much concerned with how
an organization manages its change control procedures,
but in the environment the organization establishes to make
sure that change is properly managed.
And so the first requirement is that the test or development environments are
kept separate from the live or production environments.
The guidance describes the reason for this,
and let's be honest; it's really sensible security practice,
because the test or development environment isn't going to be maintained
and managed as securely as a production environment.
And so the key point of this requirement is that the separation is enforced
at the network level and also by access control lists.
To test this,
the QSA is going to look in two areas; firstly at network configurations to
make sure there's separation between the two environments,
and secondly,
that any access control records that allow access to each environment.
As well as network load separation,
PCI DSS also wants logical user separation between each environment,
which I know can be hard to achieve in smaller organizations.
The requirement of separation of duties between production and development
means that an account with access to the development environment shouldn't
have access to the production environment.
Yeah, I know, this is tough.
So look, ideally this would be absolute,
but it's, you know,
we recognize or PCI DSS recognizes that developers might sometimes need
access to production to help with troubleshooting,
and so it's okay for the same physical person to
have access to both environments, but they do need to have two separate accounts,
one for development and the other one with different rights to production,
and of course,
in a modern DevOps type of environment where you've got secure
continuous build and deployment pipeline,
you'd never have anyone accessing production anyway,
would you?
As you'd expect, to assess this requirement is in place,
the QSA is going to interview people and observe your change control
process to see that there's adequate separation of duties.
Requirement 6.4 .3 is a really simple requirement,
that live card data should never be used in a
testing or development environment, and that's obviously pretty sensible,
because the protection around development and test
environments isn't going to be good enough to prevent both
systems from being compromised by criminals.
And if you're asking yourself, well,
how on earth are you expected to test code and
systems without using real card data, the answer is actually pretty simple.
You just need to ask your processor, acquirer,
or merchant bank, the organization that accepts your payment card transactions,
to provide you with a set of test card numbers,
and these test card numbers will have certain rules associated with them
so that every time you use a particular test number,
you'll know in advance what response you're supposed to get
from the bank by using this test card number.
To test this PCI DSS requirement,
the QSA will look at the data in your development and testing environments,
ask you about test card data,
and check any relevant documentation such as the policy that says,
you will never use live data in a test environment.
One other very quick point about this requirement.
You've probably heard stories and seen movies where a scientist
tries out some new compound on themselves,
and you know,
they get better and they solve a world problem and they become a superhero.
Well, although it's sometimes pretty complicated,
writing payment processing code isn't that type of science,
and so please,
don't be tempted to use your own personal credit and
debit card numbers to test your code.
I've known loads of occasions where people have done this and
not only has their card been compromised,
but the card often gets blocked because they try so many transactions with so
many wrong parameters they may can't get home at night.
Continue the theme of separating separation between development or
test environments and production environments,
the next requirement aims to make sure that when a change is
promoted from development or test to production,
there's nothing that can compromise the integrity of the production
environment that's promoted at the same time.
And the two things that PCI DSS is really concerned about are migrating
accounts and data from data and test environments into production.
In my experience,
accounts using the test environment and particularly hard-coded test
credentials are the most common things you need to look out for here,
especially if you've got some API access involved.
The QSA is going to look at your test and release processes and
they'll speak to the people responsible for releasing systems and
releasing applications into production.
They'll also look at some recent changes and make sure that
these procedures were followed and actually that there was
documentation to prove they were followed.
Now requirement 6.4 .5 is one of the longest in PCI DSS,
because it is split down into even smaller,
more prescriptive requirements.
It says that your change control procedures must contain four specific things
and these specific things are concerned with documentation,
management approval, security testing, and a way of reversing the change.
The first prescriptive change control requirement is that the
impact of the change is being documented,
and PCI is particularly concerned about any changes to payment flows,
changes to the cardholder data environment,
and anything that impacts security.
The next is that the changes documented requires approval by whatever
level of management your change control process requires.
So it's not saying, you know,
this is how change control has to be working in your organization,
but it does say you have to have a documented approval process and your
changes have to go through this approval process.
Thirdly,
that the change control process requires functionality testing to validate
that the security of the system isn't affected by the change,
and for me,
this frequently translates into a manual pen test of whatever change is being
proposed in sort of a pre-production type of environment,
but then also some sort of test when things are being promoted.
And finally, a really interesting requirement,
that change control procedures must require that any change
also has a back-out or a reversal process.
Now, look, in mature organizations,
these back-out and reversal processes will exist in the
change control process so they'll require that the
back-out procedure is thought about, it's documented,
so that if there's a change that breaks functionality,
it can be reversed.
However,
PCI DSS requires backup procedures to be in place in case the
change breaks the security of the system,
not the functionality of the system.
And this is a great discipline to have,
because I've often seen changes that were made where the functionality worked,
but at the expense of the security of the system,
but the change wasn't backed out,
because the system was working and there wasn't a back-out plan.
So look,
having a back-out plan makes it much easier to
maintain the security of the system.
To test these four sub requirements,
the QSA is going to firstly check your change control
procedures to make sure that the requirements of PCI DSS
are written into your procedures.
They're then going to pick a sample of changes that occurred
in the previous year and for each one,
the QSA is going to look at the specific change control record for
evidence that the relevant documentation was produced,
that the impact of the change was documented,
the approval's there, and that the testing is there,
and the back-out plan is also there.
The QSA is going to interview people to make sure that
that process is generally followed,
but they might also ask about specific changes.
They might pick a specific change from the previous year and ask people,
how did you test that, how did that back-out plan work?
If this is an organization's first initial PCI DSS assessment,
there's obviously no change records for the QSA to look at,
so what they're going to do then is just look at your
documented change control policies and procedures.
The last requirement in 6.4 is a big one,
and I know from my experience looking at data breaches,
this is one of the most important security
requirements in the whole of the standard,
and the requirement is to reassess all relevant PCI DSS
requirements after a significant change,
because as I said at the beginning of the module,
change is what makes secure payment systems that
were previously secure insecure.
It's what makes previously compliant systems noncompliant.
So after a significant change,
it's vital to verify that all of the relevant PCI DSS
requirements are still in place.
Of course,
this requirement means that you need to decide on what
constitutes a significant change.
There is some help in the guidance bit of PCI DSS, but my general rule is this.
Significant change is anything added to the cardholder data environment,
whether that's new hardware, new software,
or new networking equipment,
any replacement or upgrades of hardware and software
in the cardholder data environment,
any changes in the flow or storage of payment card data,
any changes to the boundary of the cardholder data environment,
and therefore the scope of the PCI DSS assessment,
any changes to the underlying supporting infrastructure such as,
I mean like directory services or time services or
your logging and monitoring system,
and then finally any changes to third-party suppliers who
support the cardholder data environment.
And the minimum requirements that should be checked
after a significant change are: firstly,
the key documentation, the network diagram,
cardholder data flows, records of what systems are in scope,
these are essentials to check because they show that you've understood
and actually have recorded the scale of the change.
Secondly, that anything added or upgraded has that standard secure build to it,
it's been hardened, default accounts and passwords have been removed,
anti-malware software is installed and working.
Next,
any changes to the storage of cardholder data and the
pre-authorization storage of sensitive authentication data.
Next, look at the loggings.
Is every component in the cardholder data environment still generating logs,
and are these logs being monitored?
Next, whether the vulnerability scan covers all systems and devices.
And finally, is a penetration test needed?
Now this isn't an exhaustive check list.
It's my list of the bare minimum things I look for,
and your environment changes might be different so it's always
worth taking a really quick run through all 300 requirements
in the standard to ask yourself,
should I revalidate this requirement or is it okay?
Should I revalidate this requirement?
Just keep going through.
I mean, it's a bit of a pain to do, I'll be really honest,
but as I say, this is where I've seen most breaches of cardholder data.
The QSA is going to check for the evidence that you've done this,
so having actually have a checklist of things you've checked for and go,
yes, I'm going to do this, no, I'm not going to do this,
is a great idea to show them.
The QSA themselves are going to make specific checks of your change
control records and they'll try to match this up with a documentation
of records that should've been updated.
So they're really going to pay particular attention to the network diagram,
inventory, and cardholder data flows.
A good QSA will use their knowledge of the significant changes to your
environment that occurred in the past 12 months when they pick systems
to sample test for the other requirements.
So they'll look at what's been added to the CDE in the past 12 months,
and you can guarantee those are the ones that they're going to
look at to see if they can play with PCI DSS.
Now it's time to return to that conversation I had with Jacob
about how to manage change to ensure that all PCI DSS compliance
and cardholder data security is embedded and becomes business as
usual in an organization.