Document Diff - PCI Watch

Added p. 4

Additional resources including Attestations of Validation, Frequently Asked Questions (FAQs) and the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms are available on the PCI Security Standards Council (PCI SSC) website•www.pcisecuritystandards.org.

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).

Traditional PCI Data Security Standard compliance may not apply directly to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, since these payment applications are used by customers to store, process, and transmit cardholder data, and customers are required to be PCI Data Security Standard compliant, payment applications should facilitate, and not prevent, the customers' PCI Data Security Standard compliance. Just a …

Added p. 7

There are two ways for a resident payment application on a hardware terminal to achieve PA-DSS validation:

1. The resident payment application directly meets all PA-DSS requirements and is validated according to standard PA-DSS procedures.

2. The resident payment application does not meet all PA-DSS requirements, but the hardware that the application is resident on is listed on the PCI SSC’s Approved PIN Transaction Security (PTS) Devices List as a current PCI PTS approved Point of Interaction (POI) device. In this scenario, it may be possible for the application to satisfy PA-DSS requirements through a combination of the PA-DSS and PTS validated controls.

The remainder of this section applies only to payment applications that that are resident on a validated PCI PTS approved POI device.

If one or more PA-DSS requirements cannot be met by the payment application directly, they may be satisfied indirectly by controls tested as part of the PCI PTS validation. …

Added p. 8

Is a centralized repository for PA-DSS Reports of Validation (ROVs) Performs Quality Assurance (QA) reviews of PA-DSS ROVs to confirm report consistency and quality Lists PA-DSS validated payment applications on the website Qualifies and trains PA-QSAs to perform PA-DSS reviews Maintains and updates the PA-DSS standard and related documentation according to a standards lifecycle management process Note that PCI SSC does not approve reports from a validation perspective. The role of the PA-QSA is to document the payment application’s compliance to the PA-DSS as of the date of the assessment. Additionally, PCI SSC performs QA to assure that the PA-QSAs accurately and thoroughly document PA-DSS assessments.

Added p. 9

Implementing a PA-DSS-compliant payment application into a PCI DSS-compliant environment (or instructing the merchant to do so) Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor Configuring the payment application (or instructing the merchant to do so) in a PCI DSS-compliant manner Servicing the payment applications (for example, troubleshooting, delivering remote updates, and providing remote support) according to the PA-DSS Implementation Guide and PCI DSS Resellers and integrators do not submit payment applications for assessment. Products may only be submitted by the vendor.

Note: Not all QSAs are PA- QSAs•there are additional qualification requirements that must be met for a QSA to become a PA-QSA.

Implementing a PA-DSS-compliant payment application into a PCI DSS-compliant environment Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor Configuring …

Added p. 11

The testing laboratory should be able to simulate real-world use of the payment application.

The PA-QSA must validate the clean installation of the lab environment to ensure the environment truly simulates a real world situation and that the vendor has not modified or tampered with the environment in any way.

Please refer to Appendix B: Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment in this document for detailed requirements for the laboratory and related laboratory processes.

PA-QSA must complete and submit Appendix B, completed for the specific laboratory used for the payment application under review, as part of the completed PA-DSS report.

PCI DSS Applicability Information (Excerpted from PCI DSS) The Payment Card Industry Data Security Standard (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 …

Added p. 13

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.

Added p. 14

1. Description of Scope of Review Describe scope of review coverage, per the Scope of PA-DSS section above Timeframe of validation PA-DSS version used for the assessment List of documentation reviewed

3. Complete and sign an Attestation of Validation (both PA-QSA and software vendor). The Attestation of Validation is available on the PCI SSC website (www.pcisecuritystandards.org). 4. After completion, submit all of the above documents to PCI SSC according to the PA-DSS Program Guide.

PA-DSS report submission and acceptance processes Annual renewal process for payment applications included on the List of PA-DSS Validated Applications Transition of PABP-validated applications to the List of PA-DSS Validated Payment Applications Notification responsibilities in the event a listed payment application is determined to be at fault in a compromise.

Added p. 17

It is permissible for Issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.

Aligns with PCI DSS Requirement 3.2 1.1.a If this payment application stores sensitive authentication data, verify that the application is intended only for issuers and/or companies that support issuing services.

1.1.b For all other payment applications, if sensitive authentication data (see 1.1.1•1.1.3 below) is stored prior to authorization and then deleted, obtain and review methodology for deleting the data to determine that the data is unrecoverable.

Aligns with PCI DSS Requirement 3.2.3 1.1.3 Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application, and verify that PINs and encrypted PIN blocks are not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application). …

Added p. 24

How to securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or resellers/integrators are involved in these key management activities.

A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key- custodian responsibilities.

How to perform key management functions defined in 2.6.1 through 2.6.7 below, as required for PCI DSS compliance 2.6.b Verify the payment application implements key- management techniques for keys, as follows:

Added p. 25

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key- encrypting key). Archived cryptographic keys should be used only for decryption/verification purposes.

2.6.5.a Verify that key-management procedures are implemented to retire keys when the integrity of the key has been weakened.

2.6.5.b Verify that key-management procedures are implemented to replace known or suspected compromised keys.

2.6.5.c If retired or replaced cryptographic keys are retained, verify that the application does not use these keys for encryption operations.

Added p. 25

Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

Added p. 27

3. Provide secure authentication features 3.1 The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts, generated or managed by the application, by the completion of installation and for subsequent changes after installation.

The application must require the following:

Aligns with PCI DSS Requirements 8.1, 8.2, and 8.5.8•8.5.15 3.1.a Examine PA-DSS Implementation Guide created by vendor to verify the following:

Customers and resellers/integrators are advised that the payment application enforces secure authentication for all authentication credentials that the application generates by:

- Enforcing secure changes to authentication credentials by the completion of installation (See below at 3.1.1 through 3.1.10).

- Enforcing secure changes for any subsequent changes (after installation) to authentication credentials (See below at 3.1.1 through 3.1.10) Customers and resellers/integrators are advised to assign secure authentication to …

Added p. 28

Aligns with PCI DSS Requirements 8.1 3.1.1 Confirm that the payment application assigns unique user IDs:

3.1.1.a By completion of the installation process.

3.1.2.a By completion of the installation process.

3.1.1.b For subsequent changes after installation.

3.1.2.b For subsequent changes after installation.

Added p. 28

Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric Aligns with PCI DSS Requirements 8.2 3.1.2 Confirm that the payment application requires at least one of the defined authentication methods:

Added p. 28

Aligns with PCI DSS Requirement 8.5.8 3.1.3 Confirm that the payment application does not rely on or use any group, shared, or generic accounts and passwords:

3.1.3.a By completion of the installation process 3.1.3.b For subsequent changes after installation.

Added p. 29

Aligns with PCI DSS Requirement 8.5.9 3.1.4 Confirm that the payment application requires users to change passwords at least every 90 days:

3.1.4.a By completion of the installation process 3.1.4.b For subsequent changes after installation 3.1.5 The payment application requires a minimum password length of at least seven characters.

Aligns with PCI DSS Requirement 8.5.10 3.1.5 Confirm that the payment requires passwords to be at least seven characters long:

3.1.5.a By completion of the installation process 3.1.5.b For subsequent changes after installation 3.1.6 The payment application requires that passwords contain both numeric and alphabetic characters.

Aligns with PCI DSS Requirement 8.5.11 3.1.6 Confirm that the payment application requires passwords to contain both numeric and alphabetic characters.

3.1.6.a By completion of the installation process 3.1.6.b For subsequent changes after installation 3.1.7 The payment application keeps password history and requires that a new password is different than any of the last four passwords used.

Aligns with PCI DSS …

Added p. 30

Aligns with PCI DSS Requirement 8.5.14 3.1.9 Confirm that the payment application locks out user accounts for a minimum of 30 minutes or until a system administrator resets the account.

3.1.9.a By completion of the installation process 3.1.9.b For subsequent changes after installation 3.1.10 If a payment application session has been idle for more than 15 minutes, the application requires the user to re-authenticate to re-activate the session.

Aligns with PCI DSS Requirement 8.5.15 3.1.10 Confirm that the payment sets a session idle time out to 15 minutes or less.

How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 below.

That logs should not be disabled and doing so will result in non-compliance with PCI DSS.

Aligns with PCI DSS Requirement 10.2 4.2 Test the payment application and examine payment application audit logs and audit log settings, and perform the following:

Added p. 32

Aligns with PCI DSS Requirement 10.3 4.3 Test the payment application and examine the payment application’s audit logs and audit log settings, and, for each auditable event (from 4.2), perform the following:

Added p. 32

4.4. Payment application must facilitate centralized logging.

Note: Examples of this functionality may include, but are not limited to:

Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.

Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.

Aligns with PCI DSS Requirement 10.5.3 4.4.a Validate that payment application provides functionality that facilitates a merchant’s ability to assimilate logs into their centralized log server.

