PCI Requirement 2.2 – Develop configuration standards for all system components
by Randy Bartels / June 30th, 2017
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.
