PCI DSS 3.0: Business as Usual?

by Davis Wright Tremaine LLP
Contact

In the past, critics of the Payment Card Industry (PCI) Data Security Standard (DSS) have alleged that the DSS requirements either (1) provide little more than a minimal baseline for security with a “check-the-box” compliance approach; or (2) are written vaguely so that the Council can retroactively allege non-compliance and impose fees on merchants who claim to have been PCI DSS “compliant” at the time of the breach (see our recent Genesco post). On November 7, 2013, the PCI Security Standards Council (SSC) released version 3.0, which may address these criticisms by:
  • 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.

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Davis Wright Tremaine LLP | Attorney Advertising

Written by:

Davis Wright Tremaine LLP
Contact
more
less

Davis Wright Tremaine LLP on:

Readers' Choice 2017
Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
Sign up using*

Already signed up? Log in here

*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Privacy Policy (Updated: October 8, 2015):
hide

JD Supra provides users with access to its legal industry publishing services (the "Service") through its website (the "Website") as well as through other sources. Our policies with regard to data collection and use of personal information of users of the Service, regardless of the manner in which users access the Service, and visitors to the Website are set forth in this statement ("Policy"). By using the Service, you signify your acceptance of this Policy.

Information Collection and Use by JD Supra

JD Supra collects users' names, companies, titles, e-mail address and industry. JD Supra also tracks the pages that users visit, logs IP addresses and aggregates non-personally identifiable user data and browser type. This data is gathered using cookies and other technologies.

The information and data collected is used to authenticate users and to send notifications relating to the Service, including email alerts to which users have subscribed; to manage the Service and Website, to improve the Service and to customize the user's experience. This information is also provided to the authors of the content to give them insight into their readership and help them to improve their content, so that it is most useful for our users.

JD Supra does not sell, rent or otherwise provide your details to third parties, other than to the authors of the content on JD Supra.

If you prefer not to enable cookies, you may change your browser settings to disable cookies; however, please note that rejecting cookies while visiting the Website may result in certain parts of the Website not operating correctly or as efficiently as if cookies were allowed.

Email Choice/Opt-out

Users who opt in to receive emails may choose to no longer receive e-mail updates and newsletters by selecting the "opt-out of future email" option in the email they receive from JD Supra or in their JD Supra account management screen.

Security

JD Supra takes reasonable precautions to insure that user information is kept private. We restrict access to user information to those individuals who reasonably need access to perform their job functions, such as our third party email service, customer service personnel and technical staff. However, please note that no method of transmitting or storing data is completely secure and we cannot guarantee the security of user information. Unauthorized entry or use, hardware or software failure, and other factors may compromise the security of user information at any time.

If you have reason to believe that your interaction with us is no longer secure, you must immediately notify us of the problem by contacting us at info@jdsupra.com. In the unlikely event that we believe that the security of your user information in our possession or control may have been compromised, we may seek to notify you of that development and, if so, will endeavor to do so as promptly as practicable under the circumstances.

Sharing and Disclosure of Information JD Supra Collects

Except as otherwise described in this privacy statement, JD Supra will not disclose personal information to any third party unless we believe that disclosure is necessary to: (1) comply with applicable laws; (2) respond to governmental inquiries or requests; (3) comply with valid legal process; (4) protect the rights, privacy, safety or property of JD Supra, users of the Service, Website visitors or the public; (5) permit us to pursue available remedies or limit the damages that we may sustain; and (6) enforce our Terms & Conditions of Use.

In the event there is a change in the corporate structure of JD Supra such as, but not limited to, merger, consolidation, sale, liquidation or transfer of substantial assets, JD Supra may, in its sole discretion, transfer, sell or assign information collected on and through the Service to one or more affiliated or unaffiliated third parties.

Links to Other Websites

This Website and the Service may contain links to other websites. The operator of such other websites may collect information about you, including through cookies or other technologies. If you are using the Service through the Website and link to another site, you will leave the Website and this Policy will not apply to your use of and activity on those other sites. We encourage you to read the legal notices posted on those sites, including their privacy policies. We shall have no responsibility or liability for your visitation to, and the data collection and use practices of, such other sites. This Policy applies solely to the information collected in connection with your use of this Website and does not apply to any practices conducted offline or in connection with any other websites.

Changes in Our Privacy Policy

We reserve the right to change this Policy at any time. Please refer to the date at the top of this page to determine when this Policy was last revised. Any changes to our privacy policy will become effective upon posting of the revised policy on the Website. By continuing to use the Service or Website following such changes, you will be deemed to have agreed to such changes. If you do not agree with the terms of this Policy, as it may be amended from time to time, in whole or part, please do not continue using the Service or the Website.

Contacting JD Supra

If you have any questions about this privacy statement, the practices of this site, your dealings with this Web site, or if you would like to change any of the information you have provided to us, please contact us at: info@jdsupra.com.

- hide
*With LinkedIn, you don't need to create a separate login to manage your free JD Supra account, and we can make suggestions based on your needs and interests. We will not post anything on LinkedIn in your name. Or, sign up using your email address.
Feedback? Tell us what you think of the new jdsupra.com!