4.4.b Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are provided with instructions and procedures for incorporating the payment application logs into a centralized logging environment.

Aligns with PCI DSS Requirement 6.3 5.1.a Obtain and examine written software development processes to verify that processes are based on industry standards and/or best practices.

5.1.b Verify that information security is included throughout the software development life …

Added p. 33

Aligns with PCI DSS Requirement 6.4.3 5.1.1 Live PANs are not used for testing or development.

Added p. 34

Aligns with PCI DSS Requirement 6.5 5.2.a Obtain and review software development processes for payment applications (internal and external, and including web-administrative access to product). Verify the process includes training in secure coding techniques for developers, based on industry best practices and guidance.

5.2.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.

5.2.c Verify that payment applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit each of the following:

Added p. 34

Note: Requirements 5.2.7 through 5.2.9, below, apply to web-based applications and application interfaces (internal or external):

Added p. 35

5.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the system 5.3.3.b Verify that all changes (including patches) are tested for compliance with 5.2 before being released.

Added p. 35

5.4.a Examine system services, protocols, daemons, components, and dependent software and hardware enabled or required by the payment application. Verify that only necessary and secure services, protocols, daemons, components, dependent software and hardware are enabled by default “out of the box” 5.4.b If the application supports any insecure services, daemons, protocols or components, verify they are securely configured by default “out of the box”.

Added p. 36

6.1.a Verify encryption keys were

• changed from default at installation, and are

• changed anytime anyone with knowledge of the keys leaves the company or changes positions 6.1.b Verify default SNMP community strings on wireless devices were changed 6.1.c Verify default passwords/passphrases on access points were changed 6.1.d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks 6.1.e Verify other security-related wireless vendor defaults were changed, if applicable 6.1.f Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are instructed, if wireless is used, to:

Change wireless vendor defaults as defined in 6.1.a

• 6.1.e above; Install a firewall between any wireless networks and systems that store cardholder data, and Configure firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment

Note: …

Added p. 38

7.1.a Verify that processes include assigning a risk ranking to identified vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as “High”.) 7.1.b Verify the processes to identify new security vulnerabilities include using outside sources for security vulnerability information 7.1.c Verify that processes include testing of payment applications for new vulnerabilities 7.1.d Verify that processes to identify new vulnerabilities and implement corrections into payment application apply to all software provided with or required by the payment application (for example, web servers, third-party libraries and programs).

7.2.a Obtain and examine processes to develop and deploy security patches and upgrades for software. Verify that processes include the timely development and deployment of patches to customers 7.2.b Review processes to verify that patches and updates are delivered in a secure manner with a known chain-of-trust 7.2.c Review processes to verify that patches and updates are delivered in a manner that maintains …

Added p. 40

Note: Two-factor authentication requires that 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 two-factor authentication. The authentication methods, also known as a factors, are:

Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric Aligns with PCI DSS Requirement 8.3 10.1 Test the payment application in a lab to obtain evidence that it does not interfere with two-factor authentication technologies.

Note: Two-factor authentication requires that two of the three authentication methods be used for authentication (see PA-DSS Req. 10.1 for descriptions of authentication methods).

Alternatively, if delivered via VPN or other high- speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure “always- on” connections.

Aligns with PCI …

Added p. 47

Restrict access to keys to the fewest number of custodians necessary. Store keys securely in the fewest possible locations and forms Software Vendor: Provide guidance to customers that keys used to secure cardholder data should be stored securely in the fewest possible locations, and access to keys must be restricted to the fewest possible custodians.

Customers & Resellers/Integrators: Store keys securely in the fewest possible locations, and restrict access to keys to the fewest possible custodians.

Added p. 47

How to securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or resellers/integrators are involved in these key management activities. A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities. How to perform key management functions defined in PA-DSS requirements 2.6.1 through 2.6.7.

Software Vendor: Provide instructions to customers that access cryptographic keys used for encryption of cardholder data to implement key management processes and procedures.

Customers & Resellers/Integrators: Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data per PA-DSS Implementation Guide and PA-DSS Requirement 2.6.

Added p. 48

That the payment application enforces secure authentication for any authentication credentials (e.g. users, passwords) that the application generates by: - Enforcing secure changes to authentication credentials by the completion of installation and for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1. Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15, by the completion of installation and for subsequent changes after installation, for all application level accounts with administrative access or access to cardholder data.

When authentication credentials are not generated or managed by the payment application, ensure the PA- DSS Implementation Guide provides clear and unambiguous guidance for customers and resellers/integrators on how to change and create secure authentication credentials …

Added p. 49

Document all required protocols, services, components, and dependent software and hardware that are necessary for any functionality of the payment application.

Software Vendor: Ensure payment application supports customer’s use of only necessary and secure protocols, services, etc., by 1) having only necessary protocols, services, etc., established “out of the box” by default, 2) having those necessary protocols, services, etc., securely configured by default, and 3) by documenting necessary protocols, services, etc., as a reference for customers and resellers/integrators.

Customers and Resellers/Integrators: Use the documented list from the Implementation Guide to ensure only necessary and secure protocols, services, etc., are used on the system, in accordance with PA- DSS Requirement 5.4.

Added p. 50

Activate remote-access technologies for payment application updates only when needed for downloads, and turn off immediately after download completes, per PCI DSS Requirement 12.3.9. If computer is connected via VPN or other high- speed connection, receive remote payment application updates via a securely configured firewall or personal firewall per PCI DSS Requirement 1.

Software Vendor: Deliver remote payment application updates securely per PA-DSS 10.3 Customers & Resellers/Integrators: Receive remote payment application updates from vendor securely, per the PA-DSS Implementation Guide, PA-DSS Requirement 10.3 and PCI DSS Requirement 1.

Added p. 51

Implement and use strong cryptography and security protocols for secure cardholder data transmission over public networks.

Software Vendor: Ensure payment application supports customer’s use of strong cryptography and security protocols for transmissions of cardholder data over public networks, per PA-DSS Requirement 11.1.

Added p. 51

Implement and use a solution that renders the PAN unreadable or implements strong cryptography if PANs can be sent with end-user messaging technologies.

5.b The laboratory uses only test card numbers for the simulation/testing

• live PANs are not used for testing.

Note: Test cards can usually be obtained from the vendor or a processor or acquirer.

7.c The PA-QSA must validate the clean installation of the remote lab environment to ensure the environment truly simulates a real world situation and that the vendor has not modified or tampered with the environment in any way.

7.e All testing is either (1) performed while onsite at the vendor’s premises, or (2) performed remotely via a network connection using a secure link (for example, VPN).

Removed p. 5

Relationship between PCI DSS and PA-DSS The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. This document, which can be found at www.pcisecuritystandards.org, details what is required to be PCI DSS compliant (and therefore what a payment application must support to facilitate a customer’s PCI DSS compliance). Traditional PCI Data Security Standard compliance may not apply directly to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, since these payment applications are used by customers to store, process, and transmit cardholder data, and customers are required to be PCI Data Security Standard compliant, payment applications should facilitate, and not prevent, the customers' PCI Data Security Standard compliance. Just a few of the ways payment applications can prevent compliance follow. 1. Storage of magnetic stripe data in …

Modified p. 6 → 5

PA-DSS does apply to payment applications that are typically sold and installed “off the shelf” without much customization by software vendors.

Modified p. 6 → 5

PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. ~~PA-DSS~~ may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a “best practice” for software vendors to isolate …

PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA- DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a “best practice” for software vendors to …

Modified p. 6 → 5

PA-DSS does NOT apply to payment applications offered by application or service providers only as a service (unless such applications are also sold, licensed, or distributed to third parties) because:

Modified p. 6 → 5

1) Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers’ use. Note that PA-DSS would apply, however, if the ASP’s payment application is also sold to, and implemented on, a third-party site, and the application was not covered by the ASP’s PCI DSS review.

1) Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers’ use. Note that PA-DSS would apply, however, if the ASP’s payment application were also sold to, and implemented on, a third-party site, and the application was not covered by the ASP’s PCI DSS review.

Modified p. 6 → 5

PA-DSS does NOT apply to non-payment applications that are part of a payment application suite. Such applications ~~(e.g.,~~ a ~~fraud- monitoring,~~ scoring or detection application included in a suite) can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a payment application is part of a suite that relies on PA-DSS requirements being met by controls in other applications in the suite, a single PA-DSS assessment should be performed …

PA-DSS does NOT apply to non-payment applications that are part of a payment application suite. Such applications (for example, a fraud-monitoring, scoring or detection application included in a suite) can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a payment application is part of a suite that relies on PA-DSS requirements being met by controls in other applications in the suite, a single PA-DSS assessment should be performed …

Modified p. 7 → 6

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.

