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.
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
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 then 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 firstname.lastname@example.org or visit the Secure Ideas - Professionally Evil site for services provided.