The application development community has come a long way in armoring their programs against the OWASP Top Ten and SANS Top 25 type of security problems, and I'm not being cynical here: While SQL injection and Cross Site Scripting are still widespread, most developers nowadays know about these problems, and are even competent to avoid them if not pressed by due dates, budgets or management to take short cuts. 

Cue the next big thing that InfoSec will have to convey to the developer community: How to write code that produces meaningful application logs. As an example, almost every country has laws in the books that ask for safeguarding of sensitive medical data, and these laws are explicit in their demands on the security controls that need to be in place. Like diligent monitoring of logs.

Well, yeah. But if an application log of a medical application looks like the example below

2010-04-06 09:57:18,773 [arch.PROCESS_CONV] INFO - JavaToDataObjectConverter.convert TransportData _PI:9d030227.c3692d30 notifyDataFlowCompletionResponse Start
2010-04-06 09:57:18,773 [arch.PROCESS_MAP] INFO - ServiceResponseTranslator.buildMessage TransportData notifyDataFlowCompletionResponse Start
2010-04-06 09:57:18,212 [arch.PROCESS_SERVICE] INFO - Invoker.createRequest TransportData notifyDataFlowCompletion

then nobody except the developer him/herself can do any monitoring. An application log file is not supposed to be a techie-only pile of debugging jargon. In my ideal world of application auditing, the authorized application users themselves would see (and be able to interpret) some of the audit records, and thus collaboratively ensure acceptable use.

Imagine, for example, an application in a hospital that displays medical files and x-ray pics. An "audit log" somewhere on the server does very little good, but displaying underneath a celebrity's X-ray picture who of the medical staff last looked at the same picture: now there's effective auditing. Doctor A is far more likely to think it odd that Doctor B looked at this x-ray than, say, some IT techie in the backroom who was charged with watching the hospitals "Security Info and Event Management" (SIEM) tool. 

Firstly though, the logs have to become more meaningful: Who did when what to which record is pretty much all it takes. Too much volume? Well, then focus on read access to privacy relevant/sensitive objects, and write access to integrity relevant objects like account balances. Once we're there, we can always go further if needed.

But, dear developer, please spare us the debug log that got swiftly re-branded into "audit log" five minutes before project completion.