Removing All Unnecessary Functionality

PCI Requirement 2.2.5 states, “Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file system, and unnecessary web servers.” Unnecessary functions are yet another way that hackers could gain access to your system, so if a function is not needed, it needs to be shut off. The PCI DSS says that, “By removing all unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.” PCI Requirement 2.2.5 is not just focused on servers; it applies to protocols, ports, services, applications, databases, etc.

It is not the assessor’s job to define what is necessary or required for your business. That is the organization’s responsibility. It is the assessor’s job to verify that you are doing the things you say you’re doing to keep your system secure. When an assessor asks you to validate why you need a certain application or port, it’s not to challenge you. It’s to gain an understanding of the level of due diligence that your organization has gone to.

Like other PCI Requirement 2 sub-requirements, the way to test that your organization meets PCI Requirement 2.2.5 is to take a sample of system components and compare it to your configuration and hardening standards. An assessor will inspect the sample to see that all unnecessary functionality has been removed, that there is appropriate documentation that verifies enabled functions, and that only the documented functionality is present on the sample. For example, if an assessor finds unnecessary default services running, this would call into question whether or not you’ve actually hardened your assets.

The purpose of PCI Requirement 2.2.5 is to help protect your organization’s environment from becoming susceptible to malicious individuals. Like many other PCI Requirement 2 sub-requirements, PCI Requirement 2.2.5 hopes to protect your organization from providing opportunities for hackers to invade your environment. Just remember: if it is not needed, it needs to be removed. Once PCI Requirement 2.2.5 is met, your organization can focus on securing the functions that are required for your business.

PCI DSS Requirement 2.2.5

Moving along with the theme of removing things that are unnecessary, we come to the next requirement, PCI DSS Requirement 2.2.5. This requirement specifically states that we have to remove all unnecessary functionality. This would include protocols, ports, services, applications – really anything. Understand that this is not just focused on servers; this is your application layer, this is your database layer. It basically boils down to: if it’s not needed, it needs to be shut off. From an assessment perspective, it’s really not our job as assessors to define what’s required for your business. It’s not our job to state whether or not you truly need something or not.

When we’re asking those questions as assessors, like “Why do you need this?”, it’s not really to challenge you to say you don’t need it. It’s really to get an understanding of the level of due diligence that you’ve done around why this particular situation or why this particular configuration is required. For this assessment, what we’re doing is we’re going back and we’re looking at your configuration standards, looking at your hardening standards, and then we’re looking at what’s actually installed. Often times we find unnecessary default services running and once again, this calls into question whether or not you’ve hardened those assets.

Preventing Misuse

PCI Requirement 2.2.4 requires, “Configure system security parameters to prevent misuse.”

There are two parts to compliance with PCI Requirement 2.2.4. First, the technical part: your organization’s system configuration standards and hardening guidelines should discuss security settings that have known security implications for each type of system in use. Assessors will need to examine the configuration standards as part of this assessment, to ensure that common security parameter settings are included. A sample of system components should also be inspected to make sure that anything considered risky or might be misused has the appropriate security controls in place to prevent that misuse.

Second, the personnel part: in order for your systems to be configured securely, the staff that is involved in managing these assets needs to have adequate technical and security expertise to understand what types of configuration settings might cause your systems to be misused or risky. To verify that your organization meets PCI Requirement 2.2.4, assessors need to have a conversation with the responsible staff to understand their general knowledge of the security of your system components.

PCI DSS Requirement 2.2.4

The PCI DSS tries to be a one-size-fits-most. The Council realizes that you cannot define security requirements for every situation in every environment. If that was the case, the particular standard being about 400 particular requirements would end up being a mile long.

When we look at the next requirement within the PCI DSS, it defines the needs to configure systems to prevent misuse. Really, what we’re looking for here, is that the administration staff that is involved in managing these assets has the technical expertise and the security expertise in order to understand what types of configuration settings might cause these systems to be misused or be risky. We’re looking for, from an assessment perspective, to have a conversation with the administration staff to understand their general knowledge of the security of these assets. We’re actually going to be looking at the configuration settings as part of this assessment as well, to make sure that anything that might be considered risky or might be misused in some capacity has the appropriate security controls in place to prevent that misuse.

Why Your Organization Needs To Implement Additional Security Features

Under PCI Requirement 2, which focuses on hardening your organization’s systems and assets, we find PCI Requirement 2.2.3. PCI Requirement 2 is not just about your servers, it’s about any asset within your environment. PCI Requirement 2.2.3 is also about all types of assets within your environment. PCI Requirement 2.2.3 instructs, “Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.”

There may be situations when your organization needs to use something that is considered insecure, like an application, service, or protocol. In these situations, the PCI DSS does not prohibit you from running these things, but you must implement additional security features to render these risky applications, services, etc. safe to use.