Modified p. 7 → 6

Operating systems onto which a payment application is installed (for example, Windows, Unix) Database systems that store cardholder data (for example, Oracle) Back-office systems that store cardholder data (for example, for reporting or customer service purposes)

Operating systems onto which a payment application is installed (for example, Windows, Unix) Database systems that store cardholder data (for example, Oracle) Back-office systems that store cardholder data (for example, for reporting or customer service purposes) The scope of the PA-DSS review should include the following:

Modified p. 7 → 6

PCI SSC will ONLY list applications that are payment applications.

Note: PCI SSC will ONLY list applications that are payment applications.

Modified p. 7 → 6

Coverage of all payment application functionality, including but not limited to 1) end-to-end payment functions (authorization and settlement), 2) input and output, 3) error conditions, 4) interfaces and connections to other files, systems, and/or payment applications or application components, 5) all cardholder data flows, 6) encryption mechanisms, and 7) authentication mechanisms.

Modified p. 7 → 6

Coverage of guidance the payment application vendor is expected to provide to customers and resellers/integrators (see PA-DSS Implementation Guide later in this document) to ensure 1) customer knows how to implement the payment application in a PCI DSS- compliant manner and 2) customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS compliance. Note that the payment application vendor may be expected to provide such guidance even when the specific setting 1) cannot …

Modified p. 7 → 6

Coverage of all selected platforms for the reviewed payment application version (included platforms should be ~~specified) Coverage of tools used by or within the payment application to access and/or view cardholder data (reporting tools, logging tools, etc.)~~

Coverage of all selected platforms for the reviewed payment application version (included platforms should be specified).

Removed p. 8

The terminal has no connections to any of the merchant’s systems or networks; The terminal connects only to the acquirer or processor; The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.

The payment brands may define compliance programs, mandates, dates, etc. using PA-DSS and the validated payment applications listed by PCI SSC. Through these compliance programs, the payment brands promote use of the listed validated payment applications.

Is a centralized repository for PA-DSS Reports of Validation (ROVs) Performs Quality Assurance (QA) reviews of PA-DSS ROVs to confirm …

Modified p. 8

Any requirements, mandates, or dates for use of PA-DSS compliant payment ~~applications; ~~ Any fines or penalties related to use of non-compliant payment applications.

Any requirements, mandates, or dates for use of PA-DSS compliant payment applications Any fines or penalties related to use of non-compliant payment applications The payment brands may define compliance programs, mandates, dates, etc., using PA-DSS and the validated payment applications listed by PCI SSC. Through these compliance programs, the payment brands promote use of the listed validated payment applications.

Removed p. 9

Creating PA-DSS compliant payment applications that facilitate and do not prevent their customers’ PCI DSS compliance. (The application cannot require an implementation or configuration setting that violates a PCI DSS requirement.); Following PCI DSS requirements whenever the vendor stores, processes or transmits cardholder data (for example, during customer troubleshooting); Creating a PA-DSS Implementation Guide, specific to each payment application, according to the requirements in this document; Educating customers, resellers, and integrators on how to install and configure the payment applications in a PCI DSS-compliant manner; Ensuring payment applications meet PA-DSS by successfully passing a PA-DSS review as specified in this document.

PA-QSAs are QSAs that have been qualified and trained by PCI SSC to perform PA-DSS reviews. Note that all QSAs are not PA-QSAs

• there are additional qualification requirements that must be met for a QSA to become a PA-QSA.

Modified p. 9

~~PA-QSAs are responsible for: ~~ Performing assessments on payment applications in accordance with the Security Assessment Procedures and the PA-QSA Validation Requirements Providing an opinion regarding whether the payment application meets PA-DSS requirements Providing adequate documentation within the ROV to demonstrate the payment application’s compliance to the PA-DSS Submitting the ROV to PCI SSC, along with the Attestation of Validation (signed by both PA-QSA and vendor) Maintaining an internal quality assurance process for their PA-QSA efforts …

Performing assessments on payment applications in accordance with the Security Assessment Procedures and the PA-QSA Validation Requirements Providing an opinion regarding whether the payment application meets PA-DSS requirements Providing adequate documentation within the ROV to demonstrate the payment application’s compliance to the PA-DSS Submitting the ROV to PCI SSC, along with the Attestation of Validation (signed by both PA-QSA and vendor) Maintaining an internal quality assurance process for their PA-QSA efforts It is the PA-QSA’s …

Removed p. 10

Resellers and integrators do not submit payment applications for assessment. Products can only be submitted by the vendor.

Implementing a PA-DSS-compliant payment application into a PCI DSS-compliant environment; Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor; A PA-DSS compliant payment application alone is no guarantee of

Configuring the payment application in a PCI DSS-compliant manner; Maintaining the PCI DSS-compliant status for both the environment and the payment application configuration.

PA-DSS Implementation Guide Validated payment applications must be capable of being implemented in a PCI DSS-compliant manner. Software vendors are required to provide a PA-DSS Implementation Guide to instruct their customers and resellers/integrators on secure product implementation, to document the secure configuration specifics mentioned throughout this document, and to clearly delineate vendor, reseller/integrator, and customer responsibilities for meeting PCI DSS requirements. It should detail how the customer and/or reseller/integrator …

Modified p. 11 → 10

Payment Application Qualified Security Assessor (PA-QSA) Requirements Only Payment Application Qualified Security Assessors (PA-QSAs) employed by Qualified Security Assessor (QSA) companies are allowed to perform PA-DSS assessments. Please see the Qualified Security Assessor list at www.pcisecuritystandards.org for a list of companies qualified to perform PA-DSS assessments. ~~ The PA-QSA must utilize the testing procedures documented in this Payment Application Data Security Standard document.~~

Payment Application Qualified Security Assessor (PA-QSA) Requirements Only Payment Application Qualified Security Assessors (PA-QSAs) employed by Qualified Security Assessor (QSA) companies are allowed to perform PA-DSS assessments. Please see the Qualified Security Assessor list at www.pcisecuritystandards.org for a list of companies qualified to perform PA-DSS assessments.

Removed p. 13

Data Element Storage Permitted Protection

PCI DSS Req. 3, 4 Cardholder Data Primary Account Number Yes Yes Yes Cardholder Name 1 Yes Yes 1 No Service Code 1 Yes Yes 1 No Expiration Date 1 Yes Yes 1 No Authentication Full Magnetic Stripe Data3 No N/A N/A CAV2/CID/CVC2/CVV2 No N/A N/A PIN/PIN Block No N/A N/A 1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS; however, does not apply if PANs are not stored, processed, or transmitted. 2 Do not store sensitive authentication data after authorization …

Modified p. 13 → 12

~~PCI DSS Applicability Information (Excerpted from PCI DSS v1.2)~~ The following table from the Payment Card Industry Data Security Standard (PCI DSS) illustrates commonly used elements of cardholder data and sensitive authentication data, whether storage of that data is permitted or prohibited, and whether this data needs to be protected. This table is not meant to be ~~exhaustive; its sole purpose~~ is to illustrate the different type of requirements that apply to each data element. ~~The Primary Account Number (PAN) …~~

The following table from the Payment Card Industry Data Security Standard (PCI DSS) illustrates commonly used elements of cardholder data and sensitive authentication data, whether storage of that data is permitted or prohibited, and whether this data needs to be protected. This table is not meant to be exhaustive, but is presented to illustrate the different type of requirements that apply to each data element.

Modified p. 14

2. Executive Summary Include the following: Product Name Product Version and related platforms covered List of resellers and/or integrators for this product Operating system(s) with which the payment application was tested Database software used or supported by the payment application Brief description of the payment application/family of products (2-3 sentences) Network diagram of a typical implementation of the payment application (not necessarily a specific implementation at a customer’s site) that includes, at high …

Modified p. 15

~~Note that Appendix B:~~ Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment must also be completed and submitted with the completed ~~PA-DSS~~ report.

Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment must also be completed and submitted with the completed PA- DSS report.

Modified p. 15

3. Findings and Observations All PA-QSAs must use the following template to provide detailed report descriptions and findings Describe tests performed other than those included in the testing procedures column.

3. Findings and Observations All PA-QSAs must use the following template to provide detailed report descriptions and findings Describe tests performed other than those included in the testing procedures column. If the assessor determines that a requirement is not applicable for a given payment application, an explanation must be included in the “In Place” column for that requirement.

Modified p. 15

4. Contact Information and Report Date Software vendor contact information (include URL, phone number, and e-mail address) PA-QSA contact information (include name, phone number and e-mail address) PA-QSA Quality Assurance (QA) primary contact information (include primary QA contact’s name, phone number and e-mail address) Date of report

Modified p. 16

