In a previous post I introduced the new OWASP Security Logging Project.  The project is fresh out of the oven.  At the time there was mostly broiler text on the wiki and few breadcrumbs for visitors to understand the project or it’s benefits.  Since then we published some project background, for full background on the OWASP Security Logging Project see the projects, “Roadmap & Getting Involved” page.

A number of powerful logging technologies are available.  The challenge with popular logging frameworks is that they focus mostly on diagnostics while security and audit are mostly an afterthought.  Most developers that require security and audit logging extend popular logging frameworks for their own purposes and often with inconsistent results.  Following are a few larger obstacles we considered when adopting popular logging frameworks for security and audit logging.

Logging platforms use-case agnostic
Popular logging platform designers are interested in developing platforms that are most useful to the widest possible audience.  As such it’s not clear to developers who use these frameworks how they should be used for security or auditing.  For instance, if your logging an access failure should the message level be a WARNING or INFORMATION type message?  The point is that a system written from a software diagnostics perspective is not necessarily intuitive for use in security and auditing.  Often log quality varies from deployment to deployment since it left up to each application designer to implement these use-cases on their own.  Sometimes these logs are little benefit for security or auditing and even worse sometimes the logs provide sensitive information attackers find helpful.

Logging is non-functional requirement
By non-functional requirement I mean, logging is seldom a feature the Software Development VP mandates is included on the projects schedule.  Logging is something developers need when “fit hits the sham”.  Comprehensive logs are tools application designers need to do a better job but not generally the focus of a project effort.

Lack of domain expertise
Security and auditing logs have a wider audience than diagnostic type logs.  Consider for a moment that software diagnostic logs are useful to application designers whereas security and audit logs are likely more useful for the business units.  Even if software developers are fortunate enough to recevie some time on the schedule to build the application logging system, development may not have the required skills to build such a system.  Last but not least, loose a diagnostic message and it’s irritating.  Loose your audit log or log the wrong information and someone receives a permanent unpaid vacation, company fines, or worse jail.

Why are we doing this?  We see some room for improvement in security and auditing logging for our applications.  The OWASP Security Logging Project is planning a combination of software and documentation building upon popular frameworks to guide the development community to improve the quality of software logs.  If your interested to participate or learn more about the project take a look at the project wiki.