Wednesday, November 07, 2007

Who are the real culprits for PCI compliance?

There was an article in SearchSecurity today on TJX issue.

Don't blame PCI DSS for TJX troubles, IT pros say,289142,sid14_gci1280854,00.html?track=sy160&asrc=RSS_RSS-10_160

Here is an excerpt from the article

The auditor said TJX passed a PCI DSS check-up, but that the auditor failed to notice some key problems.

"They had no network monitoring and no logs, and they had unencrypted data," he said. "But this wasn't picked up by the auditor. They passed the Level 1 inspection and shouldn't have."

This makes me wonder what is the real objective of PCI complpiance. Most of the companies are still trying to understand the PCI requirements and hire a third party to assess their infrastructure for PCI compliance. Now, if PCI council has approved a vendor to assess a company's infrastructure for PCI requirements then for a company, the vendor understand PCI requirements and have proven to PCI council that they are qualified and capable of doing a good job. Now if a vendor charges $1000 to do the job or $15000 is upto the vendor. Companies are always looking for a good bargain and there is nothing wrong with that, as long as they are going to an approved vendor.

So if a company still gets breached after they are PCI compliant (assuming the data stored was not encrypted), who is actually liable in this case? The company or the vendor who certified the company for PCI compliance? In my mind, if the vendor would have told the company that they have to encrypt the sensitive data in their database, and company has not done it, then there was no question of company being PCI compliant.

Company getting penalized is understandable but is PCI council also going to impose penalties and fines on vendors who are not doing a good enough job? If a company is PCI compliant then its not completely company's fault for the data breach as much as it is the vendors, who did not identify and report the issues and certified the company as PCI compliant.


kingthorin said...

A couple of thoughts.

1) VA/Pentest type contracts usually state that liability is limited to the value of the contract. (If the contract is $1000 is the client going to come after you for being wrong/missing something? The lawyers will cost more.)
2) As a VA/Pentest vendor are you willing to accept $1,000,000 in liability for being wrong/missing something on a contract worth $1000? (I wouldn't. Would your investors? Your insurance company?)
3) The PCI DDS governing body should put the certifying (VA/Pentest) vendor on probation or revoke their membership (er whatever you wanna call it) if they miss something which results in a breach.

Adrian said...

This is a really good question and I am surprised you have not gotten more response on it. I think the question you are asking is ‘who is liable?’ The company for adopting an inappropriate compensating control? An auditor for missing it? PCI sponsors for drafting a bad specification?

I think that the answer to the question is that, in the same way as a financial audit, the company is ultimately responsible. Misreported earnings, as a result of error or fraud, is the company’s problem. The same is true for a data breach. The consultant or auditor who fails to provide an effective audit will be affected as well, hopefully in proportion to their level of incompetence or complicity. I think Enron is a good example of this, where both company and auditor took the fall.

PCI standard itself as a contributing factor is another angle, but I do not think that the standard is all that confusing. I have heard several cynics that claim that PCI is sponsored by marketing organizations and therefore must only be interested in the appearance of security, labeling PCI a marketing effort rather than a security effort. But the toughest technical due diligence process I have ever gone through was one conducted by Visa, so I know first hand that this is not true. While I consider PCI DSS ‘Data Security 101’, I think that the intentions are good. I also believe they wrote the framework to be flexible so merchants had choices in how they implemented their PCI plan, making the job of auditors that much more difficult.

Anurag Agarwal said...

Adrian -

I have nothing against PCI standards. I am in fact in favor of it. My problem is with the execution. I can understand PCI council's intention of having as many auditors as possible, but what is the point in having a good standard if you are not going to implement it properly. I have spoken to many vendors who offer PCI services and more then half of them dont even understand web application security. So how did they become PCI approved vendor? I think the vendor should also be held liable if they miss something which results in a breach.

Jim Manico said...

Anurag - this is a very insightful post and I'm shocked that more of the mainstream and/or tech+security press has not picked up on this fact. So my question is, is the PCI auditor liable for this breach in any way? It seems like the PCI auditor didn't miss obscure stuff - but missed complete and totally glaring errors in TJMax's security posture.

Anurag Agarwal said...

Jim - Good question but who has the answer? The other thing is, even if lets say auditors were at fault in this case, does PCI has any kind of rules to penalize them?


Anonymous said...

My exp is that audits are more passive in nature, hence based on the evidence provided the auditor concludes. I think where the stakes are high, the approach should be more practical to aviod any future shocks. What say/


Anurag Agarwal said...

I think the real question should be "how qualified the auditors are when it comes to web application security?"
Unless they understand the field, they will never ask the right questions.

pci compliance said...

"Who are the real culprits for PCI compliance?"