The PCI Fraud Argument Conundrum
Written by David TaylorGuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.
Why do retailers, service providers and financial institutions strive to achieve and maintain PCI compliance (assuming they do)? Mostly, they do it because it’s mandated by the card brands and their card acquirer. Too often lost in the coercive relationship that drives PCI, however, is the intent of the standards: fraud reduction. A few simple Google searches will confirm that the links between PCI compliance and fraud reduction are largely unexplored and unproven.
As we’ve noted previously, being PCI compliant won’t stop breaches. It also won’t stop fraud. Standards, by their very nature, cannot be adjusted fast enough to incorporate the latest technological advances (by good people or bad people). And their implementation is always imperfect, even if a company manages to score 100 percent on the “PCI test.”
However, if the focus of compliance is shifted to “detection” of a breach or any resulting fraud, the value of PCI controls becomes clearer. Don’t think of PCI as building a wall around your credit card or other confidential data. Think of PCI controls as enabling improved fraud and breach analysis.
Very few organizations incorporate PCI controls data into their fraud analytics process. Sometimes it’s because the fraud analysts have a specific set of tools they use and these tools do not incorporate any awareness of (or data from) PCI controls. Other times it’s because the analysis of PCI controls data is too technically focused–whether a specific control is in place and whether it is detecting unauthorized access.
The missing connection between the data that PCI controls generate and the fraud analytics process may be related to the usability or granularity of the PCI controls data. On the other hand, the connection may be missing because the fraud analytics process is run out of accounting and finance while PCI is being run out of IT or the compliance office. Whether the problem is technical, analytical or organizational, it would be very valuable to get people from all these divisions talking about how to use all the data that PCI controls generate to improve fraud and/or security breach detection.
PCI compliance has not been “operationalized” by 95 percent of merchants. As such, even for those who have achieved compliance and (hopefully) are working to maintain it, the business value of PCI compliance is going unrealized. One reason is (and will continue to be) that PCI is too “technology focused” for business managers, accountants or internal auditors to want to own it or use the data its controls generate. This schism creates an opportunity for what we’re calling “PCI Analytics,” which is a type of tool or service that makes PCI controls data usable by business analysts for the purposes of fraud detection and risk management. Even though PCI requirement 12.1.2 requires a risk analysis, PCI controls themselves typically have little or no impact on any corporate risk analysis. This situation is true despite the fact that a lack of certain PCI controls almost unquestionably increases the material risk of potential security breaches an enterprise faces.
We will increasingly focus our 2009 research on developing links between PCI compliance, fraud analytics and risk management because these links are key to demonstrating the business value of PCI compliance beyond avoiding fines and satisfying the demands of acquiring banks. Needless to say, if you have any involvement in, or even just an interest in, proving the business value of PCI compliance, please visit the
PCI Knowledge Base. If you’d like to participate in our research, send an E-mail to David.Taylor@KnowPCI.com.
-Marc
February 25th, 2009 at 4:25 pm
It would be just as interesting to see how correlated the outcome of other audits are with the actual security of systems. What does an SAS 70 audit really tell you about security?
February 25th, 2009 at 4:47 pm
Luther,
Synching audit reports and security is tough, as you know, and I agree it will be worth researching. As for SAS 70 audits, I tend to be pretty negative on their effectiveness, even Type II. But your point is excellent.
February 28th, 2009 at 4:42 pm
I would take respectful exception to anyone who might be tempted to cast doubts on the effectiveness of SAS 70 audits. SAS 70 audits can be crafted to meet security objectives – it is up to the user community – that means the wholesale end users – to express their reuqirements to the servicer. If the servicer is not presented with a mandate for a meaningful security related control objective, they may take path of least resistance. It is up to the servicer’s customers to express what they need.
March 1st, 2009 at 8:34 am
The reason I tend to be negative on SAS 70 audits is that the company being audited has too much control (IMHO) over the nature and depth of the audit. You’re right that they can be made effective, but that is not what I hear from the companies that we’ve interviewed. Our view is taken from our research. I gather you’re a SAS 70 auditor, and I’m sure you and your company do an excellent job, but many companies are taking advantage of the flexibility inherent in the process. One of the reasons we like PCI assessments is that there is less room to “maneuver” for both the auditor and the auditee (if that’s a word).
thx, Dave