Document Comparison
PA-DSS_v3.pdf
→
PA-DSS_v3-1.pdf
97% similar
92 → 91
Pages
34485 → 34712
Words
53
Content Changes
Content Changes
53 content changes. 80 administrative changes (dates, page numbers) hidden.
Added
p. 22
Aligns with PCI DSS Requirement 3.4 2.3.c If the application creates both hashed and truncated versions of the same PAN, examine methods for creating the hashed and truncated versions to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Added
p. 27
• For any default accounts that won’t be used, assign secure authentication and then disable or do not use the accounts.
Added
p. 62
Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.
Added
p. 68
Note: SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL Examples of open, public networks include but are not limited to:
• SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.
• SSL and early TLS are not considered strong cryptography. Payment applications must not use, or support the use of, SSL or early TLS. Applications that use or support TLS must not allow fallback to SSL.
Modified
p. 6
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.
PCI DSS applies to all entities involved in payment card processing•including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
Modified
p. 18
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 …
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 customer systems, and malicious individuals who obtain access to this information could use it to produce counterfeit payment cards, and/or to perform fraudulent …
Modified
p. 21
(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:
(Continued on next page) 2.3.a Review the PA-DSS Implementation Guide prepared by the vendor to verify the documentation includes the following guidance for customers and integrators/resellers:
Modified
p. 21
• 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.
• A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.
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 payment …
• The PAN must be rendered unreadable anywhere it is stored, even outside the payment …
• It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls must be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.
• The PAN must be rendered unreadable anywhere it is stored, even outside the payment …
• The PAN must be rendered unreadable anywhere it is stored, even outside the payment …
Modified
p. 22
2.3.d 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.e 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.f 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.g 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.b through 2.3.f, above.
Modified
p. 22
The requirement for payment applications to protect keys from disclosure and misuse applies to both data-encrypting keys and key- encrypting keys.
The requirement for payment applications to protect keys from disclosure and misuse applies to both data-encrypting keys and key- encrypting keys. It is not intended that the key- encrypting keys be encrypted, however they are to be protected against disclosure and misuse as defined in Requirement 2.4 2.4.b Examine system configuration files to verify that:
Modified
p. 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.
• How to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers are involved in these key-management activities.
Modified
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.
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.
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.
• Advised to assign secure authentication to all default accounts in the environment.
Modified
p. 31
3.1.6.c If the application uses a different minimum character set and length for passwords, calculate the entropy of the passwords required by the application, and verify that it is at least equivalent to the parameters specified above (that is, at least as strong as 7 characters in length with numeric and alphabetic characters), 3.1.7 The payment application requires changes to user passwords at least every 90 days.
3.1.6.c If the application uses a different minimum character set and length for passwords, calculate the entropy of the passwords required by the application, and verify that it is at least equivalent to the parameters specified above (that is, at least as strong as 7 characters in length with numeric and alphabetic characters), 3.1.7 The payment application requires changes to user passwords at least once every 90 days.
Modified
p. 31
• changed at least every 90 days by completion of the installation process.
• changed at least once every 90 days by completion of the installation process.
Modified
p. 31
For all types of changes performed, examine account settings and test application functionality to verify that the application requires user passwords to be changed at least every 90 days upon completion of the change.
For all types of changes performed, examine account settings and test application functionality to verify that the application requires user passwords to be changed at least once every 90 days upon completion of the change.
Modified
p. 39
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.
4.4.b Install and configure the payment application according to the PA-DSS Implementation Guide to verify that the instructions are accurate, and that functionality that facilitates a customer’s ability to assimilate logs into their centralized log server is provided.
Modified
p. 40
• Security reviews are performed at defined intervals throughout the development process and prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.
• Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.
Modified
p. 45
Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.
Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.10 and in PCI DSS at 6.5.1 through 6.5.10 were current with industry best practices when this version of PA DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.
Modified
p. 45
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.
Requirements 5.2.1 through 5.2.10 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.
Modified
p. 51
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.
Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to Requirement 5.4.3 for additional requirements on the use of wildcards.
Modified
p. 51
5.4.1.c Examine recent payment application changes, the version numbers assigned, and the change-control documentation that specifies the type of application change, and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.
5.4.1.c Select a sample of recent payment application changes, the version numbers assigned, and the change- control documentation that specifies the type of application change, and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.
Modified
p. 51
5.4.2.c Interview personnel and observe processes for each type of change to verify that the documented methodology is being followed for all types of changes.
5.4.2.c Interview personnel and observe processes for each type of change to verify that the documented methodology is followed for all types of changes.
Removed
p. 52
• Security-impacting change requires a change to other version-number element that appears “to the left of” the first wildcard element.
Modified
p. 52
• Any elements to the right of a wildcard cannot be used for a security impacting change.
• Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must appear “to the left of” the first wildcard element.
Modified
p. 52
• Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never be used to represent a security impacting change.
• Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are never used to represent a security impacting change.
Modified
p. 53
5.4.5.b Examine recent changes to confirm internal version mapping to published versioning scheme match according to the type of change.
5.4.5.b Examine recent changes to confirm that internal version mapping to published versioning scheme is updated in accordance with the type of change, as defined in the documented methodology.
Modified
p. 59 → 58
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:
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 as follows:
Modified
p. 63 → 62
For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, SSL, IPSec, or other technology.
For example, if NetBIOS, file-sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, TLS, IPSec, or other technology.
Modified
p. 63 → 62
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”.
Aligns with PCI DSS Requirement 2.2.3 8.2.a Examine system services, protocols, daemons, components, and dependent software and hardware enabled or required by the payment application. Verify that only necessary and secure services, protocols, daemons, components, dependent software and hardware are enabled by default “out of the box”.
Modified
p. 64 → 63
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 by RFC 2865) if RADIUS is intended to be a supported authentication and authorization technology. …
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 by RFC 2865) if RADIUS is intended to be a supported authentication and authorization technology.
Modified
p. 65 → 64
• 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).
• A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).
Modified
p. 67 → 66
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.
Aligns with PCI DSS Requirements 8.5.1 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a password/phrase) is used for each customer they have access to.
Modified
p. 68 → 67
• Enable account lockout after a certain number of failed login attempts. (See PA-DSS Requirement 3.1.8.)
• Enable account lockout after a certain number of failed login attempts. (See PA-DSS Requirement 3.1.9 through 3.1.10.)
Modified
p. 69 → 68
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:
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, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:
Modified
p. 69 → 68
• The encryption strength is appropriate for the encryption methodology in use Examples of open, public networks include but are not limited to:
• The encryption strength is appropriate for the encryption methodology in use
Modified
p. 69 → 68
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 affected system. Regardless of which security protocols are used by the payment application, ensure they are configured by default to use only secure configurations and versions to prevent an insecure connection being used.
Note that some protocol implementations (such as SSL, SSH version 1.0, and early TLS) have documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the affected system. Regardless of which security protocols are used by the payment application, ensure they are configured by default to use only secure configurations and versions to prevent an insecure connection being used. • How to configure the payment application to prevent fallback to an insecure version or configuration …
Modified
p. 71 → 70
Requirement 12: Encrypt all non-console administrative access PA-DSS Requirements Testing Procedures Guidance 12.1 If the payment application facilitates non- console administrative access, encrypt all such access with strong cryptography using technologies such as SSH, VPN, or SSL/TLS, for web-based management and other non-console administrative access.
Requirement 12: Encrypt all non-console administrative access PA-DSS Requirements Testing Procedures Guidance 12.1 If the payment application facilitates non- console administrative access, encrypt all such access with strong cryptography using technologies such as SSH, VPN, or TLS, for web- based management and other non-console administrative access.
Modified
p. 71 → 70
• Clear-text protocols such as Telnet or rlogin must never be used for administrative access.
Modified
p. 71 → 70
Aligns with PCI DSS Requirement 2.3 12.1.a Install the payment application in a lab and test non- console administration connections to verify that a strong encryption method is invoked before the administrator’s password is requested.
Aligns with PCI DSS Requirement 2.3 12.1.a Install the payment application in a lab and test non- console administrative connections to verify that a strong encryption method is invoked before the administrator’s password is requested.
Modified
p. 71 → 70
12.1.c Examine the PA-DSS Implementation Guide prepared by the vendor, and verify it includes instructions for customers and integrators/resellers how to configure the application to use strong cryptography, using technologies such as SSH, VPN, or SSL/TLS, for encryption of non-console administrative access.
12.1.c Examine the PA-DSS Implementation Guide prepared by the vendor, and verify it includes instructions for customers and integrators/resellers how to configure the application to use strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of non-console administrative access.
Modified
p. 71 → 70
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.
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 TLS, for encryption of all non-console administrative access.
Modified
p. 75 → 74
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.
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 customer’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.
Modified
p. 78 → 77
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.
Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1). A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.
Modified
p. 78 → 77
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.
Instructions on how to securely generate, distribute, protect, change, store, and retire/replace cryptographic keys, where customers or integrators/resellers are involved in these key- management activities. A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.
Modified
p. 80 → 79
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 …
That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements. Assign secure authentication to all default accounts in the environment For any default accounts that won’t be used, assign secure authentication and then disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed …
Modified
p. 85 → 84
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 customer can configure their firewall to open only required ports).
Modified
p. 89 → 88
If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or SSL/TLS) for encryption of all non-console administrative access to payment application or servers in cardholder data environment.
If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or TLS) for encryption of all non- console administrative access to payment application or servers in cardholder data environment.
Modified
p. 89 → 88
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.
Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all non-console administrative access.