The Regrettable Databreach Rear View Mirror Strategy
Written by David TaylorMarch 25th, 2009
GuestView 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.
Ever wonder why when you read about a security breach it seems that it began months before the company learned about it? I’m sure that in some cases, this is because the criminals are exceptionally clever at covering their tracks. But on the basis of nearly 350 hours of anonymous interviews with merchants, financial institutions and service providers, I’ve reached the conclusion that this is primarily because companies have a “Rear View Mirror Strategy” when it comes to security breach detection and alerting.
The controls, policies and procedures used by most of the companies we’ve talked to are mainly aimed at after-the-fact forensic analysis of log data, rather than real-time alerting and event management. The questions are “Why?” and “what can be done to fix this problem?” Here’s my analysis and a few best practices from the PCI Knowledge Base research:
Almost all of the PCI standards aimed at breach detection through log analysis have a forensic focus, including 10.2, 10.3, 10.4, 10.5 and 10.7. The goal is to ensure that the logs are accurate, that they cannot be modified by unauthorized persons and that they enable the tracking of harmful events back to specific individuals. These requirements are both necessary and valuable. But the value of these controls is mainly to aid forensic technologists hired by the company or government agencies or the card brands after a breach has become large enough that it has to be reported (thanks to both the 44 US state breach disclosure laws and each merchant’s contract with its acquiring bank). The desire to catch breaches when they are merely “events” has more limited coverage in the PCI standards.
PCI DSS 10.6 is the standard that is often cited as a driver of real-time event analytics. However, it doesn’t actually say that. The standard says that companies subject to PCI must “review logs for all system components at least daily.” I don’t know if you’ve checked lately, but “all system components” is a whole lot of components. Seriously, it’s a lot. This standard also mentions that companies “may” use automated log management and alerting tools to accomplish this task. What is not mentioned, unfortunately, is any reference to “real-time” or “event management” or any suggestion that this task is essentially impossible for any large company to accomplish effectively without dedicated, expert staff using current event management tools. As a result, the implementation of this standard can best be described as perfunctory or minimalistic, or “crappy” (by those with less of a flair for rhetoric).
On the bright side, our research has found that a minority of merchants and a slightly larger minority of financial institutions and service providers have implemented best practices which go substantially beyond the PCI standards and focus on real-time event analytics. In some cases, the best practices are driven by threat management policies related to protecting the digital assets of the business by setting forth guidelines for how to treat “confidential class” data. In other cases, the best practices are focused on effective utilization of relatively advanced threat management software or services as part of an enterprise SIEM (security information and event management) strategy. In either case, the PCI standards are subsumed into the enterprise standards for the protection of confidential data (with specific procedural additions that apply only to card data).
The economy is still in the dumper, despite the current wave of pseudo-optimism, so merchants are only doing what they have to do. Maintaining PCI compliance is certainly on the “have to do” list, but automating threat management and log analytics are not. I would argue that this is a mistake. Not only are these clearly best practices, in terms of giving upper management immediate insight into the threats to the digital assets of the company, but also because “staying out of the paper” in connection with a breach has a ROI that can be measured by any of the myriad studies on the cost of a security breach. But, to circle back to the point of this column, you should manage security with more of a focus on current events, than on improving the vision in your rear view mirror. If nothing else, some of the threat management and log management tools “demo well” to senior management, which can help free up some dollars to bring event analytics from the past into the present.
Our current project at the PCI Knowledge Base is attempting to complete our Retail PCI Best Practices project report. We have broken the report into sections: 1) Log / threat management, and SIEM; 2) End to end encryption / Key Management; 3) Tokenization and scope reduction; 4) Virtualization and System management; 5) Mobile payment and Wireless security; 6) Outsourcing / Service provider security. If you have suggestions for other sub-reports, or topics to break out, please send email to David.Taylor@KnowPCI.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
