PCI Compliance Updates PCI Mobile Payment Acceptance Security Guidelines Adam Goslin, Chief Operations Officer AGoslin@HighBitSecurity.com Direct: 248.388.4328
PCI Guidance February, 2013 - PCI Mobile Payment Acceptance Security Guidelines https://www.pcisecuritystandards.org/documents/mobile_payment_security_guidelines_m erchants_v1.pdf PCI SSC is not accepting mobile applications for PA-DSS compliance, and the guide intended for merchants implementing secure mobile payment-acceptance solutions DISCLAIMER: No presumption should be made that meeting the guidelines and recommendations expressed in this document would cause a solution to be compliant with PCI DSS. Entities wishing to use such solutions would need to make their own risk assessments around the use of such solutions in consultation with their acquirers and applicable payment brands. Such solutions would be included in an entity s annual PCI DSS assessment to ensure that the application and its operating environment are compliant with all applicable PCI DSS requirements. Qualified Security Assessor input
Mobile Challenges Consumer devices not held to same security standard Consumer mobile device applications could access stored / in transit card data Across manufacturers of devices, developers of operating systems, application designers, network carriers, and the use of various protocols to connect these different entities Mobile application developers typically different personnel than web platforms, reducing both awareness and secure coding capabilities Reality of mobile security: 2012 = 163% increase in mobile malware; 95% Android Estimates that almost 1/3 of all android devices infected
Mobile Challenges, Cont. Secure card data processes performed on same device as consumer applications running Segregation of consumer from secure activities? Malware on the devices Fraud monitoring? Mobile application developers encouraged to monitor new developments on mobile platform, and continually evaluate improvements this is a FAST moving segment
Documentation Scenarios There are two scenarios covered: In the first scenario, the solution provider is responsible for the mobile app and for all the back-end processes. Additionally, the solution provider is the device owner and has provided the devices to a merchant. In the second scenario, the solution provider is responsible for the mobile app, the back-end processes, and the merchant is the device owner. NOT covered: BYOD not included as it does not afford the merchant the control required to ensure security IMPORTANT NOTE: this includes the vast majority of mobile payment platforms and solutions READ: this is a risk the company takes on themselves
Security Risks of Mobile Any risk on a server / workstation solution may exist on a mobile platform as well Mobile devices have more communication protocols (cellular, Bluetooth, infrared(ir), near-field communication(nfc)) Removable media SIM / SD Embedded sensors (e.g., tilt or motion sensors, thermal sensors, pressure sensors, and light sensors) Biometric readers Mobile portable, with risk of being altered and replaced
Security - Payment Trans 1 Interception on entry: No PIN entry direct to device; through a PTS approved PIN Entry Device or EPP (Encrypting PIN Pad). No shoulder surfing If using external device (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. Enable all proper security functions on the mobile device and, where necessary, apply all security updates and patches in accordance to solution provider documentation.
Security - Payment Trans 2 Prevent compromise while processed / stored: Only trusted individuals have access to the payment application and its associated environment The mobile device should be stored in a secure location when it is not in use Monitor physical security of the mobile device Where data passes through a network under the merchant s control (e.g., Wi-Fi or Bluetooth), ensure that it is implemented as a secure network per PCI DSS Requirement 4.
Security - Payment Trans 3 Prevent intercept on transmission: Protect wireless transmissions per PCI DSS Requirements, including but not limited to: Change wireless vendor default encryption keys, passwords, and SNMP community strings. Facilitate use of industry best practices to implement strong encryption for authentication and transmission. Ensure that account data is never stored on a server connected to the Internet.
Security Mobile Device 1 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. Prevent unauthorized physical device access Prevent unauthorized logical device access Restrict logical access to the mobile device to authorized personnel. Always use logical device access protection methods (e.g., biometrics, complex passwords, or multifactor authentication) provided as part of a payment solution either in preference or in addition to built-in methods provided by the device or the operating system manufacturer. If payment solution vendor-provided authentication measures are not present, merchants should require users to authenticate themselves positively to the device using a secure, built-in device-authentication method such as password, PIN, or pattern. If possible, configure the authentication method to force the user to re-authenticate to the device after a specified amount of time. Merchants should consider using full disk encryption on mobile devices, if available. This provides additional protection in the event of theft or loss of the device and may also prevent users from disabling device-level authentication.
Security Mobile Device 2 Protect the mobile device from malware Install and regularly update the latest anti-malware software (if available) 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. Merchants should not circumvent any security measures on the mobile device (e.g., enabling USB debugging if already disabled or rooting the mobile device). To avoid introducing new attack vectors onto a mobile device, install only trusted software that is necessary to support business operations and to facilitate payment. The merchant should require the following activities of its solution provider: The solution provider should regularly update their payment application and indicate to the merchant when updates are available and are safe to install. The solution provider should have restrictions on their payment application so that it only functions on a device running approved firmware. The solution provider should supply documentation that details any update procedures the merchant needs to follow. 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.
Security Mobile Device 3 Ensure the mobile device is in a secure state Employ mobile scanning to detect unwarranted app privileges, detecting apps that store cleartext 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 Employ indication of secure state, and application should not be used if that indicator not present Do not jailbreak or root the device payment application resides on Only use new, factory devices to avoid those devices whose history / provenance is unclear Disable unnecessary device functions Detect loss / theft Record serial, model, O/S, firmware, payment acceptance version Log the distribution of these devices Mark devices with unique indicator (U/V pen or embedded RFI tag) Process for timely detection / reporting of loss / stolen devices Capability to disable / securely wipe the device remotely Secure disposal of old devices
Security Payment Solution Implement secure solutions Ensure secure use of the payment-acceptance solution Policies for secure use Train users Prefer online transactions Do not store transactions for later transmission Prevent unauthorized use Restrict to authorized users Merchants should be able to manage access, changes permissions, revoke access Inspect system logs and reports Logging should be sufficient to detect abnormal activity Make sure logging is enabled, including but not limited to unauthorized access attempts, escalated privileges, unauthorized updates Ensure customers can validate the merchant / transaction Cardholders should be able to confirm merchant is authorized (ID card, list on website, etc.) Mechanism to validate receiver of account information abides by PCI-DSS Issue secure receipts PAN masked, cannot use non-secure channel to send PAN
Solution Provider Selection Solution provider s host-based payment-acceptance application runs in a PCI DSS compliant environment as attested by a QSA. If the solution provider is providing the mobile device, then maintenance and support are provided. The merchant will have the ability to contact the solution provider at any time. Solution provider has good documentation and training for merchant employees who will be end-users. Onboarding process includes provision of sample policies and procedures for merchant. Access control mechanism is in place with means for merchant to authorize, to monitor, and to revoke access privileges. Solution includes logging of user and device access and includes mechanism for reporting activity to merchant. Termination of agreement includes provisions for secure transfer of historic data back to merchant and removal of any merchant data from mobile devices (if such devices are returned to solution provider). Clear terms for warranty and liability that are not onerous to merchant.
Additional Risks Physical Mobile devices when stolen may be inserted into metal bags to prevent communication to remotely wipe the device Indeterminable Unforeseen attack vectors new connections to the device may open additional attack vectors Vulnerabilities markets hackers benefitting from selling zero day vulnerabilities Intentionally inserted backdoor additional zero day vulnerability possibilities Miscellaneous Network connections Memory management generating outage by taking advantage of manufacturer memory practices Variation of devices Access control implementing role based access control (RBAC)
Additional Questions? Free consultations and proposals for: - Security Testing - Security Consulting Adam Goslin, Chief Operations Officer AGoslin@HighBitSecurity.com Direct: 248.388.4328