If It’s Not Required, Get Rid of It
We believe that the PCI DSS, or really any information security framework, boils down to a simple philosophy: if you do not need it or it is not required, get rid of it. PCI Requirement 2.2.2 directly correlates to this methodology. It directs, “Enable only necessary services, protocols, daemons, etc, as required for the function of the system.” Your business should be aware that some services and protocols are regularly used by hackers to compromise an organization’s network; the services or applications that your organization needs are acceptable and justified, but there must be appropriate documentation. If a service, protocol, etc. is not required, assessors will expect it to be removed. Just remember: if it’s not required, get rid of it.
We find that default services are a common challenge for PCI Requirement 2.2.2. We see many organizations that will run a server or application based on its default environment or setting, which causes some issues. Jeff Wilder says that if he encounters a default service such as Microsoft Theme or Audio running, he questions if you’ve really done due diligence to remove all unnecessary services, protocols, daemons, applications, etc. If an assessor finds that a component is necessary, they will expect the documentation to be appropriately updated.
To verify that your organization complies with PCI Requirement 2.2.2, a sample of system components should be tested to validate that only necessary services, protocols, daemons, etc. are enabled. Personnel should also be interviewed to conclude if insecure services, protocols, daemons, etc. are justified. Assessors will look within your hardening standards and guidelines, because these documents should define how operations should be run, define how to secure these applications, and show that nothing unnecessary has been installed or is running. If there’s something that has been installed or is running that is not documented in your hardening standards or guidelines, you assessor should question this.
PCI Requirement 2.2.2
When we look at the PCI DSS or really any other security framework, it really boils down to a simple philosophy: if you don’t need it or it’s not required, just simply get rid of it. We look to apply this same methodology and same practice around the hardening of your systems. We have a requirement that says that only the necessary services and applications should be installed and running on these assets. If you need a service running, if you need an application installed on that server, that’s perfectly fine – there’s nothing wrong with that. However, if it’s not required or needed, we expect it to be removed.
We look within your hardening standards and guidelines to define what it is that we really need in order to secure these applications, and that nothing else has then been installed or is running. So, what we do for this assessment is look at your hardening standards and guidelines because these documents will specifically outline how you want your operations to be run and how these assets should be configured. We then take that back and look at what’s been installed and what’s running. If there’s something that’s been installed or something that’s running that’s not on your hardening standards or guidelines, your assessor should ask why that is.
What we often find within the organization is that people will stand up a server or application and it’s running based on its default environment, which in some situations might be okay but in others not so much. So effectively what we want to do is a full inventory of what’s running on the systems from the default install. To give an example in the Microsoft environment, you’ll also find services such as Themes running or Windows Audio running – we often encounter that – and when I look and I see that these default services are running, it really brings into question for me, from the assessor’s perspective, if you’ve really hardened your boxes, if you’ve really done the due diligence to remove all of those services, applications, or anything that isn’t required for the system to operate. If we find that there are, we’re going to ask questions and look for you, if it is required, to update your documentation to support that appropriately.