Document Diff - PCI Watch

Added p. 21

Note: The term “Capture” in Section 4.2 of the ROC Template refers to the specific transaction activity, while the use of “capture” in PCI DSS Requirement 9.9 refers to the receiving of cardholder data via physical contact with a payment card (e.g. via swipe or dip).

Cardholder data-flow diagrams may also be included as a supplement to the description of how cardholder data is transmitted and/or processed.

Added p. 27

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here> 1 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 any sensitive authentication data written by the payment application. These tools may be commercial, open-source, or developed in-house by the PA-QSA.

 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 Identify the test transactions observed for this testing procedure.

 Incoming transaction data  All logs (for example, transaction, history, …

Added p. 32

 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  Collection of sensitive authentication data only when needed to solve a specific problem.

Added p. 37

<Report Findings Here>  Instruction that if debugging logs are ever enabled and the logs include PAN, they must be protected in accordance with PCI DSS, disabled as soon as troubleshooting is complete and securely deleted when no longer needed.

Added p. 52

 Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here>

Added p. 56

<Report Findings Here> 3.1.9.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

<Report Findings Here> 3.1.11 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.

Added p. 60

 All application/service accounts have access to only those functions/resources For all types of changes performed, describe the account settings tested to verify that, upon completion of the change, all application/service accounts have:

Added p. 65

Describe the audit log output examined. <Report Findings Here> Describe the testing performed, including examination of audit log settings and audit log output, to verify that initialization of application audit logs is logged.

Added p. 73

 Code changes are reviewed by individuals other than the originating code author.  Code changes are reviewed by individuals who are knowledgeable in code review techniques.  Code changes are reviewed by individuals who are knowledgeable in secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines.  Appropriate corrections are implemented prior to release.  Code-review results are reviewed by management prior to release.  Code-review results are approved by management prior to release.

 Whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes.  Code changes are reviewed by individuals other than the originating code author.  Code changes are reviewed by individuals who are knowledgeable in code review techniques.  Code changes are reviewed by individuals who are knowledgeable in secure coding practices.  Code reviews ensure code is developed according to …

Added p. 78

<Report Findings Here> Identify the developers interviewed for this testing procedure. <Report Findings Here> For the interview, summarize the relevant details discussed that verify that training is updated as needed to address new development technologies and methods used.

Added p. 79

 Prevent cryptographic flaws.  Use strong cryptographic algorithms and keys.

Added p. 81

<Report Findings Here> 5.3 Software vendor must follow change-control procedures for all application changes. Change-control procedures must follow the same software development processes as new releases (as defined in PA-DSS Requirement 5.1), and include the following:

Added p. 90

 Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust boundaries.  Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.  Identification of all areas within payment applications that interact with PAN/SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.  A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, Identify the documented software-development procedures verified to contain risk assessment techniques, and verified to include processes for:

 Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust boundaries.  Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.  Identification of all areas within payment applications that interact with PAN/SAD or the …

Added p. 94

 Encryption keys were changed from default at installation.  Default SNMP community strings on wireless devices were changed at installation.  Default passwords/passphrases on access points were

Added p. 101

<Report Findings Here> 7.2.3 Provide instructions for customers about secure installation of patches and updates. ☐ ☐ ☐ 7.2.3 Examine the PA-DSS Implementation Guide prepared by the vendor to verify it includes the following information for customers and integrators/resellers:  How the vendor will communicate notifications of new patches and updates.  How patches and updates will be delivered in a secure manner with a known chain of trust.  How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.

 How the vendor will communicate notifications of new patches and updates.

<Report Findings Here>  How patches and updates will be delivered in a secure manner with a known chain of trust.

<Report Findings Here>  How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.

Added p. 103

<Report Findings Here> Describe the testing performed to verify that only necessary and secure services, protocols, daemons, components, dependent software and hardware are enabled by default “out of the box.” <Report Findings Here> 8.2.b Install the application and test application functions to verify that if the application supports any insecure services, daemons, protocols or components, they are securely configured by default “out of the box.” Provide the name of the PA-QSA who attests that the application was installed and application functions tested to verify that if the application supports any insecure services, daemons, protocols or components, they are securely configured by default “out of the box.” <Report Findings Here> 8.2.c Verify that the PA-DSS Implementation Guide documents all required protocols, Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include documentation of the following required or necessary for the functionality of the payment application, including those provided by …

Added p. 110

 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 (See PA-DSS Requirements 3.1.1 through 3.1.11)  Enable encrypted data transmission according to PA-DSS Requirement 12.1 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers that all remote access to the payment application must be implemented securely.

 Only trusted keys and certificates are accepted.  The protocol in use only supports secure versions or configurations.  The encryption strength is appropriate for the encryption methodology in use

Added p. 115

 Renders the PAN unreadable; OR <Report Findings Here>  Implements strong cryptography. <Report Findings Here> Describe how use of the solution is specified. <Report Findings Here> 11.2.b Examine PA-DSS Implementation Guide prepared by the vendor, and verify the vendor includes directions for customers and integrators/resellers to use a solution provided with or specified for use with the application, including:

<Report Findings Here> 12.2 Use multi-factor authentication for all personnel with non-console administrative access.

Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).

Aligns with PCI DSS Requirement 8.3 12.2.a Verify that multi-factor authentication is provided with the application, or that use thereof is specified.

Describe how review of the application as provided verified that multi-factor authentication is provided with the application, or that use thereof is specified.

<Report Findings Here> If multi-factor authentication is not provided with the …

Added p. 118

If multi-factor authentication is provided with the application, after installing the payment application in the lab, describe the testing performed to verify that the multi-factor authentication is applied before access is granted.

 At least annually <Report Findings Here>  Upon changes to the application <Report Findings Here>  Upon changes to these PA-DSS requirements <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm the PA-DSS Implementation Guide is reviewed  At least annually,  Upon changes to the application  Upon changes to these PA-DSS requirements <Report Findings Here> 13.1.3.b Verify the PA-DSS Implementation Guide is updated as needed to keep current with:

 Overall accountability for meeting all the requirements in PA-DSS  Keeping up-to-date within any changes in the PA-DSS Program Guide  Ensuring secure coding practices are followed  Ensuring integrators/resellers receive training and supporting materials  Ensuring all vendor personnel with PA-DSS responsibilities, …

Added p. 136

 How the vendor will communicate notifications of new patches and updates.

Added p. 136

 How patches and updates will be delivered in a secure manner with a known chain of trust.

 How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.

Software Vendor: Document and implement processes for communication, delivery and secure installation of patches and updates. Customers and Integrators/Resellers: Access and install patches and updates in a secure manner, in accordance with PA-DSS Implementation Guide.

Added p. 140

 Procedures for using the multi-factor authentication provided with the application (if provided).

 Instruction that multi-factor authentication must be used for all personnel with non-console administrative access to the CDE.

Added p. 140

Include instructions for customers and integrators/resellers to use multi-factor authentication, including:

Software Vendor: Ensure payment application provides or specifies use of multi-factor authentication for all personnel with non-console administrative access, per PA-DSS Requirement 12.2.

Customers & Integrators/Resellers: Use multi-factor authentication for all non-console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.2..

Modified p. 1

Payment Card Industry (PCI) Data Security Standard Payment Application Data Security Template for Report on Validation for use with PA-DSS ~~v3.1~~ Revision 1.0

Payment Card Industry (PCI) Data Security Standard Payment Application Data Security Template for Report on Validation for use with PA-DSS v3.2 Revision 1.0

Modified p. 5

Use of this Reporting Template is mandatory for all ~~v3.1~~ submissions.

Use of this Reporting Template is mandatory for all v3.2 submissions.

Modified p. 5

A PA-DSS compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …

Modified p. 9

 Use this Reporting Template, if assessing against ~~v3.1~~ of the PA- DSS.

 Use this Reporting Template, if assessing against v3.2 of the PA- DSS.

Removed p. 12

• Identify the types of transactions

• List any specific payment acceptance channels (for example, card present and card not present) the application is designed for

• Describe how the application stores, processes, or transmits cardholder data as part of authorization or settlement

• Describe how the payment application is sold, distributed, or licensed to third parties

Modified p. 12

 The type of application (for example, POS terminal, payment switch, shopping cart, kiosk, etc.)  Application Use and Purpose general description

 The type of application (for example, POS terminal, payment switch, shopping cart, kiosk, etc.)  Application Use and Purpose general description  Identify the types of transactions  List any specific payment acceptance channels (for example, card present and card not present) the application is designed for  Describe how the application stores, processes, or transmits cardholder data as part of authorization or settlement  Describe how the payment application is sold, distributed, or licensed to third parties

Modified p. 15

• The customer is clearly instructed how to implement the payment application in a PCI DSS compliant manner.

 The customer is clearly instructed how to implement the payment application in a PCI DSS compliant manner.

Modified p. 15

• The customer is clearly instructed that certain payment application and environment settings may prohibit their PCI DSS compliance.

 The customer is clearly instructed that certain payment application and environment settings may prohibit their PCI DSS compliance.

Modified p. 15

• Appropriate and accurate guidance is provided even when a specific setting cannot be controlled by the payment application vendor once the application is installed by the customer.

 Appropriate and accurate guidance is provided even when a specific setting cannot be controlled by the payment application vendor once the application is installed by the customer.

Modified p. 15

• Appropriate and accurate guidance is provided even when a specific setting is the responsibility of the customer, not the payment application vendor.

 Appropriate and accurate guidance is provided even when a specific setting is the responsibility of the customer, not the payment application vendor.

Modified p. 17

• Software vendor name:

 Software vendor name:

Modified p. 17

• Product version: (Only one version can be included per submission)  Provide a description of the payment application, including a description of the family of products.

 Product version: (Only one version can be included per submission)  Provide a description of the payment application, including a description of the family of products.

Modified p. 19

 Connections into and out of a customer’s network • All connections into and out of the network • All connections between the payment application and other applications, systems, networks or zones  Components within the customer’s network, including POS devices, systems, databases, and web servers as applicable • All critical components and systems, as well as their locations and the boundaries between them, including POS devices, systems, databases, web servers, and other components as applicable  Other necessary payment …

 Connections into and out of a customer’s network  All connections into and out of the network  All connections between the payment application and other applications, systems, networks or zones  Components within the customer’s network, including POS devices, systems, databases, and web servers as applicable  All critical components and systems, as well as their locations and the boundaries between them, including POS devices, systems, databases, web servers, and other components as applicable  Other necessary payment …

Removed p. 20

• LAN, WAN or Internet connections

• Host to host software communications

• Communications internal to the host

• Boundaries between trusted and untrusted components

• Connection methods and communication protocol

Modified p. 20

• All other connection points applicable to the assessment  Next, provide brief descriptions to illustrate each communication point:

 LAN, WAN or Internet connections  Host to host software communications  Communications internal to the host  All other connection points applicable to the assessment  Next, provide brief descriptions to illustrate each communication point:

Modified p. 20

• Identification of the communication endpoints (for example, POS terminal, database server, same-host reporting application, etc.)

 Identification of the communication endpoints (for example, POS terminal, database server, same-host reporting application, etc.)  Boundaries between trusted and untrusted components  Connection methods and communication protocol

