What is it and why should I care?
Auditing security related events includes two basic concepts, so we’ll begin by treating them individually.
Auditing is a key part of any real software system. Many people treat logging and auditing as the same idea, though they’re actually different. Definitions might vary, but mine boils down to the consumer of the output. In general, logging data is consumed by developers (most often for debugging problems), and possibly business owners to see basic trending information (likely through some basic log parsing for usage statistics, etc). Auditing, on the other hand, is meant to be used by auditors to reconstruct the events that occurred in the system. The view of these events is often constrained by a time period, a specific user or set of users, a specific function or set of functions, etc.
Usually, logged data is unstructured and can be or represent anything. Audit data, on the other hand, is generally structured, and can be thought of more like a database record where there are specific fields that are always filled in, and the only thing that changes is the data in the column, not the column itself (to use the DB analogy).
Security Related Events
Security related events are going to be determined by you as part of your development process, but there are several obvious candidates, such as login, logout, user management, credential management. etc. All of these are clearly security related and could be important to the security posture of your application either generally or specifically related to a single user or set of users.
Knowing that a security related event has occurred is important. Not knowing could lead to not only unauthorized access or usage of the system, but the inability to know that it even occurred.
What should I do about it?
Auditing is the option to choose when you’re talking about security-related events. For any security-related event that occurs in the system, you should be auditing the activity. You should collect appropriate data on each event, such as event type (what happened), actor performing event (who did it), timestamp (when did they do it), etc. This type of data will allow you to filter the dataset by user, time, function, or any of the other data points when needed to determine specifically what occurred from an auditing perspective. Structured data in this form also lets you do helpful things like look at generic patterns and find that a specific user did a bunch of things outside work hours (unusual?) or everyone in the system all performed a single function within an hour of each other (maybe strange?). Some of these ideas are found in the concept of AppSensor, an OWASP project I work on.
I would also like to point out a great talk Gunnar Peterson gave at an OWASP chapter meeting called “Audit Logging Done Right“. That video goes into detail about auditing and the power it has when used appropriately.
Auditing is not a new technology, and often is viewed as a boring “have to do”, but it is actually a very powerful concept that lets us gain access and visibility into what the application is doing. It also gives us all of the nice capabilities of dealing with structured data . Once you recognize the utility, I hope you’ll start auditing a few more things out of the realization of it’s power, not just obligation!
http://vimeo.com/15423426 – Gunnar Peterson – Audit Logging Done Right