Kim Zetter from Wired Magazine put Wal-Mart back in the news recently with information about an alleged incident that occurred in the 2005-2006 timeframe.  One of the key issues making the rounds is the following assertion made by Zetter:

The company’s server logs recorded only unsuccessful log-in attempts, not successful ones, frustrating a detailed analysis.

Logs serve multiple purposes, and for that reason they tend to grow rapidly.  Sure, storage is cheap nowadays, but every company still struggles with this very basic concept.  While I won’t speak specifically to the Wal-Mart incident (Evan Schuman has some great additions), I will address some of what I see with my customers and their struggles with logging.

Back on the Log Train, by Claire L. Evans

Back on the Log Train, by Claire L. Evans

Over-Logging

This is more typical than you might believe, especially after reading the Wired article.  For example, we had one customer that installed a commercial logging package, turned everything on, and all the sudden was generating gigabytes of log data every day at every retail location.  What are you supposed to do with that?

Over-logging creates more problems than filling up tons of hard drives, it also causes transport problems.  Many security standards or best practices require that you a) log, and b) centralize those logs for various purposes like correlation, archival, and backups.  So if my satellite location is connected to corporate via a VPN over a business-class DSL, is it feasible to send gigabytes of data back to corporate servers daily?  What about with all the other daily usage and off-hours batch activities?  What if your business internet connection is a satellite VPN and your bandwidth resembles a 256Kbit frame relay (loves me 4 B channels tied together!)?

Log Texture, by Playingwithbrushes

Log Texture, by Playingwithbrushes

Under-Logging

This is the one we focus on the most.  Logs can be some of the most valuable nuggets when investigating a breach.  One of my colleagues once investigated a breach that required imaging over 7 terabytes of drives before he finally found the source of the breach.  Why?  Because the lack of logging was so significant that there was literally no clues as to where the breach came from.  No sophisticated hacking attempt here where a hacker erased their trail.  This particular victim made it easy for the hacker because there simply was no trail!

Logs provide lots of valuable information regardless of your pre- or post-breach status (no, I did not mistype that).  If you have not had a breach yet, logs can be useful when looking for bugs, capacity planning, and finding ways to optimize your systems or applications.  For example, in next month’s column, I discuss how a development manager found a security problem in some code that I wrote ages ago by watching logging activity.

Those are the two extremes.  Where should we end up?

Right-Logging

Yeah, I couldn’t think of a better title for this last part here, so SSSSHHHHHHhhhhhh…

In order to get the most from your logs where they both add value and satisfy the requirements assessed by various security practices, you have to put the right strategy into play.  You first have to understand what capabilities your systems have.

In some cases (*cough* WINDOWS *cough*) you will probably be creating custom scripts or using third party software to capture what you need.  Be advised, turning ALL LOGGING ON will get you quickly into the Over-Logging category, and that is a spot you don’t want to be.  Instead, review all of the possible things you could capture and log, and choose the ones that make the most sense for your business.  It’s not easy, but the rewards are significant.

Once you are capturing the RIGHT logs, you will need some kind of tool to aggregate all of this stuff so you can make use of it.  Having one system kick out an error is not helpful, but being able to see that similar systems all over your enterprise are simultaneously kicking out the SAME error.  That’s where Security Information and Event Management (SIEM) comes into play.

This is a VERY hot topic in the blogosphere.  Here are a few bloggers (or blogs as it were) with valuable information on SIEM:

  • Anton Chuvakin’s Discussions on SIEM
  • SIEM Blog
  • RSA’s bloggers discuss SIEM
  • Andrew Hay’s view on SIEM
  • Security Bloggers Network results provided by Lijit

Don’t dismiss logging as unimportant or irrelevant to your security plans.  Go back to those “fortress systems” that you believe to be impenetrable and ensure you are capturing logs to prove it!

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts:


Tagged with: ,

0