Document Comparison
PA-DSS_v3-1.pdf
→
PA-DSS_v3-2.pdf
92% similar
91 → 92
Pages
34712 → 35584
Words
236
Content Changes
Content Changes
236 content changes. 98 administrative changes (dates, page numbers) hidden.
Added
p. 20
The masking approach should always ensure that only the minimum number of digits are displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits.
Added
p. 21
As another example, if a function needs access to the bank identification number (BIN) for routing purposes, unmask only the BIN digits (traditionally the first six digits) during that function.
Added
p. 32
Passwords/passphrases that are valid for a long time without being changed provide malicious individuals with more time to work on breaking the password/passphrase.
Added
p. 51
Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.) Definition of elements that indicate use of wildcards.
Added
p. 56
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 between the wireless environment and the cardholder data environment.
Default SNMP community strings on wireless devices were changed at installation. …
Default SNMP community strings on wireless devices were changed at installation. …
Added
p. 61
How the vendor will communicate notifications of new patches and updates.
How patches and updates will be delivered in a secure manner with a known chain of trust.
How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.
Advising customers and integrators/resellers of the process for receiving and installing patches securely helps protect the integrity of the update process and the application.
How patches and updates will be delivered in a secure manner with a known chain of trust.
How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.
Advising customers and integrators/resellers of the process for receiving and installing patches securely helps protect the integrity of the update process and the application.
Added
p. 68
The protocol is implemented by default to use only trusted keys and/or certificates. The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations. The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL). Proper encryption strength is implemented for the encryption methodology in use.
Added
p. 71
Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).
Aligns with PCI DSS Requirement 8.3 12.2.a Verify that multi-factor authentication is provided with the application, or that use thereof is specified.
Administrative access requires a higher level of assurance that the individual attempting to gain access is who they claim to be.
As multi-factor authentication may be implemented at the application, system, or network level, it is not required that all applications include a multi-factor authentication solution. Application vendors can either provide multi-factor authentication with their application, or include instructions for users and integrators/resellers to install multi-factor authentication for administrative access to the application.
12.2.b Examine PA-DSS Implementation Guide prepared by the vendor, and verify it includes directions for customers and integrators/resellers to use multi-factor authentication, including:
Instruction that multi-factor authentication must be used for all personnel with …
Aligns with PCI DSS Requirement 8.3 12.2.a Verify that multi-factor authentication is provided with the application, or that use thereof is specified.
Administrative access requires a higher level of assurance that the individual attempting to gain access is who they claim to be.
As multi-factor authentication may be implemented at the application, system, or network level, it is not required that all applications include a multi-factor authentication solution. Application vendors can either provide multi-factor authentication with their application, or include instructions for users and integrators/resellers to install multi-factor authentication for administrative access to the application.
12.2.b Examine PA-DSS Implementation Guide prepared by the vendor, and verify it includes directions for customers and integrators/resellers to use multi-factor authentication, including:
Instruction that multi-factor authentication must be used for all personnel with …
Added
p. 85
How the vendor will communicate notifications of new patches and updates.
How patches and updates will be delivered in a secure manner with a known chain of trust.
How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.
The following must be provided for customers and integrators/resellers:
Software Vendor: Document and implement processes for communication, delivery and secure installation of patches and updates.
Customers and Integrators/Resellers: Access and install patches and updates in a secure manner, in accordance with PA-DSS Implementation Guide.
How patches and updates will be delivered in a secure manner with a known chain of trust.
How to access and install patches and updates in a manner that maintains the integrity of the patch and update code.
The following must be provided for customers and integrators/resellers:
Software Vendor: Document and implement processes for communication, delivery and secure installation of patches and updates.
Customers and Integrators/Resellers: Access and install patches and updates in a secure manner, in accordance with PA-DSS Implementation Guide.
Added
p. 89
Instruction that multi-factor authentication must be used for all personnel with non-console administrative access to the CDE. Procedures for using the multi-factor authentication provided with the application (if provided).
Added
p. 89
Customers & Integrators/Resellers: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.1.1.
Added
p. 89
Include instructions for customers and integrators/resellers to use multi-factor authentication, including:
Software Vendor: Ensure payment application provides or specifies use of multi-factor authentication for all personnel with non-console administrative access, per PA-DSS Requirement 12.2.
Customers & Integrators/Resellers: Use multi-factor authentication for all non-console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.2.
Software Vendor: Ensure payment application provides or specifies use of multi-factor authentication for all personnel with non-console administrative access, per PA-DSS Requirement 12.2.
Customers & Integrators/Resellers: Use multi-factor authentication for all non-console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.2.
Modified
p. 6
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 environment, they must be protected in accordance with all applicable PCI DSS requirements.
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 environment (CDE), they must be protected in accordance with all applicable PCI DSS requirements.
Modified
p. 13
Applicability of PA-DSS to different types of applications PA-DSS report submission and acceptance processes Annual renewal process for payment applications included on the List of Validated Payment Applications Notification responsibilities in the event a listed payment application is determined to be at fault in a compromise.
Details of different PA-DSS versions and their effective dates Applicability of PA-DSS to different types of applications PA-DSS report submission and acceptance processes Annual renewal process for payment applications included on the List of Validated Payment Applications Notification responsibilities in the event a listed payment application is determined to be at fault in a compromise.
Removed
p. 16
• The accountholder’s name,
• Primary account number (PAN),
• Expiration date, and
• Primary account number (PAN),
• Expiration date, and
Modified
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.
Modified
p. 18
Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application).
Modified
p. 18
How to remove historical data.
Modified
p. 18
That such removal is absolutely necessary for PCI DSS compliance.
Modified
p. 19
Sensitive authentication data is collected only when needed to solve a specific problem.
Modified
p. 19
Such data is stored in a specific, known location with limited access.
Modified
p. 19
The minimum amount of data is collected as needed to solve a specific problem.
Modified
p. 19
Sensitive authentication data is encrypted with strong cryptography while stored.
Modified
p. 19
Data is securely deleted immediately after use, including from:
Modified
p. 19
Collection of sensitive authentication data only when needed to solve a specific problem.
Modified
p. 19
Storage of such data in a specific, known location with limited access.
Modified
p. 19
Collection of only a limited amount of data needed to solve a specific problem.
Modified
p. 19
Encryption of sensitive authentication data while stored.
Modified
p. 19
Secure deletion of such data immediately after use.
Modified
p. 19
Collect sensitive authentication only when needed to solve a specific problem.
Modified
p. 19
Store such data only in specific, known locations with limited access.
Modified
p. 19
Collect only the limited amount of data needed to solve a specific problem.
Modified
p. 19
Encrypt sensitive authentication data while stored.
Modified
p. 19
Securely delete such data immediately after use.
Modified
p. 20
Cardholder data exceeding the customer-defined retention period must be securely deleted. A list of all locations where the payment application stores cardholder data (so that customer knows the locations of data that needs to be deleted). Instructions that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes. Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or systems …
Modified
p. 20
Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts. Confirmation that the payment application masks PAN by default on all displays. Instructions for how to configure the payment application such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN (includes displays of the full PAN).
Removed
p. 21
• One-way hashes based on strong cryptography
• Index tokens and pads, with the pads being securely stored
• Index tokens and pads, with the pads being securely stored
Modified
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.
2.2.c Configure the payment application according to the PA-DSS Implementation Guide to allow only personnel with a legitimate business need to see more than the first six/last four digits of the PAN. For each instance where PAN is displayed, examine application configurations and displays of PAN to verify that instructions for masking PAN are accurate, and that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.
Modified
p. 21
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.
Modified
p. 21
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. 21 → 22
Aligns with PCI DSS Requirement 3.4 2.3.b 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:
Modified
p. 21 → 22
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.
Removed
p. 22
• Keys are stored in encrypted format
• Key-encrypting keys are stored separately from data-encrypting keys
• Key-encrypting keys are stored separately from data-encrypting keys
Modified
p. 22
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.
Modified
p. 22 → 23
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:
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 There should be very few who have access to cryptographic keys, usually only those who have key custodian responsibilities.
Modified
p. 22 → 23
Keys are stored in encrypted format Key-encrypting keys are stored separately from data-encrypting keys Key-encrypting keys are at least as strong as the data encrypting keys they protect.
Removed
p. 23
• Store keys securely in the fewest possible locations and forms.
• A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.
• A sample Key Custodian Form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.
Modified
p. 23
Restrict access to keys to the fewest number of custodians necessary. Store keys securely in the fewest possible locations and forms.
Modified
p. 23
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. 24
Defined cryptoperiod for each key type used by the application.
Modified
p. 24
Procedures for enforcing key changes at the end of the defined cryptoperiod.
Modified
p. 24 → 25
Instructions that keys must be retired or replaced when the integrity of the key has been weakened, or there is a known or suspected compromise of a key.
Modified
p. 24 → 25
Procedures for retiring or replacing keys (for example: by archiving, destruction, and/or revocation as applicable).
Modified
p. 24 → 25
Procedures for ensuring that retired or replaced cryptographic keys are not used for encryption operations.
Modified
p. 25 → 26
Details of any manual clear-text cryptographic key-management operations supported by the application.
Modified
p. 25 → 26
Instructions for enforcing split knowledge and dual control for all such operations.
Removed
p. 26
• The deletion of the key-encrypting key (KEK) provided that residual data- encrypting keys only exist in encrypted form under the deleted KEK.
Modified
p. 26 → 27
Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable. That cryptographic key material should be rendered irretrievable whenever keys are no longer used and in accordance with key-management requirements in PCI DSS. Procedures for re-encrypting historic data with new keys, including procedures for maintaining security of clear-text data during the decryption/re-encryption process.
Modified
p. 26 → 27
Secure deletion, as defined, for example, in the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations. The deletion of the key-encrypting key (KEK) provided that residual data- encrypting keys only exist in encrypted form under the deleted KEK.
Modified
p. 27 → 28
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 → 28
- Enforcing secure changes to authentication credentials by the completion of installation per Requirements 3.1.1 through 3.1.11). - Enforcing secure changes for any subsequent changes (after installation) to authentication credentials per Requirements 3.1.1 through 3.1.11). Advised that, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements. Advised to assign secure authentication to all default accounts in the …
Modified
p. 30 → 31
Require a minimum length of at least seven characters.
Modified
p. 30 → 31
Contain both numeric and alphabetic characters.
Modified
p. 30 → 31
Contain both numeric and alphabetic characters.
Modified
p. 30 → 31
Alternatively, the passwords/phrase must have complexity and strength at least equivalent to the parameters specified above.
Alternatively, the passwords/passphrase must have complexity and strength at least equivalent to the parameters specified above.
Modified
p. 30 → 31
Be at least seven characters in length.
Removed
p. 31
• Contain both numeric and alphabetic characters.
Passwords/phrases that are valid for a long time without being
• changed at least once every 90 days by completion of the installation process.
Passwords/phrases that are valid for a long time without being
• changed at least once every 90 days by completion of the installation process.
Modified
p. 31 → 32
Be at least seven characters in length Contain both numeric and alphabetic characters.
Modified
p. 31 → 32
3.1.7.a Install the payment application in accordance with the PA-DSS Implementation Guide and examine account settings to verify that the application requires user passwords to be changed at least once every 90 days by completion of the installation process.
Modified
p. 34 → 35
Stored passwords are rendered unreadable using a strong, one-way cryptographic algorithm, based on approved standards.
Modified
p. 34 → 35
A unique input variable is concatenated with each password before the cryptographic algorithm is applied.
Removed
p. 35
• By default, 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.
• 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.
• All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
Modified
p. 35 → 36
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.
Modified
p. 35 → 36
All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account. All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
Modified
p. 35 → 36
All application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account. All application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.
Modified
p. 36 → 37
It is critical that the payment application has a process or mechanism that links users to the application resources accessed, generates audit logs, and provides the ability to trace back suspicious activity to a specific user. Post- incident forensic teams heavily depend on these logs to initiate the investigation.
It is critical that the payment application has a process or mechanism that links users to the application resources accessed, generates audit logs, and provides the ability to trace back suspicious activity to a specific user. Post-incident forensic teams heavily depend on these logs to initiate the investigation.
Modified
p. 36 → 37
4.1.b Examine the PA-DSS Implementation Guide prepared by the vendor to verify the following instructions are included: • How to install the application so that logs are configured and enabled by default upon completion of the installation process. • How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3, and 4.4 below, for any logging options that are configurable by the customer after installation. • Logs should not be disabled and doing so will result in non- compliance …
4.1.b Examine the PA-DSS Implementation Guide prepared by the vendor to verify the following instructions are included: How to install the application so that logs are configured and enabled by default upon completion of the installation process. How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3, and 4.4 below, for any logging options that are configurable by the customer after installation. Logs should not be disabled and doing so will result in non-compliance with …
Modified
p. 38
Initialization of application audit logs Stopping or pausing of application audit logs.
Removed
p. 39
• A description of which centralized logging mechanisms are supported
• Instructions and procedures for incorporating the payment application logs into a centralized logging environment.
• Instructions and procedures for incorporating the payment application logs into a centralized logging environment.
Modified
p. 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. 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:
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 Instructions and procedures for incorporating the payment application logs into a centralized logging environment.
Modified
p. 39
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.
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 …
Removed
p. 40
• Developing payment applications in accordance with PCI DSS and PA-DSS Requirements.
• Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.
• Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.
• Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.
• Payment applications are developed in accordance with PCI DSS and PA-DSS Requirements.
Modified
p. 40
Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging). Development processes are based on industry standards and/or best practices. Information security is incorporated throughout the software development life cycle. Security reviews are performed prior to release of an application or application update.
Modified
p. 40
Incorporating information security throughout the software development life cycle. Developing payment applications in accordance with PCI DSS and PA-DSS Requirements.
Modified
p. 40
Defined security reviews prior to release of an application or application update. Procedures for security reviews to be performed to ensure the security objectives of PCI DSS and PA-DSS are being met.
Modified
p. 40
Information security is incorporated throughout the software development life cycle. Payment applications are developed in accordance with
Modified
p. 40
PCI DSS and PA-DSS Requirements. Security reviews are performed prior to release, to ensure that security objectives, including PCI DSS and PA-DSS requirements, are being met.
Removed
p. 42
• Appropriate corrections are implemented prior to release.
• Appropriate corrections are implemented prior to release.
• Appropriate corrections are implemented prior to release.
Modified
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.
Modified
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.
Modified
p. 42
Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) Appropriate corrections are implemented prior to release.
Modified
p. 42
Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.) Appropriate corrections are implemented prior to release.
Modified
p. 42
Code-review results are reviewed and approved by management prior to release.
Modified
p. 42
Code-review results are reviewed and approved by management prior to release.
Modified
p. 42
Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior to release.
Modified
p. 42
Code-review results are documented including management approval, code author, and code reviewer, and what corrections were implemented prior to release.
Modified
p. 42
Code reviews were performed by a knowledgeable individual other than the code author.
Modified
p. 42
Code reviews were developed according to secure coding guidelines.
Modified
p. 42
Appropriate corrections were implemented prior to release.
Modified
p. 42
Code-review results were reviewed and approved by management prior to release.
Modified
p. 43
Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
Modified
p. 43
Developing with fail-safe defaults (all execution is by default denied unless specified within initial design).
Modified
p. 43
Developing with fail-safe default (all execution is by default denied unless specified within initial design).
Removed
p. 45
• Secure application design
• Managing sensitive data in memory
• Security testing (for example, penetration- testing techniques)
• Risk-assessment techniques.
• Managing sensitive data in memory
• Security testing (for example, penetration- testing techniques)
• Risk-assessment techniques.
Modified
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 Code reviews Security testing (for example, penetration- testing techniques) Risk-assessment techniques.
Modified
p. 45
5.1.7a Verify documented software-development processes require training in secure development practices for application developers as applicable for the developer’s job function and technology used.
5.1.7a Verify documented software-development processes require up-to-date training in secure development practices for application developers at least annually, as applicable for the developer’s job function and technology used.
Modified
p. 45
5.1.7.c Examine records of training to verify that all application developers receive training as applicable for their job function and technology used.
5.1.7.c Examine records of training to verify that all application developers receive training at least annually, as applicable for their job function and technology used.
Removed
p. 46
• Utilizing parameterized queries.
• Truncating input strings.
• Prevent cryptographic flaws
• Truncating input strings.
• Prevent cryptographic flaws
Modified
p. 46
Validating input to verify user data cannot modify meaning of commands and queries Utilizing parameterized queries.
Modified
p. 46 → 47
Validating buffer boundaries Truncating input strings.
Modified
p. 46 → 47
Prevent cryptographic flaws Use strong cryptographic algorithms and keys.
Removed
p. 48
• Utilizing context-sensitive escaping.
• Proper authentication of users
• Not exposing internal object references to users
• Proper authentication of users
• Not exposing internal object references to users
Modified
p. 48
Validating all parameters before inclusion Utilizing context-sensitive escaping.
Modified
p. 48 → 49
Proper authentication of users Sanitizing input Not exposing internal object references to users User interfaces that do not permit access to unauthorized functions.
Removed
p. 49
• Flagging session tokens (for example cookies) as “secure”
• Not exposing session IDs in the URL
• Verify that the procedures require items 5.3.1
• Not exposing session IDs in the URL
• Verify that the procedures require items 5.3.1
Modified
p. 49
Flagging session tokens (for example cookies) as Not exposing session IDs in the URL Incorporating appropriate time-outs and rotation of session IDs after a successful login.
Modified
p. 49 → 50
Verify the procedures follow documented software- development processes as defined in Requirement 5.1 Verify that the procedures require items 5.3.1
• 5.3.4 below.
• 5.3.4 below.
Removed
p. 50
• Definition of elements that indicate use of wildcards.
Modified
p. 50 → 51
Details of how the elements of the version scheme are in accordance with requirements specified in the PA-DSS Program Guide.
Modified
p. 50 → 51
The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters).
Modified
p. 50 → 51
5.4.1.a Examine the documented versioning methodology to verify it includes the following:
Modified
p. 50 → 51
Details of how the elements of the version numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.
Modified
p. 50 → 51
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).
Modified
p. 50 → 51
A definition of what each element represents in the version-numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.) Definition of elements that indicate use of wildcards.
Removed
p. 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.)
• Specific identification and definition of changes that:
• Definition of what each element represents in the version scheme (for example, type of change, major, minor, or maintenance release, wildcard, etc.)
• Specific identification and definition of changes that:
Modified
p. 51 → 52
Descriptions of all types and impacts of application changes.
Modified
p. 51 → 52
Specific identification and definition of changes that:
Modified
p. 51 → 52
How each type of change ties to a specific version number.
Modified
p. 51 → 52
How each type of change ties to a specific version number.
Modified
p. 51 → 52
Description of all types and impacts of application changes (for example, changes that have no impact, low impact, or high impact to the application) Specific identification and definition of changes that:
Modified
p. 52 → 53
Details of how wildcards are used in the versioning methodology.
Modified
p. 52 → 53
Details of how wildcards are used in the versioning methodology.
Modified
p. 52 → 53
Wildcards are never used for any change that has an impact on security or any PA- DSS requirements.
Modified
p. 52 → 53
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.
Modified
p. 52 → 53
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.
Modified
p. 52 → 53
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.
Modified
p. 52 → 53
Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.
Modified
p. 52 → 53
Wildcards are never used for any change that has an impact on security or any PA-DSS requirements.
Modified
p. 52 → 53
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 → 53
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
Wildcards are not used for any change that has an impact on security or any PA-DSS requirements.
Modified
p. 53
Elements of the version number used to represent non- security-impacting changes (including a wildcard element) are not used to represent a security impacting change.
Modified
p. 53 → 54
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.).
Modified
p. 53 → 54
Details of how security-impacting changes will be indicated by the version scheme.
Modified
p. 53 → 54
Details of how other types of changes will affect the version.
Modified
p. 53 → 54
Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change.
Modified
p. 54 → 55
Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust-boundaries. Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data. A list of potential threats and vulnerabilities …
Modified
p. 54 → 55
Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust boundaries. Assessment of application decision points, process flows, data flows, data storage, and trust boundaries. Identification of all areas within payment applications that interact with PAN/SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data. A list of potential threats and vulnerabilities resulting from …
Removed
p. 55
• Confirmation that secure development processes were followed by the vendor.
• Formal approval and signature by an authorized party
• Confirmation that that all secure development processes were followed.
• Formal approval and signature by an authorized party
• Confirmation that that all secure development processes were followed.
Modified
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.
Modified
p. 55
5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes
5.6.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes Formal approval and signature by an authorized party Confirmation that that all secure development processes were followed.
Removed
p. 56
• 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 between the wireless environment and the cardholder data environment.
• Default SNMP community strings on wireless devices were
• changed at installation.
• changed at installation.
• Default passwords/passphrases on …
• 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 between the wireless environment and the cardholder data environment.
• Default SNMP community strings on wireless devices were
• changed at installation.
• changed at installation.
• Default passwords/passphrases on …
Modified
p. 57
Encryption keys were changed from default at installation.
Removed
p. 58
• How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission.
• Instructions to change all wireless default encryption keys, passwords, and SNMP community strings upon installation.
• Instructions to change wireless encryption keys, passwords, and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.
• Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.
• Instructions to change all wireless default encryption keys, passwords, and SNMP community strings upon installation.
• Instructions to change wireless encryption keys, passwords, and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions.
• Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission.
Modified
p. 58
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.
Modified
p. 58
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 …
Removed
p. 59
• Assign a risk ranking to all identified vulnerabilities
• Test payment applications and updates for the presence of vulnerabilities prior to release.
• Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US-CERT websites).
• Test payment applications and updates for the presence of vulnerabilities prior to release.
• Using reputable sources (such as software/systems vendor websites, NIST’s NVD, MITRE’s CVE, and the DHS’s US-CERT websites).
Modified
p. 59
Identify new security vulnerabilities using reputable sources for obtaining security vulnerability information Assign a risk ranking to all identified vulnerabilities Test payment applications and updates for the presence of vulnerabilities prior to release.
Modified
p. 59
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).
Removed
p. 62
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
Note: Two-factor authentication requires that two of the three authentication methods (see below) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. The authentication methods, also known as a factors, are:
Note: Multi-factor authentication requires that at least two of the three authentication methods (see below) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication. The authentication methods, also known as a factors, are:
Modified
p. 63
• Something you have, such as a token device or smart card
• Something you are, such as a biometric
Examples of multi-factor technologies include but are not limited to RADIUS with tokens, TACACS with tokens, or other technologies that facilitate multi-factor authentication.
Modified
p. 63
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.
Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric Aligns with PCI DSS Requirement 8.3 8.3.a Examine payment application functionality to verify it does not require use of any services or protocols that preclude the use of or interfere with the normal operation of multi-factor authentication technologies.
Modified
p. 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 multi-factor authentication solutions for secure 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. 63
8.3.b Identify remote-access mechanisms supported by the application and verify that the mechanisms do not prevent two- factor authentication.
8.3.b Identify remote-access mechanisms supported by the application and verify that the mechanisms do not prevent multi-factor authentication.
Removed
p. 64
• Instructions not to store cardholder data on public-facing systems (for example, web server and database server must not be on same server).
• A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).
• A list of services/ports that the application needs to use in order to communicate across two network zones (so the customer can configure their firewall to open only required ports).
Modified
p. 64
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 (for example, installing a web server component in a DMZ and installing a data storage component on an internal different network zone). A list of services/ports that the application needs to use in order …
Removed
p. 65
• A description of two-factor authentication mechanisms supported by the application.
• Instructions for configuring the application to support two- factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).
• Instructions for configuring the application to support two- factor authentication (two of the three authentication methods described in PA DSS Requirement 3.1.4).
Modified
p. 65
Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements Testing Procedures Guidance 10.1 Two-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.
Requirement 10: Facilitate secure remote access to payment application PA-DSS Requirements Testing Procedures Guidance 10.1 Multi-factor authentication must be used for all remote access to the payment application that originates from outside the customer environment.
Modified
p. 65
Note: Two-factor authentication requires that two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).
Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods).
Modified
p. 65
Instructions that all remote access originating from outside the customer’s network to the payment application must use multi-factor authentication in order to meet PCI DSS requirements. A description of multi-factor authentication mechanisms supported by the application. Instructions for configuring the application to support multi-factor authentication (at least two of the three authentication methods described in PA DSS Requirement 3.1.4).
Modified
p. 65
Multi-factor authentication requires at least two methods of authentication for access originating from outside the network.
Modified
p. 65
Payment application vendors will need to provide instructions to customers for configuring the application to support the specified two-factor authentication mechanisms in order to ensure those mechanisms can be implemented properly and meet applicable PCI DSS requirements.
Payment application vendors will need to provide instructions to customers for configuring the application to support the specified multi-factor authentication mechanisms in order to ensure those mechanisms can be implemented properly and meet applicable PCI DSS requirements.
Modified
p. 65
The requirement for two-factor authentication applies only where the remote access originates from outside the customer environment 10.1.b If the application vendor has remote access to a customer’s payment application that originates from outside the customer environment, examine vendor policies to verify that the vendor supports customer requirements for two-factor authentication for all such access.
The requirement for multi-factor authentication applies to all personnel with remote access that originates from outside the customer environment. 10.1.b If the application vendor has remote access to a customer’s payment application that originates from outside the customer environment, examine vendor policies to verify that the vendor supports customer requirements for multi- factor authentication for all such access.
Modified
p. 65 → 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. 65 → 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. services being delivered by those providers•should support all applicable PCI DSS requirements.
Modified
p. 66
Activation of remote-access technologies to customer networks only when needed and immediate deactivation after use.
Modified
p. 66
If remote access is via VPN or other high-speed connection, the connection is secured according to PCI DSS Requirement 1.
Modified
p. 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 authentication credential (such as a password/phrase) is used for each customer they have access to.
Aligns with PCI DSS Requirements 8.5.1 10.2.2 If vendors or integrators/resellers can access customers’ payment applications remotely, examine vendor processes and interview personnel to verify that a unique authentication credential (such as a password/passphrase) is used for each customer they have access to.
Removed
p. 67
• Establish a VPN connection via a firewall before access is allowed.
• Establish a VPN connection via a firewall before access is allowed.
• Establish a VPN connection via a firewall before access is allowed.
Modified
p. 67
Change default settings in the remote- access software (for example, change default passwords and use unique passwords for each customer).
Modified
p. 67
Allow connections only from specific (known) IP/MAC addresses.
Modified
p. 67
Allow connections only from specific (known) IP/MAC addresses.
Modified
p. 67
Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11).
Modified
p. 67
Use strong authentication and complex passwords for logins (See PA-DSS Requirements 3.1.1 through 3.1.11).
Modified
p. 67
Enable encrypted data transmission according to PA-DSS Requirement 12.1.
Modified
p. 67
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.
Modified
p. 67
Enable the logging function.
Modified
p. 67
Enable the logging function.
Modified
p. 67
Restrict access to customer environments to authorized integrators/resellers personnel.
Modified
p. 67
Change default settings in the remote-access software (for example, change default passwords and use unique passwords for each customer).
Modified
p. 67
Enable encrypted data transmission according to PA- DSS Requirement 12.1.
Modified
p. 67
Enable account lockout after a certain number of failed login attempts. (See PA-DSS Requirement 3.1.9 through 3.1.10.) Establish a VPN connection via a firewall before access is allowed.
Modified
p. 67
Restrict access to customer environments to authorized personnel.
Removed
p. 68
• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations
• 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)
• The protocol is implemented by default to use only trusted keys and/or certificates.
• The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations.
• The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL).
• Proper encryption strength is implemented for the encryption methodology in use.
• The protocol in use only supports secure versions or configurations
• 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)
• The protocol is implemented by default to use only trusted keys and/or certificates.
• The protocol is implemented by default to use only secure configurations and does not support insecure versions or configurations.
• The protocol is implemented by default to not allow fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL).
• Proper encryption strength is implemented for the encryption methodology in use.
Modified
p. 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, TLS, IPSEC, 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 to safeguard sensitive cardholder data during transmission over open, public networks, including at least the following:
Modified
p. 68
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
Modified
p. 68
The Internet Wireless technologies, including but not limited to 802.11 and Bluetooth Cellular technologies, for example, Global System for Mobile Communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS) Satellite communications Aligns with PCI DSS Requirement 4.1 11.1.a If the payment application sends, or facilitates sending, cardholder data over public networks, verify that strong cryptography and security protocols are provided with the application, or that use thereof is specified.
Modified
p. 68
Instructions that strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks. Instructions for verifying that only trusted keys and/or certificates are accepted. How to configure the payment application to use only secure versions and secure implementations of security protocols. How to configure the payment application to prevent fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL). …
Removed
p. 69
• Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.
Modified
p. 69
Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography. Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.
Modified
p. 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 TLS, for web- based management and other non-console administrative access.
Requirement 12: Secure 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.
Modified
p. 70
Clear-text protocols such as Telnet or rlogin must never be used for administrative access.
Modified
p. 70
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. 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 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 for encryption of non-console administrative access.
Modified
p. 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 TLS, for encryption of all non-console administrative access.
Aligns with PCI DSS Requirement 2.3 12.1.1 Examine the PA-DSS Implementation Guide prepared by the vendor and verify it includes instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.
Removed
p. 71
• The vendor has a mechanism in place to provide the PA- DSS Implementation Guide to customers, resellers, and integrators upon request.
• Upon changes to the application
• Changes to the application or its dependencies.
• Upon changes to the application
• Changes to the application or its dependencies.
Modified
p. 71 → 72
The PA-DSS Implementation Guide is disseminated to all customers, resellers, and integrators with the application. The vendor has a mechanism in place to provide the PA-DSS Implementation Guide to customers, resellers, and integrators upon request.
Modified
p. 71 → 72
Clearly identifies the payment application name and version to which it applies.
Modified
p. 71 → 72
Provides details of all application dependencies that are required in order for the application to be configured in a PCI DSS compliant manner.
Modified
p. 71 → 72
At least annually Upon changes to the application Upon changes to these PA-DSS requirements.
Modified
p. 71 → 72
Changes to the PA-DSS requirements Changes to the application or its dependencies.
Removed
p. 73
• Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
• Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
• Ensuring secure coding practices are followed
• Ensuring secure coding practices are followed
• Ensuring integrators/resellers receive training and supporting materials
• Ensuring integrators/resellers receive training and supporting materials
• Overall accountability for meeting all the requirements in PA-DSS
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
• Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
• Ensuring secure coding practices are followed
• Ensuring secure coding practices are followed
• Ensuring integrators/resellers receive training and supporting materials
• Ensuring integrators/resellers receive training and supporting materials
• Overall accountability for meeting all the requirements in PA-DSS
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
Modified
p. 73
Overall accountability for meeting all the requirements in PA-DSS Keeping up-to-date within any changes in the
Modified
p. 73
PCI SSC PA-DSS Program Guide Ensuring secure coding practices are followed Ensuring integrators/resellers receive training and supporting materials Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training 14.2.a Examine documented responsibilities to verify that responsibility for the following roles is formally assigned:
Modified
p. 73
Overall accountability for meeting all the requirements in PA-DSS Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide Ensuring secure coding practices are followed Ensuring integrators/resellers receive training and supporting materials Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training.
Removed
p. 74
• 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).
• Training materials are provided to integrators and resellers
• Updated as needed to keep the documentation current with new payment application versions and changes to PA-DSS requirements.
• Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
• Training materials are provided to integrators and resellers
• Updated as needed to keep the documentation current with new payment application versions and changes to PA-DSS requirements.
Modified
p. 74
How to implement the payment application and related systems and networks in a PCI DSS-compliant manner Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
Modified
p. 74
Training on how to implement the payment application and related systems and networks in a PCI DSS compliant manner Coverage of all items noted for the PA-DSS Implementation Guide throughout this document (and in Appendix A).
Modified
p. 74
Training materials are provided to integrators and resellers The vendor has a mechanism in place to provide updated materials to integrators and resellers upon request.
Modified
p. 74
Reviewed at least annually and upon changes to the application or to PA-DSS requirements Updated as needed to keep the documentation current with new payment application versions and changes to PA-DSS requirements.
Modified
p. 76
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.
Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts. Confirmation that the payment application masks PAN by default on all displays. Instructions on how to configure the payment application such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN (includes displays of the full PAN).
Modified
p. 76
Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see the full PAN.
Software Vendor: Provide instructions to customers for masking PAN so only personnel with a business need can see more than the first six/last four digits of the PAN.
Modified
p. 76
Customers & Integrators/Resellers: Mask displays of PAN so only personnel with a business need can see the full PAN, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.2.
Customers & Integrators/Resellers: Mask displays of PAN so only personnel with a business need can see more than the first six/last four digits of the PAN, per the PA-DSS Implementation Guide and PA-DSS Requirement 2.2.
Modified
p. 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 customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances.
Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1). A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering PAN unreadable in all such instances. …
Modified
p. 79 → 80
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 …
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 → 86
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).
Instruction that all remote access originating from outside the customer’s network to the payment application must use multi-factor authentication in order to meet PCI DSS requirements. Description of the multi-factor authentication mechanisms supported by the application. Instructions on how to configure the application to support multi-factor authentication (at least two of the three authentication methods described in PA DSS Requirement 3.1.4).
Modified
p. 85 → 86
Software Vendor: Ensure payment application supports customers’ use of two-factor authentication for all remote access to the payment application that originates from outside the customer environment, per PA-DSS Requirement 10.2.
Software Vendor: Ensure payment application supports customers’ use of multi-factor authentication for all remote access to the payment application that originates from outside the customer environment, per PA-DSS Requirement 10.2.
Modified
p. 85 → 86
Customers & Integrators/Resellers: Establish and maintain two-factor authentication for all remote access to payment application that originates from outside the customer environment, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.
Customers & Integrators/Resellers: Establish and maintain multi-factor authentication for all remote access to payment application that originates from outside the customer environment, per the PA-DSS Implementation Guide and PA-DSS Requirement 10.2.
Modified
p. 87 → 88
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.
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 prevent fallback to an insecure version or configuration (e.g. if TLS is used, the application must not allow fallback to SSL). How to …
Modified
p. 88 → 89
If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or TLS) for encryption of all non- console administrative access to payment application or servers in cardholder data environment.
If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography for encryption of all non-console administrative access to payment application or servers in cardholder data environment.
Modified
p. 88 → 89
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.
Customers & Integrators/Resellers: Encrypt all non- console administrative access, per the PA-DSS Implementation Guide and PA-DSS Requirement 12.1.
Modified
p. 88 → 89
Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or TLS, for encryption of all non-console administrative access.
Include instructions for customers and integrators/resellers to implement strong cryptography for encryption of all non-console administrative access.
Modified
p. 88 → 89
Software Vendor: Ensure payment application supports customer’s encryption of non-console administrative access, per PA-DSS Requirement 12.2.
Software Vendor: Ensure payment application supports customer’s encryption of non-console administrative access, per PA-DSS Requirement 12.1.1.
Modified
p. 91 → 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.
7.e Use only test card numbers for the simulation/testing•do not use live PANs for testing.