Removed p. 21

• Authorization (yes/no)

• Settlement (yes/no)

Modified p. 21

• Chargeback (yes/no)  List any other data flows present, as applicable:

 Authorization (yes/no)  Capture (yes/no)  Settlement (yes/no)  Chargeback (yes/no)  List any other data flows present, as applicable:

Modified p. 21

• Describe how cardholder data is transmitted, processed and/or stored.

 Describe how cardholder data is transmitted, processed and/or stored.

Modified p. 21

• Identify the types of cardholder data involved (for example, full track, PAN, expiry date, etc.).

 Identify the types of cardholder data involved (for example, full track, PAN, expiry date, etc.).

Modified p. 21

• Describe any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to the cardholder data.

 Describe any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to the cardholder data.

Modified p. 21

• Identify the components involved in the transmission, processing or storage of cardholder data.

 Identify the components involved in the transmission, processing or storage of cardholder data.

Modified p. 21

• Include all types of data flows, including any involving hard copy / paper media.

 Include all types of data flows, including any involving hard copy / paper media.

Modified p. 24

• Describe the format of the version scheme, such as number of elements, number of digits used for each element, format of separators used between elements and character set used for each element (consisting of alphabetic, numeric and/or alphanumeric characters)  Describe the hierarchy of the elements:

 Describe the format of the version scheme, such as number of elements, number of digits used for each element, format of separators used between elements and character set used for each element (consisting of alphabetic, numeric and/or alphanumeric characters)  Describe the hierarchy of the elements:

Modified p. 24

• Define what each element represents in the version scheme.

 Define what each element represents in the version scheme.

Modified p. 24

• If wildcards are used in the versioning methodology, describe how wildcards are used. Note: All changes impacting security functionality and/or any PA-DSS requirements must result in a change to the version number listed on the PCI SSC website; wildcards are not permitted for changes which impact security functionality and/or any PA-DSS requirements.

 If wildcards are used in the versioning methodology, describe how wildcards are used. Note: All changes impacting security functionality and/or any PA-DSS requirements must result in a change to the version number listed on the PCI SSC website; wildcards are not permitted for changes which impact security functionality and/or any PA-DSS requirements.

Modified p. 25

 Provide a full list of all resellers and/or integrator for this product, if ~~applicable~~

 Provide a full list of all resellers and/or integrator for this product, if applicable:

Removed p. 27

• The accountholder’s name,

• Primary account number (PAN),

• Expiration date, and

Modified p. 27

• Service code To minimize risk, store only those data elements needed for business.

 The accountholder’s name,  Primary account number (PAN),  Expiration date, and  Service code To minimize risk, store only those data elements needed for business.

Removed p. 28

Aligns with PCI DSS Requirement 3.2.2 1.1.2 Install the payment application and perform numerous test transactions that simulate all Identify the test transactions observed for this testing procedure.

Modified p. 28 → 27

• Incoming transaction data • All logs (for example, transaction, history, debugging, error) • Non-volatile memory, including non-volatile cache

• Database contents Identify the test transactions observed for this testing procedure.

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Non-volatile memory, including non-volatile Identify the test transactions observed for this testing procedure.

Removed p. 29

• Incoming transaction data

• All logs (for example, transaction, history, debugging, error)

• Non-volatile memory, including non-volatile cache

• Incoming transaction data Identify the test transactions observed for this testing procedure.

Modified p. 29 → 28

~~• Database contents~~ Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

<Report Findings Here> Describe how test transactions observed simulate all functions of the payment application, including generation of error conditions and log entries.

Modified p. 29 → 28

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including non-volatile cache <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated by the payment application <Report Findings Here> 1.1.3 After authorization, do not store the personal identification number (PIN) …

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Non-volatile memory, including non-volatile cache <Report Findings Here>

Removed p. 30

• All logs (for example, transaction, history, debugging, error)

• Non-volatile memory, including non-volatile cache

Removed p. 30

• How to remove historical data.

• That such removal is absolutely necessary for PCI DSS compliance.

Modified p. 30 → 29

~~• Database contents~~ For each data source type below, summarize the specific examples of each data source type observed to confirm that PIN or encrypted PIN block is never stored after authorization. If that type of data source is not present, indicate that in the space.

<Report Findings Here> For each data source type below, summarize the specific examples of each data source type observed to confirm that PIN or encrypted PIN block is never stored after authorization. If that type of data source is not present, indicate that in the space.

Modified p. 30

• Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application).

 Historical data must be removed (track 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

Modified p. 30

<Report Findings Here>  Detailed procedures for removing historical data. <Report Findings Here>

<Report Findings Here>  Detailed procedures for removing historical data. <Report Findings Here>  That such removal is absolutely necessary for PCI DSS compliance.

Removed p. 31

<Report Findings Here> Identify the configuration documentation reviewed to verify the vendor provides a secure wipe tool or procedure to remove the data.

Modified p. 31

• Sensitive authentication data is collected only when needed to solve a specific problem • Such data is stored in a specific, known location with limited access • The minimum amount of data is collected as needed to solve a specific problem • Sensitive authentication data is encrypted with strong cryptography while stored • Data is securely deleted immediately after use, including from:

 Sensitive authentication data is collected only when needed to solve a specific problem  Such data is stored in a specific, known location with limited access  The minimum amount of data is collected as needed to solve a specific problem  Sensitive authentication data is encrypted with strong cryptography while stored  Data is securely deleted immediately after use, including from:

Modified p. 31

~~1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’~~ Identify the document that contains the software vendor’s procedures for troubleshooting customers’ problems.

Identify the document that contains the software vendor’s procedures for troubleshooting customers’ problems.

Removed p. 32

• 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

Modified p. 32 → 31

~~• Secure deletion of such data immediately after use~~ Indicate whether the software vendor’s procedures for troubleshooting customers’ problems allow any collection of sensitive authentication data (pre-authorization). (yes/no) If “no,” mark the remainder of 1.1.5.a as “not applicable.” <Report Findings Here> If “yes,” briefly describe how the documented procedures for troubleshooting customers’ problems ensure the following:

<Report Findings Here> Indicate whether the software vendor’s procedures for troubleshooting customers’ problems allow any collection of sensitive authentication data (pre-authorization). (yes/no) If “no,” mark the remainder of 1.1.5.a as “not applicable.” <Report Findings Here> If “yes,” briefly describe how the documented procedures for troubleshooting customers’ problems ensure the following:

Modified p. 32

<Report Findings Here>  Encryption of sensitive authentication data while stored. <Report Findings Here> ~~ Secure deletion of such data immediately after use. <Report Findings Here>~~

<Report Findings Here>  Encryption of sensitive authentication data while stored. <Report Findings Here>

Modified p. 33

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

 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. 33

 Collection of sensitive authentication data only when needed to solve a specific problem <Report Findings Here>  Storage of such data in a specific, known location with limited access <Report Findings Here>  Collection of only a limited amount of data needed to solve a specific problem <Report Findings Here>  Encryption of sensitive authentication data while stored <Report Findings Here>  ~~Secure~~ deletion of such data immediately after use <Report Findings Here>

 Collection of sensitive authentication data only when needed to solve a specific problem <Report Findings Here>  Storage of such data in a specific, known location with limited access <Report Findings Here>  Collection of only a limited amount of data needed to solve a specific problem <Report Findings Here>  Encryption of sensitive authentication data while stored <Report Findings Here>  cure deletion of such data immediately after use <Report Findings Here>

Modified p. 34

• Cardholder data exceeding the customer- defined retention period must be securely deleted • 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) • Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes • Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or …

 Cardholder data exceeding the customer- defined retention period must be securely deleted  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)  Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes  Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or …

Modified p. 35

<Report Findings Here> 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the ~~full~~ PAN.

<Report Findings Here> 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 35

• Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts. • Confirmation that the payment application masks PAN by default on all displays • Instructions for how to configure the payment application such that only personnel with a legitimate business need can see the full ~~PAN.~~

 Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts.  Confirmation that the payment application masks PAN by default on all displays  Instructions for how to configure the payment application such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN (includes displays of the full PAN).

Modified p. 35

<Report Findings Here>  Instructions for how to configure the payment application such that only personnel with a legitimate business need can see the full ~~PAN.~~

<Report Findings Here>  Instructions for how to configure the payment application such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN (includes displays of the full PAN).

Modified p. 36

<Report Findings Here> 2.2.c Configure the payment application according to the PA-DSS Implementation Guide to allow only personnel with a legitimate business need to see the ~~full~~ PAN. For each instance where PAN is displayed, examine application configurations and displays of PAN to verify that instructions for masking PAN are accurate, and that only personnel with a legitimate business need can see the ~~full~~ PAN.

<Report Findings Here> 2.2.c Configure the payment application according to the PA-DSS Implementation Guide to allow only personnel with a legitimate business need to see more than first six/last four digits of the PAN. For each instance where PAN is displayed, examine application configurations and displays of PAN to verify that instructions for masking PAN are accurate, and that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 36

Describe the application configurations examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the ~~full~~ PAN.

Describe the application configurations examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 36

<Report Findings Here> Describe the displays of PAN examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see the ~~full~~ PAN.

<Report Findings Here> Describe the displays of PAN examined to verify that instructions in the IG for masking PAN are accurate and that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 36

Notes: • It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls must be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Notes:  It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls must be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Modified p. 36

• The PAN must be rendered unreadable anywhere it is stored, even outside the payment application (for example, log files output by the application for storage in the customer environment).

 The PAN must be rendered unreadable anywhere it is stored, even outside the payment application (for example, log files output by the application for storage in the customer environment).

Modified p. 37

• Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1). • A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.

 Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).  A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.  …

Removed p. 38

• One-way hashes based on strong cryptography.

Removed p. 38

• One-way hashes based on strong cryptography

• One-way hashes based on strong cryptography

Modified p. 38

• Strong cryptography, with associated key- management processes and procedures Identify the method(s) below used to protect PAN:

 One-way hashes based on strong cryptography.  Truncation  Index tokens and pads, with the pads being securely stored  Strong cryptography, with associated key- management processes and procedures Identify the method(s) below used to protect PAN:

Modified p. 38

• Strong cryptography, with associated key-management processes and procedures <Report Findings Here> Identify the encryption algorithms (algorithm and key length) used (if applicable).

 One-way hashes based on strong cryptography  Truncation  Index tokens and pads, with the pads being securely stored  Strong cryptography, with associated key-management processes and procedures <Report Findings Here> Identify the encryption algorithms (algorithm and key length) used (if applicable).

Modified p. 38

• Strong cryptography, with associated key-management processes and procedures <Report Findings Here> 2.3.c If the application creates both hashed and truncated versions of the same PAN, examine methods for creating the hashed and truncated versions to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

 One-way hashes based on strong cryptography  Truncation  Index tokens and pads, with the pads being securely stored  Strong cryptography, with associated key-management processes and procedures <Report Findings Here> 2.3.c If the application creates both hashed and truncated versions of the same PAN, examine methods for creating the hashed and truncated versions to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Removed p. 40

