17 August 2010

Application Security Logging

I have been meaning to write again about web application security logging, but luckily read a paper last week which provides excellent guidance.

Photograph of three footprints in wet sand wave ripple marks on a beach in Northumberland

How to Do Application Logging Right is the best guidance I have come across to date. Co-written by Anton Chuvakin and Gunnar Peterson for the IEEE Security & Privacy Journal, the paper describes the problems with typical logging systems, what events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

Previously, the most notable application security logging guidance existed buried rather deeply in the documentation for OWASP's ESAPI Java edition, the OWASP Logging Project, and more general guidance in NIST's SP 800-92 Guide to Computer Security Log Management.

If you read those in conjunction with the new paper, and perhaps Chuvakin's and Peterson's own comments, you'll be well up to speed.

The content of the "module", "object" and "action" fields will be dependent upon the degree of granularity required and how much additional event information is collected as additional details (e.g. stack trace, request headers, response body). I believe a transaction ID should always be included so that all events for a single request/response can be more easily correlated—this has a request scope rather than the session scope of a username/id. If I might suggest some other additional items for "what to include", I would also consider:

  • host address (e.g. host name and domain, or server IPv4 or IPv6 address) which is useful if clustering is being used, or to confirm logs are from live rather than staging systems
  • service (e.g. name, port and protocol)
  • full actual entry point URL (protocol, full domain, port, path and further parameters)
  • canonicalised entry point URL
  • HTTP method (for web applications)
  • responses seen by the user and/or taken by the application (e.g. status code, custom text messages, session termination, administrator alerts)
  • analytical confidence in the event detection (low, medium, high or a numeric value).

Full request headers and possibly the response body may be worth collecting for some events. But ensure these are sanitised for sensitive input such as passwords, session cookies or credit card numbers.

I would also tend to use a severity scale (0=emergency, 1=alert, ..., 7=debug) rather than the suggested "priority" field, for consistency with syslog protocol. But the paper's authors note that whatever scale is used, it will be different for each organisation due to their own priorities and views on risk.

You may also want to consider how the integrity of the logged information can be determined.

Whatever you log, bear in mind you probably want it to be relatively human-readable, but also done in a way you can share the information with other systems. For the moment, consider Common Event Format (CEF). But Common Event Expression (CEE) is an ongoing collaborative effort to develop an event interoperability format summarised in a presentation, and in more detail in a white paper. The CEE web site includes a description of alternative approaches for sharing data from event producers.

See also my previous web application logging related posts How Much Logging, Monitoring and Alerting?, Security Logging Requirements, Testing the Audit Trail, Don't Stop the Attack (Too Soon), and Application Log Management and Analysis.

Happy application logging!

Posted on: 17 August 2010 at 11:22 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

Comments

Comments are filtered automatically and should appear shortly after they been checked.

Post a comment
Confirm acceptance and understanding of the terms of use
New posts to this thread will be sent to your email address
Application Security Logging
http://www.clerkendweller.com/2010/8/17/Application-Security-Logging
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/2010/8/17/Application-Security-Logging
Requested by 107.21.136.116 on Sunday, 20 April 2014 at 08:00 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2010-2014 clerkendweller.com