Application Logging: The Next Great Wonder

Posted by on August 2, 2014

What type of logging do you perform in your applications? Do you just log exceptions? Many places I have worked and many developers I have talked to over the years mostly focus on logging troubleshooting artifacts. Where did the application break, and what may have caused it. We do this because we want to be able to fix the bugs that may crop up that cause our users difficulty in using the application.

While this makes sense to many developers, because it is directly related to the pain the face in troubleshooting, it leaves a lot to be desired. When we think about a security perspective, there is much more that should be considered. The simplest events are successful and unsuccessful authentication attempts. Many developers will say they log the first, but the latter is usually overlooked. In reality, the failed attempts are logged most likely to help with account lockout and don’t server much other purpose. But they do. Those logs can be used to identify brute force attacks against a user’s account.

Other events that are critical include logoff events, password change events and even the access of sensitive data. Not many days go buy that we don’t see word of a breach of data. If your application accesses sensitive data, how do you know who has looked at it? If records are meant to be viewed one at a time, but someone starts pulling hundreds at a time, would you notice? If a breach occurs, are you able to go back into the logs and show what data has been viewed and by who?

Logging and auditing play a critical role in an application and finding the right balance of data stored is somewhat an art. Some people may say that you need to just grab everything. That doesn’t always work. Performance seems to be the first concern that comes to mind. I didn’t say it would be easy to throw a logging plan together.

You have to understand your application and the business that it supports. Information and events that are important to one business may not be as important in another business. That is ok. This isn’t a one-size-fits-all solution. Take the time to analyze your situation and log what feels right. But more thought into it than just troubleshooting. Think about if a breach occurs how you will use that stored data.

In addition to logging the data, there needs to be a plan in place to look at that data. Whether it is an automated tool, or manual (hopefully a mix of the two) you can’t identify something if you don’t look. All too often we see breaches occur and not be noticed for months or even years afterward. In many of these cases if someone had just been looking at the logs, it would have been identified immediately and the risk of the breach could be minimized.

There are tools out there to help with logging in your application, no matter what your platform of choice is. Logging is not usually a bolt on solution, you have to be thinking about it before you build your application. Take the time up front to do this so when something happens, you have all the data you need to protect yourself and your customers.

Comments

Comments are closed.