Last month, Chinese smartphone manufacturer OnePlus announced that it had experienced a security breach that potentially exposed payment card information for over 40,000 customers.
The breach is still under investigation, but it is believed that hackers were able to inject a malicious script into the payment page code on a payment processing server operated internally by OnePlus. The script was running on the OnePlus server for almost two months before it was discovered and was capable of stealing any data customers provided on the site, including full credit card numbers, expiration dates, and security codes. Any customer that manually entered their information into the OnePlus website is at risk.
OnePlus was not processing the payment card transactions or storing cardholder data on their site. Payment card information was sent directly to their payment processing partner, CyberSource, over an encrypted connection and processed on the third-party servers. However, the payment page, which requests the customers’ cardholder information, was delivered by a OnePlus web server. Hackers were able to compromise this web server and add a script to the web page that would also harvest the information in an unencrypted format while the customer typed the cardholder data in to the payment page.
So THAT’S why we ask vendors for proof of compliance!
We often receive questions from our customers regarding the security and compliance of third-party service providers that will be collecting information via an e-commerce website on behalf of the organization. Common examples include ticket sales, crowdfunding, donations, etc. When these vendors are asked to provide the necessary PCI compliance information, namely an Attestation of Compliance (AOC), they will often respond that they do not view themselves as a PCI service provider because they “don’t store cardholder data” or they “never see cardholder data and are sending the cardholders to a validated third-party payment processor”. This is often a red flag as the vendor does not understand PCI compliance fully and their responsibility to have the appropriate security controls in place. They should be completing the SAQ D for Service Providers or having a QSA come onsite for an Onsite Assessment (also known as a Report on Compliance). Apply the quoted statements to what we know about the OnePlus breach—OnePlus used a PCI-validated third-party provider to process payments and also never stored or even had access to view customer cardholder data. However, a simple hack allowed cardholder data to be stolen utilizing a web server that simply “sent the cardholder to a validated third-party payment processor.”
When setting up a new e-commerce website for your organization or evaluating a new service provider to accept payments online, it is important to focus on PCI compliance and ensure all portions of the payment page are set up securely. Merchants can choose to integrate with a third-party developed solution or completely outsource the function, however, they must remember that no option completely eliminates their PCI DSS responsibilities. The merchant will always be responsible for ensuring that the payment card data of their customers is protected.
So what are my options?
Generally speaking, the safest option for e-commerce is to use a fully outsourced, PCI-compliant, third- party payment provider whose primary purpose is to securely process payment card transactions. These vendors have solutions that were built to securely handle payment transactions and have made the commitment to compliance and security by completing their annual PCI-compliance attestation. These types of solutions typically allow the merchant to attest compliance using the SAQ A because the customer is on the third-party site when entering their payment card information and no account data is collected, stored, processed, or transmitted by the merchant’s systems. The merchant is then responsible for only those twenty-two requirements in that shortened SAQ.
However, there is still the risk of a man-in-the-middle attack in which a hacker compromises the link that directs the customer to the third-party site, and takes them to a fake or malicious payment page instead. This risk can be alleviated by closely monitoring your website with file integrity monitoring software and rigorous adherence to your change control processes. Performing vulnerability scans on your site is not required by the PCI DSS in this instance, but can also be beneficial as a general information security best practice.
In some instances, merchants may wish to provide advanced features or customize the customer payment experience more. The benefits of customization should be closely weighed against the increased need and costs for the security responsibility and required controls. If this is the route a merchant elects to go, there are a few options explained at a high level below:
- The merchant may elect to embed a third-party payment page within the merchant website, commonly referred to as using an iFrame. This is a PCI-compliant method of accepting payments, allowing use of the SAQ A for annual merchant attestation when properly implemented.
- Another commonly used option is the Direct Post, JavaScript, or application program interface (API) integrated implementation. In each deployment it is the merchant’s website that delivers the payment page. Cardholder data is still not stored or processed on the merchant website, but the way it is collected by the payment service provider is controlled by the merchant and therefore in scope for the additional PCI DSS controls included in the SAQ A-EP. This scenario is what we saw with OnePlus who failed to protect the website and its code.
- The final option is for the merchant to create, manage, and host the entire e-commerce website. In this scenario, the merchant systems are involved in receiving, storing, and transmitting cardholder data. This architecture brings the highest risk for merchants and will require compliance with all PCI DSS requirements in the SAQ D – Merchants. Given the amount of work involved to secure the website and customer data, this is no longer a common choice but we did want to acknowledge that it is still an option.
Whether you are outsourcing pieces of your e-commerce website or not, it is the merchant’s and organization’s responsibilities to ensure all systems involved are adequately secured. A breach similar to what occurred at OnePlus can have a significant impact – the costs of downtime and suspended payments, notifications to affected users, credit monitoring services, forensic investigations, and fines will be expensive, not to mention the reputational damage that will occur when customers no longer should prevent you from ending up in a similar situation.
If you have questions about your merchants’ e-commerce practices, would like us to review payment pages or configurations, or would like a review of any third-party service provider agreements or compliance documentation, please contact your CRM Team.
You can also reference the PCI SSC’s April 2017 Best Practices for Securing E-Commerce document.
Some additional guidance from our Penetration Testing Team below:
[Wheeler]: Care should be used when selecting a 3rd party e-commerce provided. Vet the company thoroughly, and remember cost shouldn’t be the sole factor in the selection process. In the event of a breach [of your customer’s data] at the hands of the 3rd party provider, you still are left with trust issues and bad PR which is hard to monetize. Outsourcing e-commerce can be beneficial, but doesn’t mean that you have fully mitigated risk. Ensure that your organization fully understands the risks associated with each option.
