The Rodney Dangerfield Of Security Controls
Written by Evan SchumanGuest 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.
You remember Rodney Dangerfield, right? He "got no respect," no matter what he tried to do. When it comes to security and compliance, the "Rodney Dangerfield" control has to be logging.
Whether we’re talking about logs generated by network or application firewalls, intrusion detection systems, file integrity monitor tools or the operating systems themselves, I’ve come to the conclusion that the only people who don’t hate them are the vendors who sell them. But, whether we hate them, disrespect them or merely ignore them, we need to learn to live with them. So, here’s some advice on how to do just that. Remember, don’t disrespect the messenger.
After over 130 hours of interviews with retailers, banks, service providers, PCI assessors and myriad other experts for the PCI Knowledge Base, I can safely say that 90+ percent of all these folks are having problems with log management. The concept, as expressed in PCI DSS requirement 10 seems simple enough—"track and monitor all access to network resources and cardholder data." But, it turns out that "all access" to network resources is a heck of a lot of access. Since you’re required to store this data for at least a year, that adds up to hundreds of terabytes of log data during the year. Oh, I should mention that SAN and NAS storage vendors are another group that’s pretty pleased about log management. But, let’s get on with the lessons on learning to respect log management.
Logging is not just for "special occasions" (like when an auditor comes to visit). While almost all merchants regularly review their network logs for performance analysis, most do not keep server or database logging on all the time because it chews up system resources. The result is that most merchants do not have what could fairly be called a "logging plan," in that they didn’t start out with a sense of what level of detail they wanted to capture across the enterprise, but rather simply turn "on" or "off" server or database or other data access logging when potential threats are identified by the network access controls. While this approach works OK for external threats, it’s "not so good" for identifying internal threats, which are the cause of over 70 percent of serious security breaches—the kind you have to report to law enforcement, according to laws in 42 U.S. states. It’s also not enough to be compliant with PCI standards.
Stop pretending these logs can be reviewed manually. Over 70 percent of the merchants I have interviewed are still doing manual log review, at least partially. But almost all of these merchants freely admit that their manual reviews cannot keep on top of all the log data they collect. Most use a series of scripts to sift through the logs for key words and types of events, but it’s still easy to miss patterns. That’s the reason for "event correlation" tools, which use analytics to identify more sophisticated attack profiles that cross multiple platforms.
The "ROI" of log management automation is preventing reportable breaches. Most merchants are collecting and storing log data from firewalls, anti-virus software, network routers, IDSs and servers. But many are not sure that the data they are collecting is the "right" data from a compliance perspective. If you fall into that category, you could be wasting a lot of effort and data storage. Have a PCI assessor or consultant who specializes in this area review your logs. Many companies offer log review and alerting services, and virtually every merchant I’ve talked to who uses such services is happy with the savings in time which these services provide.
Built-in logging tools are generally insufficient for PCI. While Syslogs and Cisco’s Monitoring, Analysis and Response System (MARS) can tell you about network access, they typically are not able to tell you who accessed card data, at what time and whether they were authorized to do so. The one-off, platform-specific tools also do not use consistent formats, making it difficult to meet PCI standards for log aggregation and analysis. For this reason, we tend to recommend add-on tools. There are lots of these tools out there. If you’re interested in what other merchants are doing, just go to the PCI Knowledge Base and search for "logging." You’ll find experiences with a number of different tools.
Pay for usability, integration and superior analytics. While you may be able to pass a PCI audit by doing a sketchy, manual review of basic systems logs, you’re probably not getting any value from the process, beyond compliance. If you actually want to use these logs for early breach detection and prevention, you’ll need to invest in log management and analytics software or services, and then actually devote time to reviewing all the reports from these tools and services. On the bright side, it’s easier to review the reports than the logs themselves. When you’re considering a tool or service, examine the reporting functionality and the ease of integration of different types of logs, to make sure you’re reviewing the "right" data and that false positives are minimized.
Define a log review process you can live with. Whether you buy an automated tool, use freeware or outsource log review to a service provider, someone still has to "run the alerts to ground" and make decisions about which threats are serious and which are not. Some of the merchants we’ve interviewed have monthly meetings and weekly E-mail reports. Others have weekly meetings and daily E-mail reports. Either way, what’s important is that you have clear criteria for threat identification, based on "threat profiles" that are specific to your business, and that the data owners, IT management and the compliance team (or person) all understand and agree to the escalation process. This should be part of your Incident Response Plan, which is required by both PCI and the breach disclosure laws in 42 U.S. states.
Bottom line: Decide how "strategic" you want something like log management to be. You may decide to accept more risk and do only the basic logging, only for "special occasions," or you may want to get a freeware or paid logging tool, or you may want to invest in Security Information and Event Management (SIEM) software that integrates log management with analytics and provides an enterprise framework for managing confidential data. Whatever you decide, we’d like to talk to you. If you’re a retailer, we’re working with the National Retail Federation to develop a series of retail industry best practices in PCI compliance. If you’d like to participate, send me an E-mail at David.Taylor@KnowPCI.com or visit www.KnowPCI.com and click "Register" to join the PCI Knowledge Base.
-Marc
June 23rd, 2008 at 5:58 pm
David’s insights mirror what we’ve seen working with hundreds of mid-market enterprises facing regulatory compliance pressures. At Interop Las Vegas, the top priority that PCI auditors shared with us was the ability of SIEM technology to correlate events – which they admitted is a common failing among many retail organizations.
As David states, not only is it impractical (if not impossible) to analyze logs manually, but you need insight to identify sophisticated attacks that cross multiple platforms. The fact is, log management systems with Google-like search engines and hundreds of reports still lack event correlation, meaning the focus will be on reactive forensic analysis.
The goal of PCI, and many other compliance initiatives, is prevention. Real-time analysis, event correlation, notification and response technology gives companies the opportunity to be proactive and detect suspicious behaviors linked to data loss. It’s clear that at least some PCI auditors are now looking beyond log management and asking merchants to demonstrate their ability to correlate events across all monitored systems, software and users.