• Keys are stored in encrypted format.

• Key-encrypting keys are stored separately from data-encrypting keys.

• Store keys securely in the fewest possible locations and forms.

Modified p. 40

• Key-encrypting keys are at least as strong as the data encrypting keys they protect.

 Keys are stored in encrypted format.  Key-encrypting keys are stored separately from data-encrypting keys.  Key-encrypting keys are at least as strong as the data encrypting keys they protect.

Modified p. 40

• Restrict access to keys to the fewest number of custodians necessary.

 Restrict access to keys to the fewest number of custodians necessary.  Store keys securely in the fewest possible locations and forms.

Removed p. 41

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

Modified p. 41

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

 How to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers 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.

Removed p. 42

• Procedures for enforcing key changes at the end of the defined cryptoperiod.

Modified p. 42

• Defined cryptoperiod for each key type used by the application.

 Defined cryptoperiod for each key type used by the application.  Procedures for enforcing key changes at the end of the defined cryptoperiod.

Modified p. 43

• Instructions that keys must be retired or • replaced when the integrity of the key has been weakened, or there is a known or suspected compromise of a key. • Procedures for retiring or replacing keys (for example: by archiving, destruction, and/or revocation as applicable). • Procedures for ensuring that retired or • replaced cryptographic keys are not used for encryption operations.

 Instructions that keys must be retired or replaced when the integrity of the key has been weakened, or there is a known or suspected compromise of a key.  Procedures for retiring or replacing keys (for example: by archiving, destruction, and/or revocation as applicable).  Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.

Modified p. 43

<Report Findings Here> 2.5.5.b Test the application, including the methods for retiring or replacing cryptographic keys, to verify that the instructions in the ~~PA-DSS~~ Implementation Guide result the retirement or replacement of keys (for example: by archiving, destruction, and/or revocation as applicable).

<Report Findings Here> 2.5.5.b Test the application, including the methods for retiring or replacing cryptographic keys, to verify that the instructions in the PA- DSS Implementation Guide result the retirement or replacement of keys (for example: by archiving, destruction, and/or revocation as applicable).

Removed p. 45

• Instructions for enforcing split knowledge and dual control for all such operations.

Modified p. 45

• Details of any manual clear-text cryptographic key-management operations supported by the application.

 Details of any manual clear-text cryptographic key-management operations supported by the application.  Instructions for enforcing split knowledge and dual control for all such operations.

Modified p. 46

• Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable. • That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key- management requirements in PCI DSS. • Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

 Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.  That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key- management requirements in PCI DSS.  Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

Modified p. 46

• Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.

 Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable.

Modified p. 46

• That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key-management requirements in PCI DSS.

<Report Findings Here>  That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key-management requirements in PCI DSS.

Modified p. 46

• Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

<Report Findings Here>  Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption /re-encryption process.

Modified p. 48

• Provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, by: - Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11. - Enforcing secure changes for any subsequent changes (after installation) to authentication credentials per Requirements 3.1.1 through 3.1.11.

 Provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, by: - Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11. - Enforcing secure changes for any subsequent changes (after installation) to authentication credentials per Requirements 3.1.1 through 3.1.11.

Removed p. 49

• Advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.

• Advised to assign secure authentication to all default accounts in the environment.

• For any default accounts that won’t be used, assign secure authentication and then disable or do not use that accounts.

• Provided clear and unambiguous directions for all authentication credentials used by the payment application (but which are not generated or managed by the application), on how, by the completion of installation and for any changes after installation, to change authentication credentials and create strong authentication per Requirements 3.1.1 through 3.1.11 below, for all application level and user accounts with administrative access and for all accounts with access to cardholder data.

Aligns with PCI DSS Requirement 2.1 3.1.1 Install and configure the payment application in accordance with …

Modified p. 49

 Customers and integrators/resellers are advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Secure authentication should be assigned to all default accounts in the environment.  For any default accounts that won’t be used, assign secure authentication and then disable or do not use the account.

 Customers and integrators/resellers are advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Secure authentication should be assigned to all default accounts in the environment.  For any default accounts that won’t be used, assign secure authentication and then disable or do not use the account.  Identification of all roles and default accounts within …

Removed p. 50

<Report Findings Here> 3.1.3 The payment application assigns unique IDs for user accounts.

Modified p. 50

Describe the testing performed to verify that the payment application does not require the use of default administrative accounts for other necessary software <Report Findings Here> 3.1.2 The application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after installation. This applies to all accounts, including user accounts, application and service accounts, and accounts used by the vendor for support …

Describe the testing performed to verify that the payment application does not use default administrative accounts for other necessary software <Report Findings Here> Describe the testing performed to verify that the payment application does not require the use of default administrative accounts for other necessary software <Report Findings Here> 3.1.2 The application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent …

Modified p. 50 → 51

Aligns with PCI DSS Requirements 8.1.1 3.1.3 For all accounts that are generated or managed by the application, test the application as follows: ☐ ☐ ☐

Aligns with PCI DSS Requirements 8.1.1 3.1.3 For all accounts that are generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.3.a Install the payment application in accordance with the PA-DSS Implementation Guide and attempt to create different application accounts with the same user ID to verify that the payment application only assigns unique user IDs by completion of the installation process.

Removed p. 51

• Something you know, such as a password or passphrase

• Something you have, such as a token device or smart card

Modified p. 51

• Something you are, such as a biometric Aligns with PCI DSS Requirements 8.2 3.1.4 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and test authentication methods to verify that the application requires at least one of the defined authentication methods for all accounts by completion of the installation process.

 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.4 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and test authentication methods to verify that the application requires at least one of …

Modified p. 52

Describe the application functionality testing performed to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

<Report Findings Here> Describe the application functionality testing performed to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion of the change.

Modified p. 52

• Generic accounts and passwords. <Report Findings Here> Describe the testing of application functionality performed to verify that, by completion of the installation process, the application does not require or use:

 Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here> Describe the testing of application functionality performed to verify that, by completion of the installation process, the application does not require or use:

Modified p. 52 → 53

• Generic accounts and passwords. <Report Findings Here> Describe the application functionality testing performed to verify that, upon completion of the change, the application does not rely on or use:

 Any group accounts and passwords. <Report Findings Here>  Shared account s and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here> Describe the application functionality testing performed to verify that, upon completion of the change, the application does not rely on or use:

Removed p. 53

• Shared accounts and passwords. <Report Findings Here>

• Require a minimum length of at least seven characters

• Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

<Report Findings Here> 3.1.6.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that, upon completion of the change, the application requires passwords to require a minimum of the following complexity and strength:

• Be at least seven characters in length.

• Passwords to contain both numeric and alphabetic characters.

• Passwords to contain both numeric and alphabetic characters.

Modified p. 53

• Generic accounts and passwords. <Report Findings Here> 3.1.6 The payment application requires that passwords meet the following:

 Any group accounts and passwords. <Report Findings Here>  Shared accounts and passwords. <Report Findings Here>  Generic accounts and passwords. <Report Findings Here> 3.1.6 The payment application requires that passwords meet the following:

Modified p. 53

• Contain both numeric and alphabetic characters Alternatively, the ~~passwords/phrase~~ must have complexity and strength at least equivalent to the parameters specified above.

 Require a minimum length of at least seven characters  Contain both numeric and alphabetic characters Alternatively, the password/passphrase must have complexity and strength at least equivalent to the parameters specified above.

Modified p. 53

• Be at least seven characters in length.

 Be at least seven characters in length.  Contain both numeric and alphabetic characters.

Modified p. 53 → 54

~~• Passwords to contain~~ both numeric and alphabetic characters.

 Be at least seven characters in length.  Contain both numeric and alphabetic characters.

Modified p. 53 → 54

~~<Report Findings Here>~~ Describe how account settings were tested to verify that upon completion of the change, the application requires:

Describe how account settings were tested to verify that upon completion of the change, the application requires:

Modified p. 54 → 55

~~<Report Findings Here>~~ Describe how account settings were tested to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.

Describe how account settings were tested to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.

Removed p. 55

<Report Findings Here> 3.1.9 The payment application limits repeated access attempts by locking out the user account after not more than six logon attempts.

Modified p. 55

3.1.8.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that, by completion of the installation process, the application keeps password history and requires that a new password is different than any of the last four passwords used.

Aligns with PCI DSS Requirement 8.2.5 3.1.8 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.8.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that, by completion of the installation process, the application keeps password history and requires that a new password is different than any of the last four passwords used.

Modified p. 55

<Report Findings Here> 3.1.8.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine account settings and test application functionality to verify that the application keeps password history and requires that a new password is different than any of the last four passwords used, upon completion of the change.

<Report Findings Here> 3.1.8.b Test all application functionality that results in user accounts reverting to default settings, changes to existing account configurations, generation of new accounts and recreation of existing accounts.

Modified p. 55 → 56

Aligns with PCI DSS Requirement 8.1.6 3.1.9 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 8.1.6 3.1.9 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.9.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that, by completion of the installation process, the application locks out user accounts after not more than six invalid logon attempts.

Modified p. 55 → 56

~~<Report Findings Here> 3.1.9.b Test all application functionality that results in user accounts reverting to default~~ For the testing of all types of changes performed (as identified in 3.1.2.b), identify the account settings examined.

For the testing of all types of changes performed (as identified in 3.1.2.b), identify the account settings examined.

Modified p. 56

Describe how account settings were tested to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

<Report Findings Here> Describe how account settings were tested to verify that the application locks out user accounts after not more than six invalid logon attempts, upon completion of the change.

Modified p. 56

Aligns with PCI DSS Requirement 8.1.7 3.1.10 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 8.1.7 3.1.10 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.10.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that, by completion of the installation process, the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Modified p. 56 → 57

~~<Report Findings Here>~~ Describe how account settings were tested to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

Describe how account settings were tested to verify that the application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID, upon completion of the change.

Modified p. 57

Aligns with PCI DSS Requirement 8.1.8 3.1.11 For all accounts generated or managed by the application, test the application as follows:

Aligns with PCI DSS Requirement 8.1.8 3.1.11 For all accounts generated or managed by the application, test the application as follows: ☐ ☐ ☐ 3.1.11.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that, by completion of the installation process, the application sets a session idle time out to 15 minutes or less.

Modified p. 57 → 58

Aligns with PCI DSS Requirement 8.2.1

Aligns with PCI DSS Requirement 8.2.1 3.3 Perform the following:

Removed p. 58

• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

Modified p. 58 → 59

• Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

 Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.  A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

Modified p. 58 → 59

• Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.

 Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.  A unique input variable is concatenated with each password before the cryptographic algorithm is applied.

Removed p. 59

<Report Findings Here> 3.4 Payment application must limit access to required functions/resources and enforce least privilege for built-in accounts:

• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 59 → 60

• By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

 By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

Modified p. 59 → 60

• By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

 By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 59 → 60

• All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.

 All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.  All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 59 → 60

