Some Brief Thoughts on Logging

I found this article in my news feed this morning: Why PCI Will Issue Log Monitoring Guidance I tried tweeting it but could not properly rant in 144 characters or less so here we are on the blog.

This article brings up two very important aspects of information security management.  The first one is log monitoring.  You gotta log. But more importantly, you gotta look at the logs and figure out what they are telling you.  Log analysis can be tricky mostly because of volume.  The signal to noise ratio can be pretty low even if you use a Security Information and Event Management (SIEM) system.  It can be a little like a shaman reading the entrails of some unfortunate goat, but in this case the shaman is your incident responder, the goat is a network node, and its entrails are a syslog file.  (Perhaps not one of my best analogies but we’re going with it.)

I’m not a log analysis expert but know enough to be dangerous.  Here are some things to keep in mind when looking at the logs:

  1. Keep a copy of critical logs on a remote system.  The bad guys will cover their tracks and deleting or editing logs is one of the ways they do it.
  2. Logs will be helpful in detecting blatant attacks.  If you get popped with a Metasploit attack, your IDS/IPS or firewall will probably detect it and log it.  New member of the Admin group added?  Probably in your logs.
  3. Logs will be less helpful in detecting pivots within your network after initial compromise.  The bad guys use the same tools to connect to remote systems and manipulate data as you do.  Your log analysts will have to have a good idea of what normal for your network looks like.  Poaching guys and gals from the server and network teams can provide some very insightful log analysts and incident responders.
  4. Get a SIEM if you can afford it.  It will automate your process and act as a good filter when properly configured.  (EDITOR’S NOTE: Continuous and proper configuration is not a trivial process.) *
  5. Establish a dedicated team to check the logs and respond to events.  Full FTEs would be ideal, but you can make do with a couple of partials and a solid process.  If you can’t do either of those, look into a Managed Security Service Provider (MSSP) to do the work for you. *

The second issue the article discusses is vendor management, which I’ll leave on the table for now.  It deserves its own rant.

* Reach me via private message on LinkedIn if you want some pointers on vendors I’ve had good luck with in the past.  

Leave a Reply

%d bloggers like this: