7. Developer’s Guide to Audit Logging

Are you a developer or product manager and developing your own application for commercial use? The following guide will walk you through the mindset and work flow of properly logging your application in preparation for auditing and compliance purposes, as well as for security and forensic analysis.

7.1. Purpose

Application logging should always be included in order to view any security event. Application logs are invaluable data for:

  • Identifying security incidents

  • Monitoring policy violations

  • Establishing baselines

  • Assisting non-repudiation controls

  • Providing information about problems and unusual conditions

  • Contributing additional application-specific data for incident investigation which is lacking in other log sources

  • Helping defend against vulnerability identification and exploitation through attack detection

Application logging might also be used to record other types of events too such as:

  • Business process monitoring e.g. sales process abandonment, transactions, connections

  • Anti-automation monitoring

  • Audit trails e.g. data addition, modification and deletion, data exports

  • Performance monitoring e.g. data load time, page timeouts

  • Compliance monitoring

  • Data for subsequent requests for information e.g. data subject access, freedom of information, litigation, police and other regulatory investigations

  • Legally sanctioned interception of data e.g application-layer wire-tapping

  • Other business-specific requirements

Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different.

For example a PCIDSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions. It is important not to log too much, or too little. Use knowledge of the intended purposes to guide what, when and how much. The remainder of this cheat sheet primarily discusses security event logging.

OWASP Logging Cheat Sheet

Note

When creating a log entry, always remember the 5 simple questions you should always answer: Who? What? When? Where? Why? and How?

Who?:

  • Which user initiated this request?

  • Which device was this log generated on?

What?:

  • What was changed?

  • Describe the specific action that has taken place

When?:

  • At what time did this event occur?

  • A timestamp is required to assemble a timeline of the events and when they’ve occured.

Where?:

  • Where did this request come from?

  • Include the hostname, user agent, ip source, GeoIP source country, and source/destination port

Why?:

  • If possible, include a reason why this log has occurred.

  • If an error, a possible guess as to what has caused the error.

  • Or, if authentication, then what exactly are they authenticating with?

  • Remember, the more detail the better.

How?:

  • Does the user have valid permissions to make this change?

  • Mark their authority and any other additional details you may have about the “who” and the “where”.

  • Include as many details that may help assist someone investigating an incident.

Below is an example of some of these items:

  • A Unique event ID and type

  • Timestamp of the event

  • Error message

  • Success or failure of event

  • IP address of the client

  • User ID triggering the event

  • Resources accessed

  • Application Interface used by user

  • Co-relation with audit trail entries

7.2. When should I generate logs?

  • All user account management activity should be logged.

  • Addition and deletion of user accounts

  • Changes in security attributes (access-levels, login intervals, terminal login restrictions, connection interface)

  • User account suspensions and reactivations

  • Administrative password resets

  • Every access control related events should be logged.

  • Successful and failed logon/logoff events

  • Account lockout events (in-valid password, inactive session, access from un-allowed interfaces, login attempts out of valid intervals, max. concurrent session limit violations)

  • Password changes.

  • Changes to application configuration settings should be tracked.

  • Change to critical functional settings (eg. interest rates, service charges, grace period)

  • System parameters (e.g. max. no. of concurrent connections per user, Password length)

  • Access attempts to application and underlying system resources should be logged.

  • Changes to cryptographic keys

  • Startup/stops of application processes

  • Abnormal application exits

  • Failed database connection attempts

  • Attempts to modify critical registry keys

  • Login/logoff for Maintenance

  • Failed integrity checks for application data, executables and audit log should also be logged.

Paladion Application Logs (Security Best Practices)

Note

It is your responsibility as the developer to know what items are important to your application, as well as your customers. These are also items that should be logged.

7.3. How should I be delivering these logs?

SIEM/BDSA/Logging platforms collect logs in a variety of methods. The most common and recommended method is syslog. Many solutions have an agent that will send logs from your application, if your application writes it to the EventLog (Windows), a log file, or to Syslog (Linux/BSD/MacOSX/Solaris/etc).

Depending upon the language your application is written in, will dictate which logging library or mechanism to use. We recommend using the best of breed for your language. Some examples include:

7.4. What format should my log message or syslog line be in?

Our recommendation is to use the Common Event Format (CEF) message for logging. This is the structure chosen to send messages via syslog protocol tcp or udp on port 514:

Log Message Example:

CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension variable information]

This format will allow us to absorb the information very easily. An example of this message is as follows:

CEF:0|COMPANY_NAME|APPLICATION_NAME|1.0|100|worm successfully stopped|10|src=10.0.0.1 dst=2.1.2.2 spt=1232 username=guest dpt=80

A 3rd-party full documentation guide for this can be found here

Please note, HP Enterprises is responsible for creating this format and making it an industry standard. This standard is preferred for all Log Management/SIEM/BDSA platforms.