<Report Findings Here> 3.4.1.b Test all application functionality that results in changes to built-in accounts, including those that result in user accounts reverting to default settings, changes to existing account For all types of changes performed, ~~describe the account~~ settings ~~tested~~ to verify ~~that,~~ upon completion of the ~~change, all application/service accounts have:~~

<Report Findings Here> 3.4.1.b Test all application functionality that results in changes to built-in accounts, including those that result in user accounts reverting to default settings, changes to existing account settings, generation of new accounts and recreation of existing accounts. For all types of changes performed, examine settings for built-in accounts and test application functionality to verify that upon completion of the change:

Removed p. 60

• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 60

~~• All application/service accounts have access to only those functions/resources specifically~~ needed for ~~purpose of~~ the application/service account.

<Report Findings Here>  Minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 60 → 61

~~<Report Findings Here>~~  Minimum level of privilege assigned for each function/resource as needed for the application/service account.

 Minimum level of privilege assigned for each function/resource as needed for the application/service account.

Modified p. 61 → 62

• How to install the application so that logs are configured and enabled by default upon completion of the installation process. • How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 below, for any logging options that are configurable by the customer after installation. • Logs should not be disabled and doing so will result in non-compliance with PCI DSS. • How to configure PCI DSS-compliant log settings for any third-party software components packaged with …

 How to install the application so that logs are configured and enabled by default upon completion of the installation process.  How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 below, for any logging options that are configurable by the customer after installation.  Logs should not be disabled and doing so will result in non-compliance with PCI DSS.  How to configure PCI DSS-compliant log settings for any third-party software components packaged with …

Removed p. 63

• Initialization of application audit logs.

• Stopping or pausing of application audit Identify the payment application audit log settings examined.

Modified p. 63 → 64

<Report Findings Here> 4.2.6 Initialization, stopping or pausing of the application audit logs ☐ ☐ ☐ 4.2.6 Verify the following are logged:

<Report Findings Here> 4.2.6 Initialization, stopping or pausing of the application audit logs ☐ ☐ ☐ 4.2.6 Verify the following are logged: Identify the payment application audit log settings examined.

Removed p. 64

<Report Findings Here> 4.3.2 Type of event ☐ ☐ ☐ 4.3.2 Verify type of event is included in log entries.

Modified p. 64 → 66

<Report Findings Here> Describe the audit log output examined. <Report Findings Here>

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that type of event is included in log entries.

Modified p. 65 → 66

<Report Findings Here> Describe the audit log output examined. <Report Findings Here> For each auditable event from 4.2.1-4.2.7, describe the testing performed, including examination of audit log settings and audit log output, to verify that origination of event is included in log entries.

<Report Findings Here> Describe the audit log output examined. <Report Findings Here>

Modified p. 65 → 67

<Report Findings Here> 4.3.6 Identity or name of affected data, system component, or resource ☐ ☐ ☐

<Report Findings Here> 4.3.6 Identity or name of affected data, system component, or resource ☐ ☐ ☐ 4.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.

Removed p. 66

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

• A description of which centralized logging mechanisms are supported.

Modified p. 66 → 67

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

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

Modified p. 66 → 67

• Instructions and procedures for incorporating the payment application logs into a centralized logging environment.

 A description of which centralized logging mechanisms are supported.  Instructions and procedures for incorporating the payment application logs into a centralized logging environment.

Modified p. 66 → 67

<Report Findings Here> 4.4.b Install and configure the payment application according to the PA-DSS Implementation Guide to verify that the instructions are accurate, and that functionality that ~~facilitates a customer’s ability~~ to ~~assimilate logs into their centralized log server is provided.~~

<Report Findings Here> 4.4.b Install and configure the payment application according to the PA-DSS Implementation Guide to verify that the instructions are accurate, and that functionality Provide the name of the PA-QSA who attests that after installing and configuring the payment application according to the PA-DSS Implementation Guide, the following was verified to be true:

Modified p. 66 → 68

~~<Report Findings Here>~~  Functionality that facilitates a customer’s ability to assimilate logs into their centralized log server is provided.

 Functionality that facilitates a customer’s ability to assimilate logs into their centralized log server is provided.

Removed p. 67

• Developing payment applications in accordance with PCI DSS and PA-DSS Requirements.

• Developing payment applications in accordance with PA-DSS Requirements.

• Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.

• Procedures for security reviews to be performed, to ensure the security objectives of PCI DSS and PA-DSS are being met.

Modified p. 67 → 69

• Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging). • Development processes are based on industry standards and/or best practices. • Information security is incorporated throughout the software development life cycle. • Security reviews are performed prior to release of an application or application update.

 Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging).  Development processes are based on industry standards and/or best practices.  Information security is incorporated throughout the software development life cycle.  Security reviews are performed prior to release of an application or application update.

Modified p. 67 → 69

• Incorporating information security throughout the software development life cycle.

 Incorporating information security throughout the software development life cycle.  Developing payment applications in accordance with PCI DSS and PA-DSS Requirements.

Modified p. 67 → 69

• Incorporating information security throughout the software-development life cycle.

 Incorporating information security throughout the software-development life cycle.  Developing payment applications in accordance with

Modified p. 67 → 69

• Developing payment applications in accordance with ~~PCI DSS~~ Requirements.

PCI DSS Requirements.  Developing payment applications in accordance with PA-DSS Requirements.

Modified p. 67 → 69

• Defined security reviews prior to release of an application or application update.

 Defined security reviews prior to release of an application or application update.  Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.

Modified p. 67 → 69

• Defined security reviews during the development process and prior to release of an application or application update.

 Defined security reviews during the development process and prior to release of an application or application update.  Procedures for security reviews to be performed, to ensure the security objectives of PCI DSS and PA-DSS are being met.

Removed p. 68

• Procedures to ensure live PANs are not used for development.

• Development <Report Findings Here> 5.1.1.c Examine samples of test data to verify live PANs are not used for testing or Describe the samples of test data examined to verify that:

Modified p. 68 → 70

• Information security is incorporated throughout the software development life cycle. • Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements. • Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

 Information security is incorporated throughout the software development life cycle.  Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.  Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

Modified p. 68 → 70

• Information security is incorporated throughout the software development life cycle. • Payment applications are developed in accordance with PCI DSS Requirements. • Payment applications are developed in accordance with PA-DSS Requirements. • Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

 Information security is incorporated throughout the software development life cycle.  Payment applications are developed in accordance with PCI DSS Requirements.  Payment applications are developed in accordance with PA-DSS Requirements.  Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.

Modified p. 68 → 70

• Procedures to ensure live PANs are not used for testing.

 Procedures to ensure live PANs are not used for testing.  Procedures to ensure live PANs are not used for development.

Modified p. 68 → 70

 Live PANs are not used for testing. <Report Findings Here>  Live PANs are not used for development. <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm that live PANS are not used for

 Live PANs are not used for testing. <Report Findings Here>  Live PANs are not used for development. <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm that live PANS are not used for  Testing  Development <Report Findings Here> Describe the samples of test data examined to verify that:

Removed p. 69

• removed before the payment application is released to customers.

Modified p. 69 → 71

• To ensure test data is • removed before the payment application is released to customers. • To ensure accounts are • removed before the payment application is released to customers.

 To ensure test data is removed before the payment application is released to customers.  To ensure accounts are removed before the payment application is released to customers.

Modified p. 69 → 71

• removed before the payment application is released to customers.

 Test data is removed before the payment application is released to customers.  Test accounts are removed before the payment application is released to customers.

Modified p. 70 → 72

• To ensure custom payment application accounts are • removed before payment application is released to customers. • To ensure user IDs are • removed before payment application is released to customers. • To ensure passwords are • removed before payment application is released to customers.

 To ensure custom payment application accounts are removed before payment application is released to customers.  To ensure user IDs are removed before payment application is released to customers.  To ensure passwords are removed before payment application is released to customers.

Modified p. 70 → 72

• Custom payment application accounts are • removed before the payment application is released to customers. • removed before the payment application is released to customers. • removed before the payment application is released to customers.

 Custom payment application accounts are removed before the payment application is released to customers.  User IDs are removed before the payment application is released to customers.  Passwords are removed before the payment application is released to customers.

Removed p. 71

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

Removed p. 71

• Code-review results are reviewed and approved by management prior to release.

• Code changes are reviewed by individuals other than the originating code author.

• Code changes are reviewed by individuals who are knowledgeable in code review techniques.

• Code changes are reviewed by individuals who are knowledgeable in secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines.

• Code-review results are reviewed by management prior to release.

• Code-review results are approved by management prior to release.

Modified p. 71 → 73

• 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-review results are reviewed and approved by management prior to release. • Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior …

 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-review results are reviewed and approved by management prior to release.  Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior …

Modified p. 71 → 73

• Code-review results are documented including management approval, code ~~author and code reviewer and what~~ Indicate whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes. (manual/automated) <Report Findings Here> Identify the documented software-development processes reviewed and verified to include procedures for the following:

 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-review results are reviewed and approved by management prior to release.  Code-review results are documented including management approval, code Indicate whether the vendor uses a manual or automated …

Removed p. 72

• Code changes are reviewed by individuals other than the originating code author.

• Code changes are reviewed by individuals who are knowledgeable in code review techniques.

• Code changes are reviewed by individuals who are knowledgeable in secure coding practices.

• Code reviews ensure code is developed according to secure coding guidelines.

• Code-review results are reviewed by management prior to release.

• Code-review results are approved by management prior to release.

• Whether the vendor uses a manual or automated process to perform code reviews for all significant application code changes.

Modified p. 72 → 74

• Code reviews were performed by a knowledgeable individual other than the code author. • Code reviews were developed according to secure coding guidelines. • Appropriate corrections were implemented prior to release. • Code-review results were reviewed and approved by management prior to release.

 Code reviews were performed by a knowledgeable individual other than the code author.  Code reviews were developed according to secure coding guidelines.  Appropriate corrections were implemented prior to release.  Code-review results were reviewed and approved by management prior to release.

Removed p. 73

• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).

Modified p. 73 → 76

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

 Developing with least privilege for the application environment.  Developing with fail-safe default (all execution is by default denied unless specified within initial design).  Developing for all access point considerations, including input variances such as multi-channel input to the application.

Removed p. 74

• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).

• Developing with fail-safe default (all execution is by default denied unless specified within initial design).

• Developing with fail-safe default (all execution is by default denied unless specified within initial design).

Modified p. 74 → 75

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

 Developing with least privilege for the application environment.  Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).  Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 74 → 76

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

 Developing with least privilege for the application environment.  Developing with fail-safe default (all execution is by default denied unless specified within initial design).  Developing for all access point considerations, including input variances such as multi-channel input to the application.

Modified p. 74 → 76

• Developing for all access point considerations, including input variances such as multi-channel input to the application.

 Developing with least privilege for the application environment.  Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).  Developing for all access point considerations, including input variances such as multi-channel input to the application.

Removed p. 75

• Secure application design

• Managing sensitive data in memory

• Security testing (for example, penetration-testing techniques)

• Risk-assessment techniques

Modified p. 75 → 77

• Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.)

 Secure application design  Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.)  Managing sensitive data in memory  Code reviews  Security testing (for example, penetration-testing techniques)  Risk-assessment techniques

