Logging Like a Lumber Jack

Turn on any news outlet or visit any news site and you will most likely see an announcement of yet another data breach.  On the DTR podcast we discuss breaches in the news during almost every episode.  There is a push to put more of an emphasis on identifying and reacting to a breach or security incident rather than just focusing on preventing the event from happening to begin with.  We want to prevent as much as possible, however the reality is that breaches appear to be inevitable and if that is the case, we should put some focus on properly reacting and identification.

Logging is a key element to any security program.  It provides the capability to see what is currently happening as well as what has happened in the past.  In the event of a breach, the logs become critical in determining what happened, what data may have been effected, etc.

Current Logging…

Over the years I have found that many developers do incorporate logging into their applications, but it is not for security purposes.  Most of the time the logs are strictly for troubleshooting.  This makes sense because that is where a developer focuses their time once an application has been released.  Without debug logs, it can be really difficult to fix a problem.  The issue here is that while this works for debugging, it doesn’t really help from a security standpoint.   In the event of a  breach, it is doubtful that a log full of stack traces is going to be the help that is needed to determine what happened.

What Should I Log?

There is no exact formula for what needs to be logged in a system.  There are of course some starting points that are consistent across many platforms.  The following are a few examples of events that should be logged.

• Failed Authentication Attempts
• Successful Authentication Attempts
• Account Lockouts
• Sensitive Transactions
• Access of Sensitive Data
• Application Feature Changes – Logging Disabled/Enabled, System/Application Shutdown

Unfortunately, the hard part comes in when you are trying to determine the key elements to log.  You have to have a solid understanding of your business and what is important to it.  Take the time to identify the key data the application uses, the key transactions that must be recorded, and why you are logging to begin with.  

Don’t Forget Monitoring

Logging doesn’t do a whole lot of good if there is nothing monitoring it.  All too often we hear of breaches that happened more than a year ago and the Incident Response team shows the evidence from a log file.  If only someone had been looking, it would have been identified much more quickly.  Make sure that you have some method for reviewing the logs regularly.  There are lots of packages available to help with this process.  I know, manually looking at logs all day is not much fun at all.

The monitoring should be more than just looking for attack requests, but have the ability to identify when a brute force attack is happening so an alert can be sent to a technician.  As you spend more time logging and reviewing those logs you will be able to identify more events you want to monitor to help secure the site.

What To Do?

Develop a plan for any items that could appear in the log that are of concern.  Just like any response plan, you want to know what steps to take in the event of a security alert.  For example, brute force attempts may be met with blocking an IP address.  The identification of a compromised server with malware may mean taking that server offline immediately.  Know what procedures exist so proper reactions can be performed as soon as possible.

James Jardine is a Principal Security Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.