Anyone who reviewed the impact of the PCI DSS 3.0 changes on organizations two years ago might recall a set of...
requirements marked "Requirement X is a best practice until June 30, 2015, after which it becomes a requirement." If their response was "we can handle that later," it's time to realize "later" is about to arrive.
When the PCI SSC released the final PCI DSS 3.0 standard in November 2013, it realized some of the requirement modifications would have an outsized impact on organizations. It provided merchants and service providers with a 20-month grace period to slowly adapt to those changes. This tip takes a look at the previously optional requirements that are about to become mandatory and their impact on organizations.
One side note -- the PCI SSC recently released another update to PCI DSS, version 3.1. This update specifically covers the use of insecure SSL/TLS protocols and does not alter any of the delayed PCI DSS 3.0 requirements. While you should be developing an action plan for PCI DSS 3.1, you should definitely tackle these items first.
Physical security of card reading devices
Requirement 9.9 requires merchants to "protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution." This requirement, designed to protect against skimming and other techniques that tamper with the reader itself, applies to merchants involved in card-present transactions.
If an organization has point-of-sale devices that allow customers or employees to swipe payment cards, it has a few months left to get its act together on this point. Organizations need to document and follow policies for maintaining an inventory of all card swipe devices, inspecting those devices periodically and conducting training of personnel about the importance of physical security and the risks posed by device tampering.
Penetration testing methodology updates
One of the biggest changes to PCI DSS 3.0 involves the rigor of the methodology used for penetration testing, outlined in Requirement 11.3. The PCI Council is becoming much more prescriptive about the scope of the testing and the techniques used by testers. All tests performed after June 30 must follow the new standards.
It's a good idea to read the details in the standard during any redesign of the methodology, but here are the basics: First, organizations must use an industry-accepted approach for testing, with the council recommending NIST SP800-115. Second, the testing must include internal and external tests of all cardholder data environment components, including scope-reduction techniques such as network segmentation. Third, include both network- and application-layer tests. Finally, organizations must tie testing to a risk review and retain documentation of the testing and remediation results on a formal retention schedule.
Authentication and session management
The most recent version of the OWASP Top 10 Web application security threats rated broken authentication and session management as the second-highest threat facing Web applications today. Recognizing this, the PCI SSC added details about mitigating this risk to the PCI DSS 3.0 standard to Requirement 6.5.10 and used the June 30 deadline as an opportunity for developers to revisit their work.
The standard recommends developers follow secure coding practices. Web application developers must flag session tokens as secure, remove session IDs from URLs that may be captured in logs, and rotate and expire session IDs after authentication. This may require substantial reworking of Web applications, so it's time to get moving.
Two more PCI requirements for service providers
That's all merchants need to handle as far as new requirements coming online in June. Service providers, on the other hand, have two additional requirements to address. The first of these, Requirement 8.5.1, applies to service providers who remotely access customer systems. The update requires that they use unique credentials for each customer, rather than a shared master password across all accounts.
Service providers also must follow the new requirement in section 12.9. This one is more administrative, requiring that they send customers a written notice that explains the service provider is responsible for PCI DSS compliance for cardholder data that they store, process or transmit on behalf of the customer.
There are still a few months left before the deployment of these new requirements. It's a good time to get those projects rolling and allow a little wiggle room to become PCI DSS 3.0 compliant -- especially since PCI DSS 3.1 is now a reality.
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.