Modified p. 75 → 77

~~5.1.7a~~ Verify documented software-development processes require training in secure development practices for application developers as applicable for the developer’s job function and technology used.

5.1.7.a Verify documented software-development processes require up-to-date training in secure development practices for application developers at least annually, as applicable for the developer’s job function and technology used.

Modified p. 75 → 77

Identify the documented software-development processes reviewed to verify that processes require training in secure development practices for application developers as applicable for the developer’s job function and technology used.

Identify the documented software-development processes reviewed to verify that processes require up-to-date training in secure development practices for application developers at least annually, as applicable for the developer’s job function and technology used.

Modified p. 75 → 77

<Report Findings Here> 5.1.7.c Examine records of training to verify that all application developers receive training as applicable for their job function and technology used.

<Report Findings Here> 5.1.7.c Examine records of training to verify that all application developers receive training at least annually, as applicable for their job function and technology used.

Modified p. 75 → 77

Identify the sample of records of training examined <Report Findings Here> Describe how the sample of records of training was examined to verify that all application developers receive training as applicable for their job function and technology used.

Identify the sample of records of training examined <Report Findings Here> Describe how the sample of records of training was examined to verify that all application developers receive training at least annually, as applicable for their job function and technology used.

Modified p. 75 → 77

<Report Findings Here> 5.1.7.1 Update training as needed to address new development technologies and methods used. ☐ ☐ ☐ 5.1.7.1 Examine training materials and interview a sample of developers to verify that training is updated as needed to address new development Identify the training material examined to verify that training is updated as needed to address new development technologies and methods used.

<Report Findings Here> 5.1.7.1 Update training as needed to address new development technologies and methods used. ☐ ☐ ☐

Removed p. 76

• Utilizing parameterized queries.

• Truncating input strings.

• Prevent cryptographic flaws.

Modified p. 76 → 78

• Validating input to verify user data cannot modify meaning of commands and queries.

 Validating input to verify user data cannot modify meaning of commands and queries.  Utilizing parameterized queries.

Modified p. 76 → 78

• Validating buffer boundaries.

 Validating buffer boundaries.  Truncating input strings.

Modified p. 76 → 78

Describe how the penetration testing results verified that buffer overflows are addressed by coding techniques that include  Validating buffer boundaries. <Report Findings Here>  Truncating input strings. <Report Findings Here> 5.2.3 Insecure cryptographic storage ☐ ☐ ☐ ~~5.2.3 Insecure cryptographic storage is addressed by coding techniques that:~~

Describe how the penetration testing results verified that buffer overflows are addressed by coding techniques that include  Validating buffer boundaries. <Report Findings Here>  Truncating input strings. <Report Findings Here> 5.2.3 Insecure cryptographic storage ☐ ☐ ☐

Removed p. 77

• Use strong cryptographic algorithms and keys.

• Validating all parameters before inclusion

Modified p. 77 → 79

 Use strong cryptographic algorithms and keys. <Report Findings Here> 5.2.4 Insecure communications ☐ ☐ ☐ 5.2.4 Insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

 Prevent cryptographic flaws. <Report Findings Here>  Use strong cryptographic algorithms and keys. <Report Findings Here> 5.2.4 Insecure communications ☐ ☐ ☐ 5.2.4 Insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Modified p. 77 → 80

• Utilizing context-sensitive escaping Indicate whether the payment application is web-based and/or includes web-based application interfaces (internal or external). (yes/no) If “no,” mark 5.2.7-5.2.10 as “not applicable.” <Report Findings Here> Describe how the penetration testing results verified that cross-site scripting (XSS) is addressed by coding techniques that include:

 Validating all parameters before inclusion  Utilizing context-sensitive escaping Indicate whether the payment application is web-based and/or includes web-based application interfaces (internal or external). (yes/no) If “no,” mark 5.2.7-5.2.10 as “not applicable.” <Report Findings Here> Describe how the penetration testing results verified that cross-site scripting (XSS) is addressed by coding techniques that include:

Modified p. 77 → 80

 Validating all parameters before inclusion. <Report Findings Here>  Utilizing context-sensitive escaping. <Report Findings Here> 5.2.8 Improper access control such as insecure direct object references, failure to restrict URL access, and directory traversal ☐ ☐ ☐

 Validating all parameters before inclusion. <Report Findings Here>  Utilizing context-sensitive escaping. <Report Findings Here> 5.2.8 Improper access control such as insecure direct object references, failure to restrict URL access, and directory traversal ☐ ☐ ☐ 5.2.8 Improper access control, such as insecure direct object references, failure to restrict URL access, and directory traversal is addressed by coding technique that include:

Removed p. 78

• Proper authentication of users.

• Not exposing internal object. references to users.

• Flagging session tokens (for example cookies) as “secure.”

• Not exposing session IDs in the URL.

Modified p. 78 → 80

• User interface does not permit. access to unauthorized functions.

 Proper authentication of users.  Sanitizing input.  Not exposing internal object. references to users.  User interface does not permit. access to unauthorized functions.

Modified p. 78 → 80

<Report Findings Here> 5.2.10 Broken Authentication and session management ☐ ☐ ☐ ~~5.2.10 Broken authentication and session management is addressed via coding techniques that commonly include:~~

<Report Findings Here> 5.2.10 Broken Authentication and session management ☐ ☐ ☐

Modified p. 78 → 81

• Incorporating appropriate time-outs and rotation of session IDs after a successful login.

 Flagging session tokens (for example cookies) as “secure.”  Not exposing session IDs in the URL.  Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Removed p. 79

• Documentation of impact.

• Documented approval of change by appropriate authorized parties.

• Back-out or product de-installation procedures.

Modified p. 79 → 81

• Verify the procedures follow documented software-development processes as defined in Requirement 5.1.

 Verify the procedures follow documented software-development processes as defined in Requirement 5.1.  Verify that the procedures require items 5.3.1•5.3.4 below.

Modified p. 79 → 81

• Verify that the procedures require items 5.3.1

•5.3.4 below.

• Payment applications are developed in accordance with PCI DSS and PA-DSS. • Development processes are based on industry standards and/or best practices. • Information security is incorporated throughout the software development life cycle. • Security reviews are performed prior to release of an application or application update.

 Payment applications are developed in accordance with PCI DSS and PA-DSS.  Development processes are based on industry standards and/or best practices.  Information security is incorporated throughout the software development life cycle.  Security reviews are performed prior to release of an application or application update.

Modified p. 79 → 81

• Functionality testing to verify that the change does not adversely impact the security of the system.

 Documentation of impact.  Documented approval of change by appropriate authorized parties.  Functionality testing to verify that the change does not adversely impact the security of the system.  Back-out or product de-installation procedures.

Modified p. 79 → 82

<Report Findings Here> 5.3.1 Documentation of impact ☐ ☐ ☐

<Report Findings Here> 5.3.1 Documentation of impact ☐ ☐ ☐ 5.3.1 Verify that documentation of customer impact is included in the change-control documentation for each change.

Removed p. 80

<Report Findings Here> 5.4 The payment application vendor must document and follow a software-versioning methodology as part of their system development lifecycle. The methodology must follow the procedures in the PA-DSS Program Guide for changes to payment applications and include at least the following: ☐ ☐ ☐

• Include the software vendor’s versioning methodology.

• Be in accordance with the PA-DSS Program Guide.

• Details of how the elements of the version scheme are in accordance with requirements specified in the PA-DSS Program Guide.

Modified p. 81 → 83

• Be required to be followed for the payment application, including all changes to the payment application.

 Include the software vendor’s versioning methodology.  Be in accordance with the PA-DSS Program Guide.  Be required to be followed for the payment application, including all changes to the payment application.

Modified p. 81 → 83

• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters) • Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.) • Definition of elements that indicate use of wildcards

 Details of how the elements of the version scheme are in accordance with requirements specified in the PA-DSS Program Guide.  The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters)  Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.)  Definition of elements that indicate use of wildcards

Modified p. 81 → 83

• Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide. • The format of the version numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of Identify the document reviewed that verified the documented versioning methodology includes  Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.

 Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.  The format of the version numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of Identify the document reviewed that verified the documented versioning methodology includes  Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.

Removed p. 82

• A definition of what each element represents in the version-numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.).

• Definition of elements that indicate use of wildcards.

Removed p. 83

• Specific identification and definition of changes that:

• How each type of change ties to a specific version number 5.4.2.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:

• Specific identification and definition for changes that:

• Specific identification and definition for changes that:

• How each type of change ties to a specific version number.

Modified p. 83 → 85

• Descriptions of all types and impacts of application changes

 Descriptions of all types and impacts of application changes  Specific identification and definition of changes that:

Modified p. 83 → 85

• Have impact to any security functionality or PA-DSS requirement.

• Have impact to any security functionality or PA-DSS requirement.  How each type of change ties to a specific version number 5.4.2.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:

Modified p. 83 → 85

• Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application)

 Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application)  Specific identification and definition for changes that:

Modified p. 83 → 85

• Have impact to any security functionality or PA-DSS requirement.

• Have impact to any security functionality or PA-DSS requirement.  How each type of change ties to a specific version number.

Modified p. 83 → 85

• Description of all types and impacts of application changes.

 Description of all types and impacts of application changes.  Specific identification and definition for changes that:

Modified p. 83 → 85

• How each type of change ties to a specific version number.

 How each type of change ties to a specific version number.

Removed p. 84

• How the version number

