Document Comparison
Mobile_Payment_Security_Guidelines_Developers_v1.pdf
→
Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v1-1.pdf
91% similar
20 → 20
Pages
6051 → 6266
Words
31
Content Changes
Content Changes
31 content changes. 6 administrative changes (dates, page numbers) hidden.
Added
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.
Added
p. 10
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:
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.
If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM (Mobile Device Management) solutions that can monitor, evaluate, and …
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.
If anti-malware software is not available, employ MAM (Mobile Application Management) or MDM (Mobile Device Management) solutions that can monitor, evaluate, and …
Added
p. 19
10. OWASP Top 10 Mobile Risks. OWASP Mobile Security Project, The OWASP Foundation. May 2, 2014.
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 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, …
Removed
p. 4
PCI Mobile Payment Acceptance Security Guidelines
• September 2012 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 to isolate account data and protect it from exposure.
• September 2012 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 to isolate account data and protect it from exposure.
Modified
p. 4
Disclaimer Please consider carefully the limitations of this document. In particular:
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Disclaimer Please consider carefully the limitations of this document. In particular:
• July 2014 Disclaimer Please consider carefully the limitations of this document. In particular:
Modified
p. 6
• September 2012 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.
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 …
Modified
p. 9
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
•
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
• July 2014 Objective 2: Prevent account data from compromise while processed or stored within the mobile device.
Modified
p. 9
Per PCI DSS Requirement 3.2, do not retain sensitive authentication data (SAD)5 after authorization. This includes ensuring that neither the mobile device nor any attached device retains SAD after authorization.
Per PCI DSS Requirement 3.2, do not retain sensitive authentication data (SAD)5 after authorization.
Modified
p. 10
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: “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. …
Modified
p. 10
Controls should exist to prevent the escalation of privileges on the device (e.g., root or group privileges). Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Controls should include but are not limited to:
Controls should exist to prevent the escalation of privileges on the device (e.g., root or group privileges).
Modified
p. 10 → 11
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. 11
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 Providing the capability within the payment-acceptance solution for identifying authorized objects6 and designing controls to limit access to only those objects.
•
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
Supporting systems that either provide management for mobile devices or receive payment card data should be hardened to prevent unintended access or exposure of a mobile payment transaction. Therefore, any system used to support the mobile payment-acceptance solution should be compliant with PCI DSS.
Supporting systems that either provide management for mobile devices or receive payment card data should be hardened to prevent unintended access or exposure of a mobile payment transaction.
Modified
p. 11
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/IEC 21827).9 Developers should be trained on PCI standards. Secure-coding best practices should cover prevention ofcommon …
• ISO/IEC 21827).9 Developers should be trained on PCI standards. Secure-coding best practices should cover prevention of
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/IEC 21827).9 Developers should be trained on PCI standards. Secure-coding best practices should cover prevention of 6 …
• ISO/IEC 21827).9 Developers should be trained on PCI standards. Secure-coding best practices should cover prevention of 6 …
Removed
p. 12
If an entry device is attached to the mobile device (e.g., card reader)
•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 serial number or other unique identifier.
•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 serial number or other unique identifier.
Modified
p. 12
• September 2012
Developers should also document their implementation and create a formal response plan to identify and mitigate new risk. Developers should establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities and to test their applications for vulnerabilities. Any underlying software or systems that are provided with or required by the application should be included in this process.
Modified
p. 12
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. Controls should include but are not limited to:
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
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. Developers should ensure that a process exists for the secure distribution of their software such that an end user can determine that the software came from a trusted source before installing it. For instance, …
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. 13
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. Insecure channels such as e-mail and SMS should not be used to send PAN or SAD.
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.
Modified
p. 14
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 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 Glossary.
•
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.
• 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.
Modified
p. 14
Bluetooth Wireless protocol using short-range communications technology to facilitate transmission of data over short distances.
Modified
p. 15
• September 2012 Term Definition
Malicious software/malware Software designed to infiltrate or damage a computer system without the owner’s knowledge or consent. Examples include viruses, worms, Trojans (or Trojan horses), spyware, adware, and rootkits.
Modified
p. 15 → 16
Subscriber identity module (SIM) A memory card that typically stores the IMSI (International Mobile Subscriber Identity) and other related information used to authenticate subscribers.
PCI Mobile Payment Acceptance Security Guidelines
• 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.
• 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.
Removed
p. 16
PCI Mobile Payment Acceptance Security Guidelines
• September 2012 Term Definition 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.
• September 2012 Term Definition 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.
Modified
p. 17
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 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
• 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:
• 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:
Modified
p. 18
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 Best Practice DM OD AD M SP
•
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Best Practice DM OD AD M SP
• July 2014 Best Practice DM OD AD M SP
Removed
p. 19
5. NIST Special Publication 800-124, Guidelines on Cell Phone and PDA Security, October 2008.
Modified
p. 19
PCI Mobile Payment Acceptance Security Guidelines
•September 2012 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
•
PCI Mobile Payment Acceptance Security Guidelines
• July 2014 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
• July 2014 Appendix C: Industry Documents and External References Following are the sources of reference for this document.
Modified
p. 19
Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology. Gaithersburg, MD.
5. NIST Special Publication 800-124, Guidelines for Managing the Security of Mobile Devices in the Enterprise, June 2013. Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology. Gaithersburg, MD.
Modified
p. 19
WWW.OWASP.ORG 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.