Document Comparison
Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v1-1.pdf
→
PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf
81% similar
20 → 22
Pages
6266 → 7187
Words
83
Content Changes
Content Changes
83 content changes. 21 administrative changes (dates, page numbers) hidden.
Added
p. 3
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 the 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.
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.
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 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.
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 …
Added
p. 4
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 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 DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
• September 2017 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 DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
Added
p. 6
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 card and SD card), the internal electronics used for testing by the manufacturer, embedded sensors (e.g., tilt or motion sensors, thermal sensors, pressure sensors, and light sensors), and biometric readers.
i. Account data entering the device,
ii. Account data residing in the device, and
iii. Account data leaving the device.
i. Account data entering the device,
ii. Account data residing in the device, and
iii. Account data leaving the device.
• September 2017 card and SD card), the internal electronics used for testing by the manufacturer, embedded sensors (e.g., tilt or motion sensors, thermal sensors, pressure sensors, and light sensors), and biometric readers.
i. Account data entering the device,
ii. Account data residing in the device, and
iii. Account data leaving the device.
i. Account data entering the device,
ii. Account data residing in the device, and
iii. Account data leaving the device.
Added
p. 10
Mobile payment-acceptance applications are vulnerable to numerous types of attacks meant to intercept data•such as, but not limited to: MITM or passive eavesdropping on a compromised device, poorly implemented cryptography, or eavesdropping through the cellular infrastructure (i.e., air interface, carrier)7.
Added
p. 11
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 4 Guidelines for the Risk and Controls in the Supporting Environment This section addresses security measures essential to the integrity of the mobile platform and associated application environment.
Disabling USB debugging and disallowing untrusted sources should be enforced on an ongoing basis. Use of application-hardening techniques may also help prevent unauthorized logical access to a device by making it more difficult for an attacker to modify or reverse engineer the software by reducing the attack surface.
Note: Biometrics is a maturing technology. For the particular biometric chosen, the developer must ensure the biometric has the appropriate strength and security controls for their particular payment- acceptance solution.
• September 2017 4 Guidelines for the Risk and Controls in the Supporting Environment This section addresses security measures essential to the integrity of the mobile platform and associated application environment.
Disabling USB debugging and disallowing untrusted sources should be enforced on an ongoing basis. Use of application-hardening techniques may also help prevent unauthorized logical access to a device by making it more difficult for an attacker to modify or reverse engineer the software by reducing the attack surface.
Note: Biometrics is a maturing technology. For the particular biometric chosen, the developer must ensure the biometric has the appropriate strength and security controls for their particular payment- acceptance solution.
Added
p. 12
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 4.3 Prevent escalation of privileges.
Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for activities that defeat operating- system security controls
•e.g., jailbreaking or rooting
•and, when detected, the device should be quarantined by a solution that removes it from the network, removes the payment-acceptance application from the device, or disables the payment application. Offline jailbreak and root detection and auto- quarantine are key since some attackers may attempt to put the device in an offline state to further circumvent detection. Hardening of the application is a method to that may help prevent escalation of privileges in a mobile device. Controls should include, but are not limited to:
Providing the capability for the device to produce an alarm or warning if there is an attempt to root …
• September 2017 4.3 Prevent escalation of privileges.
Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for activities that defeat operating- system security controls
•e.g., jailbreaking or rooting
•and, when detected, the device should be quarantined by a solution that removes it from the network, removes the payment-acceptance application from the device, or disables the payment application. Offline jailbreak and root detection and auto- quarantine are key since some attackers may attempt to put the device in an offline state to further circumvent detection. Hardening of the application is a method to that may help prevent escalation of privileges in a mobile device. Controls should include, but are not limited to:
Providing the capability for the device to produce an alarm or warning if there is an attempt to root …
Added
p. 13
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 4.8 Prefer online transactions.
Developers should be trained on PCI standards and secure-coding best practices. Training should cover prevention of common coding vulnerabilities in software development processes to include but not be limited to injection flaws, buffer overflow, insecure cryptographic storage, insecure communications, improper error handling, and improper access control•e.g., OWASP Top 10 Mobile Risks14.
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 may not be permissible to download apps from an online store whose security cannot be validated.
Solution providers should regularly update their payment application and ensure a process is in place to notify merchants when updates are available and safe to install. The solution provider should also provide documentation to merchants that details any update procedures for installation, as well as ensure a process is in place to notify merchants when newly discovered vulnerabilities in their payment-acceptance solution …
• September 2017 4.8 Prefer online transactions.
Developers should be trained on PCI standards and secure-coding best practices. Training should cover prevention of common coding vulnerabilities in software development processes to include but not be limited to injection flaws, buffer overflow, insecure cryptographic storage, insecure communications, improper error handling, and improper access control•e.g., OWASP Top 10 Mobile Risks14.
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 may not be permissible to download apps from an online store whose security cannot be validated.
Solution providers should regularly update their payment application and ensure a process is in place to notify merchants when updates are available and safe to install. The solution provider should also provide documentation to merchants that details any update procedures for installation, as well as ensure a process is in place to notify merchants when newly discovered vulnerabilities in their payment-acceptance solution …
Added
p. 15
Developers should provide an audit and logging mechanism for their payment-acceptance solution. The mechanisms are expected to log user and device access to be used by the merchant. The developer should document how logs would be made available to the merchant and how to access the log reports.
Term Definition Application (anti-tampering) Application hardening is a process of addressing application security weaknesses.
This may be done by implementing software patches and updates, using the latest versions of protocols, and following policies and procedures in order to minimize attack surfaces or down time.
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 Rooting.
Rich OS An environment created for versatility and …
Term Definition Application (anti-tampering) Application hardening is a process of addressing application security weaknesses.
This may be done by implementing software patches and updates, using the latest versions of protocols, and following policies and procedures in order to minimize attack surfaces or down time.
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 Rooting.
Rich OS An environment created for versatility and …
Added
p. 20
10. Harden the application. X X
19. Provide an indication of a secure state. X X X X
19. Provide an indication of a secure state. X X X X
Added
p. 21
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.
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.
Removed
p. 3
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 applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
Modified
p. 3
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. 3
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. 3
This document focuses on payment applications that operate on any consumer electronic handheld device (e.g., smartphone, tablet, or PDA) that is not solely dedicated 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 applications that operate on any consumer electronic handheld device (e.g., smartphone, tablet or wearable•or collectively, “mobile device”) that is not solely dedicated 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
Modified
p. 3 → 4
The purpose of this document is to raise awareness and to provide guidance to those in the best position to protect the trust needed for a payment application that executes within mobile devices: the solution developer. This document encourages development of secure payment-acceptance solutions including applications using secure coding practices, and encourages both monitoring for advancements that improve integrity and preparing for newly discovered threats. While not exhaustive, this document outlines a variety of both traditional and less conventional mechanisms …
The purpose of this document is to raise awareness and to provide guidance to those in the best position to protect the trust needed for a payment application that executes within mobile devices: the solution developers. This document encourages the development of secure payment-acceptance solutions including applications using secure coding practices, and encourages both monitoring for advancements that improve integrity and preparing for newly discovered threats. While not exhaustive, this document outlines a variety of both traditional and less conventional …
Modified
p. 4
• July 2014
Disclaimer Please consider carefully the limitations of this document. In particular:
Modified
p. 4
Due to its rapid evolution, payment brands may have differing approaches to mobile payment acceptance. The guidelines and recommendations expressed in this document may not by themselves be sufficient to meet the specific requirements of all payment brands or territories. For example, manual key entry on a merchant-owned consumer mobile device may be prohibited in some territories but permitted in others. For information and in the event of any doubt, please contact your acquirer and/or the relevant payment brands/territories.
Due to its rapid evolution, payment brands may have differing approaches to mobile payment acceptance. The guidelines and recommendations expressed in this document may not, by themselves, be sufficient to meet the specific requirements of all payment brands or territories. For example, manual key entry on a merchant-owned consumer mobile device may be prohibited in some territories but permitted in others. For information and in the event of any doubt, please contact your acquirer and/or the relevant payment brands/territories.
Removed
p. 5
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 methods of traditional desktop and laptop computers, mobile devices may also incorporate multiple cellular technologies (e.g., CDMA and GSM), GPS, Bluetooth, infrared (IR), and near-field communication (NFC) capabilities. Risk is further increased by removable media (e.g., SIM card and SD card), the internal electronics used for testing by the manufacturer, embedded sensors (e.g., tilt or motion sensors, thermal sensors, pressure sensors, and light sensors), and biometric readers. Furthermore, vendor and network operator-level logging and debugging configurations may introduce additional risks.
Modified
p. 5
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 1 Document Overview 1.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, wearables•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. Most of these devices do not meet security characteristics …
• September 2017 1 Document Overview 1.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, wearables•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. Most of these devices do not meet security characteristics …
Modified
p. 5
The purpose of this document is to educate stakeholders responsible for the architecture, design, and development of mobile apps and their associated environment within a mobile device that merchants might use for payment acceptance. Developers and manufacturers can use these guidelines to help them design appropriate security controls within their software and hardware products. These controls can then be applied to mobile payment-acceptance environments, thus supporting the deployment of more secure solutions.
The purpose of this document is to educate stakeholders responsible for the architecture, design, and development of mobile applications and their associated environment within a mobile device that merchants might use for payment acceptance. Developers and manufacturers can use these guidelines to help them design appropriate security controls within their software and hardware products. These controls can then be applied to mobile payment-acceptance environments, thus supporting the deployment of more secure solutions.
Modified
p. 5
Implementing such a solution would include the addition of a PCI-approved point-of-interaction (POI) device. With the use of a validated solution, account data is encrypted by the POI, and the mobile device simply acts as the conduit through which the encrypted payment transaction is transmitted.
Implementing such a solution would include the addition of a PCI-approved point-of-interaction (POI) device. With the use of a validated P2PE solution, account data is encrypted by the POI, and the mobile device simply acts as the conduit through which the encrypted payment transaction is transmitted.
Removed
p. 6
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Security risks are also inherent to the developmental life cycle and infrastructure associated with mobile devices. The original equipment manufacturer, the operating-system software developer, the application developer, the integrator, the reseller, the mobile-network operator (or cellular service provider), and the mobile payment-acceptance solution provider each play a part in the overall security of a mobile device.
• July 2014 Security risks are also inherent to the developmental life cycle and infrastructure associated with mobile devices. The original equipment manufacturer, the operating-system software developer, the application developer, the integrator, the reseller, the mobile-network operator (or cellular service provider), and the mobile payment-acceptance solution provider each play a part in the overall security of a mobile device.
Modified
p. 6
Some developers are involved in multiple stages of the development process, making it potentially easier for them to address more aspects of the device from the silicon layer to the applications running on the operating system; other stakeholders are involved in only one stage of security development. Other third parties may introduce security risks through device drivers, mobile apps, peripheral equipment, and removable media. All of these represent potential vectors for unauthorized access to device operations or unauthorized disclosure of …
Security risks are also inherent to the developmental life cycle and infrastructure associated with mobile devices. For example, the original equipment manufacturer, the operating-system software developer, the application developer, the integrator, the reseller, the mobile-network operator (or cellular service provider), and the mobile payment-acceptance solution provider each play a part in the overall security of a mobile device. (NOTE: This may not be a complete list.) Some developers are involved in multiple stages of the development process, making it potentially …
Modified
p. 7
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 2 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 for reducing security risks in otherwise noncompliant mobile devices. For mobile payment acceptance, the mobile device would be considered part of the CDE …
• September 2017 2 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 for reducing security risks in otherwise noncompliant mobile devices. For mobile payment acceptance, the mobile device would be considered part of the CDE …
Modified
p. 7
Section 3: 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.
Section 3: Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
Modified
p. 8
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 3. 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 Developers
• September 2017 3 Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
• September 2017 3 Objectives and Guidance for the Security of a Payment Transaction This section addresses the three main risks associated with mobile payment transactions:
Modified
p. 8
Ensure account data is appropriately encrypted prior to entry into mobile device. This can be accomplished via a validated PCI P2PE solution.1 Ensure a trusted path2 exists between the data-entry mechanism (e.g., manual key entry or entry via a card reader) and the mobile device such that account data cannot be intercepted by an unauthorized party. One option to accomplish this is using a trusted execution environment that restricts access between the mechanism receiving account data and secured memory located …
Ensure account data is appropriately encrypted prior to entry into a mobile device. This can be accomplished via a validated PCI P2PE solution.1 Ensure a trusted path2 exists between the data-entry mechanisms•e.g., manual key entry or entry via a card reader•and the mobile device such that account data cannot be intercepted by an unauthorized party. One option to accomplish this is using a trusted execution environment that restricts access between the mechanism receiving account data and secured memory located inside …
Modified
p. 8
If the external device is wireless (e.g., Wi-Fi or Bluetooth), the wireless communication channel should be secured via strong cryptography.3 Regardless of the process used, assure the account data entry channel is secured against client-side injections. Client-side injections include but are not limited to buffer overflows, data-type mismatches, embedded code or other unexpected data, and malicious or unauthorized apps and services on the mobile device.
If the external device is wireless •e.g., Wi-Fi or Bluetooth
•the wireless communication channel should be secured via strong cryptography.3 Regardless of the process used, assure the account-data-entry channel is secured against client- side injections. Client-side injections include but are not limited to buffer overflows, data-type mismatches, embedded code or other unexpected data, and malicious or unauthorized apps and services on the mobile device.
•the wireless communication channel should be secured via strong cryptography.3 Regardless of the process used, assure the account-data-entry channel is secured against client- side injections. Client-side injections include but are not limited to buffer overflows, data-type mismatches, embedded code or other unexpected data, and malicious or unauthorized apps and services on the mobile device.
Modified
p. 8
If the solution permits PIN entry, it should only occur through a PCI PTS-approved PIN entry device or a solution that has been approved by the payment brand(s).
Modified
p. 9
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
•
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
• September 2017 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
Modified
p. 9
Ensure that account data is only processed inside a trusted execution environment. In order to prevent data leakage, account data should not be accessible outside a trusted execution environment. A data- leakage prevention methodology should be adopted based on industry best practices and guidelines.
Ensure that account data is only processed inside a trusted execution environment4. A trusted execution environment may be accomplished through multiple technologies, and the level of security may vary accordingly. In order to prevent data leakage, account data should not be accessible outside a trusted execution environment. A data-leakage prevention methodology should be adopted based on industry best practices and guidelines. The methodology should include, but is not limited to:
Modified
p. 9
Secure distribution of account data Secure access to and storage of account data Controls over account data while in use (e.g., preventing copy/paste, screen shots, file sharing, and printing) Prevention of unintentional or side-channel data leakage4 Temporary storage of account data prior to processing and authorization should be in a secured storage environment, such as a secure element, to prevent third-party eavesdropping.
Secure distribution of account data Secure access to and storage of account data Controls over account data while in use (e.g., preventing copy/paste, screen shots, file sharing, and printing) Prevention of unintentional or side-channel data leakage5 Temporary storage of account data prior to processing and authorization should be in a secured storage environment, such as a secure element, to prevent third party eavesdropping.
Modified
p. 9
If account data is stored on the mobile device post-authorization, that data should be rendered unreadable per PCI DSS Requirement 3.4. If encrypted account data is stored, any related cryptographic keys need to be managed in accordance with PCI DSS Requirement 3.5 so keys are not accessible to unauthorized people, applications, and/or processes.
If account data is stored on the mobile device post-authorization, that data should be rendered unreadable per PCI DSS Requirement 3.4. If encrypted account data is stored, any related cryptographic keys must be managed in accordance with PCI DSS Requirement 3.5 so keys are not accessible to unauthorized people, applications, and/or processes.
Modified
p. 9
Per PCI DSS Requirement 3.2, do not retain sensitive authentication data (SAD)5 after authorization.
Per PCI DSS Requirement 3.2, do not retain sensitive authentication data (SAD)6 after authorization. This includes ensuring that neither the mobile device nor any attached device retains SAD after authorization.
Modified
p. 9 → 10
Objective 3: Prevent account data from interception upon transmission out of the mobile device.
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 Objective 3: Prevent account data from interception upon transmission out of the mobile device.
• September 2017 Objective 3: Prevent account data from interception upon transmission out of the mobile device.
Modified
p. 9 → 10
Ensure that account data is encrypted (i.e., using strong symmetric or asymmetric cryptography) per
Ensure that account data is encrypted •i.e., using strong symmetric or asymmetric cryptography
Modified
p. 9 → 10
PCI DSS Requirement 4, prior to transmission out of the trusted execution environment of the mobile device.
PCI DSS Requirement 4, prior to transmission out of the trusted execution environment of the mobile device. Ensure encrypted account data is transmitted from a trusted source.
Removed
p. 10
4. Guidelines for the Risk and Controls in the Supporting Environment This section addresses security measures essential to the integrity of the mobile platform and associated application environment.
Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for jail-breaking or rooting activity, and when detected the device should be quarantined by a solution that either removes it from the network or removes the payment acceptance application from the device. Also, some attackers may attempt to put the device in an offline state to further circumvent detection; so offline jailbreak and root detection and auto-quarantine are also key. Controls should include but are not limited to:
Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for jail-breaking or rooting activity, and when detected the device should be quarantined by a solution that either removes it from the network or removes the payment acceptance application from the device. Also, some attackers may attempt to put the device in an offline state to further circumvent detection; so offline jailbreak and root detection and auto-quarantine are also key. Controls should include but are not limited to:
Modified
p. 10 → 11
Protect mobile device from unauthorized logical access. Include design features that prevent unauthorized use. For example, include in the design one of the more secure lock screens: “Face Unlock,” “Password,” “Pattern,” or “PIN.” Do not rely on “Slide,” since it does not add security. Include a feature that would force the user to re-authenticate to the device after a specified amount of time. Bypassing of the lock screen may be prevented by enabling full disk encryption and/or disabling USB debugging. …
Protect mobile device from unauthorized logical access. Include design features that prevent unauthorized use. For example, include in the design one of the more secure lock screens: “Biometric8”, “Password,” “Pattern,” or “PIN.” Do not rely on “Slide,” since it does not add security. Include a feature that would force the user to re-authenticate to the device after a specified amount of time. Bypassing of the lock screen may be prevented by enabling full media encryption and/or disabling USB debugging.
Modified
p. 10 → 11
The mobile app developer should include the capability for the mobile app to determine whether USB debugging is disabled and whether full disk encryption is enabled. In addition, the operating-system developer should include controls that can prevent the user from enabling USB debugging or disabling full disk encryption.
The mobile app developer should include the capability for the mobile app to determine whether USB debugging is disabled and whether full media encryption is enabled. In addition, the operating-system developer should include controls that can prevent the user from enabling USB debugging or disabling full media encryption.
Modified
p. 10 → 11
Develop the overall payment-acceptance solution to include capabilities for preventing and reporting unauthorized access attempts, identifying and reporting abnormal activity, and discontinuing access (i.e., the payment-acceptance solution would prevent further access by the mobile payment-acceptance app on that device until an administrator restores access). Controls include, but are not limited to:
Develop the overall payment-acceptance solution to include capabilities for preventing and reporting unauthorized access attempts, identifying and reporting abnormal activity, and discontinuing access•i.e., the payment-acceptance solution would prevent further access by the mobile payment-acceptance app on that device until an administrator restores access. Controls include, but are not limited to:
Modified
p. 10 → 11
Support for authorized access (e.g., access control list) Ability to monitor events and to distinguish normal from abnormal events Ability to report events (e.g., via a log, message, or signal) including cryptographic key changes, escalation of privileges, invalid login attempts exceeding a threshold, updates to application software or firmware, and similar actions 4.3 Prevent escalation of privileges.
Support for authorized access•e.g., access control list Ability to monitor events and to distinguish normal from abnormal events Ability to report events •e.g., via a log, message, or signal
•including cryptographic key changes, escalation of privileges, invalid login attempts exceeding a threshold, updates to application software or firmware, and similar actions 8 See Appendix C for information on biometric standards and guidance.
•including cryptographic key changes, escalation of privileges, invalid login attempts exceeding a threshold, updates to application software or firmware, and similar actions 8 See Appendix C for information on biometric standards and guidance.
Removed
p. 11
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Providing the capability for the device to produce an alarm or warning if there is an attempt to root or jail-break the device; Providing the capability within the payment-acceptance solution for identifying authorized objects6 and designing controls to limit access to only those objects.
• July 2014 Providing the capability for the device to produce an alarm or warning if there is an attempt to root or jail-break the device; Providing the capability within the payment-acceptance solution for identifying authorized objects6 and designing controls to limit access to only those objects.
Modified
p. 11 → 12
The payment application should support a mechanism that permits it to be disabled by the merchant or solution provider responsible for the payment system application. The feature should not interfere with other, non-payment functions of the mobile device.
The payment application should support a mechanism that permits it to be disabled by the merchant or solution provider responsible for the payment-system application. The feature should not interfere with other, non-payment functions of the mobile device.
Modified
p. 11 → 13
Mobile payment-acceptance applications should conform to secure coding, engineering, and testing conventions, such as the requirements and testing procedures outlined in the Payment Application Data Security Standard (PA-DSS). Other examples include CERT Secure Coding Standards7, Institute for Security and Open Methodologies (ISECOM)'s Open Source Security Testing Methodology Manual (OSSTMM)8, or International Systems Security Engineering Association (ISSEA)'s Systems Security Engineering Capability Maturity Model (SSE-CMM
• ISO/IEC21827).9 Developers should be trained on PCI standards. Secure-coding best practices should cover prevention of 6 …
• ISO/IEC
Mobile payment-acceptance applications should conform to secure coding, engineering, and testing conventions, such as the requirements and testing procedures outlined in the Payment Application Data Security Standard (PA-DSS). Other examples include CERT Secure Coding Standards10, Institute for Security and Open Methodologies (ISECOM)'s Open Source Security Testing Methodology Manual (OSSTMM)11, or International Systems Security Engineering Association (ISSEA)'s Systems Security Engineering Capability Maturity Model (SSE-CMM
• ISO/IEC 21827) 12 and OWASP Projects.13 .
• ISO/IEC 21827) 12 and OWASP Projects.13 .
Removed
p. 12
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 common coding vulnerabilities in software development processes to include but not be limited to injection flaws, buffer overflow, insecure cryptographic storage, insecure communications, improper error handling, and improper access control.
• July 2014 common coding vulnerabilities in software development processes to include but not be limited to injection flaws, buffer overflow, insecure cryptographic storage, insecure communications, improper error handling, and improper access control.
Modified
p. 12 → 13
Provide a secure means for keeping mobile device software and all applications up-to-date through patch management and other means to prevent compromise of the mobile device due to vulnerable software.
Provide a secure means for keeping mobile device software and all applications up to date through patch management and other means to prevent compromise of the mobile device due to vulnerable software.
Modified
p. 12 → 13
Evaluate updates prior to implementing them.
Evaluating updates prior to implementing them.
Modified
p. 12 → 13
Ensure that updates are received from a trusted source.
Ensuring that updates are received from a trusted source.
Modified
p. 12 → 13
Apply updates in a timely manner.
Applying updates in a timely manner.
Modified
p. 12 → 13
All authorized mobile apps, drivers and other software that form part of the payment solution should have a mechanism that permits authentication of the source and integrity of the executable file. The system should prevent the loading and subsequent execution of applications that cannot be authenticated.
All authorized mobile apps, drivers, and other software that form part of the payment solution should have a mechanism that permits authentication of the source and integrity of the executable file. The system should prevent the loading and subsequent execution of applications that cannot be authenticated.
Modified
p. 12 → 14
Enhance current capabilities to protect mobile device from malware. Deploy anti-malware products on all systems including antivirus, antispyware, and software-authentication products to protect systems from current and evolving malicious software threats.
Enhance current capabilities to protect mobile devices from malware. Deploy anti-malware products on all systems including antivirus, antispyware, and software-authentication products to protect systems from current and evolving malicious software threats.
Modified
p. 12 → 14
If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM (Mobile Device Management) solutions that can monitor, evaluate, and remove malicious software and applications from the device. Furthermore, if possible, it is ideal to deploy both anti-malware and MDM solutions (mentioned above) to protect the device from malicious software and applications. As another example, consider application wrapping, which can be employed with an MDM solution to prevent and/or remove malicious software and applications.
If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM (Mobile Device Management) solutions that can monitor, evaluate, and remove malicious software and applications from the device. Furthermore, if possible, it is ideal to deploy both anti-malware and MDM solutions (mentioned above) to protect the device from malicious software and applications. As another example, consider application wrapping, which can be employed with an MDM solution to prevent and/or remove malicious software and applications. Application hardening may also …
Modified
p. 13 → 14
• July 2014
If an enry device (e.g., card reader) is attached to the mobile device•whether the connection is physical or wireless•it needs to identify itself uniquely to the mobile payment-acceptance app to ensure that the correct entry device is paired to the correct mobile device. Mutual authentication between the entry device and the mobile device provides the best integrity assurance for the path. When the entry device is attached, the mobile payment-acceptance app validates the account-data-entry device via a serial number or …
Modified
p. 13 → 15
Regardless of the method used for producing receipts (e.g., e-mail, SMS, or attached printer), the method should mask the PAN in support of applicable laws, regulations, and payment-card brand policies.
Regardless of the method used for producing receipts •e.g., e-mail, SMS, or attached printer) method should mask the PAN in support of applicable laws, regulations, and payment-card brand policies.
Modified
p. 13 → 15
A trusted execution environment (or equivalent) should include a mechanism for indicating to the mobile- device user that the payment-acceptance mobile app is executing in a secure state. This would be similar to the indication that an SSL session is active in a browser.
A trusted execution environment (or equivalent) must include a mechanism for indicating to the mobile- device user that the payment-acceptance mobile app is executing in a secure state. This would be similar to the indication that an SSL session is active in a browser.
Modified
p. 14 → 16
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 Developers
• September 2017 Appendix A: Glossary This glossary contains definitions of words and phrases that are specific to PCI Mobile Payment Acceptance Security Guidelines for Developers. 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 Developers. For all other definitions, please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
Modified
p. 14 → 16
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. 14 → 16
Clear text Intelligible data that has meaning and can be read or acted upon without the application of decryption.
Modified
p. 14 → 17
Entry Device A type of electronic device that interacts directly with and takes input from humans to facilitate mobile payment acceptance.
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 Term Definition Entry Device A type of electronic device that interacts directly with and takes input from humans to facilitate mobile payment acceptance.
• September 2017 Term Definition Entry Device A type of electronic device that interacts directly with and takes input from humans to facilitate mobile payment acceptance.
Removed
p. 15
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Term Definition 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. Also, see Rooting.
• July 2014 Term Definition 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. Also, see Rooting.
Modified
p. 15 → 17
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. 15 → 17
Rooting Gaining unauthorized administrative control of a computer system; also, see Jail break/jail-broken.
Rooting Gaining unauthorized administrative control of a computer system; also, see Jailbreak/jailbroken.
Modified
p. 15 → 18
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 Developers
• 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. 15 → 18
Side-channel leakage An implementation-specific form of information leakage, usually from a cryptographic implementation, in a manner not considered in the data flow model of the implementation. It is generally an exploitation of physical leakages, e.g., power consumption, acoustical vibrations, or electromagnetic radiation. This can facilitate the determination of the secret key and the reconstruction of plaintext data.
Side-channel leakage An implementation-specific form of information leakage, usually from a cryptographic implementation, in a manner not considered in the data flow model of the implementation. It is generally an exploitation of physical leakages•e.g., power consumption, acoustical vibrations, or electromagnetic radiation. This can facilitate the determination of the secret key and the reconstruction of plaintext data.
Removed
p. 16
ATM 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.
Modified
p. 16 → 18
• 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. 16 → 18
Trusted execution environment An execution environment that runs alongside but isolated from an operating system. A trusted execution environment has security capabilities and meets certain security-related requirements: It protects trusted execution environment assets from general software attacks, defines rigid safeguards as to data and functions that a program can access, and resists a set of defined threats. Multiple technologies can be used to implement a trusted execution environment, and the level of security achieved may vary accordingly.
Trusted execution environment An execution environment that runs alongside but isolated from an operating system. A trusted execution environment has security capabilities and meets certain security-related requirements. It:
Modified
p. 17 → 19
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 Developers
• 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:
Removed
p. 18
18. Provide an indication of a secure state. X X X 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.
Modified
p. 18 → 20
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Best Practice DM OD AD M SP
•
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 Best Practice DM OD AD M SP
• September 2017 Best Practice DM OD AD M SP
Modified
p. 18 → 20
11. Prefer online transactions. X X
Modified
p. 18 → 20
12. Conform to secure coding, engineering, and testing. X X X
Modified
p. 18 → 20
13. Protect against known vulnerabilities. X X X
Modified
p. 18 → 20
14. Protect the mobile device from unauthorized applications. X X X
Modified
p. 18 → 20
15. Protect the mobile device from malware. X X X X
Modified
p. 18 → 20
16. Protect the mobile device from unauthorized attachments. X X
Modified
p. 18 → 20
17. Create instructional materials for implementation and use. X X X X
Modified
p. 18 → 20
18. Support secure merchant receipts. X X X
Modified
p. 19 → 21
PCI Mobile Payment Acceptance Security Guidelines
•July 2014 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
•
PCI Mobile Payment Acceptance Security Guidelines for Developers
• September 2017 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
• September 2017 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
Modified
p. 19 → 21
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. 19 → 21
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,
Removed
p. 20
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.