The next requirement looks at how we build and configure every device in
the cardholder data environment to be secure by default.
And there are quite a few sub-requirements to guide you as
to what PCI DSS thinks secure means.
The first thing is to make sure there's a configuration standard for every
system and device on your network and that your internal standards are based
on some industry-accepted hardening standard.
These could be from vendors or from independent third parties.
Many manufacturers publish hardening standards and guidance.
So, if you use Windows, Microsoft has a bunch of them on its website.
There's also a number of independent hardening standards published.
Perhaps the most common are the Center for Internet Security,
or CIS, benchmarks.
These exist for almost all operating systems,
cloud configurations, and networking devices.
And if you use the CIS benchmarks,
I can guarantee your QSA will have heard of them and
accept they're an industry standard.
And personally,
that's what I always use when I'm developing hardening
standards at any organization I work in.
Thinking of the QSA, now,
they're going to look at those standards and make
sure your systems are built to them.
And this is actually really hard because this is one
area you can get into real problems.
You know,
it's really easy to initially pick hardening standards and define them
because you can download them from the internet,
and you can get some tools that will check builds against standards.
What's going to be more difficult is to keep that standard up to date.
So,
as operating systems get patched and you get other
vulnerabilities that are addressed in the operating system,
you have to do two things.
You have to patch in managing your existing in-place estate,
and you also have to make sure you update your
hardening and configuration standards,
which is why just about all organizations rely on
external sources for these standards.
The next requirement, 2.2 .1, is a strange one.
It says that servers should only be doing one thing.
The exact term used,
and in this case it's really important to look at the exact term,
is that servers should implement one primary function per server.
And as the guidance explains,
the intention of this requirement is the server can,
of course, do multiple things,
but all the things the server does must require the same level of security.
So,
perhaps a better wording would be to say that servers can only perform a set of
tasks that require the same security profile on the server.
So it'd be acceptable for a server to be a DNS server and a time server,
but it wouldn't be acceptable for say a server to look
after a website and host a database.
To test this requirement,
the QSA is going to look at what services are running on each individual server.
Now, I guess one question you might be asking is,
what about virtual servers and whether the hypervisor,
for example,
could be running multiple different servers
requiring different security profiles?
And, of course, the answer to that is yes,
it can, although, that said, if you're using virtual servers,
the standard is pretty clear,
but you wouldn't mix systems in the CDE with systems
outside the CDE on the same hypervisor.
The next requirement follows logically on from this in that once
you've decided what your servers should do,
you should just enable this functionality and nothing else.
So when you're configuring a server or device,
PCI DSS requires you to only enable functionality that you're going to use.
Logically,
what you're doing here is minimizing the potential attack surface of the server.
To test this requirement,
the QSA is going to look at what services and protocols are enabled on
systems and make sure that that's what you intended.
PCI DSS accepts that sometimes you might need to use
insecure protocols and services,
but requirement 2.2 .3 wants you to do this knowingly,
and it wants you to make them as secure as possible.
And so where you have an insecure protocol or service,
you need to consider what else you can do to add a layer of security to it.
That could be something like adding cryptography to something or
wrapping one insecure protocol within a secure protocol.
Perhaps the most common example I've seen of this is
where you need to run an FTP server,
which we all know has got some security limitations.
And so you may typically implement your FTP server,
but you may open it over a TLS connection.
And to test this requirement,
the QSA will look at how systems are configured and
probably at some documentation as well.
Requirement 2.2 .4 aims to test both your configuration standards
and the people responsible for implementing them.
Essentially,
it wants to make sure that your configuration or hardening
standards cover all relevant security-related settings and
that your administrators, the people responsible for configuring the systems,
know how to follow your standards and how to
configure the system in a secure manner.
So, in addition to looking at the standards and actual system configurations,
the QSA will want to talk to the system administrators.
The final sub-requirement in 2.2,
it's a strange one because you might remember that in requirement 2.2
.2 PCI DSS required us to only enable things that were necessary for
the operation of a server or network device.
Well,
requirement 2.2 .5 asks us to go one step further and remove
or disable any functionality that's unnecessary which may
have been enabled by default.
You know,
I suspect this is one of those requirements that were
added after a significant data breach,
and the merchant who was breached will have argued,
well, that they only enabled necessary functionality,
but that the attacker took advantage of
functionality that was turned on by default,
and the merchant hadn't disabled the functionality because the standard didn't
say they had to disable functionality they weren't using.
Now, you and I might think it's common sense,
only enable stuff you're using is the same sort of thing
as disable stuff that you're not using, but the standard didn't say that,
and so the next version of the standard was amended to
put this type of statement in it.
Now,
hopefully this forms part of your serving the hardening configuration already.
Simply, you need to disable any service or protocol that's not necessary.
You know, and like many of the PCI DSS requirements, this is just common sense.
Again,
we're reducing the attack surface by removing the number
of things that criminals can attack.
And actually,
doing this will also give us benefits when we come to patching and
vulnerability management when we get to requirement 6.
Because the fact we're not running a particular protocol or service
on our server means that if a vulnerability is found in that
protocol or service and we're not running it,
we're not going to have the same urgency or necessity for patching.
The QSA is going to look at systems and documentation,
and particularly,
if you've got a process that requires that an administrator disable something,
the QSA is going to make sure that it's disabled,
but also,
say you wrote a process that says when we're building these type
of servers there's going to be a checklist,
the QSA is going to look at a checklist.