Document Comparison
Mobile_Payment_Acceptance_Security_Guidelines_for_Merchants_v1-1.pdf
→
PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Merchants_v2_0.pdf
74% similar
29 → 31
Pages
8869 → 10275
Words
80
Content Changes
Content Changes
80 content changes. 10 administrative changes (dates, page numbers) hidden.
Added
p. 4
When individuals load their own primary account numbers (PAN) into their personal devices, however, they are not required to validate those devices to PCI standards. At the same time, when one of those personal devices is transformed into a point of sale (POS) for a merchant to accept account data, there is a responsibility to protect that information. Thus, PCI standards begin to apply when a mobile device is used for payment card acceptance and may be subject to PCI DSS compliance as dictated by the payment brands’ compliance programs.
PCI Payment Application Data Security Standard (PA-DSS) (Category 2)
• Payment application meets all of the following criteria:
i. Payment application is only provided as a complete solution “bundled” with a specific mobile device by the vendor;
ii. Underlying mobile device is purpose-built (by design or by constraint) with a single function of performing payment acceptance; and 1 “Solely dedicated” means that the …
PCI Payment Application Data Security Standard (PA-DSS) (Category 2)
• Payment application meets all of the following criteria:
i. Payment application is only provided as a complete solution “bundled” with a specific mobile device by the vendor;
ii. Underlying mobile device is purpose-built (by design or by constraint) with a single function of performing payment acceptance; and 1 “Solely dedicated” means that the …
Added
p. 5
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017
iii. Payment application, when installed on the “bundled” mobile device•as assessed by the Payment Application Qualified Security Assessor (PA-QSA) and explicitly documented in the payment application’s Report on Validation (ROV)•provides an environment that allows the merchant to meet and maintain PCI DSS compliance.
Accepting Mobile Payments with a Smartphone or Tablet (Category 3, Scenario 1)
• Payment application operates on any consumer electronic handheld device (e.g., smartphone, tablet, wearable-or collectively, “mobile devices”) that is not solely dedicated to payment acceptance for transaction processing. The scenario includes the use of an approved hardware accessory in conjunction with a validated P2PE solution.
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI …
• September 2017
iii. Payment application, when installed on the “bundled” mobile device•as assessed by the Payment Application Qualified Security Assessor (PA-QSA) and explicitly documented in the payment application’s Report on Validation (ROV)•provides an environment that allows the merchant to meet and maintain PCI DSS compliance.
Accepting Mobile Payments with a Smartphone or Tablet (Category 3, Scenario 1)
• Payment application operates on any consumer electronic handheld device (e.g., smartphone, tablet, wearable-or collectively, “mobile devices”) that is not solely dedicated to payment acceptance for transaction processing. The scenario includes the use of an approved hardware accessory in conjunction with a validated P2PE solution.
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI …
Added
p. 7
This document provides guidance and good practice only, and does not replace, dilute, or remove any merchant’s existing compliance requirements under PCI DSS. If you are in any doubt, please contact your acquirer.
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 1.2 Security Risks of Mobile Devices This document defines mobile devices as consumer electronic handheld devices (e.g., smart phones, tablets, wearables•or collectively, “mobile devices”) that are not solely dedicated to payment acceptance for transaction processing. These devices span a broad spectrum of features and functions ranging from cellular handsets that only support telephone functionality to “smart phones” and “tablets” that have a broader functionality.
Any risk that exists on a standard desktop or laptop computer may also exist on a mobile device. In addition, mobile devices may have a broader set of functionalities than standard desktop and laptop computers, resulting in more security vulnerabilities. Along with the standard communication …
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 1.2 Security Risks of Mobile Devices This document defines mobile devices as consumer electronic handheld devices (e.g., smart phones, tablets, wearables•or collectively, “mobile devices”) that are not solely dedicated to payment acceptance for transaction processing. These devices span a broad spectrum of features and functions ranging from cellular handsets that only support telephone functionality to “smart phones” and “tablets” that have a broader functionality.
Any risk that exists on a standard desktop or laptop computer may also exist on a mobile device. In addition, mobile devices may have a broader set of functionalities than standard desktop and laptop computers, resulting in more security vulnerabilities. Along with the standard communication …
Added
p. 15
Detecting unwarranted app privileges, Detecting apps that store clear-text passwords, Determining whether other apps have access to payment application data, and Detecting apps that are vulnerable to man-in-the-middle (MITM) attacks).
Added
p. 21
Payment- acceptance solution Includes all hardware, software and processes of the solution.
Rich OS (Operating System) An environment created for versatility where device applications•such as Android, Symbian OS, and Windows Phone, for example•are executed. It is open to third- party download after the device is manufactured.
Rich OS (Operating System) An environment created for versatility where device applications•such as Android, Symbian OS, and Windows Phone, for example•are executed. It is open to third- party download after the device is manufactured.
Added
p. 30
8. NIST Special Publication 800-57, Part 1 Rev. 4 , Recommendation For Key Management, January
2017. WWW.OWASP.ORG 11. "Biometric Standards Program And Resource Center". NIST, 2017, https://www.nist.gov/programs- projects/biometric-standards-program-and-resource-center.
12. ANSI X9.84-2010 (R2017) - Biometric Information Management And Security For The Financial Services Industry. American National Standards Institute, 2010.
13. European Union Agency for Network and Information Security. Smartphone Secure Development Guidelines. ENISA, 2016, p. all.
2017. WWW.OWASP.ORG 11. "Biometric Standards Program And Resource Center". NIST, 2017, https://www.nist.gov/programs- projects/biometric-standards-program-and-resource-center.
12. ANSI X9.84-2010 (R2017) - Biometric Information Management And Security For The Financial Services Industry. American National Standards Institute, 2010.
13. European Union Agency for Network and Information Security. Smartphone Secure Development Guidelines. ENISA, 2016, p. all.
Modified
p. 1
PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Modified
p. 4
PCI SSC to consider its approach to provide guidance to secure all implementations.
PCI SSC to consider its approach to developing and providing guidance to secure all implementations.
Modified
p. 4
The PCI Security Standards Council charter provides a forum for collaboration across the payment space to develop security standards and guidance for the protection of payment card data wherever it may be stored, processed, or transmitted•regardless of the form factor or channel used for payment. All this applies only when a merchant, service provider, or other entity accepts payment card data from their customers. In other words, when individuals load their own primary account numbers (PAN) into their own devices, …
The PCI Security Standards Council charter provides a forum for collaboration across the payment space to develop security standards and guidance for the protection of payment card data wherever it may be stored, processed, or transmitted•regardless of the form factor or channel used for payment. All this applies when a merchant, service provider, or other entity accepts payment card data from its customers.
Modified
p. 4
This document focuses on payment-acceptance applications that operate on any consumer electronic handheld device (e.g., smartphone, tablet, or PDA) that is not solely dedicated1 to payment-acceptance transaction processing and where the electronic handheld device has access to clear-text data. For ease of reference, this subcategory is referred to as “Category 3, Scenario 2.” Separate PCI standards and documentation available on the PCI SSC website deal with all other categories and scenarios:
This document focuses on payment-acceptance applications that operate on any consumer electronic handheld device (e.g., smartphone, tablet, wearable•or collectively, “mobile device”) that is not solely dedicated1 to payment-acceptance transaction processing, where the electronic handheld device has access to clear-text data, and the device is not PCI PTS eligible. For ease of reference, this subcategory is referred to as “Category 3, Scenario 2.” This scenario does not include the use of a validated P2PE solution. Separate PCI standards and documentation available …
Modified
p. 4
Mobile Payment-Acceptance Applications and PA-DSS FAQs PCI PTS POI Modular Security Requirements (Category 1) PCI Payment Application Data Security Standard (PA-DSS) (Category 2) Accepting Mobile Payments with a Smartphone or Tablet (Category 3, Scenario 1) In June 2011, PCI SSC agreed (see PA-DSS and Mobile Applications FAQs, 22 June 2011) that mobile payment-acceptance applications that qualify as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such …
Mobile Payment-Acceptance Applications and PA-DSS FAQs ) PCI PTS POI Modular Security Requirements (Category 1) • Payment application operates only on a PTS-approved mobile device.
Modified
p. 5 → 6
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Disclaimer Please consider carefully the limitations of this document. In particular:
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Disclaimer Please consider carefully the limitations of this document. In particular:
• September 2017 Disclaimer Please consider carefully the limitations of this document. In particular:
Removed
p. 6
1. Introduction 1.1. Why mobile is different The uniqueness of mobile devices introduces challenges in securing that environment. General-purpose mobile devices are often built with a goal of being easy to use by the consumer. These devices do not typically provide the same level of data security you would expect when using a payment card at a traditional retail store. Due to the design, almost any mobile application could access account data stored in or passing through the mobile device. This poses a challenge for merchants to demonstrate adherence to the PCI Data Security Standard.
Modified
p. 6 → 9
Users of those applications, such as a new merchant, may be unaware of their responsibilities for safely accepting payment cards. The more secure the solution is prior to entering the market, the less risk there is to the merchant accepting payments on mobile devices. Still, adopting new technology requires a good amount of awareness in order for these businesses and their employees to operate the applications and devices correctly.
Users of those applications, such as a new merchant, may be unaware of their responsibilities for safely accepting payment cards. The more secure the solution is prior to entering the market, the less risk there is to the merchant accepting payments on mobile devices. Still, adopting new technology requires a good amount of awareness for these businesses and their employees to operate the applications and devices correctly.
Modified
p. 7 → 10
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 1.3. Processes Several issues may arise when considering how to implement mobile acceptance processes. For example: If the reader fails, is there a manual key-entry process to accept payment card data securely? The business owner might use the mobile device both for accepting account data and for personal use; in which case, can the activities be segregated? What if the mobile device is owned by an individual and not the employer? This …
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 2.3 Processes Several issues may arise when considering how to implement mobile acceptance processes. For example: If the reader fails, is there a manual key-entry process to accept payment card data securely? The business owner might use the mobile device both for accepting account data and for personal use; in which case, can the activities be segregated? What if the mobile device is owned by an individual and not the …
• September 2017 2.3 Processes Several issues may arise when considering how to implement mobile acceptance processes. For example: If the reader fails, is there a manual key-entry process to accept payment card data securely? The business owner might use the mobile device both for accepting account data and for personal use; in which case, can the activities be segregated? What if the mobile device is owned by an individual and not the …
Removed
p. 8
2. Document Overview 2.1. Document Purpose and Scope The Payment Card Industry Security Standards Council (PCI SSC) recognizes that merchants may use consumer electronic handheld devices (e.g., smartphones, tablets, PDAs, or collectively, “mobile devices”) that are not solely dedicated to payment acceptance for transaction processing. For instance, a merchant might use an off-the-shelf mobile device for both personal use and payment acceptance. Many of these devices have yet to incorporate generally accepted information security standards.
Though not mandated by PCI SSC, guidelines and best practices documents are produced to help educate and create awareness of challenges faced by the payment industry. This document focuses on guidance for merchants that plan to accept payments with a mobile device. Where merchants’ mobile device hardware and software implementation cannot currently meet the guidelines documented herein, they may choose to implement a PCI-validated, Point-to-Point Encryption (PCI P2PE) solution. Implementing such a solution would include the …
Though not mandated by PCI SSC, guidelines and best practices documents are produced to help educate and create awareness of challenges faced by the payment industry. This document focuses on guidance for merchants that plan to accept payments with a mobile device. Where merchants’ mobile device hardware and software implementation cannot currently meet the guidelines documented herein, they may choose to implement a PCI-validated, Point-to-Point Encryption (PCI P2PE) solution. Implementing such a solution would include the …
Removed
p. 8
This document provides guidance and good practice only, and does not replace, dilute or remove any merchant’s existing compliance requirements under PCI-DSS. If you are in any doubt, please contact your acquirer.
2.2. Security Risks of Mobile Devices This document defines mobile devices as consumer electronic handheld devices (e.g., smart phones, tablets, or PDAs) that are not solely dedicated to payment acceptance for transaction processing. These devices span a broad spectrum of features and functions ranging from cellular handsets that only support The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 telephone functionality to “smart phones” and “tablets” that have a broader functionality.
Any risk that exists on a standard desktop or laptop computer may also exist on a mobile device. In addition, mobile devices may have …
2.2. Security Risks of Mobile Devices This document defines mobile devices as consumer electronic handheld devices (e.g., smart phones, tablets, or PDAs) that are not solely dedicated to payment acceptance for transaction processing. These devices span a broad spectrum of features and functions ranging from cellular handsets that only support The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 telephone functionality to “smart phones” and “tablets” that have a broader functionality.
Any risk that exists on a standard desktop or laptop computer may also exist on a mobile device. In addition, mobile devices may have …
Modified
p. 10 → 11
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 3 Mobile Payments Guidance Overview The cardholder data environment (CDE) is comprised of people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, including any connected system components. This document does not focus on a PCI-validated P2PE solution, but on providing guidance to reduce security risks in otherwise noncompliant mobile devices.
• September 2017 3 Mobile Payments Guidance Overview The cardholder data environment (CDE) is comprised of people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, including any connected system components. This document does not focus on a PCI-validated P2PE solution, but on providing guidance to reduce security risks in otherwise noncompliant mobile devices.
Modified
p. 10 → 11
This document organizes the mobile payment-acceptance security guidelines into the following three Section 4: Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions: account data entering the device, account data residing in the device, and account data leaving the device.
This document organizes the mobile payment-acceptance security guidelines into the following three Section 4: Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
Modified
p. 11 → 12
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 4. Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions: account data entering the device, account data residing in the device, and account data leaving the device. An objective with associated guidance is given to address each of the three risks.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 4 Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
• September 2017 4 Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
Modified
p. 11 → 12
If the solution incorporates PIN-entry capability, it should only occur through a PTS-approved PIN Entry Device, otherwise the merchant should contact its payment brand to ensure the solution has been approved for PIN entry. Additionally, when entering account data, the merchant should take measures to ensure that no one stationed nearby is “shoulder-surfing.” The merchant should verify that the mobile device accepting account data is authorized, by validating its hardware and electronic serial numbers. Additionally, the software, firmware, and application …
Modified
p. 11 → 12
If an external device, such as a secure card reader, is used for account data entry into the mobile device, the merchant should ensure that the mobile device it intends to use has been approved by the solution provider for connection with the external device. It is essential that you enable all proper security functions on the mobile device and, where necessary, apply all security updates and patches in accordance to solution provider documentation.
If an external device, such as a secure card reader, is used for account data entry into the mobile device, the merchant should ensure that the mobile device it intends to use has been approved by the solution provider for connection with the external device. It is essential that you enable all proper security functions on the mobile device and, where necessary, apply all security updates and patches in accordance with solution provider documentation.
Modified
p. 11 → 13
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 that it is implemented as a secure network per PCI DSS Requirement 4.
• September 2017 that it is implemented as a secure network per PCI DSS Requirement 4.
Modified
p. 12
The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Where data passes through a network under the merchant’s control (e.g., Wi-Fi or Bluetooth), ensure The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Modified
p. 12 → 13
• July 2014
Objective 3: Prevent account data from interception upon transmission out of the mobile device.
Modified
p. 12 → 13
Ensure that account data is never stored on a server connected to the Internet.
Ensure that clear-text account data is never stored on a server connected to the Internet.
Removed
p. 13
5.3.2. Deploy security software products on all mobile devices including antivirus, antispyware, and software authentication products to protect systems from current and evolving malicious 2 See PCI Mobile Payment Acceptance Security Guidelines for Developers for more information.
Modified
p. 13 → 14
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 5 Guidance for Securing the Mobile Device2 Where a merchant either owns or is otherwise responsible for a mobile device being used as part of a payment solution, it is the merchant’s responsibility to take steps to establish and maintain the security of that device. The measures described in this section should also be applied to any additional hardware components that form part of the mobile payment-acceptance solution (e.g., card …
• September 2017 5 Guidance for Securing the Mobile Device2 Where a merchant either owns or is otherwise responsible for a mobile device being used as part of a payment solution, it is the merchant’s responsibility to take steps to establish and maintain the security of that device. The measures described in this section should also be applied to any additional hardware components that form part of the mobile payment-acceptance solution (e.g., card …
Removed
p. 14
5.4. Ensure the mobile device is in a secure state 5.4.1. It is strongly recommended that mobile devices are scanned by security software (e.g., detecting unwarranted app privileges, detecting apps that store clear-text passwords, determining whether other apps have access to payment application data, and detecting apps that are vulnerable to man-in-the-middle (MITM) attacks) prior to the implementation of any payment solution, and regularly thereafter throughout the lifespan of the solution.
Modified
p. 14 → 15
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 software threats. All software should be installed from a trusted source.3 If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM solutions that can monitor, evaluate, and remove malicious software and applications from the device.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 5.3.2 Deploy security software products on all mobile devices including antivirus, antispyware, and software authentication products to protect systems from current and evolving malicious software threats. All software should be installed from a trusted source.3 If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM solutions that can monitor, evaluate, and remove malicious software and applications from the device.
• September 2017 5.3.2 Deploy security software products on all mobile devices including antivirus, antispyware, and software authentication products to protect systems from current and evolving malicious software threats. All software should be installed from a trusted source.3 If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM solutions that can monitor, evaluate, and remove malicious software and applications from the device.
Modified
p. 14 → 15
The solution provider should be in communication with the merchant and make them aware of newly discovered vulnerabilities. Additionally, the solution provider should provide guidance to merchants when new vulnerabilities are discovered, as well as provide tested patches for any of these vulnerabilities.
The solution provider should be in communication with the merchant and make them aware of newly discovered vulnerabilities in their payment-acceptance solution.
Modified
p. 14 → 16
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 5.4.2 The merchant should look for an indication of a secure state (e.g., by a displayed icon) as detailed by the solution provider. If no indication is present, the payment application should not be used.
• September 2017 5.4.2 The merchant should look for an indication of a secure state (e.g., by a displayed icon) as detailed by the solution provider. If no indication is present, the payment application should not be used.
Removed
p. 15
5.4.4. Merchants should consider only using new mobile devices received in a factory state4 configuration as part of a payment solution, and recognize that mobile devices whose history and provenance are unclear should be avoided.
Modified
p. 15 → 16
Serial number (hardware and electronic should match) Model number Operating system, firmware, and payment-acceptance application versions The merchant implementing some form of log that lists who is using the device, when and where it is used 5.6.2. To help identify devices and control inventory, the merchant should mark each device with a unique identifier. For instance, mark the device with a ultra-violet (UV) security pen or an embedded RFI tag.
Serial number (hardware and electronic should match) Model number Operating system, firmware, and payment-acceptance application versions The merchant implementing some form of log that lists who is using the device, when, and where it is used 5.6.2 To help identify devices and control inventory, the merchant should mark each device with a unique identifier. For instance, mark the device with a ultra-violet (UV) security pen or an 4 “Factory state” is the device state when received …
Modified
p. 15 → 17
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 state to further circumvent detection, so offline jailbreak and root detection and auto-quarantine are also key.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 embedded RFI tag.
• September 2017 embedded RFI tag.
Modified
p. 16 → 17
• July 2014
If possible, develop a contract with an authorized vendor who can help securely dispose of electronic materials and components.
Modified
p. 17 → 18
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 6 Guidance for Securing the Payment-Acceptance Solution A mobile payment-acceptance solution consists of software and/or hardware components, which reside on or interface with a mobile device. For example, a solution might consist of a payment application and card- reader device that a merchant must install and set up to accept payments. These components must be protected using measures applied in addition to any that are undertaken to secure the mobile …
• September 2017 6 Guidance for Securing the Payment-Acceptance Solution A mobile payment-acceptance solution consists of software and/or hardware components, which reside on or interface with a mobile device. For example, a solution might consist of a payment application and card- reader device that a merchant must install and set up to accept payments. These components must be protected using measures applied in addition to any that are undertaken to secure the mobile …
Modified
p. 17 → 19
PCI Mobile Payment Acceptance Security Guidelines
•July 2014
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 support detection of abnormal activities.
• September 2017 support detection of abnormal activities.
Removed
p. 18
6.5.2. Ensure that any audit or logging capability is enabled. Additionally, regularly inspect system logs and reports for abnormal activity. If abnormal activity is suspected or discovered, discontinue access to the mobile device and its payment application until the issue has been resolved. Abnormal activities include, but are not limited to, unauthorized access attempts, escalated privileges, and unauthorized updates to software or firmware.
Removed
p. 19
An EPP has a clearly defined physical and logical boundary, and a tamper- resistant or tamper-evident shell. Encrypting PIN pads require integration into UPTs or ATMs.
Modified
p. 19 → 20
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix A: Glossary This glossary contains definitions of words and phrases that are specific to PCI Mobile Payment Acceptance Security Guidelines. For all other definitions please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Appendix A: Glossary This glossary contains definitions of words and phrases that are specific to PCI Mobile Payment Acceptance Security Guidelines. For all other definitions, please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
• September 2017 Appendix A: Glossary This glossary contains definitions of words and phrases that are specific to PCI Mobile Payment Acceptance Security Guidelines. For all other definitions, please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
Modified
p. 19 → 20
Term Definition Application Application wrapping typically involves the addition of a dynamic library to the existing application binary. This library can provide additional controls for certain aspects of the application (e.g., required user authentication, forced use of a VPN or prohibit cut and paste).
Term Definition Application Application wrapping typically involves the addition of a dynamic library to the existing application binary. This library can provide additional controls for certain aspects of the application•e.g., required user authentication, forced use of a VPN, or prohibit cut and paste.
Modified
p. 19 → 20
Clear text Intelligible data that has meaning and can be read or acted upon without the application of decryption.
Modified
p. 19 → 20
Encrypting PIN pad (EPP) A device for secure PIN entry and encryption in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller.
Encrypting PIN pad (EPP) A device for secure PIN entry and encryption in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary, …
Modified
p. 19 → 20
GPS (Global A satellite communication system that provides location and time information.
GPS (Global Positioning System) A satellite communication system that provides location and time information.
Modified
p. 20 → 21
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Term Definition Positioning System) Host-based This refers to the computer at the solution provider; i.e., not the mobile device Jail break/jail broken The rendering of a cell phone such that it is no longer subject to the limitations originally imposed on it by its manufacturers/proprietors. Jail-broken mobile devices allow access to their proprietary operating system, which then allows the installation of third-party applications not released or controlled by the manufacturer or proprietor. …
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Term Definition Host-based This refers to the computer at the solution provider•i.e., not the mobile device Jailbreak/ jailbroken The rendering of a cell phone such that it is no longer subject to the limitations originally imposed on it by its manufacturers/proprietors. Jailbroken mobile devices allow access to their proprietary operating system, which then allows the installation of third-party applications not released or controlled by the manufacturer or proprietor. Also, see …
• September 2017 Term Definition Host-based This refers to the computer at the solution provider•i.e., not the mobile device Jailbreak/ jailbroken The rendering of a cell phone such that it is no longer subject to the limitations originally imposed on it by its manufacturers/proprietors. Jailbroken mobile devices allow access to their proprietary operating system, which then allows the installation of third-party applications not released or controlled by the manufacturer or proprietor. Also, see …
Modified
p. 20 → 21
Mobile device A consumer electronic handheld device (e.g., smartphone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing and that has wireless connectivity to a network (e.g., cellular or Wi-Fi).
Mobile device A consumer electronic handheld device (e.g., smartphone, tablet, or wearable) that is not solely dedicated to payment acceptance for transaction processing and that has wireless connectivity to a network (e.g., cellular or Wi-Fi).
Modified
p. 20 → 21
Payment- acceptance application Refers to only the application on the device and/or the host computer as applicable by context.
Modified
p. 20 → 21
Rooting Gaining unauthorized administrative control of a computer system; also, see Jailbreak/jailbroken.
Modified
p. 20 → 22
Sensitive authentication data (SAD) Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Term Definition Sensitive authentication data (SAD) Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
• September 2017 Term Definition Sensitive authentication data (SAD) Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
Modified
p. 21 → 22
• July 2014 Term Definition
Subscriber identity module (SIM) A memory card that typically stores the IMSI (International Mobile Subscriber Identity) and other related information used to authenticate subscribers.
Modified
p. 21 → 22
Automated fuel dispenser Ticketing machine Vending machine The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Automated fuel dispenser Ticketing machine Vending machine The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Modified
p. 22 → 23
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix B: Best Practices and Responsibilities The table below outlines each best practice described within this document along with who should be responsible for its implementation. The definitions of those entities that are responsible for the best practices include:
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Appendix B: Best Practices and Responsibilities The table below outlines each best practice described within this document along with who should be responsible for its implementation. The definitions of those entities that are responsible for the best practices include:
• September 2017 Appendix B: Best Practices and Responsibilities The table below outlines each best practice described within this document along with who should be responsible for its implementation. The definitions of those entities that are responsible for the best practices include:
Modified
p. 22 → 23
12. Prefer online transactions. X The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
12. Prefer online transactions. X The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Modified
p. 23 → 24
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Best Practice M SP
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Best Practice M SP
• September 2017 Best Practice M SP
Modified
p. 23 → 24
16. Issue secure receipts. X The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
16. Issue secure receipts. X The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Modified
p. 24 → 25
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix C: Solution Provider Selection Criteria The following checklist is provided to assist the merchant in selecting a solution provider for mobile payment acceptance. The ideal candidate would meet all applicable criteria; however, the criteria are provided to facilitate a discussion between merchant and solution provider and between merchant and the merchant’s sponsoring financial institution or acquirer. It is not intended as qualification or disqualification of a solution provider.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Appendix C: Solution Provider Selection Criteria The following checklist is provided to assist the merchant in selecting a solution provider for mobile payment acceptance. The ideal candidate would meet all applicable criteria; however, the criteria are provided to facilitate a discussion between merchant and solution provider and between the merchant and the merchant’s sponsoring financial institution or acquirer. It is not intended as qualification or disqualification of a solution provider.
• September 2017 Appendix C: Solution Provider Selection Criteria The following checklist is provided to assist the merchant in selecting a solution provider for mobile payment acceptance. The ideal candidate would meet all applicable criteria; however, the criteria are provided to facilitate a discussion between merchant and solution provider and between the merchant and the merchant’s sponsoring financial institution or acquirer. It is not intended as qualification or disqualification of a solution provider.
Modified
p. 24 → 25
2. If the solution provider is providing the mobile device, then maintenance and support are provided.
2. If the solution provider is providing the mobile device, maintenance and support are provided.
Removed
p. 25
D.2. Regional Jurisdiction Rules and regulations pertaining to communications and forms of payment vary by jurisdiction.
Modified
p. 25 → 26
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix D: Additional Risks Associated with Mobile Devices The number of possible attack vectors targeting mobile payment transactions will continue to increase and there will be risks associated with them. Secure payments that are made today may not be secure in the future for reasons that are not yet known or covered. Therefore, it is important to include some of the possible residual risks concerning device validation, jurisdictional differences, and technological limitations …
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Appendix D: Additional Risks Associated with Mobile Devices The number of possible attack vectors targeting mobile payment transactions will continue to increase and there will be risks associated with them. Secure payments that are made today may not be secure in the future for reasons that are not yet known or covered. Therefore, it is important to include some of the possible residual risks concerning device validation, jurisdictional differences, and …
• September 2017 Appendix D: Additional Risks Associated with Mobile Devices The number of possible attack vectors targeting mobile payment transactions will continue to increase and there will be risks associated with them. Secure payments that are made today may not be secure in the future for reasons that are not yet known or covered. Therefore, it is important to include some of the possible residual risks concerning device validation, jurisdictional differences, and …
Modified
p. 25 → 26
D.1 Device Validation Numerous manufacturers, carriers, software developers, and vendors take part in developing a single mobile device. The various combinations of these entities result in an extremely large number of unique mobile devices. The resulting lack of vertical integration would make a program to validate compliance to requirements difficult.
Modified
p. 25 → 26
Preventative measures implemented in one jurisdiction may be unlawful to implement in another. For instance, remotely zeroizing a device (i.e., rendering it inoperative) may be legal in the US but not in the EU, since it may be unlawful to zeroize or otherwise do anything to a mobile device that would remove the user’s ability to make emergency calls. Adjustments made to accommodate jurisdictional legal issues may adversely affect security. This is likely to remain an intractable residual risk.
D.2 Regional Jurisdiction Rules and regulations pertaining to communications and forms of payment vary by jurisdiction. Preventative measures implemented in one jurisdiction may be unlawful to implement in another. For instance, remotely zeroizing a device (i.e., rendering it inoperative) may be legal in the US but not in the EU, since it may be unlawful to zeroize or otherwise do anything to a mobile device that would remove the user’s ability to make emergency calls. Adjustments made to accommodate jurisdictional …
Modified
p. 25 → 27
D.3. Technological Limitations D.3.1. Physical A mobile device may be shielded in such a way that it may not have the capability of being zeroized remotely (e.g., a Faraday cage). For instance, today mobile phones are being stolen and immediately put into metallic bags that shield them from sending/receiving commands, thereby removing the ability to zeroize the device remotely before the device can be used to divulge sensitive information. This type of attack could also remove the ability to “track” …
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 D.3. Technological Limitations D.3.1 Physical A mobile device may be shielded in such a way that it may not have the capability of being zeroized remotely (e.g., a Faraday cage). For instance, today mobile phones are being stolen and immediately put into metallic bags that shield them from sending/receiving commands, thereby removing the ability to zeroize the device remotely before the device can be used to divulge sensitive information.
• September 2017 D.3. Technological Limitations D.3.1 Physical A mobile device may be shielded in such a way that it may not have the capability of being zeroized remotely (e.g., a Faraday cage). For instance, today mobile phones are being stolen and immediately put into metallic bags that shield them from sending/receiving commands, thereby removing the ability to zeroize the device remotely before the device can be used to divulge sensitive information.
Removed
p. 26
D.4.3. Intentionally Inserted Backdoors At each step in the process of producing a mobile device, the potential exists for a renegade employee to introduce exploitable security vulnerabilities. Currently, no commercial vendors perform the level of hardware or software review necessary to assure detection of this kind of sabotage.
Modified
p. 26 → 27
• July 2014 D.3.2.
D.3.2 Data Accessibility Even with USB debugging disabled, other ways exist in which sensitive data can be accessed on a mobile device. Depending on the device, sensitive data may be accessible through the UART port, audio ports (e.g., headset connection and/or microphone), HDMI ports, IR ports, hardware test points (e.g., JTAG), or through various (non-native) phone states accessed by key sequences or combinations.
Modified
p. 26 → 27
These resets can be referred to as public or private resets. Public resets are generally available to the user and can be accessed through the device’s user interface. Private resets are generally not available to the user and require a key sequence, a passcode, or the device to be in a non-native state. Both public and private resets are usually not harmful to a device’s security features, although many of these resets delete large amounts of data and access different …
These resets can be referred to as public or private resets. Public resets are generally available to the user and can be accessed through the device’s user interface. Private resets are generally not available to the user and require a key sequence, a passcode, or the device to be in a non-native state. Both public and private resets are usually not harmful to a device’s security features, although many of these resets delete large amounts of data and access different …
Modified
p. 26 → 27
D.4. Indeterminable Risks D.4.1. Evolution of Technology and Unforeseen Attack Vectors In order to bypass security mechanisms such as a secure element or various biometric mechanisms, a person or organization might require very expensive and technologically advanced equipment.
D.4. Indeterminable Risks D.4.1 Evolution of Technology and Unforeseen Attack Vectors In order to bypass security mechanisms such as a secure element or various biometric mechanisms, a person or organization might require very expensive and technologically advanced equipment.
Modified
p. 26 → 28
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 D.4.2 Vulnerabilities Markets There are criminal enterprises today devoted to finding vulnerabilities within devices and selling information. Individuals and organizations stand ready to buy the vulnerabilities with the intent of keeping them secret so they can exploit them when they choose. Until made public, these are “zero- day” exploits and, as such, are a residual security risk.
• September 2017 D.4.2 Vulnerabilities Markets There are criminal enterprises today devoted to finding vulnerabilities within devices and selling information. Individuals and organizations stand ready to buy the vulnerabilities with the intent of keeping them secret so they can exploit them when they choose. Until made public, these are “zero- day” exploits and, as such, are a residual security risk.
Modified
p. 27 → 28
• July 2014
Additionally, the level of employee screening feasible in these commercial enterprises is unlikely to prevent this insider threat. As a result, there is no realistic way of preventing these “zero-day” exploits. Exploitation by the employee or sale by the employee in the aforementioned vulnerability marketplace is a residual security risk.
Modified
p. 27 → 28
D.5. Miscellaneous Risks D.5.1. Network Connections The mobile device will likely be connected to various different networks using a variety of open protocols. Additionally, it cannot be assumed that the mobile device will operate within a network that is controlled by a securely implemented firewall.
D.5. Miscellaneous Risks D.5.1 Network Connections The mobile device will likely be connected to various networks using a variety of open protocols.
Modified
p. 27 → 28
D.4.3 Intentionally Inserted Backdoors At each step in the process of producing a mobile device, the potential exists for a renegade employee to introduce exploitable security vulnerabilities. Currently, no commercial vendors perform the level of hardware or software review necessary to assure detection of this kind of sabotage. Additionally, it cannot be assumed that the mobile device will operate within a network that is controlled by a securely implemented firewall. D.5.2 Memory Management Mobile devices are developed for the ease …
Modified
p. 27 → 28
D.5.3 Anti-malware Current anti-malware products would be impractical to employ because of the tremendous amounts of resources required to run them (e.g., battery life significantly decreased). Additionally, such products would have no assurance that they could complete their testing before being terminated by the OS to release resources for other tasks.
Modified
p. 27 → 29
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 D.5.4 Variation of Devices Today, mobile devices are ubiquitous and the number of different platforms and variations in platforms is enormous. Each of these platforms seems to have new vulnerabilities being discovered constantly. The task of tracking and testing for all these vulnerabilities would be daunting and currently impractical.
• September 2017 D.5.4 Variation of Devices Today, mobile devices are ubiquitous and the number of different platforms and variations in platforms is enormous. Each of these platforms seems to have new vulnerabilities being discovered constantly. The task of tracking and testing for all these vulnerabilities would be daunting and currently impractical.
Modified
p. 27 → 29
D.5.5 Access Control Mobile devices generally do not have secure, role-based access control mechanisms that may be needed to support multiple users. This would include access controls to the device and to the application data.
Modified
p. 28 → 30
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix E: Industry Documents and External References Following are the sources of reference for this document.
•
PCI Mobile Payment Acceptance Security Guidelines for Merchants
• September 2017 Appendix E: Industry Documents and External References Following are the sources of reference for this document.
• September 2017 Appendix E: Industry Documents and External References Following are the sources of reference for this document.
Modified
p. 28 → 30
1. ANSI X9.112-2009, Wireless Management and Security
• Part 1: General Requirements.
• Part 1: General Requirements.
1. ANSI X9.112-2016, Wireless Management and Security
• Part 1: General Requirements.
• Part 1: General Requirements.
Modified
p. 28 → 30
2016. Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology. Gaithersburg, MD.
Modified
p. 28 → 30
10. OWASP Top 10 Mobile Risks. OWASP Mobile Security Project, The OWASP Foundation. May 2, 2014.
10. OWASP Top 10 Mobile Risks. OWASP Mobile Security Project, The OWASP Foundation. February 13,
Modified
p. 28 → 31
The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard. The intent of this document is to provide security risk-reduction recommendations. Information provided here does not augment, replace or supersede requirements in the PCI Data Security Standard.
Removed
p. 29
The PCI Security Standards Council was formed by the major payment card brands American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. to provide a transparent forum in which all stakeholders can provide input into the ongoing development, enhancement, and dissemination of the PCI Data Security Standard (DSS), PIN Transaction Security (PTS) Requirements, and the Payment Application Data Security Standard (PA-DSS). Merchants, banks, processors, and point-of-sale vendors are encouraged to join as Participating Organizations.