We have been performing many interesting PCI DSS compliance projects, recently, assisting organizations in identifying their security and compliance gaps, creating remediation project plans, and assisting in communication with the acquiring bank that process their credit card transactions, often ghost-writing correspondence.
One of the most interesting things to come up recently has been the response from a service provider to a client about their PCI compliance status. This company developed a custom payment application and manages it in their own data center for my client. It falls into a common area of PCI misconception – what third parties are responsible for your payment card data? The rule of thumb is, if they accept payment instruments (Payment Account Numbers, aka PAN, aka credit card numbers) even for just a moment before it’s passed to a payment gateway which returns an approval code, using your merchant ID, then it’s still in scope for your compliance project. You should make sure to have contractual agreements in place that stipulate their adherence to PCI DSS requirements, and collect compliance data from them. If you use a third party, such as Paypal or Authorize.net to completely handle all your card data and only send you an approval code or token, then it becomes their problem.
The vendor, in the specific case that brought to light the need for this blog post, indicates that they are compliant, but our review of the documentation shows that the vendor doesn’t have a clear understanding of the overall PCI requirements, of many of the specific controls, and of some very basic security concepts. Either that, or they were hoping to fool some n00bz. I’ll give them the benefit of the doubt. Hopefully, the bureaucratic inertia gives way and we’ll be able to communicate with them directly, shortly, in order to understand more about what they are are doing, and provide some guidance towards better protecting my client’s data and compliance status.
Some of the things that gave me pause:
A word of advice to those who outsource payment processing to an app vendor…
Make sure to request a copy of their Self Assessment Questionnaire (SAQ) – Version D, which contains an itemized list of controls. If they’ve never filled one out, you can bet that there are gaps. If they have filled it out, and yuo’re suspicious about whether some of the controls are in place, request validation – configuration screen shots, etc.
Request for a copy of their recent quarterly ASV scan – the executive AND technical report.
Request a copy of their most recent network penetration test or web app assessment report. At QuietMove, we often write a “customer facing letter” for a client that they can produce in lieu of the technical report. It summarizes our testing methodology, the resources tested, and provides an executive summary of the controls identified and their effectiveness, so that a service provider client of ours doesn’t have to provide a technical report with lots of internal sensitive technical information.
Verify everything – software versions, network diagrams, etc. If you have doubts, request to run your own scan using a PCI compliant scanner. If a vendor uses your merchant ID in a custom application that they wrote and host for you, and payment card data is stolen, the security of Payment Account Numbers in that environment is contractually your responsibility.
If you need help with a PCI compliance project or PCI Self Assessment Questionnaire, have PCI compliance questions, or need to have network or application penetration testing performed, contact us using the contact form on the right, or call 1(866) 894-0459.
Did you enjoy this article? Please subscribe to our our RSS feed or Security Alerts email list.
Comments on this entry are closed.