The PCI DSS E-commerce Guidelines v2 were a welcome update to the previous version of the document.
One of the new aspects included in the revised guidance was a discussion of the most common e-commerce implementation models (section 3.4) and what responsibilities the merchant and other parties have (section 3.5) under PCI DSS. The models discussed are:
- Merchant-managed e-commerce implementations
- Proprietary/custom (bespoke) developed shopping cart/payment application
- Commercial shopping cart/payment application (typically PA-DSS
- Shared-management e-commerce implementations
- Third-party embedded application programming interfaces (APIs) with direct post
- An inline frame (or "iFrame") that allows a payment form hosted by a third party to be visually embedded within the merchant's page(s), sometimes also including other intermediaries
- Customer redirection to a third-party hosted page for payment entry
- Wholly outsourced e-commerce implementations.
While some merchants believe they are "wholly outsourced" already, the definitions should be read. The guidance reminds merchants they still have primary responsibility for particular PCI DSS requirements. In the case of inline frame and hosted payment page approaches, this includes for example securing the web page(s) containing the iFrame code and redirection code and/or function(s) respectively.
Merchants should include security review and verification activities during template change processes. But regardless of PCI DSS compliance, what other technical security controls could be considered when selecting an outsourced online payment page or form? If I was a merchant, I would prefer to choose one that enables and enforces the following web application security wish list, in addition to the outsourcer's own existing PCI DSS compliance requirements:
- Page template administration
- Each user (e.g. each designated merchant employee) with the ability to upload or edit templates to have a unique identity, and no use of shared accounts
- Two factor authentication for all access to the outsourcer's systems (e.g. file transfers, web administrative interfaces, web services)
- User account access limited to a small set of merchant IP addresses
- Encrypted connections for authentication and template upload/edit
- Event alert to nominated address/system on template change
- Automatic stripping of any other party hosted (i.e. non outsourcer and non merchant) content from the template with related event alerting
- Accessible audit trail of changes
- Payment form/page hosting
- Only available using Transport Layer Security
- No other party (i.e. non outsourcer and non merchant) content
- No use or reliance on any merchant, outsourcer or other party HTTP cookies
- X-Frame-Options HTTP header, with the value "DENY" for a page that is not framed, else with a value "ALLOW-FROM ..." that (supporting web browsers) only permits the particular form to be framed by the specific individual merchant's whitelist hostnames
- HTTP Strict Transport Security Header
- X-Content-Security-Policy/X-WebKit-CSP/Content-Security-Policy header with a strict policy that does not allow any content from other parties (or perhaps just some types of content from the merchant's selected hostnames
- MIME type and character set HTTP headers correctly defined
- Strong anti-caching HTTP headers
- Payment form submission
- HTTP method POST enforced, and no other method permitted
- Only possible using Transport Layer Security.
This is a somewhat long list, but it would be interesting to know which commonly used payment outsourcers can provide this level of assistance to ecommerce merchants.