Error logging means something went wrong with the runtime code. Crimes could happen and not a single error be raised. Error logs are first for developer diagnostics. Just “logging” and trace are usually for developer diagnostics. When runtime errors aren’t happening, then developers have to move on to trace. System.Diagnostics, enterprise library and log4net are examples of that. Aspect oriented techniques that log all method calls in an assembly would fall in that category.
Server event logging is aimed at the uses cases of server administrators–the Sql Server Logs, the IIS Logs server to help the administrator troubleshoot problems.
The customer of a security log is not the developer or the system administrator. The customer is the court of law, the control and managemetn structures of the company that uses the computer system. When a security log picks up wrong doing, no one asks the developer or system administrator to fix it, instead the wrong doers get fired, arrested, sued, jailed, etc. The developers and administrators will be asked to prevent these in the future, but security logs are not kept to keep developers and sysadmins busy. Security logs are kept to find and punish wrongdoing.
Often security logging turns into an attempt to make databases temporal– meaning the state of data is recorderd for the life of the database. So not only are transactions logged to enable ACID transactions, but the state of each cell in each coloumn in each table is recorded in its before and after state. If the DB is all write with a tiny amount of update, this is okay. If you update your entire database each year, then the logging feature will cause database size doubling– even if you aren’t adding any new rows, customers or sales. While it’s an interesting database problem, data modification logging helps the DBA solve DBA oriented problems, like how to un-corrupt data after the user sends the COMMIT TRANSACTION command.
As exciting as temporal databases may be– its about as relevant as a court lawyer showing and saying he will present his evidence in the form of a real time movie of the suspect, starting when the suspect was born and continuing with out interruption until today. The temporal-database as a security log dodges the question of how to effectively do security auditing and fails to answer it. A planet sized heap of garbage data is still garbage data.
Although there is little support for the idea at the moment, I think security auditing begins with risk and threat assessment. What crimes can be committed with your data? What evidence will we wish we’d gathered for it prosecution? That is what we should audit.