tiero - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Why PCI non-compliance is a problem for many

PCI DSS requirement 2 specifies companies must change vendor-supplied default passwords, but only 50% were in compliance. Expert Mike Chapple explains why.

According to the 2014 Verizon PCI DSS compliance report a surprising 48.9% of companies failed to fully meet the demands of PCI DSS Requirement 2. The requirement, summarized as "do not use vendor-supplied defaults for system passwords and other security parameters," seems straightforward. Who doesn't change default passwords these days? But if it's so simple to do, why is it a factor in PCI non-compliance for so many organizations?

The reality is that the requirement is much more complex than simply changing default passwords. PCI DSS compliance requirements include quite a few conditions under this same banner, including developing system configuration standards, implementing separate servers for each primary function, removing unnecessary functionality, and encrypting non-console administrative access. The full text for Requirement 2 fills six pages and provides great detail on merchant expectations.

This tip reviews the requirement to change vendor-default passwords, the scope of the problem, and what technologies and processes organizations should have in place to identify systems with default passwords, make the changes and manage the overall process effectively.

Where's the true challenge?

If your organization is running an insecure protocol such as telnet, FTP, among others, it needs to have the documentation to back up the business justification for its use. And the justification must contain sound reasoning.

Closer reading of the Verizon report provides interesting insight into Requirement 2. Only two of 32 requirements in this section made it onto the list of the bottom 20 controls from a compliance perspective. Those two controls both relate to limiting the use of unnecessary and insecure services and documenting business needs. They both implement the same PCI DSS requirement 2.2.2, which states that organizations must "enable only necessary services, protocols, daemons, etc., as required for the function of the system."

The first of these two controls instructs auditors to "select a sample of system components and inspect enabled system services, daemons and protocols to verify that only necessary services or protocols are enabled." In Verizon's analysis, only 55.4% of companies complied with this requirement. The key here is documentation. Auditors look for evidence to substantiate compliance. If a company has carefully evaluated the necessity of each service on a system, it should have paperwork to back that up. If a company doesn't have records, the auditors must assume it has not evaluated the business necessity and will fail it on the audit.

Merchants performed even worse on the second half of this requirement, 2.2.2.b, with only 51.5% compliance. This requirement instructs auditors to "identify any enabled insecure services, daemons or protocols, and interview personnel to verify they are justified per documented configuration standards." If your organization is running an insecure protocol such as telnet, FTP, among others, it needs to have the documentation to back up the business justification for its use. And the justification must contain sound reasoning.

What should merchants do?

First and foremost, a merchant must ensure it performs the actions required by PCI DSS. Document the business necessity for services running on the systems with particular attention to any services auditors might consider insecure. This doesn't need to be complex and may be a part of the configuration standards. For example, if a company runs a set of management services on each system in its environment, the standard might contain the line "All systems must run the X, Y, and Z management services to facilitate automated system administration tasks." Just be sure to have the documentation to substantiate each service you run.

Don't focus exclusively on the paperwork, however. Documentation is only helpful if it supports the reality of the system configurations. It's a good idea to perform manual and/or automated assessments of systems against standards on a regular basis. If your organization is running an undocumented service, it should discover the service, not an auditor.

PCI non-compliance: Learning from the mistakes of others

The Verizon PCI compliance report offers merchants and service providers a rare opportunity to learn from the mistakes of others. By studying where others have stumbled on their PCI compliance journeys, enterprises can avoid making the same mistakes.

About the author:
Mike Chapple, Ph. D., CISA, CISSP, is a senior director of IT with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com, and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He is a technical editor for SearchSecurity.com and Information Security magazine and the author of several information security books, including the CISSP Prep Guide and Information Security Illuminated.

Next Steps

The 2015 Verizon PCI report is here: See what's new with compliance trends.

Check out this video guide that answers common questions on each PCI DSS requirement.

Learn more about how Shellshock will affect PCI DSS audits for enterprises.

This was last published in April 2015

Dig Deeper on PCI Data Security Standard