I am presenting a proposal to setup a SIG for Third Party Assurance at both Orlando and Dublin PCI SSC Community Meetings. The aim of the SIG is to provide additional guidance around control 12.8, which to date we think is somewhat open to interpretation.
The control as it stands:
12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following:
12.8.1 Maintain a list of service providers.
12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.
So what's wrong with this control? Well, firstly, “if cardholder data is shared” implies that service providers only need to be considered if you give them cardholder data. Fair enough, one might suppose this is the biggest risk, but how about managed firewall providers, or providers of desktop/server support? Cardholder data is not shared with these types of provider, but they may have access to it, or could potentially alter a security control that secures it.
During a PCI assessment, these entities are supposed to fall into an entity's scope of PCI DSS Compliance. So a managed firewall provider would need to be assessed against all relevant PCI DSS Controls. This of course rarely happens. Service providers are generally unwilling to become audited, namely due to the cost and resource it consumes, but also as they have never agreed to be PCI DSS Compliant in the first place.
If service providers are not PCI DSS Compliant, then it falls upon the assessed entity to measure and monitor the service provider and potentially control what they do. Control 12.3.9 implies that an entity only permits access to their cardholder data environment in a controlled manner:
12.3.9 Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use
..but then what about 24/7 outsourced support operations? Is an entity expected to implement controlled remote access to service providers that access systems out of hours? Technically yes, even if they are fully PCI DSS Compliant!
I've blogged and spoken about this in the past, but my one pet hate is the number of providers out there that are marketed to be “PCI DSS Compliant”, or a sales guy on the end of a phone says their service is “PCI DSS Compliant” and the entity goes ahead and buys it. Fault at both ends there really, and will be a fascinating challenge for the proposed SIG to undertake.
There are many controls in the standard that may or may not involve service providers, and each case is going to vary from entity to entity. Variance in the eyes of PCI DSS is bad, as very difficult to measure, monitor and improve card data protection in the industry as a whole if each entity is doing things in a different way. To cut a long story short (you can hear the long version at the community meetings), we propose to set this SIG up to address issues such as this, and help ensure PCI DSS-applicable entities know how to handle third party risk.
If you would like to be involved, let me know. If you are a Participating Organisation, then your vote would be much appreciated as this affects all of you! 🙂