~~The PA-QSA must perform the following steps:~~ 1. Complete the Report on Validation using this document as a template: a. Complete the preface for the Report on Validation, in accordance with the section entitled “Instructions and Content for Report on Validation” b. Complete and document all steps detailed in the Requirements and Security Assessment Procedures, including brief descriptions of controls observed in the “In Place” column, and noting any comments. Please note that a report with any “Not in Place” …

1. Complete the Report on Validation using this document as a template: a. Complete the preface for the Report on Validation, in accordance with the section entitled “Instructions and Content for Report on Validation” b. Complete and document all steps detailed in the Requirements and Security Assessment Procedures, including brief descriptions of controls observed in the “In Place” column, and noting any comments. Please note that a report with any “Not in Place” opinions should not be submitted to PCI …

Modified p. 16

PA-DSS Program Guide Please refer to the PA-DSS Program Guide for information about PA-DSS program management, including the following topics: PA-DSS report submission and acceptance processes Annual renewal process for payment applications included on the List of PA-DSS Validated Applications Transition of PABP-validated applications to the List of PA-DSS Validated Payment Applications Notification responsibilities in the event a listed payment application is determined to be at fault in a compromise.

PA-DSS Program Guide Please refer to the PA-DSS Program Guide for information about PA-DSS program management, including the following topics:

Removed p. 17

PA-DSS Requirements Testing Procedures In Place Not in Place Target Date /

Modified p. 17

1. Do not retain full magnetic stripe, card ~~validation~~ code or value (CAV2, CID, CVC2, CVV2), or PIN block data 1.1 Do not store sensitive authentication data after authorization (even if encrypted): ~~Sensitive authentication data includes the data as cited in the following Requirements 1.1.1 through 1.1.3.~~

1. Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data 1.1 Do not store sensitive authentication data after authorization (even if encrypted):

Modified p. 17

~~PCI Data Security Standard Requirement 3.2 Note:~~ By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction has completed the authorization process and the customer has received the final transaction approval. After authorization has completed, this sensitive authentication data cannot be stored.

By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction has completed the authorization process and the customer has received the final transaction approval. After authorization has completed, this sensitive authentication data cannot be stored.

Modified p. 18

In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The accountholder’s name, Primary account number (PAN), Expiration date, and Service code To minimize risk, store only those data elements needed for business.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The accountholder’s name, Primary account number (PAN), Expiration date, and Service code To minimize risk, store only those data elements needed for business.

Modified p. 18

PCI ~~Data Security Standard~~ Requirement 3.2.1 1.1.1 Use forensic tools and/or methods (commercial tools, scripts, ~~etc.)4~~ to examine all output created by the payment application and verify that the full contents of any track from the magnetic stripe on the back of the card are not stored after authorization. Include the following types of files (as well as any other output generated by the payment application):

Aligns with PCI DSS Requirement 3.2.1 1.1.1 Use forensic tools and/or methods (commercial tools, scripts, etc.)3 to examine all output created by the payment application and verify that the full contents of any track from the magnetic stripe on the back of the card or equivalent data on a chip are not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application): Incoming transaction data All …

Modified p. 18

Incoming transaction data All logs (for example, transaction, history, debugging, error) History files Trace files Non-volatile memory, including non-volatile cache Database schemas Database contents 4 Forensic tool or method: A tool or method for uncovering, analyzing and presenting forensic data, which provides a robust way to authenticate, search, and recover computer evidence rapidly and thoroughly. In the case of forensic tools or methods used by PA-QSAs, these tools or methods should accurately locate …

Aligns with PCI DSS Requirement 3.2.2 1.1.2 Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application and verify that the three-digit or four-digit card verification code printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application): Incoming transaction data …

Removed p. 19

PCI Data Security Standard Requirement 3.2.2 1.1.2 Use forensic tools and/or methods (commercial tools, scripts, etc.)5 to examine all output created by the payment application and verify that the three-digit or four-digit card- validation code printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization. Include the following types of files (as well as any other output generated by the payment application):

Incoming transaction data All logs (for example, transaction, history, debugging, error) History files Trace files Non-volatile memory, including non-volatile cache Database schemas Database contents 1.1.3 After authorization, do not store the personal identification number (PIN) or the encrypted PIN block.

PCI Data Security Standard Requirement 3.2.3 1.1.3 Use forensic tools and/or methods (commercial tools, scripts, etc.)5 to examine all output created by the payment application, and verify that PINs and encrypted PIN …

Removed p. 20

PCI Data Security Standard Requirement 3.2

PCI Data Security Standard Requirement 3.2 1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’ problems and verify the procedures include:

Modified p. 20 → 19

Note: This requirement only ~~applies~~ if previous versions of the payment application stored sensitive authentication data.

Note: This requirement applies only if previous versions of the payment application stored sensitive authentication data.

Modified p. 20 → 19

That historical data must be removed (magnetic stripe data, card ~~validation~~ codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data That such removal is absolutely necessary for PCI DSS compliance 1.1.4.b Verify the vendor provides a secure wipe tool or procedure to remove the data.

Aligns with PCI DSS Requirement 3.2 1.1.4.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators: That historical data must be removed (magnetic stripe data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data That such removal is absolutely necessary for PCI DSS compliance 1.1.4.b Verify the vendor provides a secure wipe tool or …

Modified p. 20

Collection of sensitive authentication data only when needed to solve a specific problem Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific problem Encryption of sensitive authentication data while stored Secure deletion of such data immediately after use 1.1.5.b Select a sample of recent troubleshooting requests from customers, and verify each event followed the procedure examined at 1.1.5.a.

Aligns with PCI DSS Requirement 3.2 1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’ problems and verify the procedures include: Collection of sensitive authentication data only when needed to solve a specific problem Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific problem Encryption of sensitive authentication data while stored Secure deletion of such data immediately after use …

Removed p. 21

That cardholder data exceeding the customer-defined retention period must be purged A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted) 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Modified p. 21 → 20

Collect sensitive authentication only when needed to solve a specific problem. Store such data only in specific, known locations with limited access. Collect only the limited amount of data needed to solve a specific problem. Encrypt sensitive authentication data while stored. Securely delete such data immediately after use.

1.1.5.c Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators: Collect sensitive authentication only when needed to solve a specific problem. Store such data only in specific, known locations with limited access. Collect only the limited amount of data needed to solve a specific problem. Encrypt sensitive authentication data while stored. Securely delete such data immediately after use.

Modified p. 21

This requirement does not apply to those employees and other parties with a legitimate business need to see full PAN; This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, for point-of- sale (POS) receipts.

Modified p. 21

PCI ~~Data Security Standard~~ Requirement 3.3 2.2 Review displays of credit card data, including but not limited to POS devices, screens, logs, and receipts, to determine that credit card numbers are masked when displaying cardholder data, except for those with a legitimate business need to see full credit card numbers.

Aligns with PCI DSS Requirement 3.3 2.2 Review displays of credit card data, including but not limited to POS devices, screens, logs, and receipts, to determine that credit card numbers are masked when displaying cardholder data, except for those with a legitimate business need to see full credit card numbers.

Modified p. 21 → 24

PCI ~~Data Security Standard~~ Requirement ~~3.1 2.1.a~~ Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following ~~guidance~~ for customers and resellers/integrators:

Aligns with PCI DSS Requirement 3.6 2.6.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators:

Removed p. 22

PCI Data Security Standard Requirement 3.4 The PAN must be rendered unreadable anywhere it is stored, even outside the payment application. Note: “Strong cryptography” is defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.

Removed p. 22

PCI Data Security Standard Requirement 3.6 2.6 Verify the payment application implements key- management techniques for keys, per PCI DSS Requirements 3.6.1 through 3.6.8.

Modified p. 22

~~2.3.a~~ Verify that the PAN is rendered unreadable anywhere it is stored, ~~in accordance with PCI DSS Requirement 3.4.~~

Aligns with PCI DSS Requirement 3.4 2.3 Verify that the PAN is rendered unreadable anywhere it is stored, as follows.

Modified p. 22

~~2.3.b~~ If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with ~~PCI DSS Requirement 3.4.~~

2.3.e If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with Requirements 2.3.a through 2.3.d, above.

Modified p. 22 → 23

PCI ~~Data Security Standard~~ Requirement ~~3.4.1~~ 2.4 If disk encryption is used, verify that it is implemented ~~in accordance with PCI DSS Requirements 3.4.1.a through 3.4.1.c.~~

Aligns with PCI DSS Requirement 3.4.2 2.4 If disk encryption is used, verify that it is implemented as follows:

Modified p. 22 → 23

PCI ~~Data Security Standard~~ Requirement 3.5 2.5 Verify the payment application protects keys against disclosure and misuse, ~~per PCI DSS Requirement 3.5.1 and 3.5.2.~~

Aligns with PCI DSS Requirement 3.5 2.5 Verify the payment application protects any keys used to secure cardholder data against disclosure and misuse, as follows:

Removed p. 23

PCI Data Security Standard Requirement 3.6

3. Provide secure authentication features 3.1 The “out of the box” installation of the payment application in place at the completion of the installation process, must facilitate use of unique user IDs and secure authentication (defined at PCI DSS Requirements 8.1, 8.2, and 8.5.8•8.5.15) for all administrative access and for all access to cardholder data.

PCI Data Security Standard Requirements 8.1, 8.2, and 8.5.8•8.5.15 3.1.a Test the payment application to verify that unique user IDs and secure authentication are required for all administrative access and for all access to cardholder data, in accordance with PCI DSS Requirements 8.1, 8.2, and 8.5.8• 8.5.15.

Modified p. 23 → 26

That cryptographic material must be ~~removed ~~ How to ~~remove~~ cryptographic material That such ~~removal~~ is absolutely necessary for PCI DSS compliance How to re-encrypt historic data with new keys 2.7.b Verify vendor provides a ~~secure wipe~~ tool or procedure to ~~remove~~ cryptographic ~~material.~~

That cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable That such irretrievability is absolutely necessary for PCI DSS compliance How to re-encrypt historic data with new keys 2.7.b Verify vendor provides a tool or procedure to render cryptographic material irretrievable.

Modified p. 23 → 26

2.7.c Verify, through use of forensic tools and/or methods, that the secure wipe tool or procedure ~~securely removes~~ the cryptographic ~~material,~~ in accordance with industry-accepted ~~standards for secure deletion of data.~~

2.7.c Verify, through use of forensic tools and/or methods, that the secure wipe tool or procedure renders the cryptographic material irretrievable, in accordance with industry-accepted standards.

Modified p. 23 → 27

~~Note:~~ This requirement ~~only~~ applies ~~if previous versions of~~ the payment application used ~~cryptographic key materials~~ or ~~cryptograms to encrypt~~ cardholder data.

This requirement applies to the payment application and all associated tools used to view or access cardholder data.

Modified p. 23 → 27

3.1.b Test the payment application to verify the payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the administrative ~~account for database software).~~