• changed (what the version number was and what it

Modified p. 84 → 86

• How that version number change matches the category of change made to the payment application, according to the documented methodology.

 How the version number changed (what the version number was and what it changed to).  How that version number change matches the category of change made to the payment application, according to the documented methodology.

Removed p. 85

• Details of how wildcards are used in the versioning methodology

• Wildcards are never used for any change that has an impact on security or any PA-DSS requirements

Modified p. 85 → 87

• Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change • Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes.

 Details of how wildcards are used in the versioning methodology  Wildcards are never used for any change that has an impact on security or any PA-DSS requirements  Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change  Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not …

Modified p. 85 → 87

• Details of how wildcards are used in the versioning methodology. • Wildcards are never used for any change that has an impact on security or any PA- DSS requirements. • Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change. • Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must …

 Details of how wildcards are used in the versioning methodology.  Wildcards are never used for any change that has an impact on security or any PA- DSS requirements.  Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.  Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must …

Modified p. 85 → 87

• Details of how wildcards are used in the versioning methodology. • Wildcards are never used for any change that has an impact on security or any PA-DSS requirements. • Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change. • Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must appear …

 Details of how wildcards are used in the versioning methodology.  Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.  Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.  Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must appear …

Removed p. 86

• Wildcards are never used for any change that has an impact on security or any PA- DSS requirements.

• Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.

• Wildcards are not used for any change that has an impact on security or any PA-DSS requirements.

Modified p. 86 → 88

• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

 Wildcards are never used for any change that has an impact on security or any PA- DSS requirements.  Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

Modified p. 86 → 88

• Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

 Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.  Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never used to represent a security impacting change.

Modified p. 86 → 88

• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.

 Wildcards are not used for any change that has an impact on security or any PA-DSS requirements.  Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.

Modified p. 86 → 88

~~• Details of versioning scheme, including the format of the version scheme (number of~~ Identify the page number(s)/section of the PA-DSS Implementation Guide that include:

Identify the page number(s)/section of the PA-DSS Implementation Guide that include:

Removed p. 87

• Details of how security-impacting changes will be indicated by the version scheme.

• Details of how other types of changes will affect the version.

• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security- impacting change.

Modified p. 87 → 89

<Report Findings Here> 5.4.6.b Interview software developers and observe processes to verify that application ~~updates are reviewed for conformity with the~~ Identify the software developers interviewed who confirm application updates are reviewed for conformity with the versioning methodology prior to release.

<Report Findings Here> 5.4.6.b Interview software developers and observe processes to verify that application Identify the software developers interviewed who confirm application updates are reviewed for conformity with the versioning methodology prior to release.

Removed p. 88

• Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust- boundaries.

Removed p. 88

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each Identify the documented software-development procedures verified to contain risk assessment techniques, and verified to include processes for:

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each.

Modified p. 88 → 90

• Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data. • A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.

 Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust- boundaries.  Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.  Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.  A list of potential threats and …

Removed p. 89

• A list of potential threats and vulnerabilities resulting from cardholder data-flow analyses, and assign risk ratings (e.g., high, medium, or low priority) to each.

Removed p. 90

• Confirmation that secure development processes were followed by the vendor.

• Confirmation that all SDLC processes were followed.

• Formal approval and signature by an authorized party.

• Confirmation that that all secure development processes were followed.

Modified p. 90 → 92

• Signature by an authorized party to formally approve release of the application or application update

 Signature by an authorized party to formally approve release of the application or application update  Confirmation that secure development processes were followed by the vendor.

Modified p. 90 → 92

• Formal approval and signature by an authorized party.

 Formal approval and signature by an authorized party.  Confirmation that all SDLC processes were followed.

Modified p. 90 → 92

<Report Findings Here> 5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes

<Report Findings Here> 5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes  Formal approval and signature by an authorized party.  Confirmation that that all secure development processes were followed.

Removed p. 91

• The payment application enforces changes of default encryption keys, passwords and SNMP community strings at installation for all wireless components controlled by the application.

• Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

• Instructions for changing default encryption keys, passwords and SNMP community strings on any wireless components provided with, but not controlled by, the payment application.

• Instructions to install a firewall between any wireless networks and systems that store cardholder data.

• Details of any wireless traffic (including specific port information) that the wireless function of the payment application would use.

Modified p. 91 → 93

• Instructions to configure firewalls to deny or

•if such traffic is necessary for business Indicate whether the payment application uses wireless technologies. (yes/no) <Report Findings Here> Indicate whether other applications bundled with the payment application use wireless technologies. (yes/no) <Report Findings Here> If both are “no,” describe testing performed to verify the application is not developed for use with wireless technology. If both are “no,” mark the remainder of 6.1 and 6.2 as “not applicable” and proceed to 6.3. If …

 The payment application enforces changes of default encryption keys, passwords and SNMP community strings at installation for all wireless components controlled by the application.  Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.  Instructions for changing default encryption keys, passwords and SNMP community strings on any wireless components provided with, but not controlled by, the payment application.  Instructions to install a …

Removed p. 92

• Encryption keys were

• changed from default at installation.

• Default SNMP community strings on wireless devices were

• Default passwords/passphrases on access points were

• Firmware on wireless devices is

• Other security-related wireless vendor defaults were changed, if applicable.

• Change of wireless encryption keys

• Change of passwords/passphrases

Modified p. 92 → 94

• changed at installation.

• changed at installation.  Firmware on wireless devices is

Modified p. 92 → 94

• updated to support strong encryption for authentication and transmission over wireless networks.

• updated to support strong encryption for authentication and transmission over wireless networks.  Other security-related wireless vendor defaults were changed, if applicable.

Modified p. 92 → 94

• Change of SNMP strings <Report Findings Here>

 Change of wireless encryption keys  Change of passwords/passphrases  Change of SNMP strings <Report Findings Here>

Removed p. 93

• Change of wireless encryption keys

• Change of passwords/passphrases

Modified p. 93 → 95

• Change of SNMP strings <Report Findings Here> 6.1.e Install the application and test wireless functions to verify the wireless traffic and ports used by the application are in accordance with those documented in the PA-DSS Implementation Guide.

 Change of wireless encryption keys  Change of passwords/passphrases  Change of SNMP strings <Report Findings Here> 6.1.e Install the application and test wireless functions to verify the wireless traffic and ports used by the application are in accordance with those documented in the PA-DSS Implementation Guide.

Removed p. 94

• How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission.

Modified p. 94 → 96

• How to configure the application to use industry best practices (for example, IEEE 802.11.i) for strong encryption for authentication and transmission, and/or

 How to configure the application to use industry best practices (for example, IEEE 802.11.i) for strong encryption for authentication and transmission, and/or  How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission.

Removed p. 95

• Instructions to change all wireless default encryption keys, passwords and SNMP community strings upon installation.

• Instructions to change wireless encryption keys, passwords and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.

• Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.

Modified p. 95 → 97

• Instructions to install a firewall between any wireless networks and systems that store cardholder data, and to configure firewalls to deny or, if such traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

 Instructions to change all wireless default encryption keys, passwords and SNMP community strings upon installation.  Instructions to change wireless encryption keys, passwords and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.  Instructions to install a firewall between any wireless networks and systems that store cardholder data, and to configure firewalls to deny or, if such traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and …

Removed p. 96

• Assign a risk ranking to all identified vulnerabilities.

• Assign a risk ranking to all identified vulnerabilities.

• Test payment applications and updates for the presence of vulnerabilities prior to release.

• Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.

• Test payment applications for the presence of vulnerabilities prior to release.

• Required by the payment application.

Modified p. 96 → 98

• Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.

 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.  Assign a risk ranking to all identified vulnerabilities.  Test payment applications and updates for the presence of vulnerabilities prior to release.

Modified p. 96 → 98

• Test updates for the presence of vulnerabilities prior to release <Report Findings Here> 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).

 Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information.  Assign a risk ranking to all identified vulnerabilities.  Test payment applications for the presence of vulnerabilities prior to release.  Test updates for the presence of vulnerabilities prior to release <Report Findings Here> 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 …

Modified p. 96 → 98

• Provided with the payment application.

 Provided with the payment application.  Required by the payment application.

Removed p. 97

• Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US- CERT websites).

• Using reputable sources.

• New security vulnerabilities are assigned a risk ranking.

Modified p. 97 → 99

• In both the payment application and any underlying software or systems provided with or required by the payment application.

 In both the payment application and any underlying software or systems provided with or required by the payment application.  Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US- CERT websites).

Modified p. 97 → 99

• In both the payment application and any underlying software or systems provided with or required by the payment application.

 In both the payment application and any underlying software or systems provided with or required by the payment application.  Using reputable sources.

Modified p. 97 → 99

• Processes include ranking vulnerabilities in any underlying software or systems provided with or required by the payment application.

 New security vulnerabilities are assigned a risk ranking.  Processes include ranking vulnerabilities in any underlying software or systems provided with or required by the payment application.

Removed p. 98

• Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Modified p. 98 → 100

<Report Findings Here> 7.1.3 Test payment applications and updates for the presence of vulnerabilities prior to release.

<Report Findings Here> 7.1.3 Test payment applications and updates for the presence of vulnerabilities prior to release. ☐ ☐ ☐ 7.1.3 Interview responsible personnel and observe processes to verify that payment applications are tested for the presence of vulnerabilities prior to release.

Modified p. 98 → 100

• Patches and updates are delivered to customers in a secure manner with a known chain of trust.

 Patches and updates are delivered to customers in a secure manner with a known chain of trust.  Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

Modified p. 98 → 100

<Report Findings Here> 7.2.1 Patches and updates are delivered to customers in a secure manner with a known chain of trust.

<Report Findings Here> 7.2.1 Patches and updates are delivered to customers in a secure manner with a known chain of trust. ☐ ☐ ☐ 7.2.1 Interview responsible personnel and observe processes to verify patches and updates are delivered to customers in a secure manner with a known chain of trust.

Modified p. 98 → 100

<Report Findings Here> 7.2.2 Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.

<Report Findings Here> 7.2.2 Patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code. ☐ ☐ ☐

Modified p. 99 → 101

<Report Findings Here> 7.3 Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update. ☐ ☐ ☐ 7.3.a Examine processes for releasing updates and interview personnel to verify release notes are prepared for all updates, including details and impact of the update, and how the version number was changed to reflect the application update.

<Report Findings Here> 7.3 Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update. ☐ ☐ ☐

Removed p. 100

For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, TLS, IPSec, or other technology.

Modified p. 100 → 102

Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6 8.1.a Install the application in a PCI DSS compliant laboratory environment according to the PA-DSS Implementation Guide. Test the payment application ~~to obtain evidence that it~~ can run in a network that is fully compliant with PCI DSS.

Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6 8.1.a Install the application in a PCI DSS compliant laboratory environment according to the PA-DSS Implementation Guide. Test the Describe the testing performed to verify that the payment application can run in a network that is fully compliant with PCI DSS.

Modified p. 100 → 103

~~<Report Findings Here>~~ Provide the name of the PA-QSA who attests that the application was installed in a PCI DSS compliant laboratory environment, according to the PA-DSS Implementation Guide, consistent with Appendix B for confirmation of the configuration and setup of the lab.

Provide the name of the PA-QSA who attests that the application was installed in a PCI DSS compliant laboratory environment, according to the PA-DSS Implementation Guide, consistent with Appendix B for confirmation of the configuration and setup of the lab.

Modified p. 100 → 103

<Report Findings Here> 8.2 The payment application must only use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware, including those provided by third parties, for any functionality of the payment ~~application.~~

<Report Findings Here> 8.2 The payment application must only use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware, including those provided by third parties, for any functionality of the payment application.Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that uses or supports TLS must not allow fallback to SSL.

Modified p. 100 → 103

Aligns with PCI DSS Requirement 2.2.3 8.2.a Examine system services, protocols, daemons, components, and dependent software and hardware enabled or required by the Identify the system services, protocols, daemons, components, dependent hardware, and dependent software enabled or required by the payment application.

Aligns with PCI DSS Requirement 2.2.3 8.2.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.” Identify the system services, protocols, daemons, components, dependent hardware, and dependent software enabled or required by the payment application.

Modified p. 101 → 104

 System services <Report Findings Here>  Protocols <Report Findings Here>  Components <Report Findings Here>  Dependent hardware <Report Findings Here>  Dependent software <Report Findings Here>

 System services <Report Findings Here>  Protocols <Report Findings Here>  Components <Report Findings Here>  Dependent hardware <Report Findings Here>  Dependent software <Report Findings Here> 8.3 The payment application must not require use of services or protocols that preclude the use of or interfere with normal operation of multi-factor authentication technologies.

Removed p. 102

• 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 Examples of two-factor technologies include RADIUS with tokens, TACACS with tokens, or other technologies that facilitate two-factor authentication.

