Document Comparison
Mobile_Payments_on_COTS-v1.0.pdf
→
Mobile_Payments_on_COTS-v1-0-1.pdf
98% similar
253 → 253
Pages
91052 → 91607
Words
21
Content Changes
Content Changes
21 content changes. 233 administrative changes (dates, page numbers) hidden.
Modified
p. 1
Payment Card Industry (PCI) Mobile Payments on COTS Security and Test Requirements Version 1.0
Payment Card Industry (PCI) Mobile Payments on COTS Security and Test Requirements Version 1.0.1
Modified
p. 11
Assets Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive elements. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. Software may also be considered an assets if the correct operation of that software is required to provide security protection to other assets. See also Sensitive assets.
Assets Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive elements. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. Software may also be considered an asset if the correct operation of that software is required to provide security protection to other assets. See also Sensitive assets.
Modified
p. 17
Protection types The specific form of protection required for an assets, including one or more of confidentiality, integrity, and authentication.
Protection types The specific form of protection required for an asset, including one or more of confidentiality, integrity, and authentication.
Modified
p. 21
Figure 2 shows the functional model of the solution that uses a software MPoC Application, with the option of additional hardware in the form of PCI PTS SCRP or Magnetic Stripe Reader (non-PTS approved MSR), for protecting account data. This standard defines the requirements for assessment to validate candidate MPoC Products prior to it being listed on the PCI SSC website. For details on compliance programs outlining the use of listed MPoC Products, please refer to the relevant payment card …
Figure 2 shows the functional model of the solution that uses a software MPoC Application, with the option of additional hardware in the form of PCI PTS SCRP or Magnetic Stripe Reader (non-PTS approved MSR), for protecting account data.
Modified
p. 22
• Manually entered account data and cardholder verification methods:
• Manually entered account data and cardholder verification methods
Modified
p. 25
• A non-Isolated MPoC SDK. A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive assets from the MPoC Application.
• A non-Isolated MPoC SDK A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive assets from the MPoC Application.
Modified
p. 42
An “observation” test process generally differs from a “testing” test process in that it involves some aspect of the normal operation of the system under test rather than testing of some subsystem or subfunction. For example, a process involving validation of protections against Man-in-the-Middle attacks through manipulation of a TLS connection from a functioning system would be “observation.” Side- channel analysis of the cryptography implement during the TLS process would be performed as part of “testing.”
An “observation” test process generally differs from a “testing” test process in that it involves some aspect of the normal operation of the system under test rather than testing of some subsystem or subfunction. For example, a process involving validation of protections against Man-in-the-Middle attacks through manipulation of a TLS connection from a functioning system would be “observation.” Side-channel analysis of the cryptography implement during the TLS process would be performed as part of “testing.”
Modified
p. 45
• Secure Entry and Processing of Account Data. Although not an optional Module, this includes optional Sections that provides security requirements for account data entry methods, such as COTS-native NFC, manual entry, or to ensure secure pairing with a PCI PTS SCRP, or non-PTS-approved MSR.
• Secure Entry and Processing of Account Data. Although not an optional Module, this includes optional Sections that provides security requirements for account data entry methods, such as COTS-native NFC, manual account data entry, or to ensure secure pairing with a PCI PTS SCRP, or non-PTS-approved MSR.
Modified
p. 47
• An understanding of EMV protocols and payment processing
• An understanding of EMV protocols and payment processing.
Modified
p. 47
• Skills and experience with mobile security and communications protocols
• Skills and experience with mobile security and communications protocols.
Modified
p. 47
• A clear history of penetration testing experience Results from annual penetration testing may not exist for newly developed MPoC Software products, but need to be provided for any review performed after the first year of validation. However, an initial penetration testing report is required to be available prior to the listing of the MPoC Software or the MPoC Solution (for monolithic solutions). Penetration testing may be performed by the same entity that performs the MPoC evaluation; however, the MPoC …
• A clear history of penetration testing experience. Results from annual penetration testing may not exist for newly developed MPoC Software products, but need to be provided for any review performed after the first year of validation. However, an initial penetration testing report is required to be available prior to the listing of the MPoC Software or the MPoC Solution (for monolithic solutions). Penetration testing may be performed by the same entity that performs the MPoC evaluation; however, the MPoC …
Modified
p. 48
1A-1.4.a Where an existing validation and listing of the MPoC Software A&M component to the PCI Software Security Standard exists, the tester must confirm through examination and observation that the assessment scope and listing are correct, complete, and current. The tester must cite the listing number and version from the PCI website listing.
1A-1.4.a Where an existing validation and listing of the MPoC Software A&M component to the PCI Secure Software Standard exists, the tester must confirm through examination and observation that the assessment scope and listing are correct, complete, and current. The tester must cite the listing number and version from the PCI website listing.
Modified
p. 48
1A-1.4.b Where an existing validation and listing of the MPoC Software A&M component to the PCI Software Security Standard does not exist, the tester must confirm through examination, testing, observation, and interview that all software developed by the entity meets the security test requirements outlined in the PCI Secure Software Standard, including applicable modules of that standard.
1A-1.4.b Where an existing validation and listing of the MPoC Software A&M component to the PCI Secure Software Standard does not exist, the tester must confirm through examination, testing, observation, and interview that the MPoC Software A&M component developed by the entity meets the security test requirements outlined in the PCI Secure Software Standard, including applicable modules of that standard.
Modified
p. 62
1A-4.2.a The tester must confirm through examination and observation that secret and private keys are imported or injected into the MPoC Software only in a way that protects their confidentiality and integrity.
1A-4.2.a The tester must confirm through examination and observation that secret and private keys are imported or injected into the MPoC Software only in a way that protects their confidentiality and integrity. 1A-4.2.b The tester must confirm through examination and observation that the confidentiality, integrity, and authenticity protections do not solely rely on the use of a secure channel. 1A-4.2.c The tester must confirm through examination and observation that keys used to encrypt other keys for transport are not also …
Modified
p. 72
• Components that have access to the assets in cleartext (or have enough information to recover it in cleartext (e.g., encrypted assets and encryption key).
• Components that have access to the assets in cleartext or have enough information to recover it in cleartext (e.g., encrypted assets and encryption key).
Modified
p. 74
1B-1.6.a The tester must confirm through examination, observation, and testing that code and data provisioned to the MPoC SDK after installation is transmitted, managed, and stored securely. Note: This requirement applies to data that is security sensitive (e.g., configuration files, webviews, keys, etc. as well as to all code that is executed by the MPoC SDK (that is not already part of the COTS Platform), and merchant identifiers used as part of the transaction process.
1B-1.6.a The tester must confirm through examination, observation, and testing that code and data provisioned to the MPoC SDK after installation is transmitted, managed, and stored securely. Note: This requirement applies to data that is security sensitive (e.g., configuration files, webviews, keys, etc. as well as to all code that is executed by the MPoC SDK (that is not already part of the COTS Platform)), and merchant identifiers used as part of the transaction process.
Modified
p. 86
• Provisioning (enrollment, provisioning)
• Provisioning (enrolment, provisioning)
Modified
p. 162
• Planned maintenance downtime
• Planned maintenance downtime.
Modified
p. 162
• Provisioned credentials
• Provisioned credentials.
Modified
p. 162
• Information about potential compromise/security incidents
• Information about potential compromise/security incidents.
Modified
p. 162
• End User License Agreement (EULA) It is important that the merchant receives relevant information in a timely manner, and this process cannot be performed ad hoc when issues arise. A merchant communication plan ensures that the processes for how and when to communicate to the merchant base are detailed, so all parties are aware of their obligations.
• End User License Agreement (EULA). It is important that the merchant receives relevant information in a timely manner, and this process cannot be performed ad hoc when issues arise. A merchant communication plan ensures that the processes for how and when to communicate to the merchant base are detailed, so all parties are aware of their obligations.