3.1.b Test the payment application to verify the payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).

Removed p. 24

3.1.c Examine PA-DSS Implementation Guide created by vendor to verify the following: Customers and resellers/integrators are advised against using default administrative accounts for payment application logins (for example, don’t use the “sa” account for payment application access to the database). Customers and resellers/integrators are advised to assign secure authentication to these default accounts (even if they won’t be used), and then disable or do not use the accounts. Customers and resellers/integrators are advised to assign secure authentication for payment applications and systems whenever possible. Customers and resellers/integrators are advised how to create PCI DSS-compliant secure authentication to access the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15 Customers and resellers/integrators are advised that changing “out of the box” installation settings for unique user IDs and secure authentication will result in non- compliance with PCI DSS.

Modified p. 24 → 27

Note: These password controls are not intended to apply to ~~employees~~ who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by ~~employees~~ with administrative capabilities, for access to ~~servers~~ with cardholder data, and for access controlled by the payment application. ~~This requirement applies to the payment application and all associated tools used to view or access cardholder data.~~

Note: These password controls are not intended to apply to personnel who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by personnel with administrative capabilities, for access to systems with cardholder data, and for access controlled by the payment application.

Modified p. 24 → 30

PCI ~~Data Security Standard~~ Requirements 8.1 and 8.2 3.2 Examine PA-DSS Implementation Guide created by vendor to verify customers and resellers/integrators are strongly advised to control access, via unique user ID and PCI ~~DSS-compliant~~ secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.

Aligns with PCI DSS Requirements 8.1 and 8.2 3.2 Examine PA-DSS Implementation Guide created by vendor to verify customers and resellers/integrators are strongly advised to control access, via unique user ID and PCI DSS- compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.

Modified p. 24 → 30

PCI ~~Data Security Standard~~ Requirement 8.4 3.3 Examine payment application password files during storage and transmission to verify that passwords ~~are~~ unreadable at all times.

Aligns with PCI DSS Requirement 8.4 3.3 Examine payment application password files during storage and transmission to verify that strong cryptography is used to render passwords unreadable at all times.

Removed p. 25

PCI Data Security Standard Requirements 10.2 and 10.3 4.2.a Examine payment application log parameters and verify that logs contain the data required in PCI DSS Requirements 10.2.1 through 10.2.7 and 10.3.1 through 10.3.6.

Modified p. 25 → 31

PCI ~~Data Security Standard~~ Requirement 10.1 ~~4.1~~ Examine payment application settings to verify that payment application audit trails are automatically enabled or are available to be enabled by customers.

Aligns with PCI DSS Requirement 10.1 4.1.a Examine payment application settings to verify that payment application audit trails are automatically enabled or are available to be enabled by customers.

Modified p. 25 → 31

~~4.2.b~~ If payment application log settings are configurable by the customer and resellers/integrators, or customers or resellers/integrators are responsible for implementing logging, examine PA-DSS Implementation Guide prepared by the vendor to verify the following information is included: How to set PCI DSS-compliant log settings, per PCI DSS Requirements 10.2.1 through 10.2.7 and 10.3.1 through 10.3.6 That disabling of the logs should not be done and will result in non-compliance with PCI DSS

4.1.b If payment application log settings are configurable by the customer and resellers/integrators, or customers or resellers/integrators are responsible for implementing logging, examine PA-DSS Implementation Guide prepared by the vendor to verify the following information is included:

Removed p. 26

PCI Data Security Standard Requirement 6.3 5.1 Obtain and examine written software development processes to verify that they are based on industry standards, that security is included throughout the life cycle, and that software applications are developed in accordance with PCI DSS. From an examination of written software development processes, interviews of software developers, and examination of relevant data (network configuration documentation, production and test data, etc.), verify that:

Modified p. 26 → 33

5. Develop secure payment applications 5.1 ~~Develop all~~ payment applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best ~~practices~~ and ~~incorporate~~ information security throughout the software development life cycle. These processes must include the following:

5. Develop secure payment applications 5.1 The software vendor develops payment applications in accordance with PCI DSS and PA- DSS (for example, secure authentication and logging) and based on industry best practices, and incorporates information security throughout the software development life cycle. These processes must include the following:

Removed p. 27

Note: This requirement for code reviews applies to all payment application components (both internal and public-facing web applications), as part of the system development life cycle required by PA-DSS Requirement 5.1 and PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties.

5.1.7.b Confirm the vendor performs code reviews for all application code changes for web applications (using either manual or automated processes) as follows: Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide. (See PA-DSS Requirement 5.2 and PCI DSS Requirement 6.5.) Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release.

Modified p. 27 → 33

~~5.1.7.a~~ Confirm the vendor performs code reviews for all application code changes ~~for internal applications~~ (either using manual or automated processes), as follows: Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release.

Aligns with PCI DSS Requirement 6.3.2 5.1.4 Confirm the vendor performs code reviews for all significant application code changes (either using manual or automated processes), as follows: Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) Appropriate corrections are implemented prior to release. Code …

Removed p. 28

