PCI-DSS 3 E-Commerce Learning

Disclaimer: This articles is a part of my research into PCI-DSS, and is not a definitive source of information

Payment Card Industry Data Security Standard, PCI-DSS for short, is a standard for organizations that handle cardholder data of branded credit cards from the major card schemes including Visa, MasterCard, and American Express. It is maintained by the PCI Security Secuirty Standards Council.

Non-compliance to PCI-DSS can result in a range of consequences, including range of fines and liability implications.

Cardholder Data

PCI-DSS defines cardholder data as follows:

  • Full PAN (primary account number)

When the full PAN is present, other sensitive data includes:

  • Cardholder name
  • Expiration date
  • Service code

It is allowable that a PAN’s can be masked for display by showing the first six and last four digits.

Compliance Extend beyond IT

While IT can help to make it easier to manage processes, but there is no way to replace responsibility and ownership of critical customer data.

Even if IT solution is purchased from a vendor claiming that they have attained PCI-DSS compliance before, it actually cannot encompass all of the control objectives required by PCI-DSS when an organization uses an instance of such a vendor solution. There are many controls apply to business process rather than any IT implementation.

For example, just because a website is hosted on SquareSpace, it doesn’t mean they are automatically PCI-DSS compliant. I wonder how many organizations actually do the due diligence of reading into what compliance actually requires when given the complex jargon of the documentation and numerous IT requirements to actually be compliant.

E-Commerce SAQs

Self-assessment questionnaires (SAQ) are validation tools provided by the PCI Security Standards Council intended to assist merchants and service providers in self-evaluating their compliance to PCI-DSS. The language of these SAQs would likely take an IT professional who has looked into PCI-DSS to see which one actually applies a particular e-commerce solution.

 

For e-commerce, one of SAQ A, SAQ A-EP or SAQ D would apply. Each contain a different set of validation criteria and recommendations an organization would have to meet, along with the significant cost differences to comply to each.

In general, a merchant must always be PCI-DSS compliant if they accept credit card payments, even if the card is entered on another site. Payment processors such as PayPal/Stripe/Recurly would typically recommend the merchant to completing SAQ A at minimum.

 

Just because the requirement is not a checkbox on the SAQ, it doesn’t mean that the merchant can ignore being responsible for implementing the requirements of the PCI-DSS. For example, they still need to make an effort to secure their network as well as show evidence of this. I am reading that experts who are evaluating solutions which would fall under SAQ A actually use the SAQ A-EP as much as possible to mitigate risks.

The following diagram provided by the PCI council tries to show the distinctions of which SAQ to use in various documents:

E-CommerceSAQ

From SAQ_InstrGuidelines_v3-1.pdf

VISA Europe had published an e-commerce payments guide which is more clear which SAQ to pick, as pointed out by the PCIGuru blog:

Matrix

Vulnerability scans occurring every quarter from external ASVs (approved scanning vendors) are required in SAQ A EP, SAQ D, but not under SAQ A. The list of ASVs is maintained by the PCI Security Standards Council, and adds additional cost to operating an e-commerce solution.

Under SAQ A, the merchant server serving the redirect/iFrame is not in scope for PCI-DSS compliance because no part of the merchant’s server touches CHD (card holder data).

Types of Controls

Control objectives PCI DSS requirements
Build and maintain a secure network 1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data 3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program 5. Use and regularly update anti-virus software on all systems commonly affected by malware
6. Develop and maintain secure systems and applications
Implement strong access control measures 7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security policy 12. Maintain a policy that addresses information security

From PCI-SSC quick guide, pulled from Wikipedia

Consider SaaS and Avoid Self-Hosting

Speaking from my own experience, IT professionals who know how to solve the problem of creating an e-commerce solution may not have knowledge about PCI-DSS compliance and pick the wrong solutions for your organization as a result. These organizations may have to find out the hard way via a data breach or fine to happen.

With any IT solution, ‘economy of scale’ results in products which meet more requirements at an affordable cost. Use well-known true software-as-a-service (SaaS) platforms which provide explicit documentation and support on how to operate a PCI-DSS compliant solutions.

For example, I would recommend the likes of SquareSpace and Shopify to provide a solution instead of self-hosting store-front using WordPress or Magento for organizations who cannot afford to have dedicated IT operations. Trusting off-the-shelf WordPress plugins to be part of a PCI-DSS compliant solution has the potential for pitfalls. There is a similar challenge with picking PCI-DSS compliant web hosting.

Additional Reading

  1. PCI Security Standards Understanding PCI-DSS v3
  2. PCI Security Standards PCI-DSS v3 SAQ A
  3. Recurly – PCI-DSS Compliance
Advertisements