Evan Schuman's StorefrontBacktalk

Let’s consider the case of a large retailer with multiple store locations that decides to decentralize daily log review all the way down to the store level. I am not a fan of this approach, but the retailer could put a log management application on each store’s server and then customize it to match its systems and to alert management to what is important. If each store has the same applications and systems, the process is potentially feasible.

It is now up to individual store managers (once you train them—another cost) to conduct the daily log review, which presents its own issues. If the system is improperly tuned, the manager will be overwhelmed with alerts. Furthermore, even if the system is properly tuned to reduce unnecessary reporting, it will be extremely difficult for the retailer’s IT staff to monitor performance and continue to retune the system so the log alerts remain relevant.

PCI Requirement 10.5 presents another set of challenges with this approach because you would need to apply it to each store location. For example, 10.5.1 says to “limit viewing of audit trails to those with a job-related need.” Does the store manager really have a job-related need to view alerts?

Then 10.5.2 requires you to “protect audit trail files from unauthorized modification” and 10.5.5 says to use file-integrity monitoring and change-detection software so no one can change a log file. If a store manager (or a subordinate, if this daily task is delegated) goes rogue or the retailer is subjected to a sophisticated attack, the attackers may attempt to alter the audit trails to cover their tracks.

Lastly, each store needs to back up the logs on a server or other media that is “difficult to alter.”

These requirements are hard enough to meet in a centralized IT shop. Talking your QSA into accepting that your chain is meeting them at the store level is likely to take some doing.

An alternative approach is to centralize logging and log reviews. In this case, retailers can install an agent on each store server or explore software as a service (SaaS), which certainly can work well, too. Either option may be expensive, but there are vendor packages available in the market.

Some systems generate mountains of logs, while others generate hardly any at all and still others strike a good balance somewhere in the middle. With a large number of retail locations, the volume of messages will need to be tuned to alert only on significant events. The issues retailers have to deal with are bandwidth for transferring all the data, storing (and backing up) the logs once they are received from the field and then analyzing the actual alerts.

Centralizing daily log review also helps companies meet Requirements 10.5 and 10.6. That approach puts retailers in a better position to demonstrate separation of duties as well as to store and protect the actual log files.

I usually stay away from making too many recommendations. However, from my perspective, the centralized logging and log review approach seems much more sound from both a compliance and a security perspective. There are some good vendor alternatives in the market, but the key to success is tuning the logging system so it matches your environment.

Therefore, writing a check is just a start. Retailers need to budget time to configure, monitor, manage and update their logging strategy. My favorite approach is to assemble a logging team—include both management and security people—to look at your needs from a risk and a security perspective instead of just taking a compliance view. If you are the one heading that team, you have to ask yourself: “Will we know if one of our systems is compromised?” Then keep asking that question until you can answer: “Yes.”

Unfortunately, based on the statistics in Verizon’s 2010 Data Breach Investigations Report, not everybody is doing a good job meeting Requirement 10.6. Verizon found that in 86 percent of cases, victims had evidence of the breach in their log files but no one was looking. We all have to agree that this situation is not acceptable. What it tells me is that the requirement is sound, but that we need to find a better way to meet it.

What do you think? How do you implement your daily log reviews, especially if you have a lot of stores? What resources are you devoting to tuning your logs so you don’t get overwhelmed with the logging equivalent of white noise? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.