PCI Data Security Standard Requirement 6.5 5.2.a Obtain and review software development processes for any web-based payment applications (internal and external, and including web-administrative access to product). Verify the process includes training in secure coding techniques for developers, and is based on guidance such as the OWASP guide (http://www.owasp.org). Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.

5.2.b For web payment applications included in review, verify that the payment applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit each of the following:

Modified p. 28 → 34

Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through ~~5.2.10~~ and in PCI DSS at 6.5.1 through ~~6.5.10~~ were current ~~in the OWASP guide~~ when ~~PCI~~ DSS ~~v1.2~~ was published. However, ~~if and when~~ the OWASP ~~guide is updated,~~ the current ~~version~~ must be used for these requirements.

Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Removed p. 29

PCI Data Security Standard Requirement 2.2.2 5.4 Examine system services, daemons, and protocols enabled or required by the payment application. Verify that unnecessary and insecure services or protocols are not enabled by default or required by the payment application (for example, FTP is not enabled, or is encrypted via SSH or other technology).

Modified p. 29 → 35

PCI ~~Data Security Standard~~ Requirement ~~6.4~~ 5.3.a Obtain and examine the vendor’s change-control procedures for software modifications, and verify that the procedures require items 5.3.1•5.3.4 below.

Aligns with PCI DSS Requirement 6.4.5 5.3.a Obtain and examine the vendor’s change-control procedures for software modifications, and verify that the procedures require items 5.3.1•5.3.4 below.

Removed p. 30

6.1.b Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are instructed, if wireless is used, to install a firewall per PCI DSS Requirement 1.2.3.

For new wireless implementations, it is prohibited to implement WEP after March 31, 2009.

For current wireless implementations, it is prohibited to use WEP after June 30, 2010.

Modified p. 30 → 36

6. Protect wireless transmissions 6.1 For payment applications using wireless technology, ~~the~~ wireless technology must be implemented securely.

6. Protect wireless transmissions 6.1 For payment applications using wireless technology, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. The wireless technology must be implemented securely.

Modified p. 30 → 36

PCI ~~Data Security Standard~~ Requirements 1.2.3 & 2.1.1 ~~6.1.a~~ For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the payment application, verify that the wireless applications do not use vendor default ~~settings and are configured in accordance with PCI Data Security Standard Requirement 2.1.1.~~

Aligns with PCI DSS Requirements 1.2.3 & 2.1.1 6.1 For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the payment application, verify that the wireless applications do not use vendor default settings, as follows:

Modified p. 30 → 37

PCI ~~Data Security Standard~~ Requirement 4.1.1 6.2.a For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the vendor application, verify that industry best practices (for example, IEEE 802,11.i) were used to include or make available strong encryption for authentication and ~~transmission, in accordance with PCI DSS Requirement 4.1.1.~~

Aligns with PCI DSS Requirement 4.1.1 6.2.a For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the vendor application, verify that industry best practices (for example, IEEE 802,11.i) were used to include or make available strong encryption for authentication and transmission.

Modified p. 30 → 37

6.2.b If customers could implement the payment application into a wireless environment, examine PA-DSS Implementation Guide prepared by vendor to verify customers and resellers/integrators are instructed on PCI DSS-compliant wireless settings, ~~per PCI DSS Requirements 1.2.3, 2.1.1~~ and ~~4.1.1.~~

6.2.b If customers could implement the payment application into a wireless environment, examine PA-DSS Implementation Guide prepared by the vendor to verify customers and resellers/integrators are instructed on PCI DSS-compliant wireless settings, including changing wireless vendor defaults (per 6.1.a

• 6.1.e above), and using industry best practices to implement strong encryption for authentication and transmission of cardholder data (per 6.2.a).

Removed p. 31

7. Test payment applications to address vulnerabilities 7.1 Software vendors must establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet) and to test their payment applications for vulnerabilities. Any underlying software or systems that are provided with or required by the payment application (for example, web servers, 3rd-party libraries and programs) must be included in this process.

PCI Data Security Standard Requirement 6.2 7.1.a Obtain and examine processes to identify new vulnerabilities and to test payment applications for new vulnerabilities. Verify the processes include: Using outside sources for security vulnerability information Testing of payment applications for new vulnerabilities 7.1.b Verify that processes to identify new vulnerabilities and implement corrections into payment application apply to all software provided with or required by the payment application (for example, web servers, third-party libraries and programs).

7.2.a Obtain and examine processes to develop …

Modified p. 32 → 39

PCI ~~Data Security Standard~~ Requirements 1, 3, 4, 5, and ~~6.6~~ 8.1 Test the payment application in a lab to obtain evidence that it can run in a network that is fully compliant with PCI DSS. Verify that the payment application does not inhibit installation of patches or updates to other components in the environment.

Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6 8.1 Test the payment application in a lab to obtain evidence that it can run in a network that is fully compliant with PCI DSS. Verify that the payment application does not inhibit installation of patches or updates to other components in the environment.

Modified p. 32 → 39

9. Cardholder data must never be stored on a server connected to the Internet 9.1 The payment application must be developed such that ~~the~~ database server and web server are not required to be on the same server, nor is ~~the~~ database server required to be in the DMZ with the web server.

9. Cardholder data must never be stored on a server connected to the Internet 9.1 The payment application must be developed such that a database server and web server are not required to be on the same server, nor is a database server required to be in the DMZ with the web server.

Modified p. 32 → 39

PCI ~~Data Security Standard~~ Requirement ~~1.3.2~~ 9.1.a To verify that the payment application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the payment application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (for example, payment application must not require that ~~the~~ database server and web server be on the same server, or in the DMZ with the …

Aligns with PCI DSS Requirement 1.3.7 9.1.a To verify that the payment application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the payment application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (for example, payment application must not require that a database server and web server be on the same server, or in the DMZ with the …

Modified p. 32 → 39

9.1.b If customers could store cardholder data on a server connected to the Internet, examine PA-DSS Implementation Guide prepared by vendor to verify customers and resellers/integrators are ~~told~~ not to store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server).

9.1.b If customers could store cardholder data on a server connected to the Internet, examine PA-DSS Implementation Guide prepared by vendor to verify customers and resellers/integrators are instructed not to store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server).

Removed p. 33

PCI Data Security Standard Requirements 1 and 12.3.9 10.1 If the vendor delivers payment application and/or updates via remote access to customer networks, examine PA-DSS Implementation Guide prepared by vendor, and verify it contains: Instructions for customers and resellers/integrators regarding secure use of remote-access technologies, per PCI DSS Requirement 12.3.9 Recommendation for customers and resellers/ integrators to use a firewall or a personal firewall product if computer is connected via VPN or other high-speed connection, to secure these “always-on” connections, per PCI DSS Requirement 1

11. Facilitate secure remote access to payment application 11.1 The payment application must not interfere with use of a two-factor authentication mechanism. The payment application must allow for technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates.

PCI Data Security Standard Requirement 8.3 11.1 Test the payment application in a lab to obtain evidence that it can run with a two-factor …

Modified p. 33 → 40

PCI ~~Data Security Standard~~ Requirement 8.3 ~~11.2~~ If the payment application may be accessed remotely, examine PA-DSS Implementation Guide prepared by the software vendor, and verify it contains instructions for customers and resellers/integrators regarding required use of two-factor authentication ~~(user ID and password and an additional~~ authentication ~~item such as a smart card, token, or PIN).~~

Aligns with PCI DSS Requirement 8.3 10.2 If the payment application may be accessed remotely, examine PA-DSS Implementation Guide prepared by the software vendor, and verify it contains instructions for customers and resellers/integrators regarding required use of two-factor authentication (two of the three authentication methods described in PA DSS Req. 10.1).

Removed p. 34

PCI Data Security Standard Requirement 8.3 11.3.a If the software vendor uses remote access products for remote access to the customers’ payment application, verify that vendor personnel implement and use remote access security features.

Note: Examples of remote access security features include: Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer). Allow connections only from specific (known) IP/MAC addresses. Use strong authentication and complex passwords for logins according to PCI DSS Requirements 8.1, 8.3, and 8.5.8•8.5.15 Enable encrypted data transmission according to PCI DSS Requirement 4.1 Enable account lockout after a certain number of failed login attempts according to PCI DSS Requirement 8.5.13 Configure the system so a remote user must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed. Enable the logging function. Restrict access to …

Removed p. 35

Note: Examples of remote access security features include: Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer). Allow connections only from specific (known) IP/MAC addresses. Use strong authentication and complex passwords for logins, according to PCI DSS Requirements 8.1, 8.3, and 8.5.8•8.5.15. Enable encrypted data transmission according to PCI DSS Requirement 4.1. Enable account lockout after a certain number of failed login attempts according to PCI DSS Requirement 8.5.13. Configure the system so a remote user must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed. Enable the logging function. Restrict access to customer passwords to authorized reseller/integrator personnel. Establish customer passwords according to PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5.

Removed p. 36

PCI Data Security Standard Requirement 4.1 12.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that secure encryption transmission technology (for example, IPSEC, VPN or SSL/TLS) is provided, or that use thereof is specified.

Modified p. 36 → 43

~~12.~~ Encrypt sensitive traffic over public networks ~~12.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 ~~such as SSL/TLS and~~ Internet protocol security ~~(IPSEC)~~ to safeguard sensitive cardholder data during transmission over open, public networks. ~~Examples of open, public networks that are in scope of the PCI DSS are: The Internet Wireless technologies Global System for Mobile Communications (GSM) …~~

11. Encrypt sensitive traffic over public networks 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, SSL/TLS, Internet protocol security (IPSEC), SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Modified p. 36 → 43

~~12.1.b~~ If the payment application allows data transmission over public networks, examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and resellers/integrators to use ~~secure encryption transmission technology (for example, IPSEC, VPN or SSL/TLS).~~

11.1.b If the payment application allows data transmission over public networks, examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and resellers/integrators to use strong cryptography and security protocols.

Modified p. 36 → 43

PCI ~~Data Security Standard~~ Requirement 4.2 ~~12.2.a~~ If the payment application allows and/or facilitates sending of PANs by end-user messaging technologies, verify that a strong cryptography ~~solution~~ is provided, or that use thereof is specified.

Aligns with PCI DSS Requirement 4.2 11.2.a If the payment application allows and/or facilitates sending of PANs by end-user messaging technologies, verify that a solution that renders the PAN unreadable or implements strong cryptography is provided, or that use thereof is specified.

Modified p. 36 → 43

~~12.2.b~~ If the payment application allows and/or facilitates the sending of PANs by end-user messaging technologies, examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and resellers/integrators to use a solution that implements strong cryptography.

