Document Comparison
pa-dss_v2.pdf
→
PA-DSS_v3.pdf
37% similar
55 → 92
Pages
19114 → 34485
Words
306
Content Changes
Content Changes
306 content changes. 126 administrative changes (dates, page numbers) hidden.
Added
p. 5
All applications that store, process, or transmit cardholder data are in scope for an entity’s PCI DSS assessment, including applications that have been validated to PA-DSS. The PCI DSS assessment should verify the PA-DSS payment application is properly configured and securely implemented per PCI DSS requirements. If the payment application has undergone any customization, a more in-depth review will be required during the PCI DSS assessment, as the application may no longer be representative of the version that was validated to PA-DSS
1. Storage of magnetic-stripe data and/or equivalent data on the chip in the customer's network after authorization;
1. Storage of magnetic-stripe data and/or equivalent data on the chip in the customer's network after authorization;
Added
p. 6
PCI Qualified Integrators and Resellers (QIRs) are trained by the Council in PCI DSS and PA-DSS in order to securely implement payment applications. For more information on the PCI QIR program, please see www.pcisecuritystandards.org.
PCI DSS applies to all entities involved in payment card processing•including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
Cardholder data and sensitive authentication data are defined as follows:
Account Data Cardholder Data includes: Sensitive Authentication Data includes:
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN, or are otherwise present in the cardholder data …
PCI DSS applies to all entities involved in payment card processing•including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
Cardholder data and sensitive authentication data are defined as follows:
Account Data Cardholder Data includes: Sensitive Authentication Data includes:
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN, or are otherwise present in the cardholder data …
Added
p. 7
Requirement 2.3 Account Data Cardholder Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Full Track Data 2 No Cannot store per PA-DSS Requirement 1.1 CAV2/CVC2/CVV2/CID3 No Cannot store per PA-DSS Requirement 1.1 PIN/PIN Block4 No Cannot store per PA-DSS Requirement 1.1 PA-DSS Requirements 2.2 and 2.3 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PA-DSS Requirement 2.3.
Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment.
Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment.
Added
p. 8
The scope of the PA-DSS assessment should include the following:
Coverage of all payment application functionality, including but not limited to:
Coverage of guidance the payment application vendor is expected to provide to customers and integrators/resellers (see PA-DSS Implementation Guide later in this document) to ensure:
1) Customer knows how to implement the payment application in a PCI DSS-compliant manner and 2) Customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS compliance.
Note that the payment application vendor may be expected to provide such guidance even when the specific setting:
1) Cannot be controlled by the payment application vendor once the application is installed by the customer, or 2) Is the responsibility of the customer, not the payment application vendor.
Coverage of all payment application functionality, including but not limited to:
Coverage of guidance the payment application vendor is expected to provide to customers and integrators/resellers (see PA-DSS Implementation Guide later in this document) to ensure:
1) Customer knows how to implement the payment application in a PCI DSS-compliant manner and 2) Customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS compliance.
Note that the payment application vendor may be expected to provide such guidance even when the specific setting:
1) Cannot be controlled by the payment application vendor once the application is installed by the customer, or 2) Is the responsibility of the customer, not the payment application vendor.
Added
p. 11
The PA-DSS Implementation Guide must provide details on how to configure the payment application to meet the requirement(s) and not simply restate the requirements from the PCI DSS or PA-DSS. During an assessment, the PA-QSA must verify that that the instructions are accurate and effective. The PA-QSA must also verify that the PA-DSS Implementation Guide is distributed to customers and integrators/resellers.
Instructions and Content for Report on Validation Instructions and content for the PA-DSS Report on Validation (ROV) are now provided in the PA-DSS ROV Reporting Template. The PA-DSS ROV Reporting Template must be used for creating the Report on Validation. Only compliant payment application ROVs should be submitted to PCI SSC. For details about the ROV submission process, refer to the PA-DSS Program Guide.
1. Confirm the scope of the PA-DSS assessment.
2. Perform the PA-DSS assessment.
5. After completion, submit all of the above documents and the PA-DSS Implementation Guide to PCI …
Instructions and Content for Report on Validation Instructions and content for the PA-DSS Report on Validation (ROV) are now provided in the PA-DSS ROV Reporting Template. The PA-DSS ROV Reporting Template must be used for creating the Report on Validation. Only compliant payment application ROVs should be submitted to PCI SSC. For details about the ROV submission process, refer to the PA-DSS Program Guide.
1. Confirm the scope of the PA-DSS assessment.
2. Perform the PA-DSS assessment.
5. After completion, submit all of the above documents and the PA-DSS Implementation Guide to PCI …
Added
p. 14
PA-DSS Requirements
• This column defines the security requirements for payment applications to be validated against Testing Procedures
• This column defines the testing processes to be followed by the PA-QSA to validate that PA-DSS requirements have been met Guidance
• This column describes the intent or security objective behind each PA-DSS requirement and is intended to assist understanding of the requirements. The guidance in this column does not replace or extend the PA-DSS requirements and testing procedures.
PA-DSS requirements must not be considered in place if any controls are not yet implemented or are scheduled to be completed at a future date.
• This column defines the security requirements for payment applications to be validated against Testing Procedures
• This column defines the testing processes to be followed by the PA-QSA to validate that PA-DSS requirements have been met Guidance
• This column describes the intent or security objective behind each PA-DSS requirement and is intended to assist understanding of the requirements. The guidance in this column does not replace or extend the PA-DSS requirements and testing procedures.
PA-DSS requirements must not be considered in place if any controls are not yet implemented or are scheduled to be completed at a future date.
Added
p. 15
Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited. This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.
For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted, and the application is required to have a mechanism for securely deleting the data so it is unrecoverable.
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.
For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted, and the application is required to have a mechanism for securely deleting the data so it is unrecoverable.
Added
p. 16
• The accountholder’s name,
• Primary account number (PAN),
• Expiration date, and
• Service code To minimize risk, store only those data elements needed for business.
• Primary account number (PAN),
• Expiration date, and
• Service code To minimize risk, store only those data elements needed for business.
Added
p. 16
If full track data is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions.
Added
p. 17
The purpose of the card validation code is to protect "card-not-present" transactions
• Internet or mail order/telephone order (MO/TO) transactions
•where the consumer and the card are not present. If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions.
These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals).
• Internet or mail order/telephone order (MO/TO) transactions
•where the consumer and the card are not present. If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions.
These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals).
Added
p. 18
• 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 PCI DSS compliance.
All of these elements of sensitive authentication data are not permitted to be stored post-authorization. If older versions of payment applications stored this information, the payment application vendor is required to provide instructions in the PA-DSS Implementation Guide as well as a secure wipe tool or procedure. If not securely deleted, this data could remain hidden on merchant systems, and malicious individuals who obtain access to this information could use it to produce counterfeit payment cards, and/or to perform fraudulent transactions. 1.1.4.b Examine payment application software files and configuration documentation to verify the vendor provides a secure wipe tool or procedure to remove the data.
• How to remove historical data.
• That such removal is absolutely necessary for PCI DSS compliance.
All of these elements of sensitive authentication data are not permitted to be stored post-authorization. If older versions of payment applications stored this information, the payment application vendor is required to provide instructions in the PA-DSS Implementation Guide as well as a secure wipe tool or procedure. If not securely deleted, this data could remain hidden on merchant systems, and malicious individuals who obtain access to this information could use it to produce counterfeit payment cards, and/or to perform fraudulent transactions. 1.1.4.b Examine payment application software files and configuration documentation to verify the vendor provides a secure wipe tool or procedure to remove the data.
Added
p. 19
• 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:
• Other data sources received from customers.
• Collection of sensitive authentication data only when needed to solve a specific problem.
• Storage of such data in a specific, known location with limited access.
• Collection of only a limited amount of data needed to solve a specific problem.
• Encryption of sensitive authentication data while stored.
• Secure deletion of such data immediately after use.
If the vendor provides services to their customers that could result in the collection of sensitive authentication data (for example, for troubleshooting or debugging purposes), the vendor must minimize the collection of …
• 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:
• Other data sources received from customers.
• Collection of sensitive authentication data only when needed to solve a specific problem.
• Storage of such data in a specific, known location with limited access.
• Collection of only a limited amount of data needed to solve a specific problem.
• Encryption of sensitive authentication data while stored.
• Secure deletion of such data immediately after use.
If the vendor provides services to their customers that could result in the collection of sensitive authentication data (for example, for troubleshooting or debugging purposes), the vendor must minimize the collection of …
Added
p. 21
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.
• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key- management processes and procedures.
(Continued on next page) 2.3a Review the PA-DSS Implementation Guide prepared by the vendor to verify the documentation includes the following guidance 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 …
• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key- management processes and procedures.
(Continued on next page) 2.3a Review the PA-DSS Implementation Guide prepared by the vendor to verify the documentation includes the following guidance 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 …
Added
p. 22
The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm), with strong cryptographic keys.
Note: This requirement applies to keys used to encrypt stored cardholder data, as well as to key- encrypting keys used to protect data-encrypting keys. Such key-encrypting keys must be at least as strong as the data-encrypting key.
Aligns with PCI DSS Requirement 3.5 2.4.a Examine product documentation and interview responsible personnel to verify that controls are in place that restrict access to cryptographic keys used by the application.
Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data.
The requirement for payment applications to protect keys from disclosure and misuse applies to both data-encrypting keys and key- encrypting keys.
There should be very few who have access …
Note: This requirement applies to keys used to encrypt stored cardholder data, as well as to key- encrypting keys used to protect data-encrypting keys. Such key-encrypting keys must be at least as strong as the data-encrypting key.
Aligns with PCI DSS Requirement 3.5 2.4.a Examine product documentation and interview responsible personnel to verify that controls are in place that restrict access to cryptographic keys used by the application.
Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data.
The requirement for payment applications to protect keys from disclosure and misuse applies to both data-encrypting keys and key- encrypting keys.
There should be very few who have access …
Added
p. 23
The manner in which cryptographic keys are managed is a critical part of the continued security of the payment application. A good key-management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 2.5.1 through 2.5.7.
Providing guidance to customers on how to securely transmit, store and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities.
This requirement applies to keys used to encrypt stored cardholder data, and any respective key-encrypting keys.
Providing guidance to customers on how to securely transmit, store and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities.
This requirement applies to keys used to encrypt stored cardholder data, and any respective key-encrypting keys.
Added
p. 23
The payment application must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "Strong Cryptography." 2.5.1.b Test the application, including the methods used to generate cryptographic keys, to verify that the instructions in the PA-DSS Implementation Guide result in the generation of strong cryptographic keys.
Added
p. 23
The payment application must distribute keys securely, meaning the keys are not distributed in the clear, and only via authorized processes.
2.5.2.b Test the application, including the methods used to distribute cryptographic keys, to verify that the instructions in the PA-DSS Implementation Guide result in the secure distribution of cryptographic keys.
2.5.2.b Test the application, including the methods used to distribute cryptographic keys, to verify that the instructions in the PA-DSS Implementation Guide result in the secure distribution of cryptographic keys.
Added
p. 23
The payment application must store keys securely (for example, by encrypting them with a key-encrypting key).
Added
p. 24
2.5.4.a Review the PA-DSS Implementation Guide and verify it includes the following instructions for customers and integrators/resellers:
• Defined cryptoperiod for each key type used by the application.
A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted.
Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone’s obtaining the encryption keys, and using them to decrypt data.
2.5.4.b Test the application, including the methods for changing cryptographic keys, to verify the instructions in the PA-DSS Implementation Guide result in key changes at the end of the defined cryptoperiod.
2.5.5.a Review the PA-DSS Implementation Guide and verify it …
• Defined cryptoperiod for each key type used by the application.
A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted.
Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone’s obtaining the encryption keys, and using them to decrypt data.
2.5.4.b Test the application, including the methods for changing cryptographic keys, to verify the instructions in the PA-DSS Implementation Guide result in key changes at the end of the defined cryptoperiod.
2.5.5.a Review the PA-DSS Implementation Guide and verify it …
Added
p. 25
2.5.5.c Test the application with the retired/replaced keys to verify that the instructions in the PA-DSS Implementation Guide ensure the application does not use retired or replaced keys for encryption operations.
• 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.
Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key This control is applicable for manual key-management operations.
Split knowledge is a method in which two or more people separately have key components that individually convey no knowledge of the original cryptographic key; each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key).
Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials …
• 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.
Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key This control is applicable for manual key-management operations.
Split knowledge is a method in which two or more people separately have key components that individually convey no knowledge of the original cryptographic key; each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key).
Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials …
Added
p. 25
The payment application should define methods for users of the application to ensure only authorized key substitutions can be made. The application configuration should include not allowing for or accepting substitution of keys coming from unauthorized sources or unexpected processes.
2.5.7.b Test the application, including all methods for substituting keys, to verify that the instructions in the PA-DSS Implementation Guide prevent unauthorized substitution of cryptographic keys.
2.5.7.b Test the application, including all methods for substituting keys, to verify that the instructions in the PA-DSS Implementation Guide prevent unauthorized substitution of cryptographic keys.
Added
p. 26
Note: This requirement applies only if the payment application uses or previous versions of the payment application used cryptographic key materials or cryptograms to encrypt cardholder data.
Aligns with PCI DSS Requirement 3.6 2.6.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:
• 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.
Vendors should provide a mechanism so their customers can securely delete old cryptographic material when the customer no longer needs it. Note that the deletion of old cryptographic material is at the customers’ discretion.
• Secure deletion, …
Aligns with PCI DSS Requirement 3.6 2.6.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:
• 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.
Vendors should provide a mechanism so their customers can securely delete old cryptographic material when the customer no longer needs it. Note that the deletion of old cryptographic material is at the customers’ discretion.
• Secure deletion, …
Added
p. 28
Aligns with PCI DSS Requirement 2.1 3.1.1 Install and configure the payment application in accordance with the PA-DSS Implementation Guide, including configuring any administrative accounts for all necessary software. Test the payment application to verify the payment application does not use (or require the use of) default administrative accounts for necessary software.
Default administrative accounts (and passwords) are public knowledge, and known to anyone who is familiar with the payment application or underlying system components. If default administrative accounts and passwords are used, an unauthorized individual may be able to gain access to the application and data simply by logging in with publicly known credentials.
Default administrative accounts (and passwords) are public knowledge, and known to anyone who is familiar with the payment application or underlying system components. If default administrative accounts and passwords are used, an unauthorized individual may be able to gain access to the application and data simply by logging in with publicly known credentials.
Added
p. 28
This applies to all accounts, including user accounts, application and service accounts, and accounts used by the vendor for support purposes.
Note: This requirement cannot be met through specifying a user process or via instructions in the PA-DSS Implementation Guide. At the completion of installation, and upon subsequent changes, the application must technically prevent any default or built-in accounts from being used until the default password has been changed.
If the application doesn’t enforce changing of default passwords, the application could be left exposed to unauthorized access by anyone knowledgeable of the default settings. 3.1.2.a Install the application in accordance with the PA-DSS Implementation Guide, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to any default payment application passwords by completion of the installation process.
Note: This requirement cannot be met through specifying a user process or via instructions in the PA-DSS Implementation Guide. At the completion of installation, and upon subsequent changes, the application must technically prevent any default or built-in accounts from being used until the default password has been changed.
If the application doesn’t enforce changing of default passwords, the application could be left exposed to unauthorized access by anyone knowledgeable of the default settings. 3.1.2.a Install the application in accordance with the PA-DSS Implementation Guide, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to any default payment application passwords by completion of the installation process.
Added
p. 28
For all types of changes performed, examine account and password settings and attempt to use all default passwords to verify that the application enforces changes to all default passwords upon completion of the change.
When each user is assigned a unique user ID, their access to and activities within the payment application can be traced back to the individual who performed them.
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.
When each user is assigned a unique user ID, their access to and activities within the payment application can be traced back to the individual who performed them.
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.
Added
p. 29
For all types of changes performed, examine account settings and test application functionality to verify that unique user IDs are assigned for all accounts upon completion of the change.
Aligns with PCI DSS Requirements 8.2 3.1.4 For all accounts generated or managed by the application, test the application as follows:
These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used).
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.
For all types of changes performed, test authentication methods to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion …
Aligns with PCI DSS Requirements 8.2 3.1.4 For all accounts generated or managed by the application, test the application as follows:
These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used).
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.
For all types of changes performed, test authentication methods to verify that the application requires at least one of the defined authentication methods for all accounts, upon completion …
Added
p. 30
If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to assign accountability for, or to have effective logging of, an individual’s actions, since a given action could have been performed by anyone that has knowledge of the authentication credentials.
3.1.5.a Install the payment application in accordance with the PA-DSS Implementation Guide, examine account settings and test application functionality to verify that, by completion of the installation process, the application does not require or use any group, shared, or generic accounts and passwords.
For all types of changes performed, examine account settings and test application functionality to verify that the application does not rely on or use any group, shared, or generic accounts and passwords upon completion of the change.
3.1.5.a Install the payment application in accordance with the PA-DSS Implementation Guide, examine account settings and test application functionality to verify that, by completion of the installation process, the application does not require or use any group, shared, or generic accounts and passwords.
For all types of changes performed, examine account settings and test application functionality to verify that the application does not rely on or use any group, shared, or generic accounts and passwords upon completion of the change.
Added
p. 30
• Require a minimum length of at least seven characters.
Added
p. 30
Alternatively, the passwords/phrase must have complexity and strength at least equivalent to the parameters specified above.
Added
p. 30
Malicious individuals will often try to find accounts with weak or non-existent passwords in order to gain access to an application or system. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts, and compromise an application or system under the guise of a valid user ID.
(Continued on next page) 3.1.6.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 requires passwords to require a minimum of the following complexity and strength:
• Be at least seven characters in length.
(Continued on next page) 3.1.6.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 requires passwords to require a minimum of the following complexity and strength:
• Be at least seven characters in length.
Added
p. 31
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
This requirement specifies passwords be a minimum of seven characters in length and that both numeric and alphabetic characters should be used. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800-63-1 defines “entropy” as “a measure of the difficulty of guessing or determining a password or key.” This document and others that discuss “password entropy” can be referenced for more information on entropy value and equivalent password strength for passwords of different minimum formats.
3.1.6.c If the application uses a different minimum character set and length for passwords, calculate the entropy of the passwords required …
• Be at least seven characters in length
This requirement specifies passwords be a minimum of seven characters in length and that both numeric and alphabetic characters should be used. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800-63-1 defines “entropy” as “a measure of the difficulty of guessing or determining a password or key.” This document and others that discuss “password entropy” can be referenced for more information on entropy value and equivalent password strength for passwords of different minimum formats.
3.1.6.c If the application uses a different minimum character set and length for passwords, calculate the entropy of the passwords required …
Added
p. 33
If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of these locked accounts stops the malicious individual from continually guessing the password (they will have to stop for a minimum of 30 minutes until the account is reactivated). Additionally, if reactivation must be requested, the administrator can validate that it is the actual account owner requesting reactivation.
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.
For all types of changes performed, examine account settings and test application functionality 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.
Aligns with …
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.
For all types of changes performed, examine account settings and test application functionality 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.
Aligns with …
Added
p. 34
Aligns with PCI DSS Requirement 8.2.1 3.3 Perform the following: If payment application passwords are stored or transmitted across the network without encryption, a malicious individual can easily intercept the password using a “sniffer,” or directly access the passwords in files where they are stored, and use this stolen data to gain unauthorized access.
Concatenating a unique input variable to each password before the hashing algorithm is applied reduces the effectiveness of brute force attacks. Examples of strong one-way cryptographic algorithms suitable for hashing passwords include PBKDF2 and Bcrypt.
Concatenating a unique input variable to each password before the hashing algorithm is applied reduces the effectiveness of brute force attacks. Examples of strong one-way cryptographic algorithms suitable for hashing passwords include PBKDF2 and Bcrypt.
Added
p. 34
3.3.1.b For all types of application passwords, examine transmissions of passwords (for example, by logging into the application from another system, and authenticating the application to other systems) to verify strong cryptography is used to render all passwords unreadable at all times during transmission.
Added
p. 34
Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.
Note: The input variable does not need to be unpredictable or secret 3.3.2.a Examine vendor documentation and application configurations to verify that:
• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.
3.3.2.b For all types of application passwords, identify all locations where the application may store passwords, including within the application itself, on underlying systems, log files, registry settings, etc. For all locations and types of passwords, examine stored password files to verify that passwords are rendered unreadable using a strong, one-way cryptographic algorithm, with a unique input variable at all times when stored.
Note: The input variable does not need to be unpredictable or secret 3.3.2.a Examine vendor documentation and application configurations to verify that:
• A unique input variable is concatenated with each password before the cryptographic algorithm is applied.
3.3.2.b For all types of application passwords, identify all locations where the application may store passwords, including within the application itself, on underlying systems, log files, registry settings, etc. For all locations and types of passwords, examine stored password files to verify that passwords are rendered unreadable using a strong, one-way cryptographic algorithm, with a unique input variable at all times when stored.
Added
p. 35
• 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 minimum level of privilege assigned for each function/resource as needed for the application/service account.
Aligns with PCI DSS Requirement 7 3.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine settings for built- in accounts to verify that, by completion of the installation process:
• 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.
• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
In order to limit access to cardholder data …
• By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
Aligns with PCI DSS Requirement 7 3.4.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine settings for built- in accounts to verify that, by completion of the installation process:
• 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.
• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
In order to limit access to cardholder data …
Added
p. 37
Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account. Activities including, but not limited to, creation of new accounts, escalation of privilege, or changes to access permissions may indicate unauthorized use of a system’s authentication mechanisms.
Added
p. 38
• Initialization of application audit logs
• Stopping or pausing of application audit logs.
Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.
Malicious users often create or replace system-level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized.
By recording the details in 4.3.1
• 4.3.6 for the auditable events in 4.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. 4.3.1 User identification 4.3.1 Verify user identification is included in log entries.
• Stopping or pausing of application audit logs.
Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.
Malicious users often create or replace system-level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized.
By recording the details in 4.3.1
• 4.3.6 for the auditable events in 4.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. 4.3.1 User identification 4.3.1 Verify user identification is included in log entries.
Added
p. 39
Aligns with PCI DSS Requirement 10.5.3 4.4.a Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and integrators/resellers are provided with:
• A description of which centralized logging mechanisms are supported
Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise. Including payment application logs in a centralized logging system allows the customer to integrate and correlate their logs, and secure the logs consistently in their environment.
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 merchant’s ability to assimilate logs into their centralized log server is provided.
Requirement 5: Develop secure payment applications PA-DSS Requirements Testing Procedures Guidance 5.1 The software vendor has defined and implemented a formal process for secure development of …
• A description of which centralized logging mechanisms are supported
Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise. Including payment application logs in a centralized logging system allows the customer to integrate and correlate their logs, and secure the logs consistently in their environment.
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 merchant’s ability to assimilate logs into their centralized log server is provided.
Requirement 5: Develop secure payment applications PA-DSS Requirements Testing Procedures Guidance 5.1 The software vendor has defined and implemented a formal process for secure development of …
Added
p. 41
Aligns with PCI DSS Requirement 6.4.4 5.1.2.a Review software-development processes to verify they include procedures to ensure test data and accounts are removed before payment application is released to customers.
Test data and accounts should be
• removed from the application before it is released to customers, since inclusion of these items may give away information about key constructs within the application. 5.1.2.b Observe testing processes and interview personnel to verify test data and accounts are
• removed before release to customer.
5.1.2.c Examine the final payment application product to verify test data and accounts are removed before release to customer.
Pre-release custom accounts, user IDs and passwords could be used as a back door for developers or other individuals with knowledge of those accounts to gain access to the application, and could facilitate compromise of the application and related cardholder data.
5.1.3.b Observe testing processes and interview personnel to verify that custom payment application accounts, …
Test data and accounts should be
• removed from the application before it is released to customers, since inclusion of these items may give away information about key constructs within the application. 5.1.2.b Observe testing processes and interview personnel to verify test data and accounts are
• removed before release to customer.
5.1.2.c Examine the final payment application product to verify test data and accounts are removed before release to customer.
Pre-release custom accounts, user IDs and passwords could be used as a back door for developers or other individuals with knowledge of those accounts to gain access to the application, and could facilitate compromise of the application and related cardholder data.
5.1.3.b Observe testing processes and interview personnel to verify that custom payment application accounts, …
Added
p. 42
• 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 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.)
• Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)
• Appropriate corrections are implemented prior to release.
• Appropriate corrections are implemented prior to release.
• Code-review results are reviewed and approved by management 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 to release.
Aligns with PCI DSS Requirement 6.3.2 5.1.4.a Examine written software-development procedures and interview responsible personnel …
• 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.)
• Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)
• Appropriate corrections are implemented prior to release.
• Appropriate corrections are implemented prior to release.
• Code-review results are reviewed and approved by management 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 to release.
Aligns with PCI DSS Requirement 6.3.2 5.1.4.a Examine written software-development procedures and interview responsible personnel …
Added
p. 43
5.1.5.a Examine written software-development procedures and interview responsible personnel to verify the vendor maintains secure source control practices to verify integrity of source code during the development process.
Good source-code control practices help ensure that all changes to code are intended and authorized, and performed only by those with a legitimate reason to change the code. Examples of these practices include check-in and check-out procedures for code with strict access controls, and a comparison immediately before updating code to confirm that the last approved version hasn’t been changed (for example, using a checksum).
5.1.5.b Examine mechanisms and observe procedures for securing source code to verify integrity of source code is maintained during the development process.
Good source-code control practices help ensure that all changes to code are intended and authorized, and performed only by those with a legitimate reason to change the code. Examples of these practices include check-in and check-out procedures for code with strict access controls, and a comparison immediately before updating code to confirm that the last approved version hasn’t been changed (for example, using a checksum).
5.1.5.b Examine mechanisms and observe procedures for securing source code to verify integrity of source code is maintained during the development process.
Added
p. 43
• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
• Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
Added
p. 43
5.1.6.a Examine software-development processes to verify that secure coding techniques are defined and include:
• Developing with fail-safe default (all execution is by default denied unless specified within initial design).
Developing applications with least privilege is the most effective way to ensure insecure assumptions aren’t introduced into the application. Including fail-safe defaults could prevent an attacker from obtaining sensitive information about an application failure that could then be used to create subsequent attacks. Ensuring that security is applied to all accesses and inputs into the application avoids the likelihood that an input channel may be left open to compromise. Failure to consider these concepts while developing code could result in the release of an insecure application and potentially excessive remediation at a later time.
5.1.6.b Interview developers to verify that applications are developed according to industry best practices for secure coding techniques, including:
• Developing with fail-safe default (all execution is by default denied unless specified within initial design).
Developing applications with least privilege is the most effective way to ensure insecure assumptions aren’t introduced into the application. Including fail-safe defaults could prevent an attacker from obtaining sensitive information about an application failure that could then be used to create subsequent attacks. Ensuring that security is applied to all accesses and inputs into the application avoids the likelihood that an input channel may be left open to compromise. Failure to consider these concepts while developing code could result in the release of an insecure application and potentially excessive remediation at a later time.
5.1.6.b Interview developers to verify that applications are developed according to industry best practices for secure coding techniques, including:
Added
p. 44
5.1.6.1.a Examine coding techniques to verify they include documentation of how PAN and/or SAD are handled in memory.
Attackers use malware tools to capture sensitive data from memory. Minimizing the exposure of PAN/SAD while in memory will help reduce the likelihood that it can be captured by a malicious user or be unknowingly saved to disk in a memory file and left unprotected.
This requirement is intended to ensure that consideration is given for how PAN and SAD are handled in memory.
Understanding when and for how long sensitive data is present in memory, as well as in what format, will help application vendors to identify potential insecurities in their applications and determine whether additional protections are needed.
Whether or not any coding techniques result from this activity will depend on the particular software being developed and the technologies in use.
5.1.6.1.b Interview developers to verify that they consider how PAN/SAD are handled in memory …
Attackers use malware tools to capture sensitive data from memory. Minimizing the exposure of PAN/SAD while in memory will help reduce the likelihood that it can be captured by a malicious user or be unknowingly saved to disk in a memory file and left unprotected.
This requirement is intended to ensure that consideration is given for how PAN and SAD are handled in memory.
Understanding when and for how long sensitive data is present in memory, as well as in what format, will help application vendors to identify potential insecurities in their applications and determine whether additional protections are needed.
Whether or not any coding techniques result from this activity will depend on the particular software being developed and the technologies in use.
5.1.6.1.b Interview developers to verify that they consider how PAN/SAD are handled in memory …
Added
p. 45
• 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
• Security testing (for example, penetration- testing techniques)
• Risk-assessment techniques.
Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor-led, and computer-based.
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.
Ensuring developers are knowledgeable about secure development practices will help minimize the number of security vulnerabilities introduced through poor coding practices. Trained personnel are also more likely to identify potential security issues in the application design and code. Software-development platforms and methodologies change frequently, as do the threats and risks to software applications. Training in secure development practices should keep up to date …
• 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
• Security testing (for example, penetration- testing techniques)
• Risk-assessment techniques.
Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor-led, and computer-based.
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.
Ensuring developers are knowledgeable about secure development practices will help minimize the number of security vulnerabilities introduced through poor coding practices. Trained personnel are also more likely to identify potential security issues in the application design and code. Software-development platforms and methodologies change frequently, as do the threats and risks to software applications. Training in secure development practices should keep up to date …
Added
p. 45
The application layer is high-risk and may be targeted by both internal and external threats. Without proper security, cardholder data and other confidential company information can be exposed.
Requirements 5.2.1 through 5.2.9 are the minimum controls that should be in place. This list is composed of the most common coding vulnerabilities at the time that this version of the PA-DSS was published. As industry-recognized common coding vulnerabilities change, vendor coding practices should likewise be updated to match.
Note: Requirements 5.2.1 through 5.2.6, below, apply to all payment applications (internal or external):
Requirements 5.2.1 through 5.2.9 are the minimum controls that should be in place. This list is composed of the most common coding vulnerabilities at the time that this version of the PA-DSS was published. As industry-recognized common coding vulnerabilities change, vendor coding practices should likewise be updated to match.
Note: Requirements 5.2.1 through 5.2.6, below, apply to all payment applications (internal or external):
Added
p. 46
• Validating input to verify user data cannot modify meaning of commands and queries
• Utilizing parameterized queries.
Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, thereby exposing components inside the application to attacks such as buffer overflows.
All input data should be validated by the application before being processed•for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.
• Utilizing parameterized queries.
Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, thereby exposing components inside the application to attacks such as buffer overflows.
All input data should be validated by the application before being processed•for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.
Added
p. 46
• Validating buffer boundaries
• Truncating input strings.
Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.
• Truncating input strings.
Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.
Added
p. 46
• Prevent cryptographic flaws
• Use strong cryptographic algorithms and keys.
Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised and exposing authentication credentials and/or cardholder data.
• Use strong cryptographic algorithms and keys.
Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised and exposing authentication credentials and/or cardholder data.
Added
p. 47
Applications that fail to adequately encrypt sensitive network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data.
Added
p. 47
Applications that leak information about their configuration, internal workings, or expose privileged information through improper error-handling methods are at risk of compromise. Attackers use these weaknesses to steal sensitive data or compromise the system altogether. If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the application or system. For example, the message "incorrect password provided" tells an attacker that the user ID provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like "data could not be verified." 5.2.6 All “high risk” vulnerabilities as identified in the vulnerability identification process at PA- DSS Requirement 7.1 5.2.6 Coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PA-DSS Requirement 7.1.
All vulnerabilities determined by the vendor’s vulnerability risk-ranking …
All vulnerabilities determined by the vendor’s vulnerability risk-ranking …
Added
p. 48
• Proper authentication of users
• Not exposing internal object references to users
• User interfaces that do not permit access to unauthorized functions.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
An attacker who can enumerate and navigate the directory structure of a website (directory traversal) could gain access to unauthorized information as well as further insight into the workings of the site for later exploitation.
User interfaces that permit access to unauthorized functions could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Limiting access to data resources will help prevent cardholder data from being presented to unauthorized resources.
• Not exposing internal object references to users
• User interfaces that do not permit access to unauthorized functions.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
An attacker who can enumerate and navigate the directory structure of a website (directory traversal) could gain access to unauthorized information as well as further insight into the workings of the site for later exploitation.
User interfaces that permit access to unauthorized functions could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Limiting access to data resources will help prevent cardholder data from being presented to unauthorized resources.
Added
p. 49
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application).
Added
p. 49
• 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.
Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.
• Not exposing session IDs in the URL
• Incorporating appropriate time-outs and rotation of session IDs after a successful login.
Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.
Added
p. 49
• Verify the procedures follow documented software- development processes as defined in Requirement 5.1
• Verify that the procedures require items 5.3.1
If not properly managed, the impact of software updates and security patches might not be fully realized and could have unintended consequences.
5.3.b Interview developers to determine recent payment application changes. Examine recent payment application changes and trace them back to related change-control documentation. For each change examined, verify the following was documented according to the change-control procedures:
The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.
Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by management.
• Verify that the procedures require items 5.3.1
If not properly managed, the impact of software updates and security patches might not be fully realized and could have unintended consequences.
5.3.b Interview developers to determine recent payment application changes. Examine recent payment application changes and trace them back to related change-control documentation. For each change examined, verify the following was documented according to the change-control procedures:
The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.
Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by management.
Added
p. 50
Thorough testing should be performed to verify that the security of the payment application is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the application.
For each change, there should be back- out procedures in case the change fails or adversely affects the security of the application, to allow the application to be restored back to its previous state.
For each change, there should be back- out procedures in case the change fails or adversely affects the security of the application, to allow the application to be restored back to its previous state.
Added
p. 50
Verify that the documented versioning methodology is required to be followed for the payment application, including all changes to the payment application.
Without a thoroughly defined versioning methodology, changes to applications may not be properly identified, and customers and integrators/resellers may not understand the impact of a version change to the application.
Without a thoroughly defined versioning methodology, changes to applications may not be properly identified, and customers and integrators/resellers may not understand the impact of a version change to the application.
Added
p. 50
• 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).
(Continued on next page) 5.4.1.a Examine the documented versioning methodology to verify it includes the following:
• 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 alphabetic, numeric, and/or alphanumeric characters).
• 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.
Payment application vendor versioning methodology should include a defined version scheme that specifically identifies …
• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters).
(Continued on next page) 5.4.1.a Examine the documented versioning methodology to verify it includes the following:
• 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 alphabetic, numeric, and/or alphanumeric characters).
• 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.
Payment application vendor versioning methodology should include a defined version scheme that specifically identifies …
Added
p. 51
• Definition of elements that indicate use of wildcards.
• Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.)
Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 5.5.3 for additional requirements on the use of wildcards.
5.4.1.b Verify the elements of the version scheme are in accordance with the types of changes specified in the PA- DSS Program Guide.
The version scheme can be indicated in a number of ways•for example, N.NN.NNA, where “N” indicates a numeric element and “A” indicates an alphabetic element. The versioning scheme should include identification of the character set (for example, 0-9, A-Z, etc.) that can be used for each element in the version.
Without a properly defined version scheme, changes made to the application may not be accurately represented by the version number format.
5.4.1.c Examine …
• Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.)
Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 5.5.3 for additional requirements on the use of wildcards.
5.4.1.b Verify the elements of the version scheme are in accordance with the types of changes specified in the PA- DSS Program Guide.
The version scheme can be indicated in a number of ways•for example, N.NN.NNA, where “N” indicates a numeric element and “A” indicates an alphabetic element. The versioning scheme should include identification of the character set (for example, 0-9, A-Z, etc.) that can be used for each element in the version.
Without a properly defined version scheme, changes made to the application may not be accurately represented by the version number format.
5.4.1.c Examine …
Added
p. 51
• Descriptions of all types and impacts of application changes.
• Specific identification and definition of changes that:
• Specific identification and definition of changes that:
- Have no impact on functionality of the application or its dependencies
- Have no impact on functionality of the application or its dependencies
- Have impact on application functionality but no impact on security or PA-DSS requirements
- Have impact on application functionality but no impact on security or PA-DSS requirements
- Have impact to any security functionality or PA-DSS requirement.
• How each type of change ties to a specific version number.
• 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:
• Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application)
- Have impact to any security functionality or PA- DSS requirement.
5.4.2.b …
• Specific identification and definition of changes that:
• Specific identification and definition of changes that:
- Have no impact on functionality of the application or its dependencies
- Have no impact on functionality of the application or its dependencies
- Have impact on application functionality but no impact on security or PA-DSS requirements
- Have impact on application functionality but no impact on security or PA-DSS requirements
- Have impact to any security functionality or PA-DSS requirement.
• How each type of change ties to a specific version number.
• 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:
• Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application)
- Have impact to any security functionality or PA- DSS requirement.
5.4.2.b …
Added
p. 52
• Details of how wildcards are used in the versioning methodology.
• 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 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.
Note: Wildcards may only be used in accordance with the PA-DSS Program Guide.
5.4.3.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are …
• 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 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.
Note: Wildcards may only be used in accordance with the PA-DSS Program Guide.
5.4.3.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are …
Added
p. 53
• 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.
• 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.
Added
p. 53
• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.).
• 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.
Ensuring the vendors’ versioning methodology is included in the PA-DSS Implementation Guide will provide customers and integrators/resellers the necessary information to understand which version of the payment application they are using as well as the types of changes that have been made to each version of the payment application.
• 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.
Ensuring the vendors’ versioning methodology is included in the PA-DSS Implementation Guide will provide customers and integrators/resellers the necessary information to understand which version of the payment application they are using as well as the types of changes that have been made to each version of the payment application.
Added
p. 53
5.4.5.a Examine the documented version methodology to verify it includes a mapping of internal versions to published external versions.
Some payment application vendors have versioning methodologies for internal use or reference that differ from the versioning methodology used for external (or public) releases. In these situations it is important that both versioning methodologies are well defined and documented, and the relationship between them is thoroughly documented.
5.4.5.b Examine recent changes to confirm internal version mapping to published versioning scheme match according to the type of change.
Some payment application vendors have versioning methodologies for internal use or reference that differ from the versioning methodology used for external (or public) releases. In these situations it is important that both versioning methodologies are well defined and documented, and the relationship between them is thoroughly documented.
5.4.5.b Examine recent changes to confirm internal version mapping to published versioning scheme match according to the type of change.
Added
p. 54
5.4.6.a Examine documented software-development processes and the versioning methodology to verify there is a process in place to review application updates for conformity with the versioning methodology prior to release.
It is critical that payment application vendors have a process in place to ensure product updates match the intent and scope of the planned release, and that those changes are accurately communicated to customers. Otherwise, changes could be made to an application that may negatively impact a customer’s application security without their knowledge.
5.4.6.b Interview software developers and observe processes to verify that application updates are reviewed for conformity with the versioning methodology prior to release.
It is critical that payment application vendors have a process in place to ensure product updates match the intent and scope of the planned release, and that those changes are accurately communicated to customers. Otherwise, changes could be made to an application that may negatively impact a customer’s application security without their knowledge.
5.4.6.b Interview software developers and observe processes to verify that application updates are reviewed for conformity with the versioning methodology prior to release.
Added
p. 54
• 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.
• 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 vulnerabilities resulting from cardholder data flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of risk assessment results for management review and approval.
• Documentation of risk assessment results for management review and approval.
• Assessment of application decision points, process flows, data flows, data storage, and 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 vulnerabilities resulting from cardholder data flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of risk assessment results for management review and approval.
• Documentation of risk assessment results for management review and approval.
Added
p. 54
• Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross 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, and assign risk ratings (e.g. high, medium, or low priority) to each.
To maintain the quality and security of payment applications, risk assessment techniques should be employed by application vendors during the software- development process.
Threat modeling is a form of risk assessment that can be used to analyze an application’s constructs and data flows for opportunities where confidential information may be exposed to unauthorized application users. These processes allow software developers and architects to identify and resolve potential security issues early in the development …
• 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, and assign risk ratings (e.g. high, medium, or low priority) to each.
To maintain the quality and security of payment applications, risk assessment techniques should be employed by application vendors during the software- development process.
Threat modeling is a form of risk assessment that can be used to analyze an application’s constructs and data flows for opportunities where confidential information may be exposed to unauthorized application users. These processes allow software developers and architects to identify and resolve potential security issues early in the development …
Added
p. 55
• 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.
5.6.a Examine documented processes to verify that final release of the application and any application updates must be formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
Someone within the payment application vendor’s organization should be responsible for reviewing and ensuring all aspects of the secure development processes (as defined in Requirements 5.1 through 5.5) were performed. Without a formal review and acknowledgment from a responsible party, critical security processes may be missed or excluded, resulting in a faulty or less secure application.
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 …
• Confirmation that secure development processes were followed by the vendor.
5.6.a Examine documented processes to verify that final release of the application and any application updates must be formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
Someone within the payment application vendor’s organization should be responsible for reviewing and ensuring all aspects of the secure development processes (as defined in Requirements 5.1 through 5.5) were performed. Without a formal review and acknowledgment from a responsible party, critical security processes may be missed or excluded, resulting in a faulty or less secure application.
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 …
Added
p. 57
• Default SNMP community strings on wireless devices were
• changed at installation.
• changed at installation.
• Default passwords/passphrases on access points were
• Firmware on wireless devices is
• updated to support strong encryption for authentication and transmission over wireless networks.
• Other security-related wireless vendor defaults were changed, if applicable.
6.1.c For all wireless functionality managed by the payment application, follow instructions in the PA-DSS Implementation Guide for changing wireless encryption keys, passwords/passphrases, and SNMP strings. Verify that the PA-DSS Implementation Guide instructions are accurate and result in changed wireless encryption keys, passwords and SNMP strings.
6.1.d For all wireless components provided with, but not controlled by, the payment application, follow instructions in the PA-DSS Implementation Guide for changing default encryption keys, passwords/passphrases and SNMP community strings. Verify the PA-DSS Implementation Guide instructions are accurate and result in changed wireless encryption keys, passwords, and SNMP strings.
6.1.e Install the application and test wireless functions to verify …
• changed at installation.
• changed at installation.
• Default passwords/passphrases on access points were
• Firmware on wireless devices is
• updated to support strong encryption for authentication and transmission over wireless networks.
• Other security-related wireless vendor defaults were changed, if applicable.
6.1.c For all wireless functionality managed by the payment application, follow instructions in the PA-DSS Implementation Guide for changing wireless encryption keys, passwords/passphrases, and SNMP strings. Verify that the PA-DSS Implementation Guide instructions are accurate and result in changed wireless encryption keys, passwords and SNMP strings.
6.1.d For all wireless components provided with, but not controlled by, the payment application, follow instructions in the PA-DSS Implementation Guide for changing default encryption keys, passwords/passphrases and SNMP community strings. Verify the PA-DSS Implementation Guide instructions are accurate and result in changed wireless encryption keys, passwords, and SNMP strings.
6.1.e Install the application and test wireless functions to verify …
Added
p. 59
Note: This requirement applies to all payment applications, regardless of whether the application is developed for use with wireless technologies.
Aligns with PCI DSS Requirements 1.2.3, 2.1.1, & 4.1.1 6.3 Examine the PA-DSS Implementation Guide prepared by the vendor to verify customers and integrators/resellers are instructed on PCI DSS-compliant wireless settings, including changing wireless vendor defaults and using industry best practices to implement strong encryption for authentication and transmission of cardholder data, as follows:
• 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 traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the …
Aligns with PCI DSS Requirements 1.2.3, 2.1.1, & 4.1.1 6.3 Examine the PA-DSS Implementation Guide prepared by the vendor to verify customers and integrators/resellers are instructed on PCI DSS-compliant wireless settings, including changing wireless vendor defaults and using industry best practices to implement strong encryption for authentication and transmission of cardholder data, as follows:
• 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 traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the …
Added
p. 60
• 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).
Reputable sources should be used for vulnerability information and/or patches in third-party software components. Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing lists, or RSS feeds. Examples of industry sources include NIST’s National Vulnerability Database, MITRE’s Common Vulnerabilities and Exposures list, and the US Department of Homeland Security’s US-CERT websites.
• Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US-CERT websites).
Reputable sources should be used for vulnerability information and/or patches in third-party software components. Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing lists, or RSS feeds. Examples of industry sources include NIST’s National Vulnerability Database, MITRE’s Common Vulnerabilities and Exposures list, and the US Department of Homeland Security’s US-CERT websites.
Added
p. 61
Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the application. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat, impact critical application components, or would result in a potential compromise if not addressed.
Added
p. 61
Once the vendor identifies a vulnerability that could affect their application, the risk that the vulnerability poses must be evaluated and ranked. This requires a process to actively monitor industry sources for vulnerability information.
Classifying the risks (for example, as “high,” “medium,” or “low”) allows vendors to identify, prioritize and address the highest risk items (for example, by releasing high-priority patches more quickly), and reduce the likelihood that vulnerabilities posing the greatest risk to customer environments will be exploited.
Classifying the risks (for example, as “high,” “medium,” or “low”) allows vendors to identify, prioritize and address the highest risk items (for example, by releasing high-priority patches more quickly), and reduce the likelihood that vulnerabilities posing the greatest risk to customer environments will be exploited.
Added
p. 61
Adequate testing should be included in any payment application vendor’s vulnerability management process to ensure that any identified vulnerabilities have been properly addressed prior to release.
Examples of testing methods may include penetration testing and/or fuzz-testing techniques to identify potential vulnerabilities•for example, by injecting malformed or unexpected data, or modifying the bit size of the data.
Examples of testing methods may include penetration testing and/or fuzz-testing techniques to identify potential vulnerabilities•for example, by injecting malformed or unexpected data, or modifying the bit size of the data.
Added
p. 61
Software updates to address security vulnerabilities should be developed and released to customers as quickly as possible once a critical vulnerability has been identified, to minimize the timeframe and likelihood that the vulnerability could be exploited.
Added
p. 62
Security patches must be distributed in a manner that prevents malicious individuals from intercepting the updates in transit, modifying them, and then redistributing them to unsuspecting customers.
Added
p. 62
7.2.2.a Interview responsible personnel and observe processes to verify patches and updates are delivered to customers in a manner that maintains the integrity of the patch and update code.
Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include, but are not limited to, checksums, digitally-signed certificates, etc.
7.2.2.b Interview responsible personnel and observe application update processes to verify patches and updates are integrity-tested on the target system prior to installation.
7.2.2.c Verify that the integrity of patch and update code is maintained by running the update process with arbitrary code and determining that the system will not allow the update to occur.
Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include, but are not limited to, checksums, digitally-signed certificates, etc.
7.2.2.b Interview responsible personnel and observe application update processes to verify patches and updates are integrity-tested on the target system prior to installation.
7.2.2.c Verify that the integrity of patch and update code is maintained by running the update process with arbitrary code and determining that the system will not allow the update to occur.
Added
p. 62
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.
Release notes provide customers with details about software updates, including which files may have changed, which application functionality was modified, as well as any security-related features that may be affected. Release notes should also indicate how a particular patch or update affects the overall version number associated with the patch release.
7.3.b Examine release notes for a sample of application updates and verify they were provided with the update.
For example, payment application cannot interfere with installation of patches, anti-malware protection, firewall configurations, or any other device, application, or configuration required for PCI DSS compliance.
Payment applications should be designed and developed in such a way that the installation and operation of the application must not prevent …
Release notes provide customers with details about software updates, including which files may have changed, which application functionality was modified, as well as any security-related features that may be affected. Release notes should also indicate how a particular patch or update affects the overall version number associated with the patch release.
7.3.b Examine release notes for a sample of application updates and verify they were provided with the update.
For example, payment application cannot interfere with installation of patches, anti-malware protection, firewall configurations, or any other device, application, or configuration required for PCI DSS compliance.
Payment applications should be designed and developed in such a way that the installation and operation of the application must not prevent …
Added
p. 64
• 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.
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 two-factor authentication technologies for remote access.
Payment applications should be designed and developed in such a way that the installation and operation of the application must not require an organization to use services or protocols that would inhibit that organization from implementing and operating two-factor authentication solutions for secure remote access. For example, the application should not, by default, use port 1812 (which is universally known to be assigned to RADIUS …
• 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.
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 two-factor authentication technologies for remote access.
Payment applications should be designed and developed in such a way that the installation and operation of the application must not require an organization to use services or protocols that would inhibit that organization from implementing and operating two-factor authentication solutions for secure remote access. For example, the application should not, by default, use port 1812 (which is universally known to be assigned to RADIUS …
Added
p. 67
• 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.
• If remote access is via VPN or other high-speed connection, the connection is secured according to PCI DSS Requirement 1.
Added
p. 67
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 password is used for each customer environment they have access to.
To prevent the compromise of multiple customers’ environments through the use of a single set of credentials, vendors with remote-access accounts to customer environments should use a different authentication credential for each customer.
Avoid the use of repeatable formulas to generate password that are easily guessed. These credentials become known over time and can be used by unauthorized individuals to compromise the vendor’s customers.
To prevent the compromise of multiple customers’ environments through the use of a single set of credentials, vendors with remote-access accounts to customer environments should use a different authentication credential for each customer.
Avoid the use of repeatable formulas to generate password that are easily guessed. These credentials become known over time and can be used by unauthorized individuals to compromise the vendor’s customers.
Added
p. 68
• 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 Requirements 3.1.9 through 3.1.10.)
• Establish a VPN connection via a firewall before access is allowed.
• Establish a VPN connection via a firewall before access is allowed.
Aligns with PCI DSS Requirements 2, 8 and 10 10.2.3.a Examine the PA-DSS Implementation Guide prepared by the vendor, and verify that customers and integrators/resellers are instructed that all remote access to the payment application must be implemented securely for example:
• 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 …
• Enable account lockout after a certain number of failed login attempts. (See PA- DSS Requirements 3.1.9 through 3.1.10.)
• Establish a VPN connection via a firewall before access is allowed.
• Establish a VPN connection via a firewall before access is allowed.
Aligns with PCI DSS Requirements 2, 8 and 10 10.2.3.a Examine the PA-DSS Implementation Guide prepared by the vendor, and verify that customers and integrators/resellers are instructed that all remote access to the payment application must be implemented securely for example:
• 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 …
Added
p. 69
• 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 Examples of open, public networks include but are not limited to:
• 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)
Because it is easy and common for a malicious individual to intercept and/or divert data while in transit, sensitive information must be encrypted during transmission over public networks.
Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data.
Note that some protocol implementations (such as SSL version 2.0, SSH version 1.0, and TLS 1.0) have documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the …
• The protocol in use only supports secure versions or configurations
• The encryption strength is appropriate for the encryption methodology in use Examples of open, public networks include but are not limited to:
• 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)
Because it is easy and common for a malicious individual to intercept and/or divert data while in transit, sensitive information must be encrypted during transmission over public networks.
Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data.
Note that some protocol implementations (such as SSL version 2.0, SSH version 1.0, and TLS 1.0) have documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the …
Added
p. 72
• 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.
13.1.3.a Examine the PA-DSS Implementation Guide and interview personnel to verify the PA-DSS Implementation Guide is reviewed:
• Upon changes to the application
• Upon changes to these PA-DSS requirements.
With each application update, system functionality and, in some cases, critical application security mechanisms are modified or introduced. If the PA-DSS Implementation Guide is not kept current with the latest versions of the payment application, customers and integrators/resellers could overlook or misconfigure critical application security controls that could ultimately enable an attacker to bypass such security mechanisms and compromise sensitive data.
• Changes to the PA-DSS requirements
• Changes to the application or its dependencies.
• Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.
13.1.3.a Examine the PA-DSS Implementation Guide and interview personnel to verify the PA-DSS Implementation Guide is reviewed:
• Upon changes to the application
• Upon changes to these PA-DSS requirements.
With each application update, system functionality and, in some cases, critical application security mechanisms are modified or introduced. If the PA-DSS Implementation Guide is not kept current with the latest versions of the payment application, customers and integrators/resellers could overlook or misconfigure critical application security controls that could ultimately enable an attacker to bypass such security mechanisms and compromise sensitive data.
• Changes to the PA-DSS requirements
• Changes to the application or its dependencies.
Added
p. 74
Requirement 14: Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators PA-DSS Requirements Testing Procedures Guidance 14.1 Provide training in information security and PA-DSS for vendor personnel with PA-DSS responsibility at least annually.
Added
p. 74
In order for a payment application to be designed effectively to meet PA-DSS guidelines, payment application vendor personnel should be knowledgeable in PA- DSS and their responsibilities with regards to ongoing PA-DSS assessments. It is the responsibility of the payment application vendor to ensure their personnel are properly educated in these areas.
Added
p. 74
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training 14.2.a Examine documented responsibilities to verify that responsibility for the following roles is formally assigned:
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
Within each payment application vendor organization, a responsible party (either an individual or a team) should be assigned formal responsibility for PA-DSS to ensure all PA-DSS requirements are met accordingly.
14.2.b Interview personnel assigned responsibility for the following roles to confirm that roles and responsibilities are defined and understood:
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
Within each payment application vendor organization, a responsible party (either an individual or a team) should be assigned formal responsibility for PA-DSS to ensure all PA-DSS requirements are met accordingly.
14.2.b Interview personnel assigned responsibility for the following roles to confirm that roles and responsibilities are defined and understood:
Added
p. 75
• 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).
• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
Incorrect configuration, maintenance or support of an application may lead to security vulnerabilities being introduced into the customer’s cardholder data environment, which could then be exploited by attackers. Application vendors should provide training for integrator/resellers in the secure installation and configuration of the application to ensure that, when installed in the merchant’s environment, the application facilitates PCI DSS compliance It is the responsibility of the payment application vendor to provide integrators and resellers with training in these areas.
14.3.b Examine the vendor’s communication programs and related vendor processes, and interview vendor personnel to verify:
• Training materials are provided to integrators and …
• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
Incorrect configuration, maintenance or support of an application may lead to security vulnerabilities being introduced into the customer’s cardholder data environment, which could then be exploited by attackers. Application vendors should provide training for integrator/resellers in the secure installation and configuration of the application to ensure that, when installed in the merchant’s environment, the application facilitates PCI DSS compliance It is the responsibility of the payment application vendor to provide integrators and resellers with training in these areas.
14.3.b Examine the vendor’s communication programs and related vendor processes, and interview vendor personnel to verify:
• Training materials are provided to integrators and …
Added
p. 75
Update the training materials as needed to keep the documentation current with new payment application versions and changes to PA-DSS requirements.
14.3.1.a Examine the training materials for integrators and resellers and verify the materials are:
• 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.
Training materials for payment application vendor personnel, integrators and resellers should be updated at least annually to ensure the materials remain current with the latest versions of the applications and PA-DSS requirements. Use of outdated training materials could render training programs ineffective, leading to poorly designed security functions within the application or improper application configurations by integrators and resellers.
14.3.1.a Examine the training materials for integrators and resellers and verify the materials are:
• 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.
Training materials for payment application vendor personnel, integrators and resellers should be updated at least annually to ensure the materials remain current with the latest versions of the applications and PA-DSS requirements. Use of outdated training materials could render training programs ineffective, leading to poorly designed security functions within the application or improper application configurations by integrators and resellers.
Added
p. 76
Software Vendor: Provide tool or procedure for customers to securely remove sensitive authentication data stored by previous versions, per PA-DSS Requirement 1.1.4.
Software Vendor: Do not store sensitive authentication data; and perform any troubleshooting of customer’s problems according to PA-DSS Requirement 1.1.5.a.
Software Vendor: Do not store sensitive authentication data; and perform any troubleshooting of customer’s problems according to PA-DSS Requirement 1.1.5.a.
Added
p. 77
Instruction that cardholder data exceeding the customer-defined retention period must be securely deleted. A list of all locations where payment application stores cardholder data, so that customer knows the locations of data that needs to be deleted. Instruction that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes. How to securely delete cardholder data stored by the payment application, including data stored on underlying software or systems (such as OS, databases, etc.). How to configure the underlying software or systems (such as OS, databases, etc.) to prevent inadvertent capture or retention of cardholder data.
Software Vendor: Provide guidance to customers that cardholder data exceeding customer-defined retention periods must be securely deleted where such data is stored by the payment application and underlying software or systems, and how to securely delete cardholder data stored by the payment application.
Software Vendor: Provide guidance to customers that cardholder data exceeding customer-defined retention periods must be securely deleted where such data is stored by the payment application and underlying software or systems, and how to securely delete cardholder data stored by the payment application.
Added
p. 77
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.
Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see the full PAN.
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.
Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see the full PAN.
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.
Added
p. 78
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 merchant to store outside of the payment application, and instructions that the merchant is responsible for rendering PAN unreadable in all such instances.
Software Vendor: Provide instructions to customers for rendering PAN unreadable anywhere it is stored or output by the application.
Customers & Integrators/Resellers: Render PAN unreadable anywhere it is stored per the PA-DSS Implementation Guide and PA-DSS Requirement 2.3.
Software Vendor: Provide instructions to customers for rendering PAN unreadable anywhere it is stored or output by the application.
Customers & Integrators/Resellers: Render PAN unreadable anywhere it is stored per the PA-DSS Implementation Guide and PA-DSS Requirement 2.3.
Added
p. 78
Restrict access to keys to the fewest number of custodians necessary. Store keys securely in the fewest possible locations and forms.
Customers & Integrators/Resellers: Store keys securely in the fewest possible locations, and restrict access to keys to the fewest possible custodians, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.4.
Customers & Integrators/Resellers: Store keys securely in the fewest possible locations, and restrict access to keys to the fewest possible custodians, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.4.
Added
p. 79
Provide instructions for customers and integrators/resellers on how to perform key- management functions including:
Generation of strong cryptographic keys. Secure cryptographic key distribution. Secure cryptographic key storage. Cryptographic key changes for keys that have reached the end of their cryptoperiod. Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised. Split knowledge and dual control for any manual clear-text cryptographic key-management operations supported by the payment application. Prevention of unauthorized substitution of cryptographic keys.
Software Vendor: Provide instructions to customers to implement secure key-management functions.
Customers & Integrators/Resellers: Implement secure key-management functions for cryptographic keys per PA-DSS Implementation Guide and PA-DSS Requirements 2.5.1
• 2.5.7.
Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable. Instruction that cryptographic key material be rendered irretrievable whenever …
Generation of strong cryptographic keys. Secure cryptographic key distribution. Secure cryptographic key storage. Cryptographic key changes for keys that have reached the end of their cryptoperiod. Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised. Split knowledge and dual control for any manual clear-text cryptographic key-management operations supported by the payment application. Prevention of unauthorized substitution of cryptographic keys.
Software Vendor: Provide instructions to customers to implement secure key-management functions.
Customers & Integrators/Resellers: Implement secure key-management functions for cryptographic keys per PA-DSS Implementation Guide and PA-DSS Requirements 2.5.1
• 2.5.7.
Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable. Instruction that cryptographic key material be rendered irretrievable whenever …
Added
p. 80
Directions on how the payment application enforces strong authentication for any authentication credentials (for example, users, passwords) that the application generates or manages, by: - 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 default accounts (even if not used), and disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PA-DSS Requirements 3.1.1 through 3.1.11, by the completion of installation and for subsequent changes after installation, for all …
- 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 default accounts (even if not used), and disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PA-DSS Requirements 3.1.1 through 3.1.11, by the completion of installation and for subsequent changes after installation, for all …
Added
p. 81
Provide a description of which centralized logging mechanisms are supported, as well as instructions and procedures for incorporating the payment application logs into a centralized logging server.
Added
p. 82
Provide a description of the vendor’s published versioning methodology and include guidance for the following:
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.). Details of how security-impacting changes will be indicated by the versioning scheme. Details of how other types of changes will affect the version. Details of any wildcard elements that are used, including that they will never be used to represent a security-impacting change.
Software Vendor: Document and implement a software-versioning methodology as part of the system development lifecycle. The methodology must follow the procedures in the PA-DSS Program Guide for changes to payment applications, per PA-DSS Requirement 5.5.
Customers & Integrators/Resellers: Understand which version of the payment application they are using, and ensure validated versions are in use.
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.). Details of how security-impacting changes will be indicated by the versioning scheme. Details of how other types of changes will affect the version. Details of any wildcard elements that are used, including that they will never be used to represent a security-impacting change.
Software Vendor: Document and implement a software-versioning methodology as part of the system development lifecycle. The methodology must follow the procedures in the PA-DSS Program Guide for changes to payment applications, per PA-DSS Requirement 5.5.
Customers & Integrators/Resellers: Understand which version of the payment application they are using, and ensure validated versions are in use.
Added
p. 83
For payment applications developed for use with wireless technology, the following must be provided for customers and integrators/resellers:
Instruction that 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. Instructions to configure firewalls to deny or (if such traffic is necessary for business purposes) permit only authorized traffic …
Instruction that 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. Instructions to configure firewalls to deny or (if such traffic is necessary for business purposes) permit only authorized traffic …
Added
p. 84
For payment applications developed for use with wireless technology, include instructions for using industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data. This includes:
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.
Software Vendor: Instruct customers and integrators/resellers, that if wireless technology is used with the payment application, secure encrypted transmissions must be implemented per PA-DSS Requirement 6.2.
Customers & Integrators/Resellers: For wireless implemented into the payment environment by customers or integrators/resellers, use secure encrypted transmissions per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
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.
Software Vendor: Instruct customers and integrators/resellers, that if wireless technology is used with the payment application, secure encrypted transmissions must be implemented per PA-DSS Requirement 6.2.
Customers & Integrators/Resellers: For wireless implemented into the payment environment by customers or integrators/resellers, use secure encrypted transmissions per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
Added
p. 84
Provide instructions for PCI DSS-compliant wireless settings, including:
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 control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.
Software Vendor: Instruct customers and integrators/resellers, to secure wireless technologies per PA-DSS Requirement 6.3.
Customers & Integrators/Resellers: Secure wireless technologies per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
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 control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.
Software Vendor: Instruct customers and integrators/resellers, to secure wireless technologies per PA-DSS Requirement 6.3.
Customers & Integrators/Resellers: Secure wireless technologies per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
Added
p. 85
Customers and Integrators/Resellers: Use the documented list from the PA-DSS Implementation Guide to ensure only necessary and secure protocols, services, etc., are used on the system, in accordance with PA-DSS Requirement 5.4.
Instructions not to store cardholder data on public- facing systems (for example, web server and database server must not be on same server). Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data. A list of services/ports that the application needs to use in order to communicate across two network zones (so the merchant can configure their firewall to open only required ports).
Instructions not to store cardholder data on public- facing systems (for example, web server and database server must not be on same server). Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data. A list of services/ports that the application needs to use in order to communicate across two network zones (so the merchant can configure their firewall to open only required ports).
Added
p. 86
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. Description of 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).
If payment application updates are delivered via remote access into customers’ systems, provide the following:
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. Description of 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).
If payment application updates are delivered via remote access into customers’ systems, provide the following:
Added
p. 87
Include instructions that all remote access to the payment application must be implemented securely, for example:
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 Virtual Private Network (“VPN”) connection via a firewall before access is allowed. Enable the logging function. Restrict access to customer environments to authorized integrator/reseller personnel.
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 Virtual Private Network (“VPN”) connection via a firewall before access is allowed. Enable the logging function. Restrict access to customer environments to authorized integrator/reseller personnel.
Added
p. 88
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 protocols. How to configure the payment application to use the proper encryption strength for the encryption methodology in use.
If the payment application facilitates sending of PANs by end-user messaging technologies, include instructions for implementing and using a solution that renders the PAN unreadable or implements strong cryptography, including:
Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography. Instruction that PAN …
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 protocols. How to configure the payment application to use the proper encryption strength for the encryption methodology in use.
If the payment application facilitates sending of PANs by end-user messaging technologies, include instructions for implementing and using a solution that renders the PAN unreadable or implements strong cryptography, including:
Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography. Instruction that PAN …
Added
p. 89
Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or SSL/TLS, for encryption of all non-console administrative access.
Added
p. 90
For each Laboratory Validation Procedure, the PA-QSA must indicate whether the laboratory used for the assessment and the laboratory undergoing these validation procedures was the PA-QSA’s laboratory or software vendor’s laboratory. PA-QSAs are required to maintain a testing laboratory that meets all of the requirements set out below and use their own laboratory to conduct assessments whenever possible. The software vendor’s laboratory may only be used when necessary (for example, the PA-QSA does not have the mainframe, AS400, or Tandem the payment application runs on) and after verifying that all laboratory requirements are met.
The PA-QSA must confirm all items in the table below, as well as:
Identification of location and owner of lab(s) used for the PA-DSS review Description of laboratory testing architecture and environment in place for the PA-DSS review Description of how the real-world use of the payment application was simulated in the laboratory for the …
The PA-QSA must confirm all items in the table below, as well as:
Identification of location and owner of lab(s) used for the PA-DSS review Description of laboratory testing architecture and environment in place for the PA-DSS review Description of how the real-world use of the payment application was simulated in the laboratory for the …
Added
p. 92
7.c All testing is executed by the PA-QSA (the vendor cannot run tests against their own application).
8. Maintain an effective quality assurance (QA) process.
8. Maintain an effective quality assurance (QA) process.
Removed
p. 4
The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. This document, which can be found at www.pcisecuritystandards.org, details what is required to be PCI DSS compliant (and therefore what a payment application must support to facilitate a customer’s PCI DSS compliance).
Modified
p. 4 → 5
Relationship between PCI DSS and PA-DSS Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor (per PA-DSS Requirement 13.1).
Relationship between PCI DSS and PA-DSS Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor (per PA-DSS Requirement 13). The PA-DSS requirements are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures, which details what is required to be PCI DSS …
Modified
p. 4 → 5
PCI DSS may not apply directly to payment application vendors unless the vendor stores, processes, or transmits cardholder data, or has access to their customers’ cardholder data. However, since these payment applications are used by the application vendor’s customers to store, process, and transmit cardholder data, and their customers are required to be PCI DSS compliant, payment applications should facilitate, and not prevent, their customers' PCI DSS compliance. Just a few of the ways insecure payment applications can prevent compliance …
Modified
p. 4 → 5
Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.
Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of primary account number (PAN), full track data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks, and the damaging fraud resulting from these breaches.
Removed
p. 5
The following guide can be used to determine whether PA-DSS applies to a given payment application:
PA-DSS does apply to payment applications that are typically sold and installed “off the shelf” without much customization by software vendors.
PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA- DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a “best practice” for software vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS.
…
PA-DSS does apply to payment applications that are typically sold and installed “off the shelf” without much customization by software vendors.
PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA- DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a “best practice” for software vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS.
…
Removed
p. 6
PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance.
For example, for the last two bullets above, whether the in-house developed or “bespoke” payment application stores prohibited sensitive authentication data or allows complex passwords would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance efforts and would not require a separate PA-DSS assessment.
The following list, while not all-inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):
Operating systems onto which a payment application is installed (for example, Windows, Unix) Database systems that store cardholder data (for example, Oracle) Back-office systems that store cardholder …
For example, for the last two bullets above, whether the in-house developed or “bespoke” payment application stores prohibited sensitive authentication data or allows complex passwords would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance efforts and would not require a separate PA-DSS assessment.
The following list, while not all-inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):
Operating systems onto which a payment application is installed (for example, Windows, Unix) Database systems that store cardholder data (for example, Oracle) Back-office systems that store cardholder …
Modified
p. 7 → 9
The remainder of this section applies only to payment applications that that are resident on a validated PCI PTS approved POI device.
The remainder of this section applies only to payment applications that are resident on a validated PCI PTS approved POI device.
Modified
p. 7 → 9
When conducting the PA-DSS assessment, the PA-QSA must fully test the payment application with its dependant hardware against all PA-DSS requirements. If the PA-QSA determines that one or more PA-DSS requirements cannot be met by the resident payment application, but they are met by controls validated under PCI PTS, the PA-QSA must:
When conducting the PA-DSS assessment, the PA-QSA must fully test the payment application with its dependent hardware against all PA-DSS requirements. If the PA-QSA determines that one or more PA-DSS requirements cannot be met by the resident payment application, but they are met by controls validated under PCI PTS, the PA-QSA must:
Modified
p. 7 → 10
1. Be provided together to the customer (both hardware terminal and application), OR, if provided separately, the application vendor and/or the reseller/integrator must package the application for distribution such that it will operate only on the hardware terminal it has been validated to run on.
1. Be provided together to the customer (both hardware terminal and application), OR, if provided separately, the application vendor and/or the integrator/reseller must package the application for distribution such that it will operate only on the hardware terminal it has been validated to run on.
Modified
p. 7 → 10
4. If the application is separately sold, distributed or licensed to customers, the vendor must provide details of the dependant hardware required for use with the application, in accordance with its PA-DSS validation listing.
4. If the application is separately sold, distributed, or licensed to customers, the vendor must provide details of the dependent hardware required for use with the application, in accordance with its PA-DSS validation listing.
Removed
p. 8
The following defines the roles and responsibilities of the stakeholders in the payment application community. Those stakeholders that are involved in the assessment process have those related responsibilities listed.
Payment Brands American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. are the payment brands that founded the PCI SSC. These payment brands are responsible for developing and enforcing any programs related to PA-DSS compliance, including, but not limited to, the following:
Any requirements, mandates, or dates for use of PA-DSS compliant payment applications Any fines or penalties related to use of non-compliant payment applications The payment brands may define compliance programs, mandates, dates, etc., using PA-DSS and the validated payment applications listed by PCI SSC. Through these compliance programs, the payment brands promote use of the listed validated payment applications.
Payment Card Industry Security Standards Council (PCI SSC)
PCI SSC is the standards body that maintains the payment card …
Payment Brands American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. are the payment brands that founded the PCI SSC. These payment brands are responsible for developing and enforcing any programs related to PA-DSS compliance, including, but not limited to, the following:
Any requirements, mandates, or dates for use of PA-DSS compliant payment applications Any fines or penalties related to use of non-compliant payment applications The payment brands may define compliance programs, mandates, dates, etc., using PA-DSS and the validated payment applications listed by PCI SSC. Through these compliance programs, the payment brands promote use of the listed validated payment applications.
Payment Card Industry Security Standards Council (PCI SSC)
PCI SSC is the standards body that maintains the payment card …
Removed
p. 9
PA-QSAs are responsible for:
Performing assessments on payment applications in accordance with the Security Assessment Procedures and the PA-QSA Validation Requirements Providing an opinion regarding whether the payment application meets PA-DSS requirements Providing adequate documentation within the ROV to demonstrate the payment application’s compliance to the PA-DSS Submitting the ROV to PCI SSC, along with the Attestation of Validation (signed by both PA-QSA and vendor) Maintaining an internal quality assurance process for their PA-QSA efforts It is the PA-QSA’s responsibility to state whether the payment application has achieved compliance. PCI SSC does not approve ROVs from a technical compliance perspective, but performs QA reviews on the ROVs to assure that the reports adequately document the demonstration of compliance.
Resellers and Integrators Resellers and integrators are those entities that sell, install, and/or service payment applications on behalf of software vendors or others. Resellers and integrators are responsible for:
…
Performing assessments on payment applications in accordance with the Security Assessment Procedures and the PA-QSA Validation Requirements Providing an opinion regarding whether the payment application meets PA-DSS requirements Providing adequate documentation within the ROV to demonstrate the payment application’s compliance to the PA-DSS Submitting the ROV to PCI SSC, along with the Attestation of Validation (signed by both PA-QSA and vendor) Maintaining an internal quality assurance process for their PA-QSA efforts It is the PA-QSA’s responsibility to state whether the payment application has achieved compliance. PCI SSC does not approve ROVs from a technical compliance perspective, but performs QA reviews on the ROVs to assure that the reports adequately document the demonstration of compliance.
Resellers and Integrators Resellers and integrators are those entities that sell, install, and/or service payment applications on behalf of software vendors or others. Resellers and integrators are responsible for:
…
Removed
p. 10
Implementing a PA-DSS-compliant payment application into a PCI DSS-compliant environment Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor Configuring the payment application in a PCI DSS-compliant manner Maintaining the PCI DSS-compliant status for both the environment and the payment application configuration PA-DSS Implementation Guide Validated payment applications must be capable of being implemented in a PCI DSS-compliant manner. Software vendors are required to provide a PA-DSS Implementation Guide to instruct their customers and resellers/integrators on secure product implementation, to document the secure configuration specifics mentioned throughout this document, and to clearly delineate vendor, reseller/integrator, and customer responsibilities for meeting PCI DSS requirements. It should detail how the customer and/or reseller/integrator should enable security settings within the customer’s network. For example, the PA-DSS Implementation Guide should cover responsibilities and basic features of PCI DSS password security …
Modified
p. 10 → 12
The PA-QSA must utilize the testing procedures documented in this Payment Application Data Security Standard document.
Modified
p. 10 → 12
The PA-QSA must have access to a laboratory where the validation process is to occur.
Modified
p. 11 → 12
The testing laboratory should be able to simulate real-world use of the payment application.
Modified
p. 11 → 12
The PA-QSA must validate the clean installation of the lab environment to ensure the environment truly simulates a real world situation and that the vendor has not modified or tampered with the environment in any way.
Modified
p. 11 → 12
Please refer to Appendix B: Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment in this document for detailed requirements for the laboratory and related laboratory processes.
Modified
p. 11 → 12
PA-QSA must complete and submit Appendix B, completed for the specific laboratory used for the payment application under review, as part of the completed PA-DSS Report on Validation (ROV).
Removed
p. 12
PCI DSS Applicability Information (Excerpted from PCI DSS) The Payment Card Industry Data Security Standard (PCI DSS) applies wherever account data is stored, processed or transmitted. Account Data consists of Cardholder Data plus Sensitive Authentication Data, as follows.
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full magnetic stripe data or equivalent on a chip CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number (PAN) is the defining factor in the applicability of PCI DSS requirements and PA-DSS. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS and PA-DSS do not apply.
If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with all PCI DSS requirements …
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full magnetic stripe data or equivalent on a chip CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number (PAN) is the defining factor in the applicability of PCI DSS requirements and PA-DSS. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS and PA-DSS do not apply.
If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with all PCI DSS requirements …
Removed
p. 13
PCI DSS Requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4.
PCI DSS only applies if PANs are stored, processed, and/or transmitted.
PCI DSS only applies if PANs are stored, processed, and/or transmitted.
Removed
p. 14
The Report on Validation should contain the following information as a preface to the detailed Requirements and Security Assessment Procedures:
1. Description of Scope of Review Describe scope of review coverage, per the Scope of PA-DSS section above Timeframe of validation PA-DSS version used for the assessment List of documentation reviewed
2. Executive Summary Include the following: Product Name Product Version and related platforms covered List of resellers and/or integrators for this product Operating system(s) with which the payment application was tested Database software used or supported by the payment application Brief description of the payment application/family of products (2-3 sentences) Network diagram of a typical implementation of the payment application (not necessarily a specific implementation at a customer’s site) that includes, at high level: - Connections into and out of a customer’s network - Components within the customer’s network, including …
1. Description of Scope of Review Describe scope of review coverage, per the Scope of PA-DSS section above Timeframe of validation PA-DSS version used for the assessment List of documentation reviewed
2. Executive Summary Include the following: Product Name Product Version and related platforms covered List of resellers and/or integrators for this product Operating system(s) with which the payment application was tested Database software used or supported by the payment application Brief description of the payment application/family of products (2-3 sentences) Network diagram of a typical implementation of the payment application (not necessarily a specific implementation at a customer’s site) that includes, at high level: - Connections into and out of a customer’s network - Components within the customer’s network, including …
Removed
p. 15
3. Findings and Observations All PA-QSAs must use the following template to provide detailed report descriptions and findings Describe tests performed other than those included in the testing procedures column. If the assessor determines that a requirement is not applicable for a given payment application, an explanation must be included in the “In Place” column for that requirement.
4. Contact Information and Report Date Software vendor contact information (include URL, phone number, and e-mail address) PA-QSA contact information (include name, phone number and e-mail address) PA-QSA Quality Assurance (QA) primary contact information (include primary QA contact’s name, phone number and e-mail address) Date of report
Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment must also be completed and submitted with the completed PA- DSS report.
1. Complete the Report on Validation using this document as a template: a. Complete the preface for the Report on …
4. Contact Information and Report Date Software vendor contact information (include URL, phone number, and e-mail address) PA-QSA contact information (include name, phone number and e-mail address) PA-QSA Quality Assurance (QA) primary contact information (include primary QA contact’s name, phone number and e-mail address) Date of report
Confirmation of Testing Laboratory Configuration Specific to PA-DSS Assessment must also be completed and submitted with the completed PA- DSS report.
1. Complete the Report on Validation using this document as a template: a. Complete the preface for the Report on …
Modified
p. 16 → 13
3. Complete the Report on Validation (ROV) using the PA-DSS ROV Reporting Template, including confirmation of the testing laboratory configuration used for the PA-DSS assessment.
Modified
p. 16 → 13
4. Complete and sign an Attestation of Validation (both PA-QSA and software vendor). The Attestation of Validation is available on the PCI SSC website (www.pcisecuritystandards.org).
Removed
p. 17
By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction has completed the authorization process and the customer has received the final transaction approval. After authorization has completed, this sensitive authentication data cannot be stored.
It is permissible for Issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.
1.1.c For each item of sensitive authentication data below, perform the following steps after completing numerous test transactions that simulate all functions of the payment application, to include generation of error conditions and log entries.
It is permissible for Issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.
1.1.c For each item of sensitive authentication data below, perform the following steps after completing numerous test transactions that simulate all functions of the payment application, to include generation of error conditions and log entries.
Modified
p. 17 → 15
Requirement 1: Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data PA-DSS Requirements Testing Procedures Guidance 1.1 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.
Modified
p. 17 → 15
1.1.b For all other payment applications, if sensitive authentication data (see 1.1.1•1.1.3 below) is stored prior to authorization and then deleted, obtain and review methodology for deleting the data to determine that the data is unrecoverable.
1.1.b For all other payment applications, if sensitive authentication data (see 1.1.1
• 1.1.3 below) is stored prior to authorization, obtain and review methodology for securely deleting the data to verify that the data is unrecoverable.
• 1.1.3 below) is stored prior to authorization, obtain and review methodology for securely deleting the data to verify that the data is unrecoverable.
Modified
p. 18 → 16
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The accountholder’s name, Primary account number (PAN), Expiration date, and Service code To minimize risk, store only those data elements needed for business.
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
Modified
p. 18 → 16
Aligns with PCI DSS Requirement 3.2.1 1.1.1 Use forensic tools and/or methods (commercial tools, scripts, etc.)3 to examine all output created by the payment application and verify that the full contents of any track from the magnetic stripe on the back of the card or equivalent data on a chip are not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application): Incoming transaction data All …
Aligns with PCI DSS Requirement 3.2.1 1.1.1 Install the payment application and perform numerous test transactions that simulate all functions of the payment application, including generation of error conditions and log entries. Use forensic tools and/or methods (commercial tools, scripts, etc.)5 to examine all output created by the payment application and verify that the full contents of any track from the magnetic stripe on the back of the card or equivalent data on a chip are not stored after authorization. …
Modified
p. 18 → 17
Aligns with PCI DSS Requirement 3.2.2 1.1.2 Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application and verify that the three-digit or four-digit card verification code printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application): Incoming transaction data …
Aligns with PCI DSS Requirement 3.2.2 1.1.2 Install the payment application and perform numerous test transactions that simulate all functions of the payment application, including generation of error conditions and log entries. Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application and verify that the three-digit or four-digit card verification code printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after …
Modified
p. 19 → 17
Aligns with PCI DSS Requirement 3.2.3 1.1.3 Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application, and verify that PINs and encrypted PIN blocks are not stored after authorization. Include at least the following types of files (as well as any other output generated by the payment application). Incoming transaction data All logs (for example, transaction, history, debugging, error) History files Trace files Non-volatile memory, including …
Aligns with PCI DSS Requirement 3.2.3 1.1.3 Install the payment application and perform numerous test transactions that simulate all functions of the payment application, including generation of error conditions and log entries. Use forensic tools and/or methods (commercial tools, scripts, etc.) to examine all output created by the payment application, and verify that PINs and encrypted PIN blocks are not stored after authorization. Include at least the following types of files (as well as any other output generated by the …
Modified
p. 19 → 18
Aligns with PCI DSS Requirement 3.2 1.1.4.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators: That historical data must be removed (magnetic stripe data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data That such removal is absolutely necessary for PCI DSS compliance 1.1.4.b Verify the vendor provides a secure wipe tool or …
Aligns with PCI DSS Requirement 3.2 1.1.4.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:
Removed
p. 20
Aligns with PCI DSS Requirement 3.2 1.1.5.a Examine the software vendor’s procedures for troubleshooting customers’ problems and verify the procedures include: Collection of sensitive authentication data only when needed to solve a specific problem Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific problem Encryption of sensitive authentication data while stored Secure deletion of such data immediately after use 1.1.5.b Select a sample of recent troubleshooting requests from customers, and verify each event followed the procedure examined at 1.1.5.a.
Modified
p. 20 → 19
1.1.5.c Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators: Collect sensitive authentication only when needed to solve a specific problem. Store such data only in specific, known locations with limited access. Collect only the limited amount of data needed to solve a specific problem. Encrypt sensitive authentication data while stored. Securely delete such data immediately after use.
1.1.5.c Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:
Removed
p. 21
Aligns with PCI DSS Requirement 3.3 2.2 Review displays of credit card data, including but not limited to POS devices, screens, logs, and receipts, to determine that credit card numbers are masked when displaying cardholder data, except for those with a legitimate business need to see full credit card numbers.
Modified
p. 21 → 20
Requirement 2: Protect stored cardholder data PA-DSS Requirements Testing Procedures Guidance 2.1 Software vendor must provide guidance to customers regarding secure deletion of cardholder data after expiration of customer-defined retention period.
Modified
p. 21 → 20
Aligns with PCI DSS Requirement 3.1 2.1 Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following guidance for customers and resellers/integrators: That cardholder data exceeding the customer-defined retention period must be purged A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted) Instructions for configuring the underlying software or systems (such as OS, databases, etc.) …
Aligns with PCI DSS Requirement 3.1 2.1 Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following guidance for customers and integrators/resellers:
Modified
p. 21 → 20
Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
Removed
p. 22
One-way hashes based on strong cryptography (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of PAN) Index tokens and pads (pads must be securely stored) Strong cryptography with associated key management processes and procedures.
2.3.a Examine the method used to protect the PAN, including the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using any of the following methods: 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 2.3.b Examine several tables or files from data repositories created or generated by the application to verify the PAN is rendered unreadable.
2.3.a Examine the method used to protect the PAN, including the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using any of the following methods: 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 2.3.b Examine several tables or files from data repositories created or generated by the application to verify the PAN is rendered unreadable.
Modified
p. 22
• 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 should be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN. • The PAN must be rendered unreadable anywhere it is stored, even outside the …
Modified
p. 22
Aligns with PCI DSS Requirement 3.4 2.3 Verify that the PAN is rendered unreadable anywhere it is stored, as follows.
Aligns with PCI DSS Requirement 3.4 2.3.c Examine several tables or files from data repositories created or generated by the application to verify the PAN is rendered unreadable.
Modified
p. 22
2.3.d If the application creates or generates files for use outside the application (for example, files generated for export or backup), including for storage on removable media, examine a sample of generated files, including those generated on removable media (for example, back-up tapes), to confirm that the PAN is rendered unreadable.
Modified
p. 22
2.3.e Examine a sample of audit logs created or generated by the application to confirm that the PAN is rendered unreadable or removed from the logs.
Modified
p. 22
2.3.f If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), verify that the PAN is rendered unreadable in accordance with Requirements 2.3.a through 2.3.e, above.
Removed
p. 23
2.4.a Verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating systems mechanism (for example, not using local user account databases).
2.4.b Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).
2.4.c If the application creates or generates files on removable media, verify that cardholder data on removable media is encrypted wherever stored.
Note: This requirement also applies to key- encrypting keys used to protect data-encrypting keys•such key-encrypting keys must be at least as strong as the data-encrypting key.
Aligns with PCI DSS Requirement 3.5 2.5 Verify the payment application protects any keys used to secure cardholder data against disclosure and misuse, as follows:
2.5.a Examine methodology used by application to protect keys, to verify that controls are in place that restrict access to keys.
2.5.b Examine system configuration files to verify that keys …
2.4.b Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).
2.4.c If the application creates or generates files on removable media, verify that cardholder data on removable media is encrypted wherever stored.
Note: This requirement also applies to key- encrypting keys used to protect data-encrypting keys•such key-encrypting keys must be at least as strong as the data-encrypting key.
Aligns with PCI DSS Requirement 3.5 2.5 Verify the payment application protects any keys used to secure cardholder data against disclosure and misuse, as follows:
2.5.a Examine methodology used by application to protect keys, to verify that controls are in place that restrict access to keys.
2.5.b Examine system configuration files to verify that keys …
Modified
p. 23 → 19
Aligns with PCI DSS Requirement 3.4.2 2.4 If disk encryption is used, verify that it is implemented as follows:
Aligns with PCI DSS Requirement 3.2.
Modified
p. 23 → 22
• Restrict access to keys to the fewest number of custodians necessary.
Modified
p. 23 → 22
• Store keys securely in the fewest possible locations and forms.
Removed
p. 24
How to perform key management functions defined in 2.6.1 through 2.6.7 below, as required for PCI DSS compliance 2.6.b Verify the payment application implements key- management techniques for keys, as follows:
Modified
p. 24 → 23
Aligns with PCI DSS Requirement 3.6 2.6.a Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and resellers/integrators:
Aligns with PCI DSS Requirement 3.6 2.5 Review the PA-DSS Implementation Guide prepared by the vendor and verify the documentation includes the following instructions for customers and integrators/resellers:
Modified
p. 24 → 23
• How to securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or integrators/resellers are involved in these key-management activities.
Modified
p. 24 → 23
• A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.
Removed
p. 25
2.6.5.a Verify that key-management procedures are implemented to retire keys when the integrity of the key has been weakened.
2.6.5.b Verify that key-management procedures are implemented to replace known or suspected compromised keys.
2.6.5.b Verify that key-management procedures are implemented to replace known or suspected compromised keys.
Modified
p. 25 → 24
Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key- encrypting key). Archived cryptographic keys should be used only for decryption/verification purposes.
Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encrypting key). Archived cryptographic keys should be used only for decryption/verification purposes.
Modified
p. 25 → 24
• Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.
Modified
p. 25
Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.
Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.
Removed
p. 26
That cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable That such irretrievability is absolutely necessary for PCI DSS compliance How to re-encrypt historic data with new keys 2.7.b Verify vendor provides a tool or procedure to render cryptographic material irretrievable.
Modified
p. 26
2.6.c Test the application, including the methods provided for rendering cryptographic key material irretrievable. Verify, through use of forensic tools and/or methods, that the secure wipe tool or procedure provided by the vendor renders the cryptographic material irretrievable, in accordance with industry- accepted standards.
Removed
p. 27
3.1.b Test the payment application to verify the payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).
3.1.c If the payment application generates or manages authentication credentials, test the application to verify that it enforces changes to any default payment application passwords by the completion of the installation process.
3.1.c If the payment application generates or manages authentication credentials, test the application to verify that it enforces changes to any default payment application passwords by the completion of the installation process.
Modified
p. 27
Requirement 3: Provide secure authentication features PA-DSS Requirements Testing Procedures Guidance 3.1 The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts generated or managed by the application by the completion of installation and for subsequent changes after installation.
Modified
p. 27
The application must require the following:
The application must enforce 3.1.1 through 3.1.11 below:
Modified
p. 27
Aligns with PCI DSS Requirements 8.1, 8.2, and 8.5.8•8.5.15 3.1.a Examine PA-DSS Implementation Guide created by vendor to verify the following:
Aligns with PCI DSS Requirements 8.1 and 8.2 3.1.a Examine the PA-DSS Implementation Guide created by the vendor to verify that customers and integrators/resellers are:
Modified
p. 27
• Provided clear and unambiguous directions on how the payment application enforces strong authentication for all authentication credentials that the application generates or manages, by:
Modified
p. 27
• Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11).
Modified
p. 27
• Advised to assign secure authentication to any default accounts (even if they won’t be used), and then disable or do not use the accounts.
Modified
p. 27
• 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.
Removed
p. 28
3.1.1.b For subsequent changes after installation.
3.1.2.b For subsequent changes after installation.
3.1.2.a By completion of the installation process.
3.1.3.a By completion of the installation process 3.1.3.b For subsequent changes after installation.
3.1.2.b For subsequent changes after installation.
3.1.2.a By completion of the installation process.
3.1.3.a By completion of the installation process 3.1.3.b For subsequent changes after installation.
Modified
p. 28
Aligns with PCI DSS Requirements 8.1 3.1.1 Confirm that the payment application assigns unique user IDs:
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:
Modified
p. 28 → 29
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.
Modified
p. 28 → 31
• changed at least every 90 days by completion of the installation process.
Modified
p. 28 → 36
Aligns with PCI DSS Requirement 8.5.8 3.1.3 Confirm that the payment application does not rely on or use any group, shared, or generic accounts and passwords:
Aligns with PCI DSS Requirement 10.2 4.2 Test the payment application by examining payment application audit log settings and audit log output, and perform the following:
Removed
p. 29
3.1.4.a By completion of the installation process 3.1.4.b For subsequent changes after installation 3.1.5 The payment application requires a minimum password length of at least seven characters.
3.1.5.a By completion of the installation process 3.1.5.b For subsequent changes after installation 3.1.6 The payment application requires that passwords contain both numeric and alphabetic characters.
3.1.6.a By completion of the installation process 3.1.6.b For subsequent changes after installation 3.1.7 The payment application keeps password history and requires that a new password is different than any of the last four passwords used.
3.1.8.a By completion of the installation process 3.1.8.b For subsequent changes after installation
3.1.5.a By completion of the installation process 3.1.5.b For subsequent changes after installation 3.1.6 The payment application requires that passwords contain both numeric and alphabetic characters.
3.1.6.a By completion of the installation process 3.1.6.b For subsequent changes after installation 3.1.7 The payment application keeps password history and requires that a new password is different than any of the last four passwords used.
3.1.8.a By completion of the installation process 3.1.8.b For subsequent changes after installation
Modified
p. 29 → 30
Aligns with PCI DSS Requirement 8.5.10 3.1.5 Confirm that the payment requires passwords to be at least seven characters long:
Aligns with PCI DSS Requirement 8.5 3.1.5 For all accounts generated or managed by the application, test the application as follows:
Modified
p. 29 → 31
Aligns with PCI DSS Requirement 8.5.11 3.1.6 Confirm that the payment application requires passwords to contain both numeric and alphabetic characters.
Aligns with PCI DSS Requirement 8.2.4 3.1.7 For all accounts generated or managed by the application, test the application as follows:
Modified
p. 29 → 32
Aligns with PCI DSS Requirement 8.5.13 3.1.8 Confirm that the payment locks out user account after not more than six invalid logon attempts.
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:
Modified
p. 29 → 36
Aligns with PCI DSS Requirement 8.5.9 3.1.4 Confirm that the payment application requires users to change passwords at least every 90 days:
Aligns with PCI DSS Requirement 10.1 4.1.a Install the payment application. Test the application to verify that payment application audit trails are automatically enabled upon installation.
Modified
p. 30 → 32
Aligns with PCI DSS Requirement 8.5.14 3.1.9 Confirm that the payment application locks out user accounts for a minimum of 30 minutes or until a system administrator resets the account.
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:
Modified
p. 30 → 33
Aligns with PCI DSS Requirement 8.5.15 3.1.10 Confirm that the payment sets a session idle time out to 15 minutes or less.
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:
Modified
p. 30 → 34
Aligns with PCI DSS Requirements 8.1 and 8.2 3.2 Examine PA-DSS Implementation Guide created by vendor to verify customers and resellers/integrators are strongly advised to control access, via unique user ID and PCI DSS- compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.
Aligns with PCI DSS Requirements 8.1 and 8.2 3.2 Examine the PA-DSS Implementation Guide created by vendor to verify customers and integrators/resellers are instructed to control access, via unique user ID and PCI DSS- compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data.
Modified
p. 30 → 34
3.3.1.a Examine vendor documentation and application configurations to verify that strong cryptography is used to render all passwords unreadable at all times during transmission.
Removed
p. 31
4.1.b If payment application log settings are configurable by the customer and resellers/integrators, or customers or resellers/integrators are responsible for implementing logging, examine PA-DSS Implementation Guide prepared by the vendor to verify the following information is included:
Aligns with PCI DSS Requirement 10.2 4.2 Test the payment application and examine payment application audit logs and audit log settings, and perform the following:
Aligns with PCI DSS Requirement 10.2 4.2 Test the payment application and examine payment application audit logs and audit log settings, and perform the following:
Modified
p. 31 → 28
Aligns with PCI DSS Requirement 10.1 4.1.a Examine payment application settings to verify that payment application audit trails are automatically enabled or are available to be enabled by customers.
Aligns with PCI DSS Requirement 2.1 3.1.2 For all accounts generated or managed by the application, test the application as follows:
Modified
p. 31 → 36
Requirement 4: Log payment application activity PA-DSS Requirements Testing Procedures Guidance 4.1 At the completion of the installation process, the “out of the box” default installation of the payment application must log all user access and be able to link all activities to individual users.
Modified
p. 31 → 36
• 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.
Modified
p. 31 → 36
• Logs should not be disabled and doing so will result in non- compliance with PCI DSS.
Removed
p. 32
Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.
Aligns with PCI DSS Requirement 10.5.3 4.4.a Validate that payment application provides functionality that facilitates a merchant’s ability to assimilate logs into their centralized log server.
Aligns with PCI DSS Requirement 10.5.3 4.4.a Validate that payment application provides functionality that facilitates a merchant’s ability to assimilate logs into their centralized log server.
Modified
p. 32 → 38
Aligns with PCI DSS Requirement 10.3 4.3 Test the payment application and examine the payment application’s audit logs and audit log settings, and, for each auditable event (from 4.2), perform the following:
Aligns with PCI DSS Requirement 10.3 4.3 Test the payment application by examining the payment application’s audit log settings and audit log output, and, for each auditable event (from 4.2), perform the following:
Modified
p. 32 → 39
• 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. 32 → 39
• Instructions and procedures for incorporating the payment application logs into a centralized logging environment.
Removed
p. 33
5. Develop secure payment applications 5.1 The software vendor develops payment applications in accordance with PCI DSS and PA- DSS (for example, secure authentication and logging) and based on industry best practices, and incorporates information security throughout the software development life cycle. These processes must include the following:
5.1.d From an examination of written software development processes, interviews of software developers, and examination of the final payment application product, verify that:
5.1.d From an examination of written software development processes, interviews of software developers, and examination of the final payment application product, verify that:
Removed
p. 33
Aligns with PCI DSS Requirement 6.3.2 5.1.4 Confirm the vendor performs code reviews for all significant application code changes (either using manual or automated processes), as follows: Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release.
Modified
p. 33 → 40
Aligns with PCI DSS Requirement 6.3 5.1.a Obtain and examine written software development processes to verify that processes are based on industry standards and/or best practices.
Aligns with PCI DSS Requirement 6.3 5.1.a Examine documented software-development processes and verify that processes are based on industry standards and/or best practices.
Modified
p. 33 → 40
• Information security is incorporated throughout the software development life cycle.
Modified
p. 33 → 40
• Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.
Modified
p. 33 → 40
Aligns with PCI DSS Requirement 6.4.3 5.1.1 Live PANs are not used for testing or development.
Aligns with PCI DSS Requirement 6.4.3 5.1.1.a Review software development processes to verify that they include procedures to ensure live PANs are not used for testing or development.
Removed
p. 34
Aligns with PCI DSS Requirement 6.5 5.2.a Obtain and review software development processes for payment applications (internal and external, and including web-administrative access to product). Verify the process includes training in secure coding techniques for developers, based on industry best practices and guidance.
5.2.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.
5.2.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.
Modified
p. 34 → 45
Aligns with PCI DSS Requirement 6.5 5.2 Verify that payment applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit each of the following:
Modified
p. 34 → 48
Note: Requirements 5.2.7 through 5.2.9, below, apply to web-based applications and application interfaces (internal or external):
Note: Requirements 5.2.7 through 5.2.10, below, apply to web-based applications and application interfaces (internal or external):
Removed
p. 35
5.3.b Examine recent payment application changes, and trace those changes back to related change control documentation. Verify that, for each change examined, the following was documented according to the change control procedures:
Modified
p. 35 → 49
Aligns with PCI DSS Requirement 6.4.5 5.3.a Obtain and examine the vendor’s change-control procedures for software modifications, and verify that the procedures require items 5.3.1•5.3.4 below.
Aligns with PCI DSS Requirement 6.4.5 5.3.a Examine the vendor’s change-control procedures for software modifications, and:
Modified
p. 35 → 50
5.3.3.b Verify that all changes (including patches) are tested for compliance with 5.2 before being released.
Modified
p. 35 → 63
Aligns with PCI DSS Requirement 2.2.2 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”.
Removed
p. 36
Aligns with PCI DSS Requirements 1.2.3 & 2.1.1 6.1 For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the payment application, verify that the wireless applications do not use vendor default settings, as follows:
6.1.a Verify encryption keys were
• changed anytime anyone with knowledge of the keys leaves the company or changes positions 6.1.b Verify default SNMP community strings on wireless devices were changed 6.1.c Verify default passwords/passphrases on access points were changed 6.1.d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks 6.1.e Verify other security-related wireless vendor defaults were changed, if applicable 6.1.f Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are instructed, if wireless is used, to:
Change wireless vendor defaults as defined in 6.1.a
• 6.1.e above; Install a firewall between any wireless networks …
6.1.a Verify encryption keys were
• changed anytime anyone with knowledge of the keys leaves the company or changes positions 6.1.b Verify default SNMP community strings on wireless devices were changed 6.1.c Verify default passwords/passphrases on access points were changed 6.1.d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks 6.1.e Verify other security-related wireless vendor defaults were changed, if applicable 6.1.f Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are instructed, if wireless is used, to:
Change wireless vendor defaults as defined in 6.1.a
• 6.1.e above; Install a firewall between any wireless networks …
Modified
p. 36 → 56
Requirement 6: Protect wireless transmissions PA-DSS Requirements Testing Procedures Guidance 6.1 For payment applications using wireless technology, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. The wireless technology must be implemented securely.
Modified
p. 36 → 57
• changed from default at installation, and are
• Encryption keys were changed from default at installation.
Removed
p. 37
6.2.b If customers could implement the payment application into a wireless environment, examine PA-DSS Implementation Guide prepared by the vendor to verify customers and resellers/integrators are instructed on PCI DSS-compliant wireless settings, including changing wireless vendor defaults (per 6.1.a
• 6.1.e above), and using industry best practices to implement strong encryption for authentication and transmission of cardholder data (per 6.2.a).
• 6.1.e above), and using industry best practices to implement strong encryption for authentication and transmission of cardholder data (per 6.2.a).
Modified
p. 37 → 58
Note: The use of WEP as a security control was prohibited as of 30 June 2010.
Note: The use of WEP as a security control is prohibited.
Modified
p. 37 → 58
Aligns with PCI DSS Requirement 4.1.1 6.2.a For payment applications developed by the vendor using wireless technology, and other wireless applications bundled with the vendor application, verify that industry best practices (for example, IEEE 802,11.i) were used to include or make available strong encryption for authentication and transmission.
Aligns with PCI DSS Requirement 4.1.1 6.2.a For payment applications developed for use with wireless technology, test all wireless functionality to verify the application uses industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.
Removed
p. 38
Aligns with PCI DSS Requirement 6.2
Removed
p. 38
7.1.a Verify that processes include assigning a risk ranking to identified vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as “High”.) 7.1.b Verify the processes to identify new security vulnerabilities include using outside sources for security vulnerability information 7.1.c Verify that processes include testing of payment applications for new vulnerabilities 7.1.d Verify that processes to identify new vulnerabilities and implement corrections into payment application apply to all software provided with or required by the payment application (for example, web servers, third-party libraries and programs).
7.2.a Obtain and examine processes to develop and deploy security patches and upgrades for software. Verify that processes include the timely development and deployment of patches to customers 7.2.b Review processes to verify that patches and updates are delivered in a secure manner with a known chain-of-trust 7.2.c Review processes to verify that patches and updates are delivered in a manner that maintains …
7.2.a Obtain and examine processes to develop and deploy security patches and upgrades for software. Verify that processes include the timely development and deployment of patches to customers 7.2.b Review processes to verify that patches and updates are delivered in a secure manner with a known chain-of-trust 7.2.c Review processes to verify that patches and updates are delivered in a manner that maintains …
Modified
p. 38 → 60
Note: Any underlying software or systems that are provided with or required by the payment application (for example, web servers, third-party libraries and programs) must be included in this process.
Modified
p. 38 → 61
Note: Risk rankings should be based on industry best practices. For example, criteria for ranking ”High” risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor- supplied patch classified by the vendor as “critical,” and/or a vulnerability affecting a critical component of the application.
Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or impact to application functionality.
Removed
p. 39
9. Cardholder data must never be stored on a server connected to the Internet 9.1 The payment application must be developed such that a database server and web server are not required to be on the same server, nor is a database server required to be in the DMZ with the web server.
Aligns with PCI DSS Requirement 1.3.7 9.1.a To verify that the payment application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the payment application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (for example, payment application must not require that a database server and web server be on the same server, or in the DMZ with the web server).
9.1.b If customers could store cardholder data on a server connected to the Internet, examine PA-DSS Implementation …
Aligns with PCI DSS Requirement 1.3.7 9.1.a To verify that the payment application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the payment application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (for example, payment application must not require that a database server and web server be on the same server, or in the DMZ with the web server).
9.1.b If customers could store cardholder data on a server connected to the Internet, examine PA-DSS Implementation …
Modified
p. 39 → 63
Requirement 8: Facilitate secure network implementation PA-DSS Requirements Testing Procedures Guidance 8.1 The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance.
Modified
p. 39 → 63
Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6 8.1 Test the payment application in a lab to obtain evidence that it can run in a network that is fully compliant with PCI DSS. Verify that the payment application does not inhibit installation of patches or updates to other components in the environment.
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.
Removed
p. 40
10. Facilitate secure remote access to payment application.
Removed
p. 40
Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric Aligns with PCI DSS Requirement 8.3 10.1 Test the payment application in a lab to obtain evidence that it does not interfere with two-factor authentication technologies.
Modified
p. 40 → 66
Note: Two-factor authentication requires that two of the three authentication methods be used for authentication (see PA-DSS Req. 10.1 for descriptions of authentication methods).
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).
Modified
p. 40 → 66
Aligns with PCI DSS Requirement 8.3 10.2 If the payment application may be accessed remotely, examine PA-DSS Implementation Guide prepared by the software vendor, and verify it contains instructions for customers and resellers/integrators regarding required use of two-factor authentication (two of the three authentication methods described in PA DSS Req. 10.1).
Aligns with PCI DSS Requirement 8.3 10.1.a Examine the PA-DSS Implementation Guide prepared by the vendor to verify it contains the following for customers and integrators/resellers:
Modified
p. 41 → 66
Alternatively, if delivered via VPN or other high- speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure “always- on” connections.
Alternatively, if delivered via virtual private network (VPN) or other high-speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure “always-on” connections.
Modified
p. 41 → 66
Aligns with PCI DSS Requirements 1 and 12.3.9 10.3.1 If the vendor delivers payment application and/or updates via remote access to customer networks, examine PA-DSS Implementation Guide prepared by vendor, and verify it contains:
Aligns with PCI DSS Requirements 1 and 12.3.9 10.2.1.a If payment application updates are delivered via remote access into customers’ systems, examine the PA- DSS Implementation Guide prepared by the vendor and verify it contains:
Modified
p. 41 → 66
• 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.
Modified
p. 41 → 66
• Recommendation for customers and integrators/resellers to use a securely configured firewall or a personal firewall product if computer is connected via VPN or other high-speed connection, to secure these “always-on” connections, per PCI DSS Requirement 1.
Removed
p. 42
Note: Examples of remote access security features include:
Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.10) 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 Requirement3.1.8) Configure the system so a remote user must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed.
10.3.2.b If resellers/integrators or customers can use remote access software, examine PA-DSS Implementation Guide prepared by the software vendor, and verify that customers and resellers/integrators are instructed to use and implement remote access security features.
Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.10) 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 Requirement3.1.8) Configure the system so a remote user must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed.
10.3.2.b If resellers/integrators or customers can use remote access software, examine PA-DSS Implementation Guide prepared by the software vendor, and verify that customers and resellers/integrators are instructed to use and implement remote access security features.
Modified
p. 42 → 65
Aligns with PCI DSS Requirement 8.3 10.3.2.a If the software vendor uses remote access products for remote access to the customers’ payment application, verify that vendor personnel implement and use remote access security features.
Aligns with PCI DSS Requirement 1.3.7 9.1.a Identify all payment application data storage components (for example, databases) and all web servers.
Modified
p. 42 → 68
• Change default settings in the remote- access software (for example, change default passwords and use unique passwords for each customer).
Modified
p. 42 → 68
• Allow connections only from specific (known) IP/MAC addresses.
Modified
p. 42 → 68
• Enable the logging function.
Modified
p. 42 → 68
• Restrict access to customer environments to authorized integrators/resellers personnel.
Modified
p. 42 → 68
• Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11).
Removed
p. 43
Examples of open, public networks that are in scope of the PCI DSS are:
Modified
p. 43 → 65
9.1.c Examine the PA-DSS Implementation Guide prepared by the vendor to verify it includes the following for customers and integrators/resellers:
Modified
p. 43 → 69
Requirement 11: Encrypt sensitive traffic over public networks PA-DSS Requirements Testing Procedures Guidance 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:
Modified
p. 43 → 69
• 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. 43 → 70
11.2.c If a solution is provided with the payment application, install and test the application to verify that the solution renders the PAN unreadable or implements strong cryptography.
Removed
p. 44
13.1.2.b Verify the PA-DSS Implementation Guide is reviewed on an annual basis and updated as needed to document changes to the PA-DSS requirements.
Modified
p. 44 → 71
Note: Telnet or rlogin must never be used for administrative access.
Note: Clear-text protocols such as Telnet or rlogin must never be used for administrative access.
Modified
p. 44 → 71
Aligns with PCI DSS Requirement 2.3 12.1 If payment application or server allows non-console administration, examine the PA-DSS Implementation Guide prepared by vendor, and verify vendor recommends use of strong cryptography, using technologies such as SSH, VPN, or SSL/TLS for encryption of non-console administrative access.
Aligns with PCI DSS Requirement 2.3 12.2 Examine the PA-DSS Implementation Guide prepared by the vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or SSL/TLS, for encryption of all non-console administrative access.
Modified
p. 44 → 72
Requirement 13: Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators PA-DSS Requirements Testing Procedures Guidance 13.1 Develop, maintain, and disseminate a PA- DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following:
Modified
p. 44 → 72
13.1.3.b Verify the PA-DSS Implementation Guide is updated as needed to keep current with:
Removed
p. 45
13.2.1.a Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new payment application versions are released, and updated as needed.
Modified
p. 45 → 75
14.3.1.b Examine the distribution process for new payment application versions and verify that
Modified
p. 45 → 75
• updated documentation is distributed with the
• updated documentation is distributed to integrators and resellers with the
Modified
p. 45 → 75
14.3.1.c Interview a sample of integrators and resellers to verify they received updated training materials from the application vendor.
Removed
p. 46
Cardholder data must be purged after it exceeds the customer-defined retention period All locations where payment application stores cardholder data Software Vendor: Provide guidance to customers that cardholder data exceeding customer-defined retention periods must be purged and where such data is stored by the payment application.
Modified
p. 46 → 76
Requirement PA-DSS Topic Implementation Guide Content Control Implementation Responsibility 1.1.4 Delete sensitive authentication data stored by previous payment application versions.
PA-DSS Requirement PA-DSS Topic Required Implementation Guide Content Control Implementation Responsibility 1.1.4 Delete sensitive authentication data stored by previous payment application versions.
Modified
p. 46 → 76
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. Such removal is absolutely necessary for PCI DSS compliance.
Modified
p. 46 → 76
Customers & Resellers/Integrators: Delete any historical data per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.4.
Customers & Integrators/Resellers: Delete any historical data per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.4.
Modified
p. 46 → 76
Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem. Such data must be stored only in specific, known locations with limited access. Only collect a limited amount of such data as needed to solve a specific problem. Sensitive authentication data must be encrypted while stored. Such data must be securely deleted immediately after use.
Modified
p. 46 → 76
Customers & Resellers/Integrators: Troubleshoot any problems per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.5.a.
Customers & Integrators/Resellers: Do not store sensitive authentication data; and troubleshoot any problems per the PA-DSS Implementation Guide and PA-DSS Requirement 1.1.5.a.
Modified
p. 46 → 77
Customers & Resellers/Integrators: Purge cardholder data exceeding customer-defined retention period.
Customers & Integrators/Resellers: Securely delete cardholder data exceeding customer-defined retention period, per the PA-DSS Implementation Guide and PA- DSS Requirement 2.1.
Removed
p. 47
Restrict access to keys to the fewest number of custodians necessary. Store keys securely in the fewest possible locations and forms Software Vendor: Provide guidance to customers that keys used to secure cardholder data should be stored securely in the fewest possible locations, and access to keys must be restricted to the fewest possible custodians.
Cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable Such irretrievability is absolutely necessary for PCI compliance How to re-encrypt historic data with new keys Software Vendor: Provide tool or procedure to securely remove cryptographic key material or cryptograms stored by previous versions, per PA-DSS Requirement 1.1.5, provide tool or procedure to re- encrypt historic data with new keys.
Cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable Such irretrievability is absolutely necessary for PCI compliance How to re-encrypt historic data with new keys Software Vendor: Provide tool or procedure to securely remove cryptographic key material or cryptograms stored by previous versions, per PA-DSS Requirement 1.1.5, provide tool or procedure to re- encrypt historic data with new keys.
Modified
p. 47 → 78
Software Vendor: Provide guidance to customers that keys used to secure cardholder data should be stored securely in the fewest possible locations, and access to keys must be restricted to the fewest possible custodians.
Modified
p. 47 → 78
Instructions on how to securely generate, distribute, protect, change, store, and retire/replace encryption 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.
Modified
p. 47 → 78
Software Vendor: Provide instructions to customers that access cryptographic keys used for encryption of cardholder data to implement key management processes and procedures.
Software Vendor: Provide instructions to customers that access cryptographic keys used for encryption of cardholder data to implement key-management processes and procedures.
Modified
p. 47 → 78
Customers & Resellers/Integrators: Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data per PA-DSS Implementation Guide and PA-DSS Requirement 2.6.
Customers & Integrators/Resellers: Implement key- management processes and procedures for cryptographic keys used for encryption of cardholder data per PA-DSS Implementation Guide and PA-DSS Requirement 2.5.
Modified
p. 47 → 79
Customers & Resellers/Integrators: Delete any historical cryptographic material per PA-DSS Implementation Guide and PA-DSS Requirement 1.1.5.
Customers & Integrators/Resellers: Delete any historical cryptographic material in accordance with key- management requirements per PA-DSS Implementation Guide and PA-DSS Requirement 2.6.
Removed
p. 48
That the payment application enforces secure authentication for any authentication credentials (e.g. users, passwords) that the application generates by: - Enforcing secure changes to authentication credentials by the completion of installation and for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1. Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15, by the completion of installation and for subsequent changes after installation, for all application level accounts with administrative access or access to cardholder data.
Modified
p. 48 → 80
Software Vendor: When the payment application generates or manages authentication credentials, ensure payment application enforces customer’s use of unique user IDs and secure authentication for payment application accounts/passwords, per PA-DSS Requirements 3.1.1 through 3.1.10.
Software Vendor: For all authentication credentials generated or managed by the application, ensure payment application enforces customer’s use of unique user IDs and secure authentication for accounts/passwords, per PA-DSS Requirements 3.1.1 through 3.1.11.
Modified
p. 48 → 80
For authentication credentials not generated or managed by the payment application, ensure the PA- DSS Implementation Guide provides clear and unambiguous guidance for customers and integrators/resellers on how to change and create secure authentication credentials per PA-DSS Requirements 3.1.1 through 3.1.11.
Modified
p. 48 → 80
Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS Requirements 3.1.1 through 3.1.10.
Customers & Integrators/Resellers: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS Requirements 3.1.1 through 3.1.11.
Modified
p. 48 → 81
Customers & Resellers/Integrators: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS requirements 3.1.2 through 3.1.10.
Customers & Integrators/Resellers: Establish and maintain unique user IDs and secure authentication per the PA-DSS Implementation Guide and PA-DSS requirements 3.1.1 through 3.1.11.
Modified
p. 48 → 81
Instruct customers and integrators/resellers to use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, per PA-DSS requirements 3.1.1 through 3.1.11.
Modified
p. 48 → 81
Customers & Resellers/Integrators: Establish and maintain PCI DSS-compliant logs per the PA-DSS Implementation Guide and PA-DSS Requirements 4.2, 4.3 and 4.4.
Customers & Integrators/Resellers: Establish and maintain PCI DSS-compliant logs per the PA-DSS Implementation Guide and PA-DSS Requirements 4.2, 4.3 and 4.4.
Removed
p. 49
Customers and Resellers/Integrators: Use the documented list from the Implementation Guide to ensure only necessary and secure protocols, services, etc., are used on the system, in accordance with PA- DSS Requirement 5.4.
Removed
p. 49
Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, change vendor defaults per PA-DSS Requirement 6.1 and install a firewall per the PA-DSS Implementation Guide and PCI DSS Requirement 2.1.1.
Modified
p. 49 → 81
Software Vendor: Ensure payment application supports centralized logging in customer environments per PA-DSS Requirement 4.4.
Software Vendor: Ensure payment application supports centralized logging in customer environments per PA- DSS Requirement 4.4.
Modified
p. 49 → 81
Customers & Resellers/Integrators: Establish and maintain centralized logging per the PA-DSS Implementation Guide and PA-DSS Requirement 4.4.
Customers & Integrators/Resellers: Establish and maintain centralized logging per the PA-DSS Implementation Guide and PA-DSS Requirement 4.4.
Modified
p. 49 → 85
Software Vendor: Ensure payment application supports customer’s use of only necessary and secure protocols, services, etc., by 1) having only necessary protocols, services, etc., established “out of the box” by default, 2) having those necessary protocols, services, etc., securely configured by default, and 3) by documenting necessary protocols, services, etc., as a reference for customers and resellers/integrators.
Software Vendor: Ensure payment application supports customer’s use of only necessary and secure protocols, services, etc., by 1) having only necessary protocols, services, etc., established “out of the box” by default, 2) having those necessary protocols, services, etc., securely configured by default, and 3) by documenting necessary protocols, services, etc., as a reference for customers and integrators/resellers.
Removed
p. 50
If payment application is implemented into a wireless environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data.
Software Vendor: Instruct customers and resellers/integrators, that if wireless technology is used with the payment application, that secure encrypted transmissions must be implemented, per PA-DSS Requirement 6.2.
Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, use secure encrypted transmissions per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
Do not store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server).
Customers & Resellers/Integrators: Establish and maintain payment applications so that cardholder data is not stored on Internet-accessible systems, per the PA-DSS Implementation Guide and PA-DSS Requirement 9 10.2 Implement two-factor authentication for remote access to payment application.
Use two-factor authentication (user ID and password and an additional authentication item such as a …
Software Vendor: Instruct customers and resellers/integrators, that if wireless technology is used with the payment application, that secure encrypted transmissions must be implemented, per PA-DSS Requirement 6.2.
Customers & Resellers/Integrators: For wireless implemented into the payment environment by customers or resellers/integrators, use secure encrypted transmissions per the PA-DSS Implementation Guide and PA-DSS Requirement 6.2.
Do not store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server).
Customers & Resellers/Integrators: Establish and maintain payment applications so that cardholder data is not stored on Internet-accessible systems, per the PA-DSS Implementation Guide and PA-DSS Requirement 9 10.2 Implement two-factor authentication for remote access to payment application.
Use two-factor authentication (user ID and password and an additional authentication item such as a …
Modified
p. 50 → 85
Software Vendor: Ensure payment application does not require data storage in the DMZ or on Internet- accessible systems, and will allow use of a DMZ per PA-DSS Requirement 9.
Software Vendor: Ensure payment application does not require cardholder data storage in the DMZ or on Internet-accessible systems, and will allow use of a DMZ per PA-DSS Requirement 9.
Modified
p. 50 → 86
Software Vendor: Ensure payment application supports customers’ use of two-factor authentication, per PA-DSS Requirement 10.2.
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.
Modified
p. 50 → 86
Customers & Resellers/Integrators: Establish and maintain two-factor authentication for remote access to payment application, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.
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.
Modified
p. 50 → 86
Instructions for activation of remote-access technologies for payment application updates only when needed for downloads, and turning access off immediately after download completes, per PCI DSS Requirement 12.3.9. Instructions that, if computer is connected via VPN or other high-speed connection, receive remote payment application updates via a securely configured firewall or personal firewall per PCI DSS Requirement 1.
Modified
p. 50 → 86
Software Vendor: Deliver remote payment application updates securely per PA-DSS 10.3 Customers & Resellers/Integrators: Receive remote payment application updates from vendor securely, per the PA-DSS Implementation Guide, PA-DSS Requirement 10.3 and PCI DSS Requirement 1.
Software Vendor: Deliver remote payment application updates securely per PA-DSS 10.3 Customers & Integrators/Resellers: Receive remote payment application updates from vendor securely, per the PA-DSS Implementation Guide, PA-DSS Requirement 10.3 and PCI DSS Requirement 1.
Removed
p. 51
Implement and use remote access software security features if remote access software is used to remotely access the payment application or payment environment.
Implement and use strong cryptography and security protocols for secure cardholder data transmission over public networks.
Implement and use strong cryptography and security protocols for secure cardholder data transmission over public networks.
Modified
p. 51 → 87
Software Vendor: (1) If vendor uses remote access products to access customer sites, use remote access security features such as those specified in PA-DSS Requirement 10.3.2. (2) Ensure payment application supports customers’ use of remote access security features.
Software Vendor: (1) If vendor can access customers’ payment applications remotely, implemented secure remote access such as those specified in PA-DSS Requirement 10.3.2. (2) Ensure payment application supports customers’ use of remote-access security features.
Modified
p. 51 → 87
Customers & Resellers/Integrators: Use remote access security features if you allow remote access to payment applications, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.3.2.
Customers & Integrators/Resellers: Use remote- access security features for all remote access to payment applications, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.3.2.
Modified
p. 51 → 88
Customers & Resellers/Integrators: Establish and maintain strong cryptography and security protocols for transmissions of cardholder data, per the PA-DSS Implementation Guide and PA-DSS Requirement 11.1.
Customers & Integrators/Resellers: Establish and maintain strong cryptography and security protocols for transmissions of cardholder data, per the PA-DSS Implementation Guide and PA-DSS Requirement 11.1.
Modified
p. 51 → 88
Software Vendor: Provide or specify use of a solution that renders the PAN unreadable or implements strong cryptography, and ensure payment application supports the encryption or rendering unreadable of PANs if sent with end-user messaging technologies, per PA-DSS Requirement 11.2.
Modified
p. 51 → 88
Customers & Resellers/Integrators: Encrypt all PANs sent with end-user messaging technologies, per the PA- DSS Implementation Guide and PA-DSS Requirement 11.2.
Customers & Integrators/Resellers: Render unreadable or encrypt with strong cryptography all PANs sent with end-user messaging technologies, per the PA- DSS Implementation Guide and PA-DSS Requirement 11.2.
Modified
p. 51 → 89
Software Vendor: Ensure payment application supports the encryption or rendering unreadable of PANs if sent with end-user messaging technologies, per PA-DSS Requirement 11.2.
Software Vendor: Ensure payment application supports customer’s encryption of non-console administrative access, per PA-DSS Requirement 12.2.
Modified
p. 51 → 89
Software Vendor: Ensure payment application supports customer’s encryption of any non-console administrative access, per PA-DSS Requirement 12.1.
Software Vendor: If the payment application facilitates non-console administrative access, ensure payment application implements strong encryption for non- console administrative access, per PA-DSS Requirement 12.1.
Modified
p. 51 → 89
Customers & Resellers/Integrators: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.1
Customers & Integrators/Resellers: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.1 12.2 Encrypt non-console administrative access.
Removed
p. 52
Describe how the real-world use of the payment application was simulated in the laboratory for this PA-DSS review:
2.c Verify that all critical payment application functionalities were tested.
2.c Verify that all critical payment application functionalities were tested.
Modified
p. 52 → 90
Laboratory Requirement Laboratory Validation Procedure Completed in Comments PA-QSA’s Lab Vendor’s
Laboratory Requirement Laboratory Validation Procedure
Modified
p. 52 → 90
1. Verify that the vendor’s installation manual or training provided to customers was used to perform the default installation for the payment application product on all platforms listed in the PA-DSS report.
1. Verify that the vendor’s installation manual or training provided to customers was used to perform the default installation for the payment application product on all platforms listed in the PA-DSS report to simulate real-world customer experience.
Modified
p. 52 → 90
2.b Verify that all payment application versions and platforms were tested.
2.b Verify that all payment application versions and platforms were tested, including all necessary system components and dependencies 2.c Verify that all critical payment application functionalities were tested for each version.
Modified
p. 54 → 91
6.a Use of forensic tools/methods: Forensic tools/methods were used to search all identified output for evidence of sensitive authentication data (commercial tools, scripts, etc.), per PA-DSS Requirement 1.1.1•1.1.3.4 6.b Attempt to exploit application vulnerabilities: Current vulnerabilities (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), were used to attempt to exploit the payment application(s), per PA-DSS Requirement 5.2.
6.a Use of forensic tools/methods: Forensic tools/methods were used to search all identified output for evidence of sensitive authentication data (commercial tools, scripts, etc.), per PA- DSS Requirement 1.1.1•1.1.3.6 6.b Attempt to exploit application vulnerabilities: Current vulnerabilities (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), were used to attempt to exploit the payment application(s), per PA-DSS Requirement 5.2.
Modified
p. 54 → 91
6.c Laboratory and/or processes attempted to execute arbitrary code during the payment application update process: Run the update process with arbitrary code per PA-DSS Requirement 7.2.b.
6.c Laboratory and/or processes attempted to execute arbitrary code during the payment application update process: Run the update process with arbitrary code per PA-DSS Requirement 7.2.2.
Modified
p. 54 → 92
If use of the software vendor’s lab is necessary (for example, the PA-QSA does not have the mainframe, AS400, or Tandem the payment application runs on), the PA-QSA can either (1) use equipment on loan from the vendor or (2) use the vendor’s lab facilities, provided that this is detailed in the report together with the location of the tests. For either option, the PA-QSA verifies that the vendor’s equipment and lab meet the following requirements:
Modified
p. 54 → 92
7.a The PA-QSA verifies that the vendor’s lab meets all above requirements specified in this document and documents the details in the report.
Modified
p. 54 → 92
7.b The PA-QSA must validate the clean installation of the remote lab environment to ensure the environment truly simulates a real world situation and that the vendor has not modified or tampered with the environment in any way.
Modified
p. 55 → 92
7.d All testing is either (1) performed while onsite at the vendor’s premises, or (2) performed remotely via a network connection using a secure link (for example, VPN).
Modified
p. 55 → 92
7.e Use only test card numbers for the simulation/testing•do not use live PANs for testing. These test cards can usually be obtained from the vendor or a processor or acquirer.
Modified
p. 55 → 92
8.a PA-QSA QA personnel verify that all versions and platforms identified in the PA-DSS report were included in testing.