Whose fault is it anyway?

Jan 05, 2015

The news that Charge Anywhere, a US based payment gateway provider was breached, is maybe not a shock to InfoSec professionals but will rightly cause concern for merchants.  After all, if you can’t trust your payment gateway to be secure, who can you trust?   

It is perhaps timely that this breach comes to light just as PCI DSS v3.0 becomes mandated.  One of the most significant changes in v3.0 is the increased focus on merchant/provider relationships.  The standard now requires not only that merchants agree with their suppliers the supplier’s responsibility for protecting card data under their control but also that they maintain information about the specific requirements for which each party takes responsibility. 

The main reason for this is that your QSA needs to know that all the requirements relevant to your environment are being covered by someone.   The risk is that each party believes that the other is responsible or sometimes, more cynically, believes that they can offload responsibility.  An example might be where the merchant outsources network management.  The provider may manage the network in a way that complies with all the requirements about secure configuration, access control and so forth, but whose responsibility is it to define and review the firewall rules? 

It may seem much more straightforward when considering a provider such as a payment gateway or an outsourced managed web site. The provider is surely responsible for all the requirements relating to that service.  A good first step might be ask for the supplier’s SAQ or RoC and see if this if matches up to what you would expect for the service they are providing.   Be prepared to query anything shown as ‘Not Tested’ or ‘Not Applicable’.

A complication arises when the service provider sub-contracts elements of the service.  If the service provider is compliant then they should have met the requirement (if they are compliant with v3.0) to agree the requirements covered by the companies providing a service to them, so you don’t need to duplicate this.   But if the primary supplier has not been assessed as compliant and is sub-contracting to others then you will need to go through the process of agreeing what the sub contracted parties cover. 

Thinking about this chain of responsibility raises another important point.  Although PCI DSS says that you must have an agreement with your providers that they are responsible for security of any of your card data that they handle and you must agree the division of responsibility for requirements, this is NOT the same as contractually being able to pass on any fines, penalties, and other costs arising from a breach.  This is not directly a PCI DSS issue but might end up being critical.  Ensure that your procurement and legal staff are aware of the risks and engage them in the process of agreeing responsibility.          

To find out more about the security risks raised in this article, or to learn how to comply with PCI DSS V.3, contact 7Safe to speak to a QSA today.