11.2.b If the payment application allows and/or facilitates the sending of PANs by end-user messaging technologies, examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and resellers/integrators to use a solution that renders the PAN unreadable or implements strong cryptography.

Modified p. 37 → 44

~~13.~~ Encrypt all non-console administrative access ~~13.1~~ Instruct customers to encrypt all non-console administrative access using technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

12. Encrypt all non-console administrative access 12.1 Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Modified p. 37 → 44

~~PCI Data Security Standard Requirement 2.3~~ Telnet or rlogin must never be used for administrative access.

Note: Telnet or rlogin must never be used for administrative access.

Modified p. 37 → 44

~~14.~~ Maintain instructional documentation and training programs for customers, resellers, and integrators ~~14.1~~ Develop, maintain, and disseminate a PA- DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following:

13. Maintain instructional documentation and training programs for customers, resellers, and integrators 13.1 Develop, maintain, and disseminate a PA- DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following:

Modified p. 37 → 44

~~14.1.2.a~~ Verify the PA-DSS Implementation Guide is reviewed on an annual basis and updated as needed to document all major and minor changes to the payment application.

13.1.2.a Verify the PA-DSS Implementation Guide is reviewed on an annual basis and updated as needed to document all major and minor changes to the payment application.

Modified p. 37 → 44

~~14.1.2.b~~ Verify the PA-DSS Implementation Guide is reviewed on an annual basis and updated as needed to document changes to the PA-DSS requirements.

13.1.2.b Verify the PA-DSS Implementation Guide is reviewed on an annual basis and updated as needed to document changes to the PA-DSS requirements.

Modified p. 38 → 45

~~14.2.1.a~~ Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new payment application versions are released, and updated as needed.

13.2.1.a Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new payment application versions are released, and updated as needed.

Modified p. 38 → 45

~~14.2.1.b~~ Examine the distribution process for new payment application versions and verify that

13.2.1.b Examine the distribution process for new payment application versions and verify that

Modified p. 38 → 45

~~14.2.1.c~~ Select a sample of resellers and integrators and interview them to verify they received the training materials.

13.2.1.b Select a sample of resellers and integrators and interview them to verify they received the training materials.

Modified p. 39 → 46

Historical data must be removed (magnetic stripe data, card ~~validation~~ codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data Such removal is absolutely necessary for PCI DSS compliance Software Vendor: Provide tool or procedure for customers to securely remove data stored by previous versions, per PA-DSS Requirement 1.1.4.

Historical data must be removed (magnetic stripe data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data Such removal is absolutely necessary for PCI DSS compliance Software Vendor: Provide tool or procedure for customers to securely remove data stored by previous versions, per PA-DSS Requirement 1.1.4.

Modified p. 39 → 46

Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem Such data must be stored only in specific, known locations with limited access Only collect a limited amount of such data as needed to solve a specific problem Sensitive authentication data must be encrypted while stored Such data must be securely deleted immediately after use Software Vendor: Perform any troubleshooting of customer’s problems according to PA-DSS Requirement ~~1.1.6.a.~~

Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem Such data must be stored only in specific, known locations with limited access Only collect a limited amount of such data as needed to solve a specific problem Sensitive authentication data must be encrypted while stored Such data must be securely deleted immediately after use Software Vendor: Perform any troubleshooting of customer’s problems according to PA-DSS Requirement 1.1.5.a.

Modified p. 39 → 46

Customers & Resellers/Integrators: Troubleshoot any problems per the PA-DSS Implementation Guide and PA-DSS Requirement ~~1.1.6.a.~~

Customers & Resellers/Integrators: Troubleshoot any problems per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.5.a.

Modified p. 39 → 46

Cardholder data must be purged after it exceeds the customer-defined retention period All locations where payment application stores cardholder data Software Vendor: Provide guidance to customers that cardholder data exceeding customer-defined retention periods must be purged and where such data is stored by the payment application.

Removed p. 40

Do not use default administrative accounts for payment application logins. Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. Use secure authentication for the payment application and system whenever possible. How to create secure authentication to access the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15.

Modified p. 40 → 47

Cryptographic material must be ~~removed ~~ How to ~~remove~~ cryptographic material Such ~~removal~~ is absolutely necessary for PCI compliance How to re-encrypt historic data with new keys Software Vendor: Provide tool or procedure to securely remove cryptographic key material or cryptograms stored by previous versions, per PA-DSS Requirement 1.1.5, provide tool or procedure to re- encrypt historic data with new keys.

Cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable Such irretrievability is absolutely necessary for PCI compliance How to re-encrypt historic data with new keys Software Vendor: Provide tool or procedure to securely remove cryptographic key material or cryptograms stored by previous versions, per PA-DSS Requirement 1.1.5, provide tool or procedure to re- encrypt historic data with new keys.

Modified p. 40 → 48

Software Vendor: ~~Ensure~~ payment application ~~supports~~ customer’s use of unique user IDs and secure authentication for payment application accounts/passwords, per ~~PCI DSS~~ Requirements ~~8.1 and 8.2.~~

Software Vendor: When the payment application generates or manages authentication credentials, ensure payment application enforces customer’s use of unique user IDs and secure authentication for payment application accounts/passwords, per PA-DSS Requirements 3.1.1 through 3.1.10.

Modified p. 40 → 48

Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirements ~~8.1 and 8.2.~~

Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS Requirements 3.1.1 through 3.1.10.

Modified p. 40 → 48

Use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, ~~per PCI DSS Requirements 8.5.8~~ through ~~8.5.15.~~

Use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, PA-DSS requirements 3.1.1 through 3.1.10.

Modified p. 40 → 48

Software Vendor: Ensure payment application supports customer’s use of unique user IDs and secure authentication for accounts/passwords if set by vendor to access PCs, servers, and databases, per ~~PCI DSS Requirements 8.1, 8.2, and 8.5.8•8.5.15.~~

Software Vendor: Ensure payment application supports customer’s use of unique user IDs and secure authentication for accounts/passwords if set by vendor to access PCs, servers, and databases, per PA-DSS requirements 3.1.2 through 3.1.9.

Modified p. 40 → 48

Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and ~~PCI DSS Requirements 8.1, 8.2, and 8.5.8•8.5.15.~~

Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS requirements 3.1.2 through 3.1.10.

Modified p. 40 → 48

Software Vendor: Ensure payment application supports customer’s use of compliant logs per ~~PCI DSS Requirement 10.~~

Software Vendor: Ensure payment application supports customer’s use of compliant logs per PA-DSS Requirements 4.2, 4.3 and 4.4.

Modified p. 40 → 48

Customers & Resellers/Integrators: Establish and maintain PCI DSS-compliant logs per the PA-DSS Implementation Guide and ~~PCI DSS Requirement 10.~~

Customers & Resellers/Integrators: Establish and maintain PCI DSS-compliant logs per the PA-DSS Implementation Guide and PA-DSS Requirements 4.2, 4.3 and 4.4.

Modified p. 41 → 49

Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, ~~use secure encrypted transmissions~~ per the PA-DSS Implementation Guide and PCI DSS Requirement ~~4.1.1.~~

Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, change vendor defaults per PA-DSS Requirement 6.1 and install a firewall per the PA-DSS Implementation Guide and PCI DSS Requirement 2.1.1.

Modified p. 41 → 50

Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, ~~install a firewall~~ per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirement ~~2.1.1.~~

Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, use secure encrypted transmissions per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.

Modified p. 41 → 50

If payment application is implemented into a wireless environment, use ~~PCI DSS-compliant wireless settings, per PCI DSS Requirement 4.1.1.~~

If payment application is implemented into a wireless environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data.

Modified p. 41 → 50

Software Vendor: Instruct customers and resellers/integrators, that if wireless technology is used with the payment application, that secure encrypted transmissions must be implemented, per ~~PCI DSS~~ Requirement ~~4.1.1.~~

Software Vendor: Instruct customers and resellers/integrators, that if wireless technology is used with the payment application, that secure encrypted transmissions must be implemented, per PA-DSS Requirement 6.2.

Modified p. 41 → 50

Software Vendor: Ensure payment application does not require data storage in the DMZ or on Internet- accessible systems, and will allow use of a DMZ per ~~PCI DSS~~ Requirement ~~1.3.4.~~

Software Vendor: Ensure payment application does not require data storage in the DMZ or on Internet- accessible systems, and will allow use of a DMZ per PA-DSS Requirement 9.

Modified p. 41 → 50

Customers & Resellers/Integrators: Establish and maintain payment applications so that cardholder data is not stored on Internet-accessible systems, per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirement ~~1.3.4.~~

Customers & Resellers/Integrators: Establish and maintain payment applications so that cardholder data is not stored on Internet-accessible systems, per the PA-DSS Implementation Guide and PA-DSS Requirement 9 10.2 Implement two-factor authentication for remote access to payment application.

Removed p. 42

Receive remote payment application updates via secure modems, per PCI DSS Requirement 12.3. If computer is connected via VPN or other high- speed connection, receive remote payment application updates via a firewall or a personal firewall per PCI DSS Requirement 1 or 1.3.9.

Software Vendor: Deliver remote payment application updates securely per PCI DSS Requirements 1, 1.3.9, and 12.3.9.

Customers & Resellers/Integrators: Receive remote payment application updates from vendor securely, per the PA-DSS Implementation Guide and PCI DSS Requirements 1, 1.3.9, and 12.3.9.

Removed p. 42

Implement and use SSL for secure cardholder data transmission over public networks, in accordance with PCI DSS Requirement 4.1 Software Vendor: Ensure payment application supports customer’s use of secure transmissions of cardholder data over public networks, per PCI DSS Requirement 4.

Modified p. 42 → 50

Software Vendor: Ensure payment application supports customers’ use of two-factor authentication, per ~~PCI DSS~~ Requirement ~~8.3.~~

Software Vendor: Ensure payment application supports customers’ use of two-factor authentication, per PA-DSS Requirement 10.2.

Modified p. 42 → 50

Customers & Resellers/Integrators: Establish and maintain two-factor authentication for remote access to payment application, per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirement ~~8.3.~~

Customers & Resellers/Integrators: Establish and maintain two-factor authentication for remote access to payment application, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.

Modified p. 42 → 51

Software Vendor: (1) If vendor uses remote access products to access customer sites, use remote access security features such as those specified in PA-DSS Requirement ~~11.3.a.~~ (2) Ensure payment application supports customers’ use of remote access security features.

Software Vendor: (1) If vendor uses remote access products to access customer sites, use remote access security features such as those specified in PA-DSS Requirement 10.3.2. (2) Ensure payment application supports customers’ use of remote access security features.

Modified p. 42 → 51

Customers & Resellers/Integrators: Use remote access security features if you allow remote access to payment applications, per the PA-DSS Implementation Guide and PA-DSS Requirement ~~11.3.b.~~

Customers & Resellers/Integrators: Use remote access security features if you allow remote access to payment applications, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.3.2.

Modified p. 42 → 51

Customers & Resellers/Integrators: Establish and maintain ~~secure~~ transmissions of cardholder data, per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirement 4.

Customers & Resellers/Integrators: Establish and maintain strong cryptography and security protocols for transmissions of cardholder data, per the PA-DSS Implementation Guide and PA-DSS Requirement 11.1.

Modified p. 43 → 51

~~Implement and use an encryption solution for if PANs can be sent with end-user messaging technologies.~~ Software Vendor: Ensure payment application supports ~~customer’s~~ encryption of PANs if sent with end-user messaging technologies, per ~~PCI DSS~~ Requirement ~~4.2.~~

Software Vendor: Ensure payment application supports the encryption or rendering unreadable of PANs if sent with end-user messaging technologies, per PA-DSS Requirement 11.2.

Modified p. 43 → 51

Customers & Resellers/Integrators: Encrypt all PANs sent with end-user messaging technologies, per the PA- DSS Implementation Guide and ~~PCI DSS~~ Requirement ~~4.2.~~

Customers & Resellers/Integrators: Encrypt all PANs sent with end-user messaging technologies, per the PA- DSS Implementation Guide and PA-DSS Requirement 11.2.

Modified p. 43 → 51

Software Vendor: Ensure payment application supports customer’s encryption of any non-console administrative access, per ~~PCI DSS~~ Requirement ~~2.3.~~

Software Vendor: Ensure payment application supports customer’s encryption of any non-console administrative access, per PA-DSS Requirement 12.1.

Modified p. 43 → 51

Customers & Resellers/Integrators: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and ~~PCI DSS~~ Requirement ~~2.3.~~

Customers & Resellers/Integrators: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.1

Modified p. 44 → 52

Laboratory Requirement Laboratory Validation Procedure Completed in in Vendor’s ~~Lab Comments~~

Laboratory Requirement Laboratory Validation Procedure Completed in Comments PA-QSA’s Lab Vendor’s

Modified p. 45 → 53

4. Verify all PCI DSS-compliant system settings, patches, ~~etc.~~ were implemented on test systems for operating systems, system software, and applications used by the payment application.

4. Verify all PCI DSS-compliant system settings, patches, etc., were implemented on test systems for operating systems, system software, and applications used by the payment application.

Modified p. 45 → 53

~~5. Simulate real-world use of the payment application.~~ 5.a The laboratory simulates the ‘real world’ use of the payment application, including all systems and applications where the payment application is implemented. For example, a standard implementation of a payment application might include a client/server environment within a retail storefront with a POS machine, and back office or corporate network. The laboratory simulates the total implementation.

5.a The laboratory simulates the ‘real world’ use of the payment application, including all systems and applications where the payment application is implemented. For example, a standard implementation of a payment application might include a client/server environment within a retail storefront with a POS machine, and back office or corporate network. The laboratory simulates the total implementation.

Removed p. 46

7.c All testing is executed by the PA-QSA (the vendor cannot run tests against their own application).

Modified p. 46 → 54

6.a Use of forensic ~~tools/methods6:~~ Forensic tools/methods were used to search all identified output for evidence of sensitive authentication data (commercial tools, scripts, etc.), per PA-DSS Requirement ~~1.1.1•1.1.3.6~~ 6.b Attempt to exploit OWASP ~~vulnerabilities: OWASP vulnerabilities~~ were used to attempt to exploit the payment application(s), per PA-DSS Requirement ~~5.1.1•5.1.10.~~

6.a Use of forensic tools/methods: Forensic tools/methods were used to search all identified output for evidence of sensitive authentication data (commercial tools, scripts, etc.), per PA-DSS Requirement 1.1.1•1.1.3.4 6.b Attempt to exploit application vulnerabilities: Current vulnerabilities (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), were used to attempt to exploit the payment application(s), per PA-DSS Requirement 5.2.

Modified p. 46 → 54

6.c Laboratory and/or processes attempted to execute arbitrary code during the payment application update process: Run the update process with arbitrary code per PA-DSS ~~requirement~~ 7.2.b.

6.c Laboratory and/or processes attempted to execute arbitrary code during the payment application update process: Run the update process with arbitrary code per PA-DSS Requirement 7.2.b.

Modified p. 47 → 55

~~7.e~~ Use only test card numbers for the simulation/testing•do not use live PANs for testing. These test cards can usually be obtained from the vendor or a processor or acquirer.

7.f Use only test card numbers for the simulation/testing•do not use live PANs for testing. These test cards can usually be obtained from the vendor or a processor or acquirer.

Modified p. 47 → 55

8. Maintain an effective quality assurance (QA) process 8.a PA-QSA QA personnel ~~verifies~~ that all platforms identified in the PA-DSS report were included in testing.

8. Maintain an effective quality assurance (QA) process 8.a PA-QSA QA personnel verify that all platforms identified in the PA-DSS report were included in testing.

Removed p. 48

The PA-QSA and Payment Application Software Vendor should complete all sections and submit this document along with copies of all required validation documentation to PCI SSC, per PCI SSC’s instructions for report encryption and submission.

Part 1. Payment Application Qualified Security Assessor (PA QSA) Company Information Company Name:

Lead PA-QSA Contact Name: Title:

Business Address: City:

Business Address: City:

State/Province: Country: ZIP:

State/Province: Country: ZIP:

Part 2. Payment Application Vendor Information Company Name:

Part 2a. Payment Application Information List Payment Application Name(s) and Version Number(s) included in PA-DSS review:

Payment Application Functionality (check all that apply):

POS Suite POS Admin Shopping Cart & Store Front POS Face-to-Face Payment Middleware Others (please specify): POS Kiosk Payment Back Office POS Specialized Payment Gateway/Switch Target Market for Application:

Removed p. 49

Fully Validated: All requirements in the ROV are marked “in place,” thereby (Payment Application Name(s) and Version(s)) has achieved full validation with the Payment Application Data Security Standard.

The ROV was completed according to the PA-DSS, version (insert version number), in adherence with the instructions therein.

All information within the above-referenced ROV and in this attestation represents the results of the assessment fairly in all material respects.

No evidence of magnetic stripe (i.e., track) data7, CAV2, CVC2, CID, or CVV2 data8, or PIN data9 storage after transaction authorization on ANY files or functionalities generated by the application during this PA-DSS assessment.

Part 3b. Annual Re-Validation Confirmation:

The contents of the above-referenced ROV continue to be applicable to the following software version: (Payment Application Name and version).

Note: Section 3b is for the required Annual Attestation for listed payment applications, and should ONLY be completed if no modifications have been made to the Payment Application covered by …

Document Comparison

Content Changes