Who is Minding the Legal Risk Around PCI?
An article I did for the ISSA Journal: Who is Minding the Legal Risk Around PCI?
Trackbacks (2)
Links to blogs that reference this article
Trackback URL
http://www.infolawgroup.com/admin/trackback/163590
http://www.infolawgroup.com/admin/trackback/163590
The Legal Risk around PCI « The Branden Williams Security Blog -
June 16, 2009 4:36 AM
TITLE:
URL: http://www.brandenwilliams.com/blog/2009/05/01/the-legal-risk-around-pci/
IP: 76.237.242.34
BLOG NAME: The Legal Risk around PCI « The Branden Williams Security Blog
DATE: 06/16/2009 04:36:44 AM
InfoSecCompliance.com - Technology, Privacy and Security Law & Risk Management » Blog Archive » Nevada Law Incorporates PCI and Provides a Liability Safe Harbor -
June 23, 2009 12:26 AM
TITLE:
URL: http://infoseccompliance.com/2009/06/22/nevada-law-incorporates-pci-and-provides-a-liability-safe-harbor/
IP: 74.53.63.82
BLOG NAME: InfoSecCompliance.com - Technology, Privacy and Security Law & Risk Management » Blog Archive » Nevada Law Incorporates PCI and Provides a Liability Safe Harbor
DATE: 06/23/2009 12:26:29 AM
Post A Comment / Question
Use this form to add a comment to this entry.
Send To A Friend
Use this form to send this entry to a friend via email.
On the one hand, proper PCI compliance is likely to look different for Heartland Payment Systems and a local laundromat. But, on the other hand, looseness in PCI interpretation increases legal risk.
Yet another case for hiring a one-armed attorney ;-)
Tony, very good point. A couple of responses. First, I think that the PCI Standard should be modified to explicitly include a risk-based component that would apply throughout the standard.
Second, my comments about risk do not mitigate against the need to comply "with the letter" of the Standard. Risk would go to the depth of compliance. For example, under 12.8, a merchant utilizing a service provider to process 1 million transactions a week may have to "look under the hood", whereas "due diligence" for a service provider processing 100 transactions a week might be more along the lines of getting a letter concerning PCI compliance. In both cases "strict compliance" was achieved (e.g. they had a due diligence process"), but for the first service provider, a more rigorous due diligence process was warranted.
I really agree on that last post Navetta and I was hoping for PCI SSC to include it in the prioritized approach-document but unfortinately not...
Very interesting article indeed!
One question about service providers though. Am I correct in thinking that version 1.2 (published October 2008) of PCI DSS no longer requires service providers to be compliant?
Requirement 10.8.1 has been changed to "Maintain a list of service providers" and requirement 12.10.3 is no longer there.
What remains is:
- maintain a list
- maintain an agreement about responsibility for security (NOT compliance with the standard)
- process for engaging service providers based on due diligence
- program to monitor SP's compliance status
So if a merchant:
- has a company on its service providers list,
- maintains an agreement about securing the data,
- 'trusts' the service provider based on predefined criteria, and
- asks the service provider if they are compliant, to which the service provider answers: "We protect the data, but we are not compliant",
that merchant should be fine?
Thanks James, excellent point and very nice reading of v 1.2. in that respect. As you point out, in a strict reading of the PCI Standard, it does appear that technically service providers do not have to agree to be PCI compliant. (12.8.2)
They need to have an "established procedure" for engaging service providers that includes "due diligence." No reference to what that means in terms of PCI (e.g. it does not say that the process must check PCI compliance to equate to "due diligence")(12.8.3)
12.8.4 is somewhat more on point in terms of PCI -- maintaining a program to monitor service provider's PCI compliance. Again, however, the focus is on a program is not necessarily the same thing as actually confirming PCI compliance. However, this section at least provides an implication that the service provider must be PCI compliant (e.g. it at least mentions PCI).
And this is where the problem lies while 12.8.1 - 12.8.3 do not specifically require service providers to be PCI compliant, 12.8.4 certainly suggests that they should on some level. It is horribly vague and not well drafted.
If a merchant were to rely on your interpretation, which at least appears correct for 12.8.1 - 12.8.3, and a narrow reading of 12.8.4., can you imagine what happens if the merchant then suffers a breach and is getting judged by Visa (e.g. trying to preserve the PCI Standard) or a plaintiff's attorney (trying to win a case). This is where the depth of compliance matters (and where compliance with the letter and not the spirit of PCI can get one in trouble). It would be, in my opinion, engage in a practice of working with a non-PCI compliant service provider based on a narrow (and arguable correct) read of this section.
Thanks for sharing this article. I would add section 6.6 to the list of ambiguous requirements and especially the hidden debate about fix / remediation vs. discovery of web application vulnerabilities, which I always consider to be a liability and an accountability issue. See also http://blog.imperva.com/2008/04/pcis-66-accountability-problem.html
-- Sharon
Finally got to reading it! It is a truly AWESOME paper... watch for me getting excited about it on Twitter :-)