Payment Card Industry Payment Application Data Security Standard PCI PA-DSS v3.2 Before and After Redline View Change Analysis Between PCI PA-DSS v3.1 and v3.2 Assessor Company: Control Gap Inc. Contact Email: info@controlgap.com Contact Phone: 1.866.644.8808 Report Status: Final This document has been made publicly available at controlgap.com without warranty. Feel free to copy or distribute unmodified without restriction. Template Version: CG Report Layout Gap Analysis v.160531
Change Analysis Overview This document outlines each identified change (i.e. moves, additions, or deletions) that has occurred between PCI PA-DSS v3.1 and PCI PA-DSS v3.2. The PCI SSC Summary of Changes document provides a high-level summary, however in order to understand and assess potential impacts to merchant and service provider PCI programs it is critical to understand the language, wording nuances, and the context this document helps identify these details. This is a detailed companion document to a separate presentation where we summarize our findings and provide high-level commentary. See also companion document Control Gap Commentary on the Changes to the PCI Data Security Standard v3.2 How to Read this Document: Column Description # Row content represents a localized group/cluster of identified changes. PA-DSS 3.1 PA-DSS 3.2 Identified Wording Changes Redline PCI SSC Commentary Impact References: References to PCI PA-DSS v3.1 either page # or section numbers. References to PCI PA-DSS v3.2 either page # or section numbers. The original PA-DSS v3.1 text snippets compared with the changed text in PA-DSS v3.2 outlining identified changes (moves, additions, or deletions) Unchanged text: Unchanged text looks like this (with long stretches of unchanged text is represented by ellipses ). Supplemental Headings: Supplemental Headings Look Like this. New text added by PCI SSC: Added text looks like this. Deleted text removed by PCI SSC: Removed text looks like this. Our mapping of PCI SSC comments sourced from the PCI PA-DSS v3.2 Summary of Changes document. Our estimated impact of applicable change based on our existing compliance validation process, our understanding and opinion of the original intent (of PA-DSS v3.1) and the possible impact of the changes (of PA-DSS v3.2). Not all changes will be applicable to all applications each vendor must separately judge their actual severity impacts. We scored the potential impact each item as follows: - = Negligible impact to compliance - general improvements in clarity and understanding of intent - = impact/effort to compliance a new incremental change potentially causing added or altered compliance efforts - High = High impact/effort to compliance a new requirement and/or potentially significant effort to achieve or sustain compliance PCI PA-DSS v3.1 - https://www.pcisecuritystandards.org/documents/pa-dss_v3-1.pdf PCI PA-DSS v3.2 - https://www.pcisecuritystandards.org/documents/pa-dss_v3-2.pdf PCI PA-DSS v3.2 Summary of Changes - https://www.pcisecuritystandards.org/documents/pa-dss_v3-2_summary_of_changes.pdf Page 2 of 18
PCI PA-DSS v3.2 Before and After Redline View 1 - Pg.6 The primary account number (PAN) is the defining factor for cardholder data. 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, (CDE), they must be protected in accordance with all applicable PCI DSS requirements. Addressed minor typographical errors (grammar, punctuation, formatting, etc.) and incorporated minor updates for readability throughout the document. 2 - Pg.13 Please refer to the PA-DSS Program Guide for information about PA-DSS program management, including the following topics: Details of different PA-DSS versions and their effective dates Addressed minor typographical errors (grammar, punctuation, formatting, etc.) and incorporated minor updates for readability throughout the document. Page 3 of 18
3 2.2 2.2 PCI PA-DSS Requirements PCI SSC Evolving Requirement: Updated requirement to clarify that 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number any displays of PAN greater than the of digits to be displayed), such that only personnel with a legitimate business need can first six/last four digits of the PAN see more than the fullfirst six/last four digits of the PAN. require a legitimate business need. Added guidance on common masking Testing Procedures scenarios 2.2.a Review the PA-DSS Implementation Guide prepared by the vendor to verify the documentation includes Instructions for how to configure the payment application such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN (includes displays of the full PAN.). 2.2.c Configure the payment application according to the PA-DSS Implementation Guide to allow only personnel with a legitimate business need to see more than the fullfirst six/last four digits of the PAN,. For each instance where PAN is displayed, examine application configurations and displays of PAN to verify that instructions for masking PAN are accurate, and that only personnel with a legitimate business need can see more than the fullfirst six/last four digits of the PAN. Guidance The masking approach should always ensure that only the minimum number of digits are displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. As another example, if a function needs access to the bank identification number (BIN) for routing purposes, unmask only the BIN digits (traditionally the first six digits) during that function. Page 4 of 18
4 2.3.a 2.3.a Testing Procedures PCI SSC Evolving Requirement: Updated testing procedure for the PA- 2.3.a Review the PA-DSS Implementation Guide prepared by the vendor to verify the DSS Implementation Guide to include documentation includes the following guidance for customers and integrators/resellers: instruction that if debugging logs are Instruction that if debugging logs are ever enabled (for example, for ever enabled (for example, for troubleshooting purposes), and include troubleshooting purposes), and the logs include PAN, they must be protected in PAN, the logs must be protected in accordance with PCI DSS, disabled as accordance with PCI DSS, disabled as soon as troubleshooting is complete and soon as troubleshooting is complete, securely deleted when no longer needed. and securely deleted when no longer needed. 5 3.1.a 3.1.a Testing Procedures 6 3.1.6/7 3.1.6/7 Testing Procedures 3.1.a Examine the PA-DSS Implementation Guide created by the vendor to verify that customers and integrators/resellers are: Identification of all roles and default accounts within the application with administrative access. Alternatively, the passwords/phrasepassphrase must have complexity and strength at least equivalent to the parameters specified above Guidance Passwords/phrasespassphrases that are valid for a long time without being changed provide malicious individuals with more time to work on breaking the password/phrasepassphrase. (PCI SSC Classification Omitted,) Evolving Requirement: Updated testing procedure for the PA- DSS Implementation Guide to include identification of all roles and default accounts within the application with administrative access. Addressed minor typographical errors (grammar, punctuation, formatting, etc.) and incorporated minor updates for readability throughout the document. Page 5 of 18
7 4.1 4.1 Guidance Addressed minor typographical errors It is critical that the payment application has a process or mechanism that links users to (grammar, punctuation, formatting, the application resources accessed, generates audit logs, and provides the ability to trace etc.) and incorporated minor updates back suspicious activity to a specific user. PostincidentPost-incident forensic teams heavily for readability throughout the depend on these logs to initiate the investigation. document. 8 5.1.7 5.1.7 PCI PA-DSS Requirements 5.1.7 Provide up-to-date training in secure development practices for application developers at least annually, as applicable for the developer s job function and technology used, for example: Testing Procedures 5.1.7a Verify documented software-development processes require up-to-date training in secure development practices for application developers at least annually, as applicable for the developer s job function and technology used. 5.1.7.c Examine records of training to verify that all application developers receive training at least annually, as applicable for their job function and technology used. PCI SSC Clarification Clarified that training for developers must be up to date and occur at least annually. Page 6 of 18
9-7.2.3 PCI PA-DSS Requirements 7.2.3 Provide instructions for customers about secure installation of patches and updates. Testing Procedures 7.2.3 Examine the PA-DSS Implementation Guide prepared by the vendor to verify it PCI SSC Evolving Requirement: Added requirement for the PA-DSS Implementation Guide to include instructions about secure installation of patches and updates. includes the following information for customers and integrators/resellers: How the vendor will communicate notifications of new patches and updates. How patches and updates will be delivered in a secure manner with a known chain of trust. How to access and install patches and updates in a manner that maintains the integrity of the patch and update code. Guidance 10 8.2 8.2 PCI PA-DSS Requirements Advising customers and integrators/resellers of the process for receiving and installing patches securely helps protect the integrity of the update process and the application. 8.2 The payment application must only use or require use of necessary and secure services, For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, TLS, IPSec, or other technology. Removed examples of strong or secure protocols from a number of requirements, as these may change at any time. Page 7 of 18
11 8.3 8.3 PCI PA-DSS Requirements Clarified correct term is multi-factor 8.3 The payment application must not require use of services or protocols that preclude authentication rather than two-factor the use of or interfere with normal operation of twomulti-factor authentication authentication, as two or more factors technologies for securing remote access to the payment application that originates from may be used. outside the customer environment.. Note: TwoMulti-factor authentication requires that at least two of the three authentication methods (see below) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered twomulti-factor authentication. The authentication methods, also known as a factors, are: Examples of two-factor technologies include RADIUS with tokens, TACACS with tokens, or other technologies that facilitate two-factor authentication. Moved examples from a number of requirements and/or testing procedures to the Guidance column, and added guidance where appropriate. Testing Procedures 8.3.a Examine payment application functionality to verify it does not require use of any services or protocols that preclude the use of or interfere with the normal operation of twomulti-factor authentication technologies for remote access 8.3.b Identify remote-access mechanisms supported by the application and verify that the mechanisms do not prevent twofactormulti-factor authentication Guidance operating twomulti-factor authentication solutions for secure remote access. Examples of multi-factor technologies include but are not limited to RADIUS with tokens, TACACS with tokens, or other technologies that facilitate multi-factor authentication. Page 8 of 18
12 10.1 10.1 PCI PA-DSS Requirements PCI SSC Clarification Clarified correct term is multi-factor 10.1 TwoMulti-factor authentication must be used for all remote access to the payment authentication rather than two-factor application that originates from outside the customer environment. authentication, as two or more factors Note: TwoMulti-factor authentication requires thatat least two of the three authentication may be used. methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods). Aligns with PCI DSS Requirement 8.3 Testing Procedures 10.1.a Examine the PA-DSS Implementation Guide prepared by the vendor to verify it contains the following for customers and integrators/resellers: Instructions that all remote access originating from outside the customer s network to the payment application must use twomulti-factor authentication in order to meet PCI DSS requirements. A description of twomulti-factor authentication mechanisms supported by the application. Instructions for configuring the application to support twofactormulti-factor authentication (at least two of the three authentication methods described in PA DSS Requirement 3.1.4). 10.1.b If the application vendor has remote access to a customer s payment application that originates from outside the customer environment, examine vendor policies to verify that the vendor supports customer requirements for two-factormulti-factor authentication for all such access. Guidance TwoMulti-factor authentication requires at least two methods of authentication for access originating from outside the network. Payment application vendors will need to provide instructions to customers for configuring the application to support the specified twomulti-factor authentication Page 9 of 18
# PA-DSS 3.1 PA-DSS 3.2 Identified Wording Changes Redline PCI SSC Commentary Impact mechanisms in order to ensure those mechanisms can be implemented properly and meet applicable PCI DSS requirements. The requirement for twomulti-factor authentication applies only where theto all personnel with remote access that originates from outside the customer environment. 13 10.2.2 10.2.2 PCI PA-DSS Requirements 10.2.2 If vendors or integrators/resellers can access customers payment applications remotely, a unique authentication credential (such as a password/phrasepassphrase) must be used for each customer. Testing Procedures 10.2.2 If vendors or integrators/resellers can access customers payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a password/phrasepassphrase) is used for each customer they have access to. Addressed minor typographical errors (grammar, punctuation, formatting, etc.) and incorporated minor updates for readability throughout the document. 14 11.1 11.1 PCI PA-DSS Requirements 11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following: Removed examples of strong or secure protocols from a number of requirements, as these may change at any time. 15 12 12 Requirement 12: EncryptSecure all non-console administrative access PCI SSC Clarification Changed requirement title to Secure all non-console administrative access to better reflect content of this requirement. Page 10 of 18
16 12.1 12.1 PCI PA-DSS Requirements Removed examples of strong or 12.1 If the payment application facilitates non-console administrative access, encrypt all secure protocols from a number of such access with strong cryptography using technologies such as SSH, VPN, or TLS, for requirements, as these may change at webbased management and other non-console administrative access.. any time. Testing Procedures 12.1.c Examine the PA-DSS Implementation Guide prepared by the vendor, and verify it includes instructions for customers and integrators/resellers how to configure the application to use strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of non-console administrative access. 17 12.2 12.1.1 PCI PA-DSS Requirements 12.21.1 Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access. Testing Procedures 12.21.1 Examine the PA-DSS Implementation Guide prepared by the vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all nonconsole administrative access. PCI SSC Clarification Renumbered as sub-requirement of 12.1. Removed examples of strong or secure protocols from a number of requirements, as these may change at any time. Page 11 of 18
18-12.2 PCI PA-DSS Requirements PCI SSC Evolving Requirement: High 12.2 Use multi-factor authentication for all personnel with non-console administrative access. New Requirement addresses multifactor authentication for all personnel Note: Multi-factor authentication requires at least two of the three authentication methods be with non-console administrative access used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication to the application. methods). Aligns with PCI DSS Requirement 8.3.1. Aligns with PCI DSS Requirement 8.3 Testing Procedures 12.2.a Verify that multi-factor authentication is provided with the application, or that use thereof is specified. 12.2.b Examine PA-DSS Implementation Guide prepared by the vendor, and verify it includes directions for customers and integrators/resellers to use multi-factor authentication, including: Instruction that multi-factor authentication must be used for all personnel with non-console administrative access to the CDE. Procedures for using the multi-factor authentication provided with the application (if provided). 12.2.c If multi-factor authentication is provided with the payment application, install and test the application to verify that the multi-factor authentication is applied before access is granted. Guidance Administrative access requires a higher level of assurance that the individual attempting to gain access is who they claim to be. As multi-factor authentication may be implemented at the application, system, or network level, it is not required that all applications include a multi-factor authentication solution. Application vendors can either provide multi-factor authentication with their application, or include instructions for users and integrators/resellers to install multi-factor authentication for administrative access to the application. Page 12 of 18
# PA-DSS 3.1 19 Appendix A PA-DSS 3.2 Appendix A 20 A.2.2 A.2.2 PA-DSS Topic Identified Wording Changes Redline PCI SSC Commentary Impact Changes within Appendix A: Summary of Contents for the PA-DSS Implementation Guide are organized under the supplemental headings shown below. Requirements in the Appendix are referenced with a leading A (e.g. A.2.2 for Appendix A, requirement 2.2). PA-DSS Topic Required Implementation Guide Content Control Implementation Responsibility Mask PAN when displayed so only personnel with a business need can see the full more than the first six/last four digits of the PAN. Required Implementation Guide Content Instructions on how to configure the payment application such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN (includes displays of the full PAN.). Control Implementation Responsibility Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see more than the fullfirst six/last four digits of the PAN. Customers & Integrators/Resellers: Mask displays of PAN so only personnel with a business need can see more than the fullfirst six/last four digits of the PAN, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.2. requirements, as applicable. requirements, as applicable 21 A.2.3 A.2.3 Required Implementation Guide Content The following must be provided for customers and integrators/resellers: Instruction that if debugging logs are ever enabled (for example, for troubleshooting purposes), and the logs include PAN, they must be protected in accordance with PCI DSS, disabled as soon as troubleshooting is complete and securely deleted when no longer needed. requirements, as applicable Page 13 of 18
22 A.3.1 A.3.1 Required Implementation Guide Content The following must be provided for customers and integrators/resellers: requirements, as applicable Identification of all roles and default accounts within the application with administrative access. 23 - A.7.2.3 PA-DSS Topic Provide instructions for customers about secure installation of patches and updates. Required Implementation Guide Content The following must be provided for customers and integrators/resellers: How the vendor will communicate notifications of new patches and updates. How patches and updates will be delivered in a secure manner with a known chain of trust. How to access and install patches and updates in a manner that maintains the integrity of the patch and update code. Control Implementation Responsibility Software Vendor: Document and implement processes for communication, delivery and secure installation of patches and updates. Customers and Integrators/Resellers: Access and install patches and updates in a secure manner, in accordance with PA-DSS Implementation Guide. requirements, as applicable Page 14 of 18
24 A.10.1 A.10.1 PA-DSS Topic Implement twomulti-factor authentication requirements, as applicable Required Implementation Guide Content Provide the following for customers and integrators/resellers: Instruction that all remote access originating from outside the customer s network to the payment application must use twomulti-factor authentication in order to meet PCI DSS requirements. Description of the twomulti-factor authentication mechanisms supported by the application. Instructions on how to configure the application to support twomulti-factor authentication (at least two of the three authentication methods described in PA DSS Req. Requirement 3.1.4). Control Implementation Responsibility twomulti-factor authentication 25 A.11.1 A.11.1 Required Implementation Guide Content If the payment application sends, or facilitates sending, cardholder data over public networks,... How to configure the payment application to prevent fallback to an insecure version or 26 A.12.1 A.12.1 Required Implementation Guide Content configuration (e.g. if TLS is used, the application must not allow fallback to SSL). If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or TLS) for encryption of all non-console administrative access to payment application or servers in cardholder data environment. requirements, as applicable requirements, as applicable Page 15 of 18
27 A.12.2 A.12.1.1 Required Implementation Guide Content Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all non-console administrative requirements, as applicable access Control Implementation Responsibility PA-DSS Requirement 12.21.1 28 - A.12.2 PA-DSS Topic Use multi-factor authentication for all personnel with non-console administrative access requirements, as applicable Required Implementation Guide Content Include instructions for customers and integrators/resellers to use multi-factor authentication, including: Instruction that multi-factor authentication must be used for all personnel with non-console administrative access to the CDE. Procedures for using the multi-factor authentication provided with the application (if provided). Control Implementation Responsibility Software Vendor: Ensure payment application provides or specifies use of multi-factor authentication for all personnel with non-console administrative access, per PA-DSS Requirement 12.2. Customers & Integrators/Resellers: Use multi-factor authentication for all non-console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.2. Page 16 of 18
This page intentionally left blank.
Control Gap Inc. is a privately held company, headquartered in Toronto, with hundreds of satisfied customers across North America including retail and e-commerce merchants, service providers, financial services, healthcare, government, and more. We help businesses safeguard sensitive data, reduce security risk and avoid fines. We are Canada s foremost leader in Payment Card Industry (PCI) compliance validation and advisory services, founded from decades of information security, privacy data protection, and payment industry experience. Control Gap Inc. controlgap.com This document has been made publicly available at controlgap.com without warranty. Feel free to copy or distribute unmodified without restriction.