Question

I already audit authorization success, failure and logout.

I’ve considered auditing (logging) every method call and keeping a version of every row and column that was ever modified, but both of those options will greatly increase the complexity of auditing. Auditing a random subset sees too random.

The legal specs (FISMA, C&A) just say something needs to be audited.

Are there any other non-domain specific auditing strategies I’m forgetting?

Answer 1

Considering that auditing is often about accountability you may wish to log those actions that could contribute to any event where someone/something needs to be accountable..

1. Alteration of client records
2. Alteration of configuration
3. Deletion of Data

It is a good idea to keep some of these things versioned, such that you can roll-back changes to vital data. Adding ‘who altered’ in the first place is quite straight forward.

Unless someone has direct access to the database, often application logging of any event that affects the database … such as a transaction altering many tables … may be sufficient. So long as you can link auditable logical action to a logical unit of accountability, regardless of what subsystem it affects, you should be able to trace accountability.

You should not be logging method calls and database alterations directly, but the business logic that led to those calls and changes, and who used that logic. Some small amount of backend code linking causality between calls/table alterations and some audit-message would be beneficial too (if you have resources).

Think of your application’s audit-elements as a tree of events. The root is what you log, for example ‘Dave deleted customer record 2938’. Any children of the root can be logged and you can tie it to the root, if it is important to log it as part of the audit event. For example you can assert that some audit event, ‘Dave deleted …’ was tied to some billing information also going walkies as part of a constraint or something

But I am not an expert.