Audit Trail Basics

Updated: May 4th 2012 to add reference to OWASP Logging Cheat Sheet

Updated: August 26th 2010 to add reference to The European Payment Council document

Anybody who has looked at the Payment Card Industry Data Security Standard (PCI)  will know that audit activities are an important requirement. An audit trail will maintain a record of significant events, such as logon, logoff, password changes etc. From an information security perspective an audit trail is an important control as it can be used to help monitor what is happening - and to notice if anything unusual is taking place. In addition it should be able to help recreate what happened in the event of an investigation. Most web applications do not have a proper audit trail. There might be various log files. But it can be difficult to use these in helping to recreate what happened.

However, if the audit requirements are considered at the start of a project, it is easy to build in the appropriate infrastructure to support it. At its most basic, it is a simple API that can be called from anywhere within the application. The Audit API should include the userID, type of event (e.g. logon, logoff), success or failure, timestamp, description.  Then call the API whenever a significant event occurs - such as logon, logoff. The audit API can then write the event to a permanent store. This could be a database table, a Syslog Server or similar. With the basic infrastucture in place, there are a number of other considerations. A mechanism is needed to view the audit trail. Another question is how long the audit trail should be retained for.

Requirement 10 of PCI goes into much more detail as to what is expected if you are processing payment cards. For example, the audit trail should be tamper-proof. This becomes important when the audit trail is used during formal investigations.

Basic Steps
Here are the basic steps you should think about at the start of the application.

1. Define an audit API called something like WriteAuditEvent. The API should take at least the following parameters; userID, eventType (logon, logoff etc.),success or failure flag, description. Make sure that the audit trail does not contain sensitive information - especially passwords.
2. Define the initial list of audit event types. These should include all significant user lifecycle actions, such as logon, logoff, change password etc. More events will depend on the functionality of your application.
3. Call the WriteAuditEvent from the application when the events occur.
4. WriteAuditEvent should write the details (including timestamp) to an audit store. This could be a database table, file, Windows event log, Syslog Server etc. Ideally this store should be tamper proof.
5. Develop a mechanism for querying the audit trail. This should be fairly flexible to allow you to focus on certain events or users.
6. Decide how long the audit log should be retained for.

There's a lot more that could be written about audit trails. However those are some basic steps. It is easy to build in simple audit trail functionality if you think about it at the start of your development.

Some Links:

• You can download the PCI Standard from here here (PDF) 
• How to Do Application Logging Right talks about some technical aspects.
• Have a look at the OWASP API and AppSensor 
• In June 2010, the European Payment Council published THE USE OF AUDIT TRAILS IN SECURITY SYSTEMS: GUIDELINES FOR EUROPEAN BANKS
• OWASP Logging Cheat Sheet 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot