At the request of subscribers, Compliance Week offers a Remediation Center, in which readers can submit questions—anonymously—to securities and accounting experts. Compliance Week’s editors will review all questions and then submit them—confidentially, of course—to specialists who can address the issues. The questions and responses will then be reprinted in a future edition of Compliance Week. Below is one of the Q&As; ask your own questions by clicking here.

QUESTION

I heard TJX Cos. was compliant with the PCI standards for data privacy and hackers still swiped 45.7 million customer records. Is that true? Does PCI compliance protect me against a breach? If it doesn’t, what should I be doing?

ANSWER

The question of PCI compliance and breach protection is an interesting one. Does PCI compliance protect against breaches? The answer is technically, yes, and in reality, no.

The answer is technically yes, because PCI Requirement No. 10 asks you to audit access to cardholder data. It also asks you to review these logs periodically for unusual activity. The spirit of these requirements is to ensure that you can detect a data breach and act on it. For example, PCI says: “Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.”

That’s nice, but as TJX shows, in reality the answer is no, PCI standards don’t protect from data breaches, for three principal reasons.

This recommendation is commonly ignored. No one has time to read logs frequently and look for unusual data activity. (I’m serious; I know of a retailer who says an IT security staffer spends six hours a day to look through logs.) So this activity is not real-time and misses the breach when it happens.

The logs that actually access cardholder data are much more important than any other system log. But most enterprises are still not logging cardholder access data. Without such logs, enterprises do not have the “visibility” to understand if a breach is affecting your data. Today, they still rely on perimeter intrusions and application authentication logs, not data access logs. For example, if someone detects an intrusion in an application server, it does not mean that data in the database is breached; an intrusion does not equal a data breach. Another example: if an ex-employee is accessing the data in the database, intrusion alerts might miss this activity—but data access logs will catch it.

The logs can only tell you when and how users or applications access data. They have no way to spot patterns or tell you that a particular user is doing something anomalous. Without this analytical ability, log analysis misses the breach completely. In fact, most breaches were discovered by out-of-band means, not through log analysis.

If you are looking for effective data breach protection, you have to invest in a technology that has analytics capable of spotting user-level anomalies—much like a credit card fraud protection system. Data auditing technologies have such analytics. Look for systems that are strong on such analytics and easy to use.

For example, systems that support policy-based analytics around how much data is accessed, how frequently, what time, by whom, and from where, are all good outliers to flag in real-time. Interestingly, most big breaches that happened from databases and file servers could have been caught by such analytics in real-time. You will always have a minority of breaches that escape these analytics, but that’s OK. The key is to reduce the significant risk of big breaches. Risk management is not about perfection; it’s about managing the biggest risks so that enterprises can stay in business and maintain stakeholder trust.

My recommendation: PCI compliance will help you protect against data breaches, but only if you seriously invest in PCI No. 10 analysis and alerting requirements around data access. More than 60 percent of data breach losses happen from the systems and databases that hold credit card information. That’s a good place to start in monitoring, analysis, and alerting.