Quantcast StorefrontBacktalk » Blog Archive » The Regrettable Databreach Rear View Mirror Strategy
advertisement
advertisement

The Regrettable Databreach Rear View Mirror Strategy

Written by David Taylor
March 25th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

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:

  • The PCI logging standards focus on forensics
    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.

  • Do the impossible, at least once a day
    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).

  • Taking threat and log management seriously
    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).

  • Why you should do more than the minumum
    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.

  • Bottom Line: PCI and Fraud Reduction
    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.


  • advertisement

    Leave a Reply

    Newsletter

    Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
    advertisement

    Most Recent Comments

    Kill All The Passwords

    This article does mention, but does not give enough attention to, the fact that the attacks discussed are only feasible when the encrypted password file can be copied and subjected to an offline attack. The trick is to have authentication performed on a separate, much more strongly secured host - such as an Active Directory Domain Controller, or a Kerberos server, or a NIS+ server, or even using something as banal as an LDAP-over-SSL authentication dialog. In these environments, the odds of the "password file" being stolen and subjected to an offline attack go to near zero, and only online attacks may be carried out by the attacker. With sensible exponential backoff between failed password attempts, lockout after a modest number of failed attempts on a single account, and pattern detection, that minimum 7 character password is quite secure enough. Passwords aren't dead yet for security purposes, and they will be with us for a very long while to come for practical purposes. The trick is to employ them correctly. Read more...
    The possibilities you describe are years away from being implemented at best, so for the moment passwords are an ugly reality. Luckily, password managers can easily manage hundreds of passwords of any length. The only thing a user needs to remember is the master password. It seems like an easier task to educate users on how to use password managers rather than implement complex security technology on a global basis. Read more...