Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 2.0 October 2010 PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 2 Document Changes Date Version Description Pages October 2008 1.2 To introduce PCI DSS v1.2 as ―PCI DSS Requirements and Security Assessment Procedures,‖ eliminating redundancy between documents, and make both general and specific changes from PCI DSS Security Audit Procedures v1.1. For complete information, see PCI Data Security Standard Summary of Changes from PCI DSS Version 1.1 to 1.2. July 2009 1.2.1 Add sentence that was incorrectly deleted between PCI DSS v1.1 and v1.2. 5 Correct ―then‖ to ―than‖ in testing procedures 6.3.7.a and 6.3.7.b. 32 Remove grayed-out marking for ―in place‖ and ―not in place‖ columns in testing procedure 6.5.b. 33 For Compensating Controls Worksheet – Completed Example, correct wording at top of page to say ―Use this worksheet to define compensating controls for any requirement noted as ‗in place‘ via compensating controls.‖ 64 October 2010 2.0 Update and implement changes from v1.2.1. For details, please see ―PCI DSS - Summary of Changes from PCI DSS Version 1.2.1 to 2.0.‖ PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 3 Table of Contents Document Changes 2 Introduction and PCI Data Security Standard Overview 5 PCI DSS Applicability Information 7 Relationship between PCI DSS and PA-DSS 9 Scope of Assessment for Compliance with PCI DSS Requirements 10 Network Segmentation 10 Wireless 11 Third Parties/Outsourcing 11 Sampling of Business Facilities/System Components 12 Compensating Controls 13 Instructions and Content for Report on Compliance 14 Report Content and Format 14 Revalidation of Open Items 17 PCI DSS Compliance – Completion Steps 18 Detailed PCI DSS Requirements and Security Assessment Procedures 19 Build and Maintain a Secure Network 20 Requirement 1: Install and maintain a firewall configuration to protect cardholder data 20 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters 24 Protect Cardholder Data 28 Requirement 3: Protect stored cardholder data 28 Requirement 4: Encrypt transmission of cardholder data across open, public networks 35 Maintain a Vulnerability Management Program 37 Requirement 5: Use and regularly update anti-virus software or programs 37 Requirement 6: Develop and maintain secure systems and applications 38 Implement Strong Access Control Measures 44 Requirement 7: Restrict access to cardholder data by business need to know 44 Requirement 8: Assign a unique ID to each person with computer access 46 Requirement 9: Restrict physical access to cardholder data 51 Regularly Monitor and Test Networks 55 Requirement 10: Track and monitor all access to network resources and cardholder data 55 PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 4 Requirement 11: Regularly test security systems and processes. 59 Maintain an Information Security Policy 64 Requirement 12: Maintain a policy that addresses information security for all personnel. 64 Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers 70 Appendix B: Compensating Controls 72 Appendix C: Compensating Controls Worksheet 73 Compensating Controls Worksheet – Completed Example 74 Appendix D: Segmentation and Sampling of Business Facilities/System Components 75 PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 5 Introduction and PCI Data Security Standard Overview The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data. PCI DSS applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data. PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks. Below is a high-level overview of the 12 PCI DSS requirements. This document, PCI Data Security Standard Requirements and Security Assessment Procedures, combines the 12 PCI DSS requirements and corresponding testing procedures into a security assessment tool. It is designed for use during PCI DSS compliance assessments as part of an entity’s validation process. The following sections provide detailed guidelines and best practices to assist entities prepare for, conduct, and report the results of a PCI DSS assessment. The PCI DSS Requirements and Testing Procedures begin on page 19. PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 6 The PCI Security Standards Council (PCI SSC) website (www.pcisecuritystandards.org) contains a number of additional resources, including:  Attestations of Compliance  Navigating PCI DSS: Understanding the Intent of the Requirements  The PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms  Frequently Asked Questions (FAQs)  Information Supplements and Guidelines Please refer to www.pcisecuritystandards.org for more information. Note: Information Supplements complement the PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements – they do not change, eliminate or supersede the PCI DSS or any of its requirements. PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 7 PCI DSS Applicability Information PCI DSS applies wherever account data is stored, processed or transmitted. Account Data consists of Cardholder Data plus Sensitive Authentication Data, as follows: Cardholder Data includes: Sensitive Authentication Data includes:  Primary Account Number (PAN)  Cardholder Name  Expiration Date  Service Code  Full magnetic stripe data or equivalent on a chip  CAV2/CVC2/CVV2/CID  PINs/PIN blocks The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed or transmitted, PCI DSS requirements do not apply. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with all PCI DSS requirements except Requirements 3.3 and 3.4, which apply only to PAN. PCI DSS represents a minimum set of control objectives which may be enhanced by local, regional and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personally identifiable information or other data elements (for example, cardholder name), or define an entity’s disclosure practices related to consumer information. Examples include legislation related to consumer data protection, privacy, identity theft, or data security. PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements. The following table illustrates commonly used elements of cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element. PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 8 Data Element Storage Permitted Render Stored Account Data Unreadable per Requirement 3.4 Account Data Cardholder Data Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Data 1 Full Magnetic Stripe Data 2 No Cannot store per Requirement 3.2 CAV2/CVC2/CVV2/CID No Cannot store per Requirement 3.2 PIN/PIN Block No Cannot store per Requirement 3.2 PCI DSS requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4. PCI DSS only applies if PANs are stored, processed and/or transmitted. 1 Sensitive authentication data must not be stored after authorization (even if encrypted). 2 Full track data from the magnetic stripe, equivalent data on the chip, or elsewhere. PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 9 Relationship between PCI DSS and PA-DSS Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor (per PA-DSS Requirement 13.1). The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the PCI DSS Requirements and Security Assessment Procedures (this document). The PA-DSS details what a payment application must support to facilitate a customer’s PCI DSS compliance. Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), and PINs and PIN blocks, along with the damaging fraud resulting from these breaches. Just a few of the ways payment applications can prevent compliance include:  Storage of magnetic stripe data and/or equivalent data from the chip in the customer's network after authorization;  Applications that require customers to disable other features required by the PCI DSS, like anti-virus software or firewalls, in order to get the payment application to work properly; and  Vendors’ use of unsecured methods to connect to the application to provide support to the customer. The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties. Please note the following regarding PA-DSS applicability:  PA-DSS does apply to payment applications that are typically sold and installed ―off the shelf‖ without much customization by software vendors.  PA-DSS does not apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance. For detailed guidance on determining whether PA-DSS applies to a given payment application, please refer to the PA-DSS Requirements and Security Assessment Procedures, which can be found at www.pcisecuritystandards.org. PCI DSS Requirements and Security Assessment Procedures, Version 2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 10 Scope of Assessment for Compliance with PCI DSS Requirements The PCI DSS security requirements apply to all system components. In the context of PCI DSS, ―system components‖ are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―System components‖ also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications. The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, perform the following:  The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined cardholder data environment (CDE).  Once all locations of cardholder data are identified and documented, the entity uses the results to verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).  The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE unless such data is deleted or migrated/consolidated into the currently defined CDE.  The entity retains documentation that shows how PCI DSS scope was confirmed and the results, for assessor review and/or for reference during the next annual PCI SCC scope confirmation activity. Network Segmentation Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce:  The scope of the PCI DSS assessment  The cost of the PCI DSS assessment  The cost and difficulty of implementing and maintaining PCI DSS controls  The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations) [...]... security vulnerabilities and are consistent with industry- accepted system hardening standards Sources of industry- accepted system hardening standards may include, but are not limited to:  Center for Internet Security (CIS)  International Organization for Standardization (ISO)  SysAdmin Audit Network Security (SANS) Institute  National Institute of Standards Technology (NIST) Not in Place Target... 2.1.1.e Verify other security- related wireless vendor defaults were changed, if applicable PCI DSS Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards Council LLC October 2010 Page 24 PCI DSS Requirements Testing Procedures 2.2 Develop configuration standards for all system components Assure that these standards address all known security vulnerabilities... data PCI DSS Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards Council LLC October 2010 Page 27 Protect Cardholder Data Requirement 3: Protect stored cardholder data Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection If an intruder circumvents other security controls and gains access... (URL)  Verify that no cardholder data is required when HTTPS does not appear in the URL PCI DSS Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards Council LLC October 2010 Page 35 PCI DSS Requirements Testing Procedures 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices... the standard processes  If there is more than one type of standard security and/or operational process in place (for example, for different types of business facilities/system components), the sample must be large enough to include business facilities/system components secured with each type of process PCI DSS Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards... they serve, such as card- not-present (for example, mail-order-telephone-order (MOTO), eCommerce), or card- present  Their business role with payment cards, which is how and why they store, process, and/or transmit cardholder data Note: This is not intended to be a cut-and-paste from the entity‘s web site, but should be a tailored description that shows the assessor understands payment and the entity‘s... wireless LANs and/or wireless payment applications (for example, POS terminals) that are connected to, or could impact the security of the cardholder data environment, and describe security in place for these wireless environments  The version of the PCI DSS Requirements and Security Assessment Procedures document used to conduct the assessment PCI DSS Requirements and Security Assessment Procedures,... Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards Council LLC October 2010 Page 29 PCI DSS Requirements Testing Procedures 3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card- notpresent transactions Not in Place Target Date/ Comments 3.2.2 For a sample... the PCI SSC website (www.pcisecuritystandards.org) 4 Submit the ROC, evidence of a passing scan, and the Attestation of Compliance, along with any other requested documentation, to the acquirer (for merchants) or to the payment brand or other requester (for service providers) PCI DSS Requirements and Security Assessment Procedures, Version 2.0 Copyright 2010 PCI Security Standards Council LLC October... be performed on all system components in the cardholder data environment A service provider or merchant may use a third-party service provider to store, process, or transmit cardholder data on their behalf, or to manage components such as routers, firewalls, databases, physical security, and/or servers If so, there may be an impact on the security of the cardholder data environment For those entities . Security Standard Overview The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security. Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version