Requirement 6 is perhaps the most important in PCI DSS.
In my experience,
noncompliance with its requirements is the most common
cause of breaches of cardholder data and also the most
failures in annual assessments.
The requirement is concerned with the development and maintenance of
secure systems and is split into three logical sections,
which we're going to explore over three modules.
This module looks at the two requirements focused on
vulnerability management and patching.
Next, there's a whole module dedicated to requirement 6.4,
which is all about change management, and then finally,
a module concerned with software development,
which includes the basic practices for managing software development,
making sure that code is written securely,
and the protection of web-facing applications,
and as I'm sure you can guess,
the last requirement wants to see the policies and procedures in
place to ensure these practices to develop and maintain secure
systems and applications are actually followed.
Because requirement 6 is concerned with patching,
vulnerability management, and change control,
it is going to apply to all systems in scope of PCI DSS,
and of course, if you develop any software internally,
whether that's externally facing or just for internal use,
if that software runs within that CDE,
it's in the scope of the software development requirements.
So let's start off by looking at requirement 6.1 and 6.2,
which together address vulnerability management.
Now requirement 6.1 is superficially very simple.
It demands that you actively risk access vulnerabilities
within the cardholder data environment.
The requirement is split into two parts.
Firstly,
that you have a way of keeping track of new vulnerabilities that are announced,
which could affect systems within the CDE.
More specifically, actually,
the requirement is that you make use of external resources.
So those could be commercial vulnerability subscription services,
vendors' websites,
the Midas CVE list or the NIST National Vulnerability Database.
The key thing is that you've got an inventory of what's in your CDE,
and you're proactively making sure that you're aware of any
vulnerabilities announced for software and for system components.
The second part of 6.1 is that you assign some sort of
risk ranking to each vulnerability.
The standard gives examples of high, medium,
and low, but you could pick any risk ranking methodology you want.
What's important is that you have a process to identify
and risk rank new vulnerabilities,
and although I've talked about this in terms of
inventories and awareness of vulnerabilities,
there are plenty of agent-based tools you can use to create such inventories
and which also talk to commercial vulnerability databases.
Now in all my time working with PCI DSS,
I've seen this requirement cause lots of confusion,
because this isn't a requirement to use a vulnerability scanner that scans your
CDE looking for assets and testing them for vulnerabilities.
Vulnerability scanning is actually a separate requirement.
It's in requirement 11, and we'll look at that later.
Secondly, this requirement is not just about vulnerabilities.
What asset the vulnerability affects is also really important.
A vulnerability on a database server that stores 3 million payment cards is
much more serious than an update service and within the CDE.
So when you're working on risk ranking,
it's really important to consider the asset as well.
I've seen so many organizations just use the base CVSS scores
without applying the environmental metrics.
PCI DSS wants you to understand the risk to your
environment caused by vulnerabilities,
and you can't do that without understanding the role of
the asset affected by the vulnerability.
The standard is most keen that you identify critical vulnerabilities,
which are those that pose an eminent threat to the environment,
which impact critical systems,
or those that may result in a potential compromise if not addressed.
In an assessment,
the QSA will look at the vulnerability management processes and policies.
They'll talk to the people responsible for monitoring
newly announced vulnerabilities, and also for conducting that risk scoring.
Conscientious QSA may look at records of risk scoring over the past 12 months,
and if you're using a system that relies on host-based agents to
maintain an inventory of the software on each system,
which is matched up with the commercial vulnerability database,
the QSA will probably want to look at the central management console for this.