PCI DSS 3.0: Business as Usual?

By Randy Gainer, Attorney, CISSP, and Christin McMeley, CIPP-US

• Focusing on “security, not compliance;”
• Making PCI DSS a “business as usual practice;”
• Providing “added flexibility on ways to meet the requirements;” and
• Clarifying “the level of validation the assessor is expected to perform.”

Additionally, the DSS 3.0 changes seek to establish security as a “shared responsibility” between merchants and their service providers or business partners. During the weeks since DSS 3.0’s release, data security specialists and commentators have offered their views on the changes and whether they will help improve the security of payment card networks. Here, we take a look at what they have to say and how it will affect companies’ compliance efforts. Service Provider Changes—Shared Responsibility Two new DSS provisions will require additional compliance steps regarding service providers. Revised section 12.8.5 will require merchants and others who rely on third-party service providers to document which data security measures the merchant, processor, or other organization will perform itself and which security measures the service provider will perform. Although merchants and others were previously required to maintain lists of the vendors that connected to their cardholder data environment (CDE), another revised provision, section 12.9, requires each vendor to acknowledge in writing the DSS requirements for which the vendor is responsible. Revised DSS section 8.5.1 will also affect how merchants and others work with service providers. That section will require service providers that connect to CDEs to use a unique set of log-on credentials for each customer. This new requirement is designed stop criminals who learn of a vendor’s log-on credentials for one merchant’s network from using the same credentials to steal card data from other merchants that use the same service provider. Steven Weil, a PCI Qualified Security Auditor (QSA) at Coalfire, describes these changes as “excellent additions.” He predicts the changes will correct the problem of organizations not knowing which DSS requirements their service providers are responsible for, will promote “healthy discussions” between organizations and service providers about who is responsible for what, and will clarify for QSAs who is responsible for each DSS control. Ed Moyle, Director of emerging business and technology at ISACA, agrees that the changes are important but suggests negotiations with service providers over their responsibilities will be challenging: “negotiating these points (particularly after a contract with a service provider is in place) will be time-consuming and may be . . . contentious.” This may have been one of the reasons why the effective date of requirement 12.9 is delayed to July 1, 2015, when most of the other requirements become effective January 1, 2014. Requiring merchants, processors, and other organizations to document vendors’ DSS responsibilities should be particularly useful as more card data is processed using services of public cloud providers. The PCI DSS Cloud Computing Guidelines acknowledge merchants and processors, on one hand, and cloud providers, on the other, each have certain DSS responsibilities. Getting cloud providers to acknowledge their DSS responsibilities may prevent instances where a cloud service provider’s security staff thinks merchants and processors are performing specific security measures and the merchants’ and processors’ staff believes cloud providers are performing those tasks. Compliance is “Business as Usual” vs. “Annual Event” The Security Standards Counsel also stresses in the introductory DSS 3.0 guidance that compliance is a continuous and ongoing process for companies, versus an annual certification-driven event. The SSC points to existing requirements relating to the monitoring of security controls to ensure they are operating effectively and ensuring that all failures in security controls are detected and responded to in a timely manner, as well as continuous review of the impact to PCI DSS scope and requirements when there are changes to the CDE or organizational changes. For instance, while version 2.0 generally required merchants to conduct a risk assessment, Requirement 12.2 in DSS 3.0 clarifies that risk assessments “should be performed at least annually and after significant changes to the environment.” As Steve Weill points out, “there will likely be debates between organizations and QSAs about what constitutes a ‘significant change.’ This is a specific point that organizations should discuss with their QSAs prior to an on-site assessment.” New Controls to Protect Point of Sale Devices Revised DSS section 9.9 is designed to help prevent tampering with point of sale (PoS) devices, which the 2013 Verizon Data Breach Investigations Report identified as one of the leading methods criminals use to steal card data. Section 9.9 will require merchants to “[p]rotect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.” Sub-requirement 9.9.1 states that lists of such devices should be maintained that include the make, model, location, and serial numbers of PoS devices. The “Guidance” for this requirement states that automation may be used to comply with these requirements. This new requirement will force merchants and others who deploy PoS devices, from doctors’ offices to taxis, to undertake additional tasks. It may take significant training and management attention to make sure this chore is completed initially and that the lists are maintained. Industry Accepted Methodology for Penetration Testing DSS 3.0 makes another significant change by updating penetration testing requirements. Section 11.3 mandates that testers follow an “industry-accepted penetration testing methodology.” The section refers to NIST Special Publication 800-15 as one such accepted methodology. This new mandate does not take effect until July 1, 2015. As Ed Moyle notes, this change requires that merchants must be careful about which penetration testers they select and should motivate them to add language to pen-testing contracts that requires testers to utilize an industry-accepted methodology. A second change to penetration testing requirements takes effect on January 1, 2014 together with most other DSS 3.0 requirements: if a merchant or another affected organization uses network segregation to narrow the scope of the CDE, section 11.3.4 will require penetration tests to confirm the effectiveness of the segregation measures. CDE Inventory and Access DSS 3.0 section 2.4 mandates merchants and other affected organizations to “maintain an inventory of system components that are in scope for PCI DSS.” The “Testing Procedures” for this section require that a “list of software and hardware components is maintained and includes a description of function/use for each.” Merchants and assessors must not only document all CDE components but must also document what each component does. As Moyle observes, it is almost impossible for large organizations to meet even existing CDE inventory requirements without using automation and the new requirement to document the function of CDE components will add to this burden. Steve Weill has a slightly different perspective, stating “[c]areful and thorough CDE definition is critical for a QSA, making this a great mandate.” Summary The new requirements in DSS 3.0 “will mean an increase in time and costs for organizations to remain compliant,” according to Kurt Hageman, director of information security at FireHost. Some of the new requirements, including the mandates to maintain inventories of CDE components and their functions and to keep accurate lists of PoS devices, will require year-round monitoring rather than once-per-year assessments. To the extent these DSS 3.0 changes require security monitoring to become part of doing business rather than a periodic “check-the-box” compliance exercise, the new requirements should improve payment card data security. Most parts of the PCI DSS v3.0 will go into effect January 1, 2014, although merchants, processors, and others who must comply with the DSS have until December 31, 2014 to comply with the new version.