Application Security Logging

events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

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.

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

Happy application logging!