PCI Requirement 2.2.3 exists to make it harder for malicious individuals to enter your network. Implementing additional security features to risky or insecure services, protocols, or daemons makes it a challenge for hackers to take advantage of commonly used points of compromise within a network. PCI Requirement 2.2.3 recommends that organizations implement additional security features before a new server is deployed in order to prevent servers being installed into the environment with insecure configurations.

In order to help your organization comply with PCI Requirement 2.2.3, an assessor may ask for a copy of your Nmap or run an Nmap scan to determine what the open ports are within your environment and which services are running. This list of open ports and running services will be compared to your hardening standards and configuration guidelines. If an assessor identifies something as risky, they need to see appropriate documentation that explains your additional security features and how they make risky services safe. Then, they will verify that those security features are actually implemented within your environment, not just documented.

It’s important to note that if SSL/early TLS is being used, the testing procedures outlined in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS need to be performed.

To find industry standards and best practices for implementing additional security features, strong cryptography, and identifying services, protocols, and daemons as risky or secure, look at NIST SP 800-52, SP 800-57, OWASP, etc.

PCI DSS Requirement 2.2.3

From the hardening perspective, there might be situations where your organization has to use an application that might be insecure, or use a protocol, service, or something that might be considered insecure. To give an example, years ago we used TLS 1.0. You might have Legacy applications that will only run on a TLS 1.0 protocol. In these situations, the PCI DSS does not prohibit you from running these protocols, ports, and services. But what it does say, is that if you’re going to be running these risky protocols, ports, and services, that you have to implement other security features or other security measures to render these risky protocols, ports, and services as un-risky.

So as an assessor, we’re likely going to be asking you for a copy of your Nmap or run an Nmap scan within your environment. This will let us know: what are the open ports? What are these services running? Once we get this list, we’re going to want to marry this up to your hardening standards and configuration guidelines to see why you have these things open, what’s running. We’re going to look at the running services on the boxes. If we identify that something is risky, we’re then going to look for what you’ve documented; you’re required to document about these security features. So we’re going to look at what you’ve done from a documentation perspective, in terms of rendering these particular protocols, ports, and services un-risky. Once we’ve identified what you’ve done from a risk perspective, we’re going to actually look to see that those particular things that you’ve documented have been implemented within your environment.

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.

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.

Finding Cross-Over Between Servers

PCI Requirement 2.2.1 is another requirement focusing on hardening standards. PCI Requirement 2.2.1 states, “Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. Where virtualization technologies are in use, implement only one primary function per virtual system component.”

Assessors need to make sure that your systems only have one primary function per server. So, what does it even mean to implement only one primary function per server? To comply with PCI Requirement 2.2.1, assessors look to ensure that if, for example, your organization has a server within the presentation tier, that it is not also sitting in the data or application tier. What would happen if one security tier became compromised? Everything else within that tier would become vulnerable. Assessors must make sure that one tier doesn’t pose a risk to another. The PCI DSS states, “If server functions that need different security levels are located on the same server, the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. Additionally, the server functions with a lower security level may introduce security weaknesses to other functions on the same server. By considering the security needs of different server functions as part of the system configuration standards and related processes, organizations can ensure that functions requiring different security levels don’t co-exist on the same server.” To comply with PCI Requirement 2.2.1, security tiers must be separated.

To verify that your organization’s hardening standards are implemented and functioning properly, your organization should examine a sample of system components and check to see that only one primary function is implemented per server. The same applies to virtualization technologies; verify that the sample taken meets PCI Requirement 2.2.1.

During the assessment process, your organization’s assessor should pull all of the running services, installed software, and configurations to examine what functions each of your servers have. If they find cross-over between servers, they will find an answer as to why that is. To comply with PCI Requirement 2.2.1, assessors must ensure that your systems implement only one primary function per server.

Continuing on with the hardening standards, we want to make sure that your systems only have one primary function per server. Specific to Requirement 2.2.1, the PCI DSS says that you may only have one primary function per server, so I want to take a little bit of time to describe what that means. What we’re talking about is cross-pollinating the security domains. If you have a server that sits within the presentation tier, we want to make sure that it’s not also standing in the data tier or in the application tier. The reason for that is that if one of these security tiers should somehow become compromised, we want to make sure that it doesn’t pose a risk to one of the other security tiers.

A lot of the time, what we see is that an organization might have a web server that’s producing and publishing web pages, but secondary to that, what we also see that they have a database server sitting on that same application server, and that would violate this particular requirement. So, assessors want to make sure that where you have different security tiers, those are separated. However, it wouldn’t be necessary, if you have something that’s sitting in an application tier, to give an example from Microsoft, you would have an authentication server as your active directory, that particular server could also serve your DNS, your DHCP, because those are all sitting in that same security domain. But what we would not expect to see is your application server is also your active directory server; that would be another situation that is not allowed.

So the assessor will pull all the running services, all the installed software, and all the configs and look at these to see what’s running, see what’s been installed and where there are questions on crossing those lines, they will ask questions as to why that is.