1 A QUICK PRIMER ON PCI DSS VERSION 3.0 This white paper shows you how to use the PCI 3 compliance process to help avoid costly data security breaches, using various service provider tools or on your own.
2 Security breaches relating to credit and debit cards are making news and causing big problems for credit card providers, merchants, and customers. Breaches damage the trust that consumers have placed in the merchants that get hacked, and in credit cards in general. To reduce data breaches, five major credit card providers Visa, MasterCard, American Express, Discover, and the Japan Credit Bureau created the Payment Card Industry Data Security Standard (PCI DSS). The standard gives merchants a uniform target for their data security efforts, backed by a certification process. Penalties for PCI non-compliance (include) fines of up to $500,000 per incident... (and) potential for campus wide shut down of credit card activity by our merchant bank. PCI DSS Security Penalties, University of California, Santa Cruz If a merchant suffers a breach, and is not in compliance with PCI DSS, the merchant will be fined up to $500,000 per incident by their bank. In addition, the merchant will suffer a suspension in credit card processing services until the breach is repaired, and must alert affected customers in writing that a breach has happened. All this causes serious reputational damage, in addition to the direct financial loss.
3 Focusing on losses and penalties after a breach, however, is not the most useful way for merchants to look at PCI. Instead, merchants can use the PCI standard and the certification process to help them plan and implement strong data security efforts which greatly reduce the odds of suffering a breach. A new version of PCI DSS, Version 3.0, is already a requirement for some industry participants; most merchants, however, have to comply by June 30th, 2015. This new version of the standard increases the responsibility of merchants for everything that happens to credit card data that they touch. And it has specific implications for merchants who accept credit cards online. Payment Card Industry Data Security Standard This white paper describes the major requirements of the PCI standard; the changes found in Version 3.0; how Version 3.0 affects merchants who take credit cards online; and how merchants can use PCI compliance to help avoid data breaches and the direct financial losses, suspension of credit card processing services, fines, and loss of customers that result.
4 How Are Merchants Affected by PCI? Version 1 of the PCI DSS standard, introduced in 2004, established a framework of validation levels, objectives, and requirements that continues to be used today. The interpretation and enforcement of the requirements, however, has tightened with each new version of the standard.
5 The PCI standard uses four levels of transaction volume for PCI enforcement. Visa and MasterCard use the same transaction volumes to define each validation level; other providers may vary. Merchants who process more than 6 million transactions a year are covered by PCI DSS Level 1 and must employ outside auditors to verify that they meet the standard. Merchants covered by PCI DSS Level 2 and 3 with 1 million total transactions a year or more, or more than 20,000 e-commerce transactions are required to complete and send in a self-certification form, which can be more or less extensive depending on how they handle credit card data. Merchants that fall into Level 4 below these transaction volumes are only recommended, rather than required, to complete the self-certification form. At all levels, merchants must have their network scanned quarterly by a Payment Card Industry Security Standards Council (PCI SSC)-approved scanning vendor. A merchant at Validation Level 2, 3, or 4 who suffers a breach will likely be moved up to a higher validation level, frequently Level 1, for an extended period of time. In general, all merchants who accept credit cards are subject to the PCI DSS standard. However, the extent of an audit (for Level 1 merchants) or of the self-certification process (for Level 2, 3, and 4 merchants) depends on which responsibilities the merchant chooses to take on and which they outsource. KEYS TO COMPLIANCE Know Your Volumes If your transaction volumes are moving toward a higher PCI DSS validation level, work with your bank to certify at that level well before you get there. Avoid Storage PCI DSS Version 3.0 ramps up factfinding, documentation, and compliance requirements. Don t store cardholder data (CHD) or sensitive authorization data (SAD). Lock Down Transmission Fully secure pages that accept sensitive data from customers, as described on page 12.
6 Validation Level Merchants Affected Certification Level 1 More than 6M transactions per year, or if required by the merchant s bank Outside audit Scan Level 2 1M to 6M transactions per year, or if required by the merchant s bank Self-certification form required Scan Level 3 Fewer than 1M transactions per year, but more than 20,000 e-commerce transactions Self-certification form required Scan Level 4 Fewer than 1M transactions per year, and less than 20,000 e-commerce transactions Self-certification form recommended Scan Source: Visa USA Note: Working with a service provider like Recurly reduces merchants exposure to data breaches and to PCI DSS Version 3.0 compliance requirements. However, even if their system never sees, transmits, nor stores cardholder data, the merchant still needs to certify that pages that call outside JavaScript code or link to secure external web pages are fully secured against intrusion.
7 The extent of an audit (for Level 1 merchants) or self-certification process (for others) depends on how the merchant handles credit card data: Transmitting Credit Card Data A merchant can receive cardholder data (CHD) from a customer, hold it in their server s memory briefly, transmit it to a service provider, and expunge it. PCI requires that you fully secure your server, to prevent hackers from inserting new code onto your system that transmits your customer s data to the hackers. Storing Credit Card Data A merchant can receive CHD and store it on a disk drive or similar non-transient storage. To comply with PCI, the server, the storage device, and all transmission paths for data between them must be secured. Mapping the potential paths of data transmission, as required by PCI, is complicated, and fully securing all paths is likely to be difficult. Many merchants have traditionally stored credit card data. Many more haven t stored it, but have received and transmitted it. Others leave it to service providers to receive, transmit, and store the data. Note: The final step in credit card use is processing, which is nearly always done by specialist processing companies. These companies have additional responsibilities for PCI DSS compliance which aren t covered in this white paper.
8 In response to the difficulty of securing against data breaches, the burden of meeting PCI requirements, and the penalties and loss of customer confidence that follow a breach, merchants have undertaken two main strategies: Don t Store CHD Merchants should use third-party, PCI-compliant providers to store CHD. The merchant receives the CHD and immediately transmits it to the service provider. The service provider stores CHD and interacts with the merchant s merchant bank to handle processing as well. Don t Receive CHD Many merchants use third-party providers to accept CHD directly from customers. One approach is to link to a separate payments page, hosted on the outside provider s website and showing their URL. Alternatively, the merchant can call in JavaScript code from the third-party provider, running on the merchant s page. The provider s code accepts, transmits, and stores CHD. This approach does not excuse the merchant from complying with PCI, but it greatly reduces the footprint that must be secured and simplifies the certification process. These strategies help merchants avoid attacks and reduce their exposure to documentation and certification requirements under PCI. With PCI DSS Version 3.0, however, there are stricter requirements even for companies that follow these strategies.
9 The PCI Standard The PCI standard has control objectives and requirements. The control objectives set out what the standard is trying to achieve, such as protecting cardholder data; the requirements outline what merchants have to do to support each objective. The control objectives and the requirements have been the same since Version 1 of the standard. Each new version, however, introduces a tightening of the interpretation of the requirements around the transmission, storage, and processing of credit card data.
10 Control Objectives PCI DSS Requirements Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use merchant-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software on all systems commonly affected by malware 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures 7. Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security
11 What s Different with PCI DSS Version 3.0? PCI DSS Version 3.0 has strong implications for online commerce. It addresses security breaches which have been suffered by merchants who use outside service providers to handle receiving, transmitting, and/or storing credit card data. To prevent breaches, all parts of the merchant s system which interact with outside providers need to be fully secure.
12 Here are some of the key changes in PCI DSS Version 3.0 that affect online commerce: Protect SAD, Not Just CHD Security efforts around past versions of the PCI standard focused on protecting cardholder data (CHD). Now merchants must also protect sensitive authorization data (SAD). This includes information that is part of the credit card acceptance process, such as authentication codes, magnetic stripe data, and PINs. Protect Pages that Call Outside Provider Code Some websites shell out to a separate site that handles credit card data. Pages that link to such a provider page must be fully secured, or information could be intercepted. Other pages use a JavaScript stub to call a provider s JavaScript to accept CHD. The page on which the JavaScript stub runs must be fully secured, or the JavaScript stub could be substituted, sending CHD and/or SAD where a hacker wants to send them. Be Ready for Tougher Penetration Testing All merchants must run quarterly remote penetration tests to be PCI-compliant. These tests must now follow an industry-accepted methodology such as NIST SP 800-115. Systems that passed penetration testing in the past may fail under the new approach.
13 Trace All Paths of CHD and SAD Merchants which store CHD or SAD, or transmit data within their own domain, must identify all components in the system and secure all paths that data can travel down. The Internet and server farms are designed for flexibility and substitutability, so this can be very complicated. The overhead involved in storing CHD and/or SAD on a merchant s servers is much higher under PCI DSS Version 3.0, largely because of this requirement. Document Vendor Relationships It is no longer enough to identify some areas of your website operation as being under the control of vendors. You must describe these relationships in detail. Your vendors should be prepared to provide information you can use to meet this requirement, or be ready to be booted off the sensitive parts of your network. The table on the next page summarizes these changes and how they impact different kinds of card acceptance implementations. The first three approaches correspond to using Recurly-hosted payment pages, using Recurly.js, or using the Recurly API, respectively. The final approach reflects standalone data-handling by the merchant.
14 Increased Merchant Responsibilities Under PCI DSS Version 3.0 Service Provider (SP) Involvement Merchant Responsibility Store Hold in RAM Transmit PCI DSS Version 3.0 Merchant Duties Shell out to SP page with different URL N N N Secure merchant pages linking to SP page Shell out to SP JavaScript within merchant page N N N Secure merchant page that calls SP JavaScript Use API to call SP functions N Y Y Secure merchant pages with CHD and SAD and pages linking to SP Merchant handles CHD Secure merchant pages with CHD/SAD, Y Y Y storage devices, and all possible data transmission paths
15 How You Can Help Your Site Merchants have two key challenges with regard to credit card handling: don t get your credit card processing services suspended, and don t get hacked.
16 With the tighter enforcement coming into play with PCI DSS Version 3.0, there s a three-step process you can use to avoid problems: Know Your Volumes If your volume of transactions suddenly puts you in Level 1 territory (a rate adding up to 6M transactions a year, for Visa and MasterCard), and you aren t already a certified Level 1 merchant, your bank may shut down your credit card processing. Carefully monitor transaction volumes and be proactive about speaking with your bank. If you re heading toward a higher transaction level, get certified at the higher level before you reach it. Avoid Storage Under the stricter requirements of PCI DSS Version 3.0, you need to get out of the storage business if at all possible. Don t write CHD or SAD to storage, and try to avoid having it on your servers, even in memory. NEXT STEPS If you re ready to get technical, the Open Web Application Security Project site at www.owasp.org is a great resource. See their Top 10 List for ten of the most important changes you need to make to help secure your site. Lock Down Transmission You may shell out to an external page or external JavaScript library to accept credit card information, but you must secure the parts of your site that link to the service provider. Use HTTPS for pages that accept payment data. Separate the writing of code from its deployment, or have compensating controls, and more.
17 Recurly provides enterprise-class recurring billing management for thousands of subscription-based businesses worldwide. Contact our team today to see if Recurly is the right fit for your business. +1.844.732.8759 sales@recurly.com 2015 Recurly, Inc. All rights reserved.