This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "PCI DSS"
(Rewrote to make current with latest PCI security guidelines) |
|||
| Line 1: | Line 1: | ||
| − | + | PCI DSS - Mobile Security Recommendations | |
| − | + | == PCI Mobile Payment Acceptance Security Guidelines == | |
| − | + | The 2017 PCI Mobile Payment Acceptance Security Guidelines states, “Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors.” | |
| − | + | == Section 4.3 Prevent Escalation of Privileges == | |
| − | + | 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. 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 or jailbreak the device; | |
| − | + | *Providing the capability within the payment-acceptance solution for identifying authorized objects and designing controls to limit access to only those objects | |
| − | * [ | + | == Links == |
| − | * | + | *[https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf PCI Mobile Payment Acceptance Security Guidelines for Developers • September 2017] |
| − | * [ | + | * [https://www.preemptive.com/blog/article/980-an-app-hardening-use-case-filling-the-pci-prescription-for-preventing-privilege-escalation-in-mobile-apps/106-risk-management Blog on Preventing Privilege Escalation in Mobile Payment Apps (PCI Mobile Payment Acceptance Security Guidelines Section 4.3)] |
| + | * [http://www.PCISecurityStandards.org PCISecurityStandards.org Website] | ||
Latest revision as of 14:00, 21 June 2018
PCI DSS - Mobile Security Recommendations
PCI Mobile Payment Acceptance Security Guidelines
The 2017 PCI Mobile Payment Acceptance Security Guidelines states, “Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors.”
Section 4.3 Prevent Escalation of Privileges
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. 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 or jailbreak the device;
- Providing the capability within the payment-acceptance solution for identifying authorized objects and designing controls to limit access to only those objects
