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.

Developing Configuration Standards After Industry Best Practices

System configuration standards are the proper configuration of system components like networks, servers, and applications.

PCI Requirement 2.2 ensures that organizations configure their systems to fix security vulnerabilities. There are two parts that need to be completed in order to comply with PCI Requirement 2.2. First, PCI Requirement 2.2 directs organizations to, “Develop configuration standards for all system components.” Your hardening and configuration standards do not only apply to your servers; they extend to your organization’s applications, databases, and workstations as well.

Second, PCI Requirement 2.2 says, “Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.” We want to ensure that your organization is basing your configuration standards after industry best practices.  There are many weaknesses in operating systems, databases, applications, and other technologies that hackers are aware of, but you aren’t. The PCI DSS says, “To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses.” This doesn’t mean you cannot customize your configuration standards, but your organization does need to have a documented set of standards or guidelines that define how you harden your assets. There are many published standards available for public access that represent industry best practices, like NIST, NSA, SANS, Microsoft, CIS, or ISO. We recommend you look through available published standards and determine which hardening standards or guidelines make sense for your business.

We find that it is a challenge for many organizations to build adequate documentation about their hardening standards, but assessors are looking for a set of guidelines that define your organization’s configuration standards. During the assessment process, an assessor will want to examine the actual configurations of your servers and your documented hardening standards. An assessor will look to see that the documentation says, “If you have X server or application, these are the things that you do.” These documents should also provide individuals who are new to the environment with the knowledge they need to harden systems and get them ready for business operability and production.

Complying with PCI Requirement 2.2 is an ongoing process. As new weaknesses are identified, your configuration standards must be updated to keep your system secure.

Looking at the PCI DSS Requirement 2.2, or really any other framework that you might be being assessed for, we want to be sure that you’re basing your hardening standards after an industry best practice. This isn’t to say that you can’t customize your hardening standards, but really, you have to have a documented set of standards that define how you go about building your assets. Most organizations, if they have a server, might have a hardening document. We often find that a lot of customers that we have are challenged by this area. There’s a lot of industry standards out there that you can look at – NIST, NSA, SANS, Microsoft, Red Hat – they all of published standards so that you can publicly gain access to their hardening guidelines and standards that they publish. What we recommend, as assessors, is you get a copy of those documents and you look through those assets and document the hardening standards that make business-sense for you.

Once again, what we will ask for from an assessment perspective, we will pull the actual configs off these servers and we’re going to pull your hardening standards. We’re going to look for this 1-to-1 comparison that says, “If you have X server or application, these are the things that you do.”

Also understand that these hardening guidelines and standards are not just about your servers; they extend to your applications, your databases, and your workstations as well. There are a lot of different technologies that are called out within the PCI DSS – file integrity monitoring, encryption solutions that might be utilized – but effectively, what we’re looking for is a set of guidelines that define how you harden your systems.

The intent behind these documents is that if a new individual comes into the environment, or an employee leaves, you can provide this documentation and that this documentation be written to a level that if they understand the general technology that they’re working with, at the end of the practice of using the hardening standards, those systems will be fully hardened and ready for production.