Modified p. 102 → 104

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:

Note: Multi-factor authentication requires that at least two of the three authentication methods (see below) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. The authentication methods, also known as a factors, are:

Modified p. 102 → 104

Aligns with PCI DSS Requirement 8.3 ~~8.3~~ Examine payment application functionality to verify it does not require use of any services or protocols that preclude the use of or interfere with the normal operation of ~~two-factor~~ authentication ~~technologies for remote access.~~

 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 8.3.a Examine payment application functionality to verify it does not require use of any services or protocols that preclude the use of or interfere with the normal operation of multi-factor authentication technologies.

Modified p. 102 → 104

Describe the payment application functionality examined to verify that the payment application does not require use of services or protocols that preclude the use of or interfere with normal operation of ~~two-factor~~ authentication ~~technologies for remote access.~~

Describe the payment application functionality examined to verify that the payment application does not require use of services or protocols that preclude the use of or interfere with normal operation of multi-factor authentication technologies.

Modified p. 102 → 104

<Report Findings Here> 8.3.b Identify remote access mechanisms supported by the application and verify that the mechanisms do not prevent ~~two-factor~~ authentication.

<Report Findings Here> 8.3.b Identify remote access mechanisms supported by the application and verify that the mechanisms do not prevent multi-factor authentication.

Modified p. 102 → 104

<Report Findings Here> Describe testing performed to verify the remote access mechanisms do not prevent ~~two-factor~~ authentication.

<Report Findings Here> Describe testing performed to verify the remote access mechanisms do not prevent multi-factor authentication.

Removed p. 103

• Instructions not to store cardholder data on public-facing systems (for example, web server and database server must not be on same server).

Modified p. 103 → 105

Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

 Instructions not to store cardholder data on public-facing systems (for example, web Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include the following instructions for customers and integrators/resellers:

Modified p. 104 → 106

• Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data (for example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone).

 Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data (for example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone).

Modified p. 104 → 106

• A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).

 A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).

Removed p. 105

• A description of two-factor authentication mechanisms supported by the application.

• Instructions for configuring the application to support two-factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).

Modified p. 105 → 107

Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 10.1 ~~Two-factor~~ authentication must be used for all remote access to the payment application that originates from outside the customer environment.

Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 10.1 Multi-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.

Modified p. 105 → 107

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

Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).

Modified p. 105 → 107

• Instructions that all remote access originating from outside the customer’s network to the payment application must use ~~two-factor~~ authentication in order to meet PCI DSS requirements.

 Instructions that all remote access originating from outside the customer’s network to the payment application must use multi-factor authentication in order to meet PCI DSS requirements.  A description of multi-factor authentication mechanisms supported by the application.  Instructions for configuring the application to support multi-factor authentication (at least two of the three authentication methods described in PA DSS Requirement 3.1.4).

Modified p. 105 → 107

 Instructions that all remote access originating from outside the customer’s network to the payment application must use ~~two-factor~~ authentication in order to meet PCI DSS requirements.

 Instructions that all remote access originating from outside the customer’s network to the payment application must use multi-factor authentication in order to meet PCI DSS requirements.

Modified p. 105 → 107

<Report Findings Here>  A description of ~~two-factor~~ authentication mechanisms supported by the application.

<Report Findings Here>  A description of multi-factor authentication mechanisms supported by the application.

Modified p. 105 → 107

<Report Findings Here>  Instructions for configuring the application to support ~~two- factor~~ authentication ~~(two~~ of the three authentication methods described in PA DSS Requirement 3.1.4).

<Report Findings Here>  Instructions for configuring the application to support multi-factor authentication (at least two of the three authentication methods described in PA DSS Requirement 3.1.4).

Modified p. 105 → 107

<Report Findings Here> 10.1.b If the application vendor has remote access to a customer’s payment application that originates from outside the customer environment, examine vendor policies to verify that the vendor supports customer requirements for ~~two-factor~~ authentication, for all such access.

<Report Findings Here> 10.1.b If the application vendor has remote access to a customer’s payment application that originates from outside the customer environment, examine vendor policies to verify that the vendor supports customer requirements for multi-factor authentication, for all such access.

Modified p. 105 → 107

Indicate whether the application vendor has remote access to a customer’s payment application that originates from outside the customer environment. (yes/no) <Report Findings Here> Identify the vendor policy documentation examined to verify that the vendor supports customer requirements for ~~two-factor~~ authentication for all remote access that originates from outside the customer environment.

Indicate whether the application vendor has remote access to a customer’s payment application that originates from outside the customer environment. (yes/no) <Report Findings Here> Identify the vendor policy documentation examined to verify that the vendor supports customer requirements for multi-factor authentication for all remote access that originates from outside the customer environment.

Removed p. 106

• Recommendation for customers and integrators/resellers to use a securely configured firewall or a personal firewall product if computer is connected via VPN or Indicate whether payment application updates are delivered via remote access into customers’ systems. (yes/no) If “no,” mark 10.2.1 as not applicable above and proceed to 10.2.2.

Modified p. 106 → 108

• Instructions for customers and integrators/resellers regarding secure use of remote-access technologies, specifying that remote-access technologies used by vendors and business partners should be activated only when needed and immediately deactivated after use.

 Instructions for customers and integrators/resellers regarding secure use of remote-access technologies, specifying that remote-access technologies used by vendors and business partners should be activated only when needed and immediately deactivated after use.  Recommendation for customers and integrators/resellers to use a securely configured firewall or a personal firewall product if computer is connected via VPN or Indicate whether payment application updates are delivered via remote access into customers’ systems. (yes/no) If “no,” mark 10.2.1 as not applicable above and …

Removed p. 107

• If remote access is via VPN or other high- speed connection, the connection is secured according to PCI DSS Requirement 1.

Modified p. 107 → 109

• Activation of remote-access technologies to customer networks only when needed and immediate deactivation after use.

 Activation of remote-access technologies to customer networks only when needed and immediate deactivation after use.  If remote access is via VPN or other high- speed connection, the connection is secured according to PCI DSS Requirement 1.

Modified p. 107 → 109

Aligns with PCI DSS Requirements 8.5.1 ~~☐ ☐ ☐~~ 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a ~~password/phrase)~~ is used for each customer they have access to.

Aligns with PCI DSS Requirements 8.5.1 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a password/passphrase) is used for each customer they have access to.

Removed p. 108

• 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 (See PA-DSS Requirements 3.1.1 through 3.1.11)

• Enable encrypted data transmission according to PA-DSS Requirement 12.1 Identify the page number(s)/section of the PA-DSS Implementation Guide verified to include instructions for customers and integrators/resellers that all remote access to the payment application must be implemented securely.

Modified p. 108 → 110

• 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 (See PA-DSS Requirements 3.1.1 through 3.1.11). • Enable encrypted data transmission according to PA-DSS Requirement 12.1 • Enable account lockout after a certain number of failed login attempts (See PA-DSS Requirement 3.1.9 through 3.1.10.) • Establish a VPN connection via a firewall …

 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 (See PA-DSS Requirements 3.1.1 through 3.1.11).  Enable encrypted data transmission according to PA-DSS Requirement 12.1  Enable account lockout after a certain number of failed login attempts (See PA-DSS Requirement 3.1.9 through 3.1.10.)  Establish a VPN connection via a firewall …

Removed p. 109

• Enable account lockout after a certain number of failed login attempts (See PA- DSS Requirement 3.1.9 through 3.1.10)

• Establish a VPN connection via a firewall before access is allowed.

• Enable the logging function.

• Restrict access to customer environments to authorized personnel.

Removed p. 110

• Only trusted keys and certificates are accepted.

• The protocol in use only supports secure versions or configurations.

• The encryption strength is appropriate for the encryption methodology in use

• Wireless technologies, including but not limited to 802.11 and Bluetooth

• Cellular technologies, for example, Global System for Mobile Communications (GSM), Code division multiple access (CDMA)

• General Packet Radio Service (GPRS)

Modified p. 110 → 112

Requirement 11: Encrypt sensitive traffic over public networks PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 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/TLSIPSEC, SSH, etc.)~~ to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:

Requirement 11: Encrypt sensitive traffic over public networks PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 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 to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:

Modified p. 110 → 112

~~Note::~~ SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that uses or supports TLS must not allow fallback to SSL Examples of open, public networks include but are not limited to:

Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that uses or supports TLS must not allow fallback to SSL Examples of open, public networks include but are not limited to:

Modified p. 110 → 112

• Satellite communications Aligns with PCI DSS Requirement 4.1 11.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that strong cryptography and security protocols are provided with the application, or that use thereof is specified.

 The Internet  Wireless technologies, including but not limited to 802.11 and Bluetooth  Cellular technologies, for example, Global System for Mobile Communications (GSM), Code division multiple access (CDMA)  General Packet Radio Service (GPRS)  Satellite communications Aligns with PCI DSS Requirement 4.1 11.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that strong cryptography and security protocols are provided with the application, or that use thereof is specified.

Modified p. 110 → 112

Identify the strong cryptography specified for use. <Report Findings Here> Identify the security protocols specified for use. <Report Findings Here> ~~Describe how the use of strong cryptography is specified. <Report Findings Here>~~

Identify the strong cryptography specified for use. <Report Findings Here> Identify the security protocols specified for use. <Report Findings Here>

Removed p. 111

• The protocol is implemented by default to use only trusted keys and/or certificates.

• The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations.

Modified p. 111 → 113

• Instructions that strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks. • Instructions for verifying that only trusted keys and/or certificates are accepted. • How to configure the payment application to use only secure versions and secure implementations of security protocols. • How to configure the payment application to prevent fallback to an insecure version or configuration (e.g., if TLS is used, the application must not allow fallback to SSL) • …

 Instructions that strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks.  Instructions for verifying that only trusted keys and/or certificates are accepted.  How to configure the payment application to use only secure versions and secure implementations of security protocols.  How to configure the payment application to prevent fallback to an insecure version or configuration (e.g., if TLS is used, the application must not allow fallback to SSL)  …

Modified p. 111 → 113

<Report Findings Here> ~~11.1.c~~ If strong cryptography and security protocols are provided with the payment ~~application, install and test the application according to instructions in the PA-DSS Implementation Guide, and verify:~~

<Report Findings Here> If it was noted in 11.1.a that strong cryptography and security protocols are provided with the payment application:

Removed p. 112

• Implements strong cryptography. <Report Findings Here> OR (if “yes”): Identify and describe the solution specified for use that:

• Renders the PAN unreadable; OR <Report Findings Here>

• Implements strong cryptography. <Report Findings Here> Describe how use of the solution is specified. <Report Findings Here>

Modified p. 112 → 114

• The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL). • Proper encryption strength is implemented for the encryption methodology in use.

 The protocol is implemented by default to use only trusted keys and/or certificates.  The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations.  The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL).  Proper encryption strength is implemented for the encryption methodology in use.

Modified p. 112 → 114

• Renders the PAN unreadable; OR <Report Findings Here>

 Renders the PAN unreadable; OR <Report Findings Here>  Implements strong cryptography. <Report Findings Here>

Removed p. 113

• Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Modified p. 113 → 115

• Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography.

 Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography.  Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Modified p. 114 → 116

Requirement 12: ~~Encrypt~~ all non-console administrative access PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 12.1 If the payment application facilitates non-console administrative access, encrypt all such access with strong ~~cryptography using technologies such as SSH, VPN, or TLS, for web-based management and other non-console administrative access.~~

Requirement 12: Secure all non-console administrative access PA-DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Findings (check one) In Place N/A 12.1 If the payment application facilitates non-console administrative access, encrypt all such access with strong cryptography.

Modified p. 114 → 116

• Clear-text protocols such as Telnet or rlogin must never be used for administrative access.

 Clear-text protocols such as Telnet or rlogin must never be used for administrative access.

Modified p. 114 → 116

• SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.

 SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.

Modified p. 114 → 116

<Report Findings Here> 12.1.c Examine the PA-DSS Implementation Guide prepared by vendor, and verify it includes instructions for customers and integrators/resellers how to configure the application to use strong ~~cryptography, using technologies such as SSH, VPN, or TLS,~~ for encryption of non-console administrative access.

<Report Findings Here> 12.1.c Examine the PA-DSS Implementation Guide prepared by vendor, and verify it includes instructions for customers and integrators/resellers how to configure the application to use strong cryptography for encryption of non-console administrative access.

Modified p. 115 → 117

Aligns with PCI DSS Requirement 2.3 ~~12.2~~ Examine the PA-DSS Implementation Guide prepared by vendor and verify it includes instructions for customers and integrators/resellers to implement strong ~~cryptography, using technologies such as SSH, VPN, or TLS,~~ for encryption of all non-console administrative access.

Aligns with PCI DSS Requirement 2.3 12.1.1 Examine the PA-DSS Implementation Guide prepared by vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.

Removed p. 116

• The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

• The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

• Clearly identifies the payment application name and version to which it applies.

<Report Findings Here> 13.1.2 Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced. ☐ ☐ ☐

Modified p. 116 → 119

• The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.

 The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.  The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

Modified p. 116 → 119

• The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.

 The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application.  The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.

Modified p. 116 → 119

• Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.

 Clearly identifies the payment application name and version to which it applies.  Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.

Removed p. 117

• Upon changes to the application

• Upon changes to the application

• At least annually <Report Findings Here>

• Upon changes to the application <Report Findings Here>

• Upon changes to these PA-DSS requirements <Report Findings Here> Identify the personnel interviewed for this testing procedure who confirm the PA-DSS Implementation Guide is reviewed

• Upon changes to these PA-DSS requirements <Report Findings Here> 13.1.3.b Verify the PA-DSS Implementation Guide is updated as needed to keep current with:

• Changes to the application or its dependencies.

• Provide updated versions as needed.

Modified p. 117 → 120

• Upon changes to these PA-DSS requirements Describe how the PA-DSS Implementation Guide was examined to verify it is reviewed:

 At least annually,  Upon changes to the application  Upon changes to these PA-DSS requirements Describe how the PA-DSS Implementation Guide was examined to verify it is reviewed:

Modified p. 117 → 120

• Changes to the PA-DSS requirements.

 Changes to the PA-DSS requirements.  Changes to the application or its dependencies.

Modified p. 117 → 120

• Communicate updates to customers, resellers, and integrators.

 Communicate updates to customers, resellers, and integrators.  Provide updated versions as needed.

Modified p. 117 → 121

<Report Findings Here> Describe the mechanism in place to ~~communicate updates to customers, resellers, and integrators.~~

<Report Findings Here> Describe the mechanism in place to provide updated versions as needed.

Removed p. 119

• Overall accountability for meeting all the requirements in PA-DSS

• Keeping up-to-date within any changes in the PA-DSS Program Guide

• Ensuring secure coding practices are followed

• Ensuring integrators/resellers receive training and supporting materials

• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training

Modified p. 119 → 122

Requirement 14: Assign PA-DSS responsibilities for personnel and maintain training programs for personnel, customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction ~~/ROV~~ Reporting Details:

Requirement 14: Assign PA-DSS responsibilities for personnel and maintain training programs for personnel, customers, resellers, and integrators PA-DSS Requirements and Testing Procedures Reporting Instruction ROV Reporting Details:

Removed p. 120

• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A)

Modified p. 120 → 123

• How to implement the payment application and related systems and networks in a PCI DSS-compliant manner

 How to implement the payment application and related systems and networks in a PCI DSS-compliant manner  Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A)

Removed p. 121

• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).

• Training on how to implement the payment application in a PCI DSS-compliant manner.

• Training on how to implement related systems and networks in a PCI DSS-compliant manner.

• Training materials are provided to integrators and resellers.

• Training materials are provided to integrators and resellers.

• The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

Modified p. 121 → 124

• Training on how to implement the payment application and related systems and networks in a PCI DSS-compliant manner.

 Training on how to implement the payment application and related systems and networks in a PCI DSS-compliant manner.  Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).

Modified p. 121 → 124

• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).

 Training on how to implement the payment application in a PCI DSS-compliant manner.  Training on how to implement related systems and networks in a PCI DSS-compliant manner.  Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).

Modified p. 121 → 124

• The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

 Training materials are provided to integrators and resellers.  The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

Modified p. 121 → 124

<Report Findings Here> Identify the vendor personnel interviewed who confirm that

<Report Findings Here> Identify the vendor personnel interviewed who confirm that  Training materials are provided to integrators and resellers.  The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.

Modified p. 121 → 124

~~14.3.1.a Examine the training materials for~~ Describe the training materials for integrators and resellers observed to verify the materials are:

Describe the training materials for integrators and resellers observed to verify the materials are:

Removed p. 122

• Updated as needed to keep the documentation current with new payment application versions and changes to PA- DSS requirements.

Modified p. 122 → 125

Assessor’s Response Summary of Findings (check one) In Place N/A integrators and resellers and verify the materials are:

Assessor’s Response Summary of Findings (check one) In Place N/A 14.3.1.a Examine the training materials for integrators and resellers and verify the materials are:

Modified p. 122 → 125

• Reviewed at least annually and upon changes to the application or to PA-DSS requirements.

 Reviewed at least annually and upon changes to the application or to PA-DSS requirements.  Updated as needed to keep the documentation current with new payment application versions and changes to PA- DSS requirements.

Modified p. 124 → 127

The following must be provided for customers and integrators/resellers:  Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts.  Confirmation that the payment application masks PAN by default on all displays.  Instructions on how to configure the payment application such that only personnel with a legitimate business need can see the full ~~PAN.~~

The following must be provided for customers and integrators/resellers:  Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts.  Confirmation that the payment application masks PAN by default on all displays.  Instructions on how to configure the payment application such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN (includes displays of the full PAN).

Modified p. 124 → 127

Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see the ~~full~~ PAN.

Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see more than the first six/last four digits of the PAN.

Modified p. 124 → 127

Customers & Integrators/Resellers: Mask displays of PAN so only personnel with a business need can see the ~~full~~ PAN, per the PA-DSS Implementation Guide and ~~PA- DSS~~ Requirement 2.2.

Customers & Integrators/Resellers: Mask displays of PAN so only personnel with a business need can see more than the first six/last four digits of the PAN, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.2.

Modified p. 125 → 128

The following must be provided for customers and integrators/resellers:  Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1).  A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible …

Modified p. 127 → 131

• Enforcing secure changes to authentication credentials by the completion of installation per PA-DSS requirements 3.1.1 through 3.1.11. • Enforcing secure changes to authentication credentials for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1.11.  That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Assign secure authentication to all default accounts in the environment. …

 Enforcing secure changes to authentication credentials by the completion of installation per PA-DSS requirements 3.1.1 through 3.1.11.  Enforcing secure changes to authentication credentials for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1.11.  That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements.  Assign secure authentication to all default accounts in the environment. …

Modified p. 132 → 136

Customers & Integrators/Resellers: 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.1 Implement two-factor authentication for all remote access to payment application that originates from outside the customer environment.~~

Customers & Integrators/Resellers: 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

Modified p. 132 → 137

Provide the following for customers and integrators/resellers:  Instruction that all remote access originating from outside the customer’s network to the payment application must use ~~two-factor~~ authentication in order to meet PCI DSS requirements.  Describe the ~~two-factor~~ authentication mechanisms supported by the application.  Instructions on how to configure the application to support ~~two-factor~~ authentication ~~(two~~ of the three authentication methods described in PA DSS Req. 3.1.4).

Provide the following for customers and integrators/resellers:  Instruction that all remote access originating from outside the customer’s network to the payment application must use multi-factor authentication in order to meet PCI DSS requirements.  Describe the multi-factor authentication mechanisms supported by the application.  Instructions on how to configure the application to support multi-factor authentication (at least two of the three authentication methods described in PA DSS Req. 3.1.4).

Modified p. 132 → 137

Software Vendor: Ensure payment application supports customers’ use of ~~two-factor~~ authentication for all remote access to the payment application that originates from outside the customer environment, per PA-DSS Requirement 10.2.

Software Vendor: Ensure payment application supports customers’ use of multi-factor authentication for all remote access to the payment application that originates from outside the customer environment, per PA-DSS Requirement 10.2.

Modified p. 132 → 137

Customers & Integrators/resellers: Establish and maintain ~~two-factor~~ authentication for all remote access to payment application that originates from outside the customer environment, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.

Customers & Integrators/resellers: Establish and maintain multi-factor authentication for all remote access to payment application that originates from outside the customer environment, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.

Modified p. 134 → 139

If the payment application sends, or facilitates sending, cardholder data over public networks, include instructions for implementing and using strong cryptography and security protocols for secure cardholder data transmission over public networks, including:  Required use of strong cryptography and security protocols if cardholder data is ever transmitted over public networks.  Instructions for verifying that only trusted keys and/or certificates are accepted.  How to configure the payment application to use only secure versions and secure implementations of security …

Modified p. 134 → 140

If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography ~~(such as SSH, VPN, or TLS)~~ for encryption of all ~~non- console~~ administrative access to payment application or servers in cardholder data environment.

If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography for encryption of all non-console administrative access to payment application or servers in cardholder data environment.

Modified p. 135 → 140

Include instructions for customers and integrators/resellers to implement strong ~~cryptography, using technologies such as SSH, VPN, or TLS,~~ for encryption of all non-console administrative access.

Include instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.

Modified p. 135 → 140

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

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

Modified p. 135 → 140

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

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

Modified p. 136 → 141

• Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the environment truly simulates a real- world situation.

 Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the environment truly simulates a real- world situation.

Modified p. 136 → 141

• Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the vendor has not modified or tampered with the environment in any way.

 Describe how the PA-QSA validated the clean installation of the remote lab environment to ensure the vendor has not modified or tampered with the environment in any way.

Modified p. 137 → 142

• If any of the below were not in place or if there are any other comments or details related to the laboratory the PA-QSA would like to note, please indicate that here.

 If any of the below were not in place or if there are any other comments or details related to the laboratory the PA-QSA would like to note, please indicate that here.

Document Comparison

